TETRAcontrol

[Pringman]

Bei der Sprechaufforderung gibt es derzeit 3 Optionen:
1) Status (z.B. der BDBOS Standard 80F7)
2) Normale SDS (PID 130)
3) Flash SDS (PID 137)

Nutzt Variante 1 jemand? Mir ist in der Praxis nur Variante 3 bekannt.

[schubi4908]

Moin,

hat schonmal jemand eine Rückmeldung bzw. Verfügbarkeit vom Motorola TPG2200 empfangen? Uns wurde mitgeteilt das lässt sich nur mit dem alarmierenden Gerät wieder empfangen. Was somit die Leitstelle wäre und nicht unser Gerät. Kann das jemand bestätigen?

Gruß

[ahk]

Dir Rückmeldungen gehen immer an die Alarmierende Stelle.

Das Feature "Rückmeldung an zweites Ziel" hat meines Wissens derzeit nur der Airbus P8GR.
Ob und wann das auf dem TPG2200 kommt, werden wir sehen.

Grüße
Arne

[MeisterH]

Moin zusammen,

ich verbringe aktuell viel Zeit vor Reportagen, dabei blieb ein kleines Schmunzeln nicht aus, bei einer Reportage aus dem maritimen Sicherheitszentrum Cuxhaven, siehe Anhang.

Hut ab, welche Entwicklung TETRAcontrol so durchgemacht hat, und wo es scheinbar überall zur Anwendung kommt!

[westi]

Hallo Zusammen,
ich würde gerne mit Tetracontrol ein zweites System (PHP-Webanwendung) füttern und mache mir nun Gedanken über mögliche Realisierungen..

1) Aktionsverarbeitung -> Funktioniert nur für Status. GPS-Daten und Gespräche sind kein mögliches Auslösekriterium
2) Aktionen->An Webserver senden -> Hier fehlt ein passendes Format, ich müsste ähnlich wie bei der Aktionsverarbeitung mit Variablen in der URL arbeiten. Leider werden keine Werte übergeben, wahrscheinlich muss hier eine der in der Dokumentation angegebenen APIs genutzt werden. Da meine URL keine der bekannten entsprechen wird, müsste ich mich wohl in JSON einarbeiten und die firEmergency-API nutzen?
3) Den HTTP-Websocket über einen noch nicht vorhandenen Client auslesen, welcher eine Datenbank füttert. Dafür fehlt leider die Vorkenntnisse
4) MQTT-Client, welcher eine Datenbank füttert?

Hat sich hier schon jemand mit dieser Fragestellung beschäftigt oder hätte Lösungsansätze?

Mein Favorit wäre ja eine Erweiterung von Variante 1 oder 2.

[ahk]

Hallo,

alle 4 Optionen sollten (zumindest für GPS Daten) funktionieren.
1) Aktionsverarbeitung: PID = 10 setzen. Die Daten werden dann im Text übertragen ($TEXT$). Beispiel: "GPS: 51.207477° 9.456371° 1km/h 0° ~200m"
2) Du könntest in die URL irgendwo die Zeichenfolge "/api/issiupd" einbauen, dann werden die Daten als HTTP GET übertragen (&status=... &lat=... &lon=....)
Beide o.g. Varianten können nicht für Gespräche genutzt werden
3) Das ist die technisch beste Variante
4) MQTT ist auch sehr einfahc zu realisieren. Auch dort derzeit keine Gesprächsdaten

Grüße
Arne

[westi]

Hallo Arne,

habe nun deine Ratschläge für Variante 1 und 2 getestet, da Variante 3 erst einmal eine Einarbeitung ins Thema Websocket und JSON erfordert.

zu 1) Die LIP-Positionsangaben werden auch bei PID 10 nicht übertragen, selbst wenn ich die Zeile "PosLog;;;;;;;;;PosLog" in der Events.csv probiere, wird die Action nicht ausgelöst, Statusmitteilungen kommen unverändert an
zu 2) Funktioniert super für Status und Position, allerdings würde ich mir hier ein paar Angaben wie Ziel-GSSI oder zumindest über welches Gerät es rein kam wünschen.

Wie es mir bisher scheint müsste ich eine Kombination von beiden Varianten realisieren, bis ich im Thema Websocket weiter bin. Variante 2 für die Positionen, Variante 1 für Status (wegen Ziel-GSSI) und SDS.

Aber schon einmal Danke für die Tipps.

Vielleicht kommt ja bei einem der nächsten Updates eine Erweiterung für die Variante 2?

Gruß,
Christian