Also Dank Shrek87 und seiner Leitstelle haben wir ein paar Test SDS empfangen können.
Wie erwartet werden die SDS als Typ UDH (PID 138) verschickt, nicht als verkettete SDS-TL (PID 140).
Die Decodierung funktioniert in TETRAcontrol jetzt sauber. Die entsprechende offizielle Version erscheint Ende Februar.
Die Anzeige und das Logging sind erstmal als eine Teil-SDS pro Zeile realisiert, mit Anzeige der Nummer und Gesamtzahl der Teile. Falls jemand eine Weitergabe der kompletten Nachricht an andere Programme, wie z.B. firEmergency benötigt, dann bitte melden. Dazu muss nur geklärt werden, welches Format (Text, XML) und wie (z.B. in eine Datei oder per Netzwerk) die Bereitstellung erfolgen soll.
Grüße
Arne
Einsatzdokumentation und Lageführung
http://www.einsatzdokumentation.net/
Digitalfunk im Griff: http://www.tetracontrol.de/
OK. Mir war anhand des Eröffnungs-Posts nicht klar, dass es um Tetracontrol geht.
Der PID "138" (UDH) wird laut ETSI-Spec als "Message with User Data Header" beschrieben.
Das klingt für mich danach, dass es dem Anwender obliegt ein eigenes Protokoll zu verwenden? Was war denn nun die Lösung?
@Shrek87
Ich verstehe nicht, warum die Nutzung eines Netz-Features eines BOS-Netzes (SDS) eine "Bastellösung" sein soll. Gegen das Verlorengehen von SDS gibt es doch Sicherungsmechanismen wie z.B. Report- und Acknowledgement-SDS für Text-SDS (PID 130). Viele überteuerte kommerzielle Lösungen sind aus meiner Erfahrung auch nur schöner verpackte Bastellösungen.
Wie sähe denn die Lösung mit direkter Anbindung per LWL aus?
@Kermit_t
Das wäre ja das Ende jeder Innovation. :-(
Evtl. ist man den anderen, die dieses Problem (noch) nicht haben, auch nur voraus?
Leute! Bleibt neugierig, stellt Fragen, probiert alles aus und schafft euch eure Lösungen! ;-)
Nö, ging eigentlich nicht um TETRAcontrol sondern um die Darstellung einer Alarmierung z.B. in firEmergency.
Aber da mich das Thema interessiert hat, hab' ich mich mal eingemischt und damit beschäftigt und nun funktionierts. Ich vermute mal, dass Simon von firEmergency das auch implementieren wird. Aber da es sicherlich einige Benutzer gibt, die sowohl Ihre Geräte steuern wollen und z.B. SDS verschicken, aber gleichzeitig auch die Daten in FE übernehmen wollen, wäre es ja praktisch wenn man TETRAcontrol und firEmergency verbinden kann und somit nicht zwei Digitalfunkgeräte braucht.
Ansonsten stimme ich Dir voll und ganz zu: Neugierig bleiben, Innovativ sein!
Grüße
Arne
Einsatzdokumentation und Lageführung
http://www.einsatzdokumentation.net/
Digitalfunk im Griff: http://www.tetracontrol.de/
Es ist deshalb eine Bastellösung, weil es das eigentliche Problem nicht behebt, nämlich das man einen Ausdruck braucht, der schneller da ist als ein Fax. Und das andere ist, ich würde was die Nutzung von Diensten betrifft, wäre ich derzeit eher vorsichtig. Bevor man da jetzt viel Energie reinsteckt und einem am Ende jemand sagt, dass man es nicht darf.
Was ist denn mit dem Versand der Alarmmeldung per Email und ggf. noch eine Weiterverarbeitung vor dem Ausdruck wie Umgebungskarte oder so?
Genau das ist es eben nicht. Es bedeutet einfach nur, nochmal eine Runde zu drehen und zu überlegen, ob man wirklich an alle Möglichkeiten gedacht hat und es nicht vielleicht doch noch bessere Möglichkeiten gibt.@Kermit_t
Das wäre ja das Ende jeder Innovation. :-(
Evtl. ist man den anderen, die dieses Problem (noch) nicht haben, auch nur voraus?
Leute! Bleibt neugierig, stellt Fragen, probiert alles aus und schafft euch eure Lösungen! ;-)
Und die tolle Innovationskraft sehen wir ja im Feuerwehrbereich jeden Tag, unheimlich kreative Fahrzeuge, möglichst viele Normen und der ganze Unsinn.
Also der SDS Empfang kann ja FE schon länger. Es ging nur eben um die verkette SDS. Aber hier scheint es ja ein Lösung zu geben.
Wenn du eine Schnittstelle an FE realisieren willst, kannst du hier mal schauen:
http://alamos-ug.de/mediawiki/index.php?title=TCP/IP
Darum kümmert sich dann FE. Sobald die SDS eingegangen ist, kann man damit wieder machen was man will (AlarmMonitor, an Handy schicken, email, etc.)
Der Foreneintrag war eigentlich allgemein gehalten……
und nicht Programmspezifisch…
@flachrelais_48 / Kermit_t_f
In Bayern ist leider alles etwas anders, es gibt nur begrenzt Möglichkeiten um an Einsatzrelevante Daten aus der ILS zu kommen.
Möglichkeiten:
- SMS -> zu unsicher
- Alarmfax -> zu langsam
- 5-Ton / Durchsage -> Sprache in Text UNMÖGLICH ;-)
- Folgetext -> zu unsicher
- KEZ Schnittstelle -> die einzigste Firma die offiziell an diese Schnittstelle andocken darf hat es nicht mehr nötig uns ein Angebot zukommen zu lassen, und ist mit erheblichen Kosten verbunden (nach unserer Informationen mehrere 10.000€) (nichts anderes wie ein einfache unidirektionale xml Übertragung -> z.B. über LWL…. VPN… etc.)
- SDS -> NEU und bist jetzt funktioniert es auch…. Wenn die ILS Vollumfänglich angebunden ist, gehen wir auch mal das Thema Report- und Acknowledgement-SDS an, zur Zeit gibt es noch andere Dinge zu klären
- E-Mail lässt das Sicherheitskonzept nicht zu
Wie firEmergency schon geschrieben hat, mit dem passenden Programm wird durch die SDS ein eigenes Alarmfax / Google Karten / eigene Straßenbeschreibungen / Handyalarmierung / Alarmmonitor / Routing an die Fahrzeuge / innerhalb von 2 sec abgearbeitet……
d.h. also nach ca. 4 Sec nach der 5 Ton Folge bekommt der Drucker seine Druckaufträge….. (mit einer SDS) (mit Fax kann man nochmal 35 sec länger warten bis überhaupt etwas passiert)
und firEmergency läuft bei uns seit Beginn an störungsfrei durch
In anderen Bundesländern bzw. Leistellenbereichen außerhalb Bayerns werden die Daten und Statusmeldungen der Fahrzeuge über eine XML Schnittstelle „veröffentlicht“, das ist natürlich eine 1A Lösung……. Davon sind wir aber noch weit entfernt, bzw. ist anscheinend nicht gewünscht.
Gruß
Shrek87
Schreib mir mal bitte per PN, welche ILS und welche Ständige Wache es ist. SMS und Email als zu unsicher einzustufen und es dann im Klartext über nicht verschlüsselten BOS-Funk zu übertragen ist ja ein schlechter Scherz, da höre ich mal nach.
Versuche gerade auch "verkettete" PID 138 SDS(en) zu decodieren.
Kämpfe aktuell mit dem Header. Den ersten Teil hab ich schon, ist aber eine mühselige Angelegenheit, daher die Frage:
Hat irgendjemand weitere hilfreiche Dokumente, Quellen,... wie diese "spezielle" bayerische ;) SDS aus ELDIS3BY aufgebaut ist? Gerne auch per PM.
Betrifft zwar Motorola, aber wenns bei Sepura dokumentiert ist würde es mir vermutlich auch schon weiterhelfen.
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)