MAX-M8Q-0 Real Time Clock - can I use it instead of an external RTC on my embedded Linux system?

0 votes
I have an embedded Linux system with an external RTC (DS3234) and battery.  Can I get rid of that external RTC and use the one inside the MAX-M8Q-0 instead?   If so, how would this be accomplished?    If the answer is no, then what's the point of having a backup battery on the MAX-M8Q if my external RTC already has one?  Note that my embedded system never goes into low power mode or sleep.  

Thanks for you help
by griduser asked Aug 30, 2017
287 views
+1 vote
You can't access the MAX internal RTC for external timing or clocking.  The date-time is derived from a large  counter, not like in the Dallas part.
When the MAX is on and has a fix, you can use the timestamp in NMEA messages to set the MCU clock; the MCU should be able to coast through the MAX off periods with reasonable accuracy.
Backup power is used to maintain SRAM that contains all kinds of valuable data required for hot and warm starts, to retain configuration settings and calibration data.
[Edit] There are some u-blox parts that allow an external RTC oscillator which could be shared with other devices. The date-time for the other devices would have to be generated as described above.
by grampy answered Aug 30, 2017
by griduser selected Aug 30, 2017
Flag
Best answer
I've been wondering about this too. I also have a similar combination of hardware.

With the aid of a GPS, especially, NTP and similar apps - like chrony, can work with a hardware clock to characterize its error and discipline it.  This will ensure that even when GPS or network is unavailable the clock stays precise.

I would look into chrony, because its meant for this kind of situation.
Then take a look at the LEA-M8F: self-steered/disciplined 0.1ppm VCTCXO, timepulse derived synchronously from the VCTCXO, plus location and date-time, and no need for an external app for steering, only for NTP server.
I've also spent some time trying to get an RTC reading out of a SAM-M8Q, so on reading this realize I need to give up. The M8 protocol spec says that a UBX command "RXM-RAWX" can read the "receiver clock" but only with the "Time Sync" products, which M8Q is not. Nonetheless I issued this command and got a response, - it seems to be headed as a "NAV-PVT" packet rather than expected RXM-RAWX. Any clues on this? Might it be an undocumented response which does contain something meaningful?

Seems to me that the unit does have a real time clock, and with suitable M8 firmware, it should be possible to use it as a host system real time clock. Any chance of a firmware upgrade one day?
website banner