Zeitmessstrecke mit Funkübertragung

[vajk]

Nun, die untereste Ebene ist die (Funk-)Datenkommunikation, Daten wie die Zeitübertragung sind eigentlich "höher liegend" und haben normalerweise nichts mehr mit der eigentlichen Datenübertragung zu tun .. siehe hierzu meinen Beitrag weiter oben.

Der Ping in Verbindung mit Daten wäre eine Vermischung. Besser wäre zur Trennung, daß die Kommunikationsschicht von sich aus eine Laufzeitmessung durchführt und die ermittelten Zeiten eben zur Verfügung stellt.
Ziel-ID wird ja imemr der Master sein, Absender, die des Slaves. Ich würde die IDs der Relais-Salves dann anhängen, und somit ein erneutes Senden des Slaves verhindern, wenn der nächste Slave der Kette sendet.
Oder aber die Senderichtung auch auf grund der Ids festlegen - Slave zu Master nur repeaten, wenn Sender-Slave-ID kleiner ist als die eigene (aus sicht des Slaves) ...
Ideen verstanden ?

[sast]

Wie würdest du so eine Laufzeitmessung durchführen wollen? Das ist ein sehr wichtiger Aspekt.

Es interessiert eigentlich nur die Laufzeit vom Master zum Slave, damit ich als Master weiß, wieviel Zeit ich auf meine aktuelle Zeit addieren muss, um dem Slave zu sagen was er in seinen RTC schieben soll. Danach laufen die RTC synchron.

Um noch mal das Init auf einen Verständnislevel zu bringen:
Master versucht erst mal alle Slaves im Alleingang zu erreichen.
Wenn er das nicht kann, dann nimmt er sich den ersten Slave und versucht nur über diesen die restlichen Slaves zu erreichen.
Sollten da immer noch welche unerreichbar bleiben nimmt er den nächsten Slave und so fort.
Ist in der ersten indirekten Runde ein bzw sind mehrere Slave(s) gefunden worden, aber es sind immer noch unerreichte übrig, dann versucht der Master über die Ergebnisse der ersten indirekten Runde an die fehlenden Slaves zu kommen.
So geht das weiter, bis alle Möglichkeiten ausgeschöpft sind.

Ist ein Slave erreicht worden, dann gibt es zur Kommunikation einen eindeutigen Weg für den Master zum Slave, aber auch für den Slave zum Master, der auf beiden Seiten gemerkt werden kann.
Daran anschließend folgt die RTC sync..

Beim Init müsste nun ein Relais das vom Master auserwählt wurde als solches für einen Slave zu fungieren einen Befehl bekommen: "versuche SlaveX zu erreichen". Wenn das geht sendet der neue Slave über die Relaisstrecke an den Master zurück, dass er da ist. Dazu muss aber im Datenteil der bisherige Weg dokumentiert werden. Dann könnte man nämlich auch im Header bloß immer die Zieladresse abschneiden. Und was ich für einen Vorteil erachte -es ist unabhängig von der ID-Größe-.

Bsp.: Master sendet über Slave3 und Slave5 an Slave1

Header:
sync|sync|sync|S3|S5|S1|Absenderadresse folgt|M|...

S3 erzeugt eigene sync Bytes und sendet das Paket ab S5|S3|... wieder weiter

Wenn es bei S1 ist kommt als nächstes der Indikator das jetzt der Absender kommt und das Paket somit am Ziel angekommen ist.
Daraufhin wird ein CRC Test gemacht und ein ACK oder NAK an die Absenderadresse geschickt. Dabei verwendet S1 den Pfad, den er für M irgendwo gespeichert hat.

Wir sollten nicht davon ausgehen, dass das Ziel immer der Master ist, da ja Master und Slave senden können und auch beide empfangen.

sast

[wkrug]

@sast
Laufzeitermittlung:
Das mit dem Ping zur Laufzeitermittlung wird so nicht funktionieren, da Du ja nur eine Halbdublexstrecke zur Verfügung hast.
Wenn Du PMR im VOX Mode einsetzen willst musst Du ca 300ms Warten bist der gegnerische Sender abgeschaltet ist. Diese Zeit wird der Rückweg immer länger dauern als der Hinweg.
Mit den Verarbeitungszeiten im uC für den Hin und Rückweg hast Du schon recht.
Wenn diese aber bekannt sind, das sind sie ja normalerweise, kann ich die schnellere ja so weit verlängern (NOP!?) damit die Verarbeitungszeiten wieder gleich sind. Mit etwas Aufwand sogar Taktgenau.
Ursprünglich wollte ich eigentlich die RTC als Software im uC laufen lassen und da dauert das schreiben eines Ram Speicherplatzes genauso lange wie das lesen.
Aber deine Idee mit der RTC wer ich mir auf jeden Fall überlegen, allein schon wegen der Präzision und der Unabhängigkeit vom Prozessortakt.
Um schon mal die Rahmenlaufzeiten auszuschalten würde ich mich auf eine feste Rahmenlänge für die Synchronwörter festlegen, die durch das längste zu versendente Telegramm festgelegt wird. Nicht benutzte Bytes werden einfach mit Leerzeichen oder Nullen gefüllt.
Wenn ein Slave als Relaistation für einen weiteren Slave festgelegt ist, muss hier halt der Synchronisationslauf initiiert durch den Master neu starten. Die eigentliche Synchronisation findet dann zwischen dem Relais Slave und dem zu erreichenden Slave statt.
Da der Master ja letztendlich wissen muss ob alle Slaves synchron sind wird auch bei gutwilliger Betrachtung die Anzahl der Relaistationen beschränkt bleiben. Der Master muss ja mit seinem nächsten Telegramm so lange warten bis er ein ACK vom letzen Slave in der Kette empfängt und deshalb die Timeoutzeiten hochsetzen.

Empfänger Frequenzauswertung:
Ich hätte da noch eine Anmerkung zur Frequenzauswertung:
Du schreibst:

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 das nochmal genau lese möchtest Du die entsprechende Frequenz mit einer festen Torzeit =X erfassen.
Das wir bei den paar Wellenzügen aber vermutlich nicht richtig funktionieren und es könnten dadurch tatsächlich Nulldurchgänge versiebt werden.
Die Idee war eigentlich die Periodendauer, wenn das Eingangssignal von negativ nach positiv wechselt bist zum nächsten negativ nach positiv wechsel mit einem Timer zu messen.
Dabei kann Dir kein Wellenzug verloren gehen (es sei denn durch eine Störung) und zum Ermitteln der Frequenz reicht Dir eine Periode (positive + negative Halbwelle).
An den Packet Radio Standard musst Du dich ja nicht halten weil Du ja ein Inselsystem baust.

Leitungscode:
Das mit dem Leitungscode meine ich folgendermassen.
Die zu übertragenden Bits werden kodiert z.B. Manchester Code und dann erst per FSK über Funk übertragen.
Der Vorteil ist das hier bestimmte Codekombinationen nicht auftreten können z.B. 111. Diese Kombinationen eignen sich aber dann vorzüglich um Preambeln oder Startwörter in den Code einzufügen.
Da beim Start der Senders per VOX mit Sicherheit einige Bits verloren gehen werden, kann der Empfänger dann nach genau diesen "unnormalen" Bytekombinationen suchen um sich auf den Sender aufzusynchronisieren.
Der Nachteil ist halt das sich die Datenübertragungsrate in diesem Beispiel mehr als halbiert.

Ich mag dich jetz hier nicht zumüllen, aber wie Du siehst hab ich mir auch schon mal ein paar Gedanken gemacht.

Schön langsam werd ich mal das Coden anfangen, meine Evaluation Boards hab ich ja auch schon gekriegt.
Zuerst wird mal der Sinusgenerator drankommen -schade das Du keinen ATMEGA benutzt \/

[vajk]

Argl ... VOX .. hmmm das finde ich nicht so gut! Wenn Du ein externres Mic anstecken kannst, dann geht auch die PTT, dann brauchst Du keine VOX !

Wie gesagt, ich würde auch DCF77-Module vorziehen, die dekodierung ist einfach und die Module kosten bei C* glaub ca. 14 Eur ....

JA ich bin auch ein Atmel-Fan ... 8051 nutze ich in der Zeit wo man eproms noch mit UV gelöscht hat

LG
und viel Erfolg,
Vajk

[wkrug]

Ich finde VOX ja auch nicht gerade toll.
Die Funken die ich hab haben aber einen 3,5mm Klinkenstecker für den Lautsprecher und einen 2,5mm Klinkenstecker für das Micro in dem auch die Labebuchse beschaltet ist.
Ein eigener PTT Anschluß ist nicht vorhanden.
Trotzdem gibt es Headsets mit PTT Taste für die Geräte
Es sind OnAir 446 PMR Funken von Team electronic. Hast Du eine Idee wie das mit dem PTT da geht ?

[wkrug]

@Vajk
Das mit der PTT Funktion hat sich erledigt.
Team Electronik hat sogar einen Schaltplan von der Funke im Internet zum Downloaden =D> . Welch rühmliche Ausnahme !

Jetzt steht der Anschaltung an einen Microcontroller nur noch wenig im Wege.

[vajk]

@wkrug - Ein eigener PTT Anschluß ist nicht vorhanden.
3,5mm Stereo + 2,5mm Mono = 5 Kontakte sprich Masse, Mic, Lsp, PTT .. möglicherweise sogar +UBatt .. die PTT-Leitung kann u.U. auch via Widerstände noch die Fkt. Up und Down beinhalten - beide Außenkontakte müssen nicht auch beide Masseführung haben !!
Aber wenn DU den Schaltplan hast - prima !!

[sast]

also bei meinen PMR FUN geht das PTT über 2,2k gegen Masse direkt auf der Mic-Leitung. Weiß allerdings im Moment nicht was VOX ist. Bei WhereAVR macht der das auch über die 2k2 also muss das ja bei mehreren Funkgeräten möglich sein.

sast

[wkrug]

@sast
VOX bedeutet das der Sender des Funkgerätes aktiv wird wenn ein Audiosinal am Mikrofon anliegt.
Nachdem das Audiosignal weg ist läuft der Sender noch kurze zeit weiter, es könnte ja nur eine kurze Silbenpause sein.

Für unsere Zwecke ist diese Pause allerdings pures Gift, weil der antwortende Sender auf jeden Fall so lange warten muß bis der ursprüngliche Sender abgeschaltet hat bis er mit der Datenübertragung beginnen kann.