myRIO time resets to system default starting time after reboot

[Dimasaur]

Hello lads,

i have the following issue.
I am measuring voltages on every analog input. The measurement begins right after booting the myRIO device, while the system time of the myRIO device resets to the default system time. But the measurements are unusable without a proper timestomp, containing the actual time(day, month, yearh, hour , minutes , seconds).
Is there a possibility for the myRIO device to boot with the actual time, or that the myRIO device counts time while turned off. (perhaps someone knows external devices that can be connected to the myRIO usb port to get the actual time)

Greetings from Germany

Dimasaur

[Sam_Sharp · Accepted solution]

The myRIO does not have an onboard battery for the real time clock so the date/time will reset with each power on.

You can set the date/time on the myRIO using the System Configuration VIs on the target, so all you need to do is get that timestamp from somewhere and set it when the myRIO boots up.

Here are some options:

- If you have a connected HOST VI, send the timestamp to the myRIO from your PC

- An external serial/I2C/SPI battery backed RTC chip/module which you can connect to the myRIO. There's an example here.

- A GPS module provides a very accurate timestamp as part of it's NMEA data - you could hook one up to the myRIO e.g. via Serial

- Get the timestamp information from the network (e.g. from an SNTP time server or by making a HTTP request - the timestamp is usually returned in the header information from the server and/or you could find a web service which provides 'current time' information)

[Matthew_Williams]

What we have done in situations where we have to make timestamped readings before we can know that we have a valid clock setting:

1) DAQ loop - take readings, put into a cluster with the timestamp and then the cluster goes into a queue (we have to queue data anyway, so no additional work).

2) Clock setting loop - this loop just waits until we know the clock has been set, usually by seeing that the current time is > 1/1/2014 or some date that we know is before 'now' and significantly after (as in years) the default boot up time of the device.  This loop also remembers the delta between the first clock setting (via ntp or our application) and the system time when that setting occurred; we save this delta as our clock offset.

3) De-queue loop - takes readings out of the queue.  If the timestamp of the reading is < 1/1/2014 or whatever, then we add the clock offset recorded by loop 2 to get back to what the actual time of the reading was.  If the timestamp > 1/1/2014, leave it as is because that reading was taken after the clock was set.

This approach isn't perfect and won't work for microsecond precision, but for slow logging it works just fine.

Matt

[Samuel-L]

Why did I get an error when I applied this program to change myRIO time? May I ask where I made a mistake?