Een nieuwe lente, een nieuw geluid [RPI zero w met SDR : blacklist en de muur]

We moeten nog onze dongle blacklisten.

Dit is ook reeds meerdere malen beschreven


Hiervoor gaan we naar

cd /etc/modprobe.d 

en starten de configfile op met  sudo  nano blacklist-rtl8xxxu.conf

en voegen  erbij

blacklist dvb_usb_rtl28xxu

Bewaren met <CTRL> O en eruit gaan met   <CTRL> X en enter

Nogmaals rebooten !

 In de rpi zero w starten we via Putty de tcp server op :

rtl_tcp -a " hier uw statisch ip adres "

bv rtl_tcp -a xxx.xxx.xxx.xxx  (xxx vervangen  door uw statisch ip adres)

de poort is automatisch 1234

Daarna start ge op uw remote laptop uw programma op dat  als client zal dienst doen . Bij mij is dit Gqrx , linksboven in het beeld
Waar ge op moet letten is de configuratie van de I/O

 U moet hier kiezen zoals in de afbeelding

Dus Other als "Device"  en dan in de " Device string" uw ipadres van de rpi zero w 

dit wordt dan   rtl_tcp=xxx.xxx.xxx.xxx

Hiermee connecteer je dan als client op de rpi zero w . 

De rest is instellingen en uitproberen .

Werkt het ?

Ja en nee .

Er is verbinding en ge kunt luisteren maar het komt in " snokskes" . Dit is om twee redenen :
1. de rpi heeft maar één core in de CPU
2. de overdracht via wifi is niet altijd superdeluxe.

Ik heb het doen werken op een rpi 2 en een rpi4 met vaste internetverbinding en daar loopt het soepel.

Heeft het nog zin om de rpi zero w te proberen met een lite versie van een sdr ontvanger ipv van de Gqrx? 
Eerlijk gezegd denk ik het niet , omdat de problemen zich in het frontend ( de rpi zero w)  zich voordoen en in de "lucht" 

Het was al met al een goede leerschool. Ik rond dit projectje dan ook hier af.

Een nieuwe lente, een nieuw geluid [RPI zero w met SDR : setup ]

De setup

We vertrekken dus van een klaargestoomde rpi zero w waar buster lite  op staat , de ssh is vrijgegeven en die met een statisch ip adres ingesteld staat.U weet hoe u met Putty moet werken ( kijk anders eens verderop in de blog)

Vanuit Putty:

Vooreerst zoals altijd en vanuit de home directory    /home/pi

sudo apt-get update

en daarna 

sudo apt-get upgrade 


Het volgend dat komt heb ik samengevat in een 10 stappen plan .
Elk in te typen commando is in het blauw. 

1. libusb installeren
2. build-essential installeren
3. git installeren
4. cmake installeren
5. rtl-sdr codebase clonen en map nakijken
6. compileren met cmake
7. make
8. make install
9. ldconfig
10. rules kopiëren

*********************************
1.  libusb

sudo apt-get install libusb-1.0-0   of 

sudo apt install libusb-1.0-0 mag ook

U ziet  dat ik zelf de syntax verkeerd had ( libusb-1.0.0 ipv libusb-1.0-0 ) maar hij heeft dit zelf gecorrigeerd !


*********************************
2. build essential

 Bij mij zat deze er al in , nl V12.6


sudo apt-get install build-essential  



*********************************

3. Git installeren , met git kan je software  ergens op het internet " clonen" of overhalen uit een grote bibliotheek  , repository genoemd.

sudo apt-get install git

Dit is wat er gebeurt als je op voorhand geen update hebt gedaan . Hij heeft zelf wel aan dat je dit eerst moet doen ( gele kader)


********************************* 


4. Cmake installeren .

  
 sudo apt-get install cmake

Dit hebben we straks nodig om de software te maken

*********************************
 Vanaf nu zijn we klaar om osmocom  rtl-sdr codebase te installeren

5. rtl-sdr codebase  clonen  (internet moet aanwezig zijn !)

git clone git://git.osmocom.org/rtl-sdr.git

Laat hem gewoon zijn werk doen , kijk of er geen foutmeldingen zijn.



 Kijk na of ge volgende inhoud in de map hebt met commando 

ls -al

 

 Ge ziet dat er een map bijgemaakt is , nl      rtl-sdr

Ga naar die map met 

cd rtl-sdr

maak een nieuwe map aan met 

mkdir build

ga naar die map met 

cd build  

en nu komt het grote werk : de software die daar net is overgehaald dat zijn enkel de bronbestanden . Die moeten nog gecompileerd worden en op de juiste plaats gezet worden .


*********************************
 6. Compileren 


Dit gaan we nu doen met het volgende commando.
 
cmake ../ -DINSTALL_UDEV_RULES=ON



Ik heb nooit geweten wat die regel in de hoofdletters betekende maar nu weet ik het wel . Dankzij die regel kan men de dongle ook als gewone user ( dus hier pi ) en moet men niet deze aanroepen als root

*********************************

Volgende commando in de rij is    make

7. make

Deze twee laatste commando's ( cmake en make) dat kan een tijdje duren  


 *********************************


 Installeren van de soft

8. sudo make install


Ook hier gewoon zijn werk laten doen 

en als laatste alles nog configureren 


*********************************
9. sudo ldconfig  

Gewoon alles op zijn plaats zetten 

*********************************  

10.rules kopiëren  

Ga naar map rtl-sdr met  cd .. ( in de veronderstelling dat je nog altijd in map build staat)

kopieer de rules naar de map waar het behoort.

sudo cp rtl-sdr.rules  /etc/udev/rules.d/

Dit bestand is trouwens gewoon een tekstbestand waar de vid en pid in vermeld staan . 

vid = vendor ID
pid = produkt ID 

Hier een extract eruit met onze rtl2832u

*********************************

Het is nu tijd om te rebooten . Sluit de rpi zero w af door de spanning uit te schakelen , steek de sdr dongle in de usb poort via kabeltje en zet de rpi terug onder spanning . De verbinding met Putty zal verbroken zijn , ook deze moet je terug opstarten en daar inloggen .
 
Na dit tienstappenplan is het al mogelijk om een test te doen .
Typ het volgende in Putty in nadat je weer bent ingelogd:

rtl_test

Dit zal je te zien krijgen :

Goed en niet goed !
Goed , hij herkent de dongle via de usb poort ( found 1 device ....)
Niet goed : er is een interface error , maar dat gaan we oplossen in de volgende aflevering

Een nieuwe lente, een nieuw geluid [RPI zero w met SDR : de droom ]

Een nieuwe lente , een nieuw geluid !

Wat als ?

We een rpi zero w konden  voorzien van een basis SDR  uitrusting , de data over wifi konden versturen en de decoding op afstand zouden doen ?
Maw , we maken een compact geheel met de ontvanger " ergens" en sturen deze aan vanuit een laptop.
We kunnen dan ook kiezen wat we willen ontvangen / decoderen door gewoon een andere toepassing te starten.Misschien kunnen we ons zelf eens wagen aan GNU radio !

GNU radio

Dit concept zal wel ergens al bestaan , maar ik doe het zoals ik het wil.
Lopen we tegen de muur , dan is het zo maar .

We vertrekken van de osmocom rtl-sdr codebase en we zien wel verder.

Link naar osmocom

osmocom.org

De  rtl-sdr  codebase omvat :

1. librtlsdr : deze bibliotheek voorziet dat op de uitgang van de dongle raw I/Q date ter beschikking staat.
2. Enkele commandolijn tools :

• rtl_test : hiermee kun je testen of de dongle werkt
• rtl_fm : een kleinde fm decoder , parametreerbaar . Op de uitgang heb je pcm audio direkt beschikbaar voor een audiospeler zoals aplay
• rtl-sdr zelf : een I/Q recorder , een soort gateway tussen dongle en achterkomende software
• rtl_tcp : een I/Q spectrum server : ook dit neemt de data van de dongle en geeft zelf I/Q af en dit over TCP/IP 

Deze laatste twee komen zekers in aanmerking .



De librtlsdr is zelf nog afhankelijk van een andere bibliotheek en dit is

• libusb : Omdat de dongle via een usb poort is verbonden is deze nodig.

We vertrekken van een vers raspbian Buster sd kaartje en bouwen zo verder op.
Dit kaartje is al volledig ingesteld wat de configuratie betreft , zoals wifi en is bereikbaar via Putty. dit is al meermaals beschreven overal , zelfs op deze blog.


Eerste vragen die in me opkomen  : Waar knippen we in de dataflow ?
Wat sturen we over de wifi en hoe doen we dat ?

WXbalonnen [debugverhaal episode 6 : Nu ook op Radiosondy.info ]

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

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.

SDR : [ verdere testen]

Nadat dit alles eens is bezonken komen er verdere vragen te voorschijn , wat als ....

1. Wat gebeurt er als ik twee instanties van rtl_fm wil opendoen zodat ik twee stations tergelijkerijd wil beluisteren ?

Dit is het antwoord:

Het is niet mogelijk !


2. Maar wat als we via de server/client configuratie werken ?

Wel een klein beetje wel .

U kunt geen twee instanties oproepen ( lukt mij nu toch niet) maar ge kunt wel twee of meerdere frequenties in de configfile meegeven, zolang je maar in een bandbreedte blijft van 2 MHz

Zie afdruk.

Je kunt wel beide kanalen opmixen in één audiokanaal ( - m2) , maar ik slaag er niet in ze apart te beluisteren . Zie de stereo vumeter.

Dit is dus via de audiostream . Naar wat ik nog weet van vroeger is dat via de tcp verbinding wel meerdere decoders kunnen werken . dit was toch zo bij de weerballonnen .

Misschien voor laters .

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.

 

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.

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:

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.

Radiosondes op HabHub [ deel 2 ]

Op aanvraag van de QRP heb ik ook eens tussendoor getest of je een radiosonde/wxballon decoder kunt installeren in een zogenaamde docker omgeving.
Ik kende dat niet maar dankzij de QRP en wat opzoekwerk op internet was het vrij simpel dit te installeren .

Ge kunt dit op veel OS-en . bij de QRP loopt dit op een NAS en bij mij natuurlijk in Linux.

Docker is een systeem dat , op mijn manier uitgelegd, een afgeschermde omgeving creëert waar de soft en alle bibliotheken samenzitten en op " zijn eigen" draait .
Ge haalt via een pull een image over die je daar parkeert en van die image maake je één of meerdere containers waarmee uiteindelijk je applicatie draait .
De communicatie loopt in dit geval over een lokale verbinding tussen twee gekoppelde poorten op je localhost.
In feite kun je het een beetje zien als een instantie ( container) van een klasse (class)( image)  in een hoger programmeertaal maar dan uitgebreider.

Enfin , ik bespaar je de installatie maar laat je wel het resultaat zien .

Dit is op localhost

En dit is via de link op Habhub. Ge ziet de groene lijn dat bewijst dat ik de data doorstuur naar Habhub.

Dit was de ballon van Ukkel op woe 18 mrt 2020 en het laatste contact toen hij terugviel en nog 1201 m hoogte had.


En dit is er links te zien tijdens de vlucht. De ontvangsstations worden ook meegegeven.

Hier nog de link naar pull voor radiosonde in docker


pmta/radiosonde

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.

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)

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

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 .

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.

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.

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

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.

debug

Dit is voor een volgende aflevering.