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

[Smith]

@Schrolli:
du gehst ja einen etwas anderen weg als ich es am Anfang getan habe. Hast du das Script auch auf einem Pi laufen? ich habe eine CPU Auslastung unter htop bei 100%. Das Python Script schlägt da mit 65% zubuche... bei Übertaktung auf 1000Mhz...

zum POCSAG:
Ich habe das Script umgeschrieben, bekomme aber noch keine Auswertung hin.
Vermutlich aufgrund der Systemauslastung. Der Pocsag demod brauch halt mehr. FMS und ZVEI frisst halt nix im decode...
Ich werde später mal nach den Pipes schauen. Ich habe irgendwie das Gefühl das da was nicht passt... Jetzt ist aber auch erstmal die Luft raus :-) zzZZzz

[Schrolli]

Hö? Also hier auf nem Raspi der auf 800 oder 900 MHz getaktet ist...
http://www.bilder-upload.eu/upload/f...1429341615.png
Also bei mir sieht die Auslastung definitiv anders aus ^^

Die Last vom Python Script ist so gering, das es nicht mal in der Auflistung auftaucht... und JA es läuft ;-)

[McBo]

@Smith,

Dadurch dass ich mit tee den rtl_fm Stream direkt in den multimon-ng gebe,
läuft die Auswertung sehr stabil.
Nur der Audio-Teil (Verwendung für Memo-Record, Icecast, lokaler Lautsprecher), den ich in das Loop-Device einspeise,
der muß über den Watchdog nach besagter Zeit neu gestartet werden.
Das ist aber nur ein Schönheitsfehler.

Ich habe momentan 2 Testsysteme im Dauerlauf (schon 4 Monate).
- Banana Pi Pro
- RaspBerry Pi 2 mit Touch Display

Im Anhang meine htops (4-Kerne = RaspBerry Pi2, 2-Kerne = Banana Pi Pro).

Die 2 Systeme langweilen sich :-)
Auf dem Banana Pi laufen 2 Kanäle gleichzeitig (2x rtl_fm und multimon-ng).
Auf dem RaspBerry Pi2 läuft noch ein Display-Script, welches mir eine schöne Ausgabe macht. :-)
Dieses Script zieht die größte Last.
Außerdem kommuniziere ich zwischen den Scripten mit einem TCP-IP Socket.


Gruß

Marcel

[Smith]

ich hab es mir schon gedacht.... :-)
Dann mal debugen...

und Marcel, ein Abbruch des Script nach immer der gleichen Zeit spricht von Überlauf durch eines der Programme oder durch die tee. Das wollte ich damit sagen. Deine Systeme sind performant genug, das wusste ich auch vorher schon ;-)
Bist mit dem Pi2 zufrieden?

[McBo]

Dann mal debugen...

Nur wie? Mir fehlt der Ansatz.
Ich kann auf die Sekunde genau berechnen, wann der Stream abreißt.
Unter htop sieht man aber keinen CPU-Last oder Mem-Last Anstieg.
Man sieht nur wie sich die Dienste beenden und durch meinen Watchdog
wieder neu gestartet werden.

Bist mit dem Pi2 zufrieden?

Wenn Du kein GBit-Lan oder S-ATA benötigst,
ist der Pi2 echt Top.
Habe schon einige Projekte damit umgesetzt.
Die Community ist einfach beim Pi am besten.

Gruß

Marcel

[Smith]

Das debuggen war auf mich bezogen. :)

Ich melde mich gleich mal bei dir. Ich denke es hat bei dir mit dem Audioplay zu tun.
Im Zweifel, dein Watchdog zeigt dir keine einzelenen Prozesse an oder?
Das wäre eine Möglichkeit. Denn es wird irgendwas zuerst gehen.

[Smith]

Schrolli, irgendwas passt hier noch nicht.
Allerdings hab ich gerade keine Ahnung wie man das abfangen kann...
Außer ins finally noch eine if-Schleife zu setzten welche checkt ob überhaupt einer der Prozesse gestartet wurde und dann erst versucht diese zu beenden.

root@raspoc1:/boswatch# ./boswatch.py
usage: boswatch.py [-h] -f FREQ [-d DEVICE] [-e ERROR] -a
                   {FMS,ZVEI,POC512,POC1200,POC2400}
                   [{FMS,ZVEI,POC512,POC1200,POC2400} ...] [-s SQUELCH] [-v]
                   [-q]
boswatch.py: error: argument -f/--freq is required
Traceback (most recent call last):
  File "./boswatch.py", line 321, in 
    rtl_fm.terminate()
NameError: name 'rtl_fm' is not defined

Edit:
Auslastung:
Ein frisch installierter Raspi B mit unverändertem per git und install.sh installiertem boswatch:
99.6% boswatch.py...
die anderen Prozesse sehe ich gar nicht erst unter top und htop...

[Smith]

Zum Thema Auslastung, das hat sich erledigt.
Ich habe gerade noch nen apt-get update etc gemacht. Dabei wurde auch python gefixt.
Erledigt.

[Schrolli]

Das mit dem beenden fixe ich später noch schnell.. Danke für den Hinweis

Zum Thema Auslastung, das hat sich erledigt.
Ich habe gerade noch nen apt-get update etc gemacht. Dabei wurde auch python gefixt.
Erledigt.

;-) - Wobei ja eigentlich in der install.sh eine update als erstes gemacht wird???

[McBo]

@Smith,

kann es sein das rtl_fm nach besagter Zeit (67185 Sekunden),
den Stream unterbricht?
Bei direkter Versorgung des multimon-ng stört das sicher nicht.
Aber bei einer Einspeisung über Sound Loop-Device bricht sicher die Pipe.

Gruß

Marcel

[Smith]

Das mit dem beenden fixe ich später noch schnell.. Danke für den Hinweis


;-) - Wobei ja eigentlich in der install.sh eine update als erstes gemacht wird???

dann funktioniert da aber was nicht richtig? :)
ändere mal den Befehl
apt-get update > ~/bos/install/setup_log.txt 2>&1
in
apt-get update -y > ~/bos/install/setup_log.txt 2>&1
Nur hierdurch wird keine Benutzerinteraktion gefordert.

[Smith]

@Smith,

kann es sein das rtl_fm nach besagter Zeit (67185 Sekunden),
den Stream unterbricht?
Bei direkter Versorgung des multimon-ng stört das sicher nicht.
Aber bei einer Einspeisung über Sound Loop-Device bricht sicher die Pipe.

Gruß

Marcel

rtl_fm wird da nichts unterbrechen. Ich kann es mir nicht vorstellen, denn dann wäre auch bei uns nach 67185 Sekunden ende da die Pipe sich auflösen würde.

[McBo]

rtl_fm wird da nichts unterbrechen. Ich kann es mir nicht vorstellen, denn dann wäre auch bei uns nach 67185 Sekunden ende da die Pipe sich auflösen würde.

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.


Gruß

Marcel

[Schrolli]

au Mist, das -y hab ich total verschwitzt... oke mein Fehler ^^

[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