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?

In one day my son and I added support for the Teensy 3.1 board to the PteroDAQ data acquisition system that previously supported the Freedom KL25Z board and the ATMega-based Arduino boards.

We ended up using the Teensyduino development system, but really only for the downloading and for the usb-serial library, since the K20 ARM chip on the Teensy 3.1 is quite similar to the KL25 that we originally based things on.

The Teensy 3.1 is a lot easier to install the software on than the Freedom boards, and runs a little faster (72MHz instead of 48MHz), but has essentially the same ADC.  Actually, it has 2 analog-to-digital converters, but most of the pins can only be read by ADC0, so we’ve not set up ADC1 to read anything but the internal 1.2V Vref (which is conveniently provided as an output on the AREF pin).  We had originally planned to use just ADC0, but the code for reading the Vref signal on ADC0 never worked—I suspect an error in the reference manual, since changing to reading Vref with ADC1 worked fine.

The Freedom boards are cheaper, are easier to unplug the USB cables from, can deliver more power at 3.3V, have RGB LED, and have a lot of neat features missing from the Teensy boards, but the Teensy boards can be configured to plug directly into a bread board (if you give up a lot of the connections and just use 26 pins), and have more RAM (so can run for longer at high sampling rates before the buffer overflows).

I’m going to have to rewrite part of my book to talk about the possibility of using the Teensy 3.1, and I’ll have to decide whether the extra $6–$7 is worth the simpler setup for my Applied Electronics lab course. We’d sacrifice being able to get much power from the board (probably only about 100mA instead of 500mA at 3.3V), but that is a relatively minor loss, since we have bench power supplies at every station.

I’m not sure what I’ll recommend in the book for people trying to learn on their own—I’ll probably have to play with the Teensy a bit to see how useful it is.  I have at least one other program that the students have been using in the lab (the frequency detector for turning a relaxation oscillator into a touch sensor) that I’ll have to port to Arduinos and the Teensy 3.1.

For home hobbyists who aren’t planning to dive deep into embedded-system programming, the Teensyduino IDE is a lot friendlier than the MBED.ORG tools (and I hear that the Kinetis SDK has a very, very large learning curve), so it might be a better board despite the lack of peripherals (no accelerometer, RGB LED, or capacitive touch slider).

Yesterday, while I was in the circuits lab, I checked the calibration of the voltage references on the KL25Z boards and the 4 Arduino boards I had with me.

What I did was to measure the power-supply voltage on the board with a good multimeter and make several of the PteroDAQ self-calibrations of the reference voltage (v0.2b1 does a new calibration every time the “pause” button is pressed).

For the KL25Z board, the voltage regulator on the board was well calibrated—I got a reading of 3.3001V with the bench multimeter.  The 33 PteroDAQ calibrations I recorded gave an average reading of 3.3095V with a standard deviation of 400.6µV. That means that the PteroDAQ reported voltages will be about 0.28±0.01% too high (much better than the ±3% specification for the bandgap voltage reference on the chip).   This is probably better than any of the cheap meters I have at home.

For the Arduino boards, the reference is normally the USB 5V power supply, which was not stable enough to do these comparisons with—I couldn’t get a constant reading on the good voltmeters but saw fluctuations of almost 10mV.  I should have had a 9V wall-wart power supply with me, so that I could get a more stable voltage source from the on-board regulators, but lacking that, I used a bench power supply directly connected to the +5V and Gnd pins of the Arduino to force specific voltages around 5V and did the same comparisons as for the KL25Z board.

The greater fluctuation for the Arduino boards is probably due to the lower resolution of the ADC—the 10-bit ADC should have a reading around 225 at 1.1V with a 5V reference, so ±0.15% is only ±1/3 LSB.  The ATMega chips are guaranteed to have ±10% accuracy on the bandgap reference, but that is over the full temperature range, so ±2% seems about right for room temperature.

The USB power-supply is not a constant voltage, and the fluctuation in the USB power-supply voltage (which can be as much as ±10%) is a problem when using the Arduino boards, so powering them off of a wall wart is a good idea when trying to measure signals accurately.

The voltage measurements are as good as with super-cheap handheld voltmeters (which generally have a specification of about ±1%), so the PteroDAQ system is good enough for first electronics courses and hobbyist labs.

For the past couple of years, I’ve been using the PteroDAQ data acquisition system that my son wrote for the KL25Z board (a second-generation system, replacing the earlier Arduino Data Logger he wrote). Over the past week, he has been transferring the project to me, and together we did a lot of debugging and enhancements.

Today, we tested the code on the ancient Windows 7 machines in the circuits lab at UCSC (we only have Mac OS 10 and Linux at home), and decided it was ready for a beta release.

The new code is way better than the old code! Here are a few of the bigger changes:

• We now support all the ATMega-based Arduino boards, while still supporting the KL25Z.  The KL25Z board is a better choice for a new user, since it is cheaper and has a much better analog-to-digital converter than the Arduinos, but there are a lot of Arduinos and Arduino clones already in hobbyist hands, and PteroDAQ now works for them with no new hardware.
• Sampling rates have improved enormously, particularly for the KL25Z and the Leonardo Arduino boards, which have USB serial communication without the bottleneck of a UART, but even the UART-based Arduino boards have a decent throughput of 2600Hz for a single analog channel. Leonardo gets 5370Hz, and the KL25Z is limited by the Python program on the host—7.8kHz on the old Windows machines, almost 10kHz on my old MacBook Pro (buffer overflow in the operating system loses some packets after a million samples), and about 19kHz on my son’s Linux laptop (again starting to lose samples after about 1 million).  That’s not fast enough for high-quality audio, but it would do for speech-quality audio. It’s a lot better than the old v0.1 PteroDAQ, which was much more limited by the host, having trouble getting even 180Hz on the old Windows machines.
  For short stretches, PteroDAQ can run somewhat faster—I can get 15kHz for about 400,000 samples on my MacBook Pro, which is long enough for a lot of lab experiments.
• We’ve removed the need for PySerial. My son reimplemented the USB serial interface (based heavily on the PySerial implementation), so that we could have everything in a single download with no dependencies outside the standard modules that come with Python.  The implementation may still be a bit inefficient (like the PySerial one), and we are considering working on it.
• Sparklines for the different signals now scroll smoothly even at the highest sampling rates, without taking up much of the host processor.
• Most recent data for each channel is shown numerically next to the channel (which is particularly useful when doing single samples).
• Resizing the window now works well, shrinking and stretching in the appropriate places.
• The GUI now reports errors when PteroDAQ can’t keep up with the requested sampling rate, which makes trading off the sampling rate and averaging easier.

The speed limitations are partly in how fast the Python program on the host machine can accept and process the data, and partly in how fast the KL25Z or Arduino board can do the analog-to-digital conversion. The Arduino boards hit the conversion limits before any of the host machines we used ran into Python limitations, but the KL25Z board with 1× averaging can produce data faster than any of our machines can accept it, so there is still work to be done on improving the efficiency of the Python code.

The software now needs a few users to test it out and find out what problems remain. Some things we won’t be able to do anything about—if Python crashes or the operating system messes up the communication link, there isn’t a lot we can do. Some things are not worth our time (like internationalizing the interface—though we do plan to get unicode characters properly handled in the Notes field—getting that to work in both Python2 and Python3 may be a bit tricky).

I encourage any one who has an Arduino or KL25Z board to try out the new system and tell what problems they have (other than the dire lack of documentation, which I will try to work on with my son over the summer). Ideas for new features are welcome also, though probably won’t come soon.

The software was a complete refactoring of the previous code, with much cleaner interfaces between the modules, which should help with maintenance and extension in future.  I have a huge wish list for new features to add to PteroDAQ, but my son needs to get back to work on the new product for Futuristic Lights, and I need get back to work on my book, so I’ll mainly be putting ideas onto the issue tracker, with the intent of getting back to them later.

For the past couple of years, I’ve been using the PteroDAQ data acquisition system that my son wrote for the KL25Z board (a second-generation system, replacing the earlier Arduino Data Logger he wrote).  He has been working on and off on a multi-platform version of PteroDAQ for over a year, and I finally asked him to hand the project over to me to complete, as I want it much more than he does (he’d prefer to spend his time working on new products for his start-up company, Futuristic Lights).

It has been a while since he worked on the code, and it was inadequately documented, so we’ve been spending some time together just digging into the code to figure out the interfaces, which I’ve been adding comments and docstrings to, so that I can debug the code.  Other than the lack of documentation, the code is fairly well written, so figuring out what is going on is not too bad (except in the GUI built using tkinter—like all GUI code, it is a complicated mess, because the APIs for building GUIs are a complicated mess).

The man goal of his multi-platform code was to support Arduino ATMega-based boards and the KL25Z board, while making it relatively easy to add more boards in future.  The Arduino code is compiled and downloaded by the standard Arduino IDE, while the KL25Z board code is compiled and downloaded with the MBED online compiler.  He has set up the software with appropriate #ifdef checks, so that the same code files can be compiled for either architecture.  The knowledge of what features are available on each board and how to request them is stored in one module of the python program that runs on the host computer.  As part of the cleaning up, we’ve been moving some of the code around to make sure that all the board-specific stuff is in that file, with a fairly clean interface.

He believed that he had gotten the new version working on the Arduino boards, but not on the KL25Z board.  It turned out that was almost true—I got the system working with the Leonardo board (which uses USB communication and has a weird way to get reset) almost immediately, but had to do a number of little bug fixes to get it working with other Arduino boards (which use UART protocol and a different way of resetting). It turned out that the system also worked with the KL25Z after those bug fixes, so he was very close to having it ready to turn over to me.

One of the first things I did was to time how fast the boards would run with the new code—the hope was that the cleaner implementation would have less overhead and so support a higher sampling rate.  Initial results on the Arduino boards were good, but quite disappointing on the KL25Z boards, which use a faster processor and so should be able to support much higher speeds.  We tracked the problem down to the very high per-packet overhead of the USB packets in the mbed-provided USBSerial code.  (He had tried writing his own USB stack for bare-metal ARM, but had never gotten it to work, so we were using the mbed code despite its high overhead.)

There was a simple fix for the speed problem: we stopped sending single-character packets and started using the ability of the MBED code (and the Arduino code for the Leonardo) to send multi-character packets.  With this change, we got much better sampling rates (approximate max rate):

It is interesting that the Leonardo (a much slower processor) manages to get a higher data rate than the KL25Z when sending just time stamps.  I think that I can get another factor of 3 or 4 speed on the KL25Z by flushing the packets less often, though, so I’ll try that.

By flushing only when needed, I managed to improve the KL25Z performance to

Things get a bit hard to measure above 10kHz, because the board runs successfully for several hundred thousand samples, then I start losing characters and getting bad packets. The failure mode using my son’s faster Linux box is different: we lose full packets when going too fast—which is what PteroDAQ is supposed to do—and the speed at which the failure starts happening is much higher (maybe 23kHz). In other words, what I’m seeing now are the limitations of the Python program on my old MacBook Pro. It does bother me that the Mac seems to be quietly dropping characters when the Python program can’t clear the USB serial input fast enough.

The KL25Z slows down when doing the 32x hardware averaging, because the analog-to-digital conversion is slow—particularly when doing 32× hardware averaging.  I think that we’ve currently set things up for a 6MHz  ADC clock, with short sampling times, which means that a single-ended 32× 16-bit conversion takes around 134µs and the sampling rate is limited by the conversion times (differential measurements are slower, around 182µs).

There is a problem in the current version of the code, in that interrupts that take longer to service than the interrupt time result in PteroDAQ lying about its sampling rate.  I can fix this on the KL25Z by using a separate timer, but the Arduino boards have rather limited timer resources, and we may just have to live with it on them.  At least I should add an error flag that indicates when the sampling rate is higher than board can handle.

We had a lot of trouble yesterday with using the bandgap reference to set the voltage levels.  It turns out that on the Arduino boards, the bandgap channel is a very high impedance, and it takes many conversion times before the conversion settles to the final value (nominally 1.1V).  Switching channels and then reading the bandgap is nearly useless—the MUX has to be left on the bandgap for a long time before reading the value means anything.  If you read several bandgap values in quick succession, you can see the values decaying gradually from the value of the previously read channel to the 1.1V reference.

The bandgap on the KL25Z is not such a high-impedance source, but there is some strange behavior when reading it with only 1× averaging—some values seem not to occur and the ds.  I recorded several thousand measurements with 1×, 4×, 8×, 16×, and 32× averaging:

The unaveraged (1×) reading seems to be somewhat higher than any of the hardware-averaged ones.

I was curious about how the noise reduced on further averaging, and what the distribution was for each of the averaging levels. I plotted log histograms (using kernel-density estimates of the probability density function: gaussian_kde from the scipy python package) of the PteroDAQ-measured bandgap voltages.  The PteroDAQ is not really calibrated—the voltage reference is read 64 times with 32× averaging and the average of those 64 values taken to be 1V,  but the data sheet says that the  bandgap could be as much as 3% off (that’s better than the 10% error allowed on the ATMega chips).

Without averaging, there is a curious pattern of missing values, which may be even more visible in the rug plot at the bottom than in the log histogram.

The smoothed log-histogram doesn’t show the clumping of values that is more visible in the rug plot.

With eight averages, the distribution begins to look normal, but there is still clumping of values.

With 16 averages, things look pretty good, but mode is a bit offset from the mean still.

Averaging 32 values seems to have gotten an almost normal distribution.

Interestingly, though the range of values reduces with each successive averaging, the standard deviation does not drop as much as I would have expected (namely, that averaging 32 values would reduce the standard deviation to about 18% the standard deviation of a single value). Actually, I knew ahead of time that I wouldn’t see that much reduction, since the data sheet shows the effective number of bits only increasing by 0.75 bits from 4× t0 32×, while an 8-fold increase in independent reads would be an increase in effective number of bits of 1.5 bits.  The problem, of course, is that the hardware averaging is of reads one right after another, in which the noise is pretty highly correlated.

I think that the sweet spot for averaging is the 4× level—almost as clean as 32×, but 8 times faster.  More averaging improves the shape of the distribution a little, but doesn’t reduce the standard deviation by very much.  Of course, if one has a low-frequency signal with high-frequency noise, then heavier averaging might be worthwhile, but it would probably be better to sample faster with the 4× hardware averaging, and use a digital filter to remove the higher frequencies.

The weird distribution of values for the single read is not a property of the bandgap reference, but of the converter.  I made a voltage divider with a couple of resistors to get a voltage that was a fixed ratio of the supply voltage (so should give a constant reading), and saw a similar weird distribution of values:

The distribution of single reads is far from a normal noise distribution, with fat tails on the distribution and clumping of values.

With 32× sampling, the mean is 1.31556 and the standard deviation 5.038E-04, with an excellent fit to a Gaussian distribution.

Last weekend I posted a voltage-versus-current curve for a 1N5817 Schottky diode, to confirm the theoretical formula , where I_S is the saturation current of the diode, using the following setup

and measuring the results with an Arduino Leonardo.  I claimed that the resulting data fits the model well for over six decades (> 120dB):

Fitting over a wide range of currents is more robust than fitting over the narrower range that I can get with just one value for R2.
There is quantization error still on the voltages, but the overlapping current ranges give good data for most of the range. V_T is now 26.1mV and I_S is 0.91µA.
click to embiggen

I was a little dissatisfied at the low end, because of the low resolution of the Arduino analog-to-digital converter (only 10 bits).  This weekend I decided to repeat the measurements, but using a Freedom KL25Z board, which has a 16-bit ADC.  Of course, it doesn’t really get 16 bits of accuracy—the data sheet claims that when you use the hardware averaging of 32 samples in 16-bit differential mode (the most accurate) you get at least 12.8 equivalent bits and typically 14.5 equivalent bits. (For single-ended 16-bit, the effective number of bits is only guaranteed to be 12.2, and the typical is 13.9 bits.)  They claim a ±6.8LSB total unadjusted error.

My son helped me get the bare metal ARM system set up on my laptop, along with ADC and UART routines, so that I could write my own single-purpose data logger for this problem (he’s working on getting the KL25Z board integrated into the Arduino Data Logger, but it isn’t close to being ready yet).  My program used the longest sample times and hardware averaging of 32 samples, to get the most accurate conversions possible from the 16-bit ADC.  The first version of the program used differential inputs for the voltage across the diode (E20-E21), but single-ended readings (E21) for the voltage across the resistor.  I had to reduce the voltage for the test from 5v to 3.3v, because the KL25Z runs on 3.3v, not 5v. I got some rather weird results:

Two runs of measurement with R2=100Ω. The low-current measurements seem to be all noise.
click to embiggen

I could get decent measurement in the low-current range by using a larger resistor, so the problem was not noise in the measurement fixture or problems reading low differential voltages on the diode, but just with the small single-ended read for the current. It is pretty clear to me that the ADC does not work well when the input voltage results in less than about 50 counts.  (Note, that means that at the low end of the voltage range you only have about a 9.4-bit equivalent ADC.)

I modified the circuit to allow differential reading away from 0 for both the voltage across the diode and the voltage across the shunt resistor:

Adding an extra resistor ensured that the lowest voltage did not get too close to ground and I could use differential reads for both voltage (E20-E21) and current (E22-E23)/R2

This gave me a much cleaner reading, with problems only once the differential counts got below about 20:

Differential measurement with R2=100Ω. The low-current measurements have problems when the counts get small, but not nearly as severely as with the single-ended measurements.
click to embiggen

I replaced the 100Ω R2 resistor with a 15.56kΩ resistor (nominally 15kΩ), to extend to lower currents despite the noise in the ADC:

This plot extends the fit down to about 0.1µA, but only by adding an extra term—an offset to the voltage. I thought at first that overshoot to –11mV is an error in the analog-to-digital converter on the KL25Z, as I couldn’t see how my circuit could be back-biasing the diode.
Click to embiggen

I tried using larger resistors, but was unable to get any better data using them—I seem to be limited by the differential voltage measurement of the diode at the low end. I thought I might be able to improve the measurements by adding an instrumentation amp to increase the signal for low voltages.  But first I tried just hooking up a voltmeter, with no ADC or instrumentation amp connections.  When the voltage across R2 (100kΩ) is 0.31mV, the voltage across the diode plus R2 is only 0.05V, so there is -0.26mV across the diode.  The backwards voltage across the diode was not an artifact of the ADC!

I then tried looking at the voltage across the diode with my oscilloscope.  There is about 20mV of AC noise, independent of the DC voltage, until the diode has about 50mV across it (with the 15.5kΩ resistor for R2), by which time the noise has dropped to about 10mV (the Bitscope oscilloscope with the differential probe has a noise floor of about 3mV, if the two leads are connected together, so this is not just oscilloscope noise).  This noise seems to be white noise, not 60Hz hum pickup, so is probably coming from the diode.  This AC noise signal limits how accurately we can measure the DC current, and rectifying the noise could be the source of the mysterious “backwards” bias.

To reduce the noise, I put a 4.7µF ceramic capacitor in parallel with the diode, and redid all the measurements with 100Ω, 15.5kΩ, and 100kΩ resistors for R2.

Modified measurement circuit, adding a bypass capacitor to reduce AC noise on the diode and allow better DC measurement.

Now the signals are very clean down to nanoamp levels. I no longer need to add an offset to the voltage, as it is 0 to within the measurement repeatability. The noise from very small voltage differences for the 100Ω shunt resistor is still a bit of a problem, but that region is well covered by 15.5kΩ data. The curve was fit using just the 15.5kΩ and 100kΩ data, to avoid having to trim out the noise from the 100Ω data.
Click to embiggen

Lessons learned today:

• Higher-resolution ADCs do give smoother curves, with less digitization noise, but they aren’t a panacea for measurement problems. To get most of the resolution, I had to set the ADC to use long sample times and do a lot of averaging. I understand that Freescale Kinetis M series include 24-bit sigma-delta converters for higher precision at much lower speed (24 bits is 7 decimal digits), as well as the high-speed 16-bit successive-approximation converters. Unfortunately, they don’t have a low-cost development board for this series.
• Stay away from the bottom end of the ADC range on the KL25Z.  Scale single-ended inputs to have values at least 50, and differential inputs to have values at least 20.  There may be similar problems at the top end of the range, but I did not test for them.
  I wondered if the problem may be switching from the large value for the voltage across the diode to the small voltage across the shunt resistor that was the problem. I tried putting in a dummy read between the voltage and the current reads, but that didn’t help at all. At first I thought that the low-count readings were good with the large shunt resistors, but this is probably an illusion: errors in the current measurement for small currents aren’t visible on the plot, because the voltage across the diode is not changing, and so large horizontal errors in the plot are not visible there.
• Watch out for AC noise when trying to measure DC parameters.  If there are semiconductor junctions around, the noise may be rectified to produce an unwanted DC signal.
• The differential ADC settings have a range of ±VDDA, not ±VDDA/2. This means that the least-significant bit step size is twice as big for differential inputs as for single-ended inputs. For some reason the Freescale documentation never bothers to express what the differential range is.
• Serial USB connections are a bit flakey—the Arduino serial monitor missed a byte about every 200–300 lines.  I looked for anomalous points on the plot, then commented out the lines that produced them—they were almost all explainable by one character having been missed by the serial monitor; e.g., I commented out “662401069     86      19″ right after “660001069       865     17″,  because the last digit of the voltage (the second field) was missing.  The fields were a timestamp (in 24MHz ticks), voltage across the diode (in ADC units), and voltage across the shunt resistance (in ADC units).  [Actually, this was not a new lesson for me—I've had to do the same on almost all files collected from the Arduino serial monitor.  My son's data logger code is better at not losing data, but it is still worthwhile to check for anomalies.]
• The 3.3v supply from the Freedom board is much cleaner than the 5v USB supply that I get from the Arduino (unless I use an external power supply with the Arduino), but I can only take about 10mA from the 3.3v supply before it begins to droop.  If I want  more than that, I’d better provide my own power supply (or at least my own LDO regulator from the USB 5v supply).

Last weekend I posted a voltage-versus-current curve for a 1N5817 Schottky diode, to confirm the theoretical formula , where I_S is the saturation current of the diode, using the following setup

and measuring the results with an Arduino Leonardo.  I claimed that the resulting data fits the model well for over six decades (> 120dB):

Fitting over a wide range of currents is more robust than fitting over the narrower range that I can get with just one value for R2.
There is quantization error still on the voltages, but the overlapping current ranges give good data for most of the range. V_T is now 26.1mV and I_S is 0.91µA.
click to embiggen

I was a little dissatisfied at the low end, because of the low resolution of the Arduino analog-to-digital converter (only 10 bits).  This weekend I decided to repeat the measurements, but using a Freedom KL25Z board, which has a 16-bit ADC.  Of course, it doesn’t really get 16 bits of accuracy—the data sheet claims that when you use the hardware averaging of 32 samples in 16-bit differential mode (the most accurate) you get at least 12.8 equivalent bits and typically 14.5 equivalent bits. (For single-ended 16-bit, the effective number of bits is only guaranteed to be 12.2, and the typical is 13.9 bits.)  They claim a ±6.8LSB total unadjusted error.

My son helped me get the bare metal ARM system set up on my laptop, along with ADC and UART routines, so that I could write my own single-purpose data logger for this problem (he’s working on getting the KL25Z board integrated into the Arduino Data Logger, but it isn’t close to being ready yet).  My program used the longest sample times and hardware averaging of 32 samples, to get the most accurate conversions possible from the 16-bit ADC.  The first version of the program used differential inputs for the voltage across the diode (E20-E21), but single-ended readings (E21) for the voltage across the resistor.  I had to reduce the voltage for the test from 5v to 3.3v, because the KL25Z runs on 3.3v, not 5v. I got some rather weird results:

Two runs of measurement with R2=100Ω. The low-current measurements seem to be all noise.
click to embiggen

I could get decent measurement in the low-current range by using a larger resistor, so the problem was not noise in the measurement fixture or problems reading low differential voltages on the diode, but just with the small single-ended read for the current. It is pretty clear to me that the ADC does not work well when the input voltage results in less than about 50 counts.  (Note, that means that at the low end of the voltage range you only have about a 9.4-bit equivalent ADC.)

I modified the circuit to allow differential reading away from 0 for both the voltage across the diode and the voltage across the shunt resistor:

Adding an extra resistor ensured that the lowest voltage did not get too close to ground and I could use differential reads for both voltage (E20-E21) and current (E22-E23)/R2

This gave me a much cleaner reading, with problems only once the differential counts got below about 20:

Differential measurement with R2=100Ω. The low-current measurements have problems when the counts get small, but not nearly as severely as with the single-ended measurements.
click to embiggen

I replaced the 100Ω R2 resistor with a 15.56kΩ resistor (nominally 15kΩ), to extend to lower currents despite the noise in the ADC:

This plot extends the fit down to about 0.1µA, but only by adding an extra term—an offset to the voltage. I thought at first that overshoot to –11mV is an error in the analog-to-digital converter on the KL25Z, as I couldn’t see how my circuit could be back-biasing the diode.
Click to embiggen

I tried using larger resistors, but was unable to get any better data using them—I seem to be limited by the differential voltage measurement of the diode at the low end. I thought I might be able to improve the measurements by adding an instrumentation amp to increase the signal for low voltages.  But first I tried just hooking up a voltmeter, with no ADC or instrumentation amp connections.  When the voltage across R2 (100kΩ) is 0.31mV, the voltage across the diode plus R2 is only 0.05V, so there is -0.26mV across the diode.  The backwards voltage across the diode was not an artifact of the ADC!

I then tried looking at the voltage across the diode with my oscilloscope.  There is about 20mV of AC noise, independent of the DC voltage, until the diode has about 50mV across it (with the 15.5kΩ resistor for R2), by which time the noise has dropped to about 10mV (the Bitscope oscilloscope with the differential probe has a noise floor of about 3mV, if the two leads are connected together, so this is not just oscilloscope noise).  This noise seems to be white noise, not 60Hz hum pickup, so is probably coming from the diode.  This AC noise signal limits how accurately we can measure the DC current, and rectifying the noise could be the source of the mysterious “backwards” bias.

To reduce the noise, I put a 4.7µF ceramic capacitor in parallel with the diode, and redid all the measurements with 100Ω, 15.5kΩ, and 100kΩ resistors for R2.

Modified measurement circuit, adding a bypass capacitor to reduce AC noise on the diode and allow better DC measurement.

Now the signals are very clean down to nanoamp levels. I no longer need to add an offset to the voltage, as it is 0 to within the measurement repeatability. The noise from very small voltage differences for the 100Ω shunt resistor is still a bit of a problem, but that region is well covered by 15.5kΩ data. The curve was fit using just the 15.5kΩ and 100kΩ data, to avoid having to trim out the noise from the 100Ω data.
Click to embiggen

Lessons learned today:

• Higher-resolution ADCs do give smoother curves, with less digitization noise, but they aren’t a panacea for measurement problems. To get most of the resolution, I had to set the ADC to use long sample times and do a lot of averaging. I understand that Freescale Kinetis M series include 24-bit sigma-delta converters for higher precision at much lower speed (24 bits is 7 decimal digits), as well as the high-speed 16-bit successive-approximation converters. Unfortunately, they don’t have a low-cost development board for this series.
• Stay away from the bottom end of the ADC range on the KL25Z.  Scale single-ended inputs to have values at least 50, and differential inputs to have values at least 20.  There may be similar problems at the top end of the range, but I did not test for them.
  I wondered if the problem may be switching from the large value for the voltage across the diode to the small voltage across the shunt resistor that was the problem. I tried putting in a dummy read between the voltage and the current reads, but that didn’t help at all. At first I thought that the low-count readings were good with the large shunt resistors, but this is probably an illusion: errors in the current measurement for small currents aren’t visible on the plot, because the voltage across the diode is not changing, and so large horizontal errors in the plot are not visible there.
• Watch out for AC noise when trying to measure DC parameters.  If there are semiconductor junctions around, the noise may be rectified to produce an unwanted DC signal.
• The differential ADC settings have a range of ±VDDA, not ±VDDA/2. This means that the least-significant bit step size is twice as big for differential inputs as for single-ended inputs. For some reason the Freescale documentation never bothers to express what the differential range is.
• Serial USB connections are a bit flakey—the Arduino serial monitor missed a byte about every 200–300 lines.  I looked for anomalous points on the plot, then commented out the lines that produced them—they were almost all explainable by one character having been missed by the serial monitor; e.g., I commented out “662401069     86      19″ right after “660001069       865     17″,  because the last digit of the voltage (the second field) was missing.  The fields were a timestamp (in 24MHz ticks), voltage across the diode (in ADC units), and voltage across the shunt resistance (in ADC units).  [Actually, this was not a new lesson for me—I've had to do the same on almost all files collected from the Arduino serial monitor.  My son's data logger code is better at not losing data, but it is still worthwhile to check for anomalies.]
• The 3.3v supply from the Freedom board is much cleaner than the 5v USB supply that I get from the Arduino (unless I use an external power supply with the Arduino), but I can only take about 10mA from the 3.3v supply before it begins to droop.  If I want  more than that, I’d better provide my own power supply (or at least my own LDO regulator from the USB 5v supply).

Earlier today I posted a voltage-versus-current curve for a 1N5817 Schottky diode, to confirm the theoretical formula , where I_S is the saturation current of the diode:

Fitting over a wide range of currents is more robust than fitting over the narrower range that I can get with just one value for R2.
There is quantization error still on the voltages, but the overlapping current ranges give good data for most of the range. V_T is now 26.1mV and I_S is 0.91µA.

I also said that I should characterize the base-emitter junction of a PNP and an NPN transistor this way also, for setting the appropriate resistances for the log amplifier in the loudness circuit.  I did that this evening for the S9012 PNP and S9013 NPN transistors:

Base-emitter diode for the S9012 PNP transistor (collector and base connected together). V_T is 25.3mV and I_SO is 13.4fA.

Characteristics for the base-emitter diode of the S9013 NPN transistor (collector and base connected together). V_T is 25.5mV and I_SO is 8.85fA.

For both transistors, the region where the logarithmic fit is good is from about 0.5µA to about 50mA (maybe only 35mA for the NPN transistor). That gives about a 100dB working range for a log amplifier, if the largest current corresponds to 50mA. Of course, the op amps that are driving the input of the log amplifier don’t have that much drive capability, and we are probably limited to about 20mA—only a 90dB dynamic range on the log amplifier.

Earlier today I posted a voltage-versus-current curve for a 1N5817 Schottky diode, to confirm the theoretical formula , where I_S is the saturation current of the diode:

Fitting over a wide range of currents is more robust than fitting over the narrower range that I can get with just one value for R2.
There is quantization error still on the voltages, but the overlapping current ranges give good data for most of the range. V_T is now 26.1mV and I_S is 0.91µA.

I also said that I should characterize the base-emitter junction of a PNP and an NPN transistor this way also, for setting the appropriate resistances for the log amplifier in the loudness circuit.  I did that this evening for the S9012 PNP and S9013 NPN transistors:

Base-emitter diode for the S9012 PNP transistor (collector and base connected together). V_T is 25.3mV and I_SO is 13.4fA.

Characteristics for the base-emitter diode of the S9013 NPN transistor (collector and base connected together). V_T is 25.5mV and I_SO is 8.85fA.

For both transistors, the region where the logarithmic fit is good is from about 0.5µA to about 50mA (maybe only 35mA for the NPN transistor). That gives about a 100dB working range for a log amplifier, if the largest current corresponds to 50mA. Of course, the op amps that are driving the input of the log amplifier don’t have that much drive capability, and we are probably limited to about 20mA—only a 90dB dynamic range on the log amplifier.

Yesterday I posted a voltage-versus-current curve for a 1N5817 Schottky diode, to confirm the theoretical formula , where I_S is the saturation current of the diode, but I wasn’t really satisfied with the results, either in terms of dynamic range or the quality of the fit.

The voltage does fit nicely to the log of current, with I_S=1.32µA and V_T=27.1 mV. Given the quantization noise in the voltage measurement, these seem like a pretty good fit to theory. (click to embiggen)

One problem is that the serial variable resistor I used did not all really low currents.  I rewired it today so that I had a potentiometer providing the voltage, rather than a series variable resistor:

I also wrote a little Python program to merge different data files, so that I could combine files in which the resistance of R2 (for measuring the current) differed.

The resulting data fits the model well for over six decades (> 120dB):

Fitting over a wide range of currents is more robust than fitting over the narrower range that I can get with just one value for R2.
There is quantization error still on the voltages, but the overlapping current ranges give good data for most of the range. V_T is now 26.1mV and I_S is 0.91µA.

The measurements at the high-current end had to be redone with an external power supply for the Leonardo Arduino board (not just USB power), as the reference voltage for the A-to-D converter dipped as the load increased. There is a tiny effect still when using an external power supply, but only at the very highest current level, and it is buried in the noise.

At the low-current end, we can see the flattening of the curve from the “1+” term that is often omitted from the model.  The resolution in the voltage is poor there, but the current knee can be fairly accurately set by using a large value for R2.

I should probably characterize the base-emitter junction of a PNP and an NPN transistor this way also, for setting the appropriate resistances for the log amplifier in the loudness circuit.