Does the LS-X1 have a battery?

[Riek]

Does the LS-X1 have a battery?
When I use the scheduled energy mode the date and time change to 1-1-2000. Resetting does not help. As long as the power stays on everything works correctly.

[As3nd0r]

No it doesn't. I saw this issue on an of old kirkwood unit I own. It resets to January 1st 2000 starting 1st January 2020. Setting a valid NTP seems to make it work but doesn't fix the root cause. Did not have time yet to look further into it though.

[1000001101000]

There is no battery in that sense, nothing replaceable. Different ARM-based models use different types of RTC which are either built into the SoC or are an additional chip but as far as I know none have an external battery.

Even if there is something wrong with the RTC I would expect NTP would set the time without there being a noticable problem (assuming the device has access to the internet). You should probably start by checking the NTP settings.

[Riek]

Thank you for your reactions.
The problem indeed started at the beginning of this year.
The device is not connected to the internet so setting a valid NTP won't help...

[As3nd0r]

You could run a NTP server locally and use that.

[Riek]

You could run a NTP server locally and use that.

I am afraid that I have no idea how to do that.
Just an average Windows user using this device for back-ups and little further knowledge..

[1000001101000]

I haven't found any info about which RTC is used in this device (and I don't have one to check). There are some reports in the news of some devices running into trouble in 2020 due to a y2k-like issue but I haven't found anything specific to RTC chips or kirkwood SoCs in a brief google search to indicate that is your problem.

I took a look at a few of my devices which are of that same era and older and all seem to be reporting reasonable values from their respective RTC's. If something is physically wrong with your RTC you might see an error if you connected via command line and ran something like

Code Select Expand

dmesg | grep -i rtc. If there is a physical problem with it there probably isn't a way to fix it.

If it's some sort of software problem it could be happening to other folks but they haven't noticed because NTP is correcting it for them automatically.

[Riek]

This is the result via the command line when running "dmesg | grep -i rtc".   I see no errors

riek@Linux:~$ dmesg | grep -i rtc
[    0.094965] RTC time: 19:43:50, date: 02/19/20
[    0.774412] rtc_cmos 00:03: RTC can wake from S4
[    0.774695] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[    0.774751] rtc0: alarms up to one month, 114 bytes nvram, hpet irqs
[    0.782896] Using IPI No-Shortcut mode
[    2.310102] rtc_cmos 00:03: setting system clock to 2020-02-19 19:43:52 UTC (1582141432)

[1000001101000]

That appears to show a working RTC setting the clock at startup, though rtc_cmos usually refers to a PC. Is this from the device or from your PC running Linux?

Either way, you can use this tool to run the same command on the device:
https://github.com/1000001101000/acp-commander

Code Select Expand

java -jar -t acp_commander.jar <ip address of device> -pw <admin password> -c "dmesg | grep -i rtc"

[As3nd0r]

I was looking into this a bit more and here is a LS-QVL as an example. pretty much the same thing with an LS-WVL - both switch to 2000

rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
rtc-mv rtc-mv: setting system clock to 2000-01-01 00:00:00 UTC (946684800)

So yes, there is a general issue. guessing the sys clock is updating it though once it gets the correct time from an NTP

root@LS-xxxxxxx:~# hwclock -r
Thu Feb 20 02:55:43 2020  0.000000 seconds

[1000001101000]

Interesting!

I should have been more specific in my previous post. I checked an LS-WXL and TS-XEL which are both kirkwood devices of a similar era to the LS-XL as far as I know. They are both running Debian 10 and their SoC based RTCs are returning reasonable values. I tried uninstalling NTP and unplugging the LS-WXL but it always seems to come up with the right time in Debian.

I suppose this could be an issue with the RTC driver used by the stock firmware, though I don't fully understand how that would work.

[Riek]

That appears to show a working RTC setting the clock at startup, though rtc_cmos usually refers to a PC. Is this from the device or from your PC running Linux?

Either way, you can use this tool to run the same command on the device:
https://github.com/1000001101000/acp-commander

Code Select Expand

java -jar -t acp_commander.jar <ip address of device> -pw <admin password> -c "dmesg | grep -i rtc"

This was run from a PC running linux.

However, your suggestions go a little to far for me to handle...

But thank you for your help!

[1000001101000]

It's an interesting issue. I think your only solution will be to connect the device in such a way that it has access to the internet so that it can rely on NTP.

[Riek]

Thanks.
My solution is to turn the energy saving mode off.
As long as the power stays on, the date/time works just fine.

[1000001101000]

That works too!