Zeitmessstrecke mit Funkübertragung

Der eigentliche Thread beginnt in "Jobs/Hilfen/Stellen - Gesuche und Angebote » Wer kann Zeitmessstrecke für mich basteln?"



hier mal der Code für meine Send Routine

Code:

---

void sendTime(unsigned char id, unsigned long mslong)
{
  unsigned int n,m;
  PTT=1;
  for (n=0;n<60000;n++)
      for (m=0;m<10;m++);
  printf("VVV%c%010ldEE\n", id, mslong);
  for (n=0;n<60000;n++);
  PTT=0;
}

---

Ich glaube das sagt mehr als umständliche Umschreibungen.
Die IDs sind immer geradzahlig also 2, 4, 6, 8.

In der main() ist dann folgender Code z.B. in Slave2, welcher auf Slave 8 wartet.

Code:

---

...
if((c=nb_getkey())=='V') // Dreck rausfiltern
{
  while((c=_getkey())=='V'); // Synchronisation
  switch(c)
  {
      case '1':
      case '2': //timeslave#2
        break;
      case '3':
      case '4': //timeslave#4
        break;
      case '5':
      case '6': //timeslave#6
        break;
      case '7':
      case '8': //timeslave#8
        mslong = readTime();
        for (n=0;n<60000;n++);
        for (m=0;m<10;m++);
        if(is_released)sendTime('1', mslong);
        else sendTime('2', mslong);
        is_released = 0;
        neustart=NEWLOAD;
        break;
      default:
        break;
  }
}
...

---

is_released ist das Flag, welches anzeigt ob ein Lichtschrankeninterrupt ausgelöst wurde. Die Abfrage läuft über einen Timer.

Als Funkgeräte verwende ich PMR Fun 446MHz 500mW von Conrad. Die Module sind 1200 Baud Module und setzen lediglich die RS232 auf Funk um bzw zurück. Wenn ich mich recht erinnere machen die 1 oder 2kHz aus den Einsen und Nullen.

Ich habe aber noch nie probiert, ob ich wirklich 1km weit komme mit der Messstrecke. Entscheidend ist ja, dass der Master egal wo er steht immer alle empfängt und nach meinem Ringprinzip die 2 auch immer die 8 empfangen muss.

sast

Öhm ..

Code:

---

...  sendTime() .. printf("VVV%c%010ldEE\n", id, mslong);
... for (n=0;n<60000;n++);
... nb_getkey())=='V')
... while((c=_getkey())=='V');
... mslong = readTime();
... for (n=0;n<60000;n++);
... for (m=0;m<10;m++);

---

öhm, ganz vorsichtig gesagt, ich würde den Programmablauf etwas anders programmieren ... Du hast wohl nur eine Umlenkung von stdout gewählt, um
mit dem Außen zu sprechen, das gut für debugging, aber ... ... und dann loops, die nix machen .. das macht man anders .... so via timer und - ich bezeichne es als- "ping-pong"-Reaktionsabwicklung ... also step by step mit der Möglichkeit von timeouts etc. ...


PMR Fun 446MHz 500mW von Conrad. hmm .. nunja, dagegen spricht nicht viel, so was dachte ich mir schon ... hat den Nachteil, daß Du keine externen Antennen anschließen kannst ....

Ok. wenn die Module "direkt" arbeiten, dann is gut ... dann sollte das Ganze auch fix gehen ...

Denke wir sollten am WE mal Telefonieren ... XXl läßt grüßen ;-)


> Meine 3 Timer gehen für I2C und UART drauf.
> Ich arbeite mit C8051F300 von Cygnal.

Hmmm .. den 8051 kenne ich von vor 20 Jahren ... jetzt werkel ich mit dem mega128 rum ... 3 Timer für I2C und UART ????? Schulterzucken ..

Also ich löse eine Mehrfachnutzung des Timers so, daß ich jeweils ein Flag setze, wenn Timer ausgelöst wird und somit einen "Takt" vorgebe.
Sehr zeitkritische Sachen (.z.B. Schrittmotorsteuerung) laufen auch innerhalb der Zeitschleife ab ...

1200 Baud sind nun wirklich nicht sehr schnell .. das ist ein Nebenjob :-) ... Daten raus .. Flag eins höher setzen und wenn Antwort kommt, dann Flag wieder eins höher ... switch/case mit entsprechenden "ping-pong"-Abwicklung ...

Aber Deinen 8051-Derivat kenn ich nicht, auch nicht dessen Möglichkeiten ... dasn Problem ...

LG
Vajk

Macht ja erst mal nichts, dass du den nicht kennst. Zur Not hab ich da ein Datenblatt für.

Wir sollten erst mal auf der abstrakten Ebene bleiben. Wäre nicht schlecht wenn wir da erst mal eine Einigung erzielen. Hab zum Beispiel dein pingpong noch nicht so richtig begriffen.

Die Slavecontroller haben eigentlich nur 3 Aufgaben.
1. ADC Sharpsensor abfragen ob jemand vorbei kam (ist nämlich in meinem Fall nicht wirklich ne Lichtschranke sondern ein Entfernungssensor)
2. RTC abfragen
3. Kommunikation (auf Vorgänger warten und dann Signal für Nachfolger und Master)

Dabei läuft die Kommunikation über RS232 und die RTC über I2C und der ADC wird in einem der Timer für die I2C abgefragt.

sast

Hi
ich hab gerade was gefunden, das Dir u.U. weiterhelfen könnte .. so als Basis : http://www.knology.net/~gdion/whereavr.html

Also meine pingpongspiel:

Für den Ablauf, wenn es auf darauf ankommt, daß der uC mehr als nur einen Job macht, sollte man keine blockierenden Schleifen nutzen .. das haut einem das Ablauftiming immer wieder durcheinander ...

Also versuche ich meine Vorgehensweise möglichst einfach zu beschreiben:

Also nimmst Du eine globale Variable initalisierst diese mit 0 und machst via switch/case im Hauptprogramm eine Verteilung, was passieren soll, wenn die gV einen bestimmten Wert hat ...

Fängt an, Du willst was senden, im SendeStapel liegen Daten bereit - dann setzt Du gV auf 10 - als Startflag.

Wenn 10, dann Daten in Sendebuffer übertragen und Sendevorgang starten, gV auf 11.
Wenn Daten abgesendet, dann gV auf 12 setzen. Wenn 12, dann via Timer eine Abruchvariable (fürs Timeout) hochzählen.
Wenn jetzt ein ack (Empfangsbestätigung der Gegenseite) kommt) wird gV auf 13 gesetzt.
Wenn 13, dann Timeout löschen und gV = 14.
Wenn 14, dann job fertig, gV auf 0.
Wenn Daten reinkommen, dann gV auf 20,
wenn Daten fertig gV auf 25.
Wenn 25, dann Daten auswerten,
....

Verstanden, was ich meine ...
Das Hauptpgrogrammtiel sorgt für die Abarbeitung der gV - Zustände.

gV sollte auch abgefragt werden, bevor was neues in die Hauptabarbeitung gelangt und und wenn diese "belegt ist" ggf. auf einen Stapel gepackt werden.

Bevor jetzt ein gV wieder auf 0 gesetzt wird, eben auf 200 setzen, und Jobstapel - Element holen und entsp. weiterverfahren, wenn nichts zu tun, dann eben erst auf 0 setzen.

Verscheidene Programmteile, die z.B. via Timer oder Interrupt ausgeführt werden, müssen ggf. auch gV abfragen und entsp. handeln ...

Ping-Pong, weil immer hin-und-her-gesprungen wird.

So, hoffe nichts vergessen zu haben :-)
Idee der Abarbeitung verstanden ...
.. auf diese Art und Weise, mußt Du keine for(irgendwas)-Schleifen einsetzen.
Insbesondere kann ein Interrupt von außen die aufgaben des uC ja auch bestimmen und z.b. einen Sendevorgang sinnvollerweise verzögern oder eben erst zu ende machen lassen und seinen Job dranhängen ...

Auf die Art und weise koppel ich einiges in meinen Progs mit Timerjobs, UART-RX/TX und LCD-Out, DCF77 auswerten, Schrittmotor steuern u.s.w. quasi parallel ...

... habs mal probiert, meine LCD-Routine konnte Texte ausm RAM so schnell ausgeben, daß ein mitlesen durch zwinkern nicht möglich ist (man den Text klar lesen kann), während gleichzeit die DCF77-Auswertung stimmig erfolgt und die RS232 bedient wird ...

Also, wenn Du Dein Paketsystem beibehalten willst, muß das als untergeordneter PPJob laufen ...
Und eben auch drauf reagieren, wenn nicht innerhalb eines Zeitfensters eine Antwort der Gegenstelle kommt ....

Eigentlich sollte es auch kein Problem sein, via Master die einzelnen Stellen zu pollen, ohne daß diese auch als Weiterleiter fungieren müssen ... wobei die Idee natürlich was hat :-)

Liebe Grüße,
Vajk

Mir fällt auch noch ein, hast Du die Richtung der Paketransporte vom Salve zum Master hin geregelt ...

das slave 1 sendet, slave 2 empfängt und sendet zum master und ack zum slave 1, slave 3 empfängt und sendet zum master und ack zum slave 2, master empfängt und sendet ack zum slave 1 ...

Gibt es schon Test-Datensendung vom Master zu den slaves .. prüft er den datentransportweg .. sind ihm die slaves und deren Reihenfolge bekannt (am besten über einstellbare ids ...

...

Ich glaube jetzt tritt das Verständnisproblem zu Tage.

Die aktuelle Anordnung hat folgenden Stand. 4 Slaves und ein Master. Die Slaves heißen 2, 4, 6, 8. Sie bilden einen Ring der unabhängig vom Master funktioniert. Das hatte ich mir überlegt, um die Abarbeitung nicht zu verlangsamen. Die Slaves stehen auch immer in der Reihenfolge: 2 ist Start dann kommen 4 und 6 als Ziel steht die 8.

Der 2er fängt nun an zu senden, weil er ein timeout erreicht, in dem er keine Signale von der 8 erhält. Das ist auch gleichzeitig die Vorgehensweise wenn es mal zu einer Unterbrechung der Funkstrecke kommt.

Sagen wir mal es ist noch keiner gestartet, dann sendet Slave 2 seine ID und seine aktuelle Zeit. Diese Sendung wird von allen Slaves und dem Master empfangen. Slave 4 sieht jetzt, dass da sein Vorgänger was gesagt hat und meldet sich nun anschließend zu Wort. So geht das rum bis die 8 dran ist. Hat Slave 8 gesendet kommt wieder die 2 dran.

Nun wurde bei Slave 2 ein Event ausgelöst -Startschranke durchfahren-. Zur Zeit ist es nun so, dass das Ereignis registriert wird und der Slave trotzdem erst wenn er dran ist die Zeit einfügt. Das muss ich wenn der Rest geht noch so anpassen, dass der Zeitstempel gleich dran kommt, wenn das Event ausgelöst wird. Slave 2 sendet nun ID-1 anstelle von ID und die Zeit.
Jetzt kommt der Master zum Tragen. Solange Slave 2 immer nur seine ID gesendet hat, hat der Master jedesmal den Offset zu seiner Zeit berechnet. Dieses Mal nimmt er den Offset und den aktuellen Zeitstempel von Slave 2 und generiert daraus die Startzeit. Die wird gespeichert und der Master wartet auf die nächste Sendung. Gerade ID bedeutet wieder Offset für den jeweiligen Slave berechnen, ungerade ID heißt Event ausgelöst.

Maximal 3 Messojekte können sich gleichzeitig in der Messstrecke befinden. Das heißt, nach einem Startevent kann entweder ein Zwischenzeit1event kommen, oder wieder ein Startevent.
Diese Auswertung übernimmt ein ATMega32 der auch gleichzeitig ein Touchpanel ansteuert.

So ich hoffe jetzt kannst du meine Gedanken verstehen. Bin da auch irgendwie festgefahren und suche deshalb nach einer anderen Herangehensweise. Deshalb finde ich es auch gut, wenn mal ein anderer drüberliest und seine Gedanken niederschreibt oder halt was völlig neues vorschlägt.

Bin mir auch nicht ganz sicher ob das der richtige Ansatz ist, da ich dadurch auch mal etwas verpassen kann.

Ein Vorteil ist, dass durch dieses Verfahren nie alle Slaves durcheinander reden.

Als Nachteil sehe ich hauptsächlich, dass ein Event was kurz nach dem Senden von SlaveX ausgelöst wird erst angezeigt werden kann, wenn SlaveX wieder dran ist mit Senden. Die Frage ist allerdings in wie weit das stört. Wenn man die Messstrecke vergrößert wirds bestimmt irgendwann mal ein Zeitproblem.

sast

Nun hab ich so meine Probs, alles zu verstehen.


Aber ich denke Du solltest meine Idee mal aufnehmen und durchdenken.

Also Du solltest mehrere Ebenen einführen.

Funknetzwerkebene

Unterste Ebene ist die Sicherstellung der Funkübertragung. Hierbei sollte der Master die Führungsrolle übernehmen.
Zunächst sollte - um möglichst variable eine "beliebige" Anzahl Slaves einbinden zu künnen, das Funknetzwerk untersucht werden.

Die Untersuchung hat den Vorteil, daß das System leicht erweitert werden kann. Du könntest auch von festen Parametern und
Verbindungen ausgehen, dann entfallen die Suchfunktionen.

Dem Master sollten bekannt sein, wieviele Slaves es gibt, Wert einstellbar. Daraus sollte sich ableiten, wie die Slaves heißen (IDs).
Zunächst sollte der Master den ersten Slave ansprechen, wenn die Verbindung klappt - ask: also "hallo bist Du da" - "ja": ack (acknowledge=Empfangsbestätigung)
dann den nächsten .usw.
Wurden alle Slaves gefunden, dann bedeutet es, daß der Master mit allen Slaves direkte Verbindug hat. Die Salves sollten dann nicht im Repeatermous arbeiten.

Fehlen Slaves, dann sollte der Master über den ersten Slave versuchen, den/die Fehlenden zu erreichen.

Das kann zu einer Kette gesteigert werden. Die Adressierung sollte die Tatsache berücksichtigen, daß zwischenliegende Slaves auch als Repeater fungieren. Das ist wichtig für die Timeouts, in denen der Master eine Antwort erwartet. Und wichtig für die Slaves am Ende der Kette, damti die wissen, wie der Master zu adressieren ist!

Während des späterern Ablaufs muß dieser Netzwerktest im Gesamten oder einzelnen Ästern nur noch manuell stattfinden, wenn z.b. eine längerwierige Funkstörung auftritt, diese behoben werden konnte ... u.s.w.

Ein Fehlschlag einer Verbindung zu einem Slave, sollte zu z.b. 3 Wiederholungen des Verbindungsaufbaus führen und dann als Fehler angezeigt werden, erneute Überprüfung entweder manuell auslösen oder automatisch in größeren Zeitintervallen.

Das Funknetzwerk ist die Basis.
Das hier vorgeschlagene Verfahren eine Möglichkeit, die Kontrolle und Übersicht vom Master aus zu wahren um auch feststellen zu können, welcher Salve ggf. ausgefallen oder wessen Funkverbindung gestört ist.


Diese Ebene betrifft auch die Datendurchreichung der Slaves, wenn sie ein Kettenglied sind. Das ist unabhängig von den durchzureichenden Daten. Hierbei beachten, der Slave wird gepollt ... empfängt er nichts aus Richtung Master, tut er auch nichts.
Hinweis: die Adressierung sorgt dafür, daß nur angesprochene Slaves antworten, auch wenn sie den Master hören, aber das Netzwerk über die Adressierung festlegt, daß ein Kettenslave die Kommunikation übernimmt.


Alternativ zur Funkstrecke könnte auch ein RS485-Netzwerk stehen, wobei hier über Draht alles Slaves einen direkten Kontakt haben könnten ... oder eben auch eine Mischung aus allem :-)


Kontrollfunktionen-Ebene

Wenn das Netzwerk initialisiert ist, pollt der Master die Slaves zyclisch über das Netzwerk an um die Funkstrecke(n) zu prüfen.

Dieser Zyclus sollte allen Slaves bekannt sein oder bekannt gemacht werden, damit sie ihr Zeitfenster kennen, in dem diese selbständig Events melden dürfen.


Dantenübertragunsebene

Die nächste Ebene ist die Übertragung der Daten über das bestehende Netzwerk.

Kann das Netzwerk nicht genutzt werden, so ist das Event zwischenzuspeichern (fifo oder ring)

Ein Event wird dem Netzwerk zur Übertragung übergeben. (Im erlaubten Zeitfenster sendet der Slave also selbständig Events!!!)


Die Zeitsynchronisation ist in meinen Augen nur eine (wichtige) Sonderfunktion des Events. Wobei nach der Initialisierung des Netzwerkes das als erstes erfolgen muß, später dann ebenso passend zyclisch.




Idee verstanden ?



Deine Umsetzung der Unabhängigkeit vom Master finde ich hier nicht passend und zwar, weil der Master und der Mensch dahinter den Überblick behalten muß, was abgeht. Im Fehlerfall muß dieser auch den selbigen möglichst genau einschränken.

So wie Du das dargestellt hast, kann bei Fehlern (wo die auch immer herkommen) nicht festgestellt werden, ob es an einer Selbstfindung der Slaves untereinander liegt, oder eben an Übertragungsproblemen ...

Außerdem schriebst Du ja, daß Dein Netzwerk zu lange Laufzeiten hat ....

LG
Vajk

Also ich fasse mal zusammen was ich verstanden habe.

Master fragt am Anfang alle Slaves ab. Kennt anhand der Anzahl die IDs. Als nächstes wird die Zeit synchronisiert. Das ist wichtig da anhand dieser Zeit die Zeitfenster für die Sendungen der Slaves festgelegt wird.

Ist das so korrekt?

Das mit dem Durchreichen der Nachrichten klingt auch nicht schlecht. Würde die Reichweite der Funkstrecke noch mal erhöhen. Aber wie ist das in Einklang mit den Zeitfenstern zu bringen?

sast

Ja und Nein - mit Ebenen meine ich nicht nur die Reihenfolge sondern auch die entsp. Funktionsgruppe, Ebene, Layer ... ein Programmteil hat nur mit der Kommunikation zu tun, egal was dann später für Daten übertragen werden.

Der Prorammteil, der die Daten zur Versendung in Auftrag gibt, der will nur wissen:gehts oder muß ichs aufn SendeStapel packen um es später zu probieren.

Das Übertragungfszeitfenster hat nur indirekt was mit der absoluten Uhrzeit zu tun, sondern wie ein Kuchen, der in die Anzahl der Slaves +1 geteilt wird, das Kuchenstück wird daraus ermittelt, aus dem Polling der einzelnen Slaves durch den Master ... ein Kuchenrandumlauf entspricht dem Zeitabstand zwischen zwei Polls des Masters eines Slaves .. das erfolgt z.b. alle 20 sec. bei 3 Slaves hat also jeder Salve 5 sec. Zeit, Daten zu senden und kann die Datensendung auf dieses Zeitfenster beschränken - verstanden ?

Im vierten Zeitfenster sendet der Master wieder ein Poll zu einem der Slaves ... wobei die Zeitscheibe nicht unbedingt 20 sec. betragen muß ... aber sinnvoll könnte ... kommt auch auf die Anzahl der Slaves plus Master an.
Das einzelne Zeitfenster sollte so bemessen sein, daß z.b. 3 Sendeversuche von Daten reinpassen .. also bei 5 sec und 1200 Baud sind das - wenn ich micht nicht irre - etwa Platz für ca. 200 Byte Daten ( 5 x 1200 / 8 / 3 - Overhead wie Prüfsumme,Trennzeichen,Ziel-ID,Repeater-ID,[Repeater-ID,Repeater-ID,...],Absender-ID,Job) ... wobei der Job z.b. angibt ob die Daten für die Funknetzwerksteuerung dienen oder an die übergeordnete Ebene weitergeleitet werden sollen ....

Anhand der Gesamtanzahl der Slaves plus Master und anhand der funktionellen Repeater, wird der Master die Gesamtzeit der Zeitscheibe ermitteln und diese dann den Slaves global bei der Initialisierung mitteilen. Der Slave muß dann nur wissen, daß er alle 20 sec für 5 sec. senden darf ... wie geschrieben, wird das dann immer wieder durch den Master synhronisiert, wenn er ein "Bist Du da" an der einzelnen Slave sendet ...

Diese Form der Kommunikation entspricht wohl einem Multiplexen von Daten ... grübel .. oder .. bin nunmal kein Informatiker, entstammt also nur meiner Vorstellung eines solchen Ablaufs und meiner Analytik ... ich würde das so aufbauen.

Damit kannst Du auch gut hören und beobachten, was auf dem Funk passiert ... weißt wann wer sendet und so .. oder senden müßte

Das alles Slaves die gleiche Uhrzeit haben müssen, damit die Zeitmessung von Start zu Zeil auch stimmt ist eine Sache der höheren Ebene und eben "nur" Datenbeiwerk. Daten könnten auch sein, welche Temperatur, Helligkeit, Pulsschlag etc. am Standort des Slaves herrscht. Oder eben die Hauptaufgabe des Projektes, wann ein Lichtschrankenevent stattgefunden hat.

Die Daten, die auf unterer Ebene fließen dienen nur der Funkstreckenüberwachung und der Sendezeitsynchronisierung.

Idee jetzt verstanden ?

Damit sollte ich Deine Frage beantwortet haben, bzg. dem Einklang der Zeitfenster.

Auf dem Prinzip wäre auch eine dynamsiche Veränderung der Übertragungszeiträume möglich ... wenn Slave ausfällt oder Ersatzslave oder neuschlumpf dazukommt ...

All dies ist wiegesagt eine andere Ebene als dann die Daten die im paket dann transportiert werden können ...

ok, lass uns mal diese Ebene in die Praxis umsetzen. Der Master weiß natürlich am besten wie groß der maximale Zeitkuchen ist.

Die Idee mit dem Durchschleifen gefällt mir. Könnte man ja so bauen, dass beim Init durch den Master zuerst ein direkter Kontakt zu allen Slaves versucht wird. Da ja alle Slaves ein ACK senden, merkt der Master wenn er an einer Stelle nicht mehr weiter kommt. Dann könnte man ja den letzten erreichbaren als Repeater verwenden und die Initialisierung an dieser Stelle fortsetzen. Das läßt sich solange wiederholen, bis alle Slaves erreichbar sind oder aber feststeht, dass es so nicht geht.

Bin mal kurz durch den von dir angegebenen Link geflitzt und finde die Verwendung eines ATMega ist ziemlich gut. Zur Zeit habe ich einen Controller der ADC und RTC managed und eine Schaltung die den RS232 Code in die 1-2kHz Funksignale umsetzt. Wenn das alles in einem ist, wird das Ganze sogar noch etwas kleiner.

Muss das jetzt erst mal alles sacken lassen. Werde mir den Link noch etwas genauer ansehen - speziell die Softwareumsetzung.

Falls du noch irgendwelche Gedanken loswerden willst, dann halt dich nicht zurück. Meine Erfahrung ist: nur was man aufschreibt kann man nicht vergessen.

sast

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

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.

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

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.

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

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?

@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

>> 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 ;-)

@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

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 ?

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

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 ?

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

@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:

Zitat:

---

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 \:D/

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

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 ?

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

@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 !!

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

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