multimon (der Vorgänger des monitord) auf Raspberry Pi

[JHC]

Hallo Joki,

die RICs werden von BOSWatch aussortiert, da sie nicht 7-stellig sind.
https://de.wikipedia.org/wiki/Radio_Identification_Code

Stimmen die ausgegebenen RICs bei Euch? 0123456 -> 123456?

Ich werde mal bei multimon-ng gucken, ob führende Nullen unterdrückt werden, dann hätten wir da ein ToDo...

Grüße,
Jens

PS: Ich würde Dir empfehlen Deine Beiträge zu editieren.
Das Veröffentlichen des Logs mit echten RICs/Adressen/Meldungen ist nicht erlaubt.

[Schrolli]

Na dann melde ich mich auch mal kurz aus dem Urlaub ;-)

Wegen den 6 stelligen RICs müsste eben mal geklärt werden, ob das nur führende 0en Betrifft, oder generell 6stellig geht. Da kann man das Vadlidation RegEX ja recht schnell umstricken...

Und zum Web Frontend:
Das wurde mal angefangen zum testen, da jetzt aber derzeit große Änderungen an BOSWatch selbst laufen, lag das erst mal auf Eis. Eine Pocsag Anzeige wurde bisher noch gar nicht im Frontend implementiert.
Aber das wird dann wohl die nächste Baustelle sein, wenn die größten Bugs aus dem Aktuellen Dev Stand raus sind.

Grüße aus Prag - Basti

[Smith]

Hey,

Wegen den 6 stelligen RICs müsste eben mal geklärt werden, ob das nur führende 0en Betrifft, oder generell 6stellig geht. Da kann man das Vadlidation RegEX ja recht schnell umstricken...

RICs müssen definitv 7-Stellig sein, wie JHC schon schrieb. Das einzige was auftreten kann, sind führende Nullen.
Die ersten 3 Stellen sind zur Identifizierung des LK in der BRD, soweit ich weiß.
Also muss der RegEx dementsprechend angepasst werden. Ich hab da aber ehrlich gesagt nicht dran gedacht.... :)

@JHC:
Es sieht so aus als wäre es auch so das Multimon die führende Null rauswirft. Es muss also auch die Plausibilitätskontrolle (ric==7) angepasst werden oder es schreibt wer einen Pull-Req. an Elias :)

Grüße aus Prag - Basti

Grüße aus den Niederlanden! :-)

[JHC]

Moin Smith,

Es sieht so aus als wäre es auch so das Multimon die führende Null rauswirft. Es muss also auch die Plausibilitätskontrolle (ric==7) angepasst werden oder es schreibt wer einen Pull-Req. an Elias

Ich habe im Quellcode von multimon-ng keinen Abschnitt gefunden, der dafür sorgt, dass eine führende Null ausgegeben wird. Ich habe nur Längenprüfungen 1-7 gesehen und die Ausgabeformatierung auf 7 Zeichen Platz, rechtsbündig. Das passt soweit zum geposteten Bild mit " 123456". Entweder Dekodierungsfehler oder der RIC war wirklich 0123456 und multimon-ng lässt irgendwo in der Typkonventierng die null fallen.
Ich habe es mir mal erlaubt Elias eine eMail zu schreiben, mal schauen ob er darauf reagiert.

Grüße
Jens

PS: Leider habe ich keine offiziellen RIC-Struktur-Dokumente gefunden, die das vorgeben...

[Smith]

Ich habe im Quellcode von multimon-ng keinen Abschnitt gefunden, der dafür sorgt, dass eine führende Null ausgegeben wird. Ich habe nur Längenprüfungen 1-7 gesehen und die Ausgabeformatierung auf 7 Zeichen Platz, rechtsbündig. Das passt soweit zum geposteten Bild mit " 123456". Entweder Dekodierungsfehler oder der RIC war wirklich 0123456 und multimon-ng lässt irgendwo in der Typkonventierng die null fallen.

Ich gehe davon aus, das dies der Fall ist. Ich habe mir zwar den Quelltext nicht angeschaut, aber es wird so sein.

Die RIC wird dann von boswatch aktuell nicht mehr aufgefüllt. Ich hatte das damals so geschrieben.

.replace(" ", "").zfill(7)

Ich denke damit sollte der Fehler dann behoben sein.
Mit der Filterung der Range, welche dann nach diesem Schritt ausgeführt wird, sollte dann auch Fehldekodierungen nicht mehr vorhanden sein.
Eingang -> RIC auf 7 Stellen -> RIC in Range? -> weitere Ausführung.

Ich habe es mir mal erlaubt Elias eine eMail zu schreiben, mal schauen ob er darauf reagiert.

Bin gespannt, was er dazu sagt. :-)

PS: Leider habe ich keine offiziellen RIC-Struktur-Dokumente gefunden, die das vorgeben...

Naja, offizielle Doku kenne ich auch nicht. Aber schonmal einen DME mit 6 Stellen versucht zu programmieren? Lässt das Programm nicht zu :-)

[JHC]

Hi Smith,

Die RIC wird dann von boswatch aktuell nicht mehr aufgefüllt. Ich hatte das damals so geschrieben.

.replace(" ", "").zfill(7)

Ich denke damit sollte der Fehler dann behoben sein.

Ich sehe das nicht als "Fehler" in BOSWatch, wenn RICs eigentlich 7-Stellig sind sollte. Eigentlich dürfte BOSWatch die RIC nur von links beginnend auffüllen, ein Leerzeichen rechts von der Zahl oder zwischen den Ziffern wäre ein echter Fehler.

Naja, offizielle Doku kenne ich auch nicht. Aber schonmal einen DME mit 6 Stellen versucht zu programmieren? Lässt das Programm nicht zu :-)

Da wir hier nur RICs > 1xxxxxxx haben, hat sich mir das Problem mit 0xxxxxx noch nicht gestellt.

Grüße
Jens

[Smith]

Ich denke du weißt was ich meine.
das zfill ist schon der passende Weg um eine von multimon nicht übergebene führende Null wieder hinzu zufügen.
Damit sollten wir auch für Landkreise in denen es mit 00 beginnt gewapnet sein. Auch wenn es nur 9 sein können ;)
Ich wollte auch nur darauf hinaus, das ich damals in meinem Script und in der ersten Phase von BosWatch aus diesem Grund das zfill eingesetzt habe.

Und damit wäre dann das "Problem", welches kein Fehler ist, erledigt :-)