Which devices have Battery backed RTC built in?

Not so easy to find in the standard specs of the hw.

I know for a fact that devices with the apm821xx target have built-in RTCs.

From the APM82181 CPU product sheet:

Standard Peripherals

  • On-chip real-time clock with external battery backup capability

Just keep in mind that a RTC without battery backup (and a battery inserted) isn't that useful, so it depends on the actual model if the vendor if they've fitted a battery holder. For most traditional routers the answer is probably no, for SBCs it might be more hit or miss.

1 Like

I agree. Routers aren't really designed to be too useful without power, and most have NTP Clients and/or Servers (i.e. OpenWRT).

An x86 board or other mini PC will defiantly have an RTC with battery or capacitor backup.

Turris omnia

1 Like

You might be able to get a USB RTC, for example: http://bastioninfotech.com/india/products/hardware-keys/rtc-real-time-clock-dongle-key.jsp

or

https://www.alibaba.com/showroom/usb-real-time-clock.html

Just a thought.

EDIT: or use a GPS receiver, depending on your application.

1 Like

GL.inet AR150 has an add on module for RTC

Most of the PC-Engines, like the ALIX, APU have a battery.
https://www.pcengines.ch/apu.htm

The question this all depends on is "How accurate and how fast do you need the time on your OpenWRT device?"

Typically, during boot, the clock is set to the latest file under /etc/ by /etc/rc.d/S00sysfixtime This is at least a "reasonable" time, and one that shouldn't result in "time going backwards" (assuming you're either using UTC, or ignoring the annual set-back of an hour for most time zones).

NTP should be within a few seconds of connectivity being established.

GPS, unless constantly powered, is unlikely to acquire lock faster than NTP can provide time. Unless the GPS unit is directly connected to a GPIO or similar pin and provides PPS outputs, by the time you get through the serial pathway (including delays in the serial-to-USB converters), it's not better than a few hundred milliseconds.

Is the RTC for purpose other than initial time set, or do you have some very strict requirements on time keeping during the first minute after boot?

2 Likes

Not all routers are internet connected. If you're running a LAN at a school in a developing country and connecting to say a local library... The whole net could be 25 PC's at two locations, and NTP free, in which case time never gets established...

Just some thoughts on one possible use case

Radio time signals, like DCF77 in central europe, are another option - but -like GPS- they'll need considerable time to receive and decode the time signal (~3 minutes).

1 Like

Initial time set.
I implemented your idea already, but I am looking at a better solution, because I consider it a bad hack:
The time adjustment happens at very end of all services in /etc/init.d
, which is not explainable to me, as it only depends upon network conn available.
Standard time adjustment is graceful, so it might take considerable time.
I hacked single shot time adjustment into the startup of the services, as soon as WAN up,
but again, it is a (bad) hack.
Usage case:
vpn wireguard. It needs time going forward to connect with peer.
But imagine a travel router, kept in storage for quite some time.

Good idea regarding the USB-clock. This looks reasonable.

Thanx, the AR150 looks reasonable, but on minimum of resources, otherwise. An APU a bit too expensive.

Just found http://ahsoftware.de/usb-rtc/ for some ideas. Then again, if you have access to spare GPIO in your router, that and a $5 eBay RTC board may not be more complicated. I haven't looked at Linux code for RTC, but it may not be too bad.

To get the time set relatively well initially couldn't you either install ntp-utils and force a sync during boot (would at least avoid too long of gradual sync), or grab some website that shows current time, or look at some http date time headers from a gstatic url or something? A piece of hardware seems overkillish for a travel router.

Not really a "bad hack", especially as, as I remember it, the reference NTPv4 implementation does a burst initial time set before switching over to its tracking PLL/FLL mode.

I don't understand why NTP isn't started as soon as the network is up either. That's pretty typical on desktop/server systems, especially as things like Kerberos requires a "good" time, which is required to mount certain network file systems.

Monotonically increasing or accurate?

If just the former, the "latest file timestamp" is likely sufficient.

Not definitive, but scanning through https://www.wireguard.com/papers/wireguard.pdf the requirement may come from

The responder keeps track of the greatest timestamp received per peer and discards packets containing timestamps less than or equal to it. (In fact, it does not even have to be an accurate timestamp; it simply must be a per-peer monotonically increasing 96-bit number.)

You are correct, of course. Sorry to have forgotten to ask for "Battery backed RTC".

Depending on your perspective on older HW the ALIX bds can be had for about $50 on ebay. I still use one as my main router (w/VPN server). 500mhz geode cpu w/ AES-ni (128 bit only) and 256MB ram. Runs on a CF card and there is (was?) an image specific for this. No wifi.

Thanx for mentioning it. In case, you still need some more ALIX, I have one or two in my stock of ancient hw :slight_smile:
I am looking for a rather cheap, (still) off-the-shelf device with ample resources, and RTC+battery,
for a commercial product, including wireguard vpn.
So far, only the AR150 matches, which I will definetely try, but thats at the very low end of available resources.