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.

Interludium [ De framboos aka Raspberry Pi : eindelijk ! dump1090 in werking ]

Het enige wat ons nu nog te doen staat is de toepassing laten lopen .

Sluit een antenne aan , steek de dongle in de USB poort en start de rpi op.

Na inloggen gaan we naar de dump1090 map met

cd dump1090

en starten we op de commandolijn met :

./dump1090 --interactive

u krijgt iets in de zin van :

Als je dit ziet , loopt de soft .
We kunnen het aanschouwelijker maken  door het volgende:

Verlaat eerst met <CTRL>  C het scherm.

Daarna start je met :

./dump1090 --interactive --net

Op het eerste zicht zie je hetzelfde , maar ondertussen loopt er wel een webserver die je kunt oproepen in een browser.

Typ in je browser op de adresbalk ( url) het volgende in :

uw-ipadres van uw rpi zero w :8080

bv  192.168.1.125:8080  en kijk wat er gebeurt !

 Wat u hier ziet is met weliswaar een zelfgemaakte antenne maar wel in huis op de begane grond en met enkel een rpi zero w en een SDR dongle .
Antennehoogte 1m50 !

Indien u dit buitenshuis zet ( bv in uw tuinhuis), maar wel in het bereik van uw wifi, kunt ge in huis alles gemakkelijk volgen .

Veel plezier ermee.

ps: ook eens de processor - en geheugen belasting bekeken met de browser open 

 CPU  ca 40 % en slechts 45 MB aan ram ! Toch niet slecht voor deze lilliputter

Interludium [ De framboos aka Raspberry Pi : de oplossing van het fout-compileren]

Nu we dit allemaal weten , is de oplossing slechts vijf minuten werk.
Zo gaat het altijd , de weg ernaar toe is altijd de  lastigste klus .

We openen het bestand in nano , maar zorgen eerst dat we in de juiste directory zitten .

 cd /usr/local/lib/pkgconfig

daarna openen van het bestand:

sudo nano  librtlsdr.pc

en vullen we de lege velden in zoals in de bijlage getoond. Let goed op de allerhande leestekens zoals $ en { ...
U ziet ook de verwijzing naar onze arm-linux processor architectuur.

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/arm-linux-gnueabihf
includedir=${prefix}/include

Name: RTL-SDR Library
Description: C Utility Library
Version: 0.6.0-22-g3d7c
Cflags: -I${includedir}/
Libs: -L${libdir} -lrtlsdr
Libs.private:  -lusb-1.0

Bewaren met

 <CTRL> o en  <ENTER> afsluiten met <CTRL> X

Misschien is het best om toch maar eens te herstarten 

sudo reboot 

Na herstart  gaan we terug naar onze dump1090 map met 

cd dump1090

en voeren we opnieuw het make commando uit.

sudo make  

Het resultaat is al volgt , let niet op de warnings

 Geen errors , opdracht volbracht!

Interludium [ De framboos aka Raspberry Pi : de finale , de foutopsporing van het compileren.]

Foutopsporing.

Hiervoor ben ik enkele dagen in de weer geweest.
Eerst uitzoeken hoe het make script in elkaar zit , dan opzoeken waar het script naar verwijst en dan proberen te interpreteren hoe alles aan elkaar hangt.
Ik moet zeggen dat ik alles eerst nog eens naar een raspberry 2 overgezet hebt , maar daar dook hetzelfde probleem op.

Kort analyse van het make-script ( Makefile). ik ga hier niet in detail wat al die argumenten doen maar enkel de hoofdbrok.

In weze is het script zo opgebouwd:


target:afhankelijkheden
<TAB> recept

<TAB> of inspringen is verplicht !

Hieronder een voorbeeld uit een extract van de Makefile:

dump1090 is hier het target en alle bestanden met .o zijn de afhankelijkheden
vanaf $(CC) komt het recept ( hier aanroepen van de compiler en de nodige bibliotheken ($(LIBS))

dump1090: dump1090.o anet.o interactive.o mode_ac.o mode_s.o net_io.o

$(CC) -g -o dump1090 dump1090.o anet.o interactive.o mode_ac.o mode_s.o net_io.o $(LIBS) $(LDFLAGS)

$(LIBS) is eigenlijk een variabele die hogerop is gedeclareerd ( hier niet te zien) maar hieronder toch opnieuw is weergegeven

LIBS=`pkg-config --libs librtlsdr` -lpthread -lm

Hierbij is de verwijzing naar de pkg-config van groot belang.
pkg-config is in feite een soort script dat de bibliotheken weet zitten .
Elk operatingssyteem heeft zijn eigen architectuur aan boord ( bv een x86-64 of  in dit geval bij de rpi  een ARM processor.)
Afhankelijk van deze arch. moet er anders gebuild worden .
Om uw software voor alle van deze architecturen te kunnen laten werken is er een " agent" nodig die u de weg wijst.
Deze verwijzing voor de bibliotheek van de  rtl-sdr  zit in een bestand dat librtlsdr.pc   zit . Het is dit bestand dat nodig is om juist te kunnen compileren.
Alle verwijzingen voor de pkg-config hebben een extensie die eindigt op .pc 

Eerst zoeken we waar  librtlsdr.pc   zich bevindt.Vanop de root zoeken we met

sudo find -name librtlsdr.pc

Het antwoord ziet U hieronder

Er zijn meerdere antwoorden ,maar  /usr/local/lib/pkgconfig is het juiste.

Let ook op dat pkgconfig ook in het pad zit !

We gaan naar daar met :
 cd /usr/local/lib/pkgconfig

en kijken wat er in librtlsdr.pc zit met

 cat -n  librtlsdr.pc

 

 Deze ziet er nogal leeg uit vind ik , vergelijk hem eens met het bestand dat op mijn linux desktop staat. Let ook op het andere pad in de desktop !

Hier zijn wel de eerste regels ingevuld !

Hier moet iets aan gedaan worden , dit is in een volgende aflevering.
eerst koffie drinken ;)

Interludium [ De framboos aka Raspberry Pi : de finale , een toepassing met dump1090 die fout afloopt]

Om te laten zien de rpi zero w nu in staat is toepassingssoftware te draaien gaan we het ADS-B pakketje genaamd dump1090 hierop installeren .

Althans , dat was de bedoeling maar ik stuitte tegen héél wat problemen nochtans had ik deze soft reeds meerdere malen kunnen doen draaien .
Volg hieronder mijn lijdensweg 

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

Allereerst voordat ge iets nieuws doet , updaten van uw lijst.

sudo apt-get update

en eventueel ook

sudo apt-get upgrade

zo staan we weer in sync met de laatste soft.

Dan via Putty

maak dat je in de home directory staat

met  
cd ~   of  ( tip : de <Page Down> key geeft ook een tilde (~) af )
cd /home/pi
je kunt dit checken met 

pwd 

de  ~ is de home directory en
de $  is de prompt van de user , hier duidelijk gemaakt in het gele kader

Nu zijn we klaar voor dump1090.

De mosterd komt van hier uit Github

https://github.com/MalcolmRobb/dump1090

Ook hier komt het git commando van pas:

sudo git clone git://github.com/MalcolmRobb/dump1090.git

Vervolgens veranderen van map, aangemaakt door git

cd dump1090

en compileren met

sudo make 

en vanaf hier loopt het allemaal mis.

Het make commando roept de Makefile op waar een script in staat om het          " builden" uit te voeren .
Het compileren naar objectbestanden ( bv dump1090.o ) gaat goed ( --cflags ) maar het omzetten en verder linken met de bibliotheken gaat grof in de fout .
De gekleurde opmerkingen in de gele kader zijn geen fouten maar waarschuwingen . Dat is in elk geval niet de boosdoener. Het loopt mis vanaf de rode kader.