Zeitmessstrecke mit Funkübertragung

Mein Problem befindet sich in einer Schicht die viel weiter unten liegt.

Ich empfange Sinus mit 1200Hz und mit 2200Hz, nach dem whereAVR Prinzip werden, wenn ichs richtig verstanden habe, die Nulldurchgänge zum Erkennen der jeweiligen Frequenz genutzt. Bei einer Messung über einer Frequenz von 1200Hz habe ich mit einem Zähler in der Zeit X ca. Y mal einen Zähler inkrementiert und bei 2200Hz sind es Z mal, wobwei Y größer als Z ist. bei 2200Hz gehören aber 4 Nulldurchgänge zu einem Bit und bei 1200 sind es nur 2. Wenn ich nun aus irgendeinem Grund in der Mitte des 2200Hz Bits anfange zu interpretieren,habe ich doch nicht 4 Nulldurchgänge sondern nur 2 oder vielleicht drei.

Oder liege ich da falsch mit meiner Überlegung, und sowas passiert nie?

Bei einem Atmel Controller würde ich das Problem mit dem Analog Komperator lösen.
Diesen kann man so programmieren das er entweder bei einer steigenden, einer fallenden, oder einem Wechsel der Polarität einen Interrupt triggert.

Was dein 8051 Derivat da hergibt kann ich natürlich nicht wissen.

Du wartest auf die steigende Flanke und startest einen Timer (oder liest einen freilaufenden Timer aus). Beim nächsten Nulldurchgangs- Interrupt (= eine vollständige Periode weil wir ja auf steigende Flanke triggern) wird der Timer erneut (evtl. Subtrahiert) ausgelesen und mit einem Zeitfenster für 1200 und 2200Hz verglichen (toleranzen). Passt der Wert für eine der beiden Frequenzen hast Du eine 1 bzw. eine 0 anliegen. Zeiten die nicht in das Zeitfenster passen werden Ignoriert (=Störung). Der Timer ist nach jedem Nulldurchgang wieder zu resetten.
Läuft der Timer irgendwann über wurde nichts (auch keine Störung) empfangen. Das geht natürlich nur mit resetteten Timern.
Das bei 2200Hz zwei Wellenzüge übertragen werden ist dann eigentlich nur noch ein Softwareproblem das sich mit einem Flag lösen ließe.
Die empfangenen Bits werden in ein Software- Schieberegister geschoben, das bei Timeouts wieder gelöscht wird.
Die Auswertung des im Schieberegister hinterlegten Daten erfolgt über eine der übergeordneten Schichten, kann aber auch durch den Nulldurchgansinterrupt getriggert werden.

Ich hab sowas schon mal als normalen Interrupt für RC- Servoimpulse gemacht - funktioniert tadellos.

.. zu den Ausführungen von wkrug kann ich nur ergänzen, daß ich immer einen Timer verwende und entsp. Teiler- / Countervariablen (volatile) nutze. Somit läßt sich eben auch gleich ein Timeout integrieren.

hmmm, ne RTC synchronisieren ist nicht unbedingt die schwierigste Aufgabe,
aber der Messbereich ist dann schon recht grob, die bringt ja nur
auflösung im Sekundentakt, reicht Euch das ?

@vajk:
Das nennt sich dann Ringspeicher. Ich hab sowas mal gemacht indem ich die
Start und Stop-Kondition aus den oberen 4 Bit eines gesendeten Byte verwendet hab.

@vitis
Wir reden hier (vermutlich) schon von einer Auflösung im 1/100 Sekunden Bereich.
Uhren in einem so engen Zeitraster über eine Funkstrecke mit relativ langen Laufzeiten zu Synchronisieren dürfte nicht ganz einfach sein.
Schön wäre es natürlich wenn man eine Referenzuhr hätte die alle Angeschlossenen Teilnehmer (Master + Slave) gleichzeitig versorgt.
Denn dabei wären ja alle Laufzeiten (fast) gleich und die interenen Uhren würden alle Synchron laufen.
Das ginge vermutlich mit DCF 77 oder GPS allerdings nur mit nicht unbeträchtlichem Aufwand (Gps Empfänger oder PLL Frequenzvervielfacher).
Bei Ethernet gibt es dafür eigene Chips, die diese Aufgabe erledigen.
Aber ich hab da aber schon ein paar Ideen...
Ich möchte den Quarztakt des uC verwenden, der aber abgeglichen werden kann. Siehe diesen Threat weiter oben.
An eine RTC hab ich auch schon gedacht allerdings noch keine gefunden die 1/100 Sekunden macht.

RTC:
Als RTC hab ich den M41T81 von ST. Da hab ich ne Auflösung bis 1/100 Sekunden.

Leider hab ich noch keine Idee wie man das so genau synchronisiert.

Mit mal über den Daumen peilen ist da nichts mehr.

Funksync:
Was mein eigentliches Problem mit der Synchronisation angeht, hab ich das jetzt so verstanden, dass ich mir mal um die Verschiebung um ein halbes Bit in einem 2200Hz Signal keine Sorgen machen muss, da ich dann einfach beim nächsten 1200Hz Signal merke, dass da irgendwas nicht stimmt. Ich gehe jetzt einfach mal davon aus, dass ich immer alle Nulldurchgänge mitbekomme.

Wenn das so falsch gedacht ist gebt mir bitte einen Wink.

sast

@sast
Ich seh das auch so das Du alle Nulldurchgänge mitbekommen musst, damit eine klare Aussage 1 oder 0 getroffen werden kann.
Ich würd aber in den Rahmen am Anfang mehrere Bytes Preambel einbauen, damit sich Sender und Empfänger mal "warmlaufen" können.
Diese Preambel wird dann beim Empfänger wieder verworfen leitet aber den Empfang der eigentlichen Bytes ein. Ich würd trotz allem einen Leitungscode verwenden, dadurch wären dann unverwechselbare Bytes für die Preambel möglich.

Für die Synchronisierung der Uhren hab ich mir das so gedacht.
Die Master Uhr sendet ihre aktuelle Zeit und einen leeren Offsetwert aus.
Die Slave Uhr nimmt diese Zeitinformation auf und übergibt Sie ihrer RTC.
Der Slave sendet nun ebenfalls seine aktuelle Zeit wieder an den Master zurück.
Der Master subtrahiert nach dem Empfang die empfangene Zeit von seiner internen RTC und teilt das Ergebnis durch 2.
Der Master sendet nun wiederum seine aktuelle RTC Zeit und versendet im selben Rahmen noch den errechneten Offset mit.
Die Slave RTC nimmt die Zeitinformation auf und addiert den Offset dazu.
Das Ergebnis wird der RTC des Slaves übergeben.
Dadurch sollten beide Uhren jetzt synchron laufen.
Bei den nachfolgenden Synchronisationsläufen kann man noch eine Filterfunktion einbauen, die den neuen Wert mit dem gespeicherten Offsetwert gewichtet verrechnet und Extremwerte verwirft.
Vorraussetzung für das funktionieren dieses Systems ist, das beide Richtungen die gleiche Laufzeit haben und die Anzahl der übertragenen Bytes gleich ist (Rahmendauer). Zumindest für die Pakete die der Synchronisierung dienen.
Dadurch scheiden für mich auch Funkmodule mit sich verändernder Durchlaufzeit aus.
Das Synchronisationsproblem ist auch der Grund warum ich nur maximal eine Durchschaltestelle haben will, da ich sonst den Offset für jede Station neu berechnen muß. Im Master muss ich das ohnehin machen.
Der Königsweg wäre für mich immer noch eine zentrale Taktquelle, allerdings scheidet das wegen der nicht unerheblichen Kosten leider aus.

@wkrug

was ist denn ein Leitungscode?

Also mit dem durch 2 teilen bin ich noch nicht so ganz zu frieden. Da fällt ja noch die Kommunikation mit dem RTC und die eigentliche Verarbeitungszeit mit rein. Die ist ja beim Empfangen und Senden höchstwahrscheinlich unterschiedlich. Immerhin bewegen wir uns hier im ms-Bereich und die Weiterleitungsmethode möchte ich eigentlich nur ungern einschränken.

Aber vielleicht sehe ich da schon wieder Probleme wo gar keine sind.

Mir ist da gerade eine Idee gekommen.
Man könnte einen Ping an den Slave schicken, den dieser einfach zurückgibt (ohne irgendwelche Verarbeitungsschritte).
Dann halbiert der Master die zwischenzeitlich vergangene Differenz und addiert sie zu einer Zeit die er jetzt an den Slave schickt.
Und dieser muss sie nur noch eintragen.
Damit ist erst mal eine Grundsynchronisation da.
Dann sollte man mal über deine Filteridee nachdenken um ein resync zu machen. Obwohl ich davon ausgehe, dass die Synchronisation solange bestehenbleibt, solange die RTCs unter Saft stehen und die Controller immer noch aktiv sind.

sast

Edit: Naja das in Klammern nehme ich zurüch, da ja auch beim Ping der Kommunikationsweg klar sein muss. Aber er geht ja hin und zurück über die selben Kanäle.

... das mit den Antwortzeiten messen ist eine Möglichkeit, das "ping" sollte auch auf untester Ebene sofort durchgereicht werden, das müßte auch über die Relaisstationen funktionieren.
Alternativ würde denn eine DCF77-Empfang jedes Slaves nicht auch funktionieren ? Kontrolle in Kombination mit "ping" ?

@vajk
Ich dachte immer wir befinden uns hier auf der untersten Ebene.
Ping sollte nur aus Addresse des Empfängers, Zwischenstationen und Absenderadresse bestehen, wobei der Adressheader ja nach dem Init im Slave fest gespeichert werden kann, bis zum Ausfall einer Komponente.
Und irgendein Pingzeichen.

Sollte man eigentlich den Header beim Durchreichen verändern, durch Anhängsel oder Wegschneiden von Headerteilen?

Das bedeutet dann ja immer Verarbeitungszeit im Relais.

Meine Idee war in jeder Relaisstation die Zieladresse abzuschneiden, damit die Nächste vorn steht. Das würde aber bedeuten, dass ich den Weg zurück irgendwie anders bekannmachen muss.

sast