MSF60 Dekoder AVR Teil_2

[Karl B. (gustav)]

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

[Karl B. (gustav)]

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. (df2au)]

Welchen Vorteil gegenüber DCF77 bietet MSF60?

[c-hater (Gast)]

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.

[MaWin (Gast)]

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

[Karl B. (gustav)]

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

[c-hater (Gast)]

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

[Karl B. (gustav)]

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

[Karl B. (gustav)]

Bild dazu