PteroDAQ board calibration

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.

board	measurements	voltage reading
KL25Z	33	+0.28±0.01%
Sparkfun Redboard	10	+0.08±0.10%
Duemilanove	11	–0.26±0.15%
Leonardo	10	–1.81±0.13%
Uno	8	+1.68±0.05%%

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.

Second lecture in Spring 2015 electronics

The lecture today started by me redoing the demo that failed on Monday, showing them how to run PteroDAQ and display the results with gnuplot.  Everything worked fine this time. I even showed them the use of two channels, by putting the Bandgap voltage reference (1v) on the second channel, and plotting its variation over time:

The ADC was measuring consistently slightly low (probably because the power supply voltage had drifted a little) from when PteroDAQ measured the bandgap reference to set the calibration).

I showed them how to plot the signal divided by the bandgap signal to correct for such calibration problems.  The plot also gave a good segue to talking about resolution, precision (which I equated with repeatability), and accuracy, because the step size of about 50µV for the ADC is clearly visible (3.3V/2¹⁶), but the signal is not repeatable to 50µV.  The precision is limited to about ±200µV and the inaccuracy can be as much as 700µV.

I then walked them through a gnuplot script for demonstrating sampling:

# frequencies in Hz
sine_freq = 1.100 *1.0
sample_freq= 40. *1.0

sine_wave(t)=sin(2.*pi*sine_freq*t)
sampled(t) = sine_wave( floor(t*sample_freq+0.5)/sample_freq )

set title sprintf("Sine wave of %.2fHz, sampled at %.2fHz", sine_freq, sample_freq)
set xlabel "time [seconds]"
set ylabel "signal"

set samples 5000
set yrange[-1.05:1.05]
set xrange [0:2]
plot sampled(x) notitle, sine_wave(x) lt 3 notitle

which produces a simple example of discrete-time sampling:

Sampling a 1.1Hz signal at 40Hz does a good job of representing the waveform.

I even explained why I used “lt 3” for making a red/blue color distinction rather than a red/green one (around 5–7% of males have some form of red-green color blindness).

I then showed them the effect of changing the sampling rate (by alternating “sample_freq=…” and “replot” commands). I think that this will help them with tomorrow’s lab, in which they use the function generators in the lab to generate sine waves, and look at them with PteroDAQ software on the KL25Z boards.

Speaking of PteroDAQ, one of the students in the class and I figured out what was going wrong on the Mac OS 10.10.1 installations of PteroDAQ. It turns out that the problem was not specific to the OS 10.10.1, or even to Macs, as we observed the same problem of not being able to select a port (because the GUI automatically deselected it) even on a Windows 7 box.  It turned out to be a problem in Python 3.4.3 (the latest release on python.org) not playing nicely with Tkinter.  Rolling back to Python 3.4.0 fixed the problem (with either Tcl/Tk 8.5 or 8.6).  We’ve not yet looked to see whether 3.4.1 or 3.4.2 work correctly.

The rollback to Python 3.4.0 worked on both Mac OS 10.10.1 and on Windows 7.  The only machines we haven’t yet gotten a demonstrably working PteroDAQ installation are Windows 8 machines—the problem there seems to be installing drivers for the USB port.  The Arduino community has encountered the same problem (Windows 8 insisting on digitally signed drivers) and the community figured out how to turn off that insistence. The instructions there (http://forum.arduino.cc/index.php/topic,94651.msg727588.html#msg727588) are rather scary.  A more tutorial presentation is given by SparkFun at https://learn.sparkfun.com/tutorials/disabling-driver-signature-on-windows-8