1. bestimme ich sowas nicht und 2.ist das bei uns schon immer so.
und 3. ... bei uns die sollen mehr Arbeiten ???ha ne Beamten machen die net :-)
Wie ist das bei Euch Aufgebaut ?? macht bei euch das alles die Leitstelle ??
1. bestimme ich sowas nicht und 2.ist das bei uns schon immer so.
und 3. ... bei uns die sollen mehr Arbeiten ???ha ne Beamten machen die net :-)
Wie ist das bei Euch Aufgebaut ?? macht bei euch das alles die Leitstelle ??
Gruß MasterOfFire
in den Betrieblichen Regelungen zur Durchführung des Digitalfunk BOS steht alles drinnen.
Anlage 1 regelt OPTA Adressen
Anlage 2 Statusmeldungen
diese sollten über entsprechende Wege dienstlich zu erlangen sein.
Hallo,
eine Leitstelle, die gar keine Übersicht über ihre Einsatzmittel hat?????
Zum Glück gibt es so etwas bei uns nicht, da wir schon seit 20 Jahren integrierte Leitstellen und nun Regionalleitstellen haben. Und ja, die haben jedes Fahrzeug auf dem Schirm und funken auch mit diesem.
"Lokale" Führung gibt es nur bei größeren Schadensfällen bzw. zur Abarbeitung von Unwettereinsätzen auf "Amtsebene".
Knut
bei uns Alamiert die Leitstelle nur die Feuerwehr mit Zentrale.
Die Leitstelle weis dan das XY dort einen Einsatz hat.. weis aber nicht welche Fahrzeuge dort hinfahren oder nachgefordert werden.....
Gruß MasterOfFire
Ich glaub da war eher der 112-Notruf gemeint :-)
Naja, stimmt meinem Kentnissstand nach nicht ganz. Laut Christof Linde "Aufbau und Technik des digitalen BOS-Funks" beherrscht das SDS sowohl Punkt-zu-Punkt- als auch Punkt-zu-Mehrpunkt-Verbindung. Also müsste es von technischer Seite her möglich sein sowohl die Lst als auch einen ELW und/oder ein Gerät im Gerätehaus anzugeben. Dieses Gerät kann dann den Status über die PEI entsprechend weiterreichen. Z.b. an FMS64, welches dann auch Digitalfunk kann ;-)
Müsste halt nur noch geschrieben werden...
Aber Spaß bei Seite.
Gerade bei größeren Ereignissen wie Sturm oder Hochwasser ist es Gang und Gäbe, dass die örtliche Feuerwerwehr ihre Einsätze selbst abwickelt. Von der Leitstelle werden quasi nur noch die Einsatzstellen übermittelt.
Und gerade hier würde ein System wie oben beschrieben sehr Sinvoll sein.
Denn Einsätze selbst abarbeiten heißt die Übersicht zu bewahren, Zeiten mit zu schreiben und eben alles das zu machen, was sonst die Lst erledigt.
Und genau hierfür wurde das Statussystem eingeführt.
Alles wieder im Klartext übertragen wäre ein Rückschritt.
In diesem Fall ist Multipunkt anders zu verstehen. Du kannst Status-SDS an eine Einzeladresse oder an eine Gruppenadresse senden. Letzteres wäre dann Multipunkt, weil beliebig viele Teilnehmer in dieser Gruppen mithören und somit auch die SDS empfangen könnten.
Mehrere Empfänger in eine Status SDS packen kann kein TETRA-Endgerät derzeit, ist auch imho nach ETSI nicht vorgesehen, da bin ich aber nicht 100%ig drin.
Ob das so gewünscht und sinnvoll ist, muss man anderweitig entscheiden.
Hallo zusammen,
ich arbeite an einer Lösung, Status-SDS in unserer Leitstelle die mitttels FuG empfangen wurden zur weiteren Verwendung in eine MySQL-DB zu schreiben.
Da SDS im TETRA ähnlich wie SMS im GSM sein sollte, hatte ich die Idee, eine vorhandene SMS-Software dafür zu nutzen. Ich denke da an die "SMS Server Tools 3" von Keijo Kasvi http://smstools3.kekekasvi.com/.
Mein Versuchsaufbau besteht aus einem Motorola MTM800FuG als SDS-Empfänger, an welches mittels PEI-Interface und Seriell-zu-USB-Kabel an einen PC mit seriellem Terminal (Hyperterminal) angeschlossen ist und einem Motorola MTP850 als SDS-Sender.
Leider habe ich die Erfahrung von coolcat1975 teilen müssen. Es klappt nämlich nicht wie erhofft.
Einen Teilerfolg habe ich aber bereits errungen. Status-SDS werden auf dem PEI-Interface als sog. "unsolicited message" ausgegeben.
Bsp. für einen empfangenen Status "1":
+CTSDSR: 13,6xx4x46,0,6xx4x76,0,16
8003
Aufgeschlüsselt müsste es bedeuten:
13 - AI service - type of service: Status (16 bits, some values are reserved in EN 300 392-2 [3])
6xx4x46 - calling party identity - Absender
0 - calling party identity type - type of identity: SSI
6xx4x76 - called party identity - Empfänger
0 - called party identity type - type of identity: SSI
16 - length - Dem Haeder im Textmode folgen nach "CR LF" 16 Bit User-Daten im HEX-Format
CR LF - Zeilenumbruch
8003 - user data - Dezimalwert 32771
Nach diesem Muster habe ich alle vordefinierten Status-SDS durchgespielt. Dabei enthielten die User-Daten HEX-Werte von 8002 - 800B (dezimal 32770 - 32779) sowie 80F2 - 80FF (dezimal 33010 - 33023).
Nun aber der Reihe nach. Hier einige interessante Abfragekommandos:
at+creg?
+CREG: 1,15980,26201001
OK
---> Network registration
---> Reg stat, [LA], [MNI]: wir sind im Heim-Netz eingebucht
at+csq?
+CSQ: 18,99
OK
---> wir haben einen Empfangspegel von -77dBm?
at+gcap?
+GCAP: TETRA,1a9360,0
OK
---> MT Capabilities
---> TETRA, [class of MS], [stack present]: (0 - Stack present; 1 - Stack not present) also SDS message stack vorhanden!
at+ctsp?
+CTSP: 0,0,0
0,1,11
2,2,20
1,2,21
1,2,22
1,2,23
0,3,10
0,3,130
0,3,220
0,3,230
0,3,240
0,4,30
OK
---> TETRA Service Profile
---> service profile, service layer1, [service layer2]
Interessant ist hier 2,2,20: SDS (2) vom Typ Status (20) werden an MT und TE geroutet (2).
Alle anderen SDS-Typen(21-23) werden nur an TE geroutet (1).
Das verwirrt mich nun aber total. Ich dachte, mein serielles Terminal an der PEI-Schnittstelle ist das TE?
Um nun per Umkehr-Prüfung herauszufinden, ob diese Einstellung "Schuld" daran ist, das außer Status-SDS keine anderen SDS-Meldungen als "unsolicited message" auf der PEI-Schnittstelle ankommen, wollte ich die Service Profile ändern. Leider hat das Gerät die Einstellungen nicht aktzeptiert:
at+ctsp=2,2,21
+CME ERROR: 33
at+ctsp=2,2
+CME ERROR: 33
Die AT-Kommandos die eigentlich zur SDS-Behandlung vorgesehen sind, funktionieren leider auch nicht:
at+cmgl?
+CME ERROR: 35
at+cmgl=?
+CME ERROR: 4
at+cmgl=13
+CME ERROR: 4
at+cmgl=13,0
+CME ERROR: 35
at+cmgl=13,1
+CME ERROR: 4
at+cmgl=13,2
+CME ERROR: 4
at+cmgl=13,3
+CME ERROR: 4
at+cmgr=13,1
+CME ERROR: 4
at+cmgr=10,1
+CME ERROR: 35
at+cmgr=11,1
+CME ERROR: 4
In der Spezifikation steht "All new incoming SDS messages onto any of the SDS stacks are indicated to the TE by the +CMTI command."
Wenn also wie durch +gcap gemeldet ein SDS message stack vorhanden ist, müssten doch eingehende SDS mittels +CMTI gemeldet werden, was aber nicht passiert.
Irgendwie komme ich hier nicht weiter. Hat jemand Tips wie ich mittels PEI an die empfangenen SDS komme? Über das Bedienteil kann ich natürlich alle SDS unter Nachrichten/Eingang sehen.
Verzweifelte Grüße
Ich habe meine Herausforderung gelöst. Ich habe mich aber gegen die Modifikation der SMS Server Tools und für ein selbstgeschriebenes kleines Linux-Shellscript entschieden.
Schöne Grüße
Hallo
finde das sind gute Ideen die hier angesprochen worden sind. Jetzt nur mal ehrlich. Braucht man wirklich bei einer FEZ die Anzeige von Statusmeldungen von den Einsatzfahrzeugen die gerade im Einsatz sind.
Auch wenn mehrere Einsätze sind wie beim Unwetter. Reicht es doch aus das man mündlich mitgeteilt bekommt das das Fahrzeug X am EInsatzort an ist oder nicht?!
mit freundlichen Grüßen
doubleG112
-----------
Warum Mündlich durchgeben, wenn es Technik gibt, die das kann? Seit Jahren nutzt man ja auch FMS - und das ist letztendlich bei Tetra genau das gleiche. Allerdings bringt hier Tetra einen kleinen Vorteil mit: Keine Belegung des Sprachkanals, bei xRT`s mit GPS auch Standortübermittlung.
Wenn (bei Unwettern o.ä. Großlagen) richtig Bambule ist, bist Du froh, wenn Du solch Statusänderungen nicht auch noch von Hand im Programm o. sonstwo vermerken musst ;)
Von unterwegs gesendet, Gruß, WG
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)