[posted] USB DAQ with the Teensy

D

DrM

Well-known member
Working with a senior instrumentation specialist, we have implemented a USB DAQ module using the Teensy 3.2, with analog circuits designed around the electrical characteristics of the Teensy ADCs and DAC. There is also a precision current amplifier that we designed to pair with the board, and the system with software, provides measurement into the pA and pF ranges. The control software is written in Python and provides a GUI and CLI.

I have been using the system to characterize OLEDS and measure detailed electrical effects of surface contamination. In these studies I routinely clock the two ADCs and DAC together, at 200 kHz without data loss.

If anyone is interested, please let me know. I am planning to make some extra copies of the boards.
 

Attachments

  • IMG_7161.small.JPG
    IMG_7161.small.JPG
    217.7 KB · Views: 680
Last edited:
I want to add that the noise performance for the Teensy DAQ board is better than 0.1 mV.
 
I think it'd be really interesting to see more details, especially on the control software, even just screenshots and a little info about what it does with the data.

We get questions about doing this sort of project pretty regularly. Sometimes the questions are about pushing the USB limits. I believe quite a few people would be really interested to know more about how you did this, if you're willing to share.
 
I am indeed willing to share. This is a screen shot of the python GUI that we use for testing our solid state lighting devices. You'll notice that it is pretty quiet, even though I just now ran it with the unshielded board sitting on my desk with open inputs except for the wire patching the DAC output to the input labeled Voltage.

Screenshot from 2018-10-07 18-42-02.png

The data is output as floating point or binary values to a column formatted ASCII file.

The gui runs alongside a console CLI, so that you can enter commands or click buttons and see the interaction between the program and the Teensy DAQ. There is also a stand-alone CLI program.

There is a help command that lists and briefly explains the complete command set for the firmware along with commands recognized in the CLI.

The CLI (no graphic) and the GUI programs, can take commands from stdin and write to stdout, and provide syntax to string commands together, sleep, wait, and pipe or tee to a file. I have automated a lot of my data acquisition procedures using bash to feed commands into the CLI or GUI.

Some of the important DAQ features include
  • a ramp control for the DAC output (this is very impprtant when the test article is capacitive).
  • scanning the DAC while reading the analog inputs
  • generate a tone and save the analog inputs
  • scanning frequency with the tone finction
  • stream data
  • single read and write for analog input and output
  • set and read digital i/o pins

Here is the Analog input control dialogue. Notice that it has settings for labels, scale, and differential or single ended input (this is controlled by a digital i/o pin). The number of channels is set in CLI or cfg file. There are four input circuits on the TDAQ board, and I have external boards that add more channels,

Screenshot from 2018-10-07 19-15-15.png

And here is the Analog/DAC output control dialogue. Notice that it has settings for rate and an external gain. The output OP-AMP provides up to 40 mA, and when needed, I also have an external power OP-AMP that works as a fast, voltage controlled power supply or amplifier.

Screenshot from 2018-10-07 19-14-51.png
 
Last edited:
Here is a capacitance measurement, it was made by measuring amplitudes as a function of frequency. The parallel resistance refers to leakage current.

In addition to the conventiional DAQ functions (read voltage, set voltage, set/read pin, etc) the firmware also has tone and frequency sweep functions that can use the two ADC's together.

In this instance, the frequency sweep was run at a clock rate of 200 kS/s per ADC, at 16 bits, and with a command switch that causes it to return an amplitude for each of the two channels at each tone frequency. The firmware uses a Goertzel to extract amplitude and phase.

C10PF.png

And here is a measurement for a solid state lighting device that we are studying. It has a large capacitance and more leakage current.

MN-0115-3B.png
 
USB DAQ with Teensy - Noise measurements

Here are signal and noise measurement for the four inputs in 16 bit mode, with the first three channels unconnected, and the output from the DAC set at 1.0 V and connected to Ain3. Notice that the bare inputs have noise below 0.1 mV and the DAC output has noise below 1mV.

ChanAvgStdev
Ain03.26E-065.6E-E05
Ain16.8E-067.1E-05
Ain29.3E-068.0E-05
Ain31.00.00067
 
Very interesting, thanks for this thread

DrM said:
I am indeed willing to share.
Click to expand...
OK that snip is out of context, we can talk off-forum about your board etc.

This is very interesting. I am interested in the board you developed; would need to know more before deciding if it would work in this application or not. I just sent you a private email.

The Python GUI looks interesting too... I guess that's running on a PC connected to Teensy? Or something smaller like RPi? On your board I can't make out a uSD card? How do you store acquired data?

I went ahead and purchased a USD$180 Dataq 1120 USB data logger since it has four true differential inputs which can handle 120V RMS without damage, programmable gain, etc. My intent is to try controlling it with Teensy 3.6 since it has the USB host and the uSD for local logging (in CSV form for easy import and analysis). As well as local we want to push out to Google or AWS cloud. This has to work unattended for at least weeks at a time.

I'm planning to open source my code, assuming I get something working soon. At the moment I am wrapped around the axle ordering parts and scheduling production for the next run of Teensy-powered environmental control systems...
 
A few weeks should be easy. Assuming careful design, the limits are usually storage, cooling and power.
 
DrM said:
A few weeks should be easy. Assuming careful design, the limits are usually storage, cooling and power.
Click to expand...
Agreed, for an embedded system. We design and have systems working around the world for years unattended. That's what embedded control does.
[RANT]But in this case a Windows PC is assumed by vendors (Dataq, Digilent, PicoScope) to be the controlling and logging device. I've set up a test system and it will not run for more than a few days without failing, using the Digilent Waveform software connected to their $300 + accessories Analog Discovery 2 hardware, running under Windows 10 Pro or Ubuntu 18.04 on two different PC hardware platforms! Part of the problem is the USB connection fails (usually a timeout) and their code can't recover. Another problem is holding off all Windows updates and disk scans may be only partly possible... plus Windows is not intended to run unattended for even days without rebooting. It's really frustrating. I have support tickets open with Digilent and other vendors. We are also using a $1500 PicoScope 3425 but their Linux SW (not open source, so we can't even fix it ourselves) has critical missing pieces (only once we purchased the scope and were able to run the SW, we discovered the missing parts include the logging to local storage piece!) so we will be forced to use Windows with it... or do a Teensy or Rpi based interface to it also. So what I thought would be a simple job has turned into a tar pit.[/RANT]
In this case we have plenty of power (120V mains with battery backup) and storage (local PC disk or onboard uSD card), with tethered cell phone data link to Google Cloud.
 
The GUI is written in Python, and I have run it on Linux, Windows 10, and Windows 7, and desktops and laptops for each. I have not seen any crashes.
 
Last edited:
DAQ vendors in general are miserable sources of DAQ software, and very few are conscientious even about their hardware.

That in part, is why I built this. I needed a system with strong performance metrics that I can trust, I needed to be able to program the internals directly to provide features that are import for my data acquisition application, and I wanted to provide an API that is easy integrate with host software and platform.
 
Last edited:
Very nice, from experience you will have noise issues with the ADC's if you try to run SPI while sampling the ADC's which makes logging or running small screens a pita. What I ended up doing was using an external spi adc with isolation between the Teensy and the SPI ADC. With careful routing it's possible to skip the isolation but that requires far more attention to detail and experience than most of us DIYers have.

You can read up on some of my trials here. Which reminds me I need to work less and finish my projects....
 
In fact, the noise that I reported for our design in #6 above (0.05 mv to 0.08 mv), does not change when I run other interfaces at the same time. It stays in the 10^-5V range.

In the picture in #1 above, you see that this is a surface mount board. I'll expand on that a little bit to note that we spent about three months on the design, including optimal component selections, detailed circuit analysis and optimal board design. The low noise figure did not just happen, we worked for it.

@Donziboy2 Compare this to the circuit shown in your link; a collection of loose jumper wires, solderless breadboards and budget circuit pieces. it would be a big surprise if you did not see pick-up when you run the SPI. The assertions you make based on your breadboard experience, are simply not accurate of a professionally designed SMT board. We do not see pick-up of that sort whatsoever.
 
Last edited:
Quick question - Were extra boards made & sold somewhere? Or still planning to be sold?

Was supporting Python GUI software published, so still planning to be published?

Usually when a project is going to be sold or crowdfunded, we try to wait and then post it on the website when you're ready to accept orders or backers.
 
Hi Paul, I have one extra board. I am probably going to use it in the lab. Can we talk off-line?
 
I am happy to publish the python gui, and probably the firmware that runs the board as well. The intent is that it be a flexible instrumentation grade DAQ interface and still be very affordable. Everything on the market falls short of that.
 
Oh, I'm not personally looking for this board, but if you're selling them online, I'd certainly like to help you get the word to people who might want them!
 
Sounds like you've made a really useful product here. I totally understand how much extra work it is to sell & support something as a commercial product.

If you're not going to sell these, but willing to share the info, it'd be really awesome if other people could build & use it. :)
 
And yes, of course, I did plan to produce and sell the board, and would be happy to do it if there is interest. I think there a lot of researchers in science and engineering who would benefit.
 
It takes me about four hours to build one by hand, with tweezers and a magnifier, and then a few minutes in a small reflow oven. Having the pcb service that I regularly use, do the assembly for a small run of 4-5 boards might cost less than $1K all included. There is still some time on my end for preparing files and BOM etc, But, it seems well worth it, we just need a few people who want boards.
 
Great, thank you. I see two replies already, the first might be talking about a pci/pcie board from general standards, they usually go for 5-8 K$.
 
Hi Paul, the twitter response seems promising. I plan to ask for a quote today for a small production run. Will let you know how it comes out.
 
I meant to reply here a while ago, but I got busy. But this is pretty awesome. Something I/We would really find useful. Currently, we use https://www.mccdaq.com/ DAQs but the software support on Linux is inexistent and it's really hard to debug stuff since the hardware is closed source.
 
You must log in or register to reply here.
Back
Top