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

Thread: Teensy 3.2 High Speed data transfer feasibility

  1. #1
    Junior Member
    Join Date
    Apr 2017
    Posts
    3

    Teensy 3.2 High Speed data transfer feasibility

    Hi,

    I am currently working on a small turbine project, where I need to measure the strain on a single rotor blade with a strain gauge via a single analog pin, and give each reading a time stamp for post processing, along with logging a 1/rev signal from a Hall effect sensor on a digital pin.

    The rotor will be rotating up to a rotational speed of 1000 RPM, and I would like to sample the analog pin at 6 kHz if possible so that I can obtain data for every degree of rotor revolution. The tests will be relatively short up to 10/15 seconds.

    Due to the rotor rotation, I cannot have wires trailing from the rotor, and from some research deemed that slip rings were too complicated to develop.

    From this, I think the solution would either need to be an on rotor data logger possibly using an on board micro SD card or a wireless system. I have been looking into using two NRF24L01 modules between two Teensy 3.2 boards, and printing the data to serial so that it can be pasted into a .CSV file. The NRF24L01 modules are stated as having 1Mbps and 2Mbps on-air data-rate

    This is my first real attempt at programming/electronics of this nature so am not sure if any of these approaches is feasible or whether there are better alternatives. I was just wondering if anyone would be able to provide me with some feedback based on their experience with the Teensy 3.2 boards with similar applications or point me in the direction of calulation that I could undertake to verify/ascertain whether or not the sampling frequency of 6 kHz and the data transfer rates required are possible.

    I am not looking to do any processing of the data on the Teensy 3.2; this will be undertaken at a later date.

    Any feedback would be much appreciated

  2. #2
    Senior Member Constantin's Avatar
    Join Date
    Nov 2012
    Location
    In the yard with a 17' Dia. Ferris Wheel
    Posts
    1,408
    A couple of thoughts. For one, I suppose you will have to mount the Teensy at the center of the hub in order to avoid adding a significant amount of strain on the blades, etc. from mass imbalance and so on. Additionally, you will need a battery that will sustain the ~30-100mA current draw of the Teensy as long as your experiment is running. Even if you LiOn, that battery will add mass... so the first thing I'd think about is how to safely mount all that on your hub.

    Next, I doubt that the Teensy ADC will be good enough out of the box to measure a strain gage with the precision you're looking for - you likely will need to use a SPI-based external ADC that is optimized for strain gages. While the Teensy can do a pretty good job of handling differential signals at up to 13 bits and the PGA offers even more amplification, I wonder if dedicated ADC doesn't make more sense. For example, this AMS ADC is built specifically to measure strain gages, can handle up to 10k updates per second, and so on.

    So if it was me, I'd design a daughter-board to sit on the hub with a small LiOn battery pack, a teensy 3.2, and this strain gage ADC, along with a SD card, NRF, or XBee transmitter. I'd lean towards Xbee for ease of implementation but the data rate requirements may or may not get in the way. All depends on how much data you're trying to push through the wireless interface. (~35kbps is the wireless communications limit for the Xbee even if the wired XBEE-MCU connection is at 110kbps). I imagine that the real-life NRF communications limits are similar.

    If that doesn't work, you could follow in my footsteps and dedicate one MCU towards measurements and a second one to writing to SD card. The two-MCU setup is not ideal re: cost but it ensures that no measurements are lost while SD card writes cause occasional latency issues. A serial connection between the Teensy's can operate at up to 6Mbit/s (using serial 1 or 2, with RTS/CTS enabled!).
    Last edited by Constantin; 04-11-2017 at 12:55 AM.

  3. #3
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    Consider a T3.5/3.6. Much higher memory meaning you could buffer several seconds if needed, and a built in SD card that could be used to store data.
    The T3 series also has ADC DMA control so the ADC's could run in the background without interfering with the SD Card and visa versa.

    The OP idea could work, it just depends on how accurate(limited by internal ADC) the data needs to be and the real life abilities of the NRF24L01(go with the + version).

  4. #4
    Senior Member Constantin's Avatar
    Join Date
    Nov 2012
    Location
    In the yard with a 17' Dia. Ferris Wheel
    Posts
    1,408
    A 3.5 or 3.6 would certainly remove some constraints. DMA control of the ADC is not a trivial thing to implement. IIRC, the current ADC library doesn't...

    The best bet may be a 3.5 with onehorse NRF+ module from Tindie (verify it works with a 3.5!) combined with a strain gauge ADC on a daughterboard along with the battery. Depending on your needs, it may make sense to implement a battery charger on said daughterboard as well. They don't take a lot of room and the JST connectors on adafruit cells can be a PIA to clp and unclip (which is good to prevent accidental loss, not so great for repeated battery swapping).

  5. #5
    Junior Member
    Join Date
    Apr 2017
    Posts
    3
    Hi Constantin/Donziboy2,

    Many thanks for your comprehensive replies it is much appreciated. I think the use of a daughter board and battery pack is a neat solution and definitely the way to go. I just had a few other questions based on your replies. I was looking into possibly using an external instrument amplifier to connect to the Teensy board, maybe an INA125P, but I still need to check the spec to see if it is suitable. The force measurement range I require is 0 -70 N tensile load, and reading typical commercial load cell manufacturer data they suggest that a resolution of 1 in 5000 is possible. Using this as an initial estimate this would give me a resolution of 0.014N which is more than adequate for my application, and requires the use of a 13 bit ADC. Would the internal ADC of the Teensy 3.2/3.5 be suitable for this used in conjunction with an amplifier, or would you still recommend an external ADC?

    Having under taken some very quick numbers, I estimate that I will need 128 bits per read, which if I sample at 6 kHz gives approximately 768,000 bits/sec. The 6 kHz is not a hard limit, but it is something that I am aiming for so that I can use the system for the full test envelope.

    Based on this, from my little research on the web, having never used an SD card before, is this level of data transfer possible considering the latency in SD card writes of up to 0.5s (?) without losing data? I would be interested to know how the two teensy boards connected via serial and using an SD card overcame this problem and with the 6 Mb/s serial ability how this then worked whilst writing to the SD card, and could this be overcome via using the Teensy 3.5?

    I know that the data transfer rate is higher than the typical Xbee limit of 35 kbps, but based on this I think it would be worthwhile building a small bench mounted system with an NRF+ module and maybe a Teensy 3.2 or 3.5 to see what data transfer rates I can get. The modules will only be 0.5 m apart for this application. Depending on these results I could then try the SD card as a second option and compare the two.

  6. #6
    Senior Member Constantin's Avatar
    Join Date
    Nov 2012
    Location
    In the yard with a 17' Dia. Ferris Wheel
    Posts
    1,408
    I would start as follows:

    Hook up a Teensy 3.6 via the differential inputs to the strain gage and see to what extent the results match reality. Especially if you can use the built in PGA as an amplifier. If the results are OK, you can skip the need for an instrumentation amplifier. One thing I would do, however, is to power the Teensy off a battery during the measurements. Not only does that better reflect how the teensy will be used, it may also reduce some of the noise that your PC may otherwise inject into the voltage regulator of the Teensy. To do this, cut the VUSB-VIN trace on the underside and power the Teensy from a 3.7Lion cell (see adafruit for chargers and cells).

    If the Teensy-only approach is not sufficient, then you have to ask yourself what tradeoff you would like to make: Build a proper instrumentation amplifier circuit board and benefit from the ease of use / diagnostics of the Teensy ADC vs. dealing with a SPI/I2C specialized setup that is perfect for strain gages but which may be more difficult to use initially (i.e. getting the thing set up, talking to your Teensy, etc.). Neither approach is without pitfalls. For my ADC application, I ended up choosing specialized chips that communicate via SPI with the Teensy. But my case involved a bipolar signal and the instrumentation amplifier to turn said signal into a unipolar one was a PIA to set up.

    You should be able to get 13 bits ENOB out of the differential inputs of the Teensy ADC. There are only two sets of pads for that on the 3.2, there may be more on the 3.5/3.6.
    Given that strain gages are unlikley to ever produce negative voltages, you should be all set re: the unipolar ADC in the Teensy. But it depends on your setup. If there is a bipolar range, then you will likely will need to use an op-amp to produce a unipolar one for use with the Teensy ADC. A small capacitor (0.01uF) may help smooth noise on the teensy ADC inputs, install one for each input from the input to AGND.

    As for communicating all that, I'd prefer using a NRF+ to bridge the data back to your PC vs. another Teensy. The simple reason is that a 2Mbit/s connection should be able to sustain a 760kbit/s data stream, even when accounting for overhead, etc. It's much better to have a CPU with comparatively endless RAM/storage space, etc. deal with storing the data while receiving it vs. another Teensy. My application involves a master Teensy querying other Teensy's over time to allow a small local network to exist. The total data being moved is relatively little but having no latency between expected measurements is important to me.

    So that's where I would start: build a rig to see if the Teensy can communicate quick enough via NRF. Simultaneously, build a rig that uses just the Teensy (if possible) to do all the strain measurements. If a instrumentation amplifier is needed (bipolar signal, noise, etc.) then add one. If that doesn't cut it, investigate the AMS unit I linked to above or an alternative.

    One thing I would consider, however, is to power the NRF separately from from the Teensy/INA/etc. Perhaps even a separate battery. I presume the NRF will produce a lot of power supply noise while it is transmitting. Thus, once you marry the ADC portion of your Teensy setup to the transmitting portion, I would review to see if thee signal quality changes. If so, use a separate battery.

  7. #7
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    Here is a thread that has working code for DMA ADC control. I was out of town for a few weeks and could not do anything with it so im playing catchup with work and my side projects atm. (keep in mind i'm still trying to figure out why the data order is off when reading it back.)

    13bit is reasonable with the Teensy, but if you use DMA you can over sample without impacting anything else.

    SD Card performance is hard to gauge, I have no experience using them on teensy or arduino projects.

    If you don't need SD Card sized storage you can look at this thread on SPI Memory options.
    Last edited by Donziboy2; 04-12-2017 at 02:56 PM.

  8. #8
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Quote Originally Posted by Constantin View Post
    As for communicating all that, I'd prefer using a NRF+ to bridge the data back to your PC vs. another Teensy. The simple reason is that a 2Mbit/s connection should be able to sustain a 760kbit/s data stream, even when accounting for overhead, etc.
    It's not that simple. When using auto-ack for reliable transmission, you can expect at best 500-600kbit/s. Otherwise, up to 1600kbit, but you have to deal with lost packets yourself.

    An SD-card can perform quite well. Teensy 3.5 can easily buffer more than a full second of data. The worst-case I have seen with standard writes is 850ms latency (on very rare occasions). Using contiguous, pre-erased files, worst case was 40ms latency. With the SdFat-beta library, >10MB/s writing is doable.

Posting Permissions

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