BOSS: 1-Bit Adressfehler zulassen???

[huhu]

Hallo,

bei der Programmierung der BOSS Melder ist es möglich 1-Bit Adressfehler zuzulassen.
In der Anleitung ist nur davon die Rede, dass der Melder somit ein sichereres Auslösen besitzt.

*Wer hat Erfahrungen damit?
*Was muss ich mir darunter vorstellen? Heißt das, dass wenn die RIC sich um 1 Bit von der programmierten Ric unterscheidet dann löst der BOSS auch aus?
*Kann es so nicht vermehrt zu Fehlauslösungen kommen?
*Ist es empfehlenswert diese Einstellung vorzunehmen?

MkG
huhu

[huhu]

Will niemand was zu sagen?

[frank555]

Hallo....

nun... der Fachmann bin ich nicht, aber ich habe einen ziemlich neuen BOSS920 und die Option 1-BIT Fehler zulassen ist bei mir aktiviert, also ich habe Erfahrung damit und kann Dir sagen, eine Fehlauslösung hatte ich noch nie.

Was dies letztendlich bedeutet, ist -so denke ich- wie Du bereits geschrieben hast. Wieviel letztendlich 1 BIT vom Ganzen ist, weiß ich auch nicht genau, kann aber nicht viel sein, denn sonst würde es tatsächlich vermehrt zu Fehlalarmierungen kommen.


Gruß
Frank

[Christian]

Hallo,

ich muß mal in der Programmieranweisung nachsehen. Ich glaube aber, daß sich das eine Bit nur auf die Funktionsadresse nicht auf die RIC Adresse an sich bezieht. Beispiel:

1-Bit Fehler zugelassen:

Lst sendet RIC 1234567 A
DME empfängt 1234567 B -> Melder löst aus obwohl B eine ganz andere Funktion hat wie A

Wenn der 1-Bit Fehler nicht zugelassen wäre würde der Melder nicht auslösen.

[huhu]

das würde aber wiederum bedeuten, dass der boss immer dann auslöst wenn eine subadresse einer ric einprogrammiert ist. also nur noch nach rics, nicht mehr nach subadressen unterschieden wird.

hab ich also nur 1234567 a programmiert und b c d nicht,

dann geht der boss auch los wenn die b c d ausgelöst werden obwohl ich das nicht will.... blöd

[tm112]

Aus der Programmieranleitung:

"Ist "1-Bit Adressfehler zulassen" aktiviert, werden kleine Fehler in der Meldungsadresse korrigiert. Dies erhöht die Empfangswahrscheinlichkeit."

Die Unteradressen können damit nicht gemeint sein, braucht es doch zur Darstellung von 4 unterschiedlichen Zuständen 2 bit (Bit 20 und 21).

So viel zur Beschreibung.

POCSAG ist dank seines CRC (x10+x9+x8+x6+x5+x3+1; 21 Informationsbits + 10 Bit Redundanz, CRC + Parity Bit) nicht nur ein prüfbarer (vgl. FMS x7+x6+x2+1; 40 Informationsbits + 7 Bit Redundanz, CRC + 1 Schlussbit, frei) sondern ein korrigierbarer Code.
Weiß ich an welcher Stelle sich der Bitfehler befindet, muss dieses nur invertiert werden, da jedes Bit nur entweder "1" oder "0" sein kann.

Ein Frame enthält Adress- und Messagecodewort.

Adresscodewort und Messagecodewort sind prinzipiell ähnlich aufgebaut.

Die Unterschiede:

address codeword:
Bit 1: Flag "0"
Bit 2-19: adress bits
Bit 20-21: function bits (Unteradressen)
Bit 22-31: CRC
Bit 32: even parity bit

message codeword
Bit 1: Flag "1"
Bit 2-21: message bits
Bit 22-31: CRC
Bit 32: even parity bit

Das Ganze hat jedoch seinen Preis:
Während also beim FMS nur 17,5% der Gesamtnachricht (lassen wir mal Vorlauf und Synchronisation weg) dazu verwendet werden, um festzustellen, ob die Übertragung korrekt war, belasten bei POCSAG fast 48% CRC die Übertragung. Dafür können maximal 2 1-Bit-Fehler festgestellt und korrigiert werden. Theoretisch hilft das in Grenzsituationen den Empfang zu verbessern. Die Wahrscheinlichkeit ist jedoch relativ gering, dass sich beim schlechten Empfang nur ein Bit "verbiegt". Fehler, die eine größere Anzahl von Bits betreffen, werden erkannt, jedoch ist eine Korrektur nicht mehr möglich.

Thomas

[frank555]

"Christian," das kann ich mir nicht vorstellen. Ich muss "huhu" Recht geben.
Bei uns in der Wehr sind nämlich die Melder folgendermaßen programmiert, unterteilt nach Tag/Nacht und Samstag/Sonntag:
RIC 123456 = BRAND 3, Unteradresse A = Tag, B = Nacht, C = Samstag, D = Sonntag.

Das würde bedeuten, wenn "Nacht" alarmiert wird, wird auch "Tag" alarmiert, wenn die 1BIT-Fehleradresse-zulassen-Option gesetzt ist, da dies nur 1 Unteradresse daneben liegt. Das kann nicht sein.

1 Bit bedeutet NICHT 1 "Unteradresse"



Ich stelle mir das so vor:
Allerdings weiß ich nicht, wieviel Bit/Byte es bei einer Alarmierun gibt. Nehmen wir an (um es kurz zu machen) , die digitale Alarmierung erfolgt mit 8 Bit, also 8 mal Einsen und Nullen. Es wird Ric xxxxxxx-b alarmiert, welcher in Bits entspricht: z.B. 10110010. Der Melder empfängt 10010010, also 1 Bit Unterschied, und piepst, da er auf 10110010 programmiert ist. Der Unterschied kam durch evtl. irgendwelche Übertragungsschwierigkeiten zustande. Hört sich jetzt kompliziert an, aber so könnte es sein (Wo sind denn in diesem Forum die Fachmänner??)
Also 1 Bit müsste daher nur ein Bruchteil eines Rics/Unteradresse sein.

[Christian]

Hallo...

also ich glaube ich habe micht etwas unmißverständlich ausgedrückt.

Der Melder geht nicht wenn in der Adresse (also der Zahl) ein Fehler ist, erkennt er bei richtiger RIC ein Fehler im Funktionsbit würde er auslösen. Würde er den richtigen RIC erkennen aber merken das im Funktionsbit ein Fehler ist würde er auslösen. Beispiel RIC 1234567 A ist programmiert, B C D nicht. Melder empfängt korrekt 1234567 C > Melder löst nicht aus. Melder empfängt fehlerhaft 1234567 D > Melder löst aus. Ob er die RIC korrekt empfangen hat merkt er ja CRC. Würde er jetzt 1234566 würde er die Alarmierung verwerfen.

Melder empfängt RIC + Sub + CRC
Melder prüft RIC + Sub mittels CRC
wenn RIC + Sub = ok > Alarm
wenn RIC ok + Sub nicht ok > Alarm
wenn RIC nicht ok > dann Sub egal > kein Alarm

Verstanden ? Wie gesacht ich weiß nicht ob's 100 % so richtig ist, ich werde Montag mal ins Handbuch sehen !

[frank555]

Vielleicht doch eher missverständlich? Ich weiß es auch nicht. Ich habe nur die eine Vermutung (wie beschrieben) . Aber wieviel ist denn "1 BIT" vom Ganzen? Bsp: RIC 342386a und 342386b. Wieviel BIT Unterschied sind das? 1 (sicher nicht) oder 3000 oder 10000? Keine Ahnung, würde mich aber auch interessieren.....

Mal was anderes:
Von Swio weiß ich, dass es eine 128-Bit Verschlüsselung gibt. Hat das auch etwas hiermit zu tun?

[Antennenfan]

Vorweg muss ich auch zugeben, dass ich nicht genau weiß, was das mit dem fehlerhaften Adressbit aufsich hat.

Pocsag besteht aus ein oder mehreren Reihen, welche immer mit einem 32-Bit langem Synchronwort beginnen und danach 8 Rahmen mit 2x32-Bit aufgefüllt sind. Das bedeutet, eine Reihe besteht aus 32Bit+8x(2x32Bit)=544 Bit.

Eine Adressecodewort sitz in einem Teil der 8 Rahmen und ist 32 Bit lang. Voraussetzung, dass ein Adresswort erkannt wird ist, dass es mit "0" beginnt (steckt hier schon der Fehler, dann ist eine Erkennung sehr schwer). Danach folgen 18 Adressbits und zwei Funktionsbits (für Fkt. A..D). Darauf folgen noch 10 Fehlererkennunsbits, welche aus den ersten 21 Bits durch eine Rechnung entstehen (ziemlich kompliziert und aufwändig) und zum Schluss ein Paritätsbit.
Entstehen also die 10 Fehlererkennungsbits durch die Fehlerrechnung aus den ersten 21 Bits, dann ist alles in Ordnung. Stimmt das nicht überein, dann kann eine Fehlerkorrektur der Adressbits vorgenommen werden (dafür bin ich aber auch überfragt wie das funktioniert). Ich könnte mir aber vorstellen, dass der DME in der Lage ist, durch die Fehlerrechnung wenigstens ein fehlerhaftes Bit zu erkennen und demzufolge zu invertieren.

Noch zur Frage, wieviel denn 1 fehlerhaftes Bit ist: 1/544=0,001838 (0,18%).

[Christian]

Hallo,

es ist exakt so wie Steffen112 erklärt hat. Ich habe heute mit dem Softwareentwickler von Swissphone gesprochen. Leider ist das in der neuen
Programmieranleitung nicht so doll beschrieben.

Der Melder kann ein Fehlerhaftes Bit in der Adresse + Sub erkennen, es notfalls umkehren (0 -> 1 oder 1 -> 0) und somit die Auslösesicherheit erhöhen. Die Einstellung ist in etwa (auch wenn technisch völling anders umgesetzt) mit der Auswerteempfindlichkeit der analogen Melder (A B C) zu vergleichen.