Die Satellitenempfangsanlage

[enager]

Heute geht es um die Satellitenempfangsanlage. Von der Antenne, bei welcher die Stellitensignale ankommen, bis hin zum fertigen Satellitenbild.

Fangen wir bei der Antenne an:

Es handelt sich hier um eine selbstgebaute Quadrifilar Helix (kurz QFH) Antenne, abgestimmt auf 137MHz. Diese ist rechtsdrehend zirkularisiert und weist vom Empfangsdiagramm her nahezu Kugelcharakteristik auf. Das heiß, sie empfängt nach alle Richtungen (Oben, unten, rechts, links, vorne, hinten) annähernd gleich gut. Dies ist auch wichtig, da die Satelliten abgesehen von unten, auch von überall zu empfangen sind.

Weiter geht es über die Antennenleitung. Hier ist an der Antenne zunächst RG58 Antennenkabel mit 50 Ohm Impedanz verbaut. Da aber das normale Satkabel aus dem Baumarkt die geringste Signaldämpfung aufweist und die Fehlanpassung 50 Ohm auf 75 Ohm nur einen sehr geringen Signalverlust darstellt, geht schon auf dem Dach über einen F-Stecker-Verbinder das RG58 auf ein KOX 720 Satkabel über.

Als nächstes folgt der SDR-Stick:

Wie das Bild zeigt, habe ich diesen recht elegant in einen Kabelkanal eingebaut. Oben steckt der dicke Koaxialstecker in der Buchse des SDR-Sticks (welcher mit einem RTL2832u AD-Wandler sowie einem R820T Tunerchip bestückt ist), unten steckt der USB-Stecker dran. Dieser Stick ist bislang der empfindlichste den ich bisher hatte und zaubert die auf dieser Homepage auffindbaren Satellitenbilder ganz ohne Vorverstärker. Die Aufschrift "Defekt" hatte ich einst drauf geschrieben, da bei dem Versuch das Antennenkabel direkt auf den Stick zu löten, ein SMD-Bauteil verrutscht war und der Stick zwar weiterhin funktionierte, aber recht taub geworden war. Glücklicher Weise befand sich das Bauteil noch auf der Platine, so dass ich es wieder korrekt festlöten konnte. Danach war der Stick wieder gewohnt empfindlich.

Es folgt, der Banana-Pi:

An diesem hängt der SDR-Stick über eine 3m USB-Leitung. Ebenfalls am Banana ist ein kleiner weisser Stecker am Klinkenanschluss zu sehen. Über diesen werden die Audiosignale der NOAA-Satelliten zur Kontrolle auf einen Ohrhöhrer ausgegeben. Vorrangig werden sie natürlich als WAVE-Datei aufgezeichnet. Dazu aber gleich mehr.

Zur Aufzeichnung der Satellitensignale habe ich mir 3 Programme unter GNURadio geschrieben:

Das Programm ist dabei jedes mal das Gleiche, nur dass es eine andere Empfangsfrequenz hat. Eben für NOAA15, 18 und 19 jeweils ein Empfangsprogramm. Wie im Flowchart zu sehen ist, kommt ein 960kHz breites Spektrum vom RTL-SDR-Stick. Von diesem Spektrum werden insgesamt 100kHz vom LowPass Filter durchgelassen, wobei nur 60kHz mit voller Signalstärke durchgelassen werden. Das Signal am Rand des durchgelassenen Spektrums wird zum Rand hin immer schwächer. Diese verbliebenen 100kHz Bandbreite gehen dann durch einen Breitband-FM-Demodulator, welcher die nicht hörbaren Hochfrequenzsignale in hörbare Niederfrequenzsignale umwandelt. Da der Demodulator noch mit 96kHz arbeitet, die WAVE-Dateien aber mit 11,025kHz und der Audioausgang des Banana-Pi mit 44,1kHz arbeiten, müssen die 96kHz noch entsprechend herunter gerechnet werden, was der "Rational Resampler" erledigt. Nun ist das Pfiepen der NOAA-Satelliten am Audio-Ausgang des Banana-Pi zu hören und wird zeitgleich als WAVE-Datei aufgezeichnet.

Auf diesem Screenshot ist nun das Steuerprogramm (unter Lazarus programmiert) zu sehen:

Dieses hat die Zeiten und andere Daten der Satellitenüberflüge gespeichert und schaut im Sekundentakt, ob die Zeit für die Aufnahme eines Satelliten erreicht wurde. Kommt ein Satellit, so wird über einen Shellbefehl das Phytonscript welches GNURadio generiert hat, gestartet:

Das Steuerprogramm hat kurz vor dem Start des GNURadio-Scripts noch eben die Endzeit in eine Textdatei geschrieben, welche sich ein anderes Lazarus-Programm schnappt und bei Erreichen dieser Zeit, dass GNURadio-Phytonscript per "killall" Konsolenbefehl beendet. Da sich das Steuerprogramm während des Satellitenüberflugs in einer Warteschleife befindet (es hängt sich also quasi auf und bleibt stehen) kann es nach dem starten des GNURadio-Scripts auch gleich mit der Dekodierung des Satellitenbildes los legen. Dies geschieht per Konsolenbefehle, welche WxToImg bereit stellt. Als erstes erstellt WxToImg per Konsolenbefehl die passende MAP zum Satellitenbild. Danach wird das Bild selbst dekodiert und als letztes die Map darüber gelegt. Das Steuerprogramm generiert die HTML-Seite für die Homepage und lädt die HTML-Seite wie auch die Satbilder auf die Homepage.

Woher weiss nun das Steuerprogramm wann ein Satellit kommt?

Hier bediene ich mich einfach bei WxToImg. Als erstes werden die Keplerdaten aktualisiert. Danach lasse ich mir die kommenden Satllitenüberflüge anzeigen und übertrage sie in ein weiteres selbst geschriebenes Lazarusprogramm. Dieses dekodiert die Satellitenzeiten und speichert sie in einem vom Steuerprogramm lesbaren Format. Alle paar Wochen muss ich diese Daten aktualisieren um die Satellitendaten auf dem Laufendem zu halten.

Aber ich empfange ja nicht nur die NOAA-Satelliten, sondern auch die Meteor Satelliten:

Hier sieht der Flowgraph unter GNURadio ein wenig anders aus. Denn hier wird nur das 1,04MHz breite Spektrum auf 130kHz herunter gerechnet und von einem "Complex to Float" Wandler in ein Stereo-Audio-Stream gewandelt, welcher in einer WAVE-Datei aufgezeichnet wird. Diese meist um die 360MB großen Dateien ziehe ich mir am Nachmittag, nach Feierabend auf meinen Windows-Rechner und dekodiere diese dort. Hierzu findet das Programm LRPT.exe Verwendung, welches die WAVE-Datei in eine RAW Datei wandelt. Diese RAW-Datei wid dann vom "LRPTofflinedecoder" in 3 Bilder gewandelt. Meist sind dies die Bildkanäle Rot, grün und Infrarot. Rot und grün können zu einem Farbbild zusammengerechnet werden. Da die originalen Meteor-Bilder noch einen sehr deutlichen "FischAugen-Effekt" aufweisen, werden sie noch mittels smoothmet.exe entzerrt. Unter Photoscape schärfe ich die Bilder dann noch etwas, trage das neue Bild in die HTML-Datei für die Homepage ein und dann geht das alles auf die Homepage.

In diesem Forum wird das Thema "Meteor Satellitenbilder dekodieren" sehr ausgiebig behandelt. Auch sind hier Downloadlinks für die zum dekodieren nötigen Programme zu finden.

Die Aufnahme der Meteorsatelliten wird ebenfalls vom Steuerprogramm für die NOAA-Satelliten gesteuert. Die Überflugszeiten hole ich mir hier von Orbitron und trage diese Zeiten von Hand in den Sateliitenüberflugszeit-Dekoder ein. Die Aufnahme der Meteor-Satelliten ist also im Gegensatz zu den NOAA-Satelliten nur sehr wenig automatisiert.

So, dass mal zu meiner Satellitenempfangsausstattung.

Update:

Inzwischen habe ich ein Raspberry-Pi Image erstellt, mit welchem der Empfang der NOAA und Meteor-Satelliten möglich ist. Das Image kann hier heruntergeladen werden.

[enager]

Gestern habe ich den Speicherort der WAVE-Dateien abgeändert. Wurden diese bislang auf der SD-Karte abgelegt, welche der Banana-Pi zum booten benötigt, so werden die WAVE-Dateien nun auf der SATA-Festplatte gespeichert. Hintergrund dieser Änderung ist die Hoffnung, dass damit die vorzeitigen Aufzeichnungsabbrüche der Vergangenheit angehören. Bisher war es oft so, dass das GNURadio-Programm während der Satellitenbildaufzeichnung sich einfach beendet hat. Dadurch entstanden immer die kurzen Satellitenbilder. Seit dieser Änderung am gestrigen Nachmittag, sieht es auch so aus, als hätte diese Aktion Erfolg. Seit dem wurden alle Satellitenbilder in voller Länge aufgezeichnet. Aber man soll den Tag ja bekanntlich nicht vor dem Abend loben. Daher hoffe ich, dass sich auch weiterhin keine vorzeitigen Empfangsabbrüche ereignen.

Ebenfalls neu, ist die Ausgabe der Endzeiten der Satellitenüberflüge. Etwa 3 Minuten nach dieser Zeit kann man auch so langsam die entsprechenden Bilder auf der Homepage erwarten. Der Banana-Pi möchte schließlich auch etwas Zeit zum Bilder dekodieren und den Upload haben.

[enager]

Nachdem ich in den letzten Tagen im Netz einen Konsolenbefehl gefunden habe, mit welchem die NOAA-Satellitenbilder mittels "RTL_FM"-Befehl aufgezeichnet werden können, ist es nun möglich, endlich diesen ewigen vorzeitigen Empfangsabbrüchen aus dem Weg zu gehen.

Bisher wurden die Satellitenbilder mit unter GNURadio erstellten Phyton-Scripte aufgezeichnet.



Diese Scripte haben den kleinen Banana-Pi auch stets gut ausgelastet. Leider sind die Aufnahmescripte auch nicht selten mitten drin abgestürzt, so dass nur ein geringer Teil des Satellitenbildes aufgezeichnet wurde. In Zukunft werden die Bilder mit dem Befehl "rtl_fm" aufgezeichnet. Zusätzlich sorgt ein "Timeout" Befehl dafür, dass der Satellit nicht endlos aufgezeichnet wird. Die Zeit für das Timeout wird vom Steuerprogramm, aus den Anfangs- und Endzeiten des Satellitenüberfluges berechnet (Endzeit - Anfangszeit = Überflugsdauer = Timeout-Zeit). Damit enfallen 2 zusätzliche Programme. Zum einen das bisherige GNURadio-Script, zum anderen das zusätzliche Programm, welches bei Überflugsende die Aufzeichnung mittels "Killall" Befehl beendet. Erste Tests zeigten auch eine deutlich geringere Auslastung des Banana-Pi. Zeigte der CPU-Monitor bei Verwendung der GNURadio-Scripte stets runde 50% Auslastung an, so ist bei Verwendung des "RTL_FM" Befehls die Auslastung auf dem CPU-Monitor kaum zu erkennen und liegt deutlich unter 10%.

Die Umstellung auf den "rtl_fm"-Befehl wird am heutigen Abend geschehen. Nachfolgend sollten alle Satellitenbilder vollständig aufgezeichnet werden und Satellitenbilder wie dieses:



werden zukünftig Geschichte sein.

---

Nachtrag 12.02.2017:

Es ist geschafft. Am heutigen Tag wurde bisher noch kein Satellitenbild vorzeitig abgebrochen. Allerdings ist nicht alles so gelaufen wie geplant. Statt dem „rtl_fm“ Befehl kommen nun doch meine GNURadio-Scripte weiterhin zum Einsatz. Diese weisen eine deutlich höhrere Empfangsempfindlichkeit auf, als der Konsolenbefehl „rtl_fm“. Kam bei „rtl_fm“ Noaa18 am Samstag am Bildanfang- und Ende recht verrauscht daher, so können alle 3 aktiven NOAA-Satelliten bei Verwendung der GNURadio Scripte weit bis in den Norden/Süden hin aufgezeichnet werden und das nahezu störungsfrei. Das große Geheimnis warum die Satbilder nun stets komplett aufgezeichnet werden, liegt darin wie die Aufzeichnung beendet wird. Wurde dazu bisher der Konsolenbefehl „killall“ verwendet, so kommt nun der „timeout“ Befehl zum Einsatz. Die Timeout-Zeit wird aus der Differenz von Anfangs- und Endzeit der Satellitenaufnahme berechnet. Offenbar gibt es immer wieder Prozesse im Hintergrund des Banana-Pi welche zu einem vorzeitigen Auslösen des „killall“ Befehls führten. Durch den Wechsel zum „timeout“ Befehl, ist dies nun irrelevant geworden. Das einzigste was schön wäre wenns irgendwann mal klappt ist jetzt noch, dass auch Satelliten mit einer max. Erhebung <20° auch eine überlagerte Landkarte bekämen. Da streikt bisher WxToImg indem es mir erzählt das es keinen entsprechenden Satelliten finden konnte, welcher zur angegebenen Zeit den Standort überflogen hätte. Ist die max. Satellitenerhebung hingegen größer 20°, klappt auch die überlagerte Landkarte.

Des weiteren wurde der F-Stecker/Buchse-Kontakt an der Antenne noch einmal überarbeitet. Aus einem einfachen, auf das Antennenkabel geschraubten F-Stecker wurde nun eine direkt an das Antennenkabel angelötete F-Platinen-Buchse, welche mittels Heißkleber und Schrumpfschlauch wetterfest gemacht wurde, verwendet. Damit wurden die Litungswiederstände aufs Minimum reduziert und damit die Empfangsleistung wieder deutlich gesteigert.

Antenne-neu.jpg (55.15 KiB) 42376 mal betrachtet

[enager]

Leider hat sich die Thematik der zu früh beendeten Satellitenaufzeichnungen bis heute nicht erledigt. Immer wieder werden teilweise mehrere Bilder nacheinander nicht bis zu Ende aufgenommen. Kurioser Weise besteht dieses Problem bei den Meteor-Aufnahmen nicht. Hier zeichnet das GNU-Radio Script den Satelliten von Anfang bis zum Timeout komplett auf. Folglich muss das Problem irgendwo bei der nachgeschalteten Signalverarbeitung liegen. Damit käme eigentlich nur die Komponente "WBFM Receive" in Frage, welche das Satellitensignal gleich in ein Frequenzdemoduliertes Signal umwandelt. Die restlichen Komponenten existieren so auch im Meteor-Script.

Mal schauen. Ich probiere heute mal den Einsatz der "Osmocom Source" als SDR-Quelle, anstelle der bisher verwendeten "RTL-SDR Source". Vielleicht macht die ja etwas anders und die Scripts stürzen nicht mehr so viel ab. Zudem ist ein neuer SDR-Stick unterwegs. Dieser ist Temperaturstabilisiert (Wärme wird über ALU-Gehäuse abgeführt) und besitzt den neuen Tunerchip "R820T2" welcher gegenüber dem jetztigen R820T noch ein wenig empfindlicher ist. Zudem ist beim neuen Stick auch ein temperaturstabilisierter Oszillator im Einsatz, so dass eine Erwärmung des Sticks nicht mehr zur Frequenzverschiebung führt.

Zudem bin ich auch am überlegen, mir irgendwann mal den "Banana Pi M2 ultra" zuzulegen. Dieser ist nach dem Original-Banana-Pi der nächste, welcher einen Sata-Port anbietet, welcher eine eigene Datenleitung zur CPU aufweist. Bei den meisten anderen Mini-Computern mit Sata-Port, hängt dieser nur auf der USB-Leitung mit drauf, auf welcher oft auch die Netzwerkadapter, SD-Ports und natürlich die USB2.0 Ports mit drauf liegen. Dies ist beim M2 ultra nicht an dem. Hier stört dem Sata-Port kein weiterer, auf die Leitung gesetzter Anschluss.

[enager]

Es hat sich wieder einiges an der Empfangsanlage getan. Zum einem ist seit Mittwoch ein neuer DVB-T Stick im Einsatz. Es handelt sich hier um den "NESDR Smart" welcher nicht nur einen neuen Tuner (R820T2) besitzt, welcher nun nochmals empfindlicher ist, als der R820T, sondern zudem sehr temperaturstabil aufgebaut wurde. Er wurde er so konstruiert, dass er seine Abwärme problemlos an sein Aluminiumgehäuse abgeben kann (welches zugleich vor Einstrahlung von Störfeldern schützt), zum anderem wurden besonders temperaturunabhängige TCXO-Quarze verwendet, so dass die Empfangsfrequenz sich nicht mehr in Abhängigkeit zur Temperatur im Stick, ändert. Alles in allem, ist dieser neue Stick sein Geld wert.

Des weiteren wurden mögliche Übergangswiderstände in der Antennenleitung beseitig. Bisher war der Übergang RG58 zu KOX720 Antennenkabel durch einen F-Stecker und einer F-Kupplung ausgeführt. Gestern Abend habe ich nun beide Kabel aneinander gelötet. Zunächst wurden beide Innenleiter miteinander verlötet. Danach wurden die Innenleiter mit etwas Heißkleber und einem äußeren Mantel vom RG58 Kabel isoliert. Es folgte eine Lage Alu-Klebeband, welches die Alufolie aus den beiden Antennenleitungen ersetzen sollte. Auf diese Alu-Folie wurden die beiden Schirmungen überlappend aufgelegt und verlötet. Als letzte Lage kam als Witterungsschutz sowohl Schrumpfschlauch als auch Alu-Klebeband zum Einsatz. Durch das Löten gibt es nun keine Übergangswiderstände mehr, was sich auch in den Satellitenbildern nieder schlägt. Hatte ich zuvor noch im Norden und Süden leichte Rauscheinbrüche in den Bildern, weisen die heutigen Bilder kaum noch sichtbare Störungen auf. Der Empfang wurde durch diese Maßnahme folglich nochmals gesteigert. Und das alles nach wie vor, ganz ohne Vorverstärker in der Antennenleitung. Ein LNA4ALL liegt zwar in der Bastelkiste und ich hatte immer wieder überlegt, ihn in die Antennenleitung zu setzen, aber angesichts des hervorragenden Empfangs, sehe ich derzeit keine Notwendigkeit dazu.

Im Empfangsscript (GNURadio) wurde ebenfalls ein wenig etwas verändert. Die RTL-SDR Quelle wurde geändert und zur Synchronisierung ist nun der PC-Takt eingestellt. Seit dem gab es zumindest keine Komplettausfälle mehr, bei denen in der Vergangenheit oft nicht mehr, als ein schmaler Strich vom Satellitenbild zu sehen war. Der Satellit schafft es nun wenigstens über Deutschland hinweg, bevor das Empfangsscript abstürzt, was seit der Umstellung auch deutlich seltener geworden ist. Leider ist es mir dennoch nicht gelungen, vorzeitige Empfangsabbrüche gänzlich zu vermeiden.

[enager]

Und wieder habe ich ein wenig etwas geändert. Bisher liefen die GNURadio-Scripts mit grafischer Oberfläche (GUI - Grafical User Interface). Am Wochenende habe ich dann mal alle Einstellregler aus dem Script heraus genommen und mich auf feste Einstellungswerte festgelegt. Damit laufen die Empfangsscripts auf "no GUI". Die Programme starten nun ohne grafische Oberfläche im Hintergrund und alles was auf den Empfang eines Satelliten hinweist, ist eine deutlich stärkere CPU-Auslastung. Um das dass Empfangsscript nicht durch andere Prozesse gestört wird, macht das Programm für die Wetterdatenauswertung, als auch die Webcam für die Zeit des Satellitenempfangs Pause. Die Webcam zeichnet in dieser Zeit zwar weiter Bilder auf, lädt diese während eines Satellitenüberfluges aber nicht ins Internet. Ähnlich sieht es mit dem Wetterstationsprogramm aus. Dieses nimmt zwar weiterhin Datenpakete vom Sensor-Empfänger entgegen, wertet diese aber nicht aus. Erst wenn der Satellit vorrüber und das aktuelle Sat-Bild auf der Homepage ist, starten Webcam und Wetterprogramm wieder ihre reguläre Arbeit.

Der gestrige Tag zeigte, dass auch dies nicht zu 100% Satellitenbilder führt. Das Empfangsscript beendete die Satellitenaufzeichnung dennoch hier und da vorzeitig. Aber die Zahl der komplett aufgezeichneten Satellitenbilder ist seit dem deutlich gestiegen. Zudem ist der Empfang seit dem Wechsel auf "no GUI" nochmal besser geworden. Klingt komisch, könnte aber sein, dass die Scripts jetzt besser arbeiten, da sie nicht ständig Einstellregler abfragen müssen, ob sich irgendwelche Werte geändert haben. Der Empfang ist inzwischen auf jeden Fall hervorragend. Ich vergleiche meine Satellitenbilder gern mit denen von WRAASE Electronic in Altenholz welche im Gegensatz zu mir, allerdings noch einen ihrer Vorverstärker in der Antennenleitung haben. Dafür das bei mir keinerlei Verstärker in der Leitung sitzen, können sich die Satbilder wirklich sehen lassen. Mehr werde ich ohne Verstärker nicht mehr hinbekommen. Und es reicht mir auch. Selbst vom Meteor-Satelliten bekomme ich inzwischen sogar Bilder, auf denen Grönland zu sehen ist, was im Winter interessant wird, um den dortigen Vereisungsstand nachvollziehen zu können. Auch bei den NOAA-Satelliten komme ich nun weit nach Norden und kann dort soagr den südlichen Teil des Nordmeeres sehen. Besser geht es kaum. Vielleicht ziehe ich den Aufzeichnungsbeginn im Norden von derzeit 3° noch hoch auf 1°. Dann wäre noch etwas mehr Nordmeer zu sehen. Mal schauen in wie fern das Empfangstechnisch sinnvoll ist. Das Nordmeer interessiert mich schon sehr, da der Vereisungsgrad in Skandinavien und nördlich davon, einen entscheidenen Einfluss auf unseren Winter haben kann. Wenn von irgendwo Kaltluft kommen kann, dann meist vom Nordmeer.

[enager]

letzter Akt der Verzweiflung: Neuinstallieren des RTL-SDR Treibers.

Gestern Abend habe ich nun noch eben den RTL-SDR Treiber für Linux neu herunter geladen, kompiliert und installiert. Damit ist der Treiber nun auf dem neusten Stand und sollte aktuelle RTL23832u Sticks deutlich besser unterstützen, als der alte Treiber. Da jetzt auch wieder Satelliten komplett aufgezeichnet werden, werde ich jetzt auch alles so belassen, wie es derzeit ist. Dann geht es eben einfach nicht besser und es kommt immer wieder zu vorzeitigen Aufzeichnungsabbrüchen. Nach all dem, was ich die letzten Tage da herum gebastelt habe um diesen vorzeitigen Empfangsabbrüchen endlichen ein Ende zu bereiten... Der Banana-Pi ist wohl eben nur ein kleiner Minicomputer, auf dem nicht immer alles stabil läuft. Und ein Großteil der Satelliten wird ja auch tatsächlich bis zum bitteren Ende aufgezeichnet. Dann müssen diese Bilder eben reichen. Ich denke dennoch, dass ich mich spätestens im Winterhalbjahr bei machen werde und mit dem Raspberry 3, welcher derzeit nur zuhause herum liegt, noch einen weiteren Satellitenempfänger aufsetzen werde. Sollte das klappen und der Raspberry Pi 3 zeichnet die Satelliten ohne Empfangsabbrüche auf, dann werden sich Banana-Pi und Raspberry-Pi die Arbeit teilen. Der Banana macht dann Wetterstation und Webcam, der Raspberry nimmt die Satelliten in Empfang.

[enager]

Unverhofft kommt oft? Naja, in diesem Fall hat sich "unverhofft" sehr viel Zeit gelassen...

Durch Zufall bemerkte ich, dass der Banana-Pi immer dann die Satelliten vollständig aufzeichnete, wenn ich den USB-PS2-Adapter für Maus und Tastatur nicht wie gewohnt nach der Arbeit am Banana-Pi abzog. Blieb der Adapter dran, wurden die Satelliten nahezu immer bis zum bitteren Ende aufgezeichnet. Zudem habe ich im Internet gelesen, dass der RTL2832u nicht nur oberhalb von 900kSamples/s arbeitet, sondern er hat auch ein kleines Spektrum von 225kSamples/s bis 300kSamples/s. Laut Datenblatt sind auch die Samplerates von 240kS und 288kS mit dabei. Also ran an den Banana-Pi und getestet. Erst mittels

Code: Alles auswählen

RTL_Test -s 240000

getestet, wie viele Bytes bei dieser Frequenz verloren gehen. Erfreulicher Weise gingen keine Bytes verloren. Die 240kSamples können also genutzt werden:



Die Auslastung des Banana-Pi ist mit diesen neuen Programmen auf dem CPU-Monitor (welcher unten rechts, neben der Uhr in der LXDE Desktop-Umgebung zu sehen ist) kaum zu sehen. Einzelne kleine Balken lassen erahnen, dass irgendetwas am laufen ist. Seit dem wurden alle Satelliten vollständig aufgenommen. Wenn dem mal nicht so war, lag es daran, dass ich gerade irgendwelche Versuche an den Empfangsscripten durchführte.

Da es mich schon seit geraumer Zeit sörte, dass der Banana-Pi ohne jegliche Art von Gehäuse aufgebaut war, habe ich mich heute mal bei gemacht und habe ihm ein recht offenes Holzgehäuse gebaut:



Durch die neue Sandwich-Bauweise nimmt er auch deutlich weniger Platz weg, als bisher, wo sich die SATA-Festplatte neben dem Banana-Pi befand. Zudem hat er ein neues Netzteil bekommen. Wurde er bisher mit 5V und 2 Ampere betrieben, so sind es nun 5V und 3 Ampere. Damit hat er jetzt mehr Reserven für Stromhungrige USB-Geräte wie dem RTL-SDR Stick. Denn auch die Sata-Festplatte zieht schon gut Strom. Und 15W Leistungsaufnahme sind nach wie vor nicht sonderlich viel. Weiterhin wurde auch die 3m lange USB-Leitung zum SDR-Stick getauscht, da der Stecker der alten Leitung einen leichten Wackelkontakt an der USB-Buchse des Banana-Pi aufwies. Ich denke, die 3 Punkte:

- neue Samplerate (240kS statt 960kS, wodurch sowohl Banana-Pi als auch SDR-Stick weit weniger ausgelastet sind)
- 3A Netzteil statt 2A, wodurch dem Banana-Pi nun 1A mehr an Strom zu Verfügung steht
- sowie letztlich auch das neue USB-Kabel durch welches der Wackelkontakt beseitigt wurde

düften ingesamt die Stabilität der Satellitenaufzeichnung deutlich erhöht haben. Vermutlich auch unabhängig vom angesteckten USB-PS2 Adapter.

---

Nachtrag 03.07.2017:

Heute habe ich nun den PS2-USB-Adapter mal versuchsweise abgelassen. Trotzdem wurden am heutigen Tage bisher alle Satelliten komplett aufgezeichnet. Demnach hat der PS2-USB Adapter nichts mit der deutlichen Verbesserung zu tun. Damit kommen nur noch folgende Dinge in Betracht:

- das eine Ampere mehr an Strom
- die bessere USB-Leitung
- und natürlich die durch die neue Samplerate, die deutlich geringere Auslastung von SDR-Stick und Banana-Pi.

[enager]

Hallo allerseits,

ich schätze, ich muss hier mal wieder ein wenig was zur Sat-Empfangsanlage schreiben. Ich hatte die gesamte Wetterstation vor einigen Wochen auf 12V Solar umgebaut. Meine bisherige Solaranlage habe ich deutlich vergrößert. Von ehemals 2x 14W Solarmodule auf 2x 160W. Auch der Laderegler wurde getauscht, vom alten PWM Solarladeregler, auf MPPT. PWM-Laderegler arbeiten bei weitem nicht so effizient, wie es MPPT-Laderegler tun. Entsprechend wurde auch die Batterie von 60Ah auf 120Ah verdoppelt.

Sinn und Zweck des ganzen war es, die gesamte Wetterstation (inklusive Raspberrys und Banana-Pi) vom 230V Netz zu trennen und autark am 12V Insel-Solarnetz laufen zu lassen. Das ganze hat auch alles hervorragend funktioniert, trotz Sata-Festplatte am Banana-Pi und damit deutlich höheren Stromverbrauch. Betrieben werden die Raspberrys und auch der Banana-Pi mit solchen 12V-Zigarrettenanzünder-5V-USB Wandlern. Diese sind aber offenbar mit ihren 2A zu schwach für die Sata-Festplatte und den SDR-Stick, welche beide am Banana-Pi hängen. Es läuft alles, kein Thema. Aber der Empfang ist deutlich abgesackt.

Empfang mit 12V-Solaranlage: (NOAA15 25° West)

202107272051-ir.jpg (431.28 KiB) 35591 mal betrachtet

Empfang mit 3A-USB-Netzteil: (NOAA15 38° West)

202107282025-ir.jpg (718.81 KiB) 35591 mal betrachtet

Ich denke, der Unterschied ist deutlich. Mit dem 3A Netzteil für die 230V Steckdose ist der Empfang um Welten besser, als über den 5V-USB-Wandler für die 12V Solaranlage. Ich spekuliere auf einen deutlichen Spannungsabfall, der zwar den Banana-Pi nicht abstürzen lässt, aber den Empfang des SDR-Sticks deutlich schwächt. Entsprechend läuft der Banana-Pi nun doch wieder über 230V Netzteil und 5V/3A auf der USB-Seite.

Fazit: Nehmt für Euren Raspberry Pi oder sonstigen Minicomputer stets das Leistungsstärkste Netzteil, welches Euch zur Verfügung steht. Inbesondere wenn damit Wettersatelliten per SDR-Stick empfangen werden sollen.