The RoboRIO does not have a RTC (calendar/wall time clock). It normally gets the correct time from the driver’s station, but there are use cases where this might not happen and you still want to create logs with useful timestamps, a RTC (real time clock) is a good way to handle the problem if you do not have (or cannot depend on) internet connectivity.
Interesting, I was not aware of this. Are there cases aside from data logging that this could benefit as well? Say time-based robot actions (autonomous, etc.)? Is there enough variance in the DS-acquired time that there would be any benefits to this for anything aside from logs?
Probably not, because most of the things you care about have to do with the *change\i] in time, rather than the time itself. So as long as you have a base number to say ‘this is the start of the program’, then everything past there will be in reference to that start number.
Knowing the ‘exact’ time is really only useful for logging, but even then, not really useful. Knowing that the robot finished autonomous at 11:33:22.879 is (to me) less useful than knowing it finished 11.3 seconds into autonomous*
Ohh! Good question! So, my code changes to the stock module were to enable the trickle charge setting for the RTC (without all of the device tree shenanigans). It has some internal bits to flip to make that work:
I would recommend putting a label on it that says “Not a Battery” :yikes:
In all seriousness, I had wondered the same thing, how you were persisting the clock through power outages, and had to go take a look myself earlier. I may have missed it in the documentation, how long will the clock persist once the robot is turned off?
There are situations where power may be inadvertently cut to the RoboRio. Even if it’s for a fraction of a second, if it’s enough to cause the RoboRio to reboot the relative timestamps may not give you what you want. Further, if you’re trying to track down an issue at the end of the day and have video showing it occurring in different matches, having exact timestamps can let you more easily isolate the different occurrences.
And looking at non-FRC robot related usage, exact timestamps are pretty much critical for many applications. When a user calls in to complain that “something bad” happened with an application, many times your first question (after ascertaining that it really was “something bad”) is going to be when did it occur. Then you can go to the logs, search the timeframe the user gives (plus or minus half an hour because users aren’t always the most accurate people) for the user’s ID and figure out exactly what happened and why. Relative timestamps are pretty useless in many professional applications.