Sadly, that is not a constant and depends largely on te recieving equipments buffers
I listen to internet radio via two software identical computers. The sound has a different delay on each
Sadly, that is not a constant and depends largely on te recieving equipments buffers
I listen to internet radio via two software identical computers. The sound has a different delay on each
-- New Socialism consists essentially in being seen to have your heart in the right place whilst your head is in the clouds and your hand is in
What is the point when both VHF FM and DAB have the time transmitted all the time and displayed on the radio. I would think both of these are quite accurate enough for most people most of the time.
Anyone needing precision time is going to be using something else.
I don't have any radio that can display the time, even if it is transmitted as part of RDS. My car radio is the only one that can handle RDS, and that doesn't set the car's clock - you always have to set it manually , and there isn't even a "0 or +1 hour" GMT/BST setting to keep the minutes and seconds the same and only change the hour. I *think* my wife's Honda (dating from
2015) also needs to have the time and daylight savings set manually and it doesn't set/correct it from the FM RDS or the DAB radio.The only radios I have are a tuner from a stereo system I bought in 1986, and my wife's all-in-one music centre that is probably from the 1990s. I use to have a little clock radio (AM/FM) but it was fairly primitive: manual needle-on-a-dial tuning and no presets, so there was a great disincentive to change it from the station that I'd spent ages adjusting to optimum tuning. If I want to listen to / record from from the radio, I tend to use the 7xx channels on Freeview, or the Freesat equivalents. I don't know how the quality (eg bitrate) and error-correction of Freeview/Freesat compare with DAB.
There's (at least) two problems:
- time differences with other transmission media. For example lower lag on FM against DAB. Should FM be delayed to match? That becomes problematic when you have multiple sources, for example two radios in different rooms.
- time difference against other media the broadcaster doesn't control. For example people next door cheering when a goal is scored, which your feed hasn't got to yet. Maybe they're watching the match on a different channel to yours, which your broadcaster can't delay. In that case they can't have the goal scored two seconds early to compensate.
Internet streaming is difficult as the stream will wait to fill up its buffer before it starts, and that time depends on the speed of your connection. At least DAB and DVB don't suffer from that.
It might be feasible to do something like rate-adaptive buffering - for example start the stream at a low resolution while you're buffering in the background, and then upgrade the resolution when there's enough buffered. I don't know if anyone does that already.
Theo
On Wed, 21 Jul 2021 12:45:39 +0100, "NY" declaimed the following:
At least all of my vehicle clocks have separate HH and MM settings, so one can cycle the hour without touching the minute.
I have an old Sangean general coverage receiver (ATS-909X) which can decode the text piggy-backed onto a standard FM signal. Don't think that has time encoded, but if it did, it still wouldn't set the radio's clock (which is a bit of pain to set -- I think it keeps UTC separate from local time-zone, or one has to set it in UTC and then toggle to local, or maybe set in local then toggle to UTC...)
With the discontinuation of most analog short wave broadcasts, there aren't many general coverage receivers left unless one purchases a full up amateur HF transceiver. I've still got a Kenwood R-5000 (early 80s top-end general coverage receiver with filters for AM/SSB-W/SSB-N/Morse -- which the Sangean doesn't have; just AM/SSB). The R-5000 even had a special noise blanker for the Russian Woodpecker (which was abandoned after Chernobyl went up -- It was located near the reactor, and drew most of its power).
If one needs accurate time on an R-Pi, either a network connection to NTP servers, a battery-backed RTC module (though those do tend to lose a bit of time and need to be resynced to another time source at periods), or a GPS time source.
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
That's the sort of thing that DASH and HLS are capable of, whether [m]any services start low and adapt upwards, rather than starting with high quality and adapting downwards, I don't know, you could snoop a few streaming sessions I suppose ...
My Pi's are connected to my LAN, so they get the benefit of NTP resyncs every so often. The problem comes when a Pi reboots and then can't see the LAN for a while - eg because everything has come back after a power cut and the router is taking ages to connect to the internet. In that case, the Pi can be running for a significant period of time with a slightly-wrong time.
I notice this on the Pi which logs data from my weather station: I've seen occasions when the graphs of temperature, wind speed etc have a section which goes back in time and then suddenly jumps forwards in time again once NTP can reset the clock to the correct time. Usually the temporary error is only 30 minutes or so - enough to create an "interesting" blip (*) but not enough to go back to before the beginning of the graph (I plot the last 48 hours' data).
What is the accuracy of the clock on the Pi if it initially syncs with an NTP source but then loses network contact while remaining booted up? What is the default resync period for Raspberry PiOS - is it every 24 hours or is it more/less frequent that that? My old (Windows 7) laptop had a very poor RTC which lost a lot of time - several minutes over the default resync time of Windows - so I found the registry keys to make it resync more frequently - probably once per day. My new Windows 10 laptop never seems to be out by more than a few seconds, so either its RTC is more accurate or it resyncs more often.
(*) We're used to see discontinuities on the y axis of a value-versus-time graph, but a discontinuity on the x axis caused by the time setting itself to a silly value and then righting itself, is not something that we're used to seeing.
Lots of good suggestions here: scroll down for suggestions that work with systemd installed.
IIRC I have mine set up to run ntpd and referencing europe.pool.ntp.org, oceania.pool.ntp.org and my house server, which is on a short runtime UPS (long enough for a clean shutdown) and also runs ntpd, so regardless of whether my external link is up, the RPi and assorted laptops should be able to get a valid time at boottime.
If that's not enough, you can always attach a GPS receiver and/or a receiver for one of the broadcast time signals to something on your LAN. ntpd is capable of accepting time from any GPS receiver with NMEA output. See docs in /usr/share/doc/ntp for more detail.
If you want to build a receiver for the 'Rugby' RF time service, look here
There's also some good stuff here:
-- Martin | martin at Gregorie | gregorie dot org
On Wed, 21 Jul 2021 19:53:49 +0100, "NY" declaimed the following:
Power failure -- could corrupt the R-Pi uSD card.
Normally (I believe), a clean shutdown writes the current time to a file which gets loaded on start-up; otherwise it somehow loads the last file change time on the system.
Seems RaspiOS is using systemd-timesyncd rather than plain ntp(d).
md_admin@microdiversity:~$ sudo systemctl status systemd-timesyncd ? systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enable Drop-In: /lib/systemd/system/systemd-timesyncd.service.d +-disable-with-time-daemon.conf Active: active (running) since Thu 2021-04-29 10:27:25 EDT; 2 months 22 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 16297 (systemd-timesyn) Status: "Synchronized to time server for the first time
209.51.161.238:123 (0.debian.pool.ntp Tasks: 2 (limit: 2065) CGroup: /system.slice/systemd-timesyncd.service +-16297 /lib/systemd/systemd-timesyncdWarning: Journal has been rotated since unit was started. Log output is incomplete or unavailabl md_admin@microdiversity:~$
md_admin@microdiversity:~$ timedatectl Local time: Wed 2021-07-21 16:30:48 EDT Universal time: Wed 2021-07-21 20:30:48 UTC RTC time: n/a Time zone: America/Detroit (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: no md_admin@microdiversity:~$
md_admin@microdiversity:~$ timedatectl show-timesync FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org
2.debian.pool.ntp.org 3.debian.pool.ntp.org ServerName=0.debian.pool.ntp.org ServerAddress=209.51.161.238 RootDistanceMaxUSec=5s PollIntervalMinUSec=32s PollIntervalMaxUSec=34min 8s PollIntervalUSec=34min 8s NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-23, RootDelay=62.118ms, RootDispersion=2.975ms, Reference=7F43715C, OriginateTimestamp=Wed 2021-07-21 16:12:28 EDT, ReceiveTimestamp=Wed 2021-07-21 16:12:28 EDT, TransmitTimestamp=Wed 2021-07-21 16:12:28 EDT, DestinationTimestamp=Wed 2021-07-21 16:12:28 EDT, Ignored=no PacketCount=3519, Jitter=2.608ms } Frequency=-59929 md_admin@microdiversity:~$If I read that, this R-Pi runs a time sync every 34 minutes (which could explain your ~30 history, if the power fails at say, 4 minutes before the next sync, it initially loads a 30 minute old timestamp.
md_admin@microdiversity:~$ timedatectl timesync-status Server: 209.51.161.238 (0.debian.pool.ntp.org) Poll interval: 34min 8s (min: 32s; max 34min 8s) Leap: normal Version: 4 Stratum: 2 Reference: 7F43715C Precision: 1us (-23) Root distance: 34.034ms (max: 5s) Offset: +297us Delay: 37.769ms Jitter: 2.608ms Packet count: 3519 Frequency: -0.914ppm md_admin@microdiversity:~$
Windows XP, and maybe 7, defaulted to once-a-week time sync. Actually,
My system seemed to be set for 9 hours... Just changed the value to 6 hours, to take effect next reboot.
My Win7 laptop, when used (it's set up for PSK31, FT8, etc. digital modes on Amateur Radio -- and FT8 needs very precise timing since even a 2 second time error can result is losing the start of a packet), is running
ntp-4.2.8p14-win32-setup.exe
Looks like there may be an update...
If you need really precise NTP updates, this is the option to install on Windows. Meingberg builds the installers using the source code the NTP organization releases
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
I would recommend installing NTP which appears to be missing from the recent RPi OS releases.
A decent RTC is here (plus GPS module) and I measured this as about 2ppm, so a fraction of a second per day.
You can install NTP on Windows as well which can easily give sub-second accuracy. I have some old notes here:
-- Cheers, David
That's because of the switch to systemd. An ntp (-like?) service is still installed. Its interface is "timedatectl" which gives a status overview. See man timedatectl.
It seems to sync often enough by itself that my Pi4 (without an rtc) which is always on and which I don't monitor is accurate to within about a second compared manually to this iOS device from which I just logged in. So, I don't think it's a good idea to install the ntp service on top of that; not without first disabling this new stuff.
The whole point is that OP is doing that, but on boot, sync to get a valid time is overtaken by other stuff starting (and getting the wrong time).
Check timedatectl (a systemd service)
-- Chris Elvidge England
Or even generate the pips in the DAB radio, rather than at the studio :)
It would also be handy when you've got several radios in different rooms of the house, all playing the same station.
But it's water under the bridge now, sadly. The decoding delay isn't standardised, as someone else has alredy said.
John
Write a script that runs early in the boot process and looks for a response (ping?) from 8.8.8.8 - once a response is received allow the boot process and subsequent time sync to proceed. So in effect it waits for the home router to become ready.
Alternatively build your own NTP server using a cheap GPS board and another Pi, or buy a battery backed clock board for the original Pi in question.
It may not be installed if you've had your RPI for some time and have done in-situ upgrades as successive Raspbian versions have been released.
I have an early Pi 2B (the 512MB version) successively upgraded from Wheezy to Buster. It does not have the timedatectl service installed.
-- Martin | martin at Gregorie | gregorie dot org
systemd-timesyncd.service and/or systemd-timedated.service?
-- Chris Elvidge England
A "sudo apt-get install ntp" fixes the lack of NTP on all my RPi cards. No problems at all even with the latest OS. Personally I prefer to trust the reference NTP version rather than some other version, and it has the advantage that I can manage it in the same way as NTP on Windows and other Linux systems.
Here I see accuracies well under a millisecond even when syncing over Wi-Fi - e.g. a Raspberry Pi 400:
and when you activate the GPS/PPS option, well under 10 microseconds even with a Raspberry Pi 1B:
Here's a Raspberry Pi 4 with the Uputronics GPS/PPS/RTC HAT:
The antenna is a mag mount puck, indoors, on top of some mains trunking. Something like that can be your stratum-1 source so many local clients.
I'm comparing file timestamps with another system in the Netherlands and having sub-second accuracy makes the comparison much more certain. I appreciate that your requirements may be less stringent, but you can have a lot of fun with NTP and GPS!
-- Cheers, David
Thanks, Bob. Perhaps simply delay the other stuff by 30 seconds or so might be a simple solution?
-- Cheers, David
Indeed. I thought systemd was supposed to solve all that (hollow laugh, glad I don't have to use it).
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.