Hallo das klingt interessant.
Kann die Software auch mit den Tetrapagern kommunizieren und Callouts auswerten?
Hallo das klingt interessant.
Kann die Software auch mit den Tetrapagern kommunizieren und Callouts auswerten?
Super! Hört sich extremst vielversprechend an! Jetzt hast du mich erst recht neugierig gemacht. Dann sind wir mal gespannt.
Hab es in unsere selbst programmierte Einsatz-Doku/Verwaltungs-Software miteingebaut. Es ist quasi die Middleware zwischen unserer Software und dem Tetranetz.
Statusmeldungen kann ich leider von unseren Fahrzeugen keine auswerten, da ich keinen Zugriff auf die Datengruppe habe.
Es loggt momentan "nur" die Gespräche von unseren Fahrzeugen in eine Datenbank mit und ich kann darüber SDS versenden und Einzelrufe zu den Geräten starten.
MQTT wird das ganze aber denke ich ein gutes Stück vereinfachen und schneller / stabiler machen.
Sowohl Airbus P8ger als auch der Motorola ADVISOR TPG2200 haben eine Schnittstelle, welche AT-Befehle unterstützen.
Hier mein aktueller Stand. Aufgrund der komischen Beschränkung der Datei-Typen beim Upload, habe ich wieder ein "zip" anfügen müssen. Nach dem Download einfach umbenennen und das zip wieder entfernen.
..._base.tgz -> das Basispaket
..._trx_sms.tgz -> das Transceiver-Plugin für SMS (GSM-Modem) - benötigt zusätzlich das Programm "Nullmodem" (nullmodem-0.0.6.tar.gz)
..._trx_sds.tgz -> das Transceiver-Plugin für SDS (MTM800FuG/MTP850)
..._trx_poc.tgz -> das Transceiver-Plugin für POCSAG (cijo ANTON)
..._sub_mysql.tgz -> Subscriber-Plugin um Meldungen in eine MySQL/MariaDB Datenbank zu schreiben
..._sub_mysql.sql -> SQL zum Anlegen der vom Plugin benutzten Datenbank-Tabellen
..._sub_sdsfrsms.tgz -> Subscriber-Plugin um Nachrichten die per SMS kommen in eine SDS umzuwandeln
..._sub_sdsfrpoc.tgz -> Subscriber-Plugin um Nachrichten die per POCSAG kommen in eine SDS umzuwandeln
Das Programm Nullmodem muss installiert (configure; make; make install) werden, wenn das Transceiver-Plugin für SMS verwendet wird. Nullmodem (a Utility to loopback Pseudo-Terminals) stammt von Juergen Rinas (http://www.ant.uni-bremen.de/whomes/...dem/index.html) und steht unter GPL. Beim Kompilieren kommt es bei mir zu Warnungen. Es funktioniert aber trotzdem.
In den SMS-Plugins verwende ich eine PHP-Klasse von https://github.com/SmsNica/pdu (mit meinen Bugfixes) zum decodieren und encodieren von SMS. Diese Klasse steht unter MIT License.
Die Lizenzbedingungen für alles, was ich geschrieben habe:
# Dieses Programm ist freie Software. Sie können es unter Beachtung der Nutzungsbedingungen benutzen,
# weitergeben und modifizieren.
# Die Veröffentlichung dieses Programms erfolgt in der Hoffnung, dass es Ihnen von Nutzen sein wird,
# aber OHNE IRGENDEINE GARANTIE, sogar ohne die Garantie der MARKTREIFE oder der VERWENDBARKEIT FÜR EINEN
# BESTIMMTEN ZWECK.
Alle Archive sollten per root entpackt werden: # tar xvPzf ...tgz Alle Programm-Teile liegen dann unter /usr/local/smi/...
Nullmodem habe ich unter /usr/local/nullmodem installiert (Parameter beim configure: ./configure --prefix=/usr/local/nullmodem). Wenn Sie es wo anders hin installieren, muss der Pfad zum Binary in der Config angepasst werden.
Ansonsten werden einige Linux-Pakete vorausgesetzt: stty awk php socat mosquitto_pub mosquitto_sub md5sum jq bc base64 mysql
Viel Erfolg!
Geändert von flachrelais_48 (15.01.2018 um 00:13 Uhr)
Hallo,
ich habe aktuell einen P8GR mit aktiviertem USB-Datenmodem an eine Raspberry-Pi mit aktuellem Raspbian-Image angeschlossen und bin damit am experimentieren...
Der P8GR hat eine PEI-Schnittstelle, die auch einwandfrei erkannt wird und durch dein Script auch angesprochen wird.
Leider klappt es mit der richtigen Interpretation der AT-Befehle noch nicht ganz korrekt und viele Befehle kennt der P8GR wohl auch einfach nicht.
Die Callouts kommen zumindest in der passenden Log-Datei an, nur in der SQL tauchen sie bisher nicht auf...
Da ich selber im Bereich Linux eher Neuling bin und schon sehr stolz auf mich bin, dass ich deine Scripte unfallfrei zum Laufen gebracht habe, wäre es nett, wenn du vielleicht ne Idee hättest, wo es hakt... ;)
Kann dir bei Bedarf gerne mal Logs der Module per PN schicken ;)
Na das klingt doch schon vielversprechend.
Ohne Dokumentation und ohne eigene Test-Möglichkeit, könnte es etwas umständlicher werden. :-)
Bin auch stolz auf dich. ;-) Linux ist cool! Hoffentlich fühlen sich andere ermutigt, es dir gleich zu tun. Immer her mit den Logs.
Bei mir läuft nun alles wunderbar durch, nur folgendes Command gibt einen Fehler zurück:
Code:tx AT+CTSP=1,2,20 rx +CME ERROR: 3
https://www.etsi.org/deliver/etsi_en...05v020200o.pdf
Wenn ich die Spezifikation richtig Verstehe, steht die
1 -> service profile / 1 = TE only
2 -> service layer1 / Short Data Service (SDS)
20 -> service layer2 / 20 - Status
Verwendet wird das MTM800ET FuG.
Weicht hier Motorola von der Spezifikation ab?
Gibts eigentlich zu der ETSI Spezifikation, irgendwelche Wiki's, HowTo's, etc. - jemanden was bekannt?
Bei Motorola verhindert die Notruf-Funktion das Registrieren von Status ausschließlich für die PEI. Also kannst du auf dem FuG Notruf deakivieren oder das SP auf MT + PEI setzen.
habs geändert nun OK, aber egal was ich für einen Status drücke ich erhalte folgendes:Code:smi: tx AT+CTSP=2,2,20 smi: rx OK
(ISSI geändert in 1234567)
Ich hätte etwas anders erwartet, da kann ich ja nichts auswerten?Code:Status 1 gedrückt: smi: rx +CTSDSR: 13,2490293,0,1234567,0,16 smi: rx FE00 Status 2 gedrückt: smi: rx +CTSDSR: 13,2490293,0,1234567,0,16 smi: rx FE00
Was hättest du denn erwartet? Hast du den Status auf dem Gerät gedrückt wo du mit der PEI verbunden bist? Dann siehst du auf der PEI nicht, welchen Status du sendest. Das "FE00" ist eine Quittung, das dein Staus empfangen wurde. Hast du ein bestimmtes Anwendungsszenario im Auge?
Im sds.log fand ich folgendes:
Und am Funkgerät wird die Quittierung ja als Neue Nachricht angezeigt... Von ILS XY ... BY..... Auf Wache.Code:19:01:16 sds.motorola.rx.ttyUSB0: txrx: "rx" device: "ttyUSB0" id: "2190211" 19:01:16 sds.motorola.rx.ttyUSB0: visible: 0 19:01:17 sds.motorola.rx.ttyUSB0: creating new rx SDS message object 19:01:17 sds.motorola.rx.ttyUSB0: publishing rx SDS message object on MQTT topic "smi/msg/sds/rx"
Daher dachte ich, das die Quittierung eine SDS ist.
Folgendes habe ich wenn eine Sprechtaste aufgetastet wird oder?
Code:smi: rx +ENCR: 15,BYXY XYZ0123456789123456
Zum PEI-Log bei Drücken der Sprechtaste kann ich nix sagen. In meiner Anwendung sind die FuGs auf eine reine Datengruppe geschaltet. Da wird kein Gruppenruf empfangen.
Zu Zitat: "Und am Funkgerät wird die Quittierung ja als Neue Nachricht angezeigt... Von ILS XY ... BY..... Auf Wache. Daher dachte ich, das die Quittierung eine SDS ist." fällt mir folgendes ein:
Wenn das Nachrichtenrouting auf die PEI gesetzt ist, dürften die Nachrichten nicht mehr im Nachrichteneingang ankommen. Im Umkehrschluss heißt das, dass du noch Meldungen empfängst, die nicht auf die PEI geroutet werden. Sind das Meldungen die auf das "Home Mode Display" gesendet werden? Du kannst ja mal die PIDs 204 und 220 auf die PEI leiten und schauen...
Die Quittungen, die ich im vergangenen Post meinte, waren Status-SDS mit "FE00", die beinhalten aber keinen Text.
Danke Dir! :) PID 220 wird angenommen, 204 liefert Fehler 33 oder 3.
Code:smi: tx AT+CTSP=1,3,220 smi: rx OK smi: tx AT+CTSP=1,2,204 smi: rx +CME ERROR: 33 smi: tx AT+CTSP=1,3,204 smi: rx +CME ERROR: 3
sds log wieder wie gewohnt:
und im ttyUSB.log auch nicht mehr:Code:sds.motorola.rx.ttyUSB0: txrx: "rx" device: "ttyUSB0" id: "2190211" sds.motorola.rx.ttyUSB0: visible: 0 sds.motorola.rx.ttyUSB0: creating new rx SDS message object sds.motorola.rx.ttyUSB0: publishing rx SDS message object on MQTT topic "smi/msg/sds/rx"
Code:smi: rx +CTSDSR: 13,2190211,0,1234567,0,16 smi: rx FE00
Aktive Benutzer in diesem Thema: 3 (Registrierte Benutzer: 0, Gäste: 3)