DCF 77

[Uli (Gast)]

Hallo,

Hier mal ein neues Programm von mir für einen Atmel.
Dieses wertet ein DCF77 Signal aus und gibt es auf der seriellen
Schnittstelle aus. Die Uhr läuft auch weiter, wenn das Signal ausfällt.
Natürlich sollte das DCF 77 Modul an INT0 angeschlossen werden. Da ich
dieses für einen Mega128 geschrieben habe müssen noch die Int Register
auf den jeweiligen Prozessor angepasst werden.

Mfg Ulrich

[Dirk v.L. (Gast)]

Hallo Uli,

hab mir das *.zip-File mal angeschaut, aber noch nicht ausprobiert, da
ich erst mal mit einem ATmega16 arbeite.
Bei Durchsicht des Quellcodes ist mir in der clock.c aufgefallen, daß
Du beim manuellen Lauf der Uhr von 60 Stunden pro Tag ausgehst,
vermutlich sollte da aber auf 24 Stunden abgefragt werden.

Dirk

[Uli (Gast)]

Hallo,

Also habe noch die 24Stunden geändert. Weitere Infos bzw. neuer
SourceCode auf meiner Homepage.

Mfg Uli

[Peter D. (peda)]

Wenn ich das richtig sehe, wird T1 ständig bei jedem (Stör-)Impuls
zurückgesetzt. D.h. Deine interne Zeit läuft in den Wald, sobald der
Empfang gestört ist.

Außerdem machst Du keinerlei Überprüfungen (Parity,
Impulslänge/-abstand). D.h. Du weißt nie, ob die empfangene Information
auch richtig ist (ist sie nämlich oftmals nicht), z.B. bei Gewitter,
Staubsaugen, Fernsehen.

Ich hatte mir früher mal sowas komplett mit TTL-ICs aufgebaut, das
Ergebnis war nicht berauschend.

Man muß also unbedingt die Tests machen und die interne Uhr unabhängig
laufen lassen, damit man eine zuverlässige Zeitinformation erhält.

In der Codesammlung ist ein Assemblerbespiel auf dem ATTiny12 und im
Web auch C-Beispiele von mir, wie es super funktioniert.


Peter

[mthomas (Gast)]

Auch ganz brauchbar ist http://www.fh-kl.de/~ofer/avr/avrpro.htm.
Weiss zwar nicht, ob darin saemtliche von Peter Dannegger
angesprochenen Pruefungen durchgefuehrt werden aber eine Portierung auf
den LPC2106 ARM7 funktioniert seit fast 2 Monaten ohne Probleme (ohne
"unsinnige" Zeiten). Der Code ist auch nicht ganz so optimiert wie
Peter Danneggers C-Code, war aber leichter zu portieren.

[Uli (Gast)]

Hallo,

Das mit der Parity Prüfung ist richtig wird noch nicht ausgewertet.
Kann man aber ohne Probleme mit einbinden. Allerdings wenn nicht alle
Impulse Empfangen werden läuft die Interne Uhr weiter.

Mfg Ulrich

[Uli (Gast)]

Hallo,

So habe noch die Berechnung geändert. Parity werde ich evt. auch noch
einarbeiten habe mir dazu was ausgedacht. Bis dahin.....

Mfg Uli

[Uli (Gast)]

Hallo @peter dannegger

Hattest recht mit Störimpulsen habe mal den DCF77 Empfänger direkt
neben meinen Drucker gelegt, und die Zeit zählte und lief davon.
Also habe ich die Auswertung geändert und zusätzlich die Parity
Überprüfung eingebaut :-)

Also hier der neue SourceCode.

Mfg Ulrich

[max.p (Gast)]

hallo

woran kann es liegen das sich die funkuhr nicht syncronisiert? ich habe
das ganze auch auf einem m128 aufgebaut. allerdings habe ich den
interrupt auf 7 geändert. als funkuhrmodul verwede ich das vom grosen
c. Über usart empfange ich nur dauernd die sekundenangabe die immer nur
hochzählt.

mfg
max

[Uli (Gast)]

Hallo,

Das kann daran liegen das, das Modul zu nah am µC liegt.

Mfg Ulrich

[max.p (Gast)]

hallo

hab jetzt ein 20cm langes kabel dazwischen, ist aber auch nicht besser.
kann ich das auch ohne osziloskop mesen ob da überhaut was rauskommt?
ich hab den verdacht das das modul kaput sein könnte.

mfg
max

[Peter D. (peda)]

@Max,

einfach nur eine LED mit Vorwiderstand an den Ausgang gegen VCC, die
muß dann je s einmal blinken.

alle Monitore und PCs ausschalten
eventuell ans Fenster gehen
eventuell mit Batterie (4,5V) betreiben (falls das Netzteil
rumschweint).


Peter

[Stefan Seegel (Gast)]

Machne Module haben ein invertiertes Datensignal! Das sollte mit dem
Oszi rausgemessen werden und ggf. in der Routine geändert werden.

Stefan

[Benedikt (Gast)]

Könnte mal jemand eine Hex oder Bin Datei von dem Programm erstellen ?
Ich habe leider keinen C Compile für AVR installiert.

Der erste DCF77 Dekoder ist zumindest schon auf meinen DCF Sender
reingefallen.
Ich möchte erstmal einige direkt verbundene Dekoder testen, ehe ich
einen echten Sender anschließe um mal ein paar Uhren zu verstellen...

[lordludwig (Gast)]

du weißt aber schon das das illegal ist und mit hoher geldstrafe
bestraft wird???

[T29 (Gast)]

Hallo ? Gehts noch ? was soll da bitte illegal sein ? Wie war das noch ?
 wer keine Ahnung hat sollte lieber ruhig sein ?

[Rolf F. (Gast)]

> Der erste DCF77 Dekoder ist zumindest schon auf meinen DCF Sender
> reingefallen.

Wenn der Sender sich an die Spezifikation hält, also auch die drei
Prüfbits stimmen, muß die Uhr darauf synchronisieren.
https://erlangen.ccc.de/projects/dcf77/

[plitzi (Gast)]

@Benedikt
@T29

Ob illegal oder nicht, wenn Du nur eigene DCF-Dekoder testen willst und
dabei nicht "in die Luft gehst" oder Dich zumindest in der Ausbreitung
Deiner "Fehlinformationen" räumlich beschränkst, ist das sicherlich in
Ordnung. Einen DCF-Sender zu bauen, der vorsätzlich falsche
Uhrzeitinformationen ausgibt um damit "Schaden" anzurichten (ich
trage auch so eine Uhr am Handgelenk und habe mehrere davon zu Hause)
halte ich zumindest moralisch für sehr verwerflich. Es gibt zahlreiche
Besipiele, bei denen Falschinformationen zum Chaos führen können
(Ampelanlagen!).

"Was das Gesetz nicht verbietet, verbietet der Anstand!"

Jörg

[Rolf F. (Gast)]

Naja, ich mache demnächst auch einen DCF77-Sender, denn DCF77Fake (
https://erlangen.ccc.de/projects/dcf77/ ) erfordert ein LCD-Display,
das ich nicht habe.
Außerdem kann ich mit RTAI-Linux bis 400 kHz (Langwelle) die
Parallelport-Pins wackeln lassen, so daß die 77 kHz kein Problem sind
und als (zusätzliche) Hardware nur eine Spule am Parallelport nötig ist
;-)

[lordludwig (Gast)]

bei so was is des natürlich ned illegal ich dachte du hast was richtig
großes gebaut und willst "On Air" gehen.

https://erlangen.ccc.de/projects/dcf77/ interresiert mich jetzt auch
aber leider ist der download-link kaputt. Wenn einer das Prog noch hat
dann fände ich es nett wenn ich es per E-Mail oder neuem Link bekommen
würde :-)

[Rolf F. (Gast)]

Irgendwo weiter unten unter http://mazzoo.de/code.html

In Langwelle "On Air" zu gehen ist etwas schwierig, wegen der großen
Wellenlänge. Mit einer CUL-Trommel am Datenport des Parallelports komme
ich auf rund 3 m Reichweite.

Beim Programm Clock Fake 77 soll man die Funktuhr auf das LCD-Display
legen, da das Display relativ schwach strahlt. Es gibt da auch Probleme
wie daß einige Uhren nur einmal pro Stunde synchronisieren, so daß es
länger laufen sollte.

[Benedikt (Gast)]

Mein Funkuhr Sender war eigentlich nur ein Test, ob es überhaupt geht.
Mein Prof in Messtechnik hatte erzählt, dass er es nicht geschafft
hätte, da musste ich es eben einfach ausprobieren...
Der Sender lief auch nur rund 10 Stunden, bis sich alle Funkuhren
umgestellt hatten. Einige brauchten nur wenige Minuten, andere 5
Stunden. Die Reichweite war erstaunlich hoch (ca. 50m bei etwa 10% der
Sendeleistung eines TDA2030)
Das Programm ebenso erstaunlich einfach und in 30 minuten geschrieben.

Seitdem sende ich wieder auf rund 9kHz, und das ist legal...

[Rolf F. (Gast)]

Und was hast Du als Sende-Antenne genommen?

[Benedikt (Gast)]

Eine 25m Rolle 5x1,5mm² Kabel, die mit einem Kondensator auf Resonanz
abgestimmt wurde.

[Rolf F. (Gast)]

Aha, dann müßte ich für größere Reichweite noch abstimmen.

[Benedikt (Gast)]

Die Spannung an der Spule steigt bei richtiger Abstimmung auf über
200Veff an, wenn man etwa 5-10Veff einspeist.

[Rolf F. (Gast)]

Also ein Kondensator in Reihe zur Spule und den Kondensator an den
Verstärker-Ausgang angeschlossen, oder?

[Benedikt (Gast)]

Ja

[lordludwig (Gast)]

danke erstmal.

gibt es davon auch ne kompilierte version weil ich hab keine Ahnung
davon???

[see4far (Gast)]

@Uli: Kann es sein, dass deine Uhr 1 sec nachgeht? Die Uhrzeit wird
nämlich schon direkt mit dem Synchronisations-Bit in der 59. Sekunde
gesetzt und ist dann zur vollen Minute schon eine Sekunde weiter als
herkömmliche Funkuhren.

Ich ziehe jetzt in der Interrupt-Routine nach dem Setzen der Uhrzeit
erstmal eine Sekunde ab.

...
    //Alle 59Bits empfangen stellen der Uhr nach DCF77 Buffer
    {
    //Berechnung der Minuten BCD to HEX
    mm = rx_buffer->Min-((rx_buffer->Min/16)*6);
    //Berechnung der Stunden BCD to HEX
    hh = rx_buffer->Hour-((rx_buffer->Hour/16)*6);
    //Berechnung des Tages BCD to HEX
    day= rx_buffer->Day-((rx_buffer->Day/16)*6); 
    //Berechnung des Monats BCD to HEX
    mon= rx_buffer->Month-((rx_buffer->Month/16)*6);
    //Berechnung des Jahres BCD to HEX
    year= 2000 + rx_buffer->Year-((rx_buffer->Year/16)*6);
    //Sekunden werden auf 0 zurückgesetzt
    ss = 0;
    Remove_one_Second();
    flags.dcf_sync = 1;
                }
...

Hier die Funktion dazu.

//############################################################################
//Zieht 1 Sekunde ab
void Remove_one_Second (void)
//############################################################################
{

  
  if (ss == 00)
  {
    ss = 59;
  
    if (mm == 00)
    {
      mm = 59;
      
      if (hh == 00)
      {
        hh = 23;
      }
      else
      hh--;//1 Stunde abziehen
    }
    else
    mm--;//1 Minute abziehen
  }
  else 
  ss--;//1 Sekunde abziehen

};

Wenn die Uhr auch ohne DCF77-Signal weiterlaufen soll, müsste man
theoretisch auch noch um 24 Uhr das Datum weiterstellen. Das müsste
dann natürlich auch bei der Remove_one_second-Funktion berücksichtigt
werden. Also um 24 Uhr erstmal einen Tag zurückspulen. Das ganze wird
dann bloß etwas komplizierter, weil man Monatswechsel (sind ja
dummerweise nicht alle gleich lang) und Schaltjahre berücksichtigen
müsste.

mfg
see4far

[Peter Dannegger (Gast)]

@see4far

" if (ss == 0000) "


Führende Nullen sollte man sich schleunigst abgewöhnen.

Unter C bedeuten sie nämlich, daß diese Zahl als Oktalzahl
interpretiert wird.

D.h. es geht nur für Zahlen <= 7 gut.

Es sei denn Du bist wirklich noch so ein Freak aus der Lochkarten-Ära,
der oktal rechnet.


Peter

[see4far (Gast)]

g ne, bin ich nicht... ursprünglich hatte ich das auch mit "00" und
nicht mit "0000" gepostet (siehe "view plain"). sieht man mal, wo
das alles falsch interpretiert werden kann. führende nullen gehören
also jetzt bei mir der vergangenheit an. wusste ich nicht.

[Peter Dannegger (Gast)]

@see4far

"Wenn die Uhr auch ohne DCF77-Signal weiterlaufen soll, müsste man
theoretisch auch noch um 24 Uhr das Datum weiterstellen. Das müsste
dann natürlich auch bei der Remove_one_second-Funktion berücksichtigt
werden."


Wie Du siehst, wird dadurch alles nur unnötig kompliziert.

Deshalb laufen bei meiner Routine die interne Uhr und der DCF77 Dekoder
völlig getrennt voneinander.

Und nur, wenn alle Fehlertests sagen, daß die DCF77-Zeit gültig ist,
wird sie einfach in die interne Uhr übernommen.

http://home.tiscali.de/peterd/appl/soft/c51/thclock/index.htm


Peter

[Clemens H. (sum)]

Hallo,

jetzt - da meine DCF77-Uhr fertig programmiert ist - finde ich diesen
Thread ... welch ein Trauerspiel.

Ich möchte dennoch meinen Code zur Verfügung stellen, vielleicht findet
ja jemand gefallen daran.

Der µC wird für folgende Zwecke "mis"braucht:
 1. 5stellige 7-Segment-LED-Anzeige ansteuern (gemuxt)
 2. Umgebungshelligkeit messen
 3. DCF77-Signal auswerten
 4. Zeit zählen (Uhr)

Ich habe mich dagegen entschlossen, den Code auf mehrere Dateien zu
verteilen, weil man dann leicht auf die Versuchung reinfällt, ihn
unbesehen in ein neues Projekt zu übernehmen und sich somit viel Mühe
mit dem Fehlersuchen machen muss.

Der DCF77-Empfangsteil arbeitet etwa wie folgt:
Bei einer Flanke am Interrupt wird dieser ausgelöst. Er löscht einen
Counter und schaltet sich selbst ab.
Nach ca. 100ms (Counter) wird angefangen, in 12ms-Abständen, den
Zustand des DCF77-Pins in ein Register zu kopieren.
Nach ca. 200ms (Counter) wird das Register an die Behandlungsroutine
(asynchron) übergeben und diese zählt die Einsen im Register und
schließt auf eine 1 oder eine 0.
Nach ca. 700ms (Counter) wird der Interrupt wieder eingeschaltet.
Nach ca. 1.6s (Counter überlauf) wird die 60. Sekunde erkannt und der
Behandlungsroutine (asynchron) gemeldet.

Die asynchrone Kommunikation geschieht über Flags in einem Register
(rStatus). Diese ist nötig, um auch die anderen Aufgaben, die der µC zu
bewältigen hat, zeitgerecht unterzubringen.

Ich hoffe, der Code ist ausreichend kommentiert. Fragen/Kritik/Fehler
höhre ich in freundlicher Wortwahl immer gerne.

Clemens

PS: der Code muss vor dem assemblieren durch den cpp ;)
Die Anzeige ist ausserdem in etwa 3900 Schritten dimmbar :))

[Christian Spahn (Gast)]

Hallo!

Zu Ulis soeit super funktionierendem Programm habe ich eine kleine
Anmerkung. Und zwar kann mein Compiler (avr-gcc) mit der folgenden
Zeile nicht so toll umgehen:

dcf_rx_buffer = dcf_rx_buffer | ((unsigned long long) 1 <<
rx_bit_counter);

Funktioniert zwar, aber ich habe mir mal das Ergebnis in Assembler
angeschaut und war nicht ganz so begeistert:
- Zuerst wird eine 64-bit große 1 angelegt.
- Diese wird dann einer Methode übegeben, die 64-bit Zahlen shiftet.
- Letzendlich werden dann dieses lange Ergebnis mit dem rx-Buffer
geodert.

Besser fände ich, die Adresse des entsprechenden Bytes auszurechnen und
nur dort die Operation mit 8-bit auszuführen. Sieht dann so aus:

((uint8_t *)&dcf_rx_buffer)[rx_bit_counter >> 3]  |= (uint8_t)(1 <<
(rx_bit_counter % 8));

Ok, sieht nicht so schön aus, allerdings wird bei mir damit das
Programm um gut 400 Byte kleiner und vermutlich auch schneller.

Und wenn ich schon am meckern bin :), den rx-Buffer würde nicht nicht
in einem "unsigned long long" halten, sonden dem Compiler überlassen,
wie er dieses Struct speichert.

Das war's aber jetzt! :-)

Viele Grüße
 Christian

[Algernon M. (algernon)]

.

Sorry, daß ich diesen alten Thread nochmal hochspüle, aber ich habe
noch Fragen dazu, die mir die Beteiligeten dank Erfahrungswerten sicher
auf Anhieb beantworten können.

Als ich das hier gelesen habe:
>>Hier mal ein neues Programm von mir für einen Atmel.
Dieses wertet ein DCF77 Signal aus und gibt es auf der seriellen
Schnittstelle aus.<<
dachte ich: Perfekt, exakt was ich lange suche.
...nur leider haben mich die nachfolgenden Postings etwas verwirrt, was
die Funktionssicherheit (Störempfindlichkeit, erst nachträglich
eingebauter Paritycheck etc.) angeht.

Leider bin ich in Assembler nicht firm genug um eure Statements
nachvollziehen zu können.

Wie verhält es sich damit, existiert eine letzte Version die stabil
läuft und auch bei störenden Magnetfeldern soweit softwareseitig
abgesichert ist, daß Sie nicht losrennt?

Vielen Dank schonmal für die Antworten.
MfG
Algernon

.

[Werner B. (Gast)]

Mein bester Tipp

http://www.ulrichradig.de

und dort im Forum weiterforschen.

[Peter D. (peda)]

@Algernon,


"Wie verhält es sich damit, existiert eine letzte Version die stabil
läuft und auch bei störenden Magnetfeldern soweit softwareseitig
abgesichert ist, daß Sie nicht losrennt?"


Also meine Versionen laufen zuverlässig seit über 10 Jahren aufm 8051.
Und die AVR-Versionen benutzen ja exakt das gleiche Prinzip.

Durch die sehr strengen Prüfungen werden wohl auch viel korrekte Pakete
weggeschmissen, aber ein Update alle 24h sollte ja dicke ausreichen.

Eine Version mit dem MAX7219 als Displaytreiber stört sich selbst
(Multiplextakt) und die Antenne wollte ich nicht extra rausführen.
Daher wird das Display um 3:17Uhr für 6min abgeschaltet, wenn innerhalb
der letzten 24h kein Empfang möglich war. Auch diese Uhr läuft seit
Jahren einwandfrei. Jeder Fehlempfang wäre nicht zu übersehen, da er ja
bis zum nächsten 3:17Uhr angezeigt würde.


Peter

[Algernon M. (algernon)]

.

Danke für die Antworten, ich werde mir die Programme mal ansehen.

Nur zur Erläuterung:
Die DCF77-Uhr brauche ich um Terrarien- und Brutkastensteuerungen
autarkt arbeiten zu lassen - Futterautomat, Beleuchtung, Temperatur-
und Feuchtigkeitsregelung etc.

Deshalb ist besonders wichtig, daß mir die Uhr sicher niemals über
längere Zeit ernsthaft Quark ausgibt, sonst bräuchte ich auch kein
DCF-Empfang sondern könnte das einfach mit einer kalibrierten Quarz-Uhr
machen. Besonders im Urlaub wäre ein Stromausfall und
unsynchronisiertes, zufälliges Anlaufen z.B. beim Brutkasten
verhängnisvoll - da kann schnell mal ein komplettes Gelege dahin sein.

Deshalb suche ich nach einer Lösung, bei der (aus Sicherheitsaspekten)
ein eigener Controller die Tages-Zeit über die Uart ausgibt. Diplay und
Datum sind irrelevant, nur wenn man schon einen eignen Zeit-Server-µC
dezentral dazuzieht muß der seine (eine) Aufgabe 100%ig verlässlich
erfüllen - deshalb meine kritische Nachfrage.

Außerdem ist es schön eine Fertiglösung in der Schublade zu haben, die
man bei allen möglichen Anwendungen einfach anstöpseln kann um über
Absolutzeiten zu verfügen.

Nochmal Danke für eure Antworten!

MfG
Algernon

.

[Steffen Schmid (Gast)]

Hi!

ich habe die DCF-77 Uhr von Ulrich Radig um einen "ewigen Kalender"
erweitert. Ist eigentlich nicht nötig, aber es kann ja vorkommen, dass
in der letzten Minute vor 0:00 Uhr ein Empfangsfehler auftritt und
somit das Datum nicht sofort umgestellt wird.

Im Monat Februar wird berechnet, ob es sich um ein Schaltjahr handelt
oder nicht.

Vielleicht kann es ja jemand gebrauchen.

MfG
Steffen

[Christian (Gast)]

Guten Abend,

ich habe auch vor für meinen Seminarkurs der Schule einen DCF-77 Sender 
zu bauen. (Umkreis <10m) Das Funksignal würde ich gerne mit einem DCF-77 
Empfänger oder einem Oszi auswerten. Wie der Empfänger realisierbar ist, 
weiß ich schon. Jetzt geht es eigentlich nur noch um den Sender. Davon 
habe ich keine Ahnung und ich würde mich gerne einmal damit 
auseinandersetzen.
Was für technische Geräte werden dafür benötigt und wie kann ich diesem 
Sender einen Impuls geben, dass er die Zeit xlz an den Empfänger 
aussendet?

Viele Grüße

Christian

[Peter D. (peda)]

Wenn Du weißt, wie ein Empfänger funktioniert, dann kannst Du auch nen 
Sender programmieren.

Einfach nen Pin-Toggle auf etwa 77,5kHz programmieren und dann für 
100ms/200ms austasten.

Bzw. wenn mans ganz genau machen will, die 77,5kHz durchlaufen lassen 
und per Spannungsteiler mit nem anderen Pin (trisate/low) auf 25% 
abschwächen.


Peter

[Christian (Gast)]

Aha, okay, ich verstehe ehrlich gesagt nur Bahnhof. Vielleicht habe ich 
mich davor auch falsch ausgedrückt. Ich kenne das Prinzip eines 
Empfängers, doch selbst gebaut habe ich jenen noch nicht.

MfG

Christian

[Markus B. (wolframator)]

Hab das Projekt mal nachgebaut und musste feststellen das nach der 
Ausgabe diverser Parameter der Rx-Counter statt bis 59 bis 75 läuft. 
Interessanter weise blinkt eine zur besseren Detektierung eines Pulses 
vom DCF77 Modul perfekt je Sekunde aber bei der Ausgabe am Terminal 
zählt der RxCounter manchmal alle ca. 0,5 Sekunden hoch was dann in 1 
Minute 75 etwa ergibt. Bei Funkuhrzeit 00 Sekunden geht das dann wieder 
auf 0. Also scheint ja nicht alles schief zu laufen. Aber wie kanns sein 
das der 5 statt den 59 hat?

/Edit:
Ja am Fenster
Ja auch mit Batterie
Nein kein 10kOhm weil dann keine Daten mehr kommen (egal ob gegen Masse 
oder gegen +5)

Modul: Das Neue von Pollin für 5 Euro

[Ulrich R. (radiguli)]

Hallo,

Ich gehe mal von zu vielen Interrupts aus. Die Anzeige wechselt bei dem 
auslösen eines Interrupts.

Gruß
Uli

[Markus B. (wolframator)]

An dem µC ist nicht anderes angeschlossen und als Quellcode sogar Deinen 
1:1 schon ausprobiert. Selbst wenn ich UART weg lasse und nur eine LED 
ansteuer wenn ein Sync gekommen ist passiert nichts.
Könnte es sein das das Modul vom Pollin ein unsauberes Signal liefert 
wenn da so viele Ints ausgelöst werden?

[Mr. Magic (Gast)]

Ich bin hobbymäßig als Zauberer unterwegs, und ich suche für einen Trick 
eine Möglichkeit eine Wanduhr mit Ziffernblattanzeige zu manipulieren.
Das heißt ein Zuschauer nennt eine Uhrzeit ,die dann im laufe der 
Vorführung auf einer Uhr ,die die ganze Zeit mit einem Tuch verdeckt 
einige Meter von mir stand auftaucht. Da ich im Forum schon etwas 
gelesen habe bin ich auf die Sache mit dem DCF77 Sender gestoßen hört 
sich sehr Interessant an da es ja Funkuhren mit Ziffferblatt schon für 
wenig Geld zu kaufen gibt. Ich muss aber noch dazu sagen ich bin auf dem 
Elektronikgebiet eine Niete , also wäre ich an einer Fertiglösung 
interessiert.

Vielleicht gibt es ja noch andere Ideen zu dieser Sache für Hinweise 
wäre ich dankbar. !!!

Mfg

Email [e-mail]

[Klaus2 (Gast)]

...und jetzt frag dich mal selbst, ob sowas wohl legal ist und es somit 
"frei verfügbar" ist?! Ich helf dir: NEIN, ist es nicht!

Zumal solche Zaubertricks eher "uns" gehören :) Du darfst nur mit 
Tüchern und Hasen spielen gähn

Klaus.

[Philipp B. (philipp_burch)]

Da wird deine Vorführung sehr lange dauern müssen, da viele Funkuhren 
nur ein- bis zweimal pro Tag synchronisieren. Normalerweise ändert sich 
die Uhrzeit ja nicht "einfach so".

[Pete K. (pete77)]

Hat jemand schon einmal das Programm mit dem Pollin-Modul getestet ? 
Sind Änderungen notwendig ?

[Jonny (Gast)]

Überlege auch gerade ob ich mir das Pollin modul für 5 öcken kaufen 
sollte!
Wäre schön wenn jemand seine Erfahrung mit uns teilen würde, ob das 
Modul mit dem Code von Uli läuft!

Abendliche Grüße :-)

[CHH (Gast)]

Hi Jonny ...
Ich habe mir kürzlich zwei Pollin DCF Module gekauft ... für mich 
persönlich ein Griff in's Kloo :(

Erster Problem: Das Pollin Modul braucht an einem Anschluß einen 
Flankenweschel nach dem Stromanlegen - wenn der nicht erfolgt empfängt 
das Modul nicht ... hier ist also entweder ein zusätzlich Ausgang am 
Controller notwendig - oder externe Elektronik.

Zweites Problem: Das Modul ist extrem Anfällig für Störimpule - ich hab 
es ehrlich gesagt nicht hinbekommen mal für 2 Minuten nen sauberen 
Empfang zu haben ...

Ich habe noch ein Modul von Conrad, für 10 €, das schließt du an und 
fertig ...

Von daher würde ich vom Pollin Modul abraten ...

[Gast (Gast)]

Moin!

ich hab ein Modul von Pollin, 5 euro, und des funzt super.

Hab PON u GND verbunden, damit das Modul immer arbeitet. Im 
Netzteil-Betrieb voll OK, u bei wenigen µA Strom auch für Batterie OK 
denke ich.

laut Beschreibung braucht das Modul nach dem starten bis zu 20 min, um 
sich auf's Signal einzupendeln.
Ich habe den Empfänger in einer Werkstatt bei der Arbeit getestet und 
das Signal mit einem Datenschreiber aufgenommen, und das Ergebnis ist 
perfekt.
die werkstatt is was funksignale angeht ein Graus, viele metallregane, 
hunderte netzteile, diverse andere dinge, die den funkempfang stören 
könnten...

aber ob das modul letztenendes funktioniert hängt angeblich auch u.a. 
von der ausrichtung ab.

Greetz from Hamburg

[Falk B. (falk)]

@  Gast (Gast)

>laut Beschreibung braucht das Modul nach dem starten bis zu 20 min, um
>sich auf's Signal einzupendeln.

Eher 20s.

[Abdul K. (ehydra)]

Nach meiner Erfahrung brauchen die gängigen '(verschiedenen) Uhren 2-3 
Minuten. Der Erkennungsalgorithmus scheint eher primitiv. Würde sagen:
1. Minute: Suche nach Minuten-Anfang
2. Minute: Einlesen der Uhrzeut
3. Minute: Vergleich mit 2. Minute ob gültig


Gruß -
Abdul

[Jochen K. (jkunz)]

Ich spiele auch grad mit so einem DCF77 Empfangsmodul von Pollin rum. 
Das ist wirklich zickig. Je nach Ort empfängt es garnix, nur Müll oder 
läuft absolut stabil.

Wenn es fertig ist soll es die unvermeidliche Nixi-Uhr werden.

Schpäschel Fietschers:

- Der DFC77 Decoder erkent die Polarität (invertiert oder nicht) des 
DCF77 Signals automagisch.

- Einige Konsistenzprüfungen um Fehlempfang zu vermeiden.

- Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt 
dessen werden sie statisch mit einer länglichen 74HCT959 Kette + 
Wagenladung MPSA42 angesteuert.

- Quazuhr mit DCF77 Kalibration. Die Uhrzeit kommt von einer Quazuhr, 
die bei korrektem Empfang jede Minute mit der DCF77 Zeit synchronisiert 
wird. Die Qurzuhr sorgt somit auch bei gestörtem Empfang für eine 
richtige Zeitanzeige. Bei konstant gutem Empfang nutzt das Programm die 
DCF77 Zeit als Referenz um die Quarzuhr zu kalibrieren. Die Abweichung 
wird noch im EEPROM des AVR gespeichert. Die Auflösung ist 1:64000 = ca. 
16 ppm = ca. 1 Sekunde in 18 Stunden. Das kann man noch genauer machen 
(siehe AVR - Die genaue Sekunde / RTC), aber da die Quarzuhr 
normalerweise öfter als alle 18 Stunden auf das DCF77 Signal 
synchronisiert wird, ist das mehr als genau genug.

Das ist noch nicht fertig, aber ich häng die vorläufige Version mal an. 
Es gibt noch einige Unzulänglichkeiten, z.B. eine Race-Condition beim 
Hochzählen von cal_tics... Die wesentlichen Funktionen stehen aber und 
vielleicht ist es ja jemandem von Nutzen.

[Abdul K. (ehydra)]

Du meist dein Empfangsmodul mal einige Tage durchlaufen lassen. 
Normalerweise findet es immer einige brauchbare Daten innerhalb 24 
Stunden. Mehr kannst du von diesen Schrottteilen leider nicht erwarten.

Wenn es dir nicht zuviel Aufwand ist, einfach die Antenne abändern in 
einen größeren Stab und korrekt ausrichten. Das L und C der Antenne mußt 
du dann natürlich entsprechend anpassen.


Gruß -
Abdul

[Jochen K. (jkunz)]

CHH schrieb:

[Pollin DCF77 Modul]
> Zweites Problem: Das Modul ist extrem Anfällig für Störimpule - ich hab
> es ehrlich gesagt nicht hinbekommen mal für 2 Minuten nen sauberen
> Empfang zu haben ...
Ich hatte die Tage auch erhebliche Probleme mit dem Pollin Modul. Es 
stellte sich heraus, dass mein provisorischer Aufbau eine unsaubere 
Masseführung hatte. Das hat die Versorgungsspannung mit Störimpulsen von 
den TTL Keksen verseucht. Das scheint das Modul garnicht zu mögen. 
Störungen auf der Versorgungsspannung schlagen offenbar voll in den 
Empfänger durch und bringen ihn ins Schleudern. Auch 
Abblockkondensatoren (10 uF Elko und 100 nF KerKo) direkt auf dem Modul 
halfen nicht. Mit sauberer, sternförmiger Führung von Masse und 
Versorgungsspannung in der ganzen Schaltung arbeitet das Modul sehr 
stabil. Meine Auswertung betreibt etwas Statistik. Der Empfang läuft 
jetzt seit über zwei Stunden stabil, die Low-Pulse liegen alle zwischen 
100 ms und 120 ms, die High-Pulse zwischen 200 ms und 220 ms. Dabei 
liegt das Modul nur ca. 30 cm neben einem 21" Röhrenmonitor auf dem 
Schreibtisch.

[Z8 (Gast)]

>30 cm neben einem 21" Röhrenmonitor

Du wohnst doch wohl nicht in Mainflingen? :) Z8

[Johann L. (gjlayde)]

Jochen Kunz schrieb:
> Ich spiele auch grad mit so einem DCF77 Empfangsmodul von Pollin rum.
> Das ist wirklich zickig. Je nach Ort empfängt es garnix, nur Müll oder
> läuft absolut stabil.

-- Richtig ausrichten
-- Keine SNT/SMPS in der Schaltung (HV für die Nixies?)
-- keine µC, geMUXte Anzeigen etc in unbittelbarer Nähe
-- möglichst keine Metallteile (Stahlbeton, ...)

Der Empfang ist bekanntermaßen tageszeit- und witterungsabhängig.

> - Einige Konsistenzprüfungen um Fehlempfang zu vermeiden.

Eine meiner Uhren tickt in Wien, da ist die Empfangslage bekanntermaßen 
übel. Ich musste die Keule auspacken, aber demit geht die Uhr ;-)
   http://www.gjlay.de/pub/dcf77/konzept.html

> - Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt
> dessen werden sie statisch mit einer länglichen 74HCT959 Kette +
> Wagenladung MPSA42 angesteuert.

Schliesst MUX ja nicht aus.

> - Quazuhr mit DCF77 Kalibration.

Wieso ne Quarzuhr? Es reicht doch der normaler Quarz, der den µC 
antickt. Kalibrierung ist bei der guten Empfangslage in D nicht nötig, 
da alle naselang eni Abgleich stattfindet.

> Das ist noch nicht fertig, aber ich häng die vorläufige Version mal an.
> Es gibt noch einige Unzulänglichkeiten,

fehlt zB die Tomatensosse zum Spaghetti-Code fg

[Jochen K. (jkunz)]

Johann L. schrieb:
> Jochen Kunz schrieb:
>> Ich spiele auch grad mit so einem DCF77 Empfangsmodul von Pollin rum.
>> Das ist wirklich zickig. Je nach Ort empfängt es garnix, nur Müll oder
>> läuft absolut stabil.
> -- Richtig ausrichten
Klar. Breitseite der Antenne => FFM.

> -- Keine SNT/SMPS in der Schaltung (HV für die Nixies?)
Schnöde, altmodische 50 Hz Trafos mit Längsregler. (HV für die Nixis 
macht ein "verkertherum" geschalteter Netztrafo.)

> -- keine µC, geMUXte Anzeigen etc in unbittelbarer Nähe
Ohne uC wird es schwer. Anzeige wird auch as dem Grund nicht gemuxt.

> -- möglichst keine Metallteile (Stahlbeton, ...)
Klar.

> Der Empfang ist bekanntermaßen tageszeit- und witterungsabhängig.
>
>> - Einige Konsistenzprüfungen um Fehlempfang zu vermeiden.
> Eine meiner Uhren tickt in Wien, da ist die Empfangslage bekanntermaßen
> übel. Ich musste die Keule auspacken, aber demit geht die Uhr ;-)
>    http://www.gjlay.de/pub/dcf77/konzept.html
Verglichen mit dem Aufwand ist mein Kram harmlos. Aber Kaiserslautern 
liegt etwas näher am Sender als Wien... :-)

>> - Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt
>> dessen werden sie statisch mit einer länglichen 74HCT959 Kette +
>> Wagenladung MPSA42 angesteuert.
> Schliesst MUX ja nicht aus.
Wenn man muxt könnte man sich aber auf Kosten eines uC mit mehr IO-Pins 
die 74595 sparen...

>> - Quazuhr mit DCF77 Kalibration.
> Wieso ne Quarzuhr? Es reicht doch der normaler Quarz, der den µC
> antickt.
Genau das meine ich ja mit Quarzuhr.

> Kalibrierung ist bei der guten Empfangslage in D nicht nötig,
> da alle naselang eni Abgleich stattfindet.
Idee: Soll die Uhr irgendwo mit schlechtem Empfang stehen läuft sie 
wegen fehlender Synchronisation weg. Wenn man sie aber vorher mal einen 
Tag irgendwo bei gutem Empfang stehen lässt, wird der Quarz kalibriert, 
die Abweichung in EEPROM gespeichert und nach dem Ortswechsel hat man 
vielleicht keine DCF77 Uhr mehr, aber immerhin eine kalibrierte 
Quarzuhr.

>> Das ist noch nicht fertig, aber ich häng die vorläufige Version mal an.
>> Es gibt noch einige Unzulänglichkeiten,
> fehlt zB die Tomatensosse zum Spaghetti-Code *fg*
Die Spaghetti sind ja auch noch nicht al dente. ;-)
Die von mir eingestellte, vorläufige Version hat mindestens einen Bug 
beim einlesen des Bit 58 (Parity Datum).

[Johann L. (gjlayde)]

Jochen Kunz schrieb:
> Johann L. schrieb:
>> Jochen Kunz schrieb:
>>> - Die Nixis werden nicht gemuxt, da einige Nixis das nicht mögen. Statt
>>> dessen werden sie statisch mit einer länglichen 74HCT959 Kette +
>>> Wagenladung MPSA42 angesteuert.
>> Schliesst MUX ja nicht aus.
> Wenn man muxt könnte man sich aber auf Kosten eines uC mit mehr IO-Pins
> die 74595 sparen...

Schon, aber mit Expandern hat man alle Optionen offen.

Die sind schnell genug, um auch über SPI ein Soft-MUX zu fahren. Auf 
diese Weise kann man dann auch Kathoden der selben Röhre gegeneinander 
MUXen um fliessende Übergänge benachbarter Zahlen/Ziffern zu 
realisieren, darüber wird dann nochmal geMUXt, um die Helligkeit der Uhr 
einzustellen (zB an die Umgebungshelligkeit anzupassen).

Ohne Expander hat man viel weniger Freiheiten was die Ansteuerung 
angeht.
Und wie gesagt... mögen/können nicht alle Nixies auf MUX.

Johann

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Die Pollin-Module sind dafür bekannt, dass sie auf der steigenden Flanke 
einen überlagerten Rechteck haben. Je nach Empfindlichkeit des Eingangs, 
an dem das Modul angeschlossen wird, kann das zu zusätzlich erkannten 
Impulsen führen. Ein Schmitt-Trigger oder Debouncing wie bei Tasten 
hilft ab.

[Denny S. (nightstorm99)]

Hallo!

Ich benutze die Sourcen von U. Radig seiner Homepage!
Also Version 1.5!

Soweit läuft alles super und Empfang habe ich auch gut (Modul vom C),
aber bei jedem Stundenwechsel zählt er eine Stunde zu weit und
nach ca. 2 min stimmt die Zeit dann wieder vom DCF.

Hatt jemand von euch schon das Problem gehabt?
Was kann ich ändern daran?

Danke
Gruß Denny

[Mike (Gast)]

Hi, gibs dazu auch eine Anleitung für doofe ?
Ich würde gern die DCF77 Zeit an RS232 senden.
Da bin ich hier doch richtig oder ? ;-)

[sebastians (Gast)]

Hallo,
bei mir (mit 1MHz Takt am AVR) funktioniert die Erkennung der Pulsbreite 
nicht richtig. Ich nehme an, sie funktioniert wenn man den AVR höher 
taktet und damit weniger Rundungsfehler bekommt.

Das Problem liegt in dieser Zeile:

if (pulse_wide > (65535 - (SYSCLK / 1024)/100*85))

Statt SYSCLK habe ich F_CPU genommen, und das ist 1000000.

So funktioniert es bei mir:

static const uint16_t pulse_compare = 65535 - (uint32_t)F_CPU*85UL/(1024UL*100);
// 64705 for  F_CPU=1000000

...

if (pulse_wide > pulse_compare)

Der 32-bit-Wert läuft irgendwo um die 50MHz CPU-Takt über - ab da gehts 
so nicht mehr.

[Rolf P. (rolfp)]

sebastians schrieb:
> Das Problem liegt in dieser Zeile:
>

 if (pulse_wide > (65535 - (SYSCLK / 1024)/100*85))

Die einten Klammern sind eh überflüssig:
if (pulse_wide > (65535 - SYSCLK/1024/100*85))
jetzt noch die Division mit 1024 an den Schluss nehmen:

if (pulse_wide > (65535 - SYSCLK/100*85/1024))

Das müsste dann aufs gleiche rauskommen wie deine Variante.

Rolf

[sebastians (Gast)]

> Das müsste dann aufs gleiche rauskommen wie deine Variante.
Nicht ganz. Meine Variante macht keinen Rundungsfehler wenn SYSCLK nicht 
durch 100 teilbar ist. Zugegeben, das ist ziemlich unwahrscheinlich. 
Deine Variante ist sogar besser weil da keine so großen 
Zwischenergebnisse rauskommen (also gibts nicht so schnell einen 
Überlauf).

[Rolf P. (rolfp)]

sebastians schrieb:
> Nicht ganz. Meine Variante macht keinen Rundungsfehler wenn SYSCLK nicht
> durch 100 teilbar ist. Zugegeben, das ist ziemlich unwahrscheinlich.

Stimmt, es könnte einen Rundungsfehler geben. Dieser ist aber viel 
kleiner als der Rundungsfehler den wir beim Dividieren durch 1024 
machen. Im schlimmsten Fall haben wir schlussendlich statt einer 
Abweichung von 1.0 eine Abweichung von 1.083. Wenn es genauer sein 
müsste, könnte man noch etwas besser runden:

if (pulse_wide > (65535 - (SYSCLK/100*85+512)/1024))

Dann hätte man eine maximale Aweichung von +-0.583.

Rolf

[blablu (Gast)]

DFC 77 ist doch viel zu lahm, nur 1 baud

[David V. (davidos)]

Hallo zusammen, hat jemand hier den code von Uli auf ein Atmega8 
umgeschrieben, bitte posten Sie es.
David

[Thorsten J. (thjoos)]

Hallo, ich habe den Code für einen Atmega161 angepasst, vielleicht hilft 
es weiter. Jedoch habe ich eine Compiler-Meldung, die mir rätselhaft 
ist. Wäre schön wenn mir diese Meldung jemand erklären könnte. Wird im 
Code von Uli irgendwo Speicher zugeteilt, der aber nicht genutzt wird? 
Mir ist nichts bekannt. Danke.

Thorsten

Creating load file for EEPROM: main.eep

avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \

        --change-section-lma .eeprom=0 -O ihex main.elf main.eep

c:\Programme\WinAVR-20100110\bin\avr-objcopy.exe: --change-section-lma 
.eeprom=0

x00000000 never used

[Petr K. (buzzer_klaun)]

Hello friends,

I'm trying to retrieve data from DCF. But unsuccessfully.

Therefore, I want to ask if someone could not help.

DCF signal is connected to pin PD3 (INT1).
Tact = 16MHz MCU.

Sorry that I write in English, but German is not my forte. :)

Easy program to sync from DCF.
clock.c -> http://paste.ofcode.org/fDcJLsYJTuhL8JZXDit5mr
clock.h -> http://paste.ofcode.org/Zzp3Vgpqysv27FQLTAzcPe
main.c  -> http://paste.ofcode.org/XVn5WDfup3xfg7qAWJi5X5

Complet program with DS3232, etc. is here:

[Petr K. (buzzer_klaun)]

So the my problem is here:
TIMER1 doesn´t working.
But when I disable external interrupt, so theTIMER1 working normaly. 
Test by blink LED.
So why the TIMER1 is not working?? And F_CPU is 16000000.
The critical section is here: 
http://paste.ofcode.org/nvfTeaVQwPB3pMAuWB62Z3

Any idea, how this problem resolved?

[rolfp (Gast)]

Petr K. schrieb:
> The critical section is here:
> http://paste.ofcode.org/nvfTeaVQwPB3pMAuWB62Z3

I always get error 404 with this link.
Also tried to read Clock.rar, but it was much too big.

Rolf

[Petr K. (buzzer_klaun)]

Problem was resolved. Here is my code. Working fine. :)

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <string.h>

#include "DCF77.h"

/* Promenne pro DCF */
//volatile uint8_t dcf_active = 0;
volatile uint8_t breakcount = 0;
//volatile uint8_t array_count = 0;
//volatile uint8_t dcf_array[60];
volatile uint8_t timecount = 0;

//volatile uint8_t parity = 0;
//volatile uint8_t minute_dcf, DCFminute;
//volatile uint8_t hour_dcf, DCFhour;

void dcf77_init (void) {
  //Timer init
  TCCR0 |= (1<<CS02) | (1<<CS00);  //Pre 1024 -> 0,016384s
  TIMSK |= (1<<TOIE0);
  //externer Interrupt
  MCUCR |= (1<<ISC11) | (1<<ISC10);
  GICR |= (1<<INT1);
}

void dcf77_time(void) {

  parity = 0;
  hour_dcf = 0;
  minute_dcf = 0;
  
  /*pocatecni hodnoty (kvuli mozne chybe)*/
  DCFhour = 25;
  DCFminute = 61;
  
  /* Minutes */
  if (dcf_array [21] == 1) {  //minute 1
    minute_dcf = 1;
    parity++;
  }
  if (dcf_array [22] == 1) {  //minute 2
    minute_dcf += 2;
    parity++;
  }
  if (dcf_array [23] == 1) {  //minute 4
    minute_dcf += 4;
    parity++;
  }
  if (dcf_array [24] == 1) {  //minute 8
    minute_dcf += 8;
    parity++;
  }
  if (dcf_array [25] == 1) {  //minute 10
    minute_dcf += 10;
    parity++;
  }
  if (dcf_array [26] == 1) {  //minute 20
    minute_dcf += 20;
    parity++;
  }
  if (dcf_array [27] == 1) {  //minute 40
    minute_dcf += 40;
    parity++;
  }
  
  if (dcf_array [28] == 1) {  //kontrolni bit ?
    if (parity == 1 || parity == 3 || parity == 5 || parity == 7) {
      parity = 0;
      DCFminute = minute_dcf;
    }
  }
  else {              //kontrolni bit ?
    if (parity == 0 || parity == 2 || parity == 4 || parity == 6) {
      parity = 0;
      DCFminute = minute_dcf;
    }
  }
  
  /* Hours */
  if (dcf_array [29] == 1) {  //hodina 1
    hour_dcf = 1;
    parity++;
  }
  if (dcf_array [30] == 1) {  //hodina 2
    hour_dcf += 2;
    parity++;
  }
  if (dcf_array [31] == 1) {  //hodina 4
    hour_dcf += 4;
    parity++;
  }
  if (dcf_array [32] == 1) {  //hodina 8
    hour_dcf += 8;
    parity++;
  }
  if (dcf_array [33] == 1) {  //hodina 10
    hour_dcf += 10;
    parity++;
  }
  if (dcf_array [34] == 1) {  //hodina 20
    hour_dcf += 20;
    parity++;
  }
  
  if (dcf_array [35] == 1) // pokud je parita shodna tak
  {
    if (parity == 1 || parity == 3 || parity == 5) //pokud jsou parity liche tak pricti +1
    {
      DCFhour = hour_dcf;
      parity = 0;
    }
  }
  else
  {
    if (parity == 0 || parity == 2 || parity == 4 || parity == 6) //pokud jsou parity sude
    {
      DCFhour = hour_dcf;
      parity = 0;
    }
  }
    
  sekundy = 0;  //vynuluje sekundy
  
  synchronize++;  //inkrementuje priznak, synchronizace
}

ISR (INT1_vect) {      //External interrupt
  TCNT0 = 0;        //Restart TIMER0
  dcf_active = 1;      //set flag dcf_active to 1
  GICR &= ~(1<<INT1);    //Deactive INT1
}                

ISR (TIMER0_OVF_vect) {  //TIMER0 - every 16,384ms
  if (dcf_active) {
    if ((breakcount > 92) && (breakcount < 170)) //Signal pause > 1,5s a <2,8s
    {    
      if (array_count >= 58){  //Array full?
        //PORTB ^= (1<<PB3);  //indicate data on array_count blink led
        dcf77_time();  //function to decode dcf
      }
      breakcount = 0;    //set breakcount to 0
      array_count = 0;  //set array_count to 0
      GICR |= (1<<INT1);    //active external interrupt INT1
    }
    breakcount = 0;
    if (PIND & (1<<PD3))    //is PD3 HIGH
      timecount++;      //increment timecount
    else  {            //now is low level on PD3
      if ((timecount >= 4) && (timecount <= 7))    //low bit def. 0,1s = log0 
      {
        dcf_array [array_count] = 0;  
        array_count++;
      }
      if ((timecount >= 10) && (timecount <= 13))    //high bit def. 0,2s = log1
      {
        dcf_array [array_count] = 1;  //high bit
        array_count++;
      }
      dcf_active = 0;  //flag dcf_active set to 0
      timecount = 0;  //restart timecount
      GICR |= (1<<INT1);  //enable external interrupt
    }
  }
  else
    breakcount++;        //increment breakcount
}