Wird am Projekt "monitord" noch weiter entwickelt?

[McBo]

Hallo,

um das Projekt "monitord" ist es ja ziemlich ruhig geworden.
Wird daran eigentlich noch weiter entwickelt?

Ich hätte da einen Wunsch:

Wäre es möglich, eine direkte Unterstützung,
für DVB-T Sticks mit "RTL2832U" (SDR-Projekt) einzubauen?


Gruß

Marcel

[limberu]

Moin Zusammen...

Dem will ich mich hier auch anschliessen!

[funkwart]

Das wäre natürlich eine tolle Sache, aber ich habe auch feststellen müssen, dass die Qualität empfangener Signale mit DVB-T Sticks ziemlich zu wünschen übrig lässt. Selbst mit guten Antennen, die ja das A und O sind, ist die Qualität eher bescheiden.
Insofern ist es eben auch eine Frage, ob der Aufwand der Implementierung durch die Ergebnisse gerechtfertigt wird.

Gruß,
Funkwart

[limberu]

Kommt darauf an, wie man es macht...

Mir wäre schon recht, wenn ich unter Linux nicht über ne Sounkarte/Line-In gehen muss.
Vielleicht habe ich bisher auch einfach noch nicht das passende gefunden oder bin zu Microsoftlastig.

Mein Ziel ist folgendes:
Nutzung eines DVB-T Sticks an einem Raspberry Pi um die POCSAG-Meldungen unserer Melder mitzuschneiden und diese an FirEmergency und parallel an ein MySQL zu übergeben.

Die RTL-SDR läuft und ich kann mittels eines Lautsprechers bzw. Kofphörers auch schon die Telegramme anhören, die der Stick empfängt.
Hierzu habe ich das RTL-SDR nach folgender Anleitung eingerichtet:
http://www.raspberrypi.org/phpBB3/vi...45142&p=358012
Abhören der Sounddaten mache ich mittels
rtl_fm -f 153.350M | aplay -r 24k -f S16_LE -t raw -c 1

Ich bräuchte nun sowas wie VB Audio Cable auf Windows, um einen virtuellen Line-In zu bekommen, den ich mit monitord anzapfen kann. Oder aber die Möglichkeit, die RAW-Daten (wie in der Anleitung beschrieben für multimonNG) an monitord zu übergeben.

Gibt es sowas? Hat hierzu einer eine Idee??

PS:
Zur Qualität:
Mittels rtl_tcp -a auf dem RPi und einem ssdrsharp, VB Audio Cable und POC32 auf einem Windowsrechner, der den RPi anzapft, bekomme ich Daten geliefert.

[buster3.0]

Hallo zusammen,

ich will mich hier auch kurz melden. Mir ist ebenfalls die Idee gekommen rtl_sdr als Quelle für die Funksignale zu benutzen. Eigentlich hab ich mir vorgenommen monitord entsprechend anzupassen, nur leider bin ich nur bis zum durchschauen der Sourcen gekommen und dann hat sich das ganze verlaufen.

Eventuell finde ich die nächsten Monate Zeit dazu oder kann jemanden der schon weiter ist mit der Implementierung helfen.

Schöne Grüße

Thomas

[ToffiFee]

Mahlzeit!
Ohne da jetzt in der Tiefe recherchiert zu haben wollte ich nur mal eine Idee einwerfen:
Habt ihr schonmal Jack ausprobiert? Dieser alternative Soundserver arbeitet genau nach dem Prinzip der "softwaremäßigen Verkabelung". Allerdings weiß ich nicht ob monitord den unterstützt.

Zum anderen Thema:
Ich finde die Auswertung mit dem RTL-SDR Stick besser als mit meinem Uniden Scanner und Diskriminatorausgang. Und zwar benutze ich die mitgelieferte(!) DVB-T Antenne. Klingt total bescheuert und glaubt mir ich war ebenfalls total perplex, aber die Auswertung ist der Hammer!
(Wobei man dazusagen muss dass die Frequenz etwas im Off liegt, da muss man etwas probieren bis man die richtige gefunden hat).

Lieben Gruß,
Bene

[FlMi-14]

Hallo!

Klar kann man den MonitorD auf mit RTL_FM verwenden. Ich teste dies gerade mit diversen USB-Sticks auf Debian Wheezy (32 und 64bit) - die besten Ergebnisse habe ich mit einem Cinergy TStick RC erzeilt.

Um MonitorD mit RTL_FM zu verwenden wie folgt vorgehen:
1. modprobe snd_aloop - damit wird eine virtuelle Audio-Verbindung bereitgestellt
2. rtl_fm -f XXX.XXXM -M fm -s 22050 -p 37 -E dc -F 0 | aplay -t raw -r 22050 -f S16_LE -c 1 -D hw:1,0,0 - Ausgabe des Audio-Streams von rtl_fm auf virtueller Verbindung
3. MonitorD starten - hier ist in der monitord.xml bei der Soundkarte plughw:1,1,0 einzutragen

[McBo]

Hast Du das auf einer X86 Platform laufen oder auch auf einem RaspberryPi?


Sent from my iPhone using Tapatalk

[FlMi-14]

Das läuft im Dauertest auf einer x86-Plattform (Debian-Linux), kurz getestet habe ich das aber auch mit ARM (RaspberryPi mit Raspbian). Die ARM-Plattform kann aber auch nach dem gleichen Schema dekodieren (ist auch getestet), kommt jedoch wegen der größe der datenbank für uns nicht mehr in Frage ... 512MB sind halt etwas zu wenig ;-)

[McBo]

Ich habe aber mit dem RaspberryPi und dem CubieTruck, bei rtl_fm Aussetzer und Latenzprobleme.

Was meinst Du mit Größe der Datenbank 512 MB zu wenig?
Die kann doch größer sein, wenn die SD-Karte größer ist.
Oder meinst Du die langsame Zugriffszeit?
Dann nimm ein CubieTruck Board.


Sent from my iPhone using Tapatalk

[FlMi-14]

Das bezog sich eher auf die Zugriffszeit, vor allem bei der "Suche" nach Adressen im Alarmtext, das braucht mindestens eine Atom-CPU. In der Datenbank sind ca. 95.000 Adressen enthalten die über eine RegEx-Suche dann die Geokoordinaten des Einsatzortes auf einer Karte darstellen können - und das schafft die kleine ARM-CPU mit 512MB dann einfach nicht bzw. nicht schnell genug.

Aussetzer und Latenzprobleme habe ich bis jetzt nicht feststellen können, ich kann das aber gerne nochmal probieren da ich derzeit für ein Alarmdisplay eh einige Tests durchführen muß.

[McBo]

OK, Danke.
Ich werde auch noch einmal testen.

Andere Frage: Wie kann ich den Audio-Stream von rtl_fm auf mehre Programme verteilen?

Ich habe momentan einen Alarmserver auf x386 Basis, und 2 Soundkarten, mit Debian und dem alten monitor 1.81 laufen.

Der monitor 1.81 wertet die 5Tonfolgen aus und nimmt bei Bedarf Memofiles auf.
Zusätzlich kann ich noch über Icecast den Livestream anhören.

Geht das mit rtl_fm auch?



Sent from my iPhone using Tapatalk

[FlMi-14]

Mit der Verteilung hast Du mich jetzt erwischt ;-) Da habe ich (noch) keinen Plan von ... Theoretisch sollte das aber genauso wie in Deinem schon bestehendem System funktionieren. Das rtl_fm / aplay-Konstrukt ersetzt quasi den Scanner und die Soundkarte (eingangsseitig). Wenn Du jetzt einen Soundserver (z.B. JACK) auf den Ausgang der virtuellen Soundkarte (snd_aloop) legst, dann sollte das mitschneiden und mithören wie gehabt funktionieren.

Ansonsten nochmal grob zum funktionellen Aufbau:
rtl_fm in Verbindung mit dem DVB-T Stick bildet quasi den Funkscanner ab. Als Ausgang bekommst Du ein Audio-Signal. Das wir über eine Pipe (also über stdout bzw. stdin) an aplay weitergeleitet und von dort auf die virtuelle Soundkarte ausgegeben - das macht der letzte Parameter -D hw:1,0,0. Damit hast Du dann ein Audiosignal auf einem virtuellen LineIn wie vom Funkscanner. Das kannst Du nun wiederrum auf hw:1,1,0 (virtuelles LineOut) wieder abgreifen und beliebig weiterverarbeiten.