High speed two channel data/signal logger (to a hard drive?)

Status
Not open for further replies.

Interversus

New member
Hi,

I am about to embark on a project and I came across this forum which looks like a wonderful way to tap into the experience of others who have gone before me. I have very little experience with what I am about to attempt, and any guidance, warning and nudges are very welcome. I've got a teensy 3.2 to play with.

I want to make a 2 channel data logger for two analogue signals. I need to create a system to do this pretty much "as fast as I can". If I can do this at for a ~5 KHz signal it will be useful for me, 1MHz will have nailed it.

The 2 channels are I and Q data, so I need to sample them synchronously (or close enough for me to make a decision on the accuracy of the sample).


Amplitude, I can scale my input for the teensy no problem, I can tolerate some ADC noise as long as I can quantify it. 12 bit sampling should be fine, 16 bits are perfect. 8 bits is a bit low but I'd consider it to gain significant speed.

My first question is to all the people who have constructed high speed ADC routines, memory writing code, USB transmission, SD card streaming etc, and it is; what methods do you use to test the timing of your creations? Do you time stamp code, or do you get the scope out and toggle pins to measure achievable times? Any tips on how to measure and debug time is going to help me.

Question 2:
Anyone got a good plan or tips on how to tackle 2 channel synchronous sampling at high speed. The teensy 3.2 has 2 ADC's? Can they be triggered with the same interrupt, and has anyone got experience with this?

Question 3:
Ideally I would love to sample two channels at 1Msps and store the whole lot continuously to harddrive for hours. How far removed from reality is this dream? If I can get 1% of this speed, it might still be worth me trying, but 0.1% then I'm going to have to think of ways around the bottlenecks.

I've trawled for commercial solutions, but they all stop short at the "hard drive logging" bottle neck. Picoscope say it should be possible if I write the code myself, but I thought I'd try the teensy first as I have control of everything, just not the knowledge of how to estimate what is achievable yet!

thanks in advance for any input to any part of the above,
:)
 
Read this thread, it discusses an ADC library for Teensy that enables synchronous sampling of both channels:
https://forum.pjrc.com/threads/2553...h-support-for-Teensy-3-1?highlight=pevide+adc

For data logging - I don't have any knowledge about writing to a hard drive. Your best bet might be streaming data to a second processor to buffer and write the data to a hard drive, SD, EMMC, whatever. For previous logging projects, I've sent data to BeagleBone Blacks for logging on its EMMC and to other Teensys to log to SD. Using a second processor for logging really simplified the approach since I didn't have to worry about any logging latency impacting my data collection.
 
Thanks for the reply!

I think I might just replicate that two channel sampled generated waveform comparison in the link you sent, but sampling a much faster signal, and try and find out what the limits are.

Logging to another Teensy or cpu, I would never have thought of that. Sounds like a plan. This might suit my application somewhat as I will have some time free on the second processor to do some math and reduce the data for storage. I've a lot more options now.

Got to figure out the fastest way to get the data to a second teensy now :)

cheers


thanks :)
 
If wire lengths between the two Teensys are small, my preference would be I2C with the Teensy reading the ADC's set up as I2C Master. You could transfer up to 101 kBytes/s if you overclock your Teensy 3.2's to 120MHz:
https://github.com/nox771/i2c_t3

Assuming that you are sending 64 bits of data (two 16 bit analog channels, and 32 bits to capture the time from micros), this would take about 80us to transfer. You could pare it down to 24 bits - two 12 bit analog channels, since the last few bits are just noise anyway - which would take just 30us to transfer. I like I2C compared with serial because you receive whole packets without the need to add bits for a header and a checksum; sending and parsing data is very straightforward.

But, if your cable lengths are longer, Teensy does support really high baudrate Serial and hardware flow control.
 
I never knew I2C could be that fast. I see no reason not to have two teensys as close as possible for my application, so this might be the way I go.

Thanks again, I have some good ideas to start with now, and I need to get another Teensy!
 
One final suggestion - if you are going to be doing floating point math on the second Teensy, give the 3.6 a look. It has a hardware FPU and can give you very fast calculations if you remember to use the float version of functions (ie cosf instead of cos) and to use floats for all constants and variables. It also has a built in uSD for logging.
 
Status
Not open for further replies.
Back
Top