LRPT Empfang mit SDR / RTL-SDR auf 137 MHz

[Goofy78]

Willkommen im Forum Happysat!

[Happysat]

M2 LRPT Decoder V50:

- Der Pfad kann über das Plugin angepasst werden

In der INI-Datei können Sie pathM22 für Bilder M22 hinzufügen, während M2 im Pfad gespeichert wird.
Vom Plugin aus der Pfadparameter, der die höchste Priorität gegenüber den Einstellungen in der INI-Datei hat.

Beispiel:
M2_decoder_init_Line <Pfad = D: \ SDR \ Meteor \ ImagesM2>


M2_decoder_init_Line <Pfad = D: \ SDR \ Meteor \ ImagesM22>


Beispiel bilder von scheduler config in zip datei.

Auto Symbolrate:

https://imgur.com/HVJ6ieM

http://happysat.nl/LRPT_Decoder_v50.zip

[Enager]

Guten Morgen,

ich habe nun raus gefunden, warum SDRSharp meine vom Banana-Pi aufgezeichneten GNURadio-Aufzeichnungen nicht abspielen mag. Es liegt an der Art und Weise, wie die Aufnahmescripte beendet werden. Nämlich mittels "sudo killall python". Damit wird das Programm nicht beendet, sondern abgebrochen und die Wave-Datei wird nicht beendet. Und genau daran stört sich SDRSharp. Nun bin ich schon den ganzen Abend am suchen nach einer Möglichkeit, wie ich mittels Konsole so ein PythonScript ordentlich beenden kann, so dass auch das Dateiende der Wave-Datei geschrieben wird. Bislang wird dieses Ende nur geschrieben, wenn ich per Maus auf das X des Programmfensters klicke, oder lasse ich das Script als Konsolenanwendung laufen, so lässt es sich nur durch Betätigen der Enter-Taste ordentlich beenden. Alle Versuche mit kill, pkill, killall, timeout ... haben alle die gleiche Wirkung: Programmabbruch und fehlendes Dateiende. Wenn jemand eine Möglichkeit kennt, per Konsolenbefehl ein laufendes Programm ordentlich zu beenden, imme rher damit. Dadurch würde mir zukünftig die Arbeit erspart bleiben, die aufgezeichnete Wave-Datei immer erst mittels HDSDR für SDRSharp lesbar zu machen.

Gruß und eine gute Nacht an alle,

Stefan.

[Happysat]

Tutorial Setup Meteor M-N2 / N2-2 mit LRPT-Decoder Aktualisiert für neue Änderungen.
http://happysat.nl/Setup_Meteor/Setup.html

Stefan, wenn dieses grc-script ein rtl-sdr verwendet, kannst du es mit killall -9 rtl_fm 2> /dev/null beenden.
Andernfalls beenden über den scriptnamen, wenn diese grc-Datei bereits zu Python kompiliert wurde - killall -9 python <scriptnamen>.py 2> /dev/null

Mfg Alex

[Enager]

Guten Morgen,

Alex, ja, das Script verwendet ein RTL-SDR. Ich habe inzwischen aber eine andere Lösung gefunden, auch wenn mir dies erst um 2 Uhr nachts gelungen ist :
Hier mal das GNURadio-Script als Flowgraph:


Durch das "Promt for Exit" generiert GNURadio ganz am Ende des Scripts noch eine IF-Then-Bedingung mit try-case, welche ich wie folgt abgeändert habe:

Code: Alles auswählen

if __name__ == '__main__':
    parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
    (options, args) = parser.parse_args()
    tb = recm22()
    tb.start()
    time.sleep(780)
    tb.stop()
    tb.wait()


Die alles entscheidende Änderung besteht in der Zeile mit dem sleep. Angegeben sind 780 Sekunden, was 13 Minuten entspricht. Sollte lang genug für so ziemlich jeden Sat-Überflug sein. Da die Auswertung ohnehin per Hand über SDRSharp erfolgt, wird die weitere Verarbeitung ohnehin beendet, sobald der Dekoder das Satsignal verliert. Das Script beendet sich somit nun nach 780 Sekunden selbst.

Auf diese Weise konnte ich heute die nächtliche Aufzeichnung ohne HDSDR nutzen zu müssen, direkt in SDRSharp dekodieren lassen. Dabei ist das folgende Infrarotbild entstanden:


Gruß Stefan.

[Rommie]

Bei mir will es einfach nicht gelingen...

http://webserver-2.de/ablage/afu/6.jpg

Ich vermute, daß es hier dran liegt

http://webserver-2.de/ablage/afu/5.jpg

Irgend etwas verursacht bei mir einen 'Lattenzaun' auf dem Äther. Ich weis nur noch nicht was. APT mit NOAA hingegen klappt einwandfrei. Ok, ist ja auch wesentlich schmalbandiger...

[Enager]

Hallo Rommie,

nein, diese im Bild markierte "Störfrequenz" habe ich ebenfalls und trotzdem top Bilder. Das sind wohl eher Telemetriedaten oder sowas. Mir sieht es nach zu geringer Bandbreite aus. Die Bandbreite/Bandwith sollte mindestens 120kHz betragen. Im Bild fehlen einfach Bildinformationen, bedingt durch eine zu geringe bandbreite. Durch die fehlenden Inforamtionen kommt es zu schwarzen Streifen im Bild. Bei SDRSharp die "Bandwith" also wenigstens 120.000 einstellen und WFM auswählen. Dann sollte es klappen.

Ich selbst habe eben M2-N21 aufgezeichnet. Schöne Ostrunde, mit tollen Einblicken in Fernost:

Durch das neue Script kann ich nun beide Meteor's mittels SDRSharp dekodieren und hierbei die neuen SDRSharp-Plugins nutzen. Und hier ist mir aufgefallen, dass die Plugins offenbar deutlich besser auf die Satellitensignale ansprechen, als das bisher von mir verwendete Programm LRPTrx.exe. Die Bilder werden länger und es sind weniger bunte oder gar schwarze Streifen im Bild.

Von daher, Alex und Vasili, top Arbeit .

Gruß Stefan.

[Rommie]

Hab meine Beiträge mal so editiert, daß die Bilder nur noch verlinkt werden. Die sind wohl etwas groß für dieses Forum. Da ich eigenen Webspace nutze, klappt es auch nicht mit einer Miniatur-Ansicht. Sorry dafür...

Enager, Du schreibst, daß es sich dabei um Telemetrie-Daten handelt. Die können aber dann nicht vom Meteor selber sein, da ich die permanent empfange.

http://webserver-2.de/ablage/afu/7.jpg

Es muß also irgend etwas anderes sein, was da stört. Trotzdem werde ich mal beim nächsten Überflug eine Bandbreite von 120.000 einstellen. Vielleicht hilft es ja...

---

Zusatz-Eintrag:

Habe eben einen weiteren Überflug mit Meteor-M2 aufgezeichnet, diesesmal mit 120.000 Bandbreite. Leider keine Verbesserung.

[JA6UAR]

Grüße

Diese "schwarzen Balken" hatte ich auch schon bei mir lag es am Hardware Setup !! Mein altes Notebook war einfach zu lahm um LRPT in Echtzeit zu verarbeiten.

Was hast du für eine CPU im Einsatz ? falls es eine ältere ist probiere die 0.900001 MSPS als Sample Rate und verzichte auf das Echtzeit FFT

Mfg. Alex

[Maik]

@Rommie ich würde sagen das macht ein pulsierendes Störsignal bei dir. Die Streifen sind fehlende Bildinhalte. Beobachte doch mal dein FFT Wasserfall. Also ich würde jetzt mal ins blaue tippen, dass VDL2 auf ~136.9MHz der Übeltäter ist.