Teensy 3.1 + OpenLog
- Thread starter Mike108
- Start date
- Status
Constantin
Well-known member
unless the timing of the reads has to be very precise, you may not need the open log at all. That's because the teensy can talk directly to SD cards with one of many breakout boards. It's a less costly solution and some breakout boards mount directly to the teensy pins ( Paul sells one IIRC)
However, if the timing interval has to be very precise, then perhaps a two-MCU solution might make sense. In that case you can run wires from one of the serial interfaces on the teensy to the open logger serial and start logging. Both devices run at 3v IIRC so you won't need a voltage translator rig. They also need to share a GND and the Teensy can supply the open logger 3.3V to run.
However, if the timing interval has to be very precise, then perhaps a two-MCU solution might make sense. In that case you can run wires from one of the serial interfaces on the teensy to the open logger serial and start logging. Both devices run at 3v IIRC so you won't need a voltage translator rig. They also need to share a GND and the Teensy can supply the open logger 3.3V to run.
Last edited:
Constantin,
Thanks man. I am new to this wonderful field. Your response helped me to better understand, In fact I just purchase several teensy3.1 and the SD cards on PJRC, great design by Paul. I also learned I need to use #include <SPI.h> and #include <SD.h> in my sketch per: http://www.arduino.cc/en/Tutorial/Datalogger
- However I was wondering how to choose another set of SPI on teensy3.1, and not pins 10, 11, 12 and 13? is that possible?
- What would be the fastest baud rate teensy3.1 can talk to SD card?
- 2 ms sampling time for 4 analog inputs also includes the entire cycle of storing data on Micro SD card, I be happy if the 2 ms is withing +/- 5% timing error. is that within the accurcy range one would expect?
- will such setup also allow parallel communication with pc via USB? Although during the application, pc connection is not needed.
Thanks
Thanks man. I am new to this wonderful field. Your response helped me to better understand, In fact I just purchase several teensy3.1 and the SD cards on PJRC, great design by Paul. I also learned I need to use #include <SPI.h> and #include <SD.h> in my sketch per: http://www.arduino.cc/en/Tutorial/Datalogger
- However I was wondering how to choose another set of SPI on teensy3.1, and not pins 10, 11, 12 and 13? is that possible?
- What would be the fastest baud rate teensy3.1 can talk to SD card?
- 2 ms sampling time for 4 analog inputs also includes the entire cycle of storing data on Micro SD card, I be happy if the 2 ms is withing +/- 5% timing error. is that within the accurcy range one would expect?
- will such setup also allow parallel communication with pc via USB? Although during the application, pc connection is not needed.
Thanks
Constantin
Well-known member
AFAIK, you can make limited switches re: SPI pins. But I have never attempted to do so - too much pain for too little gain IMO.
FWIW, I would look at SDFat as a means of storing data on a SD card. Bill Greimans SDFat library has some very good examples of fast logging to SD Card.
Whether or not you can get 500 samples/s out of four channels will likely depend on a couple of things, i.e. what resolution are you looking for, how often does the stuff have to get written to disk, and so on. On the Teensy 3.1, you can make use of two ADCs and you should be able to get at least 2ksps out of them each, even at 13 bits of resolution. However, choose your pin assignments carefully to make that happen (i.e. two channels each) and in an ideal world discover that you can differentially sample data.
In my data logger application, I compress the data into second-by-second data and then store locally until a master CPU calls for the stuff. Then the local MCU squirts the bird and goes back to work with a minimum of disruption (using a Teensy LC for the measurements, 3.1 as a master). One reason I'm using this two-step process is that very consistent timing is important in my application (I'm measuring power and the phase lag between current and voltage measurements has an impact on accuracy).
The Teensy can still talk serially via USB with your PC. However, as with any input/ output, etc. I'd limit myself because you don't want to prevent your MCU from hitting its potential re: measurements in the name of spitting it all out to your serial console.
FWIW, I would look at SDFat as a means of storing data on a SD card. Bill Greimans SDFat library has some very good examples of fast logging to SD Card.
Whether or not you can get 500 samples/s out of four channels will likely depend on a couple of things, i.e. what resolution are you looking for, how often does the stuff have to get written to disk, and so on. On the Teensy 3.1, you can make use of two ADCs and you should be able to get at least 2ksps out of them each, even at 13 bits of resolution. However, choose your pin assignments carefully to make that happen (i.e. two channels each) and in an ideal world discover that you can differentially sample data.
In my data logger application, I compress the data into second-by-second data and then store locally until a master CPU calls for the stuff. Then the local MCU squirts the bird and goes back to work with a minimum of disruption (using a Teensy LC for the measurements, 3.1 as a master). One reason I'm using this two-step process is that very consistent timing is important in my application (I'm measuring power and the phase lag between current and voltage measurements has an impact on accuracy).
The Teensy can still talk serially via USB with your PC. However, as with any input/ output, etc. I'd limit myself because you don't want to prevent your MCU from hitting its potential re: measurements in the name of spitting it all out to your serial console.
You should be able to do this w/o too much problem.
I've used an interrupt to do 50k samples/second from multiple A/D pins and write to the sdcard in the main loop.
The tricky part is the interrupts and the SPI for the sd writing (not sure if I ever got that right). Paul has added the SPI Transactions to the sdcard reading, but has not done the writing ability yet.
It also might be useful to know that the sd writing is much better if you can pre-allocate a file, and you write only in 512 byte chunks. Another thing you can do is write the values in binary, rather than text files. And lastly, you can create multiple buffers to store the A/D values, and write them as they fill. Every once in awhile an sd write takes longer than usual, and having multiple buffers will allow it to finish before losing any A/D values. But at 500Hz, I don't think you'll need to do most of these optimizations.
I've used an interrupt to do 50k samples/second from multiple A/D pins and write to the sdcard in the main loop.
The tricky part is the interrupts and the SPI for the sd writing (not sure if I ever got that right). Paul has added the SPI Transactions to the sdcard reading, but has not done the writing ability yet.
It also might be useful to know that the sd writing is much better if you can pre-allocate a file, and you write only in 512 byte chunks. Another thing you can do is write the values in binary, rather than text files. And lastly, you can create multiple buffers to store the A/D values, and write them as they fill. Every once in awhile an sd write takes longer than usual, and having multiple buffers will allow it to finish before losing any A/D values. But at 500Hz, I don't think you'll need to do most of these optimizations.
PaulStoffregen
Well-known member
The Recorder example in the audio library is able to continuously write 44100 samples per second to the SD card. It uses DMA and interrupts and buffering in the library, so more data can keep arriving while the SD card is busy writing.
That's probably overkill for only 500 Hz data rate, but still, it shows what can be done if more advanced techniques are used.
That's probably overkill for only 500 Hz data rate, but still, it shows what can be done if more advanced techniques are used.
PaulStoffregen
Well-known member
If you try the recorder example, look for the commented lines that print the wait time imposed by the SD card and SD library. That should give you a pretty good feeling for how this works.
Maybe you could adapt the Recorder example to suit your needs? At the very least, you could try it as is and test with audio signals, as a starting point for your project.
Maybe you could adapt the Recorder example to suit your needs? At the very least, you could try it as is and test with audio signals, as a starting point for your project.
That's a good idea. If I can figure it out, I'm willing to try and add the ability to easily add multiple A/D pins with multiple sample rates to it. This is what I had done before using IntervalTimer.
- Status