Nebend,
eben gerade wieder in der Artikelsammlung entdeckt.
Warum grassiert auch noch im Jahre 2013 die Unsitte, bei DCF-Projekten
den Empfänger an den Interruptpin anzuschließen und im Worst-Case den µC
in Interrupts absaufen zu lassen?
Dabei existiert doch eine breite Palette an eleganten und ausführlichst
diskutierten Lösungen mit Polling, Faltung über Haar-Wavelets bis hin
zum kompletten Korrelations-Empfänger im FPGA. Allesamt hier
vorgestellt.
Wie kommt man auf die Idee, dass man auf ein Signal, das sich maximal 1
Mal pro Sekunde ändert, unverzüglich und sofort reagieren muss?
Ich werde es nie verstehen.
Beste Grüße, Marek
Man muss nicht unbedingt unverzüglich auf das Signal reagieren. Aber man
kann. Ich möchte gerne eine Gegenfrage stellen: Was stört Dich daran?
Ich keine, gerade bei der erwarteten Frequenz ist wohl kaum damit zu
rechnen, dass der Mikrocontroller mit zu vielen Interrupt überfordert
wird.
Wenn man den Sekunden-Takt und das DCF Signal per Interrupt empfängt,
kann das Hauptprogramm für die Darstellung der Anzeige dienen. Sicher
kann man das auch anders herum machen (Interrupt für die Anzeige und
Hauptprogramm für den Empfang). Ist doch gleichwertig.
Dir ist aber schon klar, dass Pollen mehr Rechenleistung verbraucht, als
2 Interrupts pro Sekunde. Falls jemand im Umkreis von 200 km um
Mainflingen wohnt, reicht das vollkommen.
> und im Worst-Case den µC in Interrupts absaufen zu lassen?
Der µC sollte auf beide Flankenwechsel reagieren, nicht auf einen
Dauerzustand. Sicherlich sind vor allem bei schwachen Signalen andere
Methoden von Vorteil.
> Interrupt für die Anzeige und Hauptprogramm für den Empfang> Ist doch gleichwertig
Das sehe ich nicht als gleichwertig an, vor allem, wenn der
DCF77-Empfang nicht die Hauptaufgabe des µCs darstellt. Interrupts sind
das Multitasking des kleinen Mikrocontrollers.
Stefan us schrieb:> Man muss nicht unbedingt unverzüglich auf das Signal reagieren. Aber man> kann. Ich möchte gerne eine Gegenfrage stellen: Was stört Dich daran?> Ich keine, gerade bei der erwarteten Frequenz ist wohl kaum damit zu> rechnen, dass der Mikrocontroller mit zu vielen Interrupt überfordert> wird.
Was er meint: Wenn der Empfänger keinen Empfang hat, dann ist nicht
gesagt, dass der Ausgang auch ruhig bleibt.
OK, kann man machen.
Aber der Regelfall ist ja eher so, dass man eine interne Uhr hat, die
eigenständig läuft und einmal am Tag synchronisiert man die. In der Zeit
wird der Interrupt aktiviert und in der Zwischenzeit ist er ganz einfach
deaktiviert.
Moin,
eben das meine ich: Man sollte immer von einem maximal gestörten Kanal
ausgehen. Schlimmstenfalls wackelt der Empfänger-Ausgang ständig, wenn
ein gestörtes Signal (früher waren es die Röhrenmonitore) empfangen
wird. Der Controller würde von einem Interrupt zum anderen springen,
ohne auch nur annähernd was gescheites dekodieren zu können.
Eine elegantere Lösung wäre es doch, z.B. den Empfänger-Pin z.B. alle 10
ms abzufragen und die Zustände in einem Akkumulator aufzuintegrieren.
Damit hätte man schon eine gewisse Mittelung und Bandbegrenzung und
spontane Störungen wären ignoriert.
Auf diese Akkumulator-Daten könnten man dann einen wie auch immer
gearteten Decoder loslassen.
Mich würden mal die tatsächlich erreichten Bitfehlerraten der
verschiedenen Decoder-Konzepte interessieren, bei gleichen
Empfangsbedingungen.
Beste Grüße, Marek
Das mit dem Interrupt kann man machen muss es aber nicht. Da moderne µC
oft genügend Interruptfähige Pins haben, stört es von den HW
Anforderungen aber auch wenig. Durch die Hardware sollte es auch kaum
viele zusätzliche Interrupts geben, denn die Bandbreite sollte begrenzt
sein, und eine mindestens kleine Hysterese wird man auch haben.
Bei der Software hängt es davon ab, was der µC noch alles zu tun hat, ob
ein Interrupt etwa 1-2 mal je Sekunde oder gleichmäßig alle etwa 5-20 ms
mehr stört. Meist stört weder das eine noch das andere.
Will man einen wirklich empfindlichen Empfänger haben, ist es sowieso
schon problematisch das Signal nur Digital als 1 Bit Wert zum µC zu
senden. Da wäre es besser wenn der µC auch eine Amplitudeninformation
mit Zwischenwerten hätte. Wenn der µC sonst nicht viel zu tun hat,
könnte man ggf. sogar auf die Idee kommen und den Empfänger als SDR
(Software Defined Radio (reciever)) aufzubauen, dem µC also so etwas wie
eine gefilterte ZF anzubieten.
Marek N. schrieb:> Warum grassiert auch noch im Jahre 2013 die Unsitte, bei DCF-Projekten> den Empfänger an den Interruptpin anzuschließen und im Worst-Case den µC> in Interrupts absaufen zu lassen?
Das werde ich auch nicht verstehen. Für mich gibts da ne ganz klare
Trennung. Alles was nicht genau definiert ist kommt nicht an einen
Interrupt. Punkt. Da gehören alle! Empfänger dazu. Auch die häufig
verwendeten AM/FM Empfänger im 868 oder 433Mhz Bereich.
Ein kurzer Test am Oszi zeigt, dass diese Ausgänge auch mal ein schönes
Rauschen produzieren können. Da kommt dann Freude auf für den
Interrupthandler.
Normalerweise ist DCF ja nicht das einzige im System. Da sind dann noch
ein paar Tasten oder Drehgeber dran oder andere langsame Peripherie.
Einen zyklischen Interrupt braucht man eh oft genug und das ist auch
genau der Punkt wo solche Sachen abgefragt werden. Alles andere ist
Schwachsinn.
Viele HF-Empfänger haben oft kurze Spikes an den Ausgängen. Das macht
eine Interruptauswertung ohnehin kaputt, bzw. eine zyklische pollende
Abfrage erhöht die Erkennungssicherkeit oft dramatisch.
Leider ist aber die Aussage: "Pollen ist schlecht" nicht aus den Köpfen
zu kriegen.
M.N. schrieb:> Mich würden mal die tatsächlich erreichten Bitfehlerraten der> verschiedenen Decoder-Konzepte interessieren, bei gleichen> Empfangsbedingungen.>> Beste Grüße, Marek
Ich kann als Beispiel nur den WDE2 (oder so) von ELV angeben. Den
benutzte ich fuer 2 Temperatur/Feuchtesensoren. Die schaffen nicht mal
10m Luftline sicher. Ich kenne zwar die Firmeware nicht, aber ich erahne
sie...
Der selben Empfänger pollend betrieben erkennt 8 S555 problemlos im
ganzen Haus.
Das Argument, dass die Ausgänge bei Störungen wesentlich mehr Interrupts
erzeugen würden, als sie es im fehlerfreien Fall zu tun ist sicherlich
standhaft.
Nichtsdestotrotz möchte ich bei nem DCF77-Signal nicht per Polling
arbeiten. Da in der Regel irgendwo eh immer ein Timer involviert ist
verwende ich diesen, um das Signal zu gaten. Damit verhindere ich, dass
das System bei Störungen mit Interrupts zugemüllt wird und kann
andererseits aber trotzdem die Pulse per Interrupt auswerten.
Ralf
Ralf schrieb:> Nichtsdestotrotz möchte ich bei nem DCF77-Signal nicht per Polling> arbeiten.
Über Geschmack lässt sich einfach nicht streiten. Über sinnvolles
Programmieren schon. Letztlich ist jedoch das Programm gut, was immer
und unter allen Umständen funktioniert - innerhalb der Spezifikationen
des Bauteils, versteht sich.
Ich habe mal Abhandlungen gelesen, wie dermaßen exakt der Null-Durchgang
des DCF-77-Signals ist, da sind 10ms-Polling ein echter Witz !!!
Ja, auf den Interrupt und ordentliche Software schreiben !
Bei mir läuft immer noch eine DCF-86 ven ELV aus dem Jahre 1986. Die
schafft das immer...
Bernd Rüter schrieb:> Ich habe mal Abhandlungen gelesen, wie dermaßen exakt der Null-Durchgang> des DCF-77-Signals ist, da sind 10ms-Polling ein echter Witz !!!>> Ja, auf den Interrupt und ordentliche Software schreiben !
Mag sein, dass die Aussendung noch extrem genau ist. Das war's dann aber
auch schon. 1ms läuft das Signal bei mir alleine schon durch die Luft.
Wie sich der Ausgang der üblichen Empfänger zum Eingangssignal verhält
wäre auch noch zu untersuchen. Wenn da weniger als 10ms Verzögerung
rauskommen wäre ich sehr überrascht.
Wenn du allerdings auf die µs genau geweckt werden willst.....
Sämtliche Hardwareeinheiten in Controllern die async. serielle Signale
auswerten sampeln mehr oder wenig. Egal ob UART oder CAN. Das hat
sicherlich auch seinen Grund. Da wo Signale vorhersehbar aufbereitet und
definiert ankommen spricht nichts gegen Interrupts. In allen anderen
Fällen sind sie nicht angebracht. Und da gehören Ausgänge von
HF-Empfängern dazu genauso wie mechanische! Schalter, Taster und
Drehencoder. Also alles was irgendwie Prellen kann hat nichts am
Interrupt zu suchen solange er nicht fürs Aufwachen aus dem Tiefschlaf
benötigt wird. Ausser natürlich das ist der einzige Interrupt im System.
Dann ist das aber auch keine ernst zu nehmende Anwendung. Ehr sowas wie
DCF auf UART. Da kanns dir ja egal sein wenn der Empfängerausgang
rauscht. Wenn aber gleichzeitig noch Motoren gesteuert werden oder
Magnetventile, dann ist es nicht zulässig die Möglichkeit bestehen zu
lassen, dass mit schnellen Interruptfolgen das System nicht mehr
arbeitet.
In der Industrie werden massenhaft SPS eingesetzt. Bis auf einen
verschwindend kleinen Anteil an Spezialfällen werden da auch alle
Eingänge nur 1 mal während der Zykluszeit gesampelt. Da braucht auch
niemand (fast) einen externen Interrupt.
Warum 10ms ein Witz sind ist mir hier schleierhaft. Es geht ja wohl in
der Regel nicht um die Genauigkeit der Sekunde im ms Bereich sondern
darum eine interne RTC mit dem DCF-Signal zu stellen.
Weiterhin steht ja auch nicht fest ob dein Interrupt auch immer sofort
bearbeitet werden kann. Und dem DCF-Signal einen hochpriorisierten
Interrupt zu geben ist noch hirnrissiger.
>> Bei mir läuft immer noch eine DCF-86 ven ELV aus dem Jahre 1986. Die> schafft das immer...
Was du damit sagen willst weißt sicher nur du.
Ich habe auch einen Funkwecker der schon lange läuft.
avr3 schrieb:> Wie sich der Ausgang der üblichen Empfänger zum Eingangssignal verhält> wäre auch noch zu untersuchen. Wenn da weniger als 10ms Verzögerung> rauskommen wäre ich sehr überrascht.
Die PTB gibt selbst an[1], dass die Genauigkeit des empfangenen
Signals stark von den Ausbreitungsbedingungen abhängig ist.
In einem Papier von hopf Electronic[2] wird für die Praxis eine
resultierende Abweichung der aus dem AM-Signal gewonnenen Sekundenmarke
zwischen +5 ms bis +150 ms angegeben. Will man mehr, müsse man das
phasenmodulierte Signal auswerten.
Grüße
Stefan
[1] PTB-Mitteilungen 114 (2004), Heft 4,
http://www.ptb.de/cms/fileadmin/internet/fachabteilungen/abteilung_4/4.4_zeit_und_frequenz/pdf/dcf77.pdf
[2] Webseite hopf Elektronik - Genauigkeitsvergleich,
http://www.hopf.com/de/dcf-gps.htm, abgerufen am 13.12.2010
Jürgen Liegner schrieb:
Das sehe ich auch so. Die Art der Auswertung hängt im Wesentlichen von
der Art des Empfängers ab:
- Bei einem einfachen Empfänger, der lediglich die Amplitudeninformation
gleichrichtet und so ein mehr oder weniger rauschüberlagertes Signal
liefert, muss in der Software gefiltert werden. Das geht mit einem mit
fester Abtastrate gewonnenen Signal am einfachsten, also Polling. (Ob
man nun mit 100 Hz oder 1 kHz abtastet, ist eine zweite Frage.)
- Hat man einen Empfänger, der die komplette Demodulation und
Rauschunterdrückung selbst erledigt und ein stabilisiertes und
definiertes Sekundensignal ähnlich dem 1PPS-Signal eines GPS-Empfängers
liefert, dann brächte die Auswertung über einen Interrupt Vorteile.
Und was man nicht vergessen darf:
Für die übliche "Funkuhr im Haushalt" ist in vielen Fällen eine absolute
Genauigkeit (Uhrstand) von etwa 1 s mehr als ausreichend. Wichtiger ist,
dass diese Abweichung über die Zeit (Uhrgang) gleich bleibt.
Und das sollte bereits mit einem einfachen Empfänger, fester Abtastung
und einer einfachen Filterung gut zu erreichen sein.
Grüße
Stefan
