OpenLog keeps creating new files when powered with Teensy by battery

Status
Not open for further replies.

armendzh

Member
I am trying to use OpenLog for one project with Teensy 3.1. I am using several functions from this example below to reset openlog (via pin 6 set of resetOpenLog).
OpenLog_ReadExample: https://github.com/sparkfun/OpenLog...s/OpenLog_ReadExample/OpenLog_ReadExample.ino

When I have my teensy with OpenLog connected to PC via usb, OpenLog creates only one file and writes everything there, just the way I want it to do. When I keep it on battery power, I get like 10-20 files after few minutes. So I am guessing openlog somehow keeps resetting itself. I also think its not the power issue, since if I am not using those functions for resetting openlog, OpenLog writes file to new single file after I insert SD-Card after it is in the part of the program for doing data recording. It would have worked for me, but I would like to have sd-card in OpenLog, and then once my teensy is powered on and ready to use, I could start data recording with command instead of manually triggering it by insert of SD-card.

Is it the reset pin that I picked that can be a problem? (pin 6)

Does anyone knows what could be my problem with OpenLog?
 
You need to post the complete code you're using and how you have everything connected for anybody to really help you.

Also, I happen to be somewhat familiar with openlog, but most people on this board probably are not, it would be a good idea to at least post a link to what an "openlog" is.
 
As noted more information would be helpful, but a quick check might be to double check your battery system. SD card writing is power intensive so not impossible that the Teensy browns out trying to write then comes up and starts trying to write another file.If you have a scope watching the 3.3V line may be informative.
 
That would be my guess too.

SD cards should IMO always feature a dedicated power supply. The 3.2 Teensy can likely handle it from an output point of view but I don't see the point of having to deal with potential software / hardware glitches when a TLV or similar VR is less than a buck.

I also fit the SD card power rail with a 0.1uF decoupling capacitor and a 10uF local storage capacitor. One way to test the brownout hypothesis is to fit a cap or two on the power rail and see if that fixes the problem.
 
Last edited:
The folks who are replying should know that an openlog is this:

https://www.sparkfun.com/products/9530

It's basically an Arduino uno chip with uno programing but it is dedicated to reading serial input and writing to an sd card. It has more advanced functionality but in it's simplest form it just writes anything you send it via serial to an SD card.

So it does have it's own power supply, or at least it has it's own voltage regulator, there's no way we can know how the OP has things connected, hopefully not powering the openlog from the teensy's 3.3volt power supply, although even if that's the case it is apparently working when the Teensy is powered via USB

All the more reason why more details are needed

Powering the openlog means you are not only powering the SD card but also a complete atmega 328. It has it's own 3v3 voltage regulator but if you're trying to power it with anything near 3.3 volts dropout is very probable.
 
I know what an openlog is... but presumed that the OP was using the software with a Teensy vs. the hardware/software combination (the latter would suggest asking Sparkfun what's going on, not this forum).

Anyhow, if it's the full monty (i.e. hardware and software combination) then VIN on the Teensy should be attached to RAW for the OpenLog VR to work as intended.

Also, keep in mind that the MCU on OpenLog is not running to spec, i.e. the 328P was not meant to run at 16MHz on a 3.3V power supply. It may do so, apparently works for most folk, but its not to spec.
 
I also think its not the power issue, since if I am not using those functions for resetting openlog, OpenLog writes file to new single file after I insert SD-Card after it is in the part of the program for doing data recording. It would have worked for me, but I would like to have sd-card in OpenLog, and then once my teensy is powered on and ready to use, I could start data recording with command instead of manually triggering it by insert of SD-card.


It's hard to say without really seeing your setup, but after reviewing this thread and the sparkfun link, I would guess that it is a power issue, but perhaps the Teensy is restarting? have you put a specific message into the startup sequence of the teensy code so that it logs a message once and only once at startup? then examine your logs to see if they contain the message, you should be able to isolate if the T3 is restarting or the data logger.

If you want further help I suggest you post the T3 code, or an example which reproduces the problem.

Cheers
 
Step one is to connect the power supply as intended. That is, RAW on the OpenLogger should be attached to the battery directly. Or VIn on the Teensy.

Per spark fun, The allowable Vin range is allegedly 3-12VDC but I'd treat the lower limit with suspicion - i.e. It likely requires a good benchtop power supply to deal with the short intense pulses as the Sd card is written to.

Users have also complained about bad EMI performance, which doesn't surprise me (it's a spark fun product). If the power fix doesn't do the trick, I wonder if running a 0.1 cap from GND to Reset may fix the problem by making it harder for spurious emissions to pull the reset down / up accidentally.
 
Step one is to connect the power supply as intended. That is, RAW on the OpenLogger should be attached to the battery directly. Or VIn on the Teensy.

Per spark fun, The allowable Vin range is allegedly 3-12VDC but I'd treat the lower limit with suspicion - i.e. It likely requires a good benchtop power supply to deal with the short intense pulses as the Sd card is written to.

Users have also complained about bad EMI performance, which doesn't surprise me (it's a spark fun product). If the power fix doesn't do the trick, I wonder if running a 0.1 cap from GND to Reset may fix the problem by making it harder for spurious emissions to pull the reset down / up accidentally.

Thank you. I will give this change a try.

I will update this topic with more of my code in the next reply as well.
On code side.. Is it better to group data before sending it to Serial software interface? For example this is my code which does transfer of recorded data from 9dof stick to OpenLogger

OpenLog.write(0x40);
OpenLog.write((uint8_t *) &timeD, 4);
OpenLog.write((uint8_t *) &(acc[0]),4);
OpenLog.write((uint8_t *) &(acc[1]),4);
OpenLog.write((uint8_t *) &(acc[2]),4)
....... // ~15 more lines

Would it better to group all that data and then send single OpenLog.write(......,..)?

Additionally, I interrupt my main program about 50 time a second, to repeatedly write to OpenLogger.
 
Last edited:
I would do what Constantin is saying.

Are you using software serial? Teensy has 3 hardware serial ports, unless you are already using them for something else why not use hardware serial.

In what way are you interrupting your code to write to openlog? If you are using an actual interrupt, I wouldn't do that.
 
I would do what Constantin is saying.

Are you using software serial? Teensy has 3 hardware serial ports, unless you are already using them for something else why not use hardware serial.

In what way are you interrupting your code to write to openlog? If you are using an actual interrupt, I wouldn't do that.

What Constantin recommended did help. Thanks a lot!
I am able to write more information to SD Card without any problems and it doesn't seem to break files apart.

I am using Hardware Serial1. I have defined OpenLog was Serial1 in my code.

I am sampling my 9dof stick at 100Hz using Time3.attachInterrupt to get sample.
 
Glad it now works. The open logger makes a good proof of concept.

As a next step, I'd consider going direct, i.e. Buy a SDHC card adapter for the teensy either here or on Tindie. Much cheaper than OpenLogger and likely more reliable too.

If the SDHC card interface doesn't have a on board voltage regulator, then I'd preferably choose a Teensy 3.2 to pair with it as the 3.2 has a separate voltage regulator with adequate output capacity (Teensy 3.1 and 3.0 have been reported to work too)
 
Last edited:
Status
Not open for further replies.
Back
Top