betere dcf77 module kopen

Tja, dan moet ik de fout bij Bill Gates leggen (XP SP3)...

Ik heb hier NTP op een klein systeempje met een PIC en ook daarop loopt de NTP tijd 2 seconden achter. (Ongeacht welke NTP server ik gebruik, alleen kan het van 1 tot 3 seconden uiteenlopen). Dus dat schijnt toch wel 'normaal' te zijn...

Op 3 januari 2011 13:52:47 schreef Turbokeu:
Mijn persoonlijk probleem gaat nog veel verder:
Mijn uiteindelijke doelstelling is een 'muur' van klokken (rechtover mijn zetel): tientallen Nixie/LCD/LED/VFD/numitron/pixie/dot matrix klokken die allemaal op de msec na gelijklopen.

Op dit moment heeft elke werkende klok zijn eigen (Conrad) DCF77 ontvanger (ik heb er 10 in totaal).
Liefst zou ik gewoon één enkele centrale DCF77-ontvanger gebruiken met een aantal buffers naar de verschillende klokken (elk aangesloten via een dun 3-aderig kabeltje).

Dat lijkt me (als techneut) een beetje saai. Ik begrijp dat het je vooral om het optische effect gaat, en dat zeker ook leuk zijn, maar het zou toch een stuk interessanter zijn als al die klokken op een verschillende manier hun tijd zouden bekomen.

Dus lichtnet, DCF77, GPS, Droitwich, MSF60 en ntp om even de meest voor de hand liggende te noemen. Veel DCF77 modules kunnen ook MSF60 decoderen. Droitwich heeft een datariedel op de carrier staan waar ook de tijd in zit. Er zijn meer omroepstations die data- en tijdriedels op de carrier hebben.

@hieronder: de path delay van wan verbindingen wordt weggerekend binnen het ntp protocol, evenals jitter, binnen bepaalde marges. En mits correct geimplementeerd.

@Arco,

Neem je dan de round-trip-delay op je Wan mee ter correctie ?

Groeten, Bram

Heb het niet precies bekeken, maar dat kan toch nooit 3 seconden zijn?...

Op 3 januari 2011 18:49:07 schreef buckfast_beekeeper:
[...]
BTW ik denk dat Junghans 1 van de eerste DCF aanbieders was. 25 jaar geleden vond je die klokken hier nog bijna niet. In Duitsland was dit anders.

Junghans was inderdaad de eerste voor mij bekende aanbieder van DCF77 klokken en polshorloges.
Met de DCF77 polshorloges zijn ze al langere tijd gestopt, het enige dat ik nog tegenkom zijn losse Junghans analoge DCF77 wandklokmechanismes (o.a. te vinden bij Conrad).

De Reichelt module geeft gelukkig een bruikbaar signaal af. Goed te zien dat er een bit ontbreekt op de 8^ste seconde van de trace.
Hier nog wel geïnverteerd. Morgen een draadje verplaatsen op de toegevoegde inverterende buffer. Buffer schakelt ook een 2mA ledje zodat een goede uitlijning snel gevonden is.

Mooi!
Hoe zit het met de ontvangstgevoeligheid t.o.v. de antenneuitlijning? (m.a.w. hoever mag je van de ideale antenneuitlijning naar Mainflingen toe afwijken vooraleer je inconsistente/random pulsen begint te ontvangen?)

De polariteit (geïnverteerd/niet geïnverteerd) van de DCF77 bits heeft niet echt belang, in mijn DCF77 code heb ik beide mogelijkheden voorzien (gewoon één lijntje code in de source in comment zetten en het volgende lijntje uncommenten, en natuurlijk effe de nieuwe hex compileren).
Alhoewel de Conrad receiver beide signalen/outputs beschikbaar heeft bestaan er misschien andere DCF77 receivers die deze mogelijkheid niet bezitten.

Tip voor K-4U i.v.m. de detectie van het missende 59e bit in het DCF77 frame:
Je vraagt je misschien af hoe je in code een missend/niet bestaand bit kan detecteren.
Aan het begin van mijn DCF77 ontvangstroutine (elke 4msec tijdens de interrupt) verhoog ik een 8-bits teller (SEC_DUR, 0 tot 255).
Telkens/zolang er ontvangst van een bit (100 of 200msec) bezig is wordt SEC_DUR gecleared tijdens de interrupt.
Na ontvangst van het 58e bit is er dus gedurende langer dan één seconde géén ontvangst meer van een bit, en krijg je overflow van teller SEC_DUR (4msec * 256 = 1024msec).
Je weet dus dat je dan in bit seconde 59 van het DCF77 frame zit en dat de start van het eerstvolgende bit (bit0) van het volgende frame exact sec 00 van de volgende minuut is.

@Henk424: Ziet er prima uit.
Enkele persoonlijke kanttekeningen:
- Met gemultiplexte LEDklokken heb ik geen enkel probleem om elke minuut een correct DCF77 frame te ontvangen/decoderen.
Je vrijwillige beslissing om het syncen te beperken tot bepaalde tijdstippen van de dag vind ik daardoor niet helemaal relevant.
Je kan toch gewoon elke minuut de DCF77 frames ontvangen/decoderen? (je MCU heeft toch het grootste deel van zijn tijd niet veel anders te doen)
Zijn de frames niet geldig (compleet garbage, of missend startbit, of foutieve pariteit) hou er dan simpelweg geen rekening mee.
Krijg je, in een hypothetisch slechte DCF77 ontvangstsituatie, maar een paar correcte frames per uur of per dag, elke goede sync maakt je klok alleen maar nauwkeuriger (ter info: mijn standalone 24u klok/kalenderroutine, mede door de eigen precisie/onprecisie van een standaardkristal, heeft een afwijking van enkele seconden/dag in offline mode).
- RTC klok/backup (DS13xx): Mijn LEDklokken synchroniseren allemaal binnen de 2 minuten (in het beste geval ca. 61 seconden).
Vermits klokken verplaatsen/stroomonderbrekingen eerder uitzonderingen zijn ontgaat het nut mij persoonlijk een beetje en lijkt het mij meer een bijkomende luxe.
De nauwkeurigheid van de DS13xx RTC's is (afhankelijk van het 32KHz kristal) ook maar een paar minuten/maand, je moet de registers wanneer mogelijk dan ook syncen met de DCF77 tijd/datum.
Indien je echt staat op het gebruik van een RTC/backup zou je dan niet beter een DS32KHZ TCXO (precisie van een paar seconden/jaar) toepassen?
- Nachtelijke display blanking: Tja...
Bij een nixieklok sta ik 100% achter het 's nachts doven van de buizen.
Nixiebuizen worden al tientallen jaren niet meer geproduceerd (de Russen, via de Sovtek fabriek, toch nog tot 1991), dus elke versleten/defecte nixiebuis is onvervangbaar en verloren voor het nageslacht.
Bij een LEDklok zie ik het nut er minder van in (ook wat betreft stroombesparing): Mijn LEDklok verbruikt, dankzij de LDR omgevingslichtafhankelijke PWM-sturing in het donker (naast de ca. 10mA op de 5V-spanningsrail voor de logica) slechts een 10-20mA voor de displays (tot 400mA in volle zonlicht) voor de uitvoering met 4.0" (102mm) hoge displays.
Wat heb ik aan een duistere LEDklok in de woonkamer als ik 's nachts van mijn bed (bovenverdieping) naar de WC (helemaal achter op de benedenverdieping) loop? (temeer daar ik brildrager ben en de 4.0" displays in het donker perfect zonder bril kan aflezen)

Let op, dit is puur opbouwende kritiek, zeker géén reden om je ontwerp af te breken!
Iedereen heeft zo zijn ideeën (gelukkig!), en discussie hieromtrent kan het welles/nietes van een bepaalde beslissing/werkwijze alleen maar gunstig beïnvloeden.

@bprosman: Heb je al verschillende locaties in huis geprobeerd tijdens het syncen?
Hier thuis ken ik de goede en minder goede locaties voor DCF77 ontvangst.
In het slechtste geval kan je het weerstation een kwartiertje buiten in de tuin zetten om te zien of de DCF77 sync dan wel lukt.
Als ie natgeregend wordt en het station geeft aan dat er kans op regen is weet je tevens dat deze functie ook werkt.

Nee serieus, bvb. mijn DCF77/WWVB/MSF60/JJY reiswekker synchroniseert, afhankelijk van zijn locatie op de koelkast ofwel op DCF77 in Mainflingen, ofwel op MSF60 in Anthorn (UK), afhankelijk van het op dat moment sterkste signaal, met als resultaat dat ik soms de UTC tijd zie verschijnen...

@Loecky Loeke : Bedankt, zal eens rondsnuffelen.
De horlogewinkel waar ik indertijd mijn Waveceptor gekocht heb had enkel een paar modellen van de G-Schock en het 400€-dure ultraplatte model met Outlooksynchronisatie met een PC (waardeloze optie voor mij omdat ik mezelf geen mails zie lezen op een polshorloge, zelfs al niet op mijn GSM...).
Ik had wel al opgemerkt dat er actueel (o.a.) op Ebay goedkopere, recente en voornamelijk discretere Casio Waveceptor modellen beschikbaar zijn.

@joopv: Ik heb de 'Update Now' optie geprobeerd zowel via de time.windows.com als time.nist.gov NTP servers en ik blijf steeds ca. 1sec tijdsverschil met DCF77 behouden.

@Henk424 & pros: Bedankt voor deze hoopgevende woorden... snif...
Ik besteed inderdaad zeer veel tijd en aandacht aan mijn replies (deze reactie ben ik ergens rond 6:00 deze morgen begonnen...), enkel onderbroken voor het inschenken van een paar verse koppen koffie, een sigaretje, de badkamer voor een wasje en vers ondergoed, een omweg naar het WC voor een watertje, nog een verse kop koffie en een sigaretje, en nog maar eens naar de WC en nog een paar koppen koffie.
Had ik het al gezegd? Ik moet echt dringend weer eens gaan wateren...

PS: Ik heb ondertussen al zò lang en zò dikwijls het tijdsdiagram van het DCF77 frame voor ogen gehad tijdens het ontwikkelen van mijn DCF77 routines dat ik nu ongeveer het uur en de datum kan lezen enkel aan de hand van een DCF77 beatLEDje...
Ik heb daarvoor wel een volle minuut nodig en ik controleer de pariteit niet, hahaha!

PS2: Dacht ik alle atoomkloktijdzenders ter wereld te kennen, zijn er voor mij toch nog een paar onbekende tussen:
http://www.compuphase.com/mp3/h0420_timecode.htm

Edit: @joopv: Moest ik met zekerheid nog een halve eeuw langer leven (ik ben 55) zou dit zeker een uitdaging zijn.
Zoals vele CO-leden die mij al langer kennen ondertussen weten heb ik continu 20-25 projecten (waarvan meerdere ondertussen al 5-, 10-of 20-jaar projecten aan het worden zijn) af te werken...

Dat lijkt zeer goed mee te vallen. Ik heb een test gedaan in 3 richtingen. Met de ferriet noord/zuid, oost/west en zw/no. In de 3 situaties blijft het een mooi bruikbaar signaal dat op de seconde triggert en geen spikes tussen door. Korter bij de pc wordt het wel wat slechter.

Ik ben zeer benieuwd hoe het signaal zal zijn in de uiteindelijke werk omgeving. Een commercieel dcf klokje moet aan de venster gezet worden in een N/Z oriëntering om tot synchronisatie te komen. 10 pc schermen boven zijn hoofd, 10 schakelende voedingen onder de tafel, 2 kvm switchen er naast en 2 touch screens is blijkbaar iets te veel storing. De betonnen structuur is waarschijnlijk ook niet bevorderlijk. Voor de dcf timeserver hebben ze een antenne op het dak moeten plaatsen. In de server ruimte lukte het niet. Deze pc's hangen om veiligheidsredenen niet aan een extern netwerk. NTP is dus niet mogelijk.

Ik voorzie alvast voldoende afgeschermde kabel om het ontvanger deel aan de klok aan te sluiten.

Ik ga alvast proberen om elke mogelijke synchronisatie te gebruiken. Mogelijk lukt het alleen 's nachts. Dan gaan de displays uit en staan alle schermen uit. Ook de voedingen krijgen dan geen spanning meer. Tussen 22h00 en 5h45 is er niemand aanwezig. Op zaterdag wordt er gewerkt tussen 8h00 en 16h00. Op zondag wordt er gewerkt in de maanden mei tot september tussen 10h00 en 18h00. Niet nodig om de display's 24h/dag te tonen.

[offtopic]
@buckfast: ik wil die werkplek toch best wel eens zien..
[/offtopic]

@Turbokeu:
Ik zal denk ik inderdaad met een interrupt routine gaan werken. Zo kan ik volgens mij het makkelijkste de DCF frames afvangen.

de 'main' loop zal het display verversen.

Ook zal ik idd gaan werken zoals jij het zegt.. elke minuut dcf packets binnenhalen.. op het moment dat hij een correcte heeft, updaten.. zoniet, verder op de interne klok.

Bij je linkje staat ook een andere dcf77 module vermeld.. Helaas kan ik hier niets meer vinden op de site.. Heb jij meer geluk gehad?

[offtopic]
Ik heb er spijtig genoeg geen foto's van.

Even in het kort. Met 3 personen bedienen wij 4 sluizen, 8 bascule bruggen (waarvan 1 dubbele), 1 ophaalbrug en 1 draaibrug. Ieder heeft op zijn werkplek mogelijkheid om 2 kunstwerken gelijktijdig te bedienen. Van op elke werkplek kan elk kunstwerk bediend worden. Slechts 1 persoon kan gelijktijdig een kunstwerk bedienen. Op elk kunstwerk staan 4 of 5 camera's. Die worden gecodeerd en in stream op glasvezel gezet. De beelden worden na decodering aan de Neovo pc schermen toevertrouwd via coax. De eigenlijke bediening gebeurd via de touch screens.
[/offtopic]

@Turbokeu
Jouw kanttekeningen bij mijn klokontwerp kan ik wel onderschrijven, echter in de info ben ik niet volledig geweest:
De klok is ontworpen voor gebruik in school. Daarom graag een backupbatterij want er is altijd wel een grapjas die de stekker even uit het stopcontact haalt.De display is buiten de schooltijden uit. De weekdagen zijn ingeprogrammeerd, tijdens vakanties gaat de stekker eruit. Dat is gewoon het idee, besparen als het kan. De display aansturing is in hardware uitgevoerd omdat ik eerlijk gezegd liever de soldeerbout gebruik dan de compiler. Een kwestie van voorkeur.
De TCXO heb ik ook overwogen maar dat leek me weer overkill als je DCF gebruikt.
Waarom niet continu het DCF signaal ontvangen? Storing overdag in het lokaal veroorzaakt door uitgebreide bedrading voor computer en beamer.
Natuurlijk ben ik nog lang niet uitgebouwd en in mijn volgend project ga ik nu maar eens het display multiplexen. Je moet een uitdaging toch niet altijd uit de weg gaan toch?

De TCXO heb ik ook overwogen maar dat leek me weer overkill als je DCF gebruikt.

Och ... je kunt het een doen en het ander niet laten ..

Een TCXO kost geen fluit meer tegenwoordig, denk aan de DS32kHz

Op 4 januari 2011 12:20:44 schreef Turbokeu:
@joopv: Ik heb de 'Update Now' optie geprobeerd zowel via de time.windows.com als time.nist.gov NTP servers en ik blijf steeds ca. 1sec tijdsverschil met DCF77 behouden.

Raar hoor. Omzeil de GUI eens en geef een time commando in een dosbox. druk op enter terwijl je naar je dcf klok kijkt op een seconde overgang. Bij mij geeft dat een afwijking van minder dan 0,1 seconde.
Gebruik eventueel de lokale ntp server van je provider of nl.pool.ntp.org

Op 4 januari 2011 16:57:42 schreef K-4U:
de 'main' loop zal het display verversen.

Aie, moet je juist nièt doen.
Bij gemultiplexte displays heb je een vaste verversingfrekwentie nodig die je niet kan garanderen in de main loop (door delays in het scannen van invoer (toetsen), key debouncing, ADC conversie e.d.).
Het resultaat kan, en zal, dan onregelmatige flikkering tot zelfs haperen van de displaymultiplexing betekenen.

Ik heb gekozen om 99% van de acties in de interruptroutine uit te voeren.
Ik weet wel dat men lange interruptroutines meestal afraadt maar ik had eigenlijk weinig keus en als je oplet vormt dit geen probleem.
Bij een interrupt om de 2msec kan ik bij 4MHz systeemclock op een PIC16F grofweg 2000 instructies in ASM uitvoeren vooraleer de volgende interrupt (Timer0 overflow) optreedt.
Mijn volledig LEDklok programma is slechts ongeveer 1100 ASM-instructies lang, initialisatie inbegrepen (het grote voordeel van programmeren in assembly )(*).
Daarin zit ook de main loop (een paar 10-tallen instructies: LDR ADC-conversie en PWM-sturing, scannen van 2 toetsen/debouncing en oproepen van de datum/tijd scrolling subroutines indien nodig).
Al de rest wordt via subroutines tijdens de interrupt afgehandeld:
- Updaten van het display (multiplexing, elke 2msec).
Om de 4msec:
- Updaten van de standalone klok/kalender.
- Ontvangen/decoderen van de DCF77 pulsen/data.
- Updaten van de standalone klok met de DCF77 waarden indien geldig.
- Afhandeling van DCF77 errorcondities.
- Updaten van de statusLEDs (DCF77 beat, DCF77 OK, DCF77 Error, Standalone).
- Aanpassen van het uur in de CET+1 en CET-1 tijdzones t.o.v. de CET DCF77 tijd (wegens mogelijke berekeningsproblemen tijdens schrikkeljaren (29 februari) en zomer/wintertijd omschakelingen om 02:00 doe ik geen update van datum en uur van de standalone klok/kalender met de DCF77 tijd/datum tussen 22:59 en 03:01 uur. Seconde 00 van elke minuut blijft wel gesynct met DCF77).

Ik maak zéér veelvuldig gebruik van flags (of semaforen) om events uit de verschillende subroutines door te geven aan de andere subroutines.
De executie van de interruptroutine neemt maximum 1msec in beslag, de resterende 1msec tot de volgende interrupt is vrij voor de main loop.

Bij je linkje staat ook een andere dcf77 module vermeld.. Helaas kan ik hier niets meer vinden op de site.. Heb jij meer geluk gehad?

Bedoel je Meinberg?
Zij hebben de EMP226 DCF77 receiver.
Je hebt er wel nog een apart te bestellen antenne bij nodig.

@Henk424: Ik dacht dat het om een huis en tuin klok ging, daarom.

@joopv: Zal ik eens proberen.

(*) De nixieklokkit van Claus Urbach draait eveneens op een 16F876.
De software is ontwikkeld in C door Thomas Scherrer (OZ2CPU) en neemt de volledige beschikbare 8KB in beslag...

Even een update alsnog..

Ik gebruik nog steeds de Conrad module, maar heb mijn code nu wel een enorme makeover gegeven.
De klok loopt nu perfect.. met een klein heel raar probleem..

Op het moment dat mijn vader de kamer binnenkomt.. krijg ik storing..
De klok loopt uren achter elkaar perfect, zonder enige tekenen van storing te weergeven. Maar als mijn vader binnenkomt krijg ik alleen nog maar rare dingen binnen.
Hoe is dit mogelijk?

(ps: "Hou je vader dan uit je kamer" is helaas niet mogelijk.. het klokje is voor hem)

Heeft je vader misschien een peacemaker?

Nop.. Niets van elektronica.. dat is het rare

peacemaker?

Altijd handig in een huwelijk

@K-4U: Je vader moet dan, logisch gezien, iets op zich dragen die de DCF77 ontvangst verstoort.
Kan je hem niet vragen eens naakt de kamer binnen te wandelen?

@bprosman: Nee, dank je. Dan was ik nu nog getrouwd...

Een pacemaker stoort niet. Dat zou veel te veel vermogen kosten.

Op 6 januari 2011 20:32:36 schreef flipflop:
Een pacemaker stoort niet.

Oeps, ne kemel geschoten in de syntax...

Ik twijfel er ook tenzeerste aan dat een pacemaker zou storen, maar 'iets' in/op/rond K-4U's vader moet schijnbaar toch de oorzaak zijn.

@K-4U: Heb je meer info?
Hoe dicht moet je vader bij de DCF77-receiver komen vooraleer de storing optreedt?

PS: Mijn Aldi analoge DCF77 wandklok heeft onlangs de geest gegeven, alhoewel nog geen 3 jaar oud (was iets van 14-15€, ben natuurlijk kasbonnetje kwijt voor terugbetaling door Aldi).
Het begon met een haperende secondenwijzer, nu haperen ook nog de minuten- en urenwijzer (denk dat de plastieken overbrenging een paar tandjes op sommige tandwieltjes mist).
Vermits ik erg aan de klok gehecht ben (zeer mooi en strak design: Geborsteld vertikaal U-vormig aluprofiel achter hetwelk het klokmechanisme gemonteerd zit. Een ronde heldere glasplaat met uren/minuten schaalverdeling is met 2 afstandshouders op het aluprofiel bevestigd. De wijzers zelf zitten tussen de glasplaat en het aluprofiel) ga ik een nieuw DCF77 klokmechanisme monteren.
Van het defecte klokmechanisme zal ik proberen het DCF77-ontvangergedeelte te recupereren/scheiden en eens uit te testen op storings- en ontvangstgevoeligheid.

In mijn eetkamer hangt tevens sinds een aantal jaar de welbekende grote Ikea analoge wandklok van zo'n 60cm diameter (nu niet meer in het gamma).
Ik heb een tijdje geleden geprobeerd deze wandklok om te bouwen naar DCF77 met een Junghans DCF77 klokmechanisme van bij Conrad.
De ombouw is mislukt om de simpele reden dat de wijzers van deze klok zò groot zijn dat de stepmotor van het Junghans mechanisme niet de benodigde kracht bezit om de wijzers betrouwbaar rond te draaien (plat op tafel lukt het wel goed ).
Zelfs uitbalanceren van de wijzers aan de korte zijde met gelijmd vislood hielp niet...
Dit Junghans mechanisme ga ik nu gebruiken om mijn Aldi wandklok weer in ere te herstellen.

Oke.. de klok is nu al bijna 24 uur aan het draaien.. In de tijd dat thuis was en niet aan het slapen, is mijn vader meerdere keren de kamer op komen lopen.

In totaal staat de "onzin-op-het-scherm"-teller op 1.
Wat er nu precies aan de hand is weet ik niet. We houden het erop dat zijn mobiele telefoon(die hij altijd met bluetooth en wifi aan bij zich heeft) de stoorzender(/ontvanger? wifi is toch deels passief?) was.

In dat ik deze post type vind mijn klok dat het 02:11 is. Nu 3 minuten wachten tot de klok zichzelf verbeterd.. (Heb een routine ingebouwd dat de klok kijkt of de tijd radicaal veranderd is.. Op het moment dat dat 3 keer is voorgekomen, is zijn gedachtengang: "Oh Wacht.. de tijd van de DCF is nu al zeker 3 keer niet eens in de BUURT geweest van mijn tijd.. zal ik het fout hebben? Zal de DCF dan toch de waarheid spreken?".. Vervolgens gaat hij zoveel twijfelen dat hij zichzelf gewoon opblaast.. zet hij de DCF tijd neer..)

Is bovenstaand te begrijpen?

@Turbokeu: Hij hoeft de deur al open te doen.. 2 a 3 meter..

Ik zou zeggen, laat ie z'n telefoon eens niet meebrengen. Da's toch snel te testen of heeft ie 'm geimplanteerd?

Op het moment dat dat 3 keer is voorgekomen, is zijn gedachtengang: "Oh Wacht.. de tijd van de DCF is nu al zeker 3 keer niet eens in de BUURT geweest van mijn tijd.. zal ik het fout hebben? Zal de DCF dan toch de waarheid spreken?"

Je moet natuurlijk ook wel kijken of het een juiste tijd is door de ontvangen tijden te vergelijken en pas als er 2 zijn ontvangen die kloppen de boel gelijk zetten.

Aanbieding http://link.marktplaats.nl/407883621

Op 1 januari 2011 11:48:22 schreef Henk424:
De module uitnemen, PON en min verbinden, + aansluiten (1,5 volt) Op de aansluiting naast de plus is het DCF-signaal beschikbaar.
Dit signaal voer ik toe aan de comparator op de PIC. Opampje kan natuurlijk ook.

Heren,
Ik ben sinds enige tijd ook met een klok project bezig (QlockTwo kloon) en wil deze via DCF gaan synchroniseren. Ik heb eerst even met de Conrad module zitten spelen maar krijg daar geen betrouwbaar signaal uit gezien de hoeveelheid electronica in mijn kamer. Als tip van Henk heb ik nu die Hema klok gehaald en al uit elkaar gehaald maar heb daar een vraag over.
PON en min verbinden => ik neem aan dat je met min de GND bedoelt? Komen beide dan aan massa te hangen? Moet je nog een pull up gebruiken voor het DCF signaal? Ik wil deze gelijk aanbieden aan de ucontroller (Arduino met ATmega) voor de decodering.

Alvast bedankt voor het antwoord.

GJ.

Ja, PON moet aan GND( massa). Pull-up hoeft niet, je kunt de module testen met een analoge meter, elke seconde gaat 'ie naar 1.5 volt.
De module verwacht ook een voedingsspanning van 1,5 volt. Als je het signaal rechtstreeks op een digitale poort aansluit is het niet zeker dat een niveauwisseling wordt herkend. Zelf heb ik hem aangesloten op de comparator van een pic. In mijn eerste experimenten gebruikte ik een opampje om het signaal op te krikken.