Logs date and time

[cpapplefamily]

Understanding that many of the logging features are not installed or fleshed out I have a question about the Logs that are present. In particula,r the CTRE logs seem to be dated wrong. A log I just ran and retrieved was labeled FC3906C24C32435320202059253C17FF_2024-05-27_16-48-54

Is there a date and time setting somewhere to correct this?

[ThadHouse]

Double check your laptop time. Just like the roboRIO, Systemcore gets its time from the DS when the DS first connects. Otherwise that'd be a CTRE question of how they get time.

[cpapplefamily]

If I recall there was a BAT header on the main board when I did my teardown.

[Kevin-OConnor]

Yes, but I was referring more to a soft solution of writing the time to a file periodically which you read back from on boot. The current intent is that SystemCore will not ship with an RTC battery, so WPILib and other ecosystem tools need to work reasonably well without it. The header does give us the option of potentially allowing teams that care a lot about timestamping to install a Raspberry Pi RTC battery if they wanted to (rules all TBD): https://www.raspberrypi.com/products/rtc-battery/

[rzblue]

systemd-timesyncd implements this behavior- by default it will save the time to disk on NTP update, shutdown, and every 60s, and it will restore the time from disk at startup. The interval can be controlled with the SaveIntervalSec option in the timesyncd config file.

The docs indicate this is designed specifically for this scenario:

This is especially useful for offline systems with no local RTC, as it will guarantee that the system clock remains roughly monotonic across reboots.

[PeterJohnson]

Something else we could do is have mrccomm create a /tmp file (or similar memory backed filesystem) after it’s set the clock. That way other processes could pick up the change without having to link to a mrccomm library?

[ThadHouse]

I was gonna send it through the comms backdoor but that works too.

[cpapplefamily]

New Question: Who is creating the [can_S0_..., can_S1_...,, can_S2_...,, can_S3_...,, can_S4_...,] log files? These exhibit the same date time error.

[spacey-sooty]

What filetype? IIRC CTRE creates seperate logs for each canbus so I suspect its them

[cpapplefamily]

All the files are .hoot

[daltzctr]

We create a log for each bus. If you have no devices on this, I expect the size to be tiny. We're also improving the behavior for the next release so that they'll be in subfolders arranged by date, so less clutter.

[cpapplefamily]

@daltzctr I hope that there will be a way to change the name from S# to a user-defined name or allow the user to append a value to the name. This way it is simple to identify both the bus number and what devices may be on that network. *Well-labeled and defined clutter
IE

• can_S0_drivetrain
• can_S1_intake
• can_S2_arm
• can_S3_subsystem4
• can_S4_subsystem5