POCSAG - Frames - RICs

[rd-lst]

Hallo Gemeinde :)

Mal wieder ein Verständnisproblem zum POCSAG-Protokoll. :/

Ich lese in sämtlichen Erklärung zum Aufbau des Protokolls, dass Adressen nicht im Frame 0 liegen dürfen.

Daraus leite ab, dass eine RIC mod 8 zwingend > 0 sein muss.

Nun haben wir bei uns im Landkreis in der Alarmierung sehrwohl RICs, die Modulo 8 ein Ergebnis von 0 liefern, vergeben. Und das funktioniert auch.

Warum!?

In diesem Beitrag hier auch gleich noch die Frage - falls sie jemand beantworten kann:
Ich bin auf der Suche nach einer Erklärung, warum zwischen dem Auslösen zweier Pieper mit unterschiedlichen RICs in unterschiedlichen Frames, sehr viel Zeit (mitunter > 30 Sekunden) vergeht.
Ist es sinnvoller, bei oft gleichzeitig alarmierten RICs (bspw. RTW + NEF) diese in einen bestimmten Frame-Abstand zu packen?
Ist dann nicht letztendlich die Zeit zwischen dem Auslösen der jeweiligen RICs wiederum von der Länge des Alarmtextes abhängig?

Oder denke ich viel zu kompliziert!? :)

[F64098]

Ich lese in sämtlichen Erklärung zum Aufbau des Protokolls, dass Adressen nicht im Frame 0 liegen dürfen.

Sollen. Man verwendet den Frame 0 hierzulande für die Steuernachrichten der DAU.
Theoretisch muß man nun nach der Steuernachricht ein komplettes Batch mit Idles senden, um wieder im im nächstfolgenden Frame 0 den Alarm-RIC aussenden zu können. Man verschenkt somit zwischen einer halben und einer ganzen Sekunde.
Man mag selber entscheiden, wie schlimm das ist.

Daraus leite ab, dass eine RIC mod 8 zwingend > 0 sein muss.

Idealerweise ist es das. Bei mehreren RIC in einer Aussendung fällt es prozentual aber nicht mehr ins Gewicht.

Nun haben wir bei uns im Landkreis in der Alarmierung sehrwohl RICs, die Modulo 8 ein Ergebnis von 0 liefern, vergeben. Und das funktioniert auch.
Warum!?

Adressworte im Frame 0 sind grundsätzlich gültig und jeder DME kann sie auch decodieren.
Da jedoch in den ersten 32 Bit des Frame 0 die Steueradresse (samt Unteradresse) und in den nächsten 32 Bit die Steuerzeichen für die DAU ausgesendet werden, müssen danach eben _immer_ 7 Leerframes gesendet werden, wenn DME-RIC im Frame 0 verwendet werden.

Ist es sinnvoller, bei oft gleichzeitig alarmierten RICs (bspw. RTW + NEF) diese in einen bestimmten Frame-Abstand zu packen?

Nur beim Express-Alarm, wobei ja pro Frame 2 Adressworte gesendet werden können, also auch beide RIC im selben Frame liegen dürfen.
Im normalen System ist der Frame-Abstand egal, da nach dem Adresswort solange Datenworte gesendet werden, bis das letzte Zeichen gesendet ist. Und dann ist es mehr oder minder vom Zufall abhängig, wieviele Leerframes zwischen dem letzten Datenwort und dem ersten richtigen Frame für das nächste Adresswort liegen.

Ist dann nicht letztendlich die Zeit zwischen dem Auslösen der jeweiligen RICs wiederum von der Länge des Alarmtextes abhängig?

Bei überlangen Texten in Systemen mit älteren DAU teilt der Alarmgeber die Mehrfachalarmierung in einzelne Nachrichten auf. Je nach Anzahl der Ringe und Länge des Textes sind Zeitversätze von bis zu 30 sec. zwischen den einzelnen Alarmen möglich. Ältere DAU können nur max. 240 Zeichen zwischenspeichern.

HTH

Frank

[Kater 9]

Hallo Gemeinde :)

Mal wieder ein Verständnisproblem zum POCSAG-Protokoll. :/

Ich lese in sämtlichen Erklärung zum Aufbau des Protokolls, dass Adressen nicht im Frame 0 liegen dürfen.

Daraus leite ab, dass eine RIC mod 8 zwingend > 0 sein muss.

Nun haben wir bei uns im Landkreis in der Alarmierung sehrwohl RICs, die Modulo 8 ein Ergebnis von 0 liefern, vergeben. Und das funktioniert auch.

Warum!?

Das sind alles alte Kamellen die meistens für Swissphone Infrastruktur empfohlen werden. Bei aktuellen DA Systeme können in allen Frames RIC ohne Einschränkung genutzt werden .

[rd-lst]

Herzlichen Dank euch beiden!

Das hab jetzt auch ich endlich begriffen :)

Bei überlangen Texten in Systemen mit älteren DAU teilt der Alarmgeber die Mehrfachalarmierung in einzelne Nachrichten auf.

Es handelt sich um Motorola DAUs; das Netz ist Baujahr ca. 2006/2007.
Ob es sich dabei um "alte" DAUs handelt mag ich nicht beurteilen ;)