rpi4 as server?

Just out of curiosity, what significant benefits do you get from the RTC? I have NTP running on mine, and the only anomaly I notice is this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in any of the greppable log files.
--
so ladies, fish, and gentlemen, 
here's my angled dream
Reply to
Adam Funk
Loading thread data ...
1st January 1970 is the "start of time" in the Unix world, that's why the next "millenium bug" is somewhere about 68 years from 1970 when a signed 32-bit count of seconds runs out.
--
Chris Green
Reply to
Chris Green
I understand why that's the magic reset date (which is why I was grepping for "Jan" as well as "1970") --- I was just wondering about what kind of situation needs the external clock so the time is accurate *before* NTP starts working.
--
I heard that Hans Christian Andersen lifted the title for "The Little 
Mermaid" off a Red Lobster Menu.                       ---Bucky Katt
Reply to
Adam Funk
It rather depends on how long might elapse before reaching a time server, if there's any danger of that being a long time then a RTC is very helpful, if you're sure of a time server immediately after boot then it's pretty much useless.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
Don't forget that an old GPS unit, provided it has serial NMEA0183 output which many of them had, can be used by ntpd as a primary time reference. These can be connected to an RPI via a USB-serial adapter. There is a reference driver for ntpd that allows it to accept an NMEA0183 primary time stream.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
The classic ntpd does not like to sync with a time that is far off from the local time. I used ntpdate to set the local time before starting ntpd up.
--

-TV
Reply to
Tauno Voipio
My home server is a syslog server for other stuff - like the VDSL router and Wireless access points - so I like it to have a reasonably good time as soon into boot as possible, even if it has only booted a handfull of times in the last couple of years. Also if the house power goes, then when it comes back, the server will come back well before the router gets DSL sync and an internet connection - and it's time will be good until internet connectivity is resumed.
Several years ago we had several incidents where power would go (all our street) for 30 secs or so and then return. It turned out there was something dodgy under a road - and an especially heavy lorry in the wrong part of the road would cause problems. The road was up for quite a while as they fixed it.
Reply to
Jim Jackson
Yeah I used to do that, but ntpd now has the -g option to allow it do an initial time jump, so ntpdate is no longer needed.
Reply to
Jim Jackson
That makes sense --- thanks.
--
We know he [Larry Walters] broke some part of the Federal Aviation 
Act, and as soon as we decide which part it is, some type of charge 
 Click to see the full signature
Reply to
Adam Funk
That seems to be the default config on Raspbian; I just found the /etc/default/ntp file (which I've never edited) with just this line in it:
NTPD_OPTS='-g'
Thanks for pointing that out.
--
I love you like sin, but I won't be your pigeon
Reply to
Adam Funk
[]
[]
A board with GPS, PPS and real-time clock is available here:
formatting link
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
How long with a GPS unit take to get a time fix from cold, out of interest?
The OP's situation sounds like one where a RTC would be quicker than a cold GPS, although maybe there's a way to get a time out of GPS before it has seen enough satellites for a position fix.
(and can you do A-GPS by configuring the lat/long of your stationary Pi?)
Theo
Reply to
Theo
I think it'll know the time as soon as it receives a single frame (every 30 seconds) that's the number of 1.5 second "ticks" into the current week, weeks start at midnight.
But it might need to receive the full almanac (every 12.5 minutes) to know the date offset to UTC, because the week number rolls around every 1024 weeks.
Reply to
Andy Burns
That depends on the make, model, how good its view of the sky is and how long since it last had a fix. The older trekking units, e.g. Garmin GPS II, generally took 1-2 minutes to get a fix outdoors and didn't work indoors. The slightly more recent GPS-35, a puck with no controls or screen, was quite a lot faster and IIRC would get a fix if left on a south-facing window sill in the UK.
How long since last the last time a GPS had a fix matters because each receiver has a copy of the ephemeris, which contains orbital parameters and time adjustments for all the satellites in the GPS constellation. If this is out of date, the receiver can't get a fix until it has downloaded a fresh ephemeris. GPS satellites broadcast their ID and time every second and a new ephemeris rather less frequently. To get a fix the receiver needs to know the ID and time at each satellite. It looks up orbital details for the satellites it can hear in the ephemeris and from this and the broadcast time at each satellite it knows where it was when that satellite sent its last time message. This lets it work out times of flight for the signals and, from that, its distance from the satellite. Then it combines information about all the satellites to work out exactly where it is and what the exact time is at its location.
I'm certain thats true, particularly with an old GPS receiver.
Another caveat: I have a pair of old Garmin GPS II+ units, used originally for model aircraft tracking and later for full-size glider navigation, bought in 2001 and 2004. They still work because they have always had good AA cells in them. That's important for early GPS units, which used battery-backed RAM to store waypoints and, most importantly, the GPS epoch counter. The old Garmins used a soldered-in battery (2032 or similar) to keep the RAM active while you changed the AA cells, but if left for any time with AA cells removed, the coin cell will die and the RAM will be wiped and the epoch counter will be zeroed. However, none of these units have any ability to configure the epoch, so once that happens, the GPS receiver is bricked. My pair still work because having good batteries in them has kept the coin cell from being used except for a minute every 2 years or so when the AA cells get changed.
More recent receivers use non-volatile memory: these should still be usable but I don't know which specific makes or models these would be.
I also have a pair of PNAs (a Binatone and a Medion S3747) which run on Li-ion batteries and store vital data in non-volatile memory, both are used to run LK8000, a glider navigation and flight logging app. The Medion normally comes up from cold in about a minute. The Binatone was bought in around 2008 and the Medion in 2014.
However, when I suggested using a GPS as time source I was thinking that in at least some cases it may be better to treat the GPS receiver as its prime time source, particularly if the RPi isn't more or less constantly online to an internet time source.
Probably not - seeing that the GPS still needs to have current ephemeris data, which it picks up when a satellite it can see broadcasts it.
I'm only suggesting that using an old trekking or puck GPS is a good idea for somebody who already has one lurking, unused in a drawer.
Otherwise the obvious way to do it is to buy one of the RPi GPS expansion cards. Most of them seem to use uBlox GPS receivers, which appear to be well-regarded devices.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
You shouldn't see any 1970's on reboot. Raspian saves the current value of the clock every 15 minutes or so. When you reboot it uses this saved time until it gets updated from ntp.
You may notice the syslog doing this
1720 Some stuff happening # the last log entry before rebooting 1715 Rebooting # Reboot using last saved time ... 1715 Getting RTC 1722 More startup # The time has been updated ... 1723 Finished rebooting
The jumping of the time backwards and forwards can be a little confusing, but it is possible to work out what is happening.
The advantage of a real time clock chip is this is avoided and the reboot time will be more accurate.
I wouldn't use a GPS clock for reboot, as may take too long to give a reading, it is more suited to keeping accurate time once the machine is up and running - as long as it has a good view of the sky.
---drukc
Reply to
druck
I think Theo was only asking about a time fix, not a location fix.
Reply to
Andy Burns
It does not matter - time and coordinates are members of the same equation group which has to be solved to get any of the members.
The ephemerides data comes pretty slowly, it will take several minutes to get them if the receiver is out of date.
A decent net connection and NTP will get the time much faster.
--

-TV
Reply to
Tauno Voipio
(Not that I need something like this, but it's interesting.)
I don't think an old GPS unit would be able to get a signal in my "network cupboard", which is a shelf in the back of a wardrobe under the stairs from the 1st to 2nd floors, & not on an outside wall.
--
Let me tell you what I think of bicycling. I think it has done more to 
emancipate women than anything else in the world. I stand and rejoice 
 Click to see the full signature
Reply to
Adam Funk
Sure, but I don't think that affects a GPS receiver's startup process: it still needs the almanac data to determine the exact time: its location matters to it when correcting for signal travel time from satellite to receiver and, if any satellite clocks have been reset recently, what their UTC offset is now. If the receiver hasn't been run for a while it will need an updated almanac and, as Andy said, it may have to wait up to 12.5 minutes for this to be retransmitted.
If a GPS receiver is designed to be a time source, it will emit NMEA-0183 ZDA messages which only contain UTC date/time information, but equally there's no reason why the time recipient shouldn't accept NMEA-0183 message types RMC, GGA or GNS and discard everything except the time field because all these messages contain a UTC time stamp accurate to 10 mS.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
The older ones often don't work in a house, and sometimes not in a forest either, let alone under a tin roof. Modern receivers are much more sensitive. I've just fired two GPS receivers up to prove this point:
- My old (1990) Garmin GPS2+ had no signal at all in the sill of a South- facing window and had problems outside it as well, due mainly to the sky view being restricted by both the house behind me and (bare) trees on the other three sides. It did eventually find two satellites, but never determined where it was.
- My more recent (2014) Medion S3747 PNA got enough signal on the window sill to set its clock, but couldn't see enough satellites to determine its position. However, when it was taken outside to the same point as the GPS2+ it was able to determine its location and altitude after around 2 minutes.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.