Ergebnis 1 bis 15 von 36

Thema: Statussystem Tetra

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Registriert seit
    21.04.2003
    Beiträge
    521
    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.

  2. #2
    Registriert seit
    30.07.2012
    Beiträge
    234
    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

  3. #3
    Registriert seit
    30.07.2012
    Beiträge
    234
    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

  4. #4
    Registriert seit
    02.09.2007
    Beiträge
    387
    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
    -----------

  5. #5
    Registriert seit
    24.04.2005
    Beiträge
    615
    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.

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •