Wettersonden jagen = Spielzeug vom Himmel !

[einergehtnochrein]

... Lindenberg: was starten derzeit für Sondentypen dort?

Lindenberg hat nach Auskunft der Berliner Sondensucher auf die RS41 umgestellt!

[firebird]

Putzig ist daran, daß doch Sondemonitor eigentlich die RS41 kennt? Decodierrate trotzdem 0% ...

[andreas6]

Kann am Empfänger liegen. Anwender von Dvbt-Sticks haben damit normalerweise keine Probleme.

MfG. Andreas

[firebird]

Für digitale Spielarten nutze ich meinen alten Icom IC207, das Signal greife ich an der Datenbuchse ab. Bisher habe ich darüber die "bekannten" Sonden empfangen, aber auch andere Dinge, wie AIS, APRS laufen damit problemlos (TX/RX). Da muß ich wohl mal einen DVB-T Stick besorgen und probieren.

Grüße,
-firebird-

[astrohardy]

Beim DVBT-Stick braucht die RS41 NFM statt WFM. Gestern hat auch Idar-Oberstein auf RS41 umgestellt. Übrigens decodiert die neueste Version von Sondemonitor von gestern auch die Meteorologiedaten der RS41.
Hartwig

[EDDS]

Die Idar 0z war laut Freund eines Freundes auch eine RS41.

[astrohardy]

Bevor die SGPs endgültig verboten werden, hier noch rasch eine Spielanleitung, wie man sie ohne Peilen, aber mit dem Zilog-Decoder im RS41/DFM-Stil finden kann.

Hartwig

[Robby_DG0ROB]

Übrigens decodiert die neueste Version von Sondemonitor von gestern auch die Meteorologiedaten der RS41.

Meinst du die Temperatur und den barometrischen Lufdruck oder auch die Feuchte? Ich habe seit vorgestern eine SG-Variante (Wiener Mittagssonde vom 30.3.), die in SM nur Temperatur und Position+GPS-Höhe ausgibt.

[Baummarder]

Ich hätte da mal ein Problem!

SondeMonitor kommt mit verschiedenen RINEX-Dateien klar, beim Zilog Decoder
muss es aber eine bestimmte Art von RINEX-Datei sein.
Ich suche da noch eine RINEX-Datei (Frankfurt/Main) für den 25-12-2016 (14:00)
welche im Zilog Decoder funktioniert.

Unter dem Link - https://www.ngs.noaa.gov/CORS/standard1.shtml - gibt es zwar
eine RINEX-Datei für den bestimmten Tag, welche im SondeMonitor zwar funktioniert,
im Zilog Decoder aber nicht!

Hat da jemand einen brauchbaren Tip für mich?

[zilog80]

Ich suche da noch eine RINEX-Datei (Frankfurt/Main) für den 25-12-2016 (14:00)
welche im Zilog Decoder funktioniert.

Die Daten der einzelnen Stationen enthalten eventuell nicht alle Satelliten, die man vor Ort nutzen moechte.

Ich nehme die Rinex-GPS-Daten von hier:
ftp://cddis.gsfc.nasa.gov/gnss/data/daily/2016/brdc/
(bzw. 2017)
die Dateien, die auf YYn.Z enden (n wie NAVIGATION DATA), muessen natuerlich noch entpackt werden.
Den Tag des Jahres kann man hier Nachschlagen:
navigationservices.agi.com/GNSSWeb/ (wenn die Seite online ist)

25-12-2016 muesste diese Datei sein (Datum/Uhrzeiten stehen auch in der Datei)
ftp://cddis.gsfc.nasa.gov/gnss/data/dai ... 3600.16n.Z

[Baummarder]

Super, vielen Dank für Deine schnelle Hilfe.
Der Link ftp://cddis.gsfc.nasa.gov/gnss/data/daily/2016/brdc/ hat mir sehr weitergeholfen.
Nun kann ich um den „neuen“ Landeort noch mal nach der Sonde suchen.

Nur komisch, dass man nach dem Entpacken der Dateien aus zwei schiedlichen Quellen
die gleichen Dateibezeichnungen bekommt (z.B. brdc3590.16n), die Daten anscheinlich
identisch sind, aber bei der Auswertung nur eine der beiden zu vernünftigen Ergebnissen
führt.

[zilog80]

https://cddis.nasa.gov/Data_and_Derived ... _data.html
Da sind einige Erklaerungen.
Die einzelnen Stationen
ftp://cddis.gsfc.nasa.gov/gnss/data/daily/2016/359/16n/
sollten individuelle Bezeichnungen haben
Die Datei mit brdcDDD0.YYn.Z sollte das gesammelte Endprodukt sein, wo alle Satelliten aufgefuehrt sind.

Hab aber auch schon Quellen gesehen, die mehr als 24 Stunden Daten in einer Datei enthielten und einige Felder nicht gefuellt waren.

[EDDS]

Berlin nun auch RS41

[Lutz]

Bevor die SGPs endgültig verboten werden, hier noch rasch eine Spielanleitung, wie man sie ohne Peilen, aber mit dem Zilog-Decoder im RS41/DFM-Stil finden kann.

Hartwig

Hartwig,
danke für das Bereitstellen einer Windowsversion des Zilog Decoders.

Die RAW Decodierung bzw. Aufarbeitung der Datei "digitalsondexxxxxx.txt" hat prima geklappt.

Mit den WAV-Dateien der eigenen Aufnahmen habe ich keinen Erfolg bzw. mache vielleicht etwas falsch ?

Ich habe WAV Dateien mitgeschnitten einer fliegenden Sonde mit Scanner bzw. Funkgerät und Soundcard im Netbook und externer Soundcard., Aufzeichnung mit Audacity. DVBT-Stick und HDSR, Aufnahme mit HDSR. Ich habe auch verschiedene Pegel versucht.Alle Varianten schreiben live in SondeMonitor einwandfrei mit.
Kein Erfolg mit Zilog. Das Ausgabefile bleibt total leer. Habe ich vielleicht die Sampelrate oder irgendwas anderes falsch?

Gruß
Lutz

[Baummarder]

Hallo –zilog80-,
Danke für alle die Informationen zu dem Thema.
Mit der „richtigen“ Rinex-Datei funktioniert die Auswertung der RS92 Daten mit
Deinem Programm super.
Ich dachte Rinex-Datei ist gleich Rinex-Datei, aber das ist offensichtlich nicht so.
Aber das Thema ist ja nun geklärt.

Anbei ein Vergleich der beiden Rinex-Datei Formate.
Links funktioniert nur im Sondemonitor und rechts in beiden Programmen.

[firebird]

Moin nochmal,

also bei mir ist irgendwo der Wurm drinne ... Ich habe als Empfänger z.Zt. einen AR-8200 von AOR (Bogerfunk) per Diskriminatorkabel am PC, SFM, NFM, SSB,CW ... alle möglichen Arten von Modulation machbar. Also wenn der das icht kann ...
Anstelle Almanachdateien mal Rinex geladen (Quelle: ftp://igs.bkg.bund.de/EUREF/BRDC/2017/). Nun gestern ganz gute Bedingungen zum testen: 401,1Mhz (Prag) perfekt und sofort dekodiert, wie auch andere SGP. Heute morgen die DFM-06 irgendwo aus dem Süden der Slowakei,
Aber keine RS41. Gestern schlug mir die Lindenberger Sonde fast die Anzeige raus -im übertriebenen Sinne- aber SM zeigt weiter tapfer die Dekodierrate 0%. Software ist aktuell, Es ist zum verzweifeln mit den Dingern. Was übersehe ich denn die ganze Zeit?

Grüße!
-firebird-

[zilog80]

Anbei ein Vergleich der beiden Rinex-Datei Formate.
Links funktioniert nur im Sondemonitor und rechts in beiden Programmen.

Kann sein, dass deine Ueberschriften vertauscht sind? Egal, auf jeden Fall ist die Blockanordnung rechts nicht so schoen, fehlen da Zeichen? (Und dennoch rechts funktioniert (cddis.nasa)?)
Habe gerade beide Quellen ausprobiert, bei mir funktionieren beide (auf Linux erstmal). Kann es sein, dass es beim Entpacken von .Z und .gz auf anderen Systemen/mit anderen Entpackern Unterschiede gibt?
Dachte erst, die COMMENTS (links sind schoen alle Stationen aufgelistet) seien zu umfangreich, aber eigentlich ueberlese ich einfach alle bis END OF HEADER.

Muss dazu sagen, dass ich mir beim Einlesen der Rinex/Almanach-Dateien nicht sehr viel Muehe gebe, Eventualitaeten abzufangen. Diese Textdateien werden auch einfach im Textmodus geoeffnet, was auf Windows (nicht Cygwin) ein Problem werden koennte mit dem Zeilenumbruch. Wer mit msvc compiliert, sollte mal versuchen, die Rinex-Datei mit DOS-Zeilenumbruechen zu speichern.

Eine Sache noch, war deine RS92 nicht vom 25.12.? Hatte auch Tag 360 geschrieben, du benutzt jetzt 359? Hab gerade ausprobiert, gibt bei beiden Daten, koennte aber sein, dass die Position mit den 359ner-Daten staerker abweicht. Oben in der Rinex-Datei steht zwar auch ein Datum (wahrscheinlich, wann die Datei erstellt wurde), in den Bloecken fuer die einzelnen Satelliten steht dann aber genauer, welcher Satellit an welchem Tag zu welcher Uhrzeit seine Daten lieferte.

Die RAW Decodierung bzw. Aufarbeitung der Datei "digitalsondexxxxxx.txt" hat prima geklappt.
Mit den WAV-Dateien der eigenen Aufnahmen habe ich keinen Erfolg bzw. mache vielleicht etwas falsch ?

Als erstes wuerde ich die umgekehrte Polaritaet mit -i noch probieren. Und dann ist bei dem Decoder wichtig, dass kein DC-Offset vorhanden ist. In Audacity wuerde man das gut sehen, ob das demodulierte Signal schoen um die Nulllinie pendelt. In sdrsharp hilft bei der Feineinstellung der Frequenz das IF-Fenster.

also bei mir ist irgendwo der Wurm drinne ...
... keine RS41.

Vielleicht mal die Audiodatei zur Einsicht anbieten. In Audacity kann man sich das ganz gut ansehen. Samplingrate von 48kHz ist hilfreich, bei sehr gutem Signal reicht sicher auch die Haelfte. Wenn RS92 funktioniert, sollte auch die Polaritaet stimmen (bei SM irrelevant). Ein Unterschied ist, dass das RS41-Signal immer wieder unterbrochen wird und dann wieder startet. Der dbvt-stick hat damit eigentlich keine Probleme. Eventuelle Audio-Filter scheinen auf die RS92-Dekodierung auch keine Auswirkung zu haben.

[Baummarder]

Hallo –zilog80-,
die Überschriften wurde nicht vertauscht, Großer Header nur SM, kleiner Header beide Programme.
Ich benutze hier Windows 7 (64) ob dass damit zusammenhängt?
Die Rinex-Datei (1brdc3590.16n) mit dem großen Header liefert, bei Deinem Programm,
ein falsches Datum und keine POS-Daten. Mit der Rinex-Datei (2brdc3590.16n) mit dem
kleinem Header sind Datum und POS-Daten ok.
Nachfolgend die Rinex-Dateien mit grossem Header– Entpacker 7zip.

[Baummarder]

... wieso kann man hier nur eine Datei hochladen?

[firebird]

Vielleicht mal die Audiodatei zur Einsicht anbieten. In Audacity kann man sich das ganz gut ansehen. Samplingrate von 48kHz ist hilfreich, bei sehr gutem Signal reicht sicher auch die Haelfte. Wenn RS92 funktioniert, sollte auch die Polaritaet stimmen (bei SM irrelevant). Ein Unterschied ist, dass das RS41-Signal immer wieder unterbrochen wird und dann wieder startet. Der dbvt-stick hat damit eigentlich keine Probleme. Eventuelle Audio-Filter scheinen auf die RS92-Dekodierung auch keine Auswirkung zu haben.

Hihihi, manchmal regelt sich alles mit einem kleinen Denkanstoß
Ich habe wieder den Icom dran, aber den Datenausgang diesmal ordnungsgemäß auf 9k6 anstelle bisher 1k2 festgelegt. Und gerade eben "lächelt" mich das Lindenberger Gespann aus RS41 und C34 über Bad Saarow fehlerfrei an
Läuft ...

Danke!
-firebird-

[zilog80]

Mit windows/msvc das Programm zu bauen war gerade etwas muehsam. Und der msvc macht leider nicht immer alles mit bzw manchmal sein eigenes Ding. Aber eins muss man ihm lassen, er stuerzt bei bugs eher ab als linux/gcc, wo kleine overflow-fehler nicht immer auffallen.
Also da war in der rinex-lesefunktion tatsaechlich noch ein klassischer bug mit einem array, ein Feld zu weit geschrieben, verzaehle mich da gerne. Koennte natuerlich noch mehr davon geben. Werde das ausbessern.

die Überschriften wurde nicht vertauscht, Großer Header nur SM, kleiner Header beide Programme.
Ich benutze hier Windows 7 (64) ob dass damit zusammenhängt?
Die Rinex-Datei (1brdc3590.16n) mit dem großen Header liefert, bei Deinem Programm,
ein falsches Datum und keine POS-Daten. Mit der Rinex-Datei (2brdc3590.16n) mit dem
kleinem Header sind Datum und POS-Daten ok.

Was ich meinte:
In dem Bild steht links Ueberschrift "cddis.gsfc.nasa.gov" und darunter Daten "cors-adm",
und recht Ueberschrift "geodesy.noaa.gov" und darunter Daten "CDDIS"... Aber egal, nicht so wichtig.

Hab das jetzt auch in windows ausprobiert. Mit cygwin/gcc laeuft es wie unter linux.
Mit msvc und im dos-fenster muss man jedoch die rinex-daten als DOS-Textdatei vorliegen haben, sonst gibt es wie vermutet ein Problem. Dennoch funktioniert es auch mit der cddis.nasa-Datei im linux-format... Koennte daran liegen, dass die cddis.nasa-rinexdateien 80-81 Zeichen pro Zeile haben, bei der noaa.cors-Datei endet die "END OF HEADER" jedoch schon nach 74 Zeichen.

Na wie dem auch sei, falls du Windows benutzt, probier es mal mit Rinex-Dateien im DOS-Textformat, d.h. Zeilenumbrueche \r\n statt nur \n.

So: Hab den bug in nav_gps_vel.c (wo rinex gelesen wird) grob ausgebessert. Muss das mal in Ruhe durchsehen, wenn ich Zeit hab. Vielleicht kann man das Einlesen etwas universeller gestalten, obwohl es mir eigentlich reicht, wenn aus auf linux funktioniert.
Nachtrag: Jetzt muesste rs92 rinex-dateien lesen, egal ob linux- oder dos-Zeilenumbruch.

[zilog80]

Am Montag flog die Essener Mittagssonde ueber Koeln.
Konnte den Ballon bis zum Platzen beobachten, ploetzlich war er weg. War auch Zeit, der Nacken schmerzte schon und man verliert den kleinen Punkt auch leicht aus den Augen. Hier ein Foto freihand leicht verwackelt, etwa 29km Hoehe:

100% crop. 200mm Brennweite, Pixelbreite des Sensors etwa 4.7µm. Freihand wackelt der Ballon ziemlich im Sucher...

Wollte den Ballon natuerlich nochmal von nahem sehen:

[astrohardy]

Saubere Aktion!

[astrohardy]

Moin
Aus Zeven fliegt gerade ein Tandem von 2 DFMs weit nach Süden: Landung bei Ottbergen südl. von Höxter. 51.704205, 9.308711
Hartwig

[zilog80]

Sind das aus Schleswig jetzt auch RS41? Hat das Dienstag angefangen?

[Robby_DG0ROB]

Ja, das war der dritte Standort in DL. Mit den Sonden erfolgt auch der Übergang zur Sondierung beim Abstieg, wie man weiter lesen konnte. Damit sind Abschaltmechanismen in DL kein Thema und auch Fallschirme wird es weiterhin geben. Mit der RS41 haben sich auch die Schnurlängen etwa verdoppelt und betragen nun knapp 60 m.

[zilog80]

Die burst-Abschaltung kenne ich zur Zeit nur noch aus Italien. In Mailand und Udine werden noch aeltere RS41-SG benutzt. Bologna startet nachts neuere RS41-SGP und mittlerweile haben die schon die neue Firmware, bei der die default-Abschaltzeit auch bei BK01 so lang ist, dass die beim Abstieg noch lange senden. Bei Sonden mit fw 0x4ef5 sollte burst-kill wahrscheinlich keine Rolle mehr spielen.

Hab die RS41, die in DeBilt gestartet sind und nach sued-osten flogen, bisher in der Regel nachts gesucht, da sieht man meist nicht viel von der Gegend. Heute startete eine RS41-SGP aus den Niederlanden auch am Mittag und landete bei Moenchengladbach.

Die Schnur ist auch hier ziemlich lang. Den roten Schirm kann man erahnen zwischen Baum und Schnur. Habs nur in Google nachgemessen, etwa 50m.

Die Ozon-Varianten sind kuerzer, vor allem Uccle/Belgien. Wenn sich die in Baeumen verfangen, dann meist ganz oben.
Diese RS41 haette fast auch wieder eine Stromleitung erwischt. Der Schirm lag kurz davor.

[derTom]

Hallo,

der DWD plant eine Veröffentlichung der Positionsdaten seiner Radiosonden (aus einem eMail-Wechsel mit dem Deutschen Wetterdienst, Abteilung Messnetze und Daten in Offenbach):

"Der DWD beabsichtigt zukünftig die Sondenflugbahnen der Radiosonden und die letzte empfangene Position auf der DWD-Seite im Internet darzustellen. Die Planungen hierzu laufen, sodass dies im Spätsommer 2017 zur Verfügung stehen sollte."

Gruß
Tom

[Durango]

Die Wetterstationen wurden schon von Amateurfunkern besucht, stellenweise auch Gruppenführungen.

Bislang berichtete man, das das Bodenpersonal zwar alle Daten der Sonde sieht, aber nie die Position !

Anderseits wäre die Datenerfassung während des Fallens soviel wert, wie ein zweiter Sondenstart, weil Ort und Zeit sich geändert haben.
Verwertbar aber nur innerhalb des DWD, da die Daten, die in das internationale Netz eingespeist werden, zu einem fest vorgegbenen Termin erwartet werden.
Also bei 0 oder 12 Uhr UTC mussen die Daten vollständig vorliegen. Das sieht man dann im Qualitätsprotokoll, ob die Meldung rechtzeitig kam.

Bei der Qualität der Antennen des DWDs und seinen tiefliegenden Standorten sehe ich keine Verbesserung gegenüber wetterson.de .

Der holländische Wetterdienst ist schon seit längeren daran interressiert, die Daten des Abstieges zu bekommen. Hier konnte schon öfters bei Weitfliegern geholfen werden.
Irgendwie können die auch die Rohdaten von SondeMonitor verarbeiten.

73 Manfred

[pedda]

Hallo Sondenhunter

ich bastelle gerade ein wenig an einem IceCast-Server zum Streamen von Wettersonden mit einem etwas modifzierten RTL_Airband (von github).
RTL_Airband lasse ich 48khz mp3 streamen und habe den NFM-Bereich vom 16khz Raster (was eh falsch ist) auf 10khz modifiziert.
mit RTL_Airband kann ich 4-5 RS92 Sonden mit einem RTL-Stick gleichzeitig hören und in mein Netzwerk streamen.
Nun versuche ich das ganze mit den Tools von Zilog RS92 zu decodieren, was für den GPS Bereich auch funktioniert.
Mein Ziel ist es diese ebenso wie mit meinem Sondemonitor-VBS-Script an aprs.fi (ich bin Amateurfunker) zu tracken -- habhub.org wäre vielleicht noch interessanter --

Jetzt meine Frage:
Welches tool aus den Sourcen von zilog ist das richtige, damit sowohl gps als auch Telemetriedaten gleichzeitig rauskommen?
Kompiliert habe ich glaube ich so inzwischen alles

Schon mal Danke!!

Peter
-----
Weitereführende Links:
http://www.sigidwiki.com/wiki/Vaisala_R ... adiosonde)
mein Sondemonitor-VBS-Tracker für aprs https://peges.de/afu/smtracker/

[pedda]

ich glaube ich habe mein Problem bereits selbst endeckt. hatte eine zu alte Version von rs92gps.
Neu von github gezogen und schon ist da fast alles, was ich vermisst habe

Peter

[Mike320]

Hallo Sondenhunter
...
Mein Ziel ist es diese ebenso wie mit meinem Sondemonitor-VBS-Script an aprs.fi (ich bin Amateurfunker) zu tracken -- habhub.org wäre vielleicht noch interessanter --
---

Bitte korrigiere dein VBS-Skript zunächst erst einmal und halte dich bitte an die APRS Konventionen (http://www.aprs.org/) und API-Standards (http://www.aprs.org/aprs12.html).

Nur auf den ersten Blick, was schon sehr vielen im Distrikt H aufgefallen ist und sich bisher nie geändert hat:
- das Skript verwendet falsche Rufzeichen, oder laßt ihr alle diese gegateten Ballons selbst fliegen? Nein -> also handelt es sich um ein APRS-Objekt und das besitzt eine eindeutige Kennung, die Sondenummer!
- der APRS-Path ist ungültig und entspricht nicht den Protokoll-Konventionen (auch NET-Pakete werden von HF-Gateways u.U. gedigipeated!)
- die verwendete(n) APRS Message Destination(s) sind ungültig (http://aprs.org/aprs11/tocalls.txt)

Seit Jahren überträgst du und deine Mitstreiter nicht nur unschöne Tracks (kennt ihr wirklich keine bessere Rinex-Quelle?), sondern leider immer wieder ungültige und nicht protokollgerechte Daten.

Warum beteiligt ihr euch nicht am Bremer Netzwerk, die OM's zeigen, wie es richtig und koordiniert funktioniert, die zusätzlichen (fehlerhaften) Tracks mit euren Calls vermißt hier im Norden wirklich niemand.

[andreas6]

Bitte locker bleiben und Fehlgriffe verzeihen. Das ist nur ein Hobby, wir führen hier keinen Krieg. Da darf mal auch mal etwas daneben gehen. Das Medium Aprs steht prinzipiell jedem Benutzer zur Verfügung.

MfG. Andreas

[uxlaxel]

moin, ich weiß nicht, ob die frage schon mal aufkam oder gar beantwortet wurde: warum haben manche sonden einen so langen strick zwischen fallschirm und sonde? dass das nicht grundlos passiert, davon gehe ich erst mal aus. 73!

[xoexlepox]

warum haben manche sonden einen so langen strick zwischen fallschirm und sonde?

Sehr interessante Frage deren Antwort auch mich interessieren würde. Ein längeres Gebilde pendelt langsamer, aber warum sollte dieser Effekt sinnvoll sein?

[zauberkopf]

Vermutlich, damit der Fallschirm nicht so leicht zusammenfällt.
Das gibt Fallschirmspringer immer wieder einen ordentlichen Adrenalin-kick.

[Durango]

moin, ich weiß nicht, ob die frage schon mal aufkam oder gar beantwortet wurde: warum haben manche sonden einen so langen strick zwischen fallschirm und sonde? dass das nicht grundlos passiert, davon gehe ich erst mal aus. 73!

Der lange Faden zwischen Sonde und Ballon soll die Einflüsse auf die Meßwerte so gering wie möglich halten.

Eigentlich ist in der Meterologie der Ballon nur ein Störfaktor. Er absorbiert die Sonnenstrahlung und schirmt Kondensfeuchte ab.

Deshalb werden Schnüre mit 30 bis 55 m länge benutzt.

73 Manfred

[Robby_DG0ROB]

Warum es genau diese Längen sind, hängt mit den Empfehlungen der WMO zusammen. Selbst bei den Bedarfssondierungen mit DFM oder Pilotsonden und den kleinen 100 g Ballonen (< 18 km Höhe) werden die bekannten 30m-Schnüre verwendet.
Zu den Störeinflüssen auf die Sondierungen gibt es die Jahrzehnte über unzählige Studien und Doktorarbeiten. Allein der Strahlungsfehler auf die Temperaturfühler und dessen systematische Berücksichtigung auf die Messungen bei Tag ist eine Wissenschaft für sich.

[astrohardy]

Habe am Wochenende mal eine der Schleswiger RS41 gejagt und auch mal die Meteorologiedaten, die Sondemonitor ja jetzt ausspuckt, angeguckt.
Mehr hier

Hartwig

[astrohardy]

Offenbar startet Nürnberg gerade mal wieder eine DFM mit alternativem Datenformat. Meine Modifikation des Zilog-Decoders könnte das richten.
http://www.astrohardy.de/radiosonde/zil ... chrott.zip
Viel Glück

Hartwig

[Andreas_P]

Sehe ich das richtig, das Nürnberg vier Sonden gestartet hat?

[astrohardy]

Du meinst nicht die 4 konventionellen DFMs aus Grafenwöhr?
Hartwig

[Andreas_P]

Ja, genau die vier.

[Robby_DG0ROB]

Aus Nürnberg kamen am Morgen zwei, die an einer Bambusstange auf Abstand gehalten wurden und hinter Plattling niedergingen; am Nachmittag, etwa zur gewohnten Zeit, ein weiteres Doppel, welches bei Eggenfelden den Boden erreichte.

Die 6 Übungsplatz-Sonden waren wieder unsinnigerweise mit Abschaltung; gestartet im Stundenabstand und nach ca. 60 Minuten verstummt. Trotz der wenigen Sonden, ausreichend Entfernung und zeitlichem Abstand. Letztes Jahr, Ende September, flogen sie ohne Timer und sind an einem Tag direkt auf dem Übungsplatzgelände gelandet - natürlich nicht zugänglich. Wahrscheinlich konnte selbst die ÜbTruppe wegen dem Scharfschießen seinerzeit die Sonden nicht aufsuchen und abschalten - daher womöglich der Befehl, immer Timer zu setzen.

[pedda]

Bitte korrigiere dein VBS-Skript zunächst erst einmal und halte dich bitte an die APRS Konventionen (http://www.aprs.org/) und API-Standards (http://www.aprs.org/aprs12.html).

Nur auf den ersten Blick, was schon sehr vielen im Distrikt H aufgefallen ist und sich bisher nie geändert hat:
- das Skript verwendet falsche Rufzeichen, oder laßt ihr alle diese gegateten Ballons selbst fliegen? Nein -> also handelt es sich um ein APRS-Objekt und das besitzt eine eindeutige Kennung, die Sondenummer!
- der APRS-Path ist ungültig und entspricht nicht den Protokoll-Konventionen (auch NET-Pakete werden von HF-Gateways u.U. gedigipeated!)
- die verwendete(n) APRS Message Destination(s) sind ungültig (http://aprs.org/aprs11/tocalls.txt)

Seit Jahren überträgst du und deine Mitstreiter nicht nur unschöne Tracks (kennt ihr wirklich keine bessere Rinex-Quelle?), sondern leider immer wieder ungültige und nicht protokollgerechte Daten.

Warum beteiligt ihr euch nicht am Bremer Netzwerk, die OM's zeigen, wie es richtig und koordiniert funktioniert, die zusätzlichen (fehlerhaften) Tracks mit euren Calls vermißt hier im Norden wirklich niemand.

Na denn. Danke für den Hinweis. hat bis jetzt noch keiner getan. Die Daten stimmen im übrigen recht genau. Ja, nicht so genau wie Rinex. Ich benutze Almanach und nicht Rinex.
Ich liefere die Daten aus Rücksicht zu den Bremern extra nicht mit der entsprechenden Sondenummer ein.
Und ich/wir betreiben das völlig egoistisch. Aus Spass am Sonden suchen.

[Durango]

Da gibt es doch Funkelamateure im OV Northeim, die zwar wegen der Tallage nix empfangen können, aber trotzdem die Sondendaten mit 500 m Fehler ins APRS einspeisen.

Seit Jahren werde ich darauf angesprochen, aber ich kann nur antworten: Die wissen was sie tun und haben sogar das Programm für die Sonde in APRS geschrieben.

Keiner weiss, warum APRS mit falschen Daten zugemüllt wird, aber der OV Northeim hat seinen Spass dabei.

Evtl, sollte mal Jemand dahin fahren, und sie ins jahr 2017 bringen. Robby, deine Aufgabe.

73 Manfred

[pedda]

Hallo Manfred,

auch Dir die bitte, falls du etwas Konstruktives zur Verbesserung meines VBS-Scripts hast, bitte Email an mich.
Danke.
Hoch Interesssant ist übrigens dass ich/wir mit diesen "Falschen" Daten schon eine Kiste voller Wettersonden gesammelt habe
Es steht übrigens jedem offen die Daten bei APRS einzuliefern. Explizit habe ich den "Test" Modus gewählt.

Nach der Kritik hier, habe ich zumindestens mein Sondemonitor gestern mal auf Rinex umgestellt.
Mal gucken ob es besser wird.

73' Peter

[pedda]

....
Keiner weiss, warum APRS mit falschen Daten zugemüllt wird, aber der OV Northeim hat seinen Spass dabei.
...
Evtl, sollte mal Jemand dahin fahren, und sie ins jahr 2017 bringen. Robby, deine Aufgabe.

wenn ich nun die APRS-Daten, wie gesagt, ab 0 Uhr bei mir Rinex, vergleiche:
2017-04-12 08:20:55 CEST: DB1OFH-11>TEST,TCPIP*,qAR,DB1OFH:@062040h5158.29N/01124.32EO135/068/A=024450 SondeID:K4953471 [405.70MHz] GPSAlt:7452,39m P-Alt:7993,54m Spd:34,98m/s Clb:-7,88m/s P:0,00hPa T:0,00oC U:0,00% FN:6479 

2017-04-12 08:20:43 CEST: DL0PTB-11>APLWS2,qAU,DL0HT-10:;K4953471 *062041h5157.73N/01125.16EO134/066/A=023851!wyQ!Clb=-7.3m/s p=399.2hPa t=-31.9C h=64% 405.70MHz ...powered by dxlAPRS

stellt sich die Frage, wer macht den Rundungsfehler in den Koordinaten. Mein VBS-Script oder dxlAPRS
Leider kann man bei den Daten aus Bremen die Frame-Number nicht sehen.

Nachtrag:
Ich lasse jetzt mal sm2aprs parallel dazu laufen und verseuche APRS noch einmal mehr mit DB1OFH-12
Die Rinexdaten werden im Sondemonitor-Script kurz vor Beginn der Aufzeichnungen aktualisiert
-------------------schnipp___Sondemonitor-Script
....
wait until 12:50:00
arm 52.815165 9.925955 1013.2 rinex rinex.txt 3D
start
wait for 04:00:00
stop
____________schnapp----------------------------------

Peter

[pedda]

Hallo Manfred, Hallo Mike320,

Mal wieder auf der Sachebene:

Mein Test mit Sonde K4953472 via Sondemonitor mit SM2APRS und meinem VBS-Tool sagt aus,
dass meine Datenlieferungen an APRS RICHTIG sind. Die Unterschiede ergeben sich aus Nutzung des Almanachs anstatt Rinex.
Das heißt, dass mein VBS-Code korrekt für Sondemonitor funktioniert.
Leichte zeitliche Abweichungen ergeben sich durch das Streaming über Icecast (3s Versatz). Aber ich betreibe ja auch Versuchsfunk und teste Dinge, die andere nicht ausprobieren
und schreibe lustige Tools unter Linux und Windows.

@Mike320: Die Anleitungen von aprs.fi hatte ich mir im Vorfeld, bzw beim Erstellen des Scripts angesehen
Nachdem ich vergeblich versucht habe Kontakt mit den Entwicklern dort aufzunehmen um ein eigenes Protokoll zu bekommen,
bin ich zum Entschluss gekommen, das über "TEST" einzuliefern.

Kurzprotokoll des Trackings :
===========================================
Protokoll (MESZ):
Umgebung: Sondemonitor bekommt Daten via VLC vom Icecast-Stream auf virtuelles Audio Device (Windows 7 x64 virtuell)
von modifiziertem rtl_airband auf einer Linux-Maschine mit NESDR-Smart RTL-Stick. Rinex-Daten werden nur kurz vor dem Start des Trackings
automatisch aktualisiert.


13.04 MESZ Rinex manuell aktualisiert
13.06 Höre die Wettersonde auf 145700 im Rauschen (ab ca. 8500m kann die Wettersonde aus Bergen höhren)
13.10 Signal wird lauter, aber immer noch im Rauschen
13.14 Sondemonitor fängt an sich zu kalibrieren
13.16 SM2APRS und vbs-Script senden Daten
13.34 rinex-Daten manuell aktualisiert
13.58 Abweichungen zum Kurs der Bremer festgestellt
14.00 rinex-Daten manuell aktualisiert
14.02 Kurs weicht trotzdem weiter ab.

=====================================================

und noch ein Nachtrag:
Das Programm sm2aprs erzeugt eine ungeheure Netzwerklast, so das meine VDSL-Leitung in Senderichtung ziemlich dicht war. Das ist mir vor 3 Jahren schon aufgefallen. Das Progrämmchen
macht immer den ET (nach Hause telefonieren). Das war der ursprüngliche Grund was eigenes zu schreiben.

73' Peter (d)Bastard(1)OperatorFromHell

[Durango]

Hallo Peter,
wenn jemand zu Hause die falschen Daten für sich persönlich darstellt, ist mir das egal.

Bei der Darstellung im APRS sieht dann leider die ganze Welt den Fehler.

Also: Immer aktuellen Rinex 3-D nehmen. Antennen müssen einen Mindeststandard beim Rundumblick ermöglichen.
Na klar bin ich schon vor deinem QTH entlang gefahren, das geht ja gar nicht !

Dann habt ihr den Fokus immer auf die falschen Sonden ! Wenn Essen bei euch einschlägt, trackt ihr Bergen !

Darum verstehe ich erst jetzt, warum ich bei einer Sonde, die bei der Northeimer Seenplatte gelandet ist, und ich erst die Fahrt nach der Landung antrat, Erfolg hatte.

Hatte immer darauf gehofft, jemand von euren OV direkt bei der Sonde zu treffen, aber Fehlanzeige. Da ist der Bruno aus OHA öfters unterwegs !

73 Manfred