RC Networks, They Matter!

After a long hiatus, I’m finally dusting off some projects and getting back into them, well, one in particular, the sous vide controller. I knew there were board errors from the prints I ordered early last year, I had even started to fix some of them. I got the boards and components and eagerly assembled one. Once I powered it on, there was one immediate problem. The LCD contrast with a diode that I wrote about previously, well, it’s not giving so constant a contrast on this board. Maybe it’s a poor diode, maybe I’ll build a bench power supply to vary the voltage across different diodes and see how they respond.

After putting some code on the chip, I found another problem. The push button on the encoder would not work. I got nothing at all from it. From probing the board and the resistors, I discovered that the button was active high, but my idle resistors were also pull-up. Tsk tsk. Ah well, that’s an “easy” fix, just scratch out some traces, re-route (in this case a power rail) around them, no problem, and connect the common side of those resistors to GND instead.

That got the button working, but not the encoder. Long story short, I played with the hard-to-see LCD for a while and then set it down for many moons. Oh that’s right, I also had to cut the common freewheel diode leg from the transistor array because apparently that’s not supposed to connect to “common”. Oops.

Fast forward, and now I dust it off, scratch my head, and try writing some simple encoder and button tests onto it. When they failed, I turned to my schematics, and scratched my head again. What I noticed actually pretty quickly is that the encoder legs were active LOW, but the push button active HIGH! *sigh* “I see why I did that,” in a way at least. I had to tie the push button active high because it shared with the common anode on the encoder LEDs. And it would seem I found that out after I made the quadrature active low.

So, I fixed all of that. I’m determined now to get this board to work. Of course I’ll make another run with corrections, but only after I find all the corrections. A few more trace cuts, more jumpers, and I got all the inputs working. Well, kinda… The rotary worked, a little bit. But not nearly fast enough. First I sped up the polling and that helped, only a little. Then I went full on PCINT driven, and no more improvement was to be found. At this point  I was beginning to suspect the RC network was too slow.


I plugged those values into units (not that that would be particularly needed in this case, but just the same, I highly recommend units!) and looky there. Fall time of 15ms! Yikes.

So I replaced the capacitors with some 15pF I found at Ra-Elco, and now it works flawlessly.

Moral is, don’t make board mistakes.
Moral is, you’re probably going to make board mistakes.
Moral is, don’t just pick component values because … whatever? Ya, don’t do that.

Broken, Now Fixed

Seems this blog was broken, not sure for how long. Tracked the issue to a missing AllowOverides directive for apache.

Hey googlers. If you have a wordpress site and you get 404 on every page but the main page, and you’ve checked everything else everyone tells you to do (check the .htaccess file, check mod_rewrite is on, save the permalink style again and again) and still no dice? Check apache’s AllowOverrides for the directory. 😀

h/t http://www.electrobucket.com/linux/debug-wordpress-permalinks-not-working

USBee and PulseView

If you get one of these USBee AX PRO logic analyzers and you try to use it in linux with pulseview you’ll probably get the cryptic error “Failed to set time-based sample limit.”

USBee clone
USBee clone

What actually fails is uploading the firmware to the device, which the pulseview message kindly leaves out. If instead you use sigrok-cli you might notice that the firmware failed. The problem is one of mere permissions. You can simply run pulseview as root and it works dandy. Or, if you followed the instructions here and copied the udev rules to /etc/udev/rules.d then you just need to add your user to the group plugdev. If you use RPM you can see where the rules file is in the libsigrok package. It’s in /usr/share/udev/rules.d/. Actually, I’m not sure if it even needs to be copied from there to /etc to work. It may work just fine where it is.

Now, enjoy using your logic analyzer in linux!