Zeitmessstrecke mit Funkübertragung

[sast]

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

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.

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

[vajk]

Öhm ..

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

[sast]

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

[vajk]

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

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

...

[sast]

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

[vajk]

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

[sast]

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

[vajk]

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

[sast]

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