Hallo allerseits,
wie ich im ZigBee-Thread schon schrieb, braucht man ein Programm, das auf dem Koordinator dafür sorgt, dass die von den Handreglern ( und später von den Loks ) einlaufenden Statustelegramme ihren Empfängern übermittelt bzw. im Fall der Handregler aus den abgelesenen Werten der ADCs und der Digitaleingänge Fahrbefehle und Funktionsbefehle für die den dem Fahrregler zugeordnete(n) Lok(s) macht. Die spuckigste Arbeit ist da erst mal das Handhaben der seriellen Kommunikation. Man muss ja Strings zusammenbauen und senden oder solche einlesen. Dazu habe ich wirklich brauchbare C-Routinen hier gefunden: https://projects.drogon.net/raspberry-pi/wiringpi/. Bei z. B. der netzmafia haben die Senderoutinen funktioniert, aber die Empfangsroutinen lieferten nur Schrott zurück. Das hat mich zwei Tage gekostet. Heute abend dann auf diese Seite gestoßen und die Routinen in ein Programm zusammencompiliert: Schon zeigte der Bildschirm ( man baut ja zum Testen immer ein printf.. ein) das Gleiche wie das Linux-Programm 'minicom' an. Jetzt ist ein Fertigstellungstermin des Gesamtprogramms bis Freitag realistisch.

Es ist zwar spät geworden, aber jetzt läuft die Nullversion des Netzwerkprogramms. Ich kann also mit dem Handregler die Lok steuern. Die Zustandsmeldungen werden im Augenblick noch über eine normale LAN-Verbindung an einen an den Raspi angeschlossenen Schleppi gegeben. Wie üblich hat sich die Fertigstellung des Programms wegen ausgiebigen PICNICs meinerseits verzögert ( das Wetter war ja so schön..)
Für die, die es nicht kennen: PICNIC = Problem In Chair Not In Computer!

Für die, die wissen wollen, was ich im Augenblick per Software kann:
Umsetzung der Drehreglerwerte in entsprechende PWM für den Motor des Schienenbusses.
Einlesen von Kippschalter und Tastern für Richtungsvorgabe und Funktionsauslösung. Spaßeshalber sind von den 8 benutzten ( es sind noch 3 frei, ebenso die serielle Schnittstelle) Ausgängen des Empfängers 4 rastende Ausgänge (Beleuchtung ein/aus) und 4 Momentausgänge ( Ausgang so lange an, wie Taste gedrückt) im Programm eingestellt.
Konnte diese beliebige Zuordnung eigentlich WLANCROC oder WLAN-TL?
Rückmeldung der Akkuspannung des Fahrzeugs auf ein per LAN-Kabel am Raspi angeschlossenes Tablet. Hier wird also parallel noch ein Netzwerk ( mit 2 Teilnehmern) unter Linux betrieben.

ateshci hat geschrieben:Spaßeshalber sind von den 8 benutzten ( es sind noch 3 frei, ebenso die serielle Schnittstelle) Ausgängen des Empfängers 4 rastende Ausgänge (Beleuchtung ein/aus) und 4 Momentausgänge ( Ausgang so lange an, wie Taste gedrückt) im Programm eingestellt.
Konnte diese beliebige Zuordnung eigentlich WLANCROC oder WLAN-TL?

Hallo Heizer,

geplant war vieles ... aber soweit ist das ursprüngliche WLANCROC-Projekt nicht mehr gekommen.

Nach meinem Kenntnisstand sind die Ausgänge bei WLAN-TL nur als rastend vorgegeben. Aktuelle Bedienungsanleitungen sind als Nichtkäufer weder vom Entwickler noch von Trainline zu bekommen. Angeblich steht die Anleitung im Netz. Die dem ausgelieferten WLAN-TL-Raspi beigelegte Anleitung ist allerdings eine andere. Eine Anfrage von mir bei Trainline bestätigte die nur rastenden Funktionsausgänge.

Viele Grüße
Holger

Es gibt zwei Möglichkeiten, ein ZigBee-Netz zu betrieben.
Den ersten Fall habe ich realisiert: Die Netzteilnehmer können nur von einer Zentrale am Netzkoordinator auf Daten abgefragt und Daten übermittelt bekommen.
Das heißt, in der Zentrale werkelt ein Programm, das die Teilnehmer entsprechend miteinander zuordnet und den Datenverkehr steuert.
Der Vorteil iegt darin, dass man neben den ZigBee-Modulen je nach ihrer vom Hersteller mitgegebenen Programmausstattung keine weitere Rechnerintelligenz auf der Teilnehmerseite braucht, um dort digitale Ausgänge zu setzen, analoge Spannungen und Eingänge zu lesen. So etwas ist dann relativ schnell gemacht und ins Laufen zu bringen. Der hauptsächliche Nachteil liegt darin, dass man wegen des Befehls- und Datenformats dann auf einen Hersteller festgelegt ist.
Im zweiten Fall arbeitet der Netzkoordinator für sich allein, denn in den Fahrzeugen und Handsteuergeräten sitzt jeweils zusätzliche Rechenleistung, die sich um die Datenaufbereitung und -verkehr kümmert. Z.B. weiß jeder Handregler schon von vornherein, welchem Fahrzeug er seine Daten zu schicken hat und es kann auch eine Tabelle für mehrere Loks dort abgelegt werden.
In dem Fall ist eine Zentrale nicht nötig und es können auch ZigBee-Module anderer Fabrikate in das Netz eingebunden werden. Er entspricht auch ziemlich dem WLAN-Betrieb.
Der Unterschied zu WLAN besteht aber weiterhin darin, dass im Netz eine Maschenstruktur herrscht, d. h. falls sich Absender und Adressat direkt 'sehen', gehen die Daten ohne Umweg dorthin. Nicht für den Adressaten bestimmte Daten werden an den nächsten Teilnehmer weitergeleitet und springen so über die verteilten ZigBee-Devides zum Ziel.