Radio Controll klokje op zomertijd

Klopt. bij DCF is offset (bit 17+18) 1+0 (winter) of 0+1(zomer). (ik vraag me overigens wel af hoe dit bij MSF zit, want die gebruiken hetzelfde formaat)

Het blijft vreemd dat de TZ-info geen eigen parity-bit heeft. (misschien is dit voor de meteo anders?)

Dat wist ik niet. Inderdaad zit er in mijn kennis een lacune voor bit 15 (alternate antenne oid)

Het meest waarschijnlijke lijkt mij dat ie gewoon op zijn "vliegwiel" (kristal) doorloopt, en dat iedere 4 uur de synchronisatie gewoon mislukt, inclusief alles. LCD-dingetjes hebben daar nog wel een indicatie voor. Mijn HEMA-wekke met wijzers gaat bij power-up op 12,4 of 8 uur staan, en wacht dan net zolang totdat ie een compleet frame binnen heeft.

AvK

Zo vreemd is dat niet. Er is immers ook bit 16 dat de overgang van zomer- naar wintertijd v.v. aankondigt. Een klok kan dus onthouden dat tot de eerstvolgende overgang er zomer- resp. wintertijd heerst en zal zich dan ook niets aantrekken van een enkele flip van bits

Bij het herstarten van een klok is het anders en moet eerst worden vastgesteld of er zomer- of wintertijd heerst. Als het lot je slecht gezind is gaat het toevallig op dat moment mis en wordt de verkeerde waarde onthouden. Eenmaal herstarten en het probleem is opgelost.

-p

Ik zie het verschil niet tussen een winter/zomer bit met parity bit en een winter/zomer indicatie van 2 bits met 01 en 10 als geldige waarden. Dit komt op het zelfde neer als 1 bit met odd parity toegevoegd.

Parity is zowizo een wankel mechanisme om data integriteit te garanderen.

Nogmaals: de winter/zomer indicatie is helemaal niet relevant voor een klok die locale tijd moet aangeven. DCF77 zendt de locale tijd uit. Dus gecorrigeerd voor winter/zomer. Die indicatie is alleen maar een extraatje. En je kunt het gebruiken als je DCF77 tijd wilt omrekenen naar UTC tijd, bijvoorbeeld in een driver voor gebruik met NTP (Network Time Protocol, dit werkt met UTC).

Een gewone klok pakt de tijd uit het bericht, zet de display of wijzers op die tijd, en klaar. Hij kan eventueel het waarschuwingsbit gebruiken om zich voor te bereiden op een plotselinge wijziging van de tijd. Maar ik denk niet dat klokken daar iets mee doen, meestal doen die alleen een ontvangst gedurende 2 of 3 minuten om te kijken of ze consistente data krijgen en zetten dan de uitlezing gewoon op die tijd. Zomer/winter gaat dan "vanzelf" goed.

Het probleem van de originele vraagsteller kan eventueel nog veroorzaakt worden doordat er misschien een mogelijkheid in die klok is om de tijdzone in te stellen. Dwz dat de klok zelf een vaste offset toevoegt van een of meer uren. Wellicht iets met het langer inhouden van een knopje ofzo.

Leuk linkje, maar ook daar zijn bits 1-14 "reserved".

Zelfde lacune, dus :-[

AvK

Op die pagina staat toch ook een link naar de PTB site? Daar staat het wel genoemd.

Maar mocht je zelf iets willen doen met die info: het is encrypted en je moet een licentie hebben van het bedrijf wat daar info mee verstuurt naar de moderne klok/weerstation apparaten die dan de weersverwachting laten zien. Dat versturen kost natuurlijk geld dus ze gebruiken dit als inkomstenbron.

Ah, je bedoelde dus v=F3=F3r bit 15.

-p

Yep. Ik doe niet aan leestekens. (bij nader inzien ware "bit 1tm15" beter geweest om ambiguiteiten te voorkomen)

Inmiddels ben ik er dankzij Rob achter, dat deze bits geheim zijn tenzij je geld betaalt. Mensen die niet betalen hebben geen recht op orkaanwaarschuwingen, zo schijnt het.

Bij nadere inspectie blijken de bits een stuk beweeglijker dan de datum- tijd - bits. Ik zal eens kijken of ik ze kan loggen naar een filetje en kijken of er een patroon in te vinden is. Als eea pas in 2003 is ingevoerd is, is de kans groot dat het vrij ingewikkeld is (CRC, gray-codes, ...) , maar misschien lijkt het op iets bestaands (Teletext, RDS)

Gegeven het acute karakter van noodwaarschuwingen zal er wel iets name=value -achtigs worden gebruikt, zodat in noodgevallen het "alarm=luiken_dicht" -bericht kan worden uitgezonden. Binnen een minuut, mits geen storing.

AvK

Op Zaterdag 29 November 2008 09:40:00 GMT, schreef Rob in artikel :

Nee, die mogelijkheid is er niet. Op het moment dat de klok zich instelde, waren de storingsbronnen uit, dus hij had alle 'ruimte'. De klok heeft op deze plaats altijd goed gelopen, dus het is toch wel apart dat hij op de zomertijd liep.

Met vriendelijke groeten, Jawade.

Zo is dat: "betalen of verzuipen". Maar het lijkt maar een deel van het verhaal:

Mij lijkt "public warning" in strijd met "betalen". Ik vermoed dus dat:

- De "public warning" functie nog niet gedefinieerd/geimplementeerd is.

- Een van de bits later gebruikt zal gaan worden om aan te geven of het om een "public warning" gaat of "third party info". Die "third party info" is (nu) natuurlijk die van Meteo Time GmbH, en laten uiteraard niets los over de codering van de weersinformatie; die geven ze alleen aan licencees; zie bijv.:

Net zo beweeglijk als het weer, vermoed ik. ;-)

-p

Bedenk dat juist het feit dat er maar zo weinig bits zijn, het decoderen lastig zal maken. Er is immers geen plaats voor verkwisting, dus je hoeft geen leesbare info te verwachten. Op die zwitserse site zijn allerlei tabelletjes te vinden die je kunt herleiden tot een paar bits die ze versturen per datapunt (bijv temperatuur, windsterkte, windrichting etc) maar hoe die bits in de DCF data staan dat staat er uiteraard niet bij. Het is geen XML wat je binnenkrijgt, dat kan ik wel voorspellen...

Waarom? Met bijvoorbeeld

EHAM 301355Z 08004KT 050V110 2900 RADZ FEW006 SCT008 BKN017 02/01 Q0993 BECMG

in een efficiente encoding heb je meerdere keren per uur het weer voor alle grote vliegvelden in Europa. Alle neerslagsoorten passen in 5 bits. Alle bewolkingstypes in 4. Voor bijzondere weersgerelateerde gebeurtenissen ben je nog eens 4 bits kwijt, maar dan kun je ook vulkaan-as boven Amsterdam melden. Enzovoort.

Bovenstaande is overigens:

Conditions at 2008.11.30 1355 UTC Wind from the E (080 degrees) at 4 KT (direction variable) Visibility 1500 meter Sky conditions mostly cloudy Weather Rain, drizzle Temperature 2 C Windchill -1 C Dew Point 1 C Relative Humidity 93% Pressure (altimeter) 0993 hPa

Ja zo iets doen ze ook. Ze sturen dit soort info voor een aantal verschillende regio's door, en de ontvanger pakt de bits weer uit en maakt er een aantal symbooltjes van op het LCD schermpje. Zon/wolkjes, windpijltjes etc. Ik gok dat het regionummer te vertalen is naar een vaste tijd waarop de info voorbij komt, bijvoorbeeld regio 1 wordt altijd uitgezonden om 1 minuut over het hele uur. Dan hoef je het regionummer niet meer mee te sturen en de klok weet aan de hand van zijn ingestelde regionummer op welk tijdstip hij moet gaan luisteren (energiebesparing!). Dan blijft dus slechts de vraag hoe hebben ze de boel ingepakt in een of meer woorden van 14 bits, zit daar nog encryptie en error-correctie overheen.

Sommige lieden hebben slecht lezen en verkeerd knippen tot een ware kunst verheven.

-p

Kom Piet. Juist jij weet wel beter. Hoe leuk zou 14 betrouwbare bits per seconde of per minuut uit amerika geweest zijn, in 1986, voor iemand die weet hoe er efficient gebruik van te maken? Ga me nou niet vertellen dat _ik_ _jou_ aan Aesop moet herinneren?

Je geeft dus blijk nog steeds niet gelezen of begrepen te hebben waar het om ging.

-p