jul 222019
 

Het is altijd een gok, vooraf al vertellen wat je aan het uitproberen bent. Maar ik deed het toch en dat betekent (uiteraard?) doorgaan totdat er een acceptabel resultaat binnengehaald wordt.
Gisteren schreef ik dus al over de uitdagingen bij het installeren van de scripts op de Raspberry Pi. Ik had de antenneset van RTL-SDR opgesteld volgens de specificaties van deze site. In eerste instantie had ik de antenne op zolder aan de binnenkant van het dakraam bevestigd.

Lees verder….

Deel dit bericht:
jul 212019
 

Na mijn initiële bericht over mijn cheapo RTL-SDR dongle was dat natuurlijk niet het einde van de experimenten. Daarom dit bericht met wat updates.

FM-ontvangst
Allereerst een aanvulling op de slechte FM-ontvangst (zie ook deze tweet). Dat bleek toch een gevalletje onkunde aan mijn kant te zijn. Ik kwam bij toeval dit Python-script tegen waarmee je een heel eenvoudige webinterface kunt maken voor rtl_fm (het tooltje dat ik op de Raspberry Pi gebruikte voor het luisteren naar radio). Op zich was het script niet zo spannend, maar naast de WBFM modulatie die ik gebruikt had, stond daar ook de optie voor FM modulatie tussen. En die zorgde voor een veel betere ontvangst van die stations.
Ok, prima, hij kan dus in ieder geval net zo goed als een normale radio ontvangen.

ADS-B en AIS ontvangst
Hoewel mijn dongle geen ADS-B signalen kan ontvangen, zou hij technisch gezien wel in staat moeten zijn om AIS-signalen te ontvangen. DIt is een systeem waarmee de transponders op boten en schepen gevolgd kunnen worden.
Op deze website staat de uitleg over hoe je e.e.a. kunt installeren op Raspberry Pi als “server” en dan je laptop als ontvanger. Helaas zit ik waarschijnlijk té ver van schepen af óf het gegeven dat ik de antenne nog in V-vorm had staan (in plaats van zoals hier aangegeven in rechte lijn) zorgde voor te slechte ontvangst. Ik kon in ieder geval niets ontvangen.

Gelukkig is er ook een website waar je al deze boten en signalen kunt volgen: http://www.scannernet.nl/maritiem/live-ais
Leuk op die site is ook dat de site op de pagina’s een livestream heeft van marifoonverkeer tussen onder andere de Zeeverkeerscentrale Brandaris. Ik kan het iedereen aanbevelen om hier gewoon een uurtje mee te luisteren, heel rustgevend.
Ze hebben meer scannerkanalen online staan: een aantal lokale kanalen en je kunt meeluisteren met luchtvaartverkeer.
Voor dat laatste kun je ook terecht op LiveATC.net, daar kun je dan specifieker kiezen met welk kanaal je mee wilt luisteren. Zo kun je bv kiezen om specifiek naar de Verkeerstoren in Eindhoven luisteren waarbij je de communicatie hoort vanuit Vliegveld Eindhoven met vertrekkende en aankomende vliegtuigen.

Omdat ik dicht genoeg bij Eindhoven zit kon ik gisterenavond (heel zwakjes) een deel van dat radioverkeer rechtstreeks met de RTL-SDR opvangen. Maar ook hier met de aantekening dat ik de antenne qua lengte (en vorm) niet optimaal voor de 122.100Mhz waarop ik wilde luisteren.

De antenne zit nu even op het raam vast in V-vorm met hoek van 120-graden ertussen en lengte van 53,4 cm per poot (volgens deze instructies) in afwachting van een volgende doorkomst van de NOAA-satellieten. Want uiteraard was het grote andere doel van de RTL-SDR natuurlijk: het ontvangen van foto’s van een weersatelliet.

Raspberry Pi NOAA Weather Satellite Receiver
De kans op echt goede foto’s was/is bij voorbaat al heel klein, maar ik neem op dit moment al genoegen met íets van een herkenbare satellietfoto. Het zou in theorie moeten kunnen ook met mijn beperkte RTL-SDR ontvanger met de antenne in zijn V-configuratie.
Er zijn een aantal manieren om de afbeeldingen te ontvangen, de meest “ideale” (als hij werkt!) is automatische ontvangst op een Raspberry Pi. Dat zou dan “installeer en vergeet” moeten zijn. Nou, dat is dus zeker niet zo. De eerste tutorial die ik gebruikt heb is deze:

De bijbehorende tekst is hier te vinden. De shell-scripts zijn hier te downloaden. WXtoImg is niet meer beschikbaar op de plek waar hij oorspronkelijk te vinden was, maar wel hier. Daarnaast gaf het tooltje Predict heel wat problemen. Als ik het op de gebruikelijke manier installeerde, via apt-get, dan liep hij vast op de Raspberry Pi. Op mijn Linux subsystem op Windows 10 deed hij het dan prima. Uiteindelijk heb ik de net wat nieuwere 2.2.5 versie vanaf Github gedownload en gecompileerd. Die werkt wél.
Daarna was het even uitzoeken welke NOAA satellieten ik moest hebben. Volgens Predict zouden dat #14, #15, #17 moeten zijn. Ergens anders las ik echter dat alleen #15, #18 en #19 in gebruik waren. De nieuwere versie gaf alleen #15 en #18 aan, dus ik ben uiteindelijk maar voor de “standaard” keuze van het script gegaan. Afwachten.

Toen ik het script afgelopen nacht had laten draaien had ik eigenlijk gehoopt vanochtend foto’s (goed of slecht) te vinden. Maar de map op de Raspberry Pi was helemaal leeg.

Ik kreeg het met deze set scripts niet aan de praat, sowieso bleek het debuggen ingewikkeld en ben daarom uitgeweken naar deze oplossing. Ook die bleek niet zomaar te werken. Het blijkt dat een aantal mappen niet aangemaakt worden bij de eerste keer uitvoeren én dat een aantal van de scripts root-rechten nodig hebben omdat ze anders geen bestanden mogen aanmaken in de mappen die voorzien zijn in het script. Een van de scripts (sun.py) werd niet gevonden in het pad, er ontbrak een Python library op mijn Raspberry Pi (sudo pip install pyephem) , omdat ik een aantal scripts nu als root aanriep, vond WXtoImg dat ik opnieuw akkoord moest gaan met de licentievoorwaarden, kortom er ging van alles mis.
Daarnaast bleek de dongle toch wat teveel van het goede als hij rechtstreeks op de Raspberry Pi aangesloten werd, dus daarom zit er nu een powered USB-hub tussen.

Klaar om te testen….

Dat moet nog even wachten. De volgende overkomst van de satelliet is namelijk pas om kwart over vijf vanmiddag. Daarom nu maar alvast even opgeschreven wat de stand van zaken is. Met op de achtergrond scannernet en de verkeerstoren van Eindhoven. Ik zou wel graag hebben dat ik bij  scannernet net als bij de verkeersfrequenties ook zou kunnen kiezen voor één frequentie waar hij dan op afgesteld blijft staan. Nu schakelt hij vaak  tussen de havendienst en Brandaris.

Kortom…wordt vervolgd…

 

Deel dit bericht:

Stoeien met een RTL-SDR dongle

 Gepubliceerd door om 00:08  Hardware, RTL-SDR
jul 192019
 

Het begon met een filmpje van Andreas Spiess (zoals wel vaker) waarin hij laat zien dat hij met een RTL-SDR dongle de signalen van zijn 433Mhz zenders decodeert. Toen ik zag dat je zo’n dongle al voor minder dan 10 euro op AliExpress kon kopen was ik verkocht. Zeker omdat ik op RTL-SDR.com een lange lijst van mogelijkheden had gezien.

Ik bestelde deze dongle, ik zal je zo uitleggen waarom dat geen goede keuze was.

Toen hij binnenkwam, lukte het al redelijk snel om in ieder geval LoraWAN / The Things Network signalen zichtbaar te maken (zie hier), het ontvangen van FM-radio viel nogal tegen (zie hier).

Het zichtbaar maken van signalen van thermometers en andere 433 Mhz ontvangers gaat prima. Op deze github-pagina kun je de binaries downloaden voor Windows, maar je kunt het ook op bv een Raspberry Pi installeren (zie ook deze uitleg).

Luisteren naar DAB+ (digitale) radio gaat beter dan naar analoge FM-radio. Met dank aan http://welle.io/ (gratis) kun je automatisch naar kanalen laten zoeken en dan luisteren:

Overigens: ik heb inmiddels al een betere antenne gekocht (niet zelf gemaakt) want ook voor de ontvangst van DAB+ bleek de bijgeleverde antenne (zoals overal aangegeven) niet voldoende.

Lees verder….

Deel dit bericht:
jun 192019
 

Last Monday I took my TTN-mapper node with me in the car driving from home (Deurne) to Nijmegen, to Arnhem, to Veenendaal and back home again in the evening. The gateways found were not really surprising. None for most of the trip to Nijmegen, good coverage in Nijmegen and Arnhem (and in between) . But there was one gateway that surprised me. While driving through “De Rips” (population 1,179 in 2011) a total of 3 packages arrived at a gateway.

According to TTN Mapper and the metadata available at The Things Network, this gateway was located in Bilthoven at the, 75 km from the place where the package was sent. On Monday I could not figure out what could have gone wrong. The gateway was registered by the RIVM, the coordinates registered was as the RIVM in Bilthoven. But 75 km sounded as too good (far) to be true (possible).

I’ll skip to the conclusion: it was, the gateway was not located in Bilthoven, it was much closer.

Today, Derko from the RIVM (the National Institute for Public Health and the Environment) contacted me by e-mail because he had seen my tweet about their gateway. I pointed him to the post (in Dutch) that I wrote about it. In his mail he had already explained that the gateway was indeed a Lorank 8 (and not a single channel gateway as TTN Mapper assumed, but since then has corrected) and was located indoors. This made the 75 km even more unlikely.

About half an hour after my reply, Derko responded again. He felt sorry for me, but had bad news. Reading about the location from where I had been able to reach their gateway, he realized that only recently, they had installed a new gateway at one of their locations where they measure air quality. And you might have already guessed: that location was close to De Rips, it was at Vreedepeel, about 3.5 – 4 km and not 75 km from the location of my node. The location data for that gateway had not been updated when it was installed.

Derko since then changed the data for the gateway, so it now correctly shows its location:

TTNMapper hasn’t updated it on the map yet (I’m guessing that is a batch process), but the change in location is listed on this page: https://ttnmapper.org/gateway_moves.php (search for 1DEE0348A7BB4EC8) so it should be corrected in not to long.

Am I sad that it wasn’t 75 km? No, not at all. It was highly unlikely and I’m happy that the puzzle has been solved (thanks Derko!). The RIVM gateway is not the only gateway that has incorrect location information.

I took the TTN-mapper node with me today in the train to Deventer and back. And in Deventer a gateway was active that has its coordinates set to South Africa. It confuses TTNMapper because it by default zooms out to a view where all the gateways are visible.

But I prefer to focus on the plausible “cool results”, like the fact that apparently I could reach the “Grote Kerk” in Deventer and het Kadaster in Apeldoorn (see map in tweet above) at the same time. Both about 12 km or 18 km from where I was. Still impressive.

 

Deel dit bericht:
jun 172019
 

 

Nu even de tweet, meer uitleg over SDR komt een andere keer.

Deel dit bericht:
nov 272018
 

Na de succesvolle test afgelopen zaterdag en de optimalisaties in de code op zondag (zie dit bericht) mocht de TTGO T-Beam gisteren en vandaag met me mee naar het werk.

Niet in de auto, maar in mijn rugzak in de bus en trein. Dat was gisteren (maandag) tamelijk teleurstellend. Behalve mijn eigen gateway kwam ik, totdat ik in Nijmegen was, onderweg geen enkele actieve gateway tegen. Mijn reis ging van Deurne met de bus naar Venray (Oostrum) en daarna met de boemel via Vierlingsbeek, Boxmeer, Cuijk, Mook-Molenhoek naar Nijmegen Heyendaal. Op zich klopt dat met de info op TTNMapper.org, die geeft daar ook geen actieve gateways (p.s. op moment van typen heeft TTNMapper wat problemen en worden *alle* gateways als offline aangegeven, dat is echter niet zo), maar de grote cirkels op de dekkingskaart deden hopen dat er toch wel ontvangst mogelijk was.
 
Hoe anders was dat vandaag. Toen moest ik namelijk door naar Arnhem. Ook nu tot Nijmegen geen ontvangst, maar vanaf Heyendaal naar Presikhaaf en de wandeling tot op het HAN terrein waren, qua ontvangst in ieder geval, perfect. Tijdens het stukje lopen waren er steeds minimaal 2 gateways die het bericht ontvingen. Het ziet er ook naar uit dat de “beweeg ik of niet?” aanpassing in het script goed werkt. Nu is het zo dat als de TTGO T-Beam wakker wordt (na 30 seconden) er eerst gekeken wordt of de huidige locatie minimaal 50 meter afwijkt van de oude locatie. Zo niet dan gaat de TTGO T-Beam weer 30 seconden in slaap (en als hij na 5 minuten nog niet bewogen heeft stuurt hij alsnog een bericht). Het aantal datapunten op de TTNMapper kaart is precies goed. Maar 1 datapunt terwijl ik op de bus sta te wachten, een viertal datapunten op station Nijmegen, maar daar verplaats ik me ook daadwerkelijk tussen perrons, maar 1 datapunt vanaf station Arnhem waar de stoptrein ongeveer 5 minuten still bleef staan.

Absolute uitblinker was/is een gateway die in Arnhem op een (hoog) flatgebouw staat (zie foto hierboven). Deze gateway was namelijk in staat om berichten te ontvangen vanaf Nijmegen Heyendaal, op ruim 14 km afstand. En dat met SF7, via een node die in mijn rugzak zat met een standaard kleine antenne. Ik vind het indrukwekkend, zeker ook gezien de compacte omvang van de TTGO T-Beam. Natuurlijk, niet iedereen kan een gateway met antenne op een flatgebouw zetten, maar afgaande op de beschrijving is ook dit een gateway op basis van een Raspberry Pi, dus zelfs al je stoer doet qua kabels, antenne etc. is dat een gateway die (zo schat ik) geen 1.000 euro gekost zal hebben. Ben jij de eigenaar van “home-made-second-ic880a-rpi3” en wil je meer vertellen over de gateway/kosten/plaatsing etc dan hoor ik het heel erg graag!!

Er komen nog wel wat dagen aan die de moeite van het tracken waard zijn. Volgende week dinsdag leg ik met de auto het traject Deurne – Druten – Roermond – Arnhem – Deurne af. En en een week later reis ik met de trein het traject Nijmegen – Zutphen – Apeldoorn (daar stap ik dan uit voor een paar uur en dan terug naar huis via) – Amersfoort – Utrecht – Den Bosch – Eindhoven – Deurne. Niet helemaal de route van april 2017 maar wel eentje die in de buurt komt. De TTGO T-Beam gaat beide dagen zeker ook mee.

Deel dit bericht:
nov 252018
 

Gisteren schreef ik over de TTGO T-Beam, een ESP32 met LoRa chip, GPS en een batterijhouder voor een 18650 Li-ion batterij gecombineerd. Ik had er het “standaard” script beschikbaar om hem als node voor TTNMapper.org in te zetten. Het script werkt, is nog lang niet geoptimaliseerd, maar het was goed genoeg voor een eerste test.

Hij ging gisteren mee, in de auto, naar Zuid-Limburg.  Gewoon voor op het dashboard. Zuid-Limburg is, zo kun je zien op TTNMapper.org niet  het gebied van Nederland met de beste dekking qua TheThingsNetwork. Conclusie is in ieder geval dat ik van de beschikbare gateways onderweg, het merendeel in ieder geval bereikt heb.

De maximale afstand die ik bereikt heb is 9,18 kilometer naar een gateway in Roermond. Dat vind ik niet slecht als je bedenkt dat ik op dat moment waarschijnlijk gewoon met een kilometer of 130 per uur over de A2 reed in een metalen doos. Ook daar ben ik zeker niet ontevreden over.

Belangrijkste minpunt van de eerste test gisteren was het gegeven dat de 3,7V 18650 oplaadbare Li-ion batterij niet eens een beetje in de buurt van de te verwachten capaciteit kwam. Dat was eigenlijk niet eens nieuws, YouTube staat vol van filmpjes waarin de exemplaren uit het Oosten getest worden en waarbij duidelijk wordt dat 9900 mAh een sprookje is. Ik heb helaas geen setup die de capaciteit van de accu goed kan testen. Maar na 3,5 uur stopte de eerste batterij er mee. Was wel 3,5 uur van continue werken en elke 30 seconden via TTN versturen van de coördinaten.

Lees verder….

Deel dit bericht:
nov 242018
 

Ruim een jaar geleden, april 2017, nam ik 2 LoRaWAN nodes mee op een treinrit van 2,5 uur. Een LoPy node en een Marvin node, een stevige powerbank en mijn smartphone werden gebruikt om data te verzamelen en te loggen.

Het idee was simpel, maar ook wel weer ingewikkeld:

Vergeet voor het gemak de Mavin node even, die maakte verbinding met KPN, dat doe ik vandaag niet. De LoPy node deed niets anders dan om de zoveel seconden te proberen een bericht via het TTN-netwerk te versturen met daarin de temperatuur / luchtvochtigheid die gemeten werden door een aangesloten DHT11.

Prima, maar ik wilde niet alleen de data doorsturen, ik wilde ook weten, als de data aan kwam, hoever ik dan van de betreffende gateway die de data ontvangen had af was. En tegelijkertijd wilde ik een bijdrage leveren aan de dekkingskaart zoals die op ttnmapper.org te vinden is. Die kaart geeft een beeld van de op dit moment beschikbare gateways en de plekken waar je zou mogen verwachten dat je data via het TTN-netwerk kunt versturen.

Om dat te doen draaide op mijn telefoon een app. Die app maakte verbinding (via 4G) met de server van het TTN-netwerk zodat hij daar kon kijken of de data van mijn LoPy node binnengekomen was. Als dat zo was, dan haalde de app ook de GPS-coördinaten van de gateway die de data ontvangen had op (die informatie wordt ook op de TTN-server opgeslagen), keek naar de GPS-locatie van mijn telefoon en stuurde die gecombineerde informatie naar de TTNmapper server. Snap je het nog?

Deze methode werkte eigenlijk best goed, maar had als nadeel dat de externe accu best groot was, mijn telefoon de hele tijd in de buurt moest zijn en de app moest draaien, de accu van de telefoon werd best wel belast omdat hij steeds dataverbinding en gps aan het gebruiken was. Kortom, niet echt ideaal om dagelijks te doen.

Inmiddels zijn we dus ruim anderhalf jaar verder en  ga ik vandaag een oplossing testen die een stuk compacter is. Ik maak dan namelijk gebruik van een TTGO T-Beam. De link is naar de verkoper op Aliexpress waar ik hem zelf besteld (en betaald) heb. Hij kost nu (op moment van schrijven), met verzendkosten € 26,06
Ik heb er zelf € 25,56 incl. verzendkosten voor betaald, de prijzen schommelen soms een beetje. Hou er rekening mee dat je de kans loopt dat je op de bestelling BTW (+21%) en inklaringskosten (+€12,50) moet betalen.

De TTGO T-Beam is een board op basis van een ESP32 met een NEO-6M GPS chip en een LoRa schip op het board. Aan de achterkant zit een grote batterijhouder. Niet voor een AA-batterij maar voor een 3,7V 18650 oplaadbare lion batterij. Ik heb er daar 2 van 9900 mAh gekocht bij deze verkoper met bijbehorende oplader (die had ik namelijk nog niet) voor totaal € 12,73 inclusief verzendkosten. Dus al met al ben je (zonder BTW en inklaringskosten) zo’n 38 euro kwijt aan deze setup. Dat is duurder dan de goedkoopste LoRaWAN node die je kunt krijgen, maar goedkoper dan een LoPy of Warvin node, zeker als je een externe accu erbij moet kopen.

Het voordeel van deze setup is dat je geen gebruik meer hoeft te maken van je telefoon. De TTGO T-Beam heeft zijn eigen GPS aan boord en stuurt die data door naar de TTN-server. Daar kun je een rechtstreekse verbinding maken met de TTNmapper server en er voor zorgen dat die GPS data doorgestuurd wordt en gebruikt kan worden.
Hoe dat moet wordt hier allemaal uitgelegd inclusief de code die je op de TTGO T-Beam moet zetten.

Het werkte allemaal meteen. Ik moest eerst een minuut of 10 wachten voor de GPS fix. Dat had ik ook wel verwacht omdat ik binnen was en het de allereerste keer was dat de node op zoek ging naar de GPS. Ik weet nog niet hoe lang dat normaal buiten gaat duren. Voor nu laat ik hem gewoon even aan staan.
Ik heb ook nog geen idee van de batterijduur. Ik neem hem vandaag mee in de auto, mocht de batterij echt heel snel leeg zijn, dan heb ik eerst een reservebatterij en anders gaat hij gewoon aan de 5V aansluiting van de auto (dat is in de trein idd wat moeilijker, dus ik wil wel even weten hoeveel uur hij dit vol houdt).

Het aardig bij TTNmapper is dat ik nog steeds kan zien welke data mijn specifieke node aangeleverd heeft, dat betekent dat ik vandaag ook kan zien of er data binnen komt. Niet zo live en realtime als met de app (die zelfs een geluidje liet horen bij dataontvangst) maar goed genoeg om een idee te krijgen.

En natuurlijk is er nog ruimte voor uitbreiding. Deze node heeft geen ingebouwd micro-SD kaart slot zoals sommige anderen wel al hebben, dus lokaal loggen van de data zodat ik kan zien hoeveel data niet ontvangen wordt, is nog niet mogelijk. Ik heb wel externe uitbreidingen die dat kunnen doen, maar dat vergt dan ook even wat aanpassing in de code.

Mooi is dat de TTG T-Beam in een stevig doosje geleverd wordt. Ik moet nog even een gaatje in de zijkant boren voor de antenne, dan kan hij hiermee ook eenvoudig en veilig mee in de trein. Wordt vervolgd.

 

Deel dit bericht:
feb 252018
 

Om te kunnen experimenteren met nodes die via LoRaWAN verbinding maken kun je in Nederland gebruik maken van KPN (niet gratis, landelijke dekking) of The Things Network (wel gratis, nog geen landelijke dekking). Hier in mijn dorpje heeft The Things Network (TTN) nog geen dekking, dus als ik met nodes wilde testen, maakte ik tot nu toe (het afgelopen jaar) gebruik van de goedkoopste tussenoplossing die er is: een single channel gateway. Dat is in mijn geval een LoPy (op basis van deze uitleg).

Maar een jaar verder en inmiddels van mening dat ik ook gewoon de investering wil doen om een “echte” TTN Gateway online te brengen. Dat kost geld en wat werk. Want ik ging natuurlijk niet voor een kant en klare black box, maar voor de combinatie van:

De antenne is nu nog een “gewone” 868Mhz “Whip” antenne omdat de definitieve plaatsing nog een onderwerp van onderzoek is. Ik vind het prima om een buitenantenne zoals de GP901C of SDBF0.5-868 op de schoorsteen te bevestigen (via een extra muurbeugel), maar de vraag is nog even of ik zelf tot zo hoog ga komen. Voor het proefdraaien kan deze antenne ook nog gewoon even.

Het samenstellen van de hardware was niet ingewikkeld, omdat ik heel lui voor de kant en klare backplane gekozen had, kwam er geen solderen aan te pas en was het een kwestie van het in elkaar drukken van Raspberry Pi, backplane en concentrator.

Het installeren van de software bleek iets meer werk dan verwacht, maar zoals zo vaak, ziet het er zo meteen in de beschrijving hieronder ongetwijfeld heel eenvoudig uit. Naar aanleiding van de eerste TTN conferentie vorige maand had ik namelijk een verwijzing naar resin.io voorbij zien komen. Dat is een online dienst die het mogelijk maakt je gateway op afstand in te richten en te beheren. Daar wilde ik ook gebruik van maken.

Lees verder….

Deel dit bericht: