Druckbare Version
Super Danke für die Info. Auf die Idee mit den Multimon Sourcen hätte ich auch selber kommen können *Kopf auf Tisch* ^^
Leg doch bitte nicht alles auf die Goldwaage :-DZitat:
Zitat von Smith
Du bist herzlich eingeladen, deine Anpassung im Repo zu Pushen ;-)
Sonst hätte ich mit den Git auch sparen können... ^^
Gruß
Ja, das habe ich den Abend und morgen getan ;-)
Ich gelobe Besserung. Solltest du bereits angefangen haben, schieb es ins devel. Ich nehme dann Anpassungen vor. Wenn nicht, baue ich den POCSAG Bereich gerne nach deinem System weiter.
Außerdem schaue ich mal am WE was wir auf der PHP Ausgabe noch machen können. Wobei McBo da besser ist. Der hat das mal gelernt :-D ;-)
Ne bis jetzt habe ich in Richtung POC noch nix gemacht. Kannst dich also gerne austoben :-)
Bei mir wirds bis zum Wochenende zeitlich eh eng...
Und was das PHP angeht. Das was aktuell existiert war ne absolut quick and dirty Lösung. Wenn McBo da Zeit und Lust hat, kann er sich gerne mit Einbringen. Ansonsten würde ich sagen frickeln wir uns da halt selbst was zusammen, wird schon werden :-P
Gruß
Ne, nix gelernt habe mir das selber angelesen.Zitat:
Zitat von Smith
Meine Zeit ist aber sehr knapp.
Aber mal was anderes, was mir aufgefallen ist.
Ich habe dafür keine Erklärung.
Ich speise über das Loop Device ezstream (Icecast).
Der multimon-ng wird über tee jetzt direkt gespeist.
Vorher hatte ich auch den multimon-ng aus dem Loop-Device gespeist.
Dabei war mir aufgefallen, dass nach einer bestimmten Laufzeit multimon-ng
beendet wurde.
Darauf hin habe ich mir jetzt mal ein Watchdog-Script mit Log-Funktion gebaut.
Exakt nach 18,6625 Stunden (67185 Sekunden) bricht der Stream ab.
Kann sich das jemand erklären?
Ist das ein Linux Problem?
Gruß
Marcel
Das einzige was mir dazu einfallen würde wäre ein Speicherüberlauf.
Eines der eingebundenen Programme in deiner Struktur wird wohl alles schön in den RAM schreiben aber wenn er es nicht mehr braucht kicken.
Ich denke irgendein Audioprogramm welches zu den Datenstrom zukommen lässt denn der Audiostream wird immer gleich groß sein da feste Samplerate etc.
Check doch einfach mal per htop Daten der Prozesse kurz vor dem Zeitablauf.
@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
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 ;-)
@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
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?
Nur wie? Mir fehlt der Ansatz.Zitat:
Dann mal debugen...
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.
Wenn Du kein GBit-Lan oder S-ATA benötigst,Zitat:
Bist mit dem Pi2 zufrieden?
ist der Pi2 echt Top.
Habe schon einige Projekte damit umgesetzt.
Die Community ist einfach beim Pi am besten.
Gruß
Marcel
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.
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.
Edit:Code: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 <module>
rtl_fm.terminate()
NameError: name 'rtl_fm' is not defined
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...
Zum Thema Auslastung, das hat sich erledigt.
Ich habe gerade noch nen apt-get update etc gemacht. Dabei wurde auch python gefixt.
Erledigt.
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???Zitat:
Zitat von 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
dann funktioniert da aber was nicht richtig? :)Zitat:
Zitat von Schrolli
ändere mal den Befehl
<CODE>apt-get update > ~/bos/install/setup_log.txt 2>&1</CODE>
in
<CODE>apt-get update -y > ~/bos/install/setup_log.txt 2>&1</CODE>
Nur hierdurch wird keine Benutzerinteraktion gefordert.
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.Zitat:
Zitat von McBo
OK, neuer Versuchsaufbau :-)Zitat:
Zitat von Smith
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
au Mist, das -y hab ich total verschwitzt... oke mein Fehler ^^
So, habe jetzt lange getestet - gleiches Problem,Zitat:
Zitat von McBo
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
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.
- 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.
Schade, kannst Du vielleicht mal über den Quellcode von multimon-ngZitat:
Zitat von Smith
schauen?
Den Fehler mit den Umlauten hast Du doch auch gefunden. :-)
Du hast keine Lust? :-)
Ich habe mir dafür einen Versuchsaufbau gemacht.Zitat:
Ich habe keine Möglichkeit mehr das zu testen.
Ü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?
Ja, haut alles hinter der Pipe weg.Zitat:
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.
Mit Reseten meinst Du Neustart der Pipe-Einspeisung?
Gruß
Marcel
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
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.... :(
OK,
habe es erst einmal so im Py Script gelöst:
Gruß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)
Marcel
@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ß
Nur Zahlen, ich wollte den Regex auch wieder eingebaut haben. Im Rahmen einer Fehlersuche ist der geflogen.
Allerdings gibt der multimon-ng eh nur Zahlen aus. Von daher ist es egal. :)
multimon-ng kennt keine Buchstaben.Zitat:
Zitat von Smith
A ist bei multimon-ng = 10
B = 11
C = 12
D = 13
........
Da benötige ich aber Zugangsdaten von Dir?Zitat:
Du musst dann nur für eine git clone den Fork aus meinem Repo nehmen. Elias pushed anscheindend keine Änderungen mehr.... :(
Ahh okay. Das hat sich Elias dann anscheinend bei FMS32 abgeschaut. Ich weiß ehrlich gesagt gar nicht wie es die TR vorsieht.
Habe mal das ganze neu geladen, aber jetzt lief ich in einen Fehler, wo vor einem else: leerzeichen statt tabs waren, aber jetzt bekomm ich folgende Meldung:
Code:File "./boswatch.py", line 345
if len(poc_id) == 7: #if POC is valid
^
IndentationError: unindent does not match any outer indentation level
[1]+ Exit 1 sudo ./boswatch.py -f 88.888M -a FMS ZVEI -s 50 -e 33
Das ist die erste Meldung:
Code:File "./boswatch.py", line 342
else:
^
IndentationError: unindent does not match any outer indentation level
[1]+ Exit 1 sudo python ./boswatch.py -f 88.888M -a FMS ZVEI -s 50 -e 33
Ich schaue gleich mal. Der Fehler wird wohl aus meiner Feder stammen, Copy&Past geschuldet...
Ich werde es gleich über Schrolli einstellen lassen.
Ich weiß nicht ob es hier irgendwer braucht, aber wenn wer Beta-Tester für eine Verbindung zu firEmergency sein möchte, der melde sich bitte bei mir per PN.
Bitte unter Angabe der Alarmierungsart - bisher habe ich nur POCSAG1200 -> firEmergency programmiert. Bei Bedarf würde ich es auch für Analog und POCSAG512 umschreiben für die Beta-Phase.
Fehler behoben. Script funktioniert wieder.
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:Zitat:
Zitat von Smith
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
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.Zitat:
Zitat von McBo
*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.
Ich hatte in meinem Python Script, nur Statis mit der Richtung 0=FZG->LSTZitat:
Zitat von Jannis
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
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 ..
Moin, moin,
ich habe mal etwas mit den beiden Skripten herum gespielt und habe da noch ein paar Fragen:
1a) Wird an Raspoc überhaupt noch entwickelt, oder ist es zugunsten von BOSWatch eingestellt worden?
1b) In Raspoc schaffen es nur die Alarmierungen mit Text in den DB, Alarmierungen ohne Text kommen dort nicht an...
1c) In Raspoc ist die Kanal-Angabe zwar bequem, aber leider sind die meisten TV-Sticks nicht so genau, so dass man einen "Versatz" angeben muss (bei meinen Sticks z.B. 9kHz)
2a) Ich habe hier im Thread von dem Zeitproblem gelesen. Daher eine Verständnisfrage: Warum wird dann im Skript nicht direkt rtl -> multimon-ng genutzt, wie bei Raspoc?
2b) In der Konfiguration ist ein Fehler:
Die Pocsag-Tabelle ist im config-File falsch angegeben.
2c) Ist es geplant den HTTP-Request parametrisierbar zu machen? Dann könnten die Alarmierungen an einen zentralen Server "weitergereicht" werden.
3) Hat schon jemand Erfahrung mit der Anbindung an BOSMon?
Grüße
Jens
Ich gehe davon aus, das Rene an Raspoc nicht weiterarbeitet, da er sich mittlerweile auch bei BOSWatch beteiligtZitat:
Zitat von JHC
Willst du alles in die DB oder nicht? BOSWatch speichert prinzipiell alles was ankommt, solange es dem Filter entspricht.Zitat:
Zitat von JHC
BOSWatch hat aktuell nur eine direkte Frequenz Angabe. Optionale Angabe des BOS Kanals ist aber angedacht. Für diesen Versatz gibt es im übrigen die Möglichkeit direkt einen Fehler in PPM des Sticks anzugeben.Zitat:
Zitat von JHC
Wird doch auch bei BOSWatch gemacht. Der Out Stream von rtl_fm wird direkt in Multimon-NG eingespeist. Das Zeitproblem bezog sich auf eine Audioaufnahme des Streams.Zitat:
Zitat von JHC
Schau ich mir an, wird behoben!Zitat:
Zitat von JHC
EDIT: Done!
Ja ist angedacht. Hast du evtl Vorschläge oder Anregung für die Art der Parametrisierung?Zitat:
Zitat von JHC
Ich Persönlich nicht.Zitat:
Zitat von JHC
Gruß Basti
Hallo Basti,
okay, die Themen zu raspoc verfolge ich dann nicht weiter und konzentriere mich auf BOSWatch:
Wie muss man diesen Versatz angeben? PPM ist was für eine Einheit?Zitat:
Zitat von Schrolli
Aktuell übergebe ich einfach die "richtige" Frequenz an BOSWatch...
zu 2c/3: BosMon-Anbindung
Tja, hier ist leider noch die Antwort von Thimo offen, welche Parameter BosMon da erwartet/anbieten kann.
Ich hoffe, dass ein parametrisierter http-Request funktionieren wird.
2d) Filter:
Ich habe hier noch ein kleines "Problem" mit dem Duplikats-Filter:
Wir sind hier im Grenzgebiet der DAU-Abdeckung, die durch eine Überlappung von
mehreren DAUs sichergestellt wird. Je nach Wetter kommt mal der eine oder mal
der andere DAU gut rein.
Wenn ich den Filter ausschalte, gibt es mehrere und meistens auch mindestens einen
vollständigen Eintrag:
Wenn ich den Duplikats-Filter hier jetzt einschalte, wird im Zweifel nur der 1. Datensatz angezeigt und ist leider nicht vollständig...Code:20:35:26 1234567 SR!*R 105*H...*G...*Friedrich-Ebert-Str. 00
20:35:33 1234567 SR!*R 105*H...*G...*Friedr
20:35:49 1234567 SR!*R 105*H...*G...*Friedrich-Ebert-Str. 00*Gebäude
xyz im 1. OG<EOT>
20:35:57 1234567 SR!*R 105*H...*G...*Friedrich-Ebert-Str. 00*Gebäude xyz
Ich befürchte, dass hier das Herausfischen des vollständigen Datensatzes nicht trivial wäre oder?
Solange würde ich den Filter ausstellen und später in der Auswertung die Duplikate hinaus schmeißen.
Grüße
Jens
erstmal was didaktisches zu PPM: http://de.wikipedia.org/wiki/Parts_per_million :-DZitat:
Zitat von JHC
Im Prinzip wird der Versatz vom Tuner abgegeben. und zwar nicht in Prozent oder Promille, sondern in PPM (also Millionstel)
Hier eine Anleitung wie man den Error für seinen Stick per kalibrate-rtl ermitteln kann
http://www.rtl-sdr.com/how-to-calibr...-rtl-on-linux/
Einfach die empirisch ermittelte, passende Frequenz anzugeben, ist natürlich einfacher und ebenso zielführend ;-)
Oke, wenn du was weist, melden :-)Zitat:
Zitat von JHC
Schwierig. Der erste Einrag wird direkt gespeichert, alle folgenden mit dem selben RIC verworfen. Um sowas zu bewerkstelligen müsste man im Prinzip JEDES irgendwo zwischenspeichern, hinterher alle Vergleichen und dann das größte Paket nehmen. Kommt bei der Auswertung nun Müll an, der an Zeichen mehr Inhalt hat als das korrekte Paket, so würde auch das fehlerhafte gespeichert.Zitat:
Zitat von JHC
Also durchaus nicht so trivial leider.
Gruß Basti
Hallo Basti,
Das habe ich schon ausprobiert, geht mit meinem Stick nicht.Zitat:
Zitat von Schrolli
Daher die "händische Frequenzwahl" per graphischem SDR...
Wäre auch nur nice-to-have gewesen...Zitat:
Zitat von Schrolli
2e) Installations-Script:
Ich hatte mir die Skripte per "git clone" in mein Home "/home/pi/scr/" geholt.
Nach dem Ausführen des Installationsskriptes mit root-Rechten wurde BosWatch ins Root-Home-Verzeichnis installiert. Das war sicherlich nicht beabsichtigt oder?
Grüße
Jens
Nein, eigentlich sollte das Paket dann in den Ordner ~/boswatch installiert werden, wobei das '~' dem home des aktuell angemeldeten Users entspricht. Daher sollten die Daten eigentlich im Ordner /home/pi/boswatch/ landen, wenn du als pi angemeldet bist.Zitat:
Zitat von JHC
Ich schau mir das Script aber morgen bei Gelegenheit noch mal an.
Gruß Basti
Hallo Basti,
gefunden hatte ich es hier: "/root/bos/BOSWatch"Zitat:
Zitat von Schrolli
Grüße
Jens
Hab jetzt noch eine kleine Änderung am Install Script vorgenommen.
Dies liegt aktuell allerdings nur dim Dev Branch https://github.com/Schrolli91/BOSWatch/tree/develop
Die Daten werden jetzt nach /home/USER/boswatch installiert
und die Daten der Installation liegen unter /home/USER/boswatch/install ebenso wie das Logfile(setup_log.txt), das es zu sichten gilt wenn bei der Installation was schief geht.
Wenn das Zeug bei dir in /home/root/... gelandet ist, dann warst du auf dem Raspi auch als root eingeloggt, so einfach ist das ^^
~/ verweist immer auf das eigene home Verzeichnis des aktuell angemeldeten Users.
(~/ == /home/USER/)
Gruß Basti
Hallo Bastion,
jein... ich war mit dem pi-User angemeldet. Da ich davon ausging, dass das Skript root-Rechte benötigt, habe ich es mit "sudo ./install.sh" ausgeführt.
Grüße
Jens
Mal eine dumme Frage ;-)
Auch wenn die meisten von Euch schon digital sind.
Kann multimon-ng - FMS-Text?
Und könnte man nicht so eine "Auto-Tune" Funktion
einbauen (eventuell mit Hilfe von "kal"),
der die genaue Centerfrequenz bestimmt und verwendet.
Weis ich leider nicht...Zitat:
Zitat von McBo
Geht bestimmt... Kann ich aber nicht machen, da bei mir nicht mal Kal läuft... irgendwas haut da nicht hin. Scheint nicht mit meinem Stick zu wollenZitat:
Zitat von McBo