Klok tijdsbasis

Hallo,

ik ben van plan een klok te gaan maken, met een weergave in BCD met LEDs (aka binary LED clock). Dit op basis van een PIC16F628A of een Attiny2313, daar ben ik nog niet over uit. Qua programmeren gaat dit mij wel lukken, en het LEDs weergaveraster ook wel. Mijn probleem is de tijdsbasis.

Ik ben van plan de lichtnetfrequentie te gebruiken. Mijn idee was een transformator te nemen, die 230VAC omzet in ongeveer 12VAC. Dan een diode erachter, een weerstand, en dan aan de basis van een NPN transistor. Daarmee wil ik dus een interruptpoort van mijn uC hoog maken, zodat ik tot 50 kan tellen (adhv netfrequentie op 50Hz), en wanneer ik bij 50 ben, de teller resetten en een seconde bij de klok tellen.
Bij deze methode is het probleem dat ik een halve sinus krijg , die de transistor schakelt, daardoor zal het signaal op de interruptpin niet 20ms hoog en 20ms laag zijn. Ik denk dat ik een blokgolf nodig heb.

Hebben jullie nog ideeën om dit te laten werken, of een beter idee? Ik zou niet weten of ik in mijn plan fouten heb zitten, maar ik ben bang dat dit niet gaat werken. Bedankt.

Je hoeft toch alleen de (opgaande) flank van die 50Hz te meten? En trouwens, wat maakt de vorm van die blokgolf uit?

Volgens mij moet dit gaan lukken met dat voorgestelde verhaal.

De AVR kan edge-triggered werken. Dan maakt de duty cycle geen zak uit (en dit is traag genoeg om op geen enkele manier te kunnen missen :) ).

ooit gehoord van een schmitt trigger?

Move /Digitaal

Deze vraag kwam vorige week ook al langs ;)
http://www.circuitsonline.net/forum/view/39169/
Alleen nu even voor de gelijkrichter aftappen.

Als je zoiets goed wil aanpakken, kan je best achter de voedingstrafo eerst de gelijkrichterbrug plaatsen, daar 100Hz aftappen, en via een diode de buffer-condensator en de rest van de schakeling voeden. Het afgetapte signaal lus je door naar een Schmitt-trigger met een zo hoog mogelijke hysteresis, waardoor stoorpulsen op de netspanning geen roet in het eten kunnen gooien. Puristen plaatsen er nog een monoflop achter die na iedere puls 19mSec actief blijft, zodat hardnekkige stoorpulsen maar 1/20e van de tijd kans krijgen de boel te belazeren...

Op 5 oktober 2006 19:40:35 schreef Ricvdp:Mijn probleem is de tijdsbasis. Ik ben van plan de lichtnetfrequentie te gebruiken.

Waarom wil je de lichtnetfrequentie gebruiken? Als je gewoon een net kristal aan de microcontroller hangt, dan kan je ook prima seconden aftellen. Zie bijvoorbeeld http://www.romanblack.com/one_sec.htm.

De lichtnetfrekwentie is, i.i.g. over langere tijd, preciezer dan een doorsnee kristal.
Ik spreek uit ervaring, ik ben al meer dan een jaar bezig een standalone klokroutine aan 't ontwerpen met HW-matig een 30ppm afwijking (die van het kristal) maar in de praktijk kom ik op een gemeten afwijking van +/-9 à 12 seconden/dag.

Daarom één, en enkel één, oplossing: DCF77 (met GPS-ontvangers zijn er nog teveel problemen in minder goede ontvangstcondities), en een DCF-synchronisatie elke minuut bij ontvangst van een correct DCF-frame.

CD :)

Op 5 oktober 2006 22:23:11 schreef Turbokeu:
De lichtnetfrekwentie is, i.i.g. over langere tijd, preciezer dan een doorsnee kristal.
Ik spreek uit ervaring, ik ben al meer dan een jaar bezig een standalone klokroutine aan 't ontwerpen met HW-matig een 30ppm afwijking (die van het kristal) maar in de praktijk kom ik op een gemeten afwijking van +/-9 à 12 seconden/dag.

De vraag is: hoe goed is goed genoeg? Als je altijd synchroon moet lopen, dan is DCF77 een goede oplossing. Als het niet zo veel uitmaakt, dan is een kristalletje ook goed.

Ik gebruik gewoon de 4MHz kristallen bij voti vandaan, en mijn klokken blijven trouwens keurig op tijd lopen. Er zal wel wat 'drift' zijn, maar zeker geen seconden per dag.

die afwijking kan ontstaan door parasitaire capaciteiten, een kristal moet altijd met exact de juiste lastcapaciteit belast worden. wijkt deze af, dan heb je een afwijking in de oscillatiefrequentie (bij parallel resonerende kwartskristallen)

Is dit wat je bedoelt? Ding kun je justeren; zolang de temperatuur constant is, zal het best nauwkeurig zijn.

Op 5 oktober 2006 22:23:11 schreef Turbokeu:
...Daarom één, en enkel één, oplossing: DCF77 (met GPS-ontvangers zijn er nog teveel problemen in minder goede ontvangstcondities), en een DCF-synchronisatie elke minuut bij ontvangst van een correct DCF-frame...

Een RTC komt aardig in de buurt, als je een nauwkeurig model neemt, zal die uit zichzelf een temperatuurscompensatie hebben (elke 30 sec temperatuur meten en zichzelf daarmee herkalibreren), en zal je erg hoge nauwkeurigheid halen. Naast het feit dat het gewoon gemakkelijk is natuurlijk.

Real Time Clock (Maxim DS1307/DS1337) + 32.768kHz Temperature-Compensated Crystal Oscillator (Maxim DS32kHz): accuraat tot +/- 1 minuut/jaar.

Heb ze hier allemaal liggen maar moet tijd vinden om er mee 'te spelen'.

CD :)

Op 5 oktober 2006 22:23:11 schreef Turbokeu:
De lichtnetfrekwentie is, i.i.g. over langere tijd, preciezer dan een doorsnee kristal.
Ik spreek uit ervaring, ik ben al meer dan een jaar bezig een standalone klokroutine aan 't ontwerpen met HW-matig een 30ppm afwijking (die van het kristal) maar in de praktijk kom ik op een gemeten afwijking van +/-9 à 12 seconden/dag.

Daarom één, en enkel één, oplossing: DCF77 (met GPS-ontvangers zijn er nog teveel problemen in minder goede ontvangstcondities), en een DCF-synchronisatie elke minuut bij ontvangst van een correct DCF-frame.

CD :)

Zo nauwkeurig dat ik DCF moet gebruiken hoeft het niet te zijn, die optie hadf ik al weggestreept.

Op 6 oktober 2006 13:41:46 schreef Marco69:
Is dit wat je bedoelt? Ding kun je justeren; zolang de temperatuur constant is, zal het best nauwkeurig zijn.

Die link vond ik ja, ze gebruiken daar een RTC, en ik wou het eerst zonder RTC proberen, maar misschien moet ik er toch maar een keer een kopen.

Bedankt voor al jullie antwoorden, en als ik niet verder kom met de tijdsbasis post ik het hier wel weer neer. Ik denk dat ik ook wel wat met Fub's link kan.