Bordsur, DCF77

[sm7tjc]

Här i Anderstorp tar min klocka emot helt OK dygnet runt, och har gjort så i 17 år. Men längre upp i landet blir det nog bara mottagning nattetid. Räckvidden är betydligt större under den mörka delen av dygnet.
Alla som lyssnat på radio på mellanvåg vet hur stor skillnaden är.

[blueint]

Fotnot: Anderstorp ligger på samma avstånd till DCF77 sändaren som Varberg och Oskarshamn.

[jadler]

Jag skulle tro att du får lägga till en RTC till klockan, korrigera denna utifrån signalen när du har bra mottagning, ta tid från RTC resten av tiden. Är du ambitiös kollar du hur mycket din RTC drar sig (och hoppas att felet är konstant) så att du kan korrigera den om du är utan tysk tid en längre stund.

[Anonym2]

Hej

Nu har jag skrivit några rader egen kod som läser av signalen och omvandlar den till datum/tid, och kollar om mottagningen stämmer med "even parity" bitarna.

Jag har lite småstrul med att köra en RTC-klocka som upptaderas av DCFF signalen när den tas emot. Att uppdatera klockan och displayen 1ggr/sekund är fixat med ett interrupt, dock verkar detta störa mottagningen, eftersom uppdatering av displayen tar en liten stund. Jag ska se om man kan korta ner uppdateringstiden till enbart de siffror som måste bytas, istället för att "rita om" hela alltet.

En nödlösning blir att skippa sekundvisningen.

//Alexander

[jadler]

Alexander, jag vet inte alls hur du har gjort, och jag har själv inte ännu gjort något liknande, men min lösning skulle vara att använda en RTC för att hämta tid till displayen, och att använda tidssignalen från mottagaren för att hålla RTC-tiden korrekt. Utan att veta något om vilken RTC det gäller skulle jag gissa att den inte avviker mer än kanske någon sekund per dygn, alltså borde det räcka att korrigera den någon gång per dygn. Radiomottagningen på AM-bandet är bäst på natten, de flesta är mindre aktiva på natten, så jag skulle kanske försöka synkronisera RTC:n vid ett tillfälle per natt, kanske någon gång mellan 0300 och 0500. Ett alternativ vore att synkronisera klockan första (eller t.ex. femte) gången per 24-timmarsperiod som man får en korrekt signal, och sedan kanske varannan timme eller så.

Personligen skulle jag under utvecklingsarbetet se till att logga eventuell skillnad mellan RTC och mottagen tid för att empiriskt ta reda på hur mycket den RTC som används drar sig under de förhållanden som jag använder den, och använda den informationen för att besluta om uppdateringsfrekvensen för den slutliga versionen. Jag har funderat lite eftersom jag har liknande tankar men då med tidssignal från en GPS och en RTC att ta tid från.

Vad är det för display som tar så lång tid att uppdatera? Jag tror absolut inte att du behöver (eller bör) uppdatera din RTC varje sekund. Spontant skulle jag, okunnig om detaljerna i ditt projekt, gissa att det är den uppdateringen som tar tid. Om du använder en interrupt-rutin för att uppdatera din RTC finns ju risken att det blir problem med andra interrupter om uppdateringen drar ut på tiden.

[blueint]

Instämmer med 'jadler'. Dessutom borde en uppdateringsoptimering vara möjlig.
En liten överkurs.. skulle man kunna plocka in fler atomurssignaler utan att skaffa en komplett ny mottagare?, finns ju fler som sänder på väldigt liknande sätt inom samma frekvensband.

[jadler]

Jag såg just att Kjell & Co har en pryl som använder DCF77 för att ta emot inte bara korrekt tid utan även professionella väderprognoser. Väderdata tillhandahålls av Meteotime som tyvärr inte har några detaljer om protokollet på sin hemsida. Innehållet verkar inte uppdaterat på ett par år, men det verkar som att de säljer licenser till företag som vill tillverka och sälja prylar som tar emot deras prognoser, så de lämnar nog inte ut protokollet till vem som helst som frågar. Å andra sidan finns det information om vilken typ av data som överförs, och köper man en mottagare kanske det inte är omöjligt att lista ut protokollet.

Har någon här försökt att ta emot och tyda dessa fyradygnsprognoser som finns för stora delar av Europa? Själv har jag ingen DCF77-mottagare än, så jag har inte möjlighet att labba med det.

[Anonym2]

Hej

Det verkar intressant med värderprognoser. Jag lyckades hitta en länk till http://www.hkw-elektronik.de/pdf/DB%20W ... -V%201.pdf som handlar om hur protokollet funkar, tror jag(typ tyska)


//Alexander

[gurgalof]

Hittade lite mer info om väderinfo... LÄNK
Verkar som att väderinformationen är krypterad

[jadler]

gurgalof: Din länk tyder väl på att det är andra entusiaster som försöker avkoda protokollet.

Jag har inte testat men jag antar att det går att få hyfsade väderprognoser helt gratis på nätet, men det vore lite skoj att lyckas avkoda dessa, menst för utmaningen och för att det går att göra. Jag antar att det kan vara lättare om man faktiskt har en fysisk mottagare och kan se vad den visar, korrelerat till de signaler man tar emot.

Apropå DCF77, har någon testat med att använda en mer optimerad extern antenn? Conrad har en mottagare för utomhusmontering, bilderna visar att den skall monteras med antennspolens kärna i rät vinkel mot riktningen till sändaren. Jag är nybörjare på radio (också), men det borde väl vara möjligt att konstruera en bättre extern antenn för den frekvensen?

Vad gäller att ta emot korrekt tid, är det någon som vet eller har en bra gissning på huruvida DCF77 eller GPS-mottagare ger bättre precision? Tuxgraphics har ju en AVR-baserad klocka som använder NTP, men som jag har förstått det har NTP sämre precision än både DCF77 och GPS. Enligt man gpsd kan man drababs av avvikelser i storleken 100 ms med vanlig GPS-mottagare, men har man en mottagare med PPS-utgång (pulser vid sekund-skifte) kan man få mycket mycket bättre precision.