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

**McBo** · 26.04.2015, 21:03

Zitat von McBo

OK, neuer Versuchsaufbau :-)
rtl_fm ist jetzt mal bei mir raus :-)
Habe über "arecord -r 22050 -D plughw:1,0 -f S16_LE -t wav"
den Soundkarten-Eingang direkt auf meine tee Pipe / Loop-Device gegeben.
Als Quelle verwende ich einen analogen Funkempfänger.
Mal sehen was hier nach 67185 Sekunden passiert.

So, habe jetzt lange getestet - gleiches Problem,
nach 67185 Sekunden bricht die Pipe.
Es liegt also an dem Sound Loop Device.

Jetzt habe ich noch etwas anderes ausprobiert.
Ich habe jetzt auf meinem RaspBerry Pi2
2x rtl_fm und 2x monitord (auf 2 verschiedenen Kanälen)
und zusätzlich noch monitord,
gleichzeitig laufen.

Läuft perfekt !!!!

Dabei ist mir aufgefallen, das monitord mit FMS besser klar kommt.
mit multimon-ng werden z.B.: Fahrzeugkenner "3A44" nicht ausgewertet.

Hat jemand dafür eine Lösung?

Gruß

Marcel

**Smith** · 27.04.2015, 01:12

Warum? keine Ahnung.
Ich bin aber bei FMS auch raus. Ich habe keine Möglichkeit mehr das zu testen.
Wir sind hier komplett umgestellt auf TETRA. Und die 2-4 KTW FMS´sen zu wenig um da eine genaue Aussage zuzulassen.

Marcel, haut der diesen 65718 Sekunden Fehler auf allen Geräten raus?
Wenn ja, lass deinen Watchdog einfach kurz vor Ablauf das Programm reseten.
Damit umgehst du zumindest die Fehler.
Und die Wahrscheinlichkeit das in der Zeit ein Alarm eingeht der verarbeitet werden soll/muss ist wohl eher gering.

@Schrolli:
Wann kommen denn mal neue Ideen von dir? :-D :-P
Ich habe dir gerade einen Pull zum POC1200 und POC512 gesetzt.
Zieh den mal in den Masterbranch.

@all:
Ich werde die Tage mal einen kleinen Desktopclienten fertig machen der per Socket die Alarme auf dem PC anzeigt. Erstmal nix besonderes.
Wer es testen will, kann ja mal hier schreien. Vielleicht schmeiße ich es es dann auch ins Git.

**Smith** · 27.04.2015, 15:48

- POCSAG Rangefilter im forke eingebaut.
In der config ist ein Start und ein Ende für den POCSAG-Bereich anzugeben.
Die Alarmierungen innerhalb der Range werden in die Datenbank oder per HTTP ausgeführt.
Alle anderen werden in der Console angezeigt.

**McBo** · 27.04.2015, 17:46

Zitat von Smith

Warum? keine Ahnung.
Ich bin aber bei FMS auch raus.

Schade, kannst Du vielleicht mal über den Quellcode von multimon-ng
schauen?
Den Fehler mit den Umlauten hast Du doch auch gefunden. :-)

Du hast keine Lust? :-)

Ich habe keine Möglichkeit mehr das zu testen.

Ich habe mir dafür einen Versuchsaufbau gemacht.
Über eine USB-Soundkarte und Line-IN,
gebe ich das von meinem PC-Tool erzeugte FMS-Signal auf den RaspBerry Pi.
multimon-ng und monitord gleichzeitig.

Das geht auch mit ZVEI und POCSAG.

Dabei habe ich festgestellt, das multimon-ng aus einer Fahrzeugkennung "3A44"
"FZG 31044". (monitord: kfz = "3A44")
Er macht also aus der "10" eine "10" und kein "A".

Kannst Du mal im Code nachschauen?

Marcel, haut der diesen 65718 Sekunden Fehler auf allen Geräten raus?
Wenn ja, lass deinen Watchdog einfach kurz vor Ablauf das Programm reseten.
Damit umgehst du zumindest die Fehler.
Und die Wahrscheinlichkeit das in der Zeit ein Alarm eingeht der verarbeitet werden soll/muss ist wohl eher gering.

Ja, haut alles hinter der Pipe weg.
Mit Reseten meinst Du Neustart der Pipe-Einspeisung?

Gruß

Marcel

**McBo** · 27.04.2015, 19:13

So, habe das KFZ-Kennungs-Problem, jetzt erst einmal im Python Script
gerade gebogen :-)

Da fällt mir noch ein Fehler auf :-(

multimon-ng erkennt die vom Fahrzeug gesendeten Statis 4-7,
mit der falschen Richtung ( 1=LST->FZG ).
Bei den anderen Statis passt es ( 0=FZG->LST ).

monitord macht es auch richtig !!!

Gruß

Marcel

**Smith** · 28.04.2015, 00:16

Also wenn er immer aus der 10 ein A macht, dann ist das mit Sicherheit im Quellcode zu finden. Da kann ich die Tage, wenn ich dran denke, mal ran gehen.
Testen werde ich das dann einfach auf einer deiner Kisten ;-P
Wenn du willst, ruf am Freitag einfach mal an. Ich habe Tagesdienst.

und ja, ich meine einfach ein Reset des Programm. Da er alles hinter der Pipe weg haut gehe ich einfach von einem Speicherüberlauf aus. Damit meine ich nicht das er auch physich voll ist sondern er in den Registern dann irgendwann am Ende ist. Oder was auch immer.
Das wird eher ein Thema für die snd_aloop aplay Foren :-)

Ansonsten läuft der multimon stabiler als monitor wie ich finde.
Der Fehler mit den Richtungen lässt sich reproduzieren?
Dann kann ich das im Zweifel auch ändern. Du musst dann nur für eine git clone den Fork aus meinem Repo nehmen. Elias pushed anscheindend keine Änderungen mehr.... :(

**McBo** · 28.04.2015, 00:23

OK,

habe es erst einmal so im Py Script gelöst:

Code:

        # FMS - Abfrage
        elif line.startswith('FMS'):
           
            utc_stamp = int(time.time())		
            bos = line[19]
            land = line[36]
            kreis= line[65:67]
                     
            # In multimon-ng ist ein Fehler bei der KFZ-Kennung. Fahrzeuge mit alphanumerischer Kennung werden 5-stellig uebermittelt. 
            # Pruefen ob KFZ-Kennung 4 oder 5 stellig
            
            if str(line[76:77]).isdigit() is True:
                #5-stellig erkannt
                k1 = line[72:73]
                k2 = line[73:75]
                k3 = line[75:76]
                k4 = line[76:77]
                
                k2 = chr((int(k2)-9)+64)
                fhzg = str(k1) + str(k2) + str(k3) + str(k4)
                status = line[85]
                richtung = line[102]
                
            else:
                #4-stellig erkannt
                fhzg = line[72:76]
                status = line[84]
                richtung = line[101]
   
            status = status.replace("\n","")
            status = status.replace("\r","")

            richtung = richtung.replace("\n","")
            richtung = richtung.replace("\r","")
            
            address = (bos+''+ land+''+ kreis+''+ fhzg)8)

Gruß

Marcel

**Schrolli** · 28.04.2015, 10:58

@Smith
Danke habe deine Änderungen in den Master gemerged und auch gleich den Dev Branch geupdatet, damit der auf dem selben Stand ist.

Komme zur zeit leider nicht wirklich oft an den Rechner, hoff das ändert sich bald wieder etwas...

Kann die poc_id nur Zahlen enthalten und muss 7 Stellen lang sein? oder Können auch Buchstaben vorkommen?

Gruß

**McBo** · 28.04.2015, 11:57

Zitat von Smith

Also wenn er immer aus der 10 ein A macht, dann ist das mit Sicherheit im Quellcode zu finden.

multimon-ng kennt keine Buchstaben.

A ist bei multimon-ng = 10
B = 11
C = 12
D = 13
........

Du musst dann nur für eine git clone den Fork aus meinem Repo nehmen. Elias pushed anscheindend keine Änderungen mehr.... :(

Da benötige ich aber Zugangsdaten von Dir?

**Smith** · 29.04.2015, 08:22

Ahh okay. Das hat sich Elias dann anscheinend bei FMS32 abgeschaut. Ich weiß ehrlich gesagt gar nicht wie es die TR vorsieht.

**Jannis** · 12.05.2015, 20:24

Zitat von Smith

Also wenn er immer aus der 10 ein A macht, dann ist das mit Sicherheit im Quellcode zu finden. Da kann ich die Tage, wenn ich dran denke, mal ran gehen.

So, als der, der den FMS-Dekoder im multimon implementiert hat, hab' ich hier auch mal wieder vorbeigeschaut. Da in meiner Gegend nur "dezimale" Fahrzeugkenner habe, ist das beim Testen nicht weiter aufgefallen, aber das Problem liegt hier:
https://github.com/EliasOenal/multim...0058ac3885dR88

Im Prinzip müsste man wohl nur die %1d durch %1x ersetzen und gut is. Elias nimmt bestimmt noch Pull-requests an, wenn man ausreichend Begründung dazuschreibt. Ansonsten halt im eigenen Branch weiterpflegen.

Was war denn mit den Umlauten konkret das Problem? Die kommen bei mit wunderbar UTF-8 kodiert raus und sollten dementsprechend weiterverarbeitet werden.

VG, Jannis

**Jannis** · 12.05.2015, 21:01

Zitat von McBo

multimon-ng erkennt die vom Fahrzeug gesendeten Statis 4-7,
mit der falschen Richtung ( 1=LST->FZG ).
Bei den anderen Statis passt es ( 0=FZG->LST )

Das Problem verstehe ich nicht ganz. Kannst du dafür Beispiele nennen? Ich hab' mich an die PDF-Dokumente gehalten, ich kann die URLs später nochmal raussuchen.
*UPDATE*: http://www.lfs-bw.de/Fachthemen/Digi.../TRBOS-FMS.pdf ab Seite 54 der Datei

Und wg. dem crash nach gewisser Zeit: Schau mal in die Kernel-Nachrichten ("dmesg"), ob du da was über den crash zu lesen ist.

**McBo** · 13.05.2015, 00:59

Zitat von Jannis

Das Problem verstehe ich nicht ganz. Kannst du dafür Beispiele nennen? Ich hab' mich an die PDF-Dokumente gehalten, ich kann die URLs später nochmal raussuchen.
*UPDATE*: http://www.lfs-bw.de/Fachthemen/Digi.../TRBOS-FMS.pdf ab Seite 54 der Datei

Ich hatte in meinem Python Script, nur Statis mit der Richtung 0=FZG->LST
ausgewertet und war verwundert, das ich nicht alle Statis dieser Richtung bekommen habe.

Darauf hin habe ich mir das Treiben mal auf der Konsole angesehen.
multimon-ng und monitord parallel.
(Ich verwende die Standard Version aus dem Git https://github.com/EliasOenal/multimon-ng)

multimon-ng erkennt die vom Fahrzeug gesendeten Statis 4-7,
mit der falschen Richtung ( 1=LST->FZG ).
Bei den anderen Statis passt es ( 0=FZG->LST ).

monitord macht es richtig.

Ich habe das dann mit einem Windows FMS-Geber-Tool ausprobiert
und hatte bei den Statis 4-7, die falsche Richtung.

Gruß

Marcel

**Smith** · 13.05.2015, 16:03

Hallo Jannis,

Zum UmlautProblem:
Es kam tatsächlich kein UTF-8 raus. Gut möglich das auf dem Pi der Satz fehlte. Dadurch war es nicht möglich zu zählen und bestimme Bereiche zu verarbeiten.
Ich hatte Elias einen Pull gesetzt in welchem einfach nur die Umlaute von Ü auf U etc. Geändert wurde.
Dadurch lief es.
der Pull wurde allerdings nicht gemerged.

VG
Rene

PS.: vom Handy geschrieben. Verzeiht die Fehler ..

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

Themen-Optionen

Anzeige

Hybrid-Darstellung

Aktive Benutzer

Aktive Benutzer

Berechtigungen