Teensy uSD Data Logger Project --> The high performance, battery operated data logger

Status
Not open for further replies.

t3andy

Well-known member
Teensy uSD Data Logger Project --> The high performance, battery operated data logger

Front_Logger.JPG

Teensy uSD Data Logger Project --> The high performance, battery operated data logger!

-------------------------------
Teensy uSD Data Logger Features:
-------------------------------

1. uSD Logger has precision timestamping from a precision TCXO RTC +-5 PPM / 0.43 secs/day or 2.63 min./yr.

2. Uses the Teensy 3 ARM 12/16 bit analogs for precision sensor logging.

3. Uses Adafruit's MicroSD breakout board.

4. Uses a precision TCXO I2C RTC to generate the needed wake-up interrupt repeat alarms from "deep sleep" needed by the uSD logger.

5. uSD Logger is battery powered using a special boost converter to suck every joule of energy from two AA batteries.

6. Uses a Command Line Interface (CLI) and can use on any of the Teensy 3 serial ports. No IDE required.

7. uSD Data Logger "carrier PCB" is extremely small. ~ 1.250" x 1.670" or 31.75 mm x 42.418 mm. (size does not include the Adafruit MicroSD addon)

8. Logger operation is very simple ... Insert uSD flash memory card, ... hook-up an analog or a digital sensor ... install 2 AA batteries and log away.

-----------------------------------------------
Application uses for the Teensy uSD Data Logger
-----------------------------------------------

Environmental sensor logging
Portable lab sensor logging
Security sensor logging
RC plane / rocket data logging
or any project that needs a "teensy", low power, battery operated, high performance, data logger.

-----------------------------
uSD Logger CSV Logging Sample
-----------------------------

Data Logger uSD ReStart ... T3 @ 96 Mhz, I2C @ 400 kHz, SD @ FULL SPEED, CLI @ 115,200 baud
1,1.3079121,VDC A9 Sensor,21:7:53,7-12-2013,DOW=5,Fri,2.7705495,VDC AA Bat.,1734,uSecs. Task Execution
2,0.6664469,VDC A9 Sensor,21:8:0,7-12-2013,DOW=5,Fri,2.2918682,VDC AA Bat.,1905,uSecs. Task Execution
3,0.7752380,VDC A9 Sensor,21:9:0,7-12-2013,DOW=5,Fri,2.1806592,VDC AA Bat.,Low Battery(s) Warning!,1897,uSecs. Task Execution

Note: Task execution uses micros() to compute the execution time of the sample logging code before sleeping. Needed in battery calculations.

--------------------------------------
Sample uSD Logger Battery Calculations
--------------------------------------

Duracell "Coppertop" 1.5 VDC @ 2200 mHh

Alkaline battery new voltage: 1.50 - 1.65 Volts
Alkaline battery voltage under load: 1.10 - 1.30 volts
Alkaline battery discharge voltage: 0.80 - 1.00 volts
< 2.2 VDC of battery voltage is used as the uSD logger low battery(s) warning.

-------------------------------------------------------------------------------------
Repeat sample interval of 60 second and T3 code execution time @ ~2000 usec @ 31.68 ma. @ 96 Mhz. (does not the include uSD peak power surge - Notes 1,2 )

Capacity rating of battery (mAh) [2200] mAh = milli-Amp-hours
Current consumption of device during sleep (mA) [6.5] mA = milli-Amps <-----<<< Present T3 "deep sleep" mode quiescent current.
Current consumption of device during wake (mA) [31.68] mA = milli-Amps (does not the include uSD peak power surge)
Number of wakeups per hour [60] If always on, enter 3600 here.
Duration of wake time (ms) [2] ms = milli-Seconds. If always on, enter 1000 here.

Results: Estimated battery life is 11.99 days, or 0.03 years. <---------------<<<
-------------------------------------------------------------------------------------


Notes:
1. We don't have any expensive test measurement equipment needed to measure the SD card peak power. (In some cases > 100 mA. peak!) T3 idle current @ 96 Mhz is used.
2. AA battery total discharge voltage will not produce 100% current depletion.
3. The booster converter will work down to 1.8 V.
4. All calculations are approximate. For better results, just run the logger, with new batteries, and review the sdFat sample log when the batteries are depleted.


http://oregonembedded.com/batterycalc.htm

----------------------------------------------------------------
Command Line Interface Menu Sample of the Teensy uSD Data Logger
----------------------------------------------------------------

mySerial.println (F("-------------------------------------------"));
mySerial.println (F(" uSD Data Logger Command Line Interface "));
mySerial.println (F("-------------------------------------------"));
mySerial.println (F(" CMD (Case Sensitive) Function "));
mySerial.println (F("[A CR] --> Read Analog A9" ));
mySerial.println (F("[R CR] --> Read Time Date" ));
mySerial.println (F("[S h m s mo d yyyy CR] --> Set Time Date" ));
mySerial.println (F("[E CR] --> Write uSD Test" ));
mySerial.println (F("[F CR] --> Read uSD Test" ));
mySerial.println (F("[I CR] --> uSD Card Info " ));
mySerial.println (F("[B CR] --> uSD Benchmark " ));
mySerial.println (F("[L CR] --> uSD List Files" ));
mySerial.println (F("[K CR] --> Kill Log File" ));
mySerial.println (F("[B CR] --> Prt. Bat. Stats"));
mySerial.println (F("[T CR] --> CR2032 Date TS "));
mySerial.println (F("[a CR] --> 1 sec sample ")); // <----- power hungry
mySerial.println (F("[b CR] --> 1 min sample "));
mySerial.println (F("[c CR] --> 10 min sample "));
mySerial.println (F("[d CR] --> 15 min sample "));
mySerial.println (F("[e CR] --> 30 min sample "));
mySerial.println (F("[f CR] --> 1 hr sample "));
mySerial.println (F("[g CR] --> 1 day sample "));
mySerial.println (F("-------------------------------------------"));
mySerial.println ();
mySerial.print (F("CMD >> "));
 

Attachments

  • Back_Logger.JPG
    Back_Logger.JPG
    106.3 KB · Views: 444
  • Booster_Converter.JPG
    Booster_Converter.JPG
    89.8 KB · Views: 436
  • New_Logger.JPG
    New_Logger.JPG
    82 KB · Views: 361
  • Old_Proto_Logger.JPG
    Old_Proto_Logger.JPG
    161.7 KB · Views: 524
  • Layer 1 top PCB.pdf
    32.2 KB · Views: 281
  • Layer 2 bottom PCB.pdf
    32.8 KB · Views: 238
  • Silkscreen.pdf
    44.5 KB · Views: 300
Last edited:
Update ... On two fresh AA batteries, we were able to log 9160 samples @ 60 samples per hour (once every min) for 7 days.
The calculated duration should have been 12 days. (from above) ??? Not being able to measure the SD peak power caused the calculation to be way off by 5 days.

We are looking at other power sources to increase this sample duration for more than 7 days.
One solution is to use the 5000 mAh "Power Bank" from Seeedstudio.
http://www.seeedstudio.com/depot/power-bank-5000mah-p-1548.html

Stay tuned ...
 
Why not use Teensy 3 RTC?

I have a dumb question... why not use a 5PPM crystal for the RTC as sold here on digikey and a CR3202 battery as a RTC backup? It's cheaper than implementing all the DS3232 business, uses the same board space or less and if you want to make the whole thing a quasi-TXCO, simply invest the time to adjust the trim on the RTC output as a function of temperature (which you are measuring anyway...). This is what I'm planning on doing, even though I do not have a battery-powered application on my hands.

IIRC, at best, the DS3232 will get you into 2PPM territory (and read the datasheet carefully - there are all sorts of caveats re: performance before and after installation). While 5PPM won't win you accuracy awards, it seems more than adequate for battery-operated use on a datalogger that is sampling as slowly as yours is. Alternatively, nothing prevents you from stretching or compacting the time data ever so slightly as a function of the time when the thing left your hands to the time you get it back and comparing it to an accurate reference clock (NTP, GPS, etc.) in post processing (i.e. Excel).

One of my next tasks will be using a PPS signal from a GPS transmitter like the UP501 to trim the Crystal above to perfection followed by testing it at different temperatures and figuring out a map for the trim as suggested on the bottom of page 7 in the DS3232 datasheet. Don't get me wrong, I love the DS3231, which is similar to the DS3232, but the RTC in the Teensy can be more than 'good enough'.
 
Last edited:
I have a dumb question... why not use a 5PPM crystal for the RTC as sold here on digikey and a CR3202 battery as a RTC backup?

Crystals are great but they are very temperature sensitive. They have to be tuned to the "ambient" air in which you are data logging. We used the DS3232 +- 5 PPM TCXO for two reasons. It came in a very small 8 pin SOIC which could be easily soldered along with the battery booster converter on the carrier board. Second, since it is a TCXO RTC then using it in different environments without constantly changing calibration constants is a very big plus. It really comes down to the user specific application.
 
The DS3232 is a great and easy solution for high accuracy.

A really difficult solution might involve using an ordinary crystal, code that occasionally reads the temperature (the chip has a built-in temperature sensor of modest accuract), and the built-in RTC's ability to correct for error. The tough part, aside from just the shear amount of work needed to replicate what the DS3232 already does internally, is probably coming up with a good and reliable mathematical model of the ordinary crystal's temperature dependence. But with that, it ought to be possible to read the temperature every minute (or perhaps every 5 minutes) and tweak the RTC adjust to compensate. To have any decent confidence, it'd probably need to be run for lengthy tests at a variety of temperatures and then carefully compared to an accurate time reference, which adds a whole other level of challenges.

Unless it was going to be mass produced in high volume, I'd just go with the much simpler RTC module that is already known to work reliably.
 
Interesting.... I wonder where that SO-8 DS3232 came from given that the datasheet only mentions a SO-20 version of the chip. A SO-8 version of the chip would be sweet indeed.

My datalogger has a DHT-22 on it, so I can log temperature quite accurately. The datasheet for the crystal also mentions a beta number that one can presumably use to adjust the trim as a function of room temperature. What's interesting for this +/- 5PPM tuning fork-based crystal is that the operating range is given as -20*C to 70*C. Normally, one associates the tolerances given to be broadly representative across the entire allowable temperature range. This in turn suggests that once the RTC has been initially trimmed that indoor use may result in the Teensy RTC achieving excellent accuracy even without using on-CPU or external temperature compensation.

All that said, I'd be happy to see if I can crack the nut with the on-board temperature sensor and then have Paul (if he's interested) incorporate it into the Teensyduino environment. Microchip even has a lookup table that one can use for PIC RTC trimming. I'm likely going to be content with 'just' +/-5 PPM accuracy given that comes out to ~12seconds per month and my data is recorded in minute intervals.
 
Last edited:
"Current consumption of device during sleep (mA) [6.5] mA = milli-Amps <-----<<< Present T3 "deep sleep" mode quiescent current. "

This is about 97 % of the total power consumption of the system. Paul -- is there any supported way in T3 of getting this down to the uA level that the K20 MCU supports ? I expect most of this current is the other bootstrap MCU on the board.
 
Interesting.... I wonder where that SO-8 DS3232 came from given that the datasheet only mentions a SO-20 version of the chip. A SO-8 version of the chip would be sweet indeed.


Check for the special automotive I2C RTC DS3232M (DS3232MZ+ to be exact) :cool:
 
This is about 97 % of the total power consumption of the system. Paul -- is there any supported way in T3 of getting this down to the uA level that the K20 MCU supports ? I expect most of this current is the other bootstrap MCU on the board.

I am also waiting for the day when the Teensy 3 would deep sleep in uA instead of mA. My logger duration would be extended by months. :D
 
is there any supported way in T3 of getting this down to the uA level that the K20 MCU supports ?

I've been working on this (and the Mac bug) for the last few weeks. Those 2 fixes are planned for Teensyduino 1.16.

I will be publishing any news on this thread, so please subscribe to it if you want to hear as soon as possible.
 
OK, so this DS3232MZ+ clock is not quite as accurate as the SO-20 version, but you're good for 5PPM, which is in striking distance of what the crystal allegedly also does.

To each his / her own, but it seems to me that if one has a choice between a $0.76 crystal that takes up zero board space and a $8.74 TXCO (however small), that one should seriously consider the crystal. I've been told (though have no firsthand knowledge) that most electronic watch crystals are cheap by design and factory-trimmed en masse during install.
 
but you're good for 5PPM, which is in striking distance of what the crystal allegedly also does.

If they were almost the same, I would buy the crystal BUT unfortunately one is a crystal and the other is a RTC with a TCXO oscillator. You get what you pay for. Try moving your 5 ppm crystal from ambient temperature and you will see a very large difference.
 
I don't want to relentlessly beat a dead horse, but I did a back of the envelope calculation based on published values for the coefficients, allowable temp range (-20*C to +70*C) and assuming absolute worst case scenario I come out to +/- 20PPM. IE about a minute a month.

Now, I don't have a CPU handy to calculate the max vs. even a rough estimate (ie simply designating 25*C as inversion temperature vs measuring it) but I suspect that even a rough open-loop approach in conjunction with an initial trim will eliminate most of the error. I'll add some charts later for comparison.

I guess the question is how many months you need to have the logger out there and how little you want to trim the crystal as a function of measured ambient or even CPU temperatures. Plane door closing, more later.
 
Last edited:
A bit of humor ...

I hope I not going to show my age but in the 70's TI (1976) came out with their famous LED digital watch.
The moment that you removed that watch away from your constant heated body "wrist" @ 98.6 F, the watch
would lose or gain minutes of time. You are dealing with the same problem of removing a watch crystal from
ambient to a higher or lower temperature environment. Try as much as you can but you will never overcome or
make a dirt cheap watch crystal into a TCXO.

If we were to use the watch crystal in our project, our name would change from "The high performance battery operated data logger"
to "The low performance battery operated data logger" :cool:

Just a thought, maybe we could strap the datalogger, using the dirt cheap watch crystal, to our wrist.
 
I totally understand why you chose the DS3232M... it's a great time saver and it's a really uncomplicated way to make your teensy sleep happily while the SQW and 32Khz output ticks away happily. I used to use the DS3231 for a similar purpose, i.e. alert a Atmel 1284P that another second had passed and that it was time to log all sorts of collected data to a SD card.

So, no doubt that the DS323X series of chips is an excellent one, yet I suspect that I won't likely need it for my project unless the trimming is very difficult to achieve (the mathematical formulas and concepts are nicely illustrated in documents like the TXCO ISL12022 controller line from Intersil which is designed to use an external crystal but which has alpha, beta, etc. compensation).

Let me try the approach I suggested and report back when I have finished. It will be interesting to learn about trimming the RTC in the Teensy 3 and devising a means of logging the deviation of the crystal as a function of temperature. The good news is that Citizen publishes the slope, inversion temperature range, etc. so the main thing re: accuracy will be to determine the inversion point and general offset at 25*C.

To achieve the above from a hardware point of view, I implemented a header for the UP501 GPS from Fastrax on my board. Using the PPS signal, it is possible to relatively quickly determine how fast or slow the crystal is running. Then, the challenge will be to put the rig through a variation of temperatures and to log the data, collect it, and then determine the inversion point.

Whether to trim the RTC inside the K20 or just compensate the sampling time length is a good question. The latter approach (i.e. if the sampling interval is 1s, add the micros as determined to the interval might be pretty simple to implement but I would have to keep track of 'lost' or 'gained' seconds in the data log.

You may want to do something somewhat analogous, i.e. using a GPS receiver's PPS output, NTP serial signals, etc. to adjust the aging trim offset function in the DS3232M. Manitou48 has done some very interesting work in this regard, publishing not only his results of testing but also how to test.
 
Last edited:
@Constantin

Let me try the approach I suggested and report back when I have finished

If you are able to turn the 0.76 cent watch crystal and the Teensy 3 RTC to replicate the Maxim-IC DS3232M or close to it,
I would wager a bet that other semiconductor houses would be kicking your front door down for your employment at their companies!

The odds of you succeeding is extremely low due to the fact that if it was that "simple" then it would have been done by now in the last ten years.

We do like your attitude in searching for this inexpensive solution and hope you truly do indeed succeed. :D
 
First, wonderful project! Thank you for sharing it. Next a few ideas for saving power.

Buffering and abbreviating log entries might reduce power consumption.

Writing complete sectors of 512 bytes to the microSD card would be more efficient than writing a hundred odd bytes at a time.

It doesn't look like the hardware writes any other amount than 512 bytes at a time. Even so, there might be charge pumps and things that are more efficient if powered on for many transactions together.

The internal RAM should be enough to store a few thousand log entries. The internal Flash should be enough to store maybe 30,000 log entries. It looks like the SdFat library does support bulk writes.

The log format is human-readable, but it could be more compact by removing all the static text, truncating measurements to the precision of the measurement, and perhaps reporting differences rather than absolute values.
 
Good ideas, but by far the biggest power saving improvement would be to reduce the data logger's K20 "deep sleep" quiescent current from millaAmps to uAmps.
Paul is working on this solution.

Current consumption of device during sleep (mA) [6.5] mA = milli-Amps <-----<<< Present T3 "deep sleep" mode quiescent current.
 
Well, its not that simple, is it? For one, it would require an OEM to run each and every board through a temperature-controlled environment while providing a very accurate signal to compare against. Then, you'd have to individually program each MCU with EEPROM entries re inversion point, slope, etc. and you'd need to have a relatively accurate on-board temperature sensor that is representative of the crystal. And the MCU would have to wake up periodically to retrim.

As I see it, external rtc's buy you not just convenience but performance as well, especially in low-power applications where keeping a relatively power-hungry MCU asleep as much as possible is a really good thing. Txco- and Oxco-based rtc's are even more accurate than 'regular' RTCs but the underlyig functionality / convenience remains similar. Yet MCU manufacturers also allow an external rtc input on most MCU's and give us hard coded registers for RTC correction, recognizing that users prefer to have a choice regarding the crystal (and its tolerances) as well the option to, or not to, trim the RTC.

For example, in an application with access to accurate time data (NTP server, GPS, cell network, etc) there are perhaps fewer reasons to have a very accurate clock. Simply correct it often enough and it'll always be reasonably accurate. Well, except in my car, where the navigation system is not used to keep the clock accurate. If an Arduino enthusiast can make a GPS-corrected clock that sets the right time and time zone based on location (!!!), why can't a major car company? But I digress.

If tolerances really didn't matter or customers didn't care, MCU manufacturers would simply give you an on-die oscillator and leave it at that. What I am proposing certainly is not novel, every MCU I've dealt with has appropriate registers for that reason - see the pages in the 870-range of the K20 manual to see just how much time the folk at Freescale dedicated to the various ways of adjusting the RTC.

BTW, informal testing with manitou48's GPS-based code re: crystal accuracy suggests 4-5ppm offset vs ideal under normal room conditions. Just as promised by the spec sheet. The next challenge will be to write a little program that takes the DHT22 output and uses that to trim the RTC register in the Teensy 3. Interestingly, that appears to be based on the ticks the clock is supposed to produce every second with 32786 as the center point. Allows for 0.12ppm adjustments, which is good enough for me.
 
Last edited:
The log format is human-readable, but it could be more compact by removing all the static text, truncating measurements to the precision of the measurement, and perhaps reporting differences rather than absolute values.

That's why we only showed code sample snippets of the sample logging code sketch. The user has many options to write uSD binary, reduce A/D bit precision and averaging and reduce the analog precision to reduce power consumption. The uSD >= 100 ma. peak power consumption is ,by far, the biggest power hog along with the deep sleep logger quiescent current of ~ 7.5 mA.

BTW ... The PJRC cavalry is coming .... please standby
 
Last edited:
BTW ... The PJRC cavalry is coming .... please standby

The PJRC cavalry did arrive and ....

http://forum.pjrc.com/threads/23660...ry-Operation-Solutions-For-The-Teensy-3/page2

A beta version of the upcoming low power support is now ready for testing. Over the last week, duff and t3andy have already been testing this version. Things are looking pretty good so far...

Now I'm ready to open the beta test to anyone else who is interested in low power applications and has time to test over the next several days. Please email me directly: paul at pjrc dot com, if you're interested?

This new version reduces the MINI54 power consumption. Currently it draws about 6 mA in all conditions. This update reduces the MINI54's current to about 0.14 mA while not uploading code, but waiting for an auto-reboot request from the Arduino software. It also adds detection for the MK20 sleep modes. When the MK20 enters a sleep mode, so will the MINI54, reducing the MINI54's current to about 6 uA.

In this beta test, aside from verifying the power savings, the main thing we're testing is if the MINI54 always wakes back up properly. While in the 0.14 mA mode, it should be able to detect a reboot request (no need to press the button). Once it enters the deep 6 uA sleep mode, the only way to return to uploading is with a pushbutton press. In particular, this beta test is focused on attempting to discover any low power condition where the pushbutton fails to respond (in theory, no such condition is supposed to exist).

Again, please email me directly if you're able to help test over the next several days. Unless any bugs turn up, my goal is to publish this new version at Teensyduino 1.16 in about week, so please only contact me if you will have time to beta test within the next 5 days.


:cool:
 
I like to add testing is not complete but ....
Low power
Teensy 3 Active Mode Test:

Before software bootloader change ...
Downloaded program: "blank.pde"
Teensy 3 active run (idle) current Is 19.29 ma. @ 24 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 25.18 ma. @ 48 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 31.68 ma. @ 96 Mhz <-------<<<<<
No connections are made to the Teensy 3
On board LED is off
Note: Higher freq = higher current consumption

After software bootloader change ...
Downloaded program: "blank.pde"
Teensy 3 active run (idle) current Is 13.07 ma. @ 24 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 18.8 ma. @ 48 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 25.4 ma. @ 96 Mhz <-------<<<<<
No connections are made to the Teensy 3
On board LED is off
Note: Higher freq = higher current consumption

The T3 low power "deep sleep" quiescent current consumption = ~ 250 uAmps <------<<<<<< (was ~ 6.5 ma.)

The Teensy 3 "only" current consumption dropped by ~ 6.5 - 0.25 in all speed modes. See above blank idle current readings.

On the data logger board, since we had "heavy" I2C 2.1K/10K pullups and the Adafruit uSD card with regulator, the deep sleep current went down from 7.5 ma down to ~ 1.25 ma. ... a 600% reduction <-----<<<< awesome
--------------------------------------------------------------------------------

Beta testing is still ongoing ...

:cool::D:cool:
 
Last edited:
RIP ... Our uSD battery operated Teensy data logger has just died after logging for every minute, of every hour, of every day for the last 42 days! :)


Here are the battery depletion results of the Teensy uSD Data Logger. We took the uSD data logger and inserted two new AA Alkaline batteries into the loggers battery holder and placed it in a secure area until battery depletion testing was complete.


The first two tests were the same using beta 1.15 and in each test the two AA Alkaline batteries failed after ~ 6-7 days. :(


The last test, using the "new" beta 1.16 with the bootloader "offset" fix by Paul S, lasted 42 days or 6x longer!!!! :)<--------<<<<<<<

On the data logger board, since we had "heavy" I2C 2.1K/10K pullups and the Adafruit uSD card with regulator, the deep sleep current went down from 7.5 ma down to ~ 1.25 ma. ... a 600% reduction <-----<<<< awesome

The testing confirms a 600% or 6x reduction in power.


--------------------
Data Logging Test #1
--------------------

Beta 1.15 <--- With mini54 bootloader "offset" of ~6.5 ma.

CSV SD file format: sample#,analog float sample,time/date stamp,DOW,battery voltage,battery status, task execution time uSecs.
Sample duration/rate: Every minute, of every hour, of every day.
AA Alkaline battery depletion or duration: 6.68 days @ 9622 samples and 1,029 KB log file <------<<<<<

Note: The booster converter minimum voltage is 1.8 VDC. The logging samples continue below this minimum "battery voltage" but
the analog sample taken is suspect below 1.8 VDC. The booster converter regulation of 5.0 VDC to the Teensy 3 drops and then the
Teensy 3 A/D reference also drops. For this battery depletion test - the logger fails, due to low batteries, only when the samples
are invalid or suspect.(Logging continues on for 10's of 100 samples before halting)

--------------------
Data Logging Test #2
--------------------

Beta 1.15 <--- With mini54 bootloader "offset" of ~6.5 ma.

CSV SD file format: sample#,analog float sample,time/date stamp,DOW,battery voltage,battery status, task execution time uSecs.
Sample duration/rate: Every minute, of every hour, of every day.
AA Alkaline battery depletion or duration: 6.70 days @ 9661 samples and 1,119 KB log file <------<<<<<

Note: The booster converter minimum voltage is 1.8 VDC. The logging samples continue below this minimum "battery voltage" but
the analog sample taken is suspect below 1.8 VDC. The booster converter regulation of 5.0 VDC to the Teensy 3 drops and then the
Teensy 3 A/D reference also drops. For this battery depletion test - the logger fails, due to low batteries, only when the samples
are invalid or suspect. (Logging continues on for 10's of 100 samples before halting)

---------------------
Data Logging Test #3
--------------------

Beta 1.16 <---- Mini54 software fix (offset) by Paul S, reduced the Teensy 3 "deep sleep" from ~6.5 ma. down to ~250 uA.

Our super high perforamce micro SD logger, with precision RTC and uSD memory now has a much lower quiescent current consumption.
Note: Since the logger quiescent current is lower, the DS3232 RTC lithium battery is being used more and will deplete faster!
The testing results below are awesome!


CSV SD file format: sample#,analog float sample,time/date stamp,DOW,battery voltage,battery status, task execution time uSecs.
Sample duration/rate: Every minute, of every hour, of every day.
AA Alkaline battery depletion or duration: 42 days @ 61,277 samples and 6734 KB log file <------<<<<<

Note: The booster converter minimum voltage is 1.8 VDC. The logging samples continue below this minimum "battery voltage" but
the analog sample taken is suspect below 1.8 VDC. The booster converter regulation of 5.0 VDC to the Teensy 3 drops and then the
Teensy 3 A/D reference also drops. For this battery depletion test - the logger fails, due to low batteries, only when the samples
are invalid or suspect.(Logging continues on for 10's of 100 samples before halting)

After testing with beta 1.16, we decided to change the logger name description to "The SUPER High Performance Battery Operated Data Logger"

Attached data log file ... <--- file too large to upload

The last line before the logger halted due to dead batteries ...

61349,0.7752380,VDC A9 Sensor,0:36:0,9-14-2013,DOW=6,Sat,1.1169230,VDC AA Bat.,Low Battery(s) Warning!,8167,uSecs. Task Execution

:cool:
 
Last edited:
Status
Not open for further replies.
Back
Top