Så fik jeg endeligt mit radiour, en DCF77 C51 fra Meinberg Funkuhren. Det meste af opsætningen havde jeg lavet på forhånd ud fra dokumentation på internettet (PDF). Selve tilslutningen af radiouret er enkel. Der følger strømkabel og antenne med og de to ting skal blot tilstuttes. Der skal også bruges et serielt kabel, RS232 25/9-polet. Sådan et havde jeg på forhånd.
Når uret er sluttet til skal antennen rettes ind. Den aflange firkantede antenne skal placeres vinkelret på sigtelinjen til senderen ved Frankfurt am Main. Dette viste sig ikke at være så nemt. Ved justeringen af antennen skal man holde øje med to af de lysdioder, der viser status for C51. En rød LED lyser når modtageren ikk er synkroniseret med radiosignalet og den LED, der er mærket modulation skal blinke en gang i sekundet. Endelig er der også en indikator for feltstyrken. Denne skulle være meget svag når antennen vender forkert, men jeg så ingen tydelig forskel. Efter flere timers prøven sig frem fik jeg et nogenlunde signal og det lykkedes at synkronisere, så den røde LED slukkede. Det holdt dog ikke længe og forbindelsen kommer og går. Måske er der torden et sted på vej mod Frankfur og det ødelægger modtagelsen? Det stormer i hvrt tilfælde meget her.
Her er en beskrivelse af, hvad jeg har gjort. Det virker ikke endnu.
Der er installeret Gentoo-Linux på den computer, der skal fungere som tidsserver. De tilretninger, der skal laves er ret uafhængige af, hvilken linuxdistribution, der bruges. Andre styresystemer som FreeBSD skal sættes lidt anderledes op. Der er tre ting, der skal tilrettets: Den serielle port, et ekstra link i /dev-mappen og endelig skal ntpd-programmet sættes op. Parametre til den serielle port indstilles med programmet setserial. Som minimum skal hastigheden indstilles til 9600 bps. Det kan midlertidigt klares med
setserial /dev/ttyS0 baud_base 9600
For at lave en permanent ændring skal der ændres i opsætningsfilen /etc/serial.conf. Jeg tilføjede følgende linje:
/dev/ttyS0 uart 8250 port 0x3f8 irq 4 low_latency baud_base 9600
UART'en er sat til 8250 som er en type med en en–bytes buffer så tidskoderne ikke bliver gemt for længe. Desuden har jeg tilføjet low_latency for at minimere forsinkelser. Prisen er, at der bliver brugt mere CPU-tid.
Hvis man bruger statiske filer i /dev er det tilstækkeligt at sende følgende afsted en enkelt gang:
cd /dev ; ln -s ttyS0 refclock-0
Hvis man bruger udev skal man tilføje følgende regel efter reglerne for serielporten:
KERNEL=="ttyS0" SYMLINK="refclock-0"
Endelig skal indstillingerne for ntpd rettes. Som udgangspunkt er der ikke understøttelse af radioure. Med Gentoo skal man tilføje USE=parseclocks. Med andre linuxdistributioner kan det være nødvendigt, at compilere og installere programmet manuelt. Der skal tilføjes følgende linje til /etc/ntp.conf:
server 127.127.8.0 mode 2 maxpoll 7 # Maxpoll holdes nede for at sikre, at tiden korriges tit nok.
I morges var der tilsyneladende et fint signal, men ikke længe nok til at, det kunne bruges. Jeg havde tænkt mig, at forlænge antennekablet med et coax-kabel, men mit gamle BNC-netværksudstyr er vist smidt ud. Et par meter skærmet kabel i nærheden af computerne ville ellers have været en god ide.
Efter lidt antennejustering fik jeg et fint signal sent om aftenen. Uret har været synkroniseret i mange minutter. Det bliver nok ikke bedre. NTP brokker sig over manglende signal, men den serielle port er blevet opdaget af linux. Muligvis skal der bruges et "nul-modem-kabel". Sådan et kabel blev ellers mest brugt til at forbinde computere før ethernet blev allemandseje.
Efter at have sendt et spørgsmål om opsætninen af DCF77 C51 på Time-Nuts postlisten fil jeg svar fra selveste Poul er jeg begyndt at bruge programmet minicom til test af systemet. Jeg fik også det forslag at skulle tjekke de indbyggede kontakter for at se om de var sat som forventet. Det var de. Andet ville også være underligt nu det er en ny enhed.
I dag kom der et svar fra Meinberg om den serielle forbindelse. Hardwarebaseret flowkontrol må ikke være aktivt. Der blev også henvist til diagrammet over den serielle forbindelse. Der var også et forslag om en test af forbindelsen ved hjælp af et modemprogram. Det ville jeg prøve senere.
Svaret sendte jeg videre til Time-Nuts og "tidstosserne" kunne give flere vigtige detaljer. Diagrammet over seriel-stikket på DCF77 C51 svarer ikke til den sædvanlige beskrivelse af RS-232. Selv når man ser bort fra det, er ikke en modemforbindelse. Pin 2 og 3 skal krydses men det er ikke standard for et modem. RTS/CTS og DSR/DTR skal også krydses. James Miller foreslog at jeg fik fat i et voltmeter og målte efter, hvilke signaler, der kom hvor. :-)
Efter nogen søgen efter passende kabler på nettet har jeg fundet ud af, at der muligvis skal bruges et kabel til en seriel printer(!) fra længe før USB blev opfundet.
Den seneste justering af antennen har vist sig at være rigtig god. Tricket var at lægge et stykke papir over statuslamperne så lysstyrken for feltstyrkeelampen svingede mellem synlig og næsten usynlig i stedet for mellem meget kraftig og kraftig.
Så fandt jeg endelig et dansk firma, der kunne sælge mig et serielt printerkabel. Det endte med GetMore.dk. Leveringstiden er kun 9-10 dage ... For mere almindelige ting er leveringstiderne nede på 2-3 dage står der på hjemmesiden.
Så fil jeg mit kabel leveret lige til døren. Det med de 10 dage var lidt optimistiskt. Nu venter jeg bare på, at naboerne slukker deres fjernsyn, så jeg kan se om det virker. På kabekpakken står, at det er et null-moden-kabel, så det skulle være i orden.
I dag modtog jeg en null-modem adapter, så nu har jeg lidt, at eksperimentere med. Uheldigvis er er årlige moddtageforhold, så jeg kan ikke lave en god test. det lader til alle vil sidde længe oppe for at se TV i aften.
Nu har jeg sat radiouret til via adapteren. Måske er det bedre. Det serielle kabel er i det mindste kortere.
Jeg har kontrolleret følgende igen: Der er en driver til den serielle port i kernen og UART'en bliver opdaget ved start af systemet. Der er et link /dev/refclock-0 til /dev/ttyS0. Jeg regner med, at det er port 0, der er ført ud af maskinen. For at kontrollere, at der er drivere med i ntpd og de virker har jeg konfigureret PC'ens ur som referencetidskilde og det virker. Stratum er ændret til 12, så maskinen ikke begynder at sende sin egen tid ud på Internettet.
Clockstats er aktiveret men uden resultat. Der skrives tilsyneladende ikke statistik for et referenceur, hvis det ikke er i brug. Maskinens eget ur er ikke længere sat op som referenceur. Jeg regner med, at jeg ikke har sluppet forkert tid ud på 'nettet.
I dag har jeg anmodet om hjælp i nyhedsgruppen comp.protocols.time.ntp og har fået et godt skub i den rigtige retning. Det er faktisk et ganske almindeligt modemkabel, der skal bruges. En del af forvirringen kommer af, at signalerne sendes ud på ben med forskellige numre alt efter om det er et 9- eller 25-polet stik. De dyre langvarige kabelkøb var altså spildt.
Selvom der ikke er forskel når man bruger ntpq -p for at se status, er der forskel når man bruger ntpq -c clocklist.
I aften fandt jeg et andet modemkabel i gemmerne efter at have overvejet at købe endnu et kabel. Det virkede! Pludselig var der hul igennem. Der er dog en del støj. Jeg prøvede så at forbedre situationen ved at sæ tte den serielle port op på en anden måde, men det virkede ikke. Standardinstillinger lader til at være vejen frem.
Stratum er fusket (fudge) til 5 så ntpd ikke bruger uret. Jeg vil samle statistik op over nogle nætter og finde gennemsnitsforsinkelsen fra Frankfurt.
Jeg har opdateret NTP-wikien med flere detaljer om DCF77 C51. Specielt er brugen af et modemkabel skåret ud i pap.
Målinger af forsinlkelsen til radiouret er meget svingende. To døgns målinger gav gennemsnitlige gorsinkelser på 7 og 10 ms.
Data til beregningerne kommer fra peerstats. Filen er filtreret med grep så der kun bruges data fra radiouret og kun nå status viser, at uret modtager tidskoder.
Efter at have gravet lidt i NTP-dokumentationen har jeg fundet ud af, at kalibrering af referenceure kan ske automatisk. Det skal afprøves. Lidt mere læsning afslører, at man skal vælge et ur, som de andre ure skal rette sig ind efter. Det er nok ikke sø smart i denne sammenhæng.
Regnearksprogrammet lader også til at have problemer med alle de data, jeg hælder i. Det undrer mig noget. Jeg prøver med en forsinkelse på 4 ms.
Hovsa! parameteren time1 til justering af referenveuret er i sekunder og ikke milisekunder. ntpd tager det for pålydende selvom der er fire andre servere, der fortæller at klokken er noget helt andet. Jeg har sat stratum til 5 for at undgå ulykker. når ntpd har stabiliseret sig igen vil jeg se om 4 var et godt bud.
Tingene har stabiliseret sig og afstanden til radiouret er ca. 12 ms. De 10 ms skal åbenvart med. En grov udmåling på et kort viser, at Frankfurt er ca. 600 km væk, så med 1 ms forsinkelse pr 300 km (lyshastighed) skulle 12 ms som offset være det optimale.
Den kunstigt høje stratum er fjernet.
2 ms tilføjet offset er ikke sagen. Prøver med 3 ms - ud over de 10, der er som standard.
Der er justeret den gale vej. Serveren ser ud til at være foran når radiouret tages i brug. Prøver med 12 igen. Måske er det optimale mindre end 12. Når radiouret ikk er i brug, er serveren en anelse foran. Når uret bruges, er serveren et par ms bagud.
Lige erfter radiouret havde fået god kontakt, var der næsten 8 ms forskel i tiden ifølge radioruret og serverne. Der ser stadig ud til at være ca. 2 ms forskel. Standardforsinkelsen på 10 ms begynder at se lovende ud. Det er bare lidt for meget af et sammentræf til at jeg vil tro på det.
De seneste tre dage har jeg haft DCF77-antennen flyttet til en diskret plads på en hylde i stedet for den sædvanlige plads nær et vindue. Det har vist sig at være en rigtig dårlig ide. Der er tilsyneladende ikke et tydeligt signal ret tit.
Efter at have brugt et onlineværktøj har jeg fundet ud af, at min C51 er ca. 3 ms bagud. Det vil sige, at der er kompenseret for meget for afstanden til senderen. 9 ms er et godt bud på den rigtige korrektion.
Der er noget med fortegn. Afstanden (offset) blev vist som -3.xxx ms men det betyder, der der mangler 3 ms i korrektion. 15 ms virker som et bedre bud, men jeg vil lige set effekten over et par døgn.
Det har også vist sig, at serverens tid når at drive ret langt uden radiouret. For at spare serverressourcer er poll-intervallet sat til 2048 s i stedet for standardværdien på 1024 s. Det retter jeg også. Poll-intervallet stabiliserede sig i øvrigt ved 1024 s når der var signal til radiouret.
I dag eksperimenterede jeg med BSD, hvilket skulle være ret vanedannende. NTP virkede ret ustabil, så jeg fandt ud af, at der tilsyneladende ikke blev gemt oplysninger om frekvensfejl på tværs af genstarter. Det fik jeg rettet, men det tog ret lang tid før frekvensfejlen var beregmnet. Selv med en kendt afvigelse steg poll-intervallet ikke over 128 bortset fra små udflugter til 512. Det virker lidt underligt når der er adgang til en stratum-1 server.
Der har været signal til radiouret 50% af tiden siden seneste genstart af ntpd. Afstanden i tid til radiosenderen varierer over døgnet og uret ser ud til stadig at være lidt bagud – set over et par dage.
I dag har jeg lavet en tidlig morgentest. Der er et fint radiosignal til min C51 og offset ser ud til at være ok når jeg tester online. Statistikken fra "poolen" ser rigtig fin ud. Det gennemsnitlige offset er på 0,1 ms. Denne statistik er forurenet af data fra de tidspunkter, hvor der ikke er radioforbindelse, men alt i alt klarer tidsserveren sig fint. Der er dog en tendens til at radiouret passer om natten men ikke om dagen, så måske skal det korrigeres lidt mere. Udsvingene er på omkring 10 ms over et døgn, så det ser ud til, at jeg må vælge et tidspunkt, hvor serveren skal give den rette tid.
Jeg har sat korrektionen op til 18 ms. Når der er radioforbindelse, bliver ntpd hurtlig klar til brug. Det lader til at radiourets tid tages for pålydende med det samme.
Jeg har aktiveret low_latency for serielporten. Det skulle give mindre støj på linjen. Jeg har ikke rettet den permanente opsætning.
Offset er sat til 12 ms efter low_latency optimeringen.
Offset er nu sat til 12,5 efter jeg afprøvede 11,5 et døgns tid. Målt i forhold til servere på nettet svinger DCF-signalets offset i løbet af dagen.
Som et eksperiment har jeg sat typen for den serielle port til 8250. Det giver muligvis mindre forsinkelse i signalet, da 8250-chippen ikke har en stor buffer. Umiddelbart er radiouret nu 7 ms foran. 3 ms lader til at være tæt på det rigtige.
3 ms var ikke helt optimalt. 2,5 ms er for lidt, så nu prøver jeg med 3,5 ms. Med 2.5 ms passer uret fint når der er forbindelse om dagen, men om natten passer det ikke så godt.
Forsinkelse på 3.5 ms lader til at være god. Når jeg sammenligner tiden med andre servere er det nærmest det samme om radiouret er med eller ej.
I dag begynder jeg at bruge BOINC på tidsserveren igen. Gad vide om det giver en masse rod?
Belastningen af systemet lader ikke til at give problemer. Computerens frekvensfejl har ændret sig lidt. Det har til gengæld vist sig, at radiouret kun får et godt signal omkring 30% af tiden og ikke 40.
offset er rettet fra 0,0035 til 0,0025. Det ser ud til at passe bedre. Måske er det den større belastning, der gør det.
Med lidt hjælp fra nyhedsgruppen har jeg fået statistik-programmerne til at virke. De forudsætter, at der bruges punktum og ikke komma som decimaltegn. Løsningen viste sig at være, at bruge en komando i stil med:
LANG=C awk -f peer.awk /var/log/ntp-stats/peer*
LANG=C awk -f loop.awk /var/log/ntp-stats/loop*
Radiouret lader til at være 0,6 ms foran. Jeg stiller uret 0,5 ms tilbage. Samlet korrektion er nu 2 ms.
Det lader til, at radiouret nu går 0,3 ms forkert. Et forslag i nyhedsgruppen var at markere radiouret med noselect, så det ikke påvirker serverens tid. Det har jeg netop rettet. Jeg har netop korrigeret for de 0.3 ms. Systemet får mere tid med noselect.
Efter en dags målinger ser det statdig ud til, at jeg har ramt rigtigt, så radiouret kan nu vælges igen. Den endelige justering er 0,00197.
Justeringen var ikke god nok. Den gennemsnitlige fejl er nu på 0,4 ms. Begynder på ny måling med moselect men ingen justering. Det skulle give et resultat, der kan bruges direkte.
Fejlen lader til at have stabiliseret sig ved 8 ms. Jeg har rettet opsætningen af ntpd, men bruger stadig noselect for at se om justeringen er god.
Årsagen til det mystiske resultat af at bruge statistikken til justering er, at time1 som bestemmer korrektionen som udgangspunkt er 10 ms, så, hvis man ikke manuelt sætter den til 0, bliver resultatet 10 ms forkert!
Et nyt testforløb er i gang!
Jeg blev nød til at genstarte ntpd, så jeg har taget en ny fudge-værdi i brug: 2,18 ms. testen er meget kortvarig, så jeg må nok lave den om.
Alle hgennemsnit gik mod nul, og der er ikke en klar trend. Det er en nødvendighed at bruge noselect for at lave brugbare målinger. Derfor starter jeg et nyt eksperiment. Det skal løbe i mindst en uge.
Den gennemsnitlige fejl på radiouret er ca. 2.4 ms. Det varierer stadig når der kommer nye data til. Den tidsmæssige afstand til senderen variere i løbet af et døgn og det varierer, hvornår DCF77-signalet går igennem.
Den 25. skete noget mærkeligt med ntpd. Det er muligvis på grund af pludseligt varmt vejr. Derfor har jeg valgt kun at bruge statistik til den 24. som basis for beregning af fudge. Det endte med 2.31 ms.
Den seneste justering virker rigtigt godt. Når jeg har sammenlignet serverens tid med andre tidsserveres tid har forskellen ofte været under et milisekund.
I dag valgte jeg at genstarte min tidsserver for at aktivere en nyere udgave af linuxkernen. Da maskinen var kommet i gang igen, viste det sig, at tiden var 40 ms forkert. Da fejlen var under 128 ms blev serverens ur ikke sat direkte til den rigtige tid. i stedet blev fejlen langsomt korrigeret.
Tidsserveren er tilbage på sporet og uret er kun få ms fra den rigtige tid.
Der har været fejl på C51 i 11 timer. Jeg aner ikke hvorfor, men problemet blev løst ved at afbryde strømmen i godt 10 sekunder. Tilfældigvis var der gode modtageforhold da jeg satte radiouret til igen og tidsserveren begyndte at bruge uret.
Der har kortvarigt været fejl på min DCF77 C51 igen. Måske er det sommervarmen.
Serverens netværksopsætning er justeret, så UDP-trafikken skulle glide lettere. Det kommer også til at gavne NTP-serveren.
Jeg har opgraderet ntpd til version 4.2.4_p0. Installationen skete mens der var god radioforbindelse, så tidsserveren var hurtigt klar til service.
Statistikken i ntpd viser, at radiouret modtager tidskoder 80% af tiden. Det lader til at familien med det 'støjende' TV er på ferie. Statistikken bliver nu nulstillet på grund af en systemopdatering.
Jeg har fået mig enMio h610 GPS-navigator og har brugt den til at beregne afstanden til DCF-senderen. GPS-enheden angiver positionen i decimal–grader, så det måtte jeg omregne til grader/minutter/sekunder. Herefter brugte jeg en storcirkelberegner til at finde afstanden. Resultatet bev meget tæt på 2 ms. På trods af senderens position kun var angivet med grader/minutter, brugte jeg alle decimaler fra beregningerne bortset fra afrundinger. Det er der nok ikke belæg for.
Efter to uger på ferie viser det sig at radiouret har haft et brugbart signal over 90% af tiden. Når bare folk holder sig væk virker det fint :-)
Jeg har flyttet lidt rundt på mine computere, og har opdaget, at når jeg har tændt for min bærbare (slæbbare) computer, er der for meget støj til at radiouret virker, men når blot computeren er slukket, virker det fint. Det hjælper også at lade den bærbare køre på batteriet.
Uret er justeret for afstanden til senderen. Det er godt 2 ms afstand. Der er kun ordenlig radioforbindelse om natten og om formiddagen når ingen af naboerne ser TV. Der er et brugbart signal ca. 30% af tiden. Serverens tid svinger +/– ca. 10 ms over et døgn. Inden jeg fik et radiour svingede tiden +/– 50 ms eller mere. Efter den serielle port er blevet tunet, er forsinkelse og støj tæt på nul.
Sommerstatus: Modtagerforholdene er blevet meget bedre, og
der er forbindelse 80% af tiden.
Den bærbare computer er nu den væsentlige støjkilde,
medmindre der bruges batteridrift.
Min stationære PC var den værste støjsender fandt jeg ud af efter den blev udskiftet med et par små computere.