Wettersonden jagen = Spielzeug vom Himmel !

Der chaotische Hauptfaden

Moderatoren: Sven, Heaterman, TDI, Finger

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon astrohardy » Sa 16. Dez 2017, 08:47

Momentan verlängert sich meine Baumlanderliste ständig, nachdem ich monatelang alles mögliche im tiefsten Wald in erreichbarer Weise vorgefunden habe.

Kommentar zu der Demod-Version des Zilog-Decoders: Habe mir die RS41-Version mal kompiliert und ein mit der alten Version nicht gut funktionierendes WAV per SOX eingefüttert, und das funktioniert sehr gut, erheblich besser als die alte RS41-Version. Habe mal eben mit SM verglichen. Beide funktionieren vergleichbar gut.

Muss es noch einmal mit der RS92 ausprobieren.
Hartwig
astrohardy
 
Beiträge: 128
Registriert: Fr 2. Sep 2016, 22:38

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zilog80 » Sa 16. Dez 2017, 10:28

Fuer die rs41 hab ich schon eine Version eingestellt, die deutlich weniger den Rechner belastet. Die erste Runde war der ganz naive Ansatz, die Correlation fuer die Synchronisation fuer jedes Sample durchzufuehren. Das bedeutet bei langen Sync-Woertern (und wie empfohlen hoher Sampling-Rate) ziemlich viel Rechenarbeit. Correlation ist ja wie Faltung, da kann man den "Umweg" ueber Fourier-Transformation gehen. Wenn man das ganz naiv macht, ist der Aufwand vergleichbar. Allerdings mit der FFT spart man da ab einer gewissen Sync-Laenge deutlich ein. Probier also auch mal die "_dft"-Version fuer die rs41: rs41dm_dft.c, demod_dft.c.

Werde das dann die Tage auch fuer die rs92 und dfm umstellen. Die rs92 hat kein so geeignetes Sync-Wort, am Anfang wiederholt sich einiges. Ist schon deshalb besser, das zu kuerzen, damit die Correlation einen besseren Peak ergibt. Aber sind ziemlich viele Samples, da wird die dft-Methode deutlich schneller sein.
Die dfm hat nur ein kurzes Sync-Wort, auf einem schnellen Rechner wird man das vielleicht kaum merken.

Etwas mehr Speicher brauchen die Version allerdings schon als frueher, aber sollte heutzutage kein Problem sein.
Man braucht nun auch keine lowpass-Filter mehr. Kann sogar stoerend sein, im Grunde wird dadurch die "Aufloesung" geringer. Wenn man viele "Spikes" hat (vielleicht eine Empfaenger-Sache), koennte es vielleicht helfen, dann aber nicht so niedrig wie frueher. Also rs41/rs92 vielleicht 6000, dfm 4000. Meist wird man das aber nicht brauchen.
zilog80
 
Beiträge: 305
Registriert: So 31. Aug 2014, 14:08

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Radiosonde » Di 19. Dez 2017, 23:08

Kann man eigentlich Daten auf Wetterson.de hochladen oder ist das irgendwie privat geregelt?Es gibt nämlich keinen Standort in Österreich,was ich persönlich schade finde meist werden Sonden nur in 1500-2000m Höhe dekodiert...Ich stell mir nur grad einen über 2000 m hoch gelegen Standort mit original Vaisala Antennenpilz (oder QFH Antenne nach R.eu..)und ein paar Yagis vor,die Reichweite denke ich währe enorm.
LG
Radiosonde
 
Beiträge: 23
Registriert: Mo 9. Okt 2017, 15:33

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Lutz » Do 21. Dez 2017, 11:48

@Radiosonde

geh doch einfach mal auf der Wettersondenseite auf das Impressum oder nimm gleich die dort angegebene Adresse mail@wetterson.de
und frage wegen einer Teilnahme am System nach. Da wird Dir sicherlich geholfen.

Gruß
Lutz
Lutz
 
Beiträge: 15
Registriert: Mo 20. Mär 2017, 09:40

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon asg » Mo 25. Dez 2017, 23:40

zilog80 hat geschrieben:Fuer die rs41 hab ich schon eine Version eingestellt, die deutlich weniger den Rechner belastet.

Naja...

wc -l zählt die Zeilen in denen lat vorkommt
Zeitmessung:
a=$(expr $(date "+%s"))
./rs41...
e=$(expr $(date "+%s"))
d=$((e-a))

Norderney3.wav Aufnahmedauer: 3334 Sekunden, sample_rate: 48000, bits: 16, channels: 1

./rs41ecc -v --crc --ecc --res Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 1479 in 8 Sekunden

./rs41ecc -v --crc --ecc -b Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 506 in 8 Sekunden

./rs41ecc -v --crc --ecc Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 1462 in 7 Sekunden

./rs41dm -v --crc --ecc Norderney3.wav | grep lat | wc -l
Anzahl: 2094 in 335 Sekunden (aber: alle lat-Zeilen, auch die ohne Framenummer/Zeit)

./rs41dm_dft -v --crc --ecc Norderney3.wav | grep lat | wc -l
Anzahl: 2093 in 252 Sekunden (aber: alle lat-Zeilen, auch die ohne Framenummer/Zeit [Anzahl: ~40])

Die _dft-Version schafft das in 75% der Zeit ggü. der !_dft-Version. Aber 245 Sekunden mehr Rechenzeit bei 3330:1479 zu 3330:2093 ist schon heftig,
Dazu kommt noch, dass sich die Sonde im Fall immer weiter meinem Standort näherte, der Vorteil sank weiter.
Trotzdem, bei schlechtem Empfang eine sehr gute Umsetzung. Weiter so zilog80 :D.

Und jetzt zum Quellcode demod_dft.c.

bufs = (float *)calloc( M+1, sizeof(float)); if (bufs == NULL) return -100;
match = (float *)calloc( N+1, sizeof(float)); if (match == NULL) return -100;
xs = (float *)calloc( M+1, sizeof(float)); if (xs == NULL) return -100;
qs = (float *)calloc( M+1, sizeof(float)); if (qs == NULL) return -100;
rawbits = (char *)calloc( N+1, sizeof(char)); if (rawbits == NULL) return -100;
usw.
Warum immer einen mehr?

//Warum, hat doch calloc aufgerufen for (i = 0; i < M; i++) bufs[i] = 0.0;
//Warum, hat doch calloc aufgerufen while (i < N_DFT) m[i++] = 0.0;
asg
 
Beiträge: 14
Registriert: So 25. Sep 2016, 19:39

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zilog80 » Di 26. Dez 2017, 01:03

asg hat geschrieben:Norderney3.wav Aufnahmedauer: 3334 Sekunden, sample_rate: 48000, bits: 16, channels: 1

./rs41ecc -v --crc --ecc --res Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 1479 in 8 Sekunden

./rs41ecc -v --crc --ecc -b Norderney3.wav | grep lat | wc -l (Die Version mit ka9q-fec)
Anzahl: 506 in 8 Sekunden


Ist es mit dem -b soviel schlechter? Bei mir ist es umgekehrt. (Es sei denn, die Sampling-Rate ist niedrig (22k oder weniger), dann wird's mit dem -b nicht so gut. Aber 48k ist eigentlich gut.) Denn dann muessten auch die dm/dm_dft-Versionen Probleme haben. Das Lesen der weiteren Bits ist da eigentlich wie mit -b, nur das Erkennen des Frame-Beginns ist anders. Da kommt der Gewinn bei schlechtem S/N, da erkennt die alte Methode nicht immer den Header.
Wenn das Signal schlecht ist und die neue Version den Frame dennoch erkennt (die alte jedoch nicht), dann kann es aber durchaus sein, dass das Rauschen zu gross ist fuer eine Fehlerkorrektur, aber dennoch einzelne Bloecke noch einen korrekten CRC-Wert liefern und ausgegeben werden.

Ach, was sein kann, wenn du noch die alte Variante mit dem Reed-Solomon von ka9q verwendest, dass da die kurzen Standardframes mit 320 byte bei -b nicht richtig erkannt werden, und dann ist die Fehlerkorrektur oft nicht viel wert. Hab das zumindest in der rs41ptu.c umgebaut, das sollte da unabhaengig von Sampling-Rate oder aehnlichem zuverlaessiger erkannt werden. Probier es vielleicht auch mal mit der rs41ptu (ist wie rs41ecc nur mit Temperatur (--ptu)).

Das Problem bei der rs41 ist nun aber, dass zwischen den Frames recht viel Pause ist. Und die grosse Rechenlast kommt in der Zeit, wo er den naechsten Frame sucht. Hab bei der rs41 am Ende des Frames erstmal soweit vorgespult, dass er noch weiter bits liest bis zur maximal moeglichen Framelaenge von 518 bytes. Man koennte auch genauer bis zum vermuteten naechsten Frame-Beginn springen oder nach der Sync-Preambel Ausschau halten (wo sich die Varianz des Signals deutlich verbessert/verkleinert), die es jedoch bei den alten rs41 noch nicht gab. Und wenn man die Frequenz zu einer anderen rs41 wechselt, verpasst man vielleicht was.
Schlimm wird es halt, wenn man gerade kein Signal empfaengt und der Decoder nach einer rs41 sucht...

Also das war so der erste Entwurf, da kann man vieles feiner abstimmen. Merke das gerade bei der M10. Im Prinzip kann ich das ganz aehnlich machen wie bei den anderen Sonden. Da ist der Frame nur etwa 1/4 sek lang, allerdings alle 10 sek gibt es einen Doppelframe (den man nicht unbedingt braucht). Ziemlich viel Leerlauf, wo der Correlator heisslaeuft... Die Bitrate ist dort hoeher, da war dann sehr hilfreich, den dc-Offset zu korrigieren, die Daten dazu werden ja eh berechnet. Da koennte vielleicht aber auch noch helfen, dass man aehnlich wie mit der --res Option die Startposition auch zwischen zwei Samples festlegen kann, vielleicht mindert das den Quantisierungsfehler bei kleiner Sampling-Rate. Hab das noch nicht ausprobiert.

Einerseits haette ich gerne fuer alle 4 Sonden moeglichst das gleiche Verfahren, andererseits hilft es dann doch manchmal, spezielle Eigenschaften der einzelnen Sonden zu beruecksichtigen.

asg hat geschrieben: bufs = (float *)calloc( M+1, sizeof(float)); if (bufs == NULL) return -100;
usw.
Warum immer einen mehr?
//Warum, hat doch calloc aufgerufen for (i = 0; i < M; i++) bufs[i] = 0.0;

Weiss, das calloc sollte eigentlich alles auf Null setzen. Und eigentlich sollte das bei nem float/double auch 0.0 bedeuten. Die Initialisierung wird aber nur einmal vorgenommen, da ist es eigentlich egal. ob man nochmal Werte zuweisst. Weiss auch nicht, ob ich konsequent alles initalisiert habe.
Ach, das +1 ist einfach nur ein minimaler Zusatzschutz, bei N=600 oder mehr spielt das dann keine Rolle. Eigentlich sollte ueberall mod N bzw. M zugewiesen oder gelesen werden. Hab mir auch noch nicht ueberlegt, wieviel von dem "delay" ich eigentlich wirklich brauche, dachte da erst an etwas anderes.

Bei der Dimensionierung von N, K und M kann man im Einzelfall, wenn man die Bitrate vorher kennt, auch optimalere Werte finden. Am besten, man braucht pro Frame nur einen FFT-Durchlauf, d.h. man ist schon ziemlich genau am Frame-Beginn und das K-Fenster ist gross genug, um den Peak zu finden, der den Header anzeigt.

Bei guter Signalqualitaet und langsamen Computer ist die Nulldurchgangsmethode wohl am einfachsten. Wenn man die Signalqualitaet zuverlaessig messen kann, koennte man zwischen den verschiedenen Methoden hin- und herschalten. Oder wenn die Decodierung ausbleibt, das ganze nochmal mit der aufwendigeren Methoden.. Am besten hat man dann Samples fuer mehrere Sekunden im Buffer. Wird dann natuerlich ein ziemlich grosses All-In-One-Paket. Das Paket, das in jeder Situation optimal funktioniert, ist wahrscheinlich auch nicht so einfach zu bauen. Deshalb stell ich erstmal die verschiedenen Varianten nebeneinander, auch wenn die Auswahl dann etwas unuebersichtlich wird. Dann kann erstmal vergleichen. Nicht bei jeder Sonde hat man immer den gleichen Gewinn. Z.B. bei Sonden ohne Fehlerkorrektur (oder nur geringer wie bei der DFM) hat man bei schlechtem Signal selten vollstaendig korrekte Frames, insbesondere wenn der Frame gerade noch mit Correlation erkannt wird. Da gefaellt mir die rs41 doch am besten.

NACHTRAG:
Wenn man das Fenster K von N/2 auf z.B. 2N erhoeht und einen etwas groesseren Buffer in Kauf nimmt, halbiert sich die Rechenzeit beinahe. (So sollte es auch sein, da kommt der Vorteil der schnellen Fouriertrafo zur Geltung.) Eigentlich muesste man diese Parameter fuer jede Bitrate/Sampling-Rate/Sonde bestimmen, um den FFT-Buffer vernuenftig auszunutzen. Haengt aber auch davon ab, wieviel Speicher man zur Verfuegung stellen will.

Die Zeit, die fuer die Verarbeitung von einer festen Anzahl Frames gebraucht wird, haengt natuerlich auch davon ab, wie oft er Fehler korrigieren muss und dadurch mehr Arbeit hat. Gerade wenn man dann noch mehrere Fehlerkorrekturrunden einbaut. Grob gesagt, wenn man mehr aus einem schlechtem Signal rausholen will, muss man meist auch mehr Aufwand treiben.

Um die verschiedenen Methoden zu vergleichen, muesste man eigentlich eine konstante S/N haben und Statistik treiben, wieiviel Fehler jeweils die Dekoder machen. Grob kriegt man mit der Anzeige in sdrsharp zum Beispiel einen Eindruck. Mit der alten Methode bekomme ich bei der rs41 Frames (wenn auch mit Fehlern) etwa bei 12dB ueberm Rauschen, mit der neuen etwa mit 10dB. Ist aber sehr grob. Bei der dfm mit der niedrigen Bitrate geht es oft schon bei 6dB los, dann haeufiger mit Fehlern, frueher waren so 9dB noetig, Das Verhaeltnis korrekte/fehlerhafte Frames ist dann jedoch schlechter. Besser waere es, einem sauberen, halbwegs konstantem Signal kuenstlich Rauschen hinzuzufuegen und dann die Fehler zu zaehlen. Dann koennte man parallel auch das saubere Signal ohne Fehler korrigieren und weiss, wo tatsaechlich Fehler auftreten.
Bei der rs41 bekommt man immerhin schon einen Eindruck, wenn man sich die Anzahl korrigierter Fehler ausgeben laesst.

asg hat geschrieben:Zeitmessung:
a=$(expr $(date "+%s"))
./rs41...
e=$(expr $(date "+%s"))
d=$((e-a))

In Linux gibt es auch "time", einfach vor das Kommando schreiben, das man messen will: time ./rs41...
zilog80
 
Beiträge: 305
Registriert: So 31. Aug 2014, 14:08

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon astrohardy » Mi 27. Dez 2017, 00:11

Ich habe mal ein paar Windows-Versionen kompiliert. OK, mein Notebook ist relativ schnell (i7, 16 GB), aber ein Soxpipe-Betrieb ist sehr gut möglich. Die Zahl der erkannten Frames ist speziell bei der RS41 ERHEBLICH besser als bei der alten Version. Kein Unterschied zu SM oder sogar besser. Die RS92-Version werde ich hinfort zur Lokalisation gelandeter Sonden benutzen, anstelle eine WAV-Datei oder eine SM-Rohdatei zu verarbeiten.
Tolle Sache
Hartwig
astrohardy
 
Beiträge: 128
Registriert: Fr 2. Sep 2016, 22:38

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon reutron » Mi 27. Dez 2017, 09:25

Irgend wie mach deine Antennenanordnung führ mich wenig Sinn, sollte der mittlere Draht nicht dein Dipol sein? :?

Edit: Hat sich erledigt mir sind mal wieder ein zwei Seiten verloren gegangen da mein Netz zu langsam ist. :oops:
Benutzeravatar
reutron
 
Beiträge: 1117
Registriert: Mo 12. Aug 2013, 19:58
Wohnort: Gottow

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon asg » Mi 27. Dez 2017, 19:09

zilog80 hat geschrieben:NACHTRAG:
Wenn man das Fenster K von N/2 auf z.B. 2N erhoeht und einen etwas groesseren Buffer in Kauf nimmt, halbiert sich die Rechenzeit beinahe. (So sollte es auch sein, da kommt der Vorteil der schnellen Fouriertrafo zur Geltung.) Eigentlich muesste man diese Parameter fuer jede Bitrate/Sampling-Rate/Sonde bestimmen, um den FFT-Buffer vernuenftig auszunutzen. Haengt aber auch davon ab, wieviel Speicher man zur Verfuegung stellen will.


Fein, jetzt sind es nur 125 anstatt 252 Sekunden. Bei der live-Auswertung habe ich jetzt dauernd buffer underrun, das sollte aber schnell gefixt sein.

Kann man die Fenstergröße für z.B. 10/48000 berechnen oder muss man probieren?
asg
 
Beiträge: 14
Registriert: So 25. Sep 2016, 19:39

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zilog80 » Mi 27. Dez 2017, 19:49

asg hat geschrieben:Kann man die Fenstergröße für z.B. 10/48000 berechnen oder muss man probieren?

Hab die Werte fuer 48k so gewaehlt, dass sie fuer alle Sonden halbwegs gut funktionieren und nicht viel verschenken.

N ist die Anzahl Samples fuer die bits, die den Header ausmachen, den man finden will. Die dfm hat nur 16 bit, da sollte man nichts verschenken, bei der rs92 hilft es hingegen, wenn man am Anfang den Teil, der sich wiederholt, etwas kuerzt, gibt einen markanteren Peak und reduziert die kleineren "Nebenpeaks". Der rs41-Header gibt einen guten Peak, den kann man auch so lassen. Bei allen kommt man bei 48k etwa auf 600 samples.
M ist der buffer fuer die gelesenen Samples. K ("Fenstergroesse" bzw. an wievielen Stellen man die N samples correliert) sollte also zusammen mit N nicht groesser als M sein. Fuer die FFT sollte nun N+K nahe an eine Zweierpotenz kommen, also < 2^n.

Fuer 48k hat man so in etwa N+K=1900<2048; das Fenster, das man damit fahren kann, ist gut 1200 Samples gross, also etwa 120 bit bei rs41.
Wenn man dann von einem Frame zum naechsten etwa 1-2 FFTs anwenden muss, ist das eigentlich ok.
Bei der m10 ist die Anzahl Samples pro bit kleiner, hab dann das Fenster verdoppelt, um zusammen auf eine aehnlich grosse FFT zu kommen, die nicht so oft wiederholt werden muss.
zilog80
 
Beiträge: 305
Registriert: So 31. Aug 2014, 14:08

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon asg » Mi 27. Dez 2017, 22:59

zilog80 hat geschrieben:
asg hat geschrieben:Kann man die Fenstergröße für z.B. 10/48000 berechnen oder muss man probieren?

Hab die Werte fuer 48k so gewaehlt, dass sie fuer alle Sonden halbwegs gut funktionieren und nicht viel verschenken.

N ist die Anzahl Samples fuer die bits, die den Header ausmachen, den man finden will. Die dfm hat nur 16 bit, da sollte man nichts verschenken, bei der rs92 hilft es hingegen, wenn man am Anfang den Teil, der sich wiederholt, etwas kuerzt, gibt einen markanteren Peak und reduziert die kleineren "Nebenpeaks". Der rs41-Header gibt einen guten Peak, den kann man auch so lassen. Bei allen kommt man bei 48k etwa auf 600 samples.
M ist der buffer fuer die gelesenen Samples. K ("Fenstergroesse" bzw. an wievielen Stellen man die N samples correliert) sollte also zusammen mit N nicht groesser als M sein. Fuer die FFT sollte nun N+K nahe an eine Zweierpotenz kommen, also < 2^n.


Warum verkleinert delay das Fenster?
asg
 
Beiträge: 14
Registriert: So 25. Sep 2016, 19:39

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Bastelbruder » Mi 27. Dez 2017, 23:23

Ausschnitt vom Ausschnitt?
Bastelbruder
 
Beiträge: 4601
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zilog80 » Mi 27. Dez 2017, 23:50

asg hat geschrieben:Warum verkleinert delay das Fenster?

Ursprunglich hatte ich ueberlegt, eine kleine Verzoegerung einzubauen, also bei sample_in wird aktuell eingelesen und die Verarbeitung und Ausgabe geschieht etwas spaeter bei sample_out=sample_in-delay. Z.B. als ich anfangs an jedem Punkt die Correlation ganz naiv durchfuehrte, wollte ich nicht jedes Mal das Maximum ueber ganz N ermitteln, sondern nach Moeglichkeit nur die neu hinzukommenen Samples beruecksichtigen. Fuer ein Maximum, das nicht auf dem Rand liegen sollte (wo dann das naechste Sample vielleicht noch groesser sein koennte), war dann hilfreich, etwas Platz zu haben und sozusagen in die Zukunft gucken zu koennen. Eigentlich braucht man dazu nur wenige bits, und selbst wenn es jetzt gerade keine Verwendung dafuer gibt, vielleicht brauch ich das nochmal. Wahrscheinlich ist aber auch N/16 (oder was ich zur Zeit habe fuer delay) ziemlich gross, im Verhaeltnis zu N aber auch nicht so viel.
Die FFT wird fuer N+K samples bis sample_out gemacht, im buffer muss man also mindesten N+K+delay Samples vorhalten. Sicher koennte man M auch direkt so waehlen, dass man fuer die FFT auf eine 2er-Potenz kommt, so dass K mindestens so gross wie N ist. (Wenn schon N sehr nahe bei 2^n liegt, sollte man wenigstens zur naechsten 2er-Potenz gehen.)

Bei der FFT faellt es nicht so sehr ins Gewicht, wenn man ein paar Samples mehr oder weniger nimmt (also K=N/2 oder K=2N macht schon einen Unterschied).
Wenn man ganz naiv die Correlation an jedem Punkt macht oder mit ganz naiver DFT, dann merkt man schnell, welchen Einfluss die Groesse von N hat.

Das delay koennte auch helfen, wenn man Werte wie die Varianz oder den Mittelwert um den verzoegerten Zeitpunkt sample_out herum ermitteln will und nicht nur von sample_out aus in die Vergangenheit. Bisher war das aber nicht noetig. Bei der rs41 kann man schoen das Rauschen mit dem Signal vergleichen, im Grunde hat man dann auch sowas wie S/N fuer jeden Frame. Bei den anderen Sonden hat man nicht den Vergleich mit dem Rauschen, auch die m10 sendet in den Pausen einen Traeger.

An vielen Stellen ist sowas wie eine "Margin" eingebaut.
zilog80
 
Beiträge: 305
Registriert: So 31. Aug 2014, 14:08

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Radiosonde » Mo 1. Jan 2018, 14:06

Kann es sein,dass vom Hohenpeissenberg keine Sonde gestartet wurde?Die Bremer Seite hatt sie jedenfalls nicht erfasst...gibt es eigentlich Leute im Raum Salzburg/Freilassing die auch Sonden jagen?
LG
Radiosonde
 
Beiträge: 23
Registriert: Mo 9. Okt 2017, 15:33

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Robby_DG0ROB » Mo 1. Jan 2018, 17:28

An Feiertagen finden dort keine Aufstiege statt. Es kann manchmal im Sommerhalbjahr passieren, dass ein wegen eines Feiertages ausgesetzter Start an einem Freitag nachgeholt wird. Die nächste Peißenberger sollte am Mittwoch starten. Prag beginnt am Mittwoch auch wieder mit den O3-Aufstiegen, die aber normal für DL nicht relevant sind, da nur ganz selten mal der Ostwind diese Apparate so weit trägt.
Robby_DG0ROB
 
Beiträge: 1445
Registriert: Do 19. Mai 2016, 21:13
Wohnort: Regensburg

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Radiosonde » Mo 1. Jan 2018, 22:29

Hallo weiß irgendwer wie man an eine iMet-1-RS rankommt?
Auf Ebay ist derzeit nichts zu finden..gibt es Stationen die solche manchmal steigen lasen?
Generel liegt mein QTH Sondentechnisch nicht so super hier fliegen eigentlich nur RS41(früher RS92) keine schönen DFMs oder irgendwelche Sondengespanne wie das "Monster"von dem ich hier gelesen habe.Derzeit arbeitet ich an einem Interface für den Xdata Bus um eigene Sensoren an gehackte Sonden anschließen zu können.Bei der RS41 liegen die Kontakte außen wie auch bei der DFM09 aber wie ist das bei der RS92 gelöst dazu konnte ich keine Stekerbelegung finden oder ist die Belegung eh gleich wie bei der Rs41? Würde ja sinnvoll erscheinen...
LG
Radiosonde
 
Beiträge: 23
Registriert: Mo 9. Okt 2017, 15:33

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Robby_DG0ROB » Di 2. Jan 2018, 00:11

Ich kann dir zwar zur IMET nichts beitragen, weil ich diese Dinger selber auch nicht kenne, aber bei der DFM ist kein XDATA nach außen geführt, jedenfalls nicht bei den üblicherweise eingesetzten Ausführungen; der UART-Port dient nur zur Initialisierung mit dem dafür vorgesehenem Interface. Es gibt spezielle Varianten, die mit einer herausgeführten 4-pol. Schnittstellenleitung ausgerüstet sind (Vcc/TX/RX/GnD).
Robby_DG0ROB
 
Beiträge: 1445
Registriert: Do 19. Mai 2016, 21:13
Wohnort: Regensburg

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Radiosonde » Di 2. Jan 2018, 00:57

Ja genau diese Schnittstelle meine ich!Ich denke die ist bei jeder Version vorhanden nur nicht nach ausen geführt das sollte aber kein Problem sein.Jetzt brauch ich nur noch nen freundlichen Sondenjäger der mir ca. 3 DFMs 2 SGPs und 2 RS41für paar Döner und Versand übergibt.Sowas fliegt bei mir ja leider nicht(bis auf die RS41) mein Bedarf an Bastelsonden ist nämlich enorm gestiegen:)und wie ich manchmal lese dass somancher die Sonden entsorgt....:)
LG
Radiosonde
 
Beiträge: 23
Registriert: Mo 9. Okt 2017, 15:33

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Robby_DG0ROB » Di 2. Jan 2018, 01:02

Radiosonde hat geschrieben:Ja genau diese Schnittstelle meine ich!Ich denke die ist bei jeder Version vorhanden nur nicht nach ausen geführt (…)


So einfach ist das nicht, da einiges nachbestückt werden muss. Bei einer TU-Variante genügt es auch nicht, einfach nur einen Baro-Sensor draufzunageln, um eine PTU-Sonde daraus zu machen.
Robby_DG0ROB
 
Beiträge: 1445
Registriert: Do 19. Mai 2016, 21:13
Wohnort: Regensburg

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Radiosonde » Di 2. Jan 2018, 01:15

Na deshalb bin ich auch so an der iMet-1-RS interresiert auch bei der RS41 ist der xdata Anschluß herausgeführt auch bei der RS92 ist der Stecker vorhanden,nur die Belegung weiß ich noch nicht.Man müsste dann wohl die richtige DFM auftreiben oder halt umbestücken.
Hatt sich eigentlich schon wer mit der Entwicklung eigener Sensoren beschäftigt?
LG
Radiosonde
 
Beiträge: 23
Registriert: Mo 9. Okt 2017, 15:33

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zilog80 » Di 2. Jan 2018, 09:22

Die iMet-1-RS wird manchmal in der Schweiz gestartet oder auch in Lindenberg. Das XDATA Protokoll, das dort benutzt wird, wurde von Vaisala glaube erst mit der RS41 unterstuetzt.

Die Broschuere der Graw PS-15 Pilotsonde erwaehnt auch eine XDATA-Schnittstelle. Testfluege von Graw werden wohl in Nuernberg gestartet.

Radiosonde hat geschrieben:Hatt sich eigentlich schon wer mit der Entwicklung eigener Sensoren beschäftigt?

Meinst du die Sensoren oder das Drumherum, mit dem du dann z.B. einen Widerstand oder eine Kapazitaet des Sensors misst? (Wahrscheinlich koennte man auch alles zusammen als Sensor bezeichnen.)
Was willst du denn messen?
zilog80
 
Beiträge: 305
Registriert: So 31. Aug 2014, 14:08

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zauberkopf » Di 2. Jan 2018, 10:57

Hatt sich eigentlich schon wer mit der Entwicklung eigener Sensoren beschäftigt?

Ja.. ich.
Ich wollte mal Ozon "optisch" messen.
Und zwar mittels 254nm UV Glimmlämpchen.
2 Leuchten, 2 Wollte ich als Sensoren verschalten.
Glimmlampen als Sensoren, deshalb, weil wirklich alles andere was 254nm detektieren kann, sau teuer ist.
Das war der Plan, der aber nie umgesetzt wurde.

Mit gelben LED's kann man übrigens auch Ozon Messen.. aber da ist die Absorbtion nicht so gut, und ich vermute, da wird der Sensor schnell ziemlich gross und wieder unhandlich.

Wegen der Sondenschnittstelle : Warum unbedingt die XDATA Schnittstelle ?!
Also wenn ich mich recht erinnere : Dann wurde die Ozonsonde so abgefragt :
Eine RS92 hat via SPI nen AD-Wandler abgefragt...
.. Naja.. und der AD-Wandler lässt sich doch gut durch einen AVR oder PIC simulieren !
Benutzeravatar
zauberkopf
 
Beiträge: 6382
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Robby_DG0ROB » Di 2. Jan 2018, 12:36

zilog80 hat geschrieben:Die Broschuere der Graw PS-15 Pilotsonde erwaehnt auch eine XDATA-Schnittstelle. Testfluege von Graw werden wohl in Nuernberg gestartet.


Die Entwicklungsmuster hatten auch nur den Samtec-Stecker für den Debugger bestückt, mit XData-Interface sind keine (mir bekannten) Exemplare geflogen - ist bei PS15 auch nur Bestückoption. Nach Erreichen der Serienreife hat Graw selber keine PS15 mehr eingesetzt, sondern ausschließlich DFM09 geflogen. Die zahlreichen Muster waren 2016 unterwegs. PS15 werden gelegentlich in den Sommermonaten für einzelne Sondenaufstiege im Raum Regensburg verwendet.

Was spricht dagegen, einfach das Passende beim Hersteller anfragen und bestellen? Die haben soviel davon, dass es schon verkauft werden muss :)
Robby_DG0ROB
 
Beiträge: 1445
Registriert: Do 19. Mai 2016, 21:13
Wohnort: Regensburg

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon zanco » Di 2. Jan 2018, 16:29

Gutentag :-)

Das bestes fur 2018 !!

Momentan haben wir auf 434.3875 rtty 75n2 einer RS41 auf 4990 m und es hat geschaft es "floaten" zu lassen

Er geht nach Deutschland :-)

Gibt es noch mithöhrer ?

Danke,

Ben
Benutzeravatar
zanco
 
Beiträge: 111
Registriert: Mo 16. Mär 2015, 08:15
Wohnort: jo21cx

Re: Wettersonden jagen = Spielzeug vom Himmel !

Beitragvon Matze_0101 » Di 2. Jan 2018, 19:41

Moin,

und ein frohes neues Jahr !!!
Bleibt vorsichtig bei der Sondensuche.
Und, es sind genug für alle da!
Hier die Landeorte aus 2017:
https://wetterson.de/landungen/2017/

(leider ist der Januar und Februar `17 irgendwie ...weg)
Gruß Matze
Matze_0101
 
Beiträge: 10
Registriert: Do 12. Mai 2016, 13:44

VorherigeNächste

Zurück zu Allgemeine Diskussion

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste

span