Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

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

  1. #1
    Junior Member
    Join Date
    Jan 2019
    Posts
    3

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

    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,

  2. #2
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    464
    Read this thread, it discusses an ADC library for Teensy that enables synchronous sampling of both channels:
    https://forum.pjrc.com/threads/25532...ght=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.

  3. #3
    Junior Member
    Join Date
    Jan 2019
    Posts
    3
    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

  4. #4
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    464
    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.

  5. #5
    Junior Member
    Join Date
    Jan 2019
    Posts
    3
    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!

  6. #6
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    464
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •