PteroDAQ boards

I took a photograph this afternoon of three of the boards that can be used with the PteroDAQ data acquisition system:

On the left is the Arduino Leonardo, the slowest and most expensive of the boards here. In the middle is the KL25Z, which I’ve been using in my class for a couple of years—it is the cheapest and most featureful of the boards. On the right is the Teensy 3.1 (without headers yet), which is the fastest and smallest of the supported boards.

I’m considering switching to the Teensy 3.1 for the class, despite its higher price than the KL25Z board, because adding male headers to the bottom of the board makes it possible to plug the Teensy 3.1 into a bread board, which makes for more secure wiring than running separate wires to the KL25Z board.  We don’t really need the 64 pins of the KL25Z board, we’re not mounting Arduino shields, and we’re not using the accelerometer or the touch sensor, so the main question is whether it is better to have the data-acquisition board be standalone or be inserted into a bread board. The RGB light on the KL25Z board is a nice feature for providing feedback that is missing from the other boards (which only have a single-color LED).

I’ve also thought about usefulness to the students after the course, though few of the students will go on to do anything other than PteroDAQ with the boards.  The Arduino IDE is much easier to deal with for beginners than any of the development environments for the KL25Z, and Teensyduino is pretty easy to install on top of the Arduino environment.  So if students are going to go on to do hobbyist-level programming on the boards, then an Arduino board or the Teensy 3.1 might be a better choice. Given how much more powerful the Teensy 3.1 is than the old ATMega-based Arduinos, I see no reason to recommend buying Arduino boards (though clones from China have gotten down to about $3).

Erich Styger, in a comment, mentioned that he is frustrated by the Teensy’s lack of a SWD (serial wire debug) connector, which he is used to using for debugging. Since I’m from an older generation of programmers, I don’t miss it—I’ve not used the SWD connector on the KL25Z boards (though my son has, to use the OpenSDA chip as a programmer).  For me, it is a luxury to have a serial port for getting print messages from the board—I started microprocessor programming in the days when having one or two LEDs was about all the information you got back from the board. Having debuggers like GDB was a luxury available on computers that cost thousands of dollars.

Of course, the ARM processors on the Teensy 3.1 and the FRDM KL25Z boards are very much more complicated than the old 8080A, Z80, and 6800 8-bit processors I started with, and people are writing much larger programs for them, so I can see the advantage of having a debugger. But there is a large startup cost to learning to use a debugger and setting up the complicated software development tools they expect you to use, so I’m happy recommending the very limited, but easy-to-use Arduino interface for bioengineering students who want to go a bit further.

I’m curious what my readers think about the choice between a FRDM KL25Z board and a Teensy 3.1 board for the Applied Electronics class, given that most of the students will only use the boards for that class.  What tradeoffs might I have missed?  If you were in the class, which board would you rather work with?

Differential ADC not working in ATMega32u4

I spent considerable time last night trying to get the differential ADC inputs working on my Arduino Leonardo board, and finally gave up.  Here is what I found:

• It was easy to set up the MUX to get differential inputs to do something—I wasn’t having trouble selecting the appropriate pairs of pins.
• The signal was much smaller than expected.  I expected a 2-fold reduction in signal, as the range for the 10-bit conversion goes from [0,+5V) to [–5V, +5V], but what I saw was an 8-fold reduction in the signal.
• Despite clear descriptions in the manual of how the differential inputs are supposed to work, the 8-bit output of the differential ADC is not aligned with the the MSB in the same place as the 10-bit single-ended DAC.  This further means that setting the ADLAR bit to get left-alignment of the outputs does not left align the signal, but leaves it a factor of 4 short of that goal.  With the gain set to 10, there seemed to be one bit less, and so the signal seemed to have not a gain of 10, but of 10/16, rather defeating the point of having an amplifier.
• The signal was far noisier than just reading the two channels separately and subtracting in software.  Setting the gain to 10 seemed to amplify the noise more than the signal.
• When using the paired inputs with a gain of 10, I saw random negations of the signal, flipping its sign a few times per second, not correlated with the input signal.
• I tried looking at the signal both with ADLAR set and without, and ADLAR seemed to be just doing a left-shift of 6 bits, as the documentation claims—the problems are in the alignment of the ADC output before shifting.

I read the documentation for the 32U4 differential ADC several times, and finally concluded that the chip I had was not behaving at all according to the specs (which themselves had several typos—Atmel writes some of the worst-checked documentation I’ve seen from a major manufacturer).

It is possible that the chip I have has been subtly fried (though the single-ended ADC seems to work fine), but I can’t find much evidence on the web that anyone uses the 32U4 with the differential inputs, particularly not with the output left-aligned.  If anyone has a Leonardo Arduino board (or other ATMega32U4-based board), I’d be interested in hearing whether you can get the differential ADC inputs on the board to work properly.  If you do get differential inputs to work properly, please send me some information about how you did it, because I’m frustrated.  Perhaps I’m missing some crucial tidbit of information that would make everything make sense.

In the meantime, I’m regarding the differential ADC channels of the 32U4 as an unimplemented marketing lie, and not going to try to use them in PteroDAQ (which wastes a couple of days work on refactoring the code to make it easier to handle boards with different gain on different differential channels).  At least the code still works with the KL25Z differential channels, which seem more limited than the 32U4 ones (only 2 pairs and both have gain of 0.5), but which actually work as documented.

Plumbing karma

A couple of days ago in Is coding for everyone?, I wrote

Atwood makes an analogy to everyone learning to do plumbing, as if that were a ridiculous idea.  Personally, I think that everyone should learn a little plumbing: enough to clear a toilet or sink trap, or replace a faucet washer, and to know when to call in a professional plumber.

So, naturally, yesterday the kitchen faucet started dripping for the first time in about 15 years.  I figured I knew how to change a faucet washer, and that it would just take a few minutes today. Ha!

The first problem was that the faucet had not been opened up in so long that the threads had seized, so it took two people to get it apart: one under the sink holding onto the valve body with channel-lock pliers, the other using a lot of leverage with an 8″ adjustable wrench.  Even that wasn’t enough, so I had to go down to the hardware store for some penetrating oil and let it soak in for a while.

The Grohe faucet cartridge from the kitchen faucet.

Eventually, the threads eased up and the the faucet came apart.  But there was no washer to replace.  Instead what I had was a Grohe washerless faucet cartridge.  The Grohe cartridges are pretty good (which is why I hadn’t had to do anything with the kitchen faucet in so long), but when they fail, there’s not much you can do but replace the cartridge.

I tried smearing everything with vaseline and replacing the cartridge, just in case the problem was with the rubber gaskets, but the drip continued as before.

Unfortunately, the local hardware store does not carry Grohe parts (too upscale for Ace Hardware), so I had to bicycle 3.7 miles across town to Bay Plumbing, the closest place I could find that stocked the part.  I was pleased that their prices were essentially the same as I would have paid online (cheaper than some of the online places), and I could get the part immediately, rather than waiting 3–5 business days for delivery.

I was not so pleased that Bay Plumbing had no bike parking, so I told them about the Santa Cruz County Regional Transportation Commission bike parking program.   Unfortunately, I found out when I got home that SCCRTC no longer has the Bike Secure parking program.  That’s a shame, because there are still a lot of businesses that need bike parking!

In other news, the Arduino Leonardo that I had ordered arrived today. I ordered the Leonardo to test whether the data logger code worked with the Leonardo’s different way of handling the serial interface and different pin mapping.  But I goofed—despite my admonitions to the students in the circuits class to make sure that they got the right USB cable to go with the Arduino board they bought, I had not checked to see if we had a micro-B USB cable in the house.  We had so many USB cables sitting around, that I was sure one of them was a micro-B.  It turns out that they were all either B or mini-B, not micro B, so we were unable to test the data logger code on the Leonardo until I got a new cable.  (Actually, we had one micro-B cable, but it was a power-only cable for recharging my son’s bicycle headlight.)

I ordered a couple of the cables online earlier in the day, but they won’t come until next week, so after buying the faucet cartridge at Bay Plumbing, I stopped in next door at Santa Cruz Electronics to pick up a cable. Unlike Bay Plumbing, their prices were about three times what the online price would have been, so the only reason to buy there was to get the cable immediately. I’ll report on the status of the data logger software later, when I get an update from my son on the code he’s been adding today and when we’ve had a chance to test the Leonardo.