Als uitsmijter nog het feit dat mijn waarnemingen ook op de website van SQ6KXY terecht komt en verder doorgesluist wordt naar aprs.fi
link : radiosondy.info
Ik heb besloten om dit te doen en geen lokale map te gebruiken omdat ten eerste de download van openstreetmap niet meer ging en ik geen goesting heb om dit uit te vlooien en ten tweede , iedereen heeft tegenwoordig een internetverbinding.
Hiervoor moest er nog één applicatie bijgevoegd worden , namelijk udpgate4.
Dit is dan ook voorzien van de juiste parameters en bijgevoegd in het shell script
Ik heb nu twee shell scripten :
1. startsonde.sh link google drive
2. stopsonde.sh link google drive
en ook nog de sdrcfg configuratie link google drive
Vergeet niet in netbeacon.txt uw GPS coördinaten te steken !
Maak dit bestand aan met nano netbeacon.txt en zet deze onder de aprs map
Zoiets als
!51xx.xxN/004xx.xxE`Igate
Let goed op de juiste leestekens en vervang de xx door uw eigen coördinaten
Hier hoeft geen verdere uitleg bij dacht ik
Enkele snapshots met de bewijzen:
En het gewijzigde blokschema van de dataflow
Posts tonen met het label weerballon. Alle posts tonen
Posts tonen met het label weerballon. Alle posts tonen
dinsdag 24 maart 2020
zondag 22 maart 2020
WXbalonnen [debugverhaal episode 6 : Het werkt weer ! ]
Alles terug aan elkaar " geknoopt" maar elke blok apart gestart .
Men moet héél goed opletten wat de argumenten betreft.
Enfin , het werkt terug .
Doordat ik nu ook audio heb tijdens decoding hoor ik wel wat er wel en niet goed gaat , dat gaat voornamelijk over de samplerates.
Als er twee stations in de configfile zitten halveert de samplerate om de één of andere reden . De audio wordt " traag" net zoals vroeger ge een singeltje afspeelde op 33 toeren ipv van 45 !
Ik had dat ook al vastgesteld bij de testen met de dubbele audiospeler.
Misschien test ik ook nog eens de mapprojectie , maar voorlopig hou ik dit nog even opzij.
23/03/2020 . Deze morgen het bash script herschreven. Nu kan ik opstarten met één commando ipv van alles één voor één te starten , ook de aplay doet nu mee.
Men moet héél goed opletten wat de argumenten betreft.
Enfin , het werkt terug .
Doordat ik nu ook audio heb tijdens decoding hoor ik wel wat er wel en niet goed gaat , dat gaat voornamelijk over de samplerates.
Als er twee stations in de configfile zitten halveert de samplerate om de één of andere reden . De audio wordt " traag" net zoals vroeger ge een singeltje afspeelde op 33 toeren ipv van 45 !
Ik had dat ook al vastgesteld bij de testen met de dubbele audiospeler.
Misschien test ik ook nog eens de mapprojectie , maar voorlopig hou ik dit nog even opzij.
23/03/2020 . Deze morgen het bash script herschreven. Nu kan ik opstarten met één commando ipv van alles één voor één te starten , ook de aplay doet nu mee.
Labels:
aplay,
debug,
pipe deleten,
rtl_tcp,
rtltst,
sdrcfg.txt,
weerballon,
wettersonde,
wxbalonnen
zaterdag 21 maart 2020
WXbalonnen [debugverhaal episode 5]
Nu dat de opstelling getest is met de standaard bouwstenen komen we uiteindelijk toe aan de configuratie zoals het bedoeld was , nl met rtl_tcp , sdrtst en sdrcfg.txt
Dit is een herwerkt blokschema van de linkerkant van het vorig schema.
Tenslotte sdrtst met sdrcfg.txt
U krijgt de instellingen te zien die zijn opgestuurd naar de rtl_tcp server .
parm1 enz...
Dit werkt dus als een client, want zie hoe rtl_tcp reageert hierop:
Het enige dat misschien nog uitleg behoeft is " allocating 15 zero-copy buffers."
Dit zijn inderdaad buffers die NIET onder bestuur van de CPU vallen maar rechtsreeks geschreven en gelezen worden voor tijdswinst.
Nu dat de server en client loopt zal ook de audiospeler in gang schieten want nu pas wordt de pipe gevuld met data.
Besluit :
Met deze config is bewezen dat het rx gedeelte ook werkt . Ik kan , in tegenstelling tot vroeger , ook het geluid laten horen .
Nu zouden we alles aan elkaar moeten koppelen om een volledig werkende weerballonontvanger/decoder te hebben .
Door te experimenteren heb ik geen tijd verloren , meer nog , ik begrijp nu beter de afzonderlijke blokken en zie dat deze ook bruikbaar zijn voor andere doeleinden waarvan ik er al één in mijn hoofd heb om uit te proberen .
De sdrtst is namelijk ook te gebruiken voor AM en SSB ontvangst .
Dit wordt mijn volgend experiment .
Nog een laatste opmerking .
Ik kon meerdere pipes niet wissen en kreeg zelfs gevulde pipes die bleven staan .
Per ongeluk heb ik gevonden dat met dit commando :
sudo rm -r *pipe*
toch alles gewist wordt .Waarom mij dit eerder niet is gelukt weet ik niet.
Dit is een herwerkt blokschema van de linkerkant van het vorig schema.
In de rode kader ziet men de volgorde van opstarten van de verschillende bouwstenen .Dit is belangrijk omdat de pipe de mogelijkheid moet hebben om op zijn uitgang ( wat de ingang van de audiospeler is) de data te dumpen , anders gaat het mis. Dus aplay starten vóór sdrtst. !
Dus
Eerst rtltcp
dan Aplay
en pas dan sdrtst, met sdrcfg.txt
Korte uitleg welke bouwsteen wat doet:
rtl_tcp : Start de dongle op , verwijdert de kernel en neemt zelf de controle over.
Luister op tcp niveau naar inkomende berichten .
Dit gebeurt er als je weer afsluit met bv <CTRL> C ( ^ C op de foto))
De originele kernel wordt weer ingeladen .
Aplay :
Start de audiospeler met de juiste argumenten en krijgt via een omleiding ( redirection, piping ) de data binnen van de voorzien pipe , hier ook pipe genoemd maar dat kan elke geldige naam zijn.
Tenslotte sdrtst met sdrcfg.txt
sdrcfg.txt wordt meegenomen als argument en is online te veranderen !
U krijgt de instellingen te zien die zijn opgestuurd naar de rtl_tcp server .
parm1 enz...
Dit werkt dus als een client, want zie hoe rtl_tcp reageert hierop:
Het enige dat misschien nog uitleg behoeft is " allocating 15 zero-copy buffers."
Dit zijn inderdaad buffers die NIET onder bestuur van de CPU vallen maar rechtsreeks geschreven en gelezen worden voor tijdswinst.
Nu dat de server en client loopt zal ook de audiospeler in gang schieten want nu pas wordt de pipe gevuld met data.
De ######## + | 79% is de vumeter .
De underrun is normaal bij de opstart en geeft verder geen problemen.
Besluit :
Met deze config is bewezen dat het rx gedeelte ook werkt . Ik kan , in tegenstelling tot vroeger , ook het geluid laten horen .
Nu zouden we alles aan elkaar moeten koppelen om een volledig werkende weerballonontvanger/decoder te hebben .
Door te experimenteren heb ik geen tijd verloren , meer nog , ik begrijp nu beter de afzonderlijke blokken en zie dat deze ook bruikbaar zijn voor andere doeleinden waarvan ik er al één in mijn hoofd heb om uit te proberen .
De sdrtst is namelijk ook te gebruiken voor AM en SSB ontvangst .
Dit wordt mijn volgend experiment .
Nog een laatste opmerking .
Ik kon meerdere pipes niet wissen en kreeg zelfs gevulde pipes die bleven staan .
Per ongeluk heb ik gevonden dat met dit commando :
sudo rm -r *pipe*
toch alles gewist wordt .Waarom mij dit eerder niet is gelukt weet ik niet.
Labels:
aplay,
debug,
pipe deleten,
rtl_tcp,
rtltst,
sdrcfg.txt,
weerballon,
wettersonde,
wxbalonnen
vrijdag 20 maart 2020
WXbalonnen [debugverhaal episode 4]
We pikken terug de draad op en fileren verder mijn oude opstelling.
Dit wordt dan de "linkerkant" of maw het ontvangstgedeelte.
Hiervoor heb ik eerst wat gespeeld met de sdr dongle zelf met eigen commando's om toch nog eens te zien wat er allemaal gebeurt.
Dus nog geen rtl_tcp en nog geen sdrtst met sdrcfg.txt
We hebben oa de volgende " ingebakken" commando's ter onze beschikking.
Deze hebben we omdat we de osmocom driver en librtlsdr bibliotheek gebruiken
rtl_fm ; rtl_sdr ; rtl_tcp ; rtl_test enz ...
Hier wat meer info daarover:
osmocom
Kort samengevat :
1. rtl_fm is een basic fm decoder waarvan de output audio is ( waarschijnlijk in het PCM S16_LE formaat ) . De frequentie en ander parameters worden als argumenten bij het commando meegegeven .
Bijv:
Frequentie is hier 96.3 Mhz (-f)
Mode is hier wideband FM , zeg maar de gewonde FM band ( -M )
Samplerate is hier 200000 ( -s) dit komt overeen met de bandbreedte van één FM uitzending, 200kHz
Resamplerate is hier 48000 ( -r) dit is een 48kHz samplerate waardoor tot max een signaal van iets meer dan 20 kHz in audiogebied kan worden weergegeven ( zie Nyquist)
| is het pijpteken , de uitgang van de decoder wordt via een pipe doorgegeven naar de Linux ( of andere ) audiospeler , hier dus aplay
-r 48 k : op zijn beurt moet de speler weten met welke samplerate het audio binnenkomt. Dit moet gelijk zijn aan de uitgang van de decoder , anders is het geluid niet op " afspeelsnelheid" of kun je helemaal niets horen .
-f S16_LE : is het formaat hoe de digitale weergave van het geluid wordt gepresenteerd . S staat voor signed ( dus met + of - teken ) 16 staat voor het aantal bits waarmee de amplitude van het audiosignaal is bemonsterd, hier dus 16 en LE staat voor Little Endian , een werkwijze of ze eerst de LSB -bit doorsturen of eerst de MSB -bit .Hier dus eerst de LSB.
Met bovenstaande code kan men dus naar een FM station luisteren op je PC.
2. rtl_sdr geeft op zijn uitgang de ruwe ( raw) I/Q formaat uit . Daardoor is het mogelijk om andere bewerkingen te doen om te decoderen /demoduleren. Wil je in deze mode toch audio verkrijgen zoals bij rtl_fm dan moet je nog zelf een decoder achterna schakelen . Ook rtl_sdr kan men parametreren .
De lijst is vrij lang maar kan altijd opgevraagd worden in Linux met volgend commando, op voorwaarde natuurlijk dat deze is geïnstalleerd:
man rtl_sdr
Verlaat de manual met q
3. rtl_sdr werkt samen met rtl_tcp:
Zoals de naam al verraadt is dit een methode om gegevens zoals parameters ( dit zijn instelgegevens) door te geven naar de SDR dongle.Dit wordt gedaan via het interne netwerk van de computer , ook wel localhost genoemd .
Elk netwerk heeft zijn adres en lokaal is dat 127.0.0.1. Daarbij hoort nog een poortnummer ( port) en voor de dongle is dat als standaard waarde op 1234 gezet , gemakkelijk om te onthouden .Wil je deze poort veranderen , dat kan , zie de manual :
man rtl_tcp
Verlaat de manual met q
rtl_tcp is een server , dit wil zeggen dat hij luistert op poort 1234 voor eventuele berichten . Onthoudt dit goed.
Langs deze weg kan dan ook de freq en al andere parameters doorgestuurd worden zoals ook de -P parameter . Met deze parameter stelt men de afwijking in die uw dongle heeft , uitgedrukt in ppm . Bij mij is dat 52 .
Dit ziet ge als ge rtl_tcp opstart als ge niets meegeeft.
Dit was het voor nu.
Dit wordt dan de "linkerkant" of maw het ontvangstgedeelte.
Hiervoor heb ik eerst wat gespeeld met de sdr dongle zelf met eigen commando's om toch nog eens te zien wat er allemaal gebeurt.
Dus nog geen rtl_tcp en nog geen sdrtst met sdrcfg.txt
We hebben oa de volgende " ingebakken" commando's ter onze beschikking.
Deze hebben we omdat we de osmocom driver en librtlsdr bibliotheek gebruiken
rtl_fm ; rtl_sdr ; rtl_tcp ; rtl_test enz ...
Hier wat meer info daarover:
osmocom
Kort samengevat :
1. rtl_fm is een basic fm decoder waarvan de output audio is ( waarschijnlijk in het PCM S16_LE formaat ) . De frequentie en ander parameters worden als argumenten bij het commando meegegeven .
Bijv:
rtl_fm -f 96.3e6 -M wbfm -s 200000 -r 48000 - | aplay -r 48000 -f S16_LE
Een beetje uitleg
Frequentie is hier 96.3 Mhz (-f)
Mode is hier wideband FM , zeg maar de gewonde FM band ( -M )
Samplerate is hier 200000 ( -s) dit komt overeen met de bandbreedte van één FM uitzending, 200kHz
Resamplerate is hier 48000 ( -r) dit is een 48kHz samplerate waardoor tot max een signaal van iets meer dan 20 kHz in audiogebied kan worden weergegeven ( zie Nyquist)
| is het pijpteken , de uitgang van de decoder wordt via een pipe doorgegeven naar de Linux ( of andere ) audiospeler , hier dus aplay
-r 48 k : op zijn beurt moet de speler weten met welke samplerate het audio binnenkomt. Dit moet gelijk zijn aan de uitgang van de decoder , anders is het geluid niet op " afspeelsnelheid" of kun je helemaal niets horen .
-f S16_LE : is het formaat hoe de digitale weergave van het geluid wordt gepresenteerd . S staat voor signed ( dus met + of - teken ) 16 staat voor het aantal bits waarmee de amplitude van het audiosignaal is bemonsterd, hier dus 16 en LE staat voor Little Endian , een werkwijze of ze eerst de LSB -bit doorsturen of eerst de MSB -bit .Hier dus eerst de LSB.
Met bovenstaande code kan men dus naar een FM station luisteren op je PC.
2. rtl_sdr geeft op zijn uitgang de ruwe ( raw) I/Q formaat uit . Daardoor is het mogelijk om andere bewerkingen te doen om te decoderen /demoduleren. Wil je in deze mode toch audio verkrijgen zoals bij rtl_fm dan moet je nog zelf een decoder achterna schakelen . Ook rtl_sdr kan men parametreren .
De lijst is vrij lang maar kan altijd opgevraagd worden in Linux met volgend commando, op voorwaarde natuurlijk dat deze is geïnstalleerd:
man rtl_sdr
Verlaat de manual met q
3. rtl_sdr werkt samen met rtl_tcp:
Zoals de naam al verraadt is dit een methode om gegevens zoals parameters ( dit zijn instelgegevens) door te geven naar de SDR dongle.Dit wordt gedaan via het interne netwerk van de computer , ook wel localhost genoemd .
Elk netwerk heeft zijn adres en lokaal is dat 127.0.0.1. Daarbij hoort nog een poortnummer ( port) en voor de dongle is dat als standaard waarde op 1234 gezet , gemakkelijk om te onthouden .Wil je deze poort veranderen , dat kan , zie de manual :
man rtl_tcp
Verlaat de manual met q
rtl_tcp is een server , dit wil zeggen dat hij luistert op poort 1234 voor eventuele berichten . Onthoudt dit goed.
Langs deze weg kan dan ook de freq en al andere parameters doorgestuurd worden zoals ook de -P parameter . Met deze parameter stelt men de afwijking in die uw dongle heeft , uitgedrukt in ppm . Bij mij is dat 52 .
Dit ziet ge als ge rtl_tcp opstart als ge niets meegeeft.
Dit was het voor nu.
Labels:
aplay,
debug,
rtl_fm,
rtl_sdr,
rtl_tcp,
weerballon,
wettersonde,
wxbalonnen
donderdag 19 maart 2020
Radiosondes op HabHub [ deel 1 ]
Ter info :
Radiosondes ( weerballonnen) zijn ook te volgen op de HabHub tracker .
Ik was mij daar niet van bewust , maar een link in een ander programma ( zie volgende post) bracht mij er naar toe .
Als je in de linkerbovenhoek het zoekveld invult met RS* en daarna op S klikt komen alle weerballonnen te voorschijn met hun blauwe radiohorizoncirkel .
Als je daarin valt kun je ze in principe ontvangen .De groen cirkel is mij niet meer bekend .Ik dacht eerst dat in die cirkel hij visueel zou te zien zijn , maar ik gok nu eerder op de opp waar hij zou neerkomen mocht hij op dat moment neervallen .Wie weet er hier meer over ?
23/03/2020
Dankzij Patrick ON4CDJ weten we nu meer !
De groene cirkel is wanneer de ballon 5° boven de horizon is .
Hoe ik tot hier kwam lees je in een volgende post.
Radiosondes ( weerballonnen) zijn ook te volgen op de HabHub tracker .
Ik was mij daar niet van bewust , maar een link in een ander programma ( zie volgende post) bracht mij er naar toe .
Als je in de linkerbovenhoek het zoekveld invult met RS* en daarna op S klikt komen alle weerballonnen te voorschijn met hun blauwe radiohorizoncirkel .
Als je daarin valt kun je ze in principe ontvangen .De groen cirkel is mij niet meer bekend .Ik dacht eerst dat in die cirkel hij visueel zou te zien zijn , maar ik gok nu eerder op de opp waar hij zou neerkomen mocht hij op dat moment neervallen .Wie weet er hier meer over ?
23/03/2020
Dankzij Patrick ON4CDJ weten we nu meer !
De groene cirkel is wanneer de ballon 5° boven de horizon is .
Hoe ik tot hier kwam lees je in een volgende post.
zondag 15 maart 2020
WXbalonnen [debugverhaal episode 3]
De test.
We gaan dus verschillende terminals moeten openen . Dit kan via muisklik maar ook via <CTRL> < ALT> + T.
Eerst nog een verduidelijking op het blokschema.
Hier is de audioweg ingetekend in het blauw . Door een pipe te voorzien en door het argument -D te gebruiken in de syntax , wordt de audio naar de audiospeler ( Aplay) uitgegeven en kunnen we dit beluisteren .
Het is ook dit dat we als eerste starten omdat we moeten maken dat de pipe zijn inhoud kan dumpen aan zijn uitgang en hier is dat aplay. Let op dat ge in de juiste directory staat.
Onderaan ziet men een soort VU meter
Bij voldoende uitsturing ziet men iets zoals
##############+ | 50 %
Dan starten we in een volgende terminal sondemod. Voor de juiste syntax , zie episode 2. U hoeft nog geen data te zien .
Daarna is het de beurt aan sondeudp , in dit geval ons shell scriptje dat we geschreven om te testen : udpaudiodec.sh
starten met
./udpaudiodec.sh
Dit is het resultaat zonder de verbose ( -v)
Dit is het resultaat met verbose , u ziet direct de data verschijnen die zich in ons audiobestand bevindt , echter op voorwaarde dat aplay loopt. Gelijktijdig komt ook de data op enigzins andere wijze te voorschijn in het terminalvenster van sondemod.
Om nog te kijken of er iets op udp vlak doorgestuurd wordt , openen we opnieuw een terminal en vullen daar de juiste syntax in.
Eerst kijken we op poort 4000 , dat is de uitgang van sondeudp
syntax :
sudo tcpdump -i lo port 4000 -v
en dan kunnen we ook eens kijken op poort 9100 , dat is de uitgang van sondemod.
sudo tcpdump -i lo port 9100 -v
Er is wel één maar :
In feite moet ge eerst tcpdump opstarten en pas dan sondemod / sondeudp anders loopt de verbinding niet .
Dus algemeen , dit is de volgorde van opstarten als je alles wilt bekijken .
1. Aplay
2. tcpdump
3. sondemod
4. sondeudp , hier via udpaudiodec.sh
5. eventueel uw geluidsmengpaneel
Opm , als je aplay niet loopt , dan zal er ook geen data te zien zijn in sondeudp en sondemod als deze het argument -v in de syntax hebben .
Nog een opmerking:
Bij het snifferen met tcpdump op poort 9100 , zal je vaststellen dat er slechts om de 20 sec of om de 6 sec iets wordt weggeschreven . Dit is omdat dit zo voorzien is bij de syntax van sondemod
./sondemod -o 4000 -I ON4AOL-12 -r 127.0.0.1:9100 -b 20 -B 6 -A 1500 \
-x e.txt -T 360 -R 240 -d -p 2 -t sondecom.txt -v &
-b 20 , om de 20 sec wegschrijven bij hoge hoogte
-B 6 , om de 6 seconden wegschrijven bij lage hoogte.
Dit is mooi , omdat dan bij het landen van de ballon er sneller datagegevens ( oa van de GPS) te zien zal zijn om de ballon eventueel te gaan zoeken.
Deze gegevens worden uiteindelijk gebruikt om oa op een map te plotten.
Besluit van dit alles :
Het rechtergedeelte in mijn blokschema werkt dus . Ik zal de fout in het linkergedeelte moeten zoeken , maar dat wordt een andere opstelling en dus ook een ander verhaal .
We gaan dus verschillende terminals moeten openen . Dit kan via muisklik maar ook via <CTRL> < ALT> + T.
Eerst nog een verduidelijking op het blokschema.
Hier is de audioweg ingetekend in het blauw . Door een pipe te voorzien en door het argument -D te gebruiken in de syntax , wordt de audio naar de audiospeler ( Aplay) uitgegeven en kunnen we dit beluisteren .
Bij voldoende uitsturing ziet men iets zoals
##############+ | 50 %
Dan starten we in een volgende terminal sondemod. Voor de juiste syntax , zie episode 2. U hoeft nog geen data te zien .
Daarna is het de beurt aan sondeudp , in dit geval ons shell scriptje dat we geschreven om te testen : udpaudiodec.sh
starten met
./udpaudiodec.sh
Dit is het resultaat zonder de verbose ( -v)
![]() |
uitgang sondeudp opgestart met udpaudiodec.sh |
Dit is het resultaat met verbose , u ziet direct de data verschijnen die zich in ons audiobestand bevindt , echter op voorwaarde dat aplay loopt. Gelijktijdig komt ook de data op enigzins andere wijze te voorschijn in het terminalvenster van sondemod.
![]() |
data in sondemod |
Om nog te kijken of er iets op udp vlak doorgestuurd wordt , openen we opnieuw een terminal en vullen daar de juiste syntax in.
Eerst kijken we op poort 4000 , dat is de uitgang van sondeudp
![]() |
poort 4000 |
syntax :
sudo tcpdump -i lo port 4000 -v
en dan kunnen we ook eens kijken op poort 9100 , dat is de uitgang van sondemod.
sudo tcpdump -i lo port 9100 -v
![]() | |||
poort 9100 |
In feite moet ge eerst tcpdump opstarten en pas dan sondemod / sondeudp anders loopt de verbinding niet .
Dus algemeen , dit is de volgorde van opstarten als je alles wilt bekijken .
1. Aplay
2. tcpdump
3. sondemod
4. sondeudp , hier via udpaudiodec.sh
5. eventueel uw geluidsmengpaneel
Opm , als je aplay niet loopt , dan zal er ook geen data te zien zijn in sondeudp en sondemod als deze het argument -v in de syntax hebben .
Nog een opmerking:
Bij het snifferen met tcpdump op poort 9100 , zal je vaststellen dat er slechts om de 20 sec of om de 6 sec iets wordt weggeschreven . Dit is omdat dit zo voorzien is bij de syntax van sondemod
./sondemod -o 4000 -I ON4AOL-12 -r 127.0.0.1:9100 -b 20 -B 6 -A 1500 \
-x e.txt -T 360 -R 240 -d -p 2 -t sondecom.txt -v &
-b 20 , om de 20 sec wegschrijven bij hoge hoogte
-B 6 , om de 6 seconden wegschrijven bij lage hoogte.
Dit is mooi , omdat dan bij het landen van de ballon er sneller datagegevens ( oa van de GPS) te zien zal zijn om de ballon eventueel te gaan zoeken.
Deze gegevens worden uiteindelijk gebruikt om oa op een map te plotten.
Besluit van dit alles :
Het rechtergedeelte in mijn blokschema werkt dus . Ik zal de fout in het linkergedeelte moeten zoeken , maar dat wordt een andere opstelling en dus ook een ander verhaal .
Labels:
debug,
weerballon,
wettersonde,
wxbalonnen
zaterdag 14 maart 2020
WXbalonnen [debugverhaal episode 2]
Wat hebben we nodig ?
1. Audiobestand in S16 LE mode en 8000 Hz rate.
2. Een klein shell bestandje om sondeudp op te starten
3. Een pipe bestand
4. Een audiospeler , we gebruiken de Aplay van Linux.
5. Eventueel iets om te snifferen op de UDP stream : --> tcpdump
6. Veel open terminal vensters om dit allemaal te kunnen ingeven .
Zoiets dus !
Voorbereiding.
Eerst een shellbestandje aanmaken ( script)
Ik heb dit udpaudiodec.sh genoemd . Maak dit aan met nano .
en geef nadien rechten aan dit bestand met :
sudo chmod +x udpaudiodec.sh
Het komt dan in de lijst als groen te staan , dwz : het is uitvoerbaar.
De naam van het audiobestand is hier UkkelAudio.wav maar dat kan natuurlijk uw bestandsnaam zijn. Let ook op de & op het einde , dit betekent dat dit als daemon zal draaien ( op de achtergrond) zoiets als een TSR bij DOS vroeger
( Terminate and Stay Resident). U kunt het ook weglaten , dat vergemakkelijkt het afsluiten bij problemen.
Dan maken we een pipe aan met :
sudo mknod audiopipe p
Vergeet het p niet op het einde en gebruik NIET mkfifo , dit geeft een bestand waar de inhoud blijft instaan , we moeten echt streamen.
Dan nog een commandoregel dat we zullen openen in één van de terminals .
Let op het einde van de eerste regel , de \ wil zeggen dat de regel afbreekt en verdergaat op de tweede lijn . Probeer echter alles op één lijn in de terminal te kopiëren, dan zonder de \ natuurlijk
./sondemod -o 4000 -I ON4AOL-12 -r 127.0.0.1:9100 -b 20 -B 6 -A 1500 \
-x e.txt -T 360 -R 240 -d -p 2 -t sondecom.txt -v &
Hiermee starten we sondemod op , zie daarvoor het blokschema.
Commando om de audiospeler te starten :
aplay -f S16_LE -r 8000 -c 1 --vumeter=mono < audiopipe
Dit is een wat uitgebreidere syntax , en geeft onderaan een soort van VU meter weer.
En dan voor de liefhebbers een commando om te snifferen op de UDP uitgang van sondemod.
sudo tcpdump -i lo port 9100 -v
Al deze losse commando's komen in een aparte terminal te staan .
hierbij is het ook aangewezen om het geluidsmengpaneel te openen , zo zie je of de aplay wel werkt .
Nog twee overzichten van mijn mappen aprs en dxlAPRS.
Dit om de eigenaars te zien van de bestanden . Maw met deze config werkt het.
U ziet dat bijna alles op mijn naam staat en niet op root.
Dit is een geheugensteuntje voor mezelf , misschien mogen er ook andere rechten zijn maar zo werkt het ( althans voor de audio-injectie).er zijn ook enkele pipes die in grijze tekst staan . Dit zijn gemaakte fouten en ik krijg ze niet weg , ook niet met een force argument bij het rm commando.
Volgende keer starten we alles op.
1. Audiobestand in S16 LE mode en 8000 Hz rate.
2. Een klein shell bestandje om sondeudp op te starten
3. Een pipe bestand
4. Een audiospeler , we gebruiken de Aplay van Linux.
5. Eventueel iets om te snifferen op de UDP stream : --> tcpdump
6. Veel open terminal vensters om dit allemaal te kunnen ingeven .
Zoiets dus !
Voorbereiding.
Eerst een shellbestandje aanmaken ( script)
Ik heb dit udpaudiodec.sh genoemd . Maak dit aan met nano .
en geef nadien rechten aan dit bestand met :
sudo chmod +x udpaudiodec.sh
Het komt dan in de lijst als groen te staan , dwz : het is uitvoerbaar.
De naam van het audiobestand is hier UkkelAudio.wav maar dat kan natuurlijk uw bestandsnaam zijn. Let ook op de & op het einde , dit betekent dat dit als daemon zal draaien ( op de achtergrond) zoiets als een TSR bij DOS vroeger
( Terminate and Stay Resident). U kunt het ook weglaten , dat vergemakkelijkt het afsluiten bij problemen.
Dan maken we een pipe aan met :
sudo mknod audiopipe p
Vergeet het p niet op het einde en gebruik NIET mkfifo , dit geeft een bestand waar de inhoud blijft instaan , we moeten echt streamen.
Dan nog een commandoregel dat we zullen openen in één van de terminals .
Let op het einde van de eerste regel , de \ wil zeggen dat de regel afbreekt en verdergaat op de tweede lijn . Probeer echter alles op één lijn in de terminal te kopiëren, dan zonder de \ natuurlijk
./sondemod -o 4000 -I ON4AOL-12 -r 127.0.0.1:9100 -b 20 -B 6 -A 1500 \
-x e.txt -T 360 -R 240 -d -p 2 -t sondecom.txt -v &
Hiermee starten we sondemod op , zie daarvoor het blokschema.
Commando om de audiospeler te starten :
aplay -f S16_LE -r 8000 -c 1 --vumeter=mono < audiopipe
Dit is een wat uitgebreidere syntax , en geeft onderaan een soort van VU meter weer.
En dan voor de liefhebbers een commando om te snifferen op de UDP uitgang van sondemod.
sudo tcpdump -i lo port 9100 -v
Al deze losse commando's komen in een aparte terminal te staan .
hierbij is het ook aangewezen om het geluidsmengpaneel te openen , zo zie je of de aplay wel werkt .
Nog twee overzichten van mijn mappen aprs en dxlAPRS.
Dit om de eigenaars te zien van de bestanden . Maw met deze config werkt het.
U ziet dat bijna alles op mijn naam staat en niet op root.
Dit is een geheugensteuntje voor mezelf , misschien mogen er ook andere rechten zijn maar zo werkt het ( althans voor de audio-injectie).er zijn ook enkele pipes die in grijze tekst staan . Dit zijn gemaakte fouten en ik krijg ze niet weg , ook niet met een force argument bij het rm commando.
Volgende keer starten we alles op.
Labels:
debug,
weerballon,
wettersonde,
wxbalonnen
WXbalonnen [debugverhaal episode 1]
Ik had weer eens de decodersoft geïnstalleerd om de wx balonnen te volgen , maar helaas het spul werkt niet meer ??
Ik hoop hier het debug verhaal te schrijven om dit tot een goed einde te brengen . De opzet is terug identiek als voorheen ( zie andere afleveringen in 2018) en ook het blokschema blijft hetzelfde .
Ergens in de keten liep het mis , maar ik kon niet direct achterhalen waar precies .
Na verschillende pogingen met allerhande shell bestandjes heb ik uiteindelijk besloten om ded dataflow in tweeën te splitsen en kijken wat wel en niet werkte.
Dit is te zien door het audiobestand eens af te spelen met VLC . Dit programma is zekers de moeite waard om in het bezit te hebben .
Bij tools kies je voor codec information
U ziet dat hier is gesampled met 48 kHz , dit moeten aanpassen.
Hoe je dat doet zou ons hier te ver brengen , er zijn YT filmpjes genoeg maar ik geef hier wel de uiteindelijke settings mee
Het is dit nieuwe bestand ( dat ook veel kleiner is) dat we gaan injecteren zoals hieronder is weergegeven.
Dit is voor een volgende aflevering.
Ik hoop hier het debug verhaal te schrijven om dit tot een goed einde te brengen . De opzet is terug identiek als voorheen ( zie andere afleveringen in 2018) en ook het blokschema blijft hetzelfde .
Ergens in de keten liep het mis , maar ik kon niet direct achterhalen waar precies .
Na verschillende pogingen met allerhande shell bestandjes heb ik uiteindelijk besloten om ded dataflow in tweeën te splitsen en kijken wat wel en niet werkte.
![]() |
origineel |
Na de verschillende programma's hun help file en/of man pages uit te printen om te achterhalen wat de argumenten precies doen , zag ik dat het niet speciaal de audiopipe nodig was als input van sondeudp maar deze ook een "gewoon" bestand kon inlezen .
Hiervoor moet je audiobestand aan de volgende codec voldoen :
PCM
S16LE
8 nov 2022 :Errata: Bovenstaande lijkt niet (meer) te lukken ! Door een opmerking van Vigor (Fr) heb ik het nog eens bekeken. Alhoewel in de help van sondeudp dit staat :
geeft hij bij het aanbieden van een wav file deze error
Dus enkel een pipe of oss kan werken .
De oplossing is dus een pipe maken , de wav file redirecten en de uitgang van de pipe naar sondeudp . De pipe hier noemt audiopipe
Starten van sondeudp in terminal 1 :
./sondeudp -f 16000 -o audiopipe -I ON4AOL-12 -u 127.0.0.1:4000 -c 1 -v
Starten van wav file in terminal 2 :
more UkkelAudio.wav > audiopipe , je kan ipv more ook cat gebruiken
Resultaat:
einde errata
***********************************************************************************
Tijdens een vlucht van een ballon uit Ukkel ( lekker sterk) heb ik een opname gemaakt met GQRX en de dongle
Dit kan je door volgende velden in te stellen
Het resultaat is een audiobestand maar wel met een verkeerde samplerate
Bij tools kies je voor codec information
U ziet dat hier is gesampled met 48 kHz , dit moeten aanpassen.
Hoe je dat doet zou ons hier te ver brengen , er zijn YT filmpjes genoeg maar ik geef hier wel de uiteindelijke settings mee
Het is dit nieuwe bestand ( dat ook veel kleiner is) dat we gaan injecteren zoals hieronder is weergegeven.
![]() |
debug |
Dit is voor een volgende aflevering.
woensdag 26 februari 2020
Interludium [ De framboos aka Raspberry Pi : De SSH verbinding]
Volgende stap waarna men verder kan zonder aangesloten KVM, dwz Keyboard , Video en Muis.
Maar eerst !
Paswoord van raspberry veranderen naar uw eigen paswoord !
Wederom met het volgende commando de config oproepen .
Kies nr 1.
en klaar !
Vergeet uw nieuw paswoord niet , anders kan je niet meer inloggen .
Instellen van een SSH verbinding .Zoek in Google op wat dit betekent , maar het komt op een veilige verbinding vanop "afstand" , in dit geval een andere PC
Kies nr 5 .
vervolgens P2
Na <Yes> krijg je nog een melding dat de SSH server is enabled ( ingesteld)
Verlaat de menu met <Finish>
Test je nieuw paswoord door de rpi te herstarten, en je nieuw paswoord in te geven bij de login van je nieuwe opstart.
login as --> blijft pi
password --> nieuw paswoord.
Maar eerst !
Paswoord van raspberry veranderen naar uw eigen paswoord !
Wederom met het volgende commando de config oproepen .
Kies nr 1.
Vergeet uw nieuw paswoord niet , anders kan je niet meer inloggen .
Instellen van een SSH verbinding .Zoek in Google op wat dit betekent , maar het komt op een veilige verbinding vanop "afstand" , in dit geval een andere PC
Kies nr 5 .
vervolgens P2
Na <Yes> krijg je nog een melding dat de SSH server is enabled ( ingesteld)
Verlaat de menu met <Finish>
Test je nieuw paswoord door de rpi te herstarten, en je nieuw paswoord in te geven bij de login van je nieuwe opstart.
login as --> blijft pi
password --> nieuw paswoord.
dinsdag 25 februari 2020
Interludium [ De framboos aka Raspberry Pi : De zero w internetconnectie]
Op het programma vandaag:
Wifi configureren .
Wifi:
Volg de toetsenreeksbeschrijving zoals beschreven in de vorige aflevering .
In de terminal aan de prompt:
sudo raspi-config en <ENTER>
Kies network options

daarna Wi-fi

Geef uw SSID in , dit is de naam van uw netwerk , NIET het paswoord van uw netwerk

Dan verder met <TAB> naar Ok en <ENTER>
Daarna uw paswoord van het netwerk , is er geen dan mag je dit veld leeg laten

Daarna naar hoofdmenu en

Reboot het systeem in de terminal

Nadat de rpi terug is opgestart kan je testen of je een ip adres hebt gekregen
Typ het volgende commando aan de prompt en <ENTER>

Bij wlan0 ( dit is de wireless verbinding of WiFi )

zie je bij inet een ipadres staan , noteer dit ergens voor laters.
Hier is dit 192.168.2.114 , bij u zal/kan dit anders zijn . Dit wordt door je router automatisch toegekend en kan de volgende keer anders zijn .We zullen dit laters veranderen naar een statisch ip adres , dat dan niet meer verandert.
Indien geen ipadres terugvindt , herhaal dan de procedure van hierboven .
Nogmaals : Let op bij het ingeven , Linux is Hoofdletter gevoelig !!!!!!
Volgende maal , het vrijgeven van SSH . Daarna kunnen we alles doen vanop afstand en kan de muis, toetsenbord en monitor eraf en zijn we echt barefoot .
Wifi configureren .
Wifi:
Volg de toetsenreeksbeschrijving zoals beschreven in de vorige aflevering .
In de terminal aan de prompt:
sudo raspi-config en <ENTER>
Kies network options
daarna Wi-fi
Geef uw SSID in , dit is de naam van uw netwerk , NIET het paswoord van uw netwerk
Dan verder met <TAB> naar Ok en <ENTER>
Daarna uw paswoord van het netwerk , is er geen dan mag je dit veld leeg laten
Daarna naar hoofdmenu en
Reboot het systeem in de terminal
Nadat de rpi terug is opgestart kan je testen of je een ip adres hebt gekregen
Typ het volgende commando aan de prompt en <ENTER>
Bij wlan0 ( dit is de wireless verbinding of WiFi )
zie je bij inet een ipadres staan , noteer dit ergens voor laters.
Hier is dit 192.168.2.114 , bij u zal/kan dit anders zijn . Dit wordt door je router automatisch toegekend en kan de volgende keer anders zijn .We zullen dit laters veranderen naar een statisch ip adres , dat dan niet meer verandert.
Indien geen ipadres terugvindt , herhaal dan de procedure van hierboven .
Nogmaals : Let op bij het ingeven , Linux is Hoofdletter gevoelig !!!!!!
Volgende maal , het vrijgeven van SSH . Daarna kunnen we alles doen vanop afstand en kan de muis, toetsenbord en monitor eraf en zijn we echt barefoot .
Abonneren op:
Posts (Atom)