Zeitmessstrecke mit Funkübertragung

[vajk]

Schön wenn alles angekommen ist ...

Bei der Slave Suche würde ich nacheinander bei allen Slaves nach weiteren Slaves suchen (wenn noch welche fehlen, so ist die Richtung egal und es könnten auch Baumstrukturen möglich werden)
Wie gesagt, durch Trennung des Funknetzwerkes von den zu transportierenden Daten könnte das Ganze auch für andere Dinge genutzt werden ...
Jednefalls solche, wo es um kleine Datenmengen geht ..

Ich bau mir gerade auchg so ein Derivat des APRS-Teils, Schaltrplan ist schon fertig, um mit einem GPS-Empfänger am APRS-Dienst teilnehmen zu können - und da so meine Erfarungen zu machen inkl. LCD-Anzeige und 2 Schaltausgänge zur Tranceiversteuerung ....

Viel Erfolg weiterhin
Vajk

[wkrug]

Hallo Leute,

wird aus diesem Threat ein konkretes Projekt oder ist das erstmal nur ein Gedankenaustausch?
Wird der Quellcode und die Schaltpläne auch für die Allgemeinheit zugänglich sein ?
Ein Arbeitskollege von mir ist nämlich genau nach so einer Zeitmesseinrchtung auf der Suche (Cartrennen).

Wenn ich irgendwie helfen kann tu ich das auch Gerne, aber ich befürchte meine Kenntnisse sind dafür nicht ausreichend.

[sast]

Bin gerade dabei den Empfangsteil zu programmieren.
Wird also noch etwas dauern.

Bin aber für Ideen und Vorschläge immer offen.

Meine Variante kommt mit einem 8bit breiten Port aus, da das 8051 Derivat nicht mehr hat.

Da ja sowieso nicht gleichzeitig gesendet und empfangen werden kann, habe ich den Signaleingang auf einen Ausgang des Sinusgenerators gelegt.
5 Port-Pins sind zum Senden, einer davon auch zum Empfangen.
2 für I2C zum Auslesen eines RTC und der letzte verbleibende Pin bekommt das Signal vom Sensor.

sast

[wkrug]

Ich hatte an die Verwendung eines ATMEGA 16 oder 32 gedacht, weil ich auch ein LCD Display ansteuern wollte und allein dafür gehen 8 Ports drauf.
Als Taktoszillator wollte ich einen 4096 MHz Quarz verwenden (steuert auch die internen Timer an). Über ein externes D- Flip Flop soll der Takt durch 2 und 4 geteilt werden um einen Messausgang zum Abgleich des Oszillators zu schaffen. Auf einen Quarzofen hätte ich gerne verzichtet.

Die Idee zum Durchreichen der Nachrichten find ich Super, ich würd das Ganze allerdings nur mit maximal einer Durchreichestelle machen. Das vereinfacht das Protokoll, das Handling und ist weniger Zeitintensiv.
Auch die Idee mit einem Master find ich besser als gleichberechtigte Teilnehmer.
Zur Funkübertragung hatte ich an PMR Funkgeräte gedacht, die eine VOX Schaltung haben. Der Knackpunkt dabei ist das die Geräte bis zum Abschalten des Senders geschätzte 300mS brauchen. Das erhöht natürlich die Übertragungszeiten immens.
Öffnen möchte ich die PMR Funken nicht (Zulassung !).

Ich möchte auch eine Abspeicherung der einzelnen Stoppzeiten in einem EEPROM (Stromausfall !) im Start, sowie im Ziel realisieren, die dann nach einem Renntag per Kommando über eine serielle Schnittstelle zu einem Rechner übertragen werden können.
Mein Kollege möchte auch noch einen potentialfreien Ausgang der kurz nach dem Start kurz geschlossen wird um die Startampel wieder auf "Rot" zu setzen.
Als Übertragungsformat hatte ich nicht an eine FSK Modulierung gedacht, sondern an eine Übertragung im Basisband mit einem Leitungscode ähnlich dem Manchester Code. Der soll allerdings mit der seriellen Schnittstelle des Controllers erzeugt werden.
Und last but not least soll der Master auch ganz normal mit nur einem Start und einem Stopp Eingang im Stand alone Betrieb funktionieren.

Jetzt die Frage - Wie kann ich Dir da helfen ?
Mit C kann ich leider nichts anfangen - ist mir auch zu abstrakt. AVR Assembler klappt schon recht gut. Bascom lern ich gerade.

[sast]

Bei der konkreten Ausführung, kannst du sicher nicht mit helfen.

Aber es geht ja in erster Linie um Übertragung von Daten über eine Master-Slave Funkstrecke mit Nachrichtenweiterleitung. Die Reichweite ist ja immer das größte Problem und da ist so eine Durchreichestrategie eine feine Sache.

Was mich an dem Projekt reizt, ist die Tatsache, das alles mit einem Controller gemacht wird. Vorher habe ich immer die Packet Radio Module an die UART des Controllers gehängt. Das bläht nur unnütz auf.

Wenn du was mit ATMega suchst, dann sieh dir doch mal den Link von vajk an, den er weiter oben erwähnt hat.

Was die Programmiersprache angeht wird das Ganze wohl auf C hinauslaufen, da mein Controller nun mal nicht Basic verstehen will und ich schon seit Ewigkeiten kein Assembler mehr geschrieben habe.

Aber im Prinzip ist es auch völlig Egal mit was man schreibt, der Inhalt ist doch trotzdem der Gleiche.

sast

[Vitis]

Ich hab gerade ein identisches Projekt am laufen,
was mir aber noch kopfzerbrechen macht ist die Signallaufzeit.
Ein PRotokoll braucht halt im Halbduplex seine Zeit
für die Abarbeitung (Handshake, Aknowledge, Ping, Tapstone etc.), wie wollt Ihr das lösen?

[sast]

@Vitis
Ich löse das so, dass das Ereignis eine Abfrage des RTC initiiert. Danach wartet der Slave bis der Master ihn abfragt und sagt Ereignis war zur Zeit X.

Wie ich das mit der Synchronisation der Master- und Slavezeiten löse, weiß ich erst wenn das Protokoll soweit funktioniert. Zur Zeit schlage ich mich mehr oder weniger erfolgreich mit der Demodulation herum. Irgendwie fehlt mir das Verständnis, wie ich den Empfangsteil dazu bringe sich auf die Sendedaten zu Synchronisieren. Da hab ich irgendwie einen schwarzen Fleck im Kopf.

Zumindest sollte da ein Routing im Header vermerkt sein. Aber wie man das möglichst unkompliziert durchgrast hab ich mir noch nicht überlegt.

@wkrug
mir ist gerade noch eingefallen, dass ich auch mal Module mit Manchesterkodierung hatte (glaub ich jedenfalls). Google mal nach RT433F1.

sast

[vajk]

>> Mit C kann ich leider nichts anfangen - ist mir auch zu abstrakt.
>> AVR Assembler klappt schon recht gut. Bascom lern ich gerade.

ASM ist sehr Controllerspezifisch, aber für sehr zeitkritische Dinge wichtig.
Bei uC-Taktfrequenzen hab ich noch nicht gebraucht.

Natürlich kann eine Interpretersprache wie Basic auch gute Ergebnisse liefern ...

@wkrug: Jedoch wenn Du ASM verstanden hast, dann ist C für Dich viel besser als Basic, denn in C kannst Du eben durch knappen Code Dinge elegant erledigen, aber hast die Mächtigkeit von ASM ...

Bsp.: int varc = (vara > 20) ? 17 : (varb == 12 || varb == 'a' ? 54 : 10);

mach das mal in Basic .. für mich ist obige Zeile sofort verständlich und eben schön kurz und knapp.

In Basic brauchste dafür doch etliche Zeilen mehr

Kann Dir nur Raten, Dich mit Zeh zu beschäftigen, wenn Du das verstanden hast, willste nix anderes mehr.

ASM,Basic, Pascal, Modula, Pascal, C, C++ ist meine Leidensgeschichte ... C ist nichts anderes als ein effizienter Macroasm, der Deinen Code soweit vom Controller abstrahiert, daß der Code portierbar wird.....


> Aber im Prinzip ist es auch völlig Egal mit was man schreibt, der
>Inhalt ist doch trotzdem der Gleiche.


.... und die Programmiersprache ist nur ein Handwerkszeug !!!
@sast gebe Dir vollkommen Recht !

Nur wer mit dem Handwerkszeug umgehen kann, muß noch lange nicht programmieren können. Dazu gehört auch der entsp. Chip im Hirn

[sast]

@vajk
schön das du vorbei schaust

kannst du mir vielleicht helfen die Verständnislücke zu schließen.

es muss doch irgendwie zu verstehen sein, wie ich dazu komme, dass ich nicht mitten im 2200Hz Signal anfange die Daten zu interpretieren, sondern immer am Anfang. Sonst stimmen doch die Anzahlen der Nulldurchgänge nicht mehr.

sast

[vajk]

Nun, darum ja die Aufsplittung in unterscheidliche Ebenen, die Quasi parallel ablaufen.
Eine Routine empfängt daten, sprich tastet den Empfänger ab und jede Information wandert in einen Puffer. Wenn die Daten korrekt empfangen worden sind, und keine weiteren folgen, wird ein Flag für die Weiterverarbeitung gesetzt.
Diese kopiert die empfangenen daten, leert den Empfangspuffer und lsöcht das Flag. Jetzt können ggf. weitere Daten empfangen werden. Gleichzeitig erfolgt eine auswertuing von dem, was empfangen wurde.
Wenn das Flag nicht gesetzt wird, wird auch nichts ausgewertet ..

Vorgehensweise klar ?