Druckbare Version
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
Moin Zusammen...
Dem will ich mich hier auch anschliessen!
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
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 <ip> auf dem RPi und einem ssdrsharp, VB Audio Cable und POC32 auf einem Windowsrechner, der den RPi anzapft, bekomme ich Daten geliefert.
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
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
Hallo Bene,
wie hast du das mit dem Stick gelöst? (ext. Soundkarte)?
Und was wertest du mit monitord aus (FMS|ZVEI|POCSAG)?
Mahlzeit,
also "gelöst" habe ich mit dem Stick noch gar nichts, ich spiele da derzeit eher ein wenig mit herum. Ich habe auch keinen Pi, aber nutze ausschließlich Linux (Debian), weshalb sich das nicht großartig unterscheiden sollte. Eine Soundkarte ist für die Auswertung mit den meisten Programmen überhaupt nicht notwendig, für den monitord kann ich da allerdings leider nicht sprechen da ich den seit Jahren nicht verwendet habe. Dem Dekodieren sind eigentlich keine Grenzen gesetzt, als beispiel nehme ich mal Pocsag mit multimon-ng und dem in der rtl-sdr lib integrierten rtl_fm:
Wir wollen mit rtl_fm eine Frequenz hören von der wir wissen dass Pocsag Telegramme ankommen. Dafür brauchen wir die Parameter -N für die schmale Frequenzdemodulation -o4 für den empfohlenen oversampling wert von 4, der ATAN Wert muss lut sein, was auch immer das ist, wenn mir das wer sagen kann ist mir geholfen :D, jedenfalls "-A lut", samplerate vonn 22.5k, also -s 22050, -C gibt uns einen DC Block und mit -f definieren wir die frequenz, hier exemplarisch mal 666,66mhz, also -f 66.6M. Das übergeben wir dann an multimon-ng als -t raw, addieren die demudolatoren für Pocsag und nehmen die Daten von /dev/stdin. Ganz einfach, oder? ;)
Jedenfalls sieht das dann folgendermaßen aus:
Das kann man natürlich beliebig abändern und alles dekodieren was der Multimon so kann, FMS inklusive. Interessant ist sicher auch ADS-B, mit dump1090 kann man die Telegramme kinderleicht dekodieren und sich dank integriertem Webserver gleich im Browser anzeigen lassen - inklusive Karte mit Flugzeugpositionen. Auch hier - die Auswertung ist einfach super!Code:rtl_fm -N -o 4 -A lut -s 22050 -C -f 666.66M - | multimon-ng -t raw -a POCSAG512 -a POCSAG1200 -a POCSAG2400 /dev/stdin
Wer einfach seinen Scanner ersetzen möchte findet hier sicherlich auch Lösungen. gqrx sei für die Linuxer unter uns da erwähnt. Aber die ganzen Möglichkeiten hier aufzuführen würde wohl den Rahmen sprengen, man sollte sich son Ding aber mal anschauen ;)
Hallo zusammen,
ATAN - lut heißt lediglich, dass für die arcustangens Berechnung eine Luckuptabelle zum Programmstart generiert um zur Laufzeit Rechenleistung zu sparen.
Leider finde ist die direkte Integration von rtl_sdr in monitor aufwendiger als ich dachte. Mir fehlt leider aktuell die Zeit dazu.
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
Hast Du das auf einer X86 Platform laufen oder auch auf einem RaspberryPi?
Sent from my iPhone using Tapatalk
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 ;-)
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
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ß.
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
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.