"high speed" data logging

[bill.french]

Using a Teensy 3.1, and Teensyduino, i'd like to log readings to a computer, from two ADCs, as fast as possible, so i can do some offline analysis.

Seems from here: https://www.pjrc.com/teensy/td_serial.html

.. Teensy "always" writes to the usb at 12Mb, which should be plenty fast.

If there's some obvious way i should be doing this, please let me know!

On Teensy, baud rate is ignored on Serial.begin -- would it be similar on the PC side? I was going to try and use Processing, similar to this: https://learn.sparkfun.com/tutorials/connecting-arduino-to-processing ... would the speed setting just be ignored, on the PC side, too?

It feels unintuitive to me, but maybe the magic of usb takes care of it?

 

[JBeale]

The USB connection is only a "virtual" serial port, so it runs at the USB data rate. However raw bitrate != useful data transfer rate, especially if data is sent in short packets instead of larger groups. If there is a question, it is easy enough to make a test program and find out the real value.

 

[PaulStoffregen]

would the speed setting just be ignored, on the PC side, too?

Correct, the baud rate setting is ignored.

You can easily prove this to yourself with any sketch that uses Serial.print(). Just open the Arduino Serial Monitor, and try setting different baud rates. You'll see they all work.

It feels unintuitive to me, but maybe the magic of usb takes care of it?

Yes, indeed, it's USB magic. If you really want to learn how USB protocols work, you certain can, but it's incredibly complex.

You should know, however, are the USB magic also gives you built-in flow control. It's like having hardware serial with hardware handshaking (CTS/RTS) turned on. You can't turn it off. If your program on the PC side doesn't read as quickly as Teensy tries to send, the Serial.print() on the Teensy side will automatically start taking extra time to compensate.

You might think a 64 bit, multi-GHz, multi-core processor with gigabytes of RAM would not be the limiting factor when talking to a 96 MHz microcontroller, but often it can be. Especially if you draw to a GUI on Windows or Mac (which lack async graphics like X11 on Linux), the PC speed can set the overall speed limit due to the hardware handshaking.

USB bandwidth is shared, in surprisingly inefficient ways if you're not using multi-TT hubs. Most PCs can achieve about 1.0 to 1.1 MByte/sec throughput when only lightweight devices like keyboard and mouse are active. But you'll get less bandwidth when things like USB drives and webcams are in use.

 

[PaulStoffregen]

Actually, to be technically correct, the baud rate setting isn't totally ignored. You can use Serial.baud() to read the baud rate setting which the PC requested.

Normally there's no need for this, but it can be really handy when you wish to retransmit the PC's data on a real serial port, where you want the PC to be able to control that port's baud rate.

 

[CyborgEars]

Side remark: when benchmarking "virtual serial" connections, the host-side software (realterm, screen, minicom ..) mostly isn't able to handle multi-megabaud-rates, or doesn't use the necessary settings.
A good starting point for performance is the "Transmit Bandwidth Benchmark" code made by Paul.

 

[jonr]

.. Teensy "always" writes to the usb at 12Mb, which should be plenty fast.

Figure that 2 teensy ADCs running at max speed and resolution need about 10Mbps - which I believe is just beyond the theoretical limit of 12 Mb USB.

 

[PaulStoffregen]

The maximum possible USB speed is approx 1100 kbytes/sec.

Even though the raw bit rate is 12 Mbit/sec, there's considerable protocol overhead. Most of the overhead is fixed, like packet headers, turn-around times, framing packets, etc. With only the fixed protocol overhead, the theoretical maximum speed is 1216 bytes/sec.

Some of the overhead is data dependent, called "bit stuffing", where sequences of 6 consecutive bits all 0 or all 1 require an extra bit inserted. Bit stuffing stuffing means you'll get slightly less, and the specific speed can vary somewhat depending on your data. Sending all zeros or all 0xFF is the slowest, if you want to test for the worst case.

 

[bill.french]

Thanks for all the info! Is there some other practical way to do this? SD Cards seem like a logical choice, but they also seem complex to get higher speeds?