NTPd server using DVB-T as clocksource

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

NTPd server using DVB-T as clocksource

Lars Schotte
Hi folks,

SHORT VERSION:

someone knows anything about using DVB-T as a clocksource for NTPd?

SOME BACKGROUND:

currently I am syncing my (OpenBSD)router's clock over NTP and this is
then the NTP server for the whole network. Of course this has a little
disadvantage that router being EdgeRouterLite loosing time on load,
however this does not happen often, so this is not a big problem as
long as I keep syncing the clock to some outside reliable clocksource.
EdgeRouterLites also do not have any hardware clock too, so I need to
sync clock anyway. The question is only to what.

Now as you see on my signature in the bottom I am in Slovakia and I
have here a DSL connection (Orange/FranceTelecom) which does IPv6 by
using DS_Lite. So I have to set up a tunnel in order to get IPv4
connectivity. But that takes some time at bootup and also the tunnel
adds latency, to cut the story short, I do not like doing NTP over IPv4.

Now here in Slovakia and also in CzechRepublic we do not have IPv6
capable NTP pool servers around, the nearest ones I found are located
in Austria, which is totally fine, because that may be even
geographically shorter path than somewhere else in SVK or CZ.
But those austrian NTP servers that can do IPv6 are not very reliable.

Here my current ntpctl -s all (OpenBSD):
6/7 peers valid, constraint offset 48s, clock unsynced, clock offset is
6997.501ms

peer
   wt tl st  next  poll          offset       delay      jitter
2001:628:21f0:80::80:160
    1 10  2    1s   34s         1.004ms    22.677ms     0.562ms
2001:628:21f0:80::80:35
    1 10  2    1s   30s         1.035ms    22.014ms     5.184ms
2001:938:1337:d1::53:c
    1 10  4   12s   32s         0.393ms    26.575ms     8.611ms
2001:938:1337:a2::53:c
    1 10  3   17s   32s        -1.066ms    28.812ms    21.493ms
2001:938:1337:d3::53:c
    1  2  -  272s  300s             ---- peer not valid ----
2001:62a:4:311::123
    1 10  1   30s   32s         2.353ms    22.303ms     2.170ms
2001:628:2030:dcf1::123
    1 10  1   21s   34s        -1.854ms    28.456ms    20.760ms

OK, that offset by 7 seconds does not happen normally, no idea why it
happened now, whatever. Network servers look fine though.

Now, I do not like all this, that's why I ordered
vk-172 gmouse g-mouse USB GPS/GLONASS USB over amazon
and hope I can use that in combination with some Raspberry PI as NTPd
clocksource, as I saw some ppl doing.

But that is only one clocksource, multiple would be preferrable.
I have some DVB-T adapter lying around that can also be used as a
clocksource, since those old DVB-T adapters are not good for TV anymore
since ppl are sending DVB-T2, there is still for the forseeable
future enough frequencies that will be still old DVB-T and those have
time signal in them that can be used SOMEHOW.

Of course there is always the fallback to having a cronjob run like
every hour and having it do "dvbdate --force --set". But that is not as
good as syncing NTPd directly to DVB-Ts signal.

I have no idea how this could be implemented, but I saw some examples
of how this GPS thing works on:
https://esp8266hints.wordpress.com/2017/02/09/a-neat-toy-but-not-an-esp/

That's where I got the idea from to get my own GPS dongle.
It looks like it opens some kind of virtual console where it puts the
current date in and NTPd reads it from there. So I suppose one would
need to open up some kind of socket and sending there DVB-T timestamps.

No idea. What do you ppl say?


--
 Lars Schotte
 Mudroňova 13
92101 Piešťany

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NTPd server using DVB-T as clocksource

Chris Cappuccio
Lars Schotte [[hidden email]] wrote:

>
> Now, I do not like all this, that's why I ordered
> vk-172 gmouse g-mouse USB GPS/GLONASS USB over amazon
> and hope I can use that in combination with some Raspberry PI as NTPd
> clocksource, as I saw some ppl doing.
>
> But that is only one clocksource, multiple would be preferrable.
> I have some DVB-T adapter lying around that can also be used as a
> clocksource, since those old DVB-T adapters are not good for TV anymore
> since ppl are sending DVB-T2, there is still for the forseeable
> future enough frequencies that will be still old DVB-T and those have
> time signal in them that can be used SOMEHOW.
>

In OpenBSD, you would write a kernel USB driver that sets up the DVB-T
adapter to receive the appropriate signal and decode it. But the DVB
decoding might be too involved for what should be a small kernel driver.
Maybe you can hack the dvbdate utility into a source of NMEA 0183 data
to be opened as a socket from ntpd.

Chris

Reply | Threaded
Open this post in threaded view
|

Re: NTPd server using DVB-T as clocksource

Lars Schotte
Well, I know that OpenBSD currently has no support for DVB-T but Linux
does, so I would run that RaspberryPi with Linux. However, the question
would be how to pair its output with OpenNTPd or NTPd.

On Sun, 28 Oct 2018 14:22:54 -0700
Chris Cappuccio <[hidden email]> wrote:
>
> In OpenBSD, you would write a kernel USB driver that sets up the DVB-T
> adapter to receive the appropriate signal and decode it. But the DVB
> decoding might be too involved for what should be a small kernel
> driver. Maybe you can hack the dvbdate utility into a source of NMEA
> 0183 data to be opened as a socket from ntpd.
>
> Chris
>



--
 Lars Schotte
 Mudroňova 13
92101 Piešťany

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NTPd server using DVB-T as clocksource

Chris Cappuccio
Lars Schotte [[hidden email]] wrote:
> Well, I know that OpenBSD currently has no support for DVB-T but Linux
> does, so I would run that RaspberryPi with Linux. However, the question
> would be how to pair its output with OpenNTPd or NTPd.
>

OpenBSD actually does support some of the ugen userland based decovers for
the R820T, as well as the RPi3.

In any event if the target is OpenNTPd, formatting the data as NMEA 0183
would be appropriate.