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.
Posts tonen met het label rtl_tcp. Alle posts tonen
Posts tonen met het label rtl_tcp. Alle posts tonen
zondag 22 maart 2020
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
Abonneren op:
Posts (Atom)






