Fez Panda II's 'real time clock' reliability


I am currently working on a Fez Panda II, and would like some advise in terms of the ‘real time clock’.

I am generating a ‘port listener’ which will hopefully log the contents of a port communication., in which will generate a text file every 255 bytes send, or alternatively when a certain time interval has taken place (that is, only when the fez is powered on).

This would hopefully allow me to ‘timestamp’ the files, and hence retrieve them (in order) at a later date.

However, I have some reservations over the clock’s accuracy.

Obviously I do not want to overwrite any of the data, and so if the data appears very quickly, I wish for these to be timestamped differently (and not have a collision occur on file names).

So would this be possible to use the clock’s time to name the file? Or should I use the approach of:

Store int X in file "indexer.txt"
Read indexer.txt to obtain number
increment number
save new text file called ‘X’.
update indexer

This wouldn’t be the most appropriate solution, though, since I would like to know the time it was recorded at (I have already done a simple test, although the file apparently was “created at 00:08 on the 01/01/2009” - although we’re currently in 2015 last time i checked).

This is suggesting that the clock will reset every time the fez is turned off. (In which would be useless, since the fez will be powered on/off regularly).

I would appreciate any advice you could give me here :S

They’re as accurate as a typical electronics item with a crystal and battery.

If you’re periodically “connected” (network ? Bluetooth?) you could potentially adjust for any drift.

Perhaps a test is in order; run it for a while and see how much drift you get !

How accurate do you need ? What happens if your time is 1 second out in a day? What about if it was 1 minute in a day, or 30 minutes in a day ?

by the way, you have read up about the RTC, right ? You have to SET the time first, otherwise it simply takes the default “start time” which you guessed it, is 1st January 2009. https://www.ghielectronics.com/docs/29/real-time-clock-rtc

@ Brett: Thank you for your (very) prompt reply.

This project is designed to never truly [em]connect[/em] to a network (it’s going to e fixed to a side of a vehicle), and only the sd card will be added/removed from the fez.

This means that the power could be off for weeks, or even months at a time.

I’ve not the experience to know exactly how long a fez can go without power before it resets it’s time on next power up (and if it does. it’ll screw up the logging). So maybe the ‘counter’ approach would be better after all.

But yes, I’ve read that article, but it talks about checking the time/setting it if it goes out of sync - i’ve got to ensure it never does (otherwise overwrite would be affected).

So maybe using the time to label the txt files isn’t the best option? But as I’ve said, I’ve not built up the experience with netmf to know yet :-[

@ Brett - Would you be able to recommend a way of always keeping power to the board at all? (i.e a li-battery module or similar). In order to ensure that the time [em]won’t [/em] ever be reset?

no, there is no way to supply power “for ever”. Mr Fusion [1] has not yet been created, and most of the “free energy” projects I’ve seen are not real [2]

The RTC needs a battery backup to operate, you realise that yeah ? When the device is powered from the usual source (for example, the car’s battery) then the RTC will run, but if you lose that power then it has to fall back to the RTC backup power. Typically, this would be a watch battery or supercapacitor, depending on what you need. But the Panda on it’s own, with just a single power source connected to the main power input barrel, will not keep RTC across power outages.

As for overwrite. No, that’s a completely solvable problem. In your code just check a file exists before creating it, and if so create some differentiator. That doesn’t help you figure out when that data came from, but it does help you keep all the data.

[1] BTTF reference
[2] I have no reference

@ Brett:

Sorry, I meant like a watch battery (not fusion ) :wall:

Like a supercapacity/watch battery module that’s already and just waiting to be plugged into the panda to keep the RTC ‘running’ a good amount of time?

I’m sure there’s one already made, (rather than me of all people trying to re-invent the wheel), which I could get ‘off the shelf’ (since i’m in no way an electrical engineer, just a simple/novice programmer, meaning i’m not good with circuits - ). :-[

It took me long enough figuring out a serial port connection and don’t fancy trying to go through that all again…yet.

So if you knew/hear of a battery module for the fez for simply powering this on-board clock, I’d be very appreciative if you gave me a shout! :slight_smile:

There’s a VBAT pin, and all you need is the + of a coin battery connected to that pin, and GND of the battery connected to a GND pin, and you’re done. You could just buy a commercial “pack” like this sparkfun item https://www.sparkfun.com/products/12618 and connect red wire to VBAT and black to GND.

1 Like

@ Brett: Thank you for your help,; it was just what I was realistically looking for! (although I could never be sure of it).

As long as it keeps the on board clock alive for at least some time, (haha, get it :smiley: ) i’ll be happy enough.

Now hopefully i’ll be able to wire a 9v battery as well in order to bring a on/off poswer supply to the board (although i’ll leave that to the electronics experts :P)


just remember, if you’re talking about the “PP3” 9v battery like outlined in Nine-volt battery - Wikipedia then you have a very small capacity, in the 400-600 mAh range, and are generally what I would see as a poor choice for most devices.

Talk about your power source and power needs. if you only have the Panda running when the vehicle is running, and you have a battery holding the RTC, then you should be OK to change the RTC battery when the vehicle is powering the device (you may want to think about how your code writes the system time back to the RTC if it drifts, like if the battery changes - reasonably easy to test I guess). If you’re doing lots of sleeping and therefore not chewing much power anyway, you may be able to run of an “always live” connection from the battery?

And of course you could always consider using a supercap in place of the coin battery, which avoids the need to replace the coin cell when or before it goes flat, but you’re going to need to do more management of voltage and charge and maybe even create your own PCB for it.

@ Brett: What sort of battery/power would you suggest?

Using the vehicle as a power source would be good, but in my project, not possible as the fez will not be ‘viewable’/accessible in terms of power. Think of the fez as a ‘black box’, and so will be inaccessible and self-contained (for between 1-2 week periods, anyway).

I was trying to implement the 9v battery (against your recommendation, but I do not I know what else), but I don’t know if it was the brand of battery itself, or just my project/implementation, but it seemed to ‘freeze’ my board/only last for around two/three hours (really hard to debug btw).

I was thinking of using an interrupt port, although since i’m ‘sniffing’ constantly for data, it makes this quite hard to implement.

I’m happy enough to ‘replace’ the battery/power supply every, say, two weeks, but I would need ‘24hr surveillance’ /logging…

As for my project, I’m afraid i’ve not really included many ‘sleeps’ due to the com port listening (so i’m currently looking to include some sort of '‘flag’ on first byte read so that i’m not chewing up resources/power unnecessarily).

You input would be very helpful at this point :slight_smile:

to be self contained, you want to figure out what your consumption is (say average it over a minute, then longer) and then multiply that by how many autonomous hours you need.

I assume you are talking about a GPS device being on a COM port? If that’s the case, how much power does it draw ? Can you switch it to a low power mode ?

Really, to do this in any decent way you are likely to need heavy use of sleep, and/or recharge capability. If I wanted to put a logger in my car but could not be permanently powered by the car battery when it was switched off, I’d be looking at something “large” like an LiIon battery (Lithium-ion battery - Wikipedia ) that could be charged from the battery when the car was running, but would likely let the device run long enough when parked (my car stays at home for days at a time, so I might struggle with this; if this was going into a fleet car, different story, you might find it runs for many hours per day). But you need to be careful about charging whatever cell chemistry device you’re talking about.

I am not surprised the 9v battery is giving you only hours runtime. As I said, they are a paltry power source.

You also need to think about the system from power loss perspective - what voltage/s do you need to implement for all the devices you have, and how are you providing those ? For example, the Panda only needs 3.3v, but the onboard power management you have can take a 9v input and turn that into the necessary 3v3 (via a conversion down to 5v) but that’s not necessarily minimising losses that would help your “24x7x14” aim. So perhaps using a 3.7v LiIon battery and an efficient regulator to get 3v3 will be more efficient ? In those scenarios you could go with an “easy” self contained solution like 18650 or similar batteries in parallel to get capacity? You could do the same with remote control “toy” batteries, you’re looking for “1s” types as they’re a single cell - but they are potentially dangerous from a charge perspective (they are “bag” style, and there are many fire stories / videos on youtube showing mistreated ones misbehaving)

Personally I don’t think I can tell you the answer - you need to measure power consumption to properly plan this.

1 Like

@ jbutler483

If I understand what you’re trying to do I think your application might benefit from using an external real time clock. I had similar requirements for low power, long life, and the ability to retain an accurate time when main power is off. The problem with the PandaII’s LPC2387 RTC is that the accuracy is variable and it draws 20 microamps which is quite a bit compared to some other RTC options. The LPC 2387 RTC should also only be connected to Vbatt after Vcc is applied or it will draw even more current. This is documented in the errata sheet LPC2387.

In my application I found that using an external RTC, the DS3231, is a far better solution although it does require a separate circuit communicating over the I2C bus. You can either add your own circuit or connect one of the prepackaged boards available. The DS3231 draws less than a microamp in backup mode and with a temperature compensated timing system it is accurate to less than 5 ppm.

I use a 1 AH 3.6 V lithium battery to power just the DS3231. With this set up you really don’t care how long the Panda main power is off because the DS3231 is alive and ticking whenever you need it, or at least for about the next 50 years.

As Brett has said, your power requirements then really determine the rest of what you need to do for long battery life. Hibernation will cut the Panda II current draw to about 12 ma so if you can hibernate for substantial periods of time it helps a lot. You can also slow the clock, but that introduces special timing considerations if you are doing serial communication.