PDA

View Full Version : Teensy uSD Data Logger Project --> The high performance, battery operated data logger



t3andy
07-15-2013, 11:58 PM
678

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 >> "));

t3andy
07-16-2013, 12:09 AM
Also attached is the beta schematic.:cool:

flipflop
07-21-2013, 03:22 AM
Great t3andy!!!, I'm also working on a datalogger with teensy 3.0:
https://github.com/lsaavedr/centinela without power manager and PCB, but I would like to integrate your contributions, is this possible?

regards!

t3andy
07-23-2013, 01:14 AM
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 ...

Constantin
07-23-2013, 07:25 PM
I have a dumb question... why not use a 5PPM crystal for the RTC as sold here on digikey (http://www.digikey.com/product-detail/en/CFS206-32.768KHZF-UB/300-8763-ND/2217074) 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 (http://datasheets.maximintegrated.com/en/ds/DS3232.pdf). 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'.

t3andy
07-23-2013, 10:02 PM
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.

PaulStoffregen
07-23-2013, 10:27 PM
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.

Constantin
07-24-2013, 02:16 AM
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 (http://ww1.microchip.com/downloads/en/AppNotes/01155a.pdf). 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.

Jp3141
07-24-2013, 07:52 AM
"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.

t3andy
07-24-2013, 12:07 PM
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:

t3andy
07-24-2013, 12:12 PM
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

PaulStoffregen
07-24-2013, 12:36 PM
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 (http://forum.pjrc.com/threads/23660-Low-Power-quot-Green-quot-Battery-Operation-Solutions-For-The-Teensy-3), so please subscribe to it if you want to hear as soon as possible.

Constantin
07-24-2013, 01:56 PM
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.

t3andy
07-24-2013, 04:49 PM
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.

Constantin
07-25-2013, 02:54 AM
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.

t3andy
07-25-2013, 10:29 AM
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.

Constantin
07-25-2013, 12:25 PM
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 (http://www.intersil.com/en/products/timing-and-digital/rtcs/real-time-clocks/ISL12022.html) 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. (https://github.com/manitou48/crystals)

t3andy
07-26-2013, 01:15 AM
@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

pictographer
07-26-2013, 05:05 AM
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.

t3andy
07-26-2013, 12:46 PM
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.

Constantin
07-29-2013, 12:16 PM
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 (https://docs.google.com/document/pub?id=1wtgUoS4d7RWNOscLEQqgQcdmxl_rW34bLy4mNCantp Q) (!!!), 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.

t3andy
08-02-2013, 03:08 PM
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

t3andy
08-07-2013, 08:07 PM
BTW ... The PJRC cavalry is coming .... please standby

The PJRC cavalry did arrive and ....

http://forum.pjrc.com/threads/23660-Low-Power-quot-Green-quot-Battery-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:

t3andy
08-07-2013, 08:18 PM
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:

t3andy
09-15-2013, 03:14 PM
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:

Constantin
11-30-2013, 10:20 PM
[BANG BANG BANG!]

There's those pesky uC companies beating on the door… again! :)

Finally got around to characterizing the RTC crystal approach with a CFS206, as promised. I used a GPS receiver to time the MCU crystal and the RTC crystal and a HTU21 temperature / humidity sensor to determine the PPM error vs. temperature. 50-odd measurements later, a least squares calculation distills the data points into a equation for a parabola that has a high degree of correlation.
1156

Not that this approach is for everyone -
a) the MCU has to be on all the time (the TXO RTC can do this automagically)
b) temperature-based refreshes of the variables in question may interfere with other tasks.
c) having a accurate on-board temperature sensor is likely a requirement. The HTU21 is great - and I needed it anyway for humidity measurements.
d) You have to run the rig through a calibration routine with a GPS receiver. Takes time but factors can be stored once in EEPROM and forgotten. Accounts for all deltas…

So, plenty of reasons to stick to a TXO RTC, but I had fun showing that this approach can also work for my application. Despite all this, I may still make room on a daughter-board for your TXO RTC to give my colleagues the opportunity to eschew the need for GPS calibration.


Welcome. Prepare to wait 0 seconds for CIC register to run out.
Now waiting for PPS signal acquisition.
Done.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.77PPM @ 22.83*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.77PPM @ 22.81*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.76PPM @ 22.75*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.75PPM @ 22.68*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.76PPM @ 22.70*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.75PPM @ 22.62*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.73PPM @ 22.43*C.
Actual MCU-RTC PPM delta: 6.80PPM, Predicted delta: 6.70PPM @ 22.21*C.
Actual MCU-RTC PPM delta: 6.40PPM, Predicted delta: 6.65PPM @ 21.87*C.
Actual MCU-RTC PPM delta: 6.40PPM, Predicted delta: 6.55PPM @ 21.24*C.
Actual MCU-RTC PPM delta: 6.60PPM, Predicted delta: 6.45PPM @ 20.77*C.
Actual MCU-RTC PPM delta: 6.20PPM, Predicted delta: 6.37PPM @ 20.41*C.
Actual MCU-RTC PPM delta: 6.40PPM, Predicted delta: 6.29PPM @ 20.10*C.
Actual MCU-RTC PPM delta: 6.20PPM, Predicted delta: 6.20PPM @ 19.79*C.
Actual MCU-RTC PPM delta: 6.20PPM, Predicted delta: 6.13PPM @ 19.52*C.
Actual MCU-RTC PPM delta: 6.20PPM, Predicted delta: 6.04PPM @ 19.25*C.
Actual MCU-RTC PPM delta: 6.40PPM, Predicted delta: 5.96PPM @ 18.99*C.
Actual MCU-RTC PPM delta: 6.20PPM, Predicted delta: 5.88PPM @ 18.75*C.
Actual MCU-RTC PPM delta: 6.20PPM, Predicted delta: 5.79PPM @ 18.49*C.
Actual MCU-RTC PPM delta: 6.00PPM, Predicted delta: 5.70PPM @ 18.27*C.
Actual MCU-RTC PPM delta: 5.80PPM, Predicted delta: 5.61PPM @ 18.03*C.
Actual MCU-RTC PPM delta: 5.80PPM, Predicted delta: 5.52PPM @ 17.81*C.
Actual MCU-RTC PPM delta: 5.60PPM, Predicted delta: 5.43PPM @ 17.59*C.
Actual MCU-RTC PPM delta: 5.60PPM, Predicted delta: 5.34PPM @ 17.38*C.
Actual MCU-RTC PPM delta: 5.60PPM, Predicted delta: 5.25PPM @ 17.17*C.
Actual MCU-RTC PPM delta: 5.40PPM, Predicted delta: 5.16PPM @ 16.96*C.
Actual MCU-RTC PPM delta: 5.20PPM, Predicted delta: 5.06PPM @ 16.75*C.
Actual MCU-RTC PPM delta: 5.60PPM, Predicted delta: 4.96PPM @ 16.54*C.
Actual MCU-RTC PPM delta: 5.00PPM, Predicted delta: 4.86PPM @ 16.35*C.
Actual MCU-RTC PPM delta: 5.00PPM, Predicted delta: 4.77PPM @ 16.15*C.
Actual MCU-RTC PPM delta: 5.00PPM, Predicted delta: 4.66PPM @ 15.95*C.
Actual MCU-RTC PPM delta: 5.00PPM, Predicted delta: 4.56PPM @ 15.76*C.
Actual MCU-RTC PPM delta: 4.80PPM, Predicted delta: 4.46PPM @ 15.56*C.
Actual MCU-RTC PPM delta: 4.80PPM, Predicted delta: 4.36PPM @ 15.38*C.
Actual MCU-RTC PPM delta: 4.40PPM, Predicted delta: 4.25PPM @ 15.18*C.
Actual MCU-RTC PPM delta: 4.60PPM, Predicted delta: 4.14PPM @ 15.01*C.
Actual MCU-RTC PPM delta: 4.40PPM, Predicted delta: 4.04PPM @ 14.82*C.
Actual MCU-RTC PPM delta: 4.20PPM, Predicted delta: 3.93PPM @ 14.64*C.
Actual MCU-RTC PPM delta: 4.20PPM, Predicted delta: 3.81PPM @ 14.45*C.
Actual MCU-RTC PPM delta: 4.20PPM, Predicted delta: 3.70PPM @ 14.27*C.
Actual MCU-RTC PPM delta: 3.80PPM, Predicted delta: 3.59PPM @ 14.10*C.
Actual MCU-RTC PPM delta: 3.80PPM, Predicted delta: 3.48PPM @ 13.93*C.
Actual MCU-RTC PPM delta: 3.80PPM, Predicted delta: 3.37PPM @ 13.75*C.
Actual MCU-RTC PPM delta: 3.60PPM, Predicted delta: 3.26PPM @ 13.58*C.
Actual MCU-RTC PPM delta: 3.60PPM, Predicted delta: 3.15PPM @ 13.43*C.
Actual MCU-RTC PPM delta: 3.60PPM, Predicted delta: 3.04PPM @ 13.26*C.
Actual MCU-RTC PPM delta: 3.60PPM, Predicted delta: 2.92PPM @ 13.09*C.
Actual MCU-RTC PPM delta: 3.40PPM, Predicted delta: 2.82PPM @ 12.94*C.
Actual MCU-RTC PPM delta: 3.20PPM, Predicted delta: 2.70PPM @ 12.79*C.
Actual MCU-RTC PPM delta: 3.20PPM, Predicted delta: 2.59PPM @ 12.63*C.
Actual MCU-RTC PPM delta: 3.00PPM, Predicted delta: 2.49PPM @ 12.49*C.
Actual MCU-RTC PPM delta: 2.80PPM, Predicted delta: 2.38PPM @ 12.34*C.
Actual MCU-RTC PPM delta: 2.80PPM, Predicted delta: 2.28PPM @ 12.21*C.
Actual MCU-RTC PPM delta: 2.00PPM, Predicted delta: 2.12PPM @ 12.00*C.
Actual MCU-RTC PPM delta: 2.40PPM, Predicted delta: 1.97PPM @ 11.81*C.
Actual MCU-RTC PPM delta: 2.60PPM, Predicted delta: 2.05PPM @ 11.91*C.

The resolution for the above data is not the greatest because I was running the Teensy on a 5 second update loop per MCU / RTC cycle, so the PPMs measured increment in 0.2PPMs. But generally within 0.5PPM despite changing temperatures and likely could be better if the time constant were longer.

t3andy
12-01-2013, 12:18 AM
Not that this approach is for everyone

Unless you have very expensive test equipment on hand and a large bank account.:cool:

BTW ... great effort! Now, what's your sleep current draw?



BANG BANG BANG!

There's those pesky uC companies beating on the door… again!



Bill collectors.:cool:

Constantin
12-01-2013, 12:55 AM
Ha ha ha. And here I thought the uC companies were beating a path here because a open-loop temperature compensated crystal seems to behave predictably enough to allow 1ppm performance or better. Oh well. Re-ran the tests tonight with a longer test period and a table-mat to slow the heat transfer. Now up to r^2 of 0.999 - this curve is good for a sub 0.5PPM error for any individual reading and 0.03PPM over the course of 2 hours of data logging across changing temperatures.
1158

And if you think about it, the DS323X series does exactly the same thing… it measures temperature, and then uses a open-loop control algorithm to adjust its outputs as needed. All in a little package with a I2C or SPI interface. Essentially, a Attiny 45 with a adequate on-board chip temperature sensor and a high-quality crystal (MEMS or otherwise)… and value-priced to reflect all the features it brings to the table. If the temperature sensor were more accurate and the updates more frequent (i.e. more often than once every 64 seconds), I'd expect that the DS323X series could exceed +/- 2PPM in terms of accuracy, though at the price of higher power consumption and lower VBAT life whenever the VBAT is providing power. At least that seems to be the most logical design tradeoff the team had to make.

The good news is, having a good clock around for calibration is pretty inexpensive - a $34 GPS receiver and it's PPS signal is a atomic clock on the cheap and no issues with latency like with NTP or computer-based clocks. The on board temperature sensor (HTU21) has a accuracy tolerance of 0.3*C vs. 2*C for the DS323X series… and since it stays with the crystal, any offsets will remain perfectly compensated. There is the issue of aging causing drift, but it seems easy enough to fix - just re-run the calibration program once a year to calculate new factors for the correction curve… Calibration, BTW, is something the DS323X series would also theoretically benefit from - hence the aging registers.

Given the level of effort of calibrating (time, not cost is the issue) I'm still interested in giving folk the option to use the DS3232 you identified. Or, how to share one PPS output among many boards. A batch process of self-calibrating boards (requiring no more than cursory supervision for let's say 8hrs) may be OK. For example, we could use a rocketscream PID reflow oven controller board as a sous-vide crystal calibration cooker! :)

My board never gets to sleep, BTW. It's purpose is power measurement of appliances 24/7 and you can't get the granularity we need re data when it's not on 24/7. Being line powered, power draw is a secondary concern. The on-board power supply is good for ~1.5A @ 5V, most of which is designed to be used by daisy-chained devices, not the board with the power supply.

Next steps include thinking of ways to reduce the processing overhead required to keep the crystal calibrated, i.e. for example a sub-routine that gets triggered once a minute to check on the temperature and to change the pre scalar settings for the RTC_TCR registers if warranted. Lastly, ideally, turn the whole thing into a library so that the programs that need it aren't cluttered with tons of crystal-related code. Have never written a library though (danger, will robinson, danger!) :D

t3andy
12-01-2013, 06:24 PM
The Maxim-IC I2C RTC DS3232MZ+ has a temperature compensation range between -40C to +85C. :cool: This is why we chose this TCXO RTC so the uSD data logger could operate in extreme temperatures and still be accurate.:cool:
BTW ...Your TCXO RTC crystal clone has what range?:(:confused:

Constantin
12-01-2013, 09:16 PM
The Maxim-IC I2C RTC DS3232MZ+ has a temperature compensation range between -40C to +85C.

Yes, a range that exceeds the recommended temperature range of any common Alkaline, Lithium-Ion, NiCd, NiMH, etc. cell I know of. You were going to power your logger with a battery, right? Energizer recommends -18 to 55*C for its alkaline cells, for example. Sure, you could operate outside that range and be OK, for all I know, but the manufacturer is making no guarantees. The alternative is to buy extended temperature range cells and pay the premium.

Also, if I were you and you want to certify your product at -40*C, I'd test it there. All battery types have a severely reduced available capacity at that temperature and may not be able to provide the juice you need to run your logger reliably. Conversely, at 85*C, I'd start to worry about the batteries overheating.


Your TCXO RTC crystal clone has what range?

So far, this one sample has been tested from about 0*C to about 40*C, which seems adequate for the indoor conditions I expect my device to encounter. Many appliances do not tolerate being operated in sub freezing conditions, and thankfully there are few to no places in the US that regularly reach 40+*C indoors. Even so, the fit to the curve seems pretty amazing (for this sample of one, so I wouldn't dare make any conclusions on that basis).

More testing with more crystals seems warranted if we want to go the route of using the compensated crystal approach in production. And, designing for a fallback with a DS3232 seems like a pretty good insurance policy. So, congrats on your data logger and I wish you great success with it.

t3andy
12-01-2013, 11:04 PM
We made it, on contract, for data logging in the wild blue yonder. One power source you forgot to mention is general purpose Supercapacitors (operating temperature range: -40C to +70C) :cool:

t3andy
12-04-2013, 11:34 PM
Another way to beat a dead horse eg watch crystal ...

You can also factory trim the Teensy 3 RTC digitally using a "GPS disciplined" oscillator.
As a result the accuracy at room temperature (whatever it was in our lab when we calibrated it!)
is better than 2ppm (parts per million). This translates to about 63 seconds per year.

http://en.wikipedia.org/wiki/GPS_disciplined_oscillator

An additional error comes in due to the temperature coefficient of the 32,768Hz timing crystal.

In a real application, this means that a clock built using a regular 32 kHz tuning fork crystal will
keep good time at room temperature, lose 2 minutes per year at 10 degrees Celsius above (or below)
room temperature and lose 8 minutes per year at 20 degrees Celsius above (or below) room temperature
due to the quartz crystal.

tim_ui
04-07-2014, 10:10 PM
Hi there t3andy! I am currently logging data in the laboratory using Arduino Uno and DS18B20 digital temperature sensors. I need to set up a field data logger that will operate for months. I found this thread, and it looks like exactly what I need. Can you help me with the parts list and tell me if the low power consumption beta test proved the setup could be semi reliable for my project? Thanks.

t3andy
04-08-2014, 12:58 PM
@ tim_ui ... you really need to "review" the docs at the beginning of this topic/thread. Inspect the provided schematic.
We are now using an "off the shelf" booster converter from Tindie. This enables one cell AA battery operation.
https://www.tindie.com/products/BBTech/tps61200-booster-module/?pt=directsearch
:cool:

tim_ui
04-08-2014, 05:08 PM
t3andy...thanks, I did not see the other thread with the information about the Duff library. So, the parts list has not changed from post number one, other than the booster? And, the schematic dated 8/1/13 is the latest?