Hallo, im zweiten Teil zunächst hier in groben Zügen die Funktionsweise des MSF60-Dekoderprogramms. Im Wesentlichen wird dazu ein lauffähiges DCF77-Programm abgeändert, das ohne Externe- Interrupt-Flankenabfrage auskommt. Der MSF60-Momentanpegel (high/low) wird vom Empfängerpufferbaustein kommend als „low-active"-Signal dem Port 6 des hier verwendeten ATTiny4313 zugeführt. Dieser Port wird alle Hundetstelsekunde mit dem Timer-Interrupt-Handler (Timer im CTC-Modus) abgefragt, und es wird abhängig vom im Flag-Register gespeicherten, vorausgegangenen Pegelzustand unter Ausnutzung des T-Flags (im Statusregister) mit den dafür spezialisierten Befehlen auf verschiedene Sprungmarken verzweigt. Das Sampling-Register „msfcnt" wird den jeweils zuvor gesicherten Flags entsprechend pro Timer-Interrupt hochgezählt. Damit wird dann einmal im Vergleich mit dem Zählerstand anhand der gesetzten Registervariablen in r25 die Zuordnung von Einsen und Nullen über das Carrybit und zum anderen die Sekunden-, sowie Minutenerkennung ermöglicht. Nach Schieben, Invertierung und Zurückschieben werden die so gewonnenen Carrybit-Zustände im entsprechenden Array „msfarr" abgelegt und jede Sekunde byteübergreifend weitergeschoben in Richtung LSB (Predecrement). In der Hauptschleife „standby" erfolgen bei Minutenbeginnerkennung die flaggesteuerte Auswertung, eine Kontrolle der letzten 8 Fix-Bits und das Ablegen der gewonnenen Werte (BCD-codiert) im Zwischenpuffer „msfbuf1" , dann noch eine Format-Umwandlung nach 8-Bit binär für Zwischenspeicherung in Puffer für Minute, Stunde etc. bei der Ausgabe über LCD und RS232. Die Ausgabe über die serielle Schnittstelle mit 9k6, 8N1 ermöglicht es, über das Terminalprogramm alle Einsen und Nullen sowie die Zeit und das Datum, sowie Wochentag - zeilenweise untereinander pro Minute angeordnet - zu vergleichen. Und somit kann man bei Unstimmigkeiten auf einen Blick leichter erkennen, ob nun ein systematischer Fehler im Programm oder „nur" eine sporadische Störung des Empfangs vorliegt. Nur so konnte ich zum Beispiel herausfinden, dass bei der provisorischen Auswertungsroutine systematisch alle Bits um ein Bit zusätzlich verschoben waren, da ja zunächst auf die 59. Sekundenmarkenauswertung - wie bei DCF77 so üblich - verzichtet wurde. Auch bei (fast) fehlerfreiem Empfang wird hier das Bit 0 nicht dargestellt, das ist aber sowieso immer 1 (bedingt durch die 500-ms-Minutenbeginnmarke). Jedenfalls werden jetzt die für die Zeitinformation relevanten Bits sauber dekodiert. 00000000000000000001011000110110000100010100101000001111110<14:50-30.06. 2016 Do@MSF 00000000000000100001011000110110000100010100101000101111110<14:51-30.06. 2016 Do@MSF 00000000001000000001011000110110000100010100101001001111110<14:52-30.06. 2016 Do@MSF 00000000000000000001011000110110000100010100101001101111110<14:53-30.06. 2016 Do@MSF 0000000000000000000101100011……….. Um diese Programmvariante beizubehalten, bei der lediglich zwei Austastungs- bzw. Trägerabsenkungszeiten ausgewertet werden müssen, also für Nullen und Einsen-Erkennung ein cp-Befehl (pro Sekunde) ausreicht, lediglich noch ein weiterer Vergleich für die Erkennung des Minutenbeginns mit 500 ms nötig wird, sollten zusätzliche Low-high-Wechsel innerhalb einer Sekunde eliminiert werden. Die Monoflop-Variante scheidet deswegen aus, weil bei so hohen Zeiten plus Diodenbeschaltung die Erholzeit mit ca. 0,6 t zu lang wird. Diese Totzeit muss noch zur gewollten Sperr-Zeit hinzuaddiert werden. Beim Minutenbeginn kann das wegen der 500-ms-Austastung dann eng werden. Das High reicht dann evtl. in den folgenden Sekunden-Impuls hinein, und der Low-Zustand ist dann vielleicht zu kurz oder wird ganz verschluckt. Wird aber die Zeitkonstante im Monoflop dann wieder kürzer eingestellt, wird die Schaltung unter Umständen wirkungslos, da sie dann ihrerseits unter Umständen selber Spikes produziert. Insgesamt scheint dabei auch die Stabilität nicht so gut zu sein. Im Versuchsaufbau hier lief das Ganze etwa eine halbe Stunde, dann kamen nur noch Lottozahlen, und es musste wieder am Poti gedreht werden. Mit einer Ergänzung im Dekoderprogramm kann das besser gemacht werden. Das Sperren erreicht man durch Setzen einer Konstanten in einem Zwischenregister „lockb" hinter der Sekundenerkennung, das mit dem Portwert-Register r25 am Anfang der Timer-ISR verodert wird, so dass dieses auf high stehen bleibt, so lange nicht die Zählschleife in Sprungmarke t010 abgearbeitet ist, und „lockb" wieder resettet wird. Damit wird dann der B-Channel-Code kurzzeitig, definiert gesperrt, deswegen die Bezeichnung für das Register „lock-B", obwohl das Ganze ja nur dazu dient, den Zustand „A-Channel-low-B-Channel-high" wegzubekommen und nur den A-Channel durchzulassen, den brauchen wir ja noch. Das sind die wichtigsten Änderungen im Programm des DCF77-Dekoders beim Empfang des MSF60. Jetzt erhält man schon fortlaufende Sekunden und Anzeige auf LCD. Nur in etwa so etwas: (Abbildung 4) Die für DCF77 bestehende Zuordnung der gesendeten Zeitinformationen zu den Auslese-Pufferpositionen muss jetzt auf MSF60-Konformität korrigiert werden. (Abbildung 5) Dann sieht die LCD-Ausgabe so aus: (Abbildung 6) Viel Spaß Have a nice day gustav Programm im Anhang
Noch weitere Bilder: Der verwendete Empfänger EM2S 60kHz (FBM10030R) und die Ferritantenne AFET60-10x100/70 (FTW01001) stammen von HKW-Elektronik GmbH Feritantenne, Empfängermodul, Stromschnittstelle (Eigenbau) und LED finden im selben Gehäuse Platz. Klemmt man anstelle des Koppelkabels eine 9V-Batterie an, läuft es schon als Kontrollempfänger. Schema: Empfänger-Ankopplung an ATMEl AVRs Die Polung der zwei Drähte vom Empfängerset zum Pufferbaustein ist egal. Die Vorzüge einer Stromkopplung werden ausgenutzt. Als Zuleitung diente hier ein altes unabgeschirmtes Telefonkabel.
Georg G. schrieb: > Welchen Vorteil gegenüber DCF77 bietet MSF60? Nunja, im Prinzip bietet es höhere Zuverlässigkeit, da das Signal mehr Redundanz enthält (mehr Parity-Bits). Blöderweise enthält es aber auch mehr Information pro Zeiteinheit, so dass das SNR natürlich geringer sein muss. Gut möglich, dass sich beide Effekte ziemlich genau aufheben (ich würde das vermuten), kann aber auch gut sein, dass der eine oder der andere überwiegt. Ich würde mir jedenfalls nicht trauen, das aus dem Stehgreif zu bewerten. Um eine zuverlässige Aussage über die tatsächlichen Vor- und Nachteile treffen zu können, wären wohl umfangreiche Feldversuche nötig. Aber: Wenn man beide Dienste sinnvoll kombiniert, dann sieht das gleich ganz anders aus. Wie gut oder schlecht jeder der beiden Dienste im Vergleich auch sein mag, wenn man die jeweils gewinnbaren Informationen sinnvoll miteinander verknüpft, hat man definitiv ein höheres SNR, denn die zu transportierende Information ist ja weitgehend identisch (natürlich: nur für die Schnittmenge der übertragenen Informationen ergibt sich ein höheres SNR). D.h.: Mit einem guten Programm (und dafür geeigneter Hardware) könnte man aus der parallelen Existenz des MSF60-Dienstes schon erhebliche Vorteile bezüglich der Zuverlässigkeit der gewonnenen Informationen generieren. Allerdings ist das Zeug, was der TO anbietet, relativ unterirdisch, es nutzt ja nicht einmal MSF60 richtig aus. Und schon garnicht sind darin irgendwelche Ansätze für die sinnvolle Kombination der beiden Dienste zu erkennen. Das gibt allerdings natürlich auch schon das Konzept der vom TO verwendeten Hardware nicht her.
> Allerdings ist das Zeug, was der TO anbietet, relativ > unterirdisch, es nutzt ja nicht einmal MSF60 richtig aus. Zeige doch einmal deine Hard- und Software zur Dekodierung des MSF.
Georg G. schrieb: > Welchen Vorteil gegenüber DCF77 bietet MSF60? Ein direkter Vergleich der dekodierten Zeit von DCF77 und MSF60 ist schon allein deswegen nicht möglich, weil MSF60 um eine Stunde nachgeht. (BST=UTC+1; MESZ= UTC+2). Wenn man aber die Sekundenflanke als Kritetrium für Genauigkeitsunterschiede ansieht, wie es im zitierten Beitrag von N.No. angedacht war, scheint MSF60 auf den ersten Blick besser wegzukommen, da tatsächlich der Träger ganz ausgetastet wird. Man scheint daraus bei DCF77 noch gelernt zu haben und senkt den Träger seit ein einiger Zeit weiter ab. Der Modulationsgrad ist jetzt - glaube ich - sogar bei 90% statt früher 75% oder ähnlich. Dann ist da noch eine Trägerphasenumtastung zu Beginn der Absenkung zur Steigerung der Flankensteilheit dazugekommen. (Das kann man den zahlreichen DCF77-Dokus entnehmen.) Das "Projekt" hier verfolgt aber einen ganz anderen Zweck: Ist es überhaupt möglich, diesen Sender in Deutschland zu empfangen, da er ja mit dem Standortwechsel von Rugby nach Anthorn weiter von Deutschland weggerückt ist. Die Sendeleistung und damit zu erwartende Nutz-Feldstärke ist auch geringer bei gleichzeitig durch tiefer liegende Frequenz noch ein wenig höher zu erwartendem Störspektrum. (Abends ist bei eingeschaltetem Fernseher und Energiesparlampen praktisch kein sauberer Empfang mehr im Innenbereich möglich. Draußen konnte ich - wie im Bild gezeigt - sogar bei auf dem Ackerboden liegenden Empfänger in der Nähe einer Hochspannungsleitung ein Signal bekommen. Es sei denn, die Luftelektrizität ist bei Gewitter im Anzug zu groß.) Dann: Wie sieht ein einfaches Assemblerprogramm für ATMEL AVRs aus, das meinem Intelligenzquotienten entspricht und zumindest bei ausreichendem Empfang irgendein passables Ergebnis zeitigt, dabei möglichst schnell auswertet, im Idealfall innerhalb einer Minute was anzeigt. Es fehlt noch eine ganze Menge: Die Redundanz nach dem Prinzip zunehmender Skalenwerte, sprich Ausgabe erst nach 2-x Minuten fehlerfreien Empfangs, wie es bei (fast) allen handelsüblichen Funkuhren der Fall ist, dann die Auswertung der Paritybits etc. Mit dem Dekodieren des B-Channels bei MSF60 nimmt - allein schon statistisch gesehen - die Anfälligkeit für Störimpulse zu. Bei DCF77 kann ich für den Rest der Sekunde (ca. 800 ms) theoretisch den Empfängereingang sperren. Bei MSF60 geht das wegen der 500-ms-Minutenbeginnmarkierung nicht. Ebenso ist Sekunde 0 immer eine halbe Sekunde zu spät bei der gezeigten Art der Auswertung. Es sei denn, man nimmt die letzten acht Fix-Bits zur Minutenbeginnerkennung und wartet auf den nächsten Durchlauf. (Interessant, wenn man zum Beispiel 'mal auf britische I-Net-Seiten geht, haben einige Leute Probleme mit ihrem eigenen Zeitzeichensender, sie tendieren umgekehrt zum DCF77.) ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Ein direkter Vergleich der dekodierten Zeit von DCF77 und > MSF60 ist schon allein deswegen nicht möglich, weil MSF60 > um eine Stunde nachgeht. (BST=UTC+1; MESZ= UTC+2). Was genau an: > wenn man die jeweils gewinnbaren Informationen > sinnvoll miteinander verknüpft Hast du jetzt nicht verstanden? Mein Gott, die unterschiedlichen Zeitzonen sind doch eine Information, die dem sinnvoll programmierten Empfänger i.d.R. vorab bereits vollständig bekannt sind...
c-hater schrieb: >> Ein direkter Vergleich der dekodierten Zeit von DCF77 und >> MSF60 ist schon allein deswegen nicht möglich, weil MSF60 >> um eine Stunde nachgeht. (BST=UTC+1; MESZ= UTC+2). Bild dazu: OK. Die Diskussion schießt weit über's Ziel hinaus. Nur noch etwas: Der Vorteil ist, bei Ausfall den jeweils arbeitenden Sender als Backup benutzen zu können. Schön wäre es, wenn trotz "Brexit" eine europäische Normung für Zeitzeichensender Platz griffe, um problemlos ohne programmtechnische Klimmzüge zwischen den Sendern hin- und herswitchen zu können, je nach Standort. (Es gibt schon solche Funkuhren, die sich "umschalten" können, sind aber kaum zu bekommen.) Jetzt kommt die Dipl.-Ing.-Frage: Wer kennt eine ASM-Progrämmchen-Ergänzung zur Dekodierung des B-Channel-Codes? Bitte kein C! Unter sonst gleichen Kautelen. Also kein Externer Interrupt, trotz zu erwartender Ungenauigkeit, die dadurch entsteht. Es geht nur um Test. ciao gustav
:
Bearbeitet durch User
Bitte 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.