Announcement: there is an English version of this forum on Guten Abend, ich wollte gern wissen ob ich DCF77 Empfänger immer an einem Interrupt Pin betreiben kann oder ob es auch über jeden anderen Pin gehen kann. Hier mein der Code und die Lib die ich verwende. https://docs.google.com/file/d/0B8CnI1PuBigbRndmc3BoZ1U5NnM/edit?usp=sharing An Pin 2 + 3 läuft er aber an allen anderen nicht.
Diese Lib geht nur mit Interruptfähigen Pins. Bei besseren Mikrocontrollern sind alle GPIOs interruptfähig, bei den billigen Hobbycontrollern nur einige wenige.
Habe arduino uno r3, heißt das jetzt das ich nur Pin 2 und 3 nutzen kann?
Hallo; wenn du die lib so wie sie ist, vermutlich. Aber, du kannst ja auch eine andere Art der Auswertung verwenden, nicht unbedingt interuptbasiert, nur eine idee.
DCF-77 sendet ja mit ner wahnsinns Datenrate von 1bit/s, da brauchts keinen Interruptpin. Im Gegenteil, ohne Interruptpin ist die Auswertung sogar deutlich einfacher. Einfach mit Timerinterrupt 10ms die Zeit bis zur nächsten Flanke abzählen, dazu reicht ein Byte als Zähler aus.
SuperD schrieb: > ... bei den billigen Hobbycontrollern nur einige wenige. Du glaubst doch nicht ernsthaft, das irgendein Prozessorhersteller extra für den Hobbybereich einen Prozessor designet?
Ein DCF77 Empfänger gehört NICHT an einen Interrupt Pin. Sofern das irgendeine Lib verlangt, würde ich sie nicht benutzen weil der Programmierer dann vermutlich nicht sehr fähig war. Das Signal ist so langsam das kann man direkt ablesen und dekodieren. Außerdem ist es nicht so optimal nur auf die Flankenwechsel zu schauen. Da gibts sinnvollere Methoden wie Faltung usw. Schwieriger zu implementieren, aber besser im Betrieb!
Wenn es doch ach so leicht geht wieso gibt es dann für Avr und arduino noch keine solche Lösung?
Peter Dannegger schrieb: > DCF-77 sendet ja mit ner wahnsinns Datenrate von 1bit/s, da brauchts > keinen Interruptpin. Unbedingt brauchen tut man keinen, das ist wahr. > Im Gegenteil, ohne Interruptpin ist die Auswertung sogar deutlich > einfacher. Das allerdings ist Unsinn. Wenn man den ICP-Int verwendet, ist die Auswertung ganz genauso einfach. > Einfach mit Timerinterrupt 10ms die Zeit bis zur nächsten Flanke > abzählen, dazu reicht ein Byte als Zähler aus. Siehste, den Solms kann man sich dann nämlich schon sparen. Statt des nutzlosen Rechenzeitverbrauchs von hundert ISRs/s hat man mit der ICP-Variante nämlich bloß durchschnittlich knapp zwei. Also weniger als 2% des Rechenzeitverbrauchs der Variante mit Timerüberläufen. Der Unterschied kann schon durchaus wichtig sein. Jedenfalls wenn der Controller auch noch was anderes machen soll, als nur den DCF-Empfang.
Dafür bremst dann schlechter Empfang das Teil stark aus. Für DCF-Empfang reicht ein Timer, welcher 4mal in der Sekunde den Pegel checkt. Hat man mehr Reserven, kann man die Frequenz erhöhen und so schlechten Empfang detektieren und berücksichtigen. Der Vorteil beim Timer ist, das man vorher schon weiß, wie oft dessen Routine durchlaufen wird. Gibt es noch mehr zu tun, kann man nach (sichergestelltem) erfolgreichem Empfang für einige Stunden den Takt auf 1Hz ändern. Ist diese Frequenz recht genau, reicht es, wenn erst wieder von 01:58 bis 02:02 und von 02:58 bis 03:02 die interne Zeit abgeglichen wird. Wertet man das Datum aus und baut die Sommer-/ Winterzeitregeln mit ein, reicht 1 Zeitkontrolle / - Einstellung pro Tag. Meine DCF-Uhren haben einmal pro Stunde die Zeit abgeglichen. Seitdem ich "überall" RaspPis verwende, stellen diese ihre Uhrzeit per NTP über den Router. Mein Radiowecker nutzt beides, falls das Internet mal ausfällt.
Peter R. schrieb: > Dafür bremst dann schlechter Empfang das Teil stark aus. Tatsächlich? Nach meiner Beobachtung liefern die üblichen DCF77-Empfänger bei schlechtem Empfang, egal ob durch zu geringe Feldstärke oder zu starke Störungen einfach garkeine Pegelwechsel mehr. Wo nix wackelt, da kein ISR-Aufruf... Aber es wird möglicherweise einen Übergangsbereich geben (auch wenn es mir nie gelungen ist, den zu erreichen), in dem vielleicht der Träger durchdringt. Gegen solche Situation hilft der "noise canceller", den ICP in Hardware bereitstellt und eine sinnvolle Auswertelogik, die dann einfach den Kram temporär deaktiviert.
c-hater schrieb: > Das allerdings ist Unsinn. Wenn man den ICP-Int verwendet, ist die > Auswertung ganz genauso einfach. Nö ist umständlicher. Du hast mehr Code, da Du sämtliche Impulszeitrechnungen und Vergleiche nun 16bittig machen mußt. c-hater schrieb: > Jedenfalls wenn der > Controller auch noch was anderes machen soll, als nur den DCF-Empfang. Das ist Quatsch. Ein 10ms Interrupt stellt für den AVR keine merkbare CPU-Last dar. Ein Routine mit <1% CPU-Last lohnt sich nicht, noch weiter zu optimieren. Ein 10ms Interrupt ist aber für weitere Sachen noch recht nützlich, z.B. Tasten entprellen, Blink-LEDs, interne Uhr bei Empfangsstörungen usw.
Angehängte Dateien:
-
Pollin810054.png
210 KB
c-hater schrieb: > Nach meiner Beobachtung liefern die üblichen DCF77-Empfänger bei > schlechtem Empfang, egal ob durch zu geringe Feldstärke oder zu starke > Störungen einfach gar keine Pegelwechsel mehr. Wo nix wackelt, da kein > ISR-Aufruf. Geht es um einen bestimmten Empfänger? Ich verstehe die Frage allgemein. Hier mal meine Beobachtung mit dem Pollin-Empfänger bei unterschiedlichem Empangssituationen (s. Bild) zur allgemeinen Information. Allerdings muss ich zugeben, dass mir das zu komplex wird. Auf Faltung o.ä. ^^ würde ich gern verzichten. Ich habe mich jetzt für den den DCF2 von ELV entschieden. Nur so als Gedanke: Der ist zwar teurer, aber dafür nehme ich nur einen und platziere ihn an einer Stelle mit gutem Empfang. Ich verteile das Zeitsignal (Beacons) per NRF24L01+ weiter an alle µCs, die wissen wollen, wie spät es gerade ist. Dann haben diese nach einem Reset auch sofort die Uhrzeit parat.
Stefan Anderson schrieb: > Wenn es doch ach so leicht geht wieso gibt es dann für Avr und arduino > noch keine solche Lösung? Um die Frage noch zu beantworten: Weil wir es hier mit dem gemeinen Arduino-Programmierer zu tun haben, der um Interrupts einen Bogen macht, wie der Teufel ums Weihwasser. Der geimeine Arduino-Programmierer instantiiert sich ein Objekt von der DCF-Klasse und erwartet, dass er von der die aktuelle Zeit kriegt. Und zwar ohne, dass er vorher irgendwelche Polling-Mechanismen an irgendwelche Timer anhängt, die er nicht versteht, oder dass er (Gott bewahre) aus loop() heraus möglichst gleichmässig eine Methode der DCF-Klasse aufrufen muss, die dann das Sampling bzw. die Auswertung davon macht. Sorry, wenn das jetzt etwas sarkastisch klingt. Aber so sieht die Realität nun mal aus. Siehe zb den TO, der trotz vorhandenem Code nicht in der Lage ist, selbst die Frage zu entscheiden: externer Interrupt - ja oder nein.
:
Bearbeitet durch User
Stefan Anderson schrieb: > Gibt es da schon was fertiges? Wie unsportlich ... SuperD schrieb: > bei den billigen Hobbycontrollern ... schliesst sich irgendwie gegenseitig aus. Die sind teuer die Dinger. Peter Dannegger schrieb: > Du hast mehr Code, da Du sämtliche > Impulszeitrechnungen und Vergleiche nun 16bittig machen mußt. Ach Peter! Musst Du nicht! Takte den Controller mal langsamer ... Peter Dannegger schrieb: > Ein 10ms Interrupt ist aber für weitere Sachen noch recht nützlich, z.B. > Tasten entprellen, Blink-LEDs, interne Uhr bei Empfangsstörungen usw. ... Multiplexanzeige (ich bevorzuge dann allerdings 4ms - da bekommt man dann in einem Byte auch noch 1s gezählt) Gruß Jobst
c-hater schrieb: > Nach meiner Beobachtung liefern die üblichen DCF77-Empfänger bei > schlechtem Empfang, egal ob durch zu geringe Feldstärke oder zu starke > Störungen einfach garkeine Pegelwechsel mehr. Wo nix wackelt, da kein > ISR-Aufruf... Ich verwende hier einen DCF-77-Empfänger von Conrad. Da ich meine Uhr mit einer zusätzlichen Empfangsled ausgestattet habe, kann ich schön die Empfangsqualität beurteilen. Zumindest bei mir ist es so, dass ab etwa 17 Uhr die LED nur noch flackert. Ich habe da spaßeshalber mal den Oszi angeschlossen und bis zu 100 Pegelwechsel gemessen. Auch wenn dies den Prozessor nicht an die Leistungsgrenze bringen wird, ist es doch ein schlechter Programmierstil. Da im µC die Uhr meistens in Software realisiert wird, kann es vorkommen, dass durch die vielen DCF-Interupts einige Timer-Interupts verloren gehen, wodurch die Uhr zunehmend falsch geht. Außerdem wird der Timer-Interupt sowieso für die Uhr benötigt. Was liegt also näher, den in einer sinnvollen Zeitspanne (10ms) überlaufen zu lassen, beim Überlauf das DCF-Pin abzufragen und danach die Zeit für die Sekunde hochzuzählen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.