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
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.