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:
feb 192018
 

In de categorie “grappig” valt de tweet van The ThingsMaastricht. Ook daar werken ze aan het in kaart brengen van het bereik van de opgestelde TTN gateways. Dat doen ze niet lopend, niet met de fiets, niet met de auto. Nee, gewoon met de bus.

Ik neem aan dat een buschauffeur van een van de stadsbussen in Maastricht een tracker met zich mee neemt tijdens de ritten. Kan zonder problemen lijkt me omdat je het apparaatje maar gewoon ergens hoeft neer te leggen en het de chauffeur tijdens de rit verder niet afleidt of zo.

Deel dit bericht:
feb 082018
 

De kans is groot dat je bovenstaande video al gezien hebt, maar ik wilde hem hoe dan ook hier nog even opnemen. Andreas Spies heeft een uitgebreide test uitgevoerd van de ESP32 bordjes voor LoRaWAN waar ik ook eerder mee aan de slag was. De conclusie is hard maar duidelijk: de bijgeleverde antennes zijn knudde. Op zich geen gigantisch probleem, die kan ik vervangen, maar het maakt wel duidelijk (samen ook met de discussies op het TTN forum over antennes) dat antennes uit China niet echt verstandige aankopen zijn.
Voor het overige moet ik bekennen dat ik een deel van zijn uitleg niet kan volgen, met name daar waar hij de prestaties van de verschillende LoRa componenten gaat vergelijken. Ik heb dus nog wat te leren.
Niet iedereen geeft de video een duimpje omhoog, ik kan niet helemaal achterhalen waarom niet. Er is één kijker die inhoudelijke bezwaren heeft als het gaat om de manier van testen. Die discussie moet ik even aan me voorbij laten gaan.
Er is inmiddels een versie 2 beschikbaar van de nodes, ook die heeft Andreas in bestelling om te testen. Wordt dus vervolgd.

Deel dit bericht:
jan 302018
 

Nee, ik heb geen plannen om Jody Foster na te doen, al was het maar omdat het letterlijk kilometers buiten mijn kennisdomein ligt, maar het is wel grappig hoe sommige zaken schijnbaar gelijktijdig plaats vinden:

Komende week is in Amsterdam de eerste conferentie van The Things Network. Ik ben er niet bij, is me privé wat prijzig, ja, ik zou zaterdag kunnen gaan, dan is het betaalbaar, maakt ook niet uit, ik ben er niet. Maar een van de dingen die ze voor de conferentie geregeld hebben is dat, met dank aan ESA , Space Norway en Norwegian Space Centre, de NORSAT-2 satelliet tijdens de drie dagen van de conferentie, LoRa berichten vanuit de ruimte (ongeveer 600 km hoogte) uit zal zenden. Op het conferentiegebouw zal een ontvanger staan om de tekstberichten te ontvangen en op een scherm weer te geven.

Anderen zouden ook in staat moeten zijn om de berichten te ontvangen, je hebt alleen maar een SX1276 module nodig die je op 169Mhz moet instellen en een antenne die goed werkt rond de 162Mhz frequentie. Nou heb ik een SX1278 module (was eigenlijk een foutje want normaal gesproken heb ik daar niets aan in NL), nog geen antenne voor die frequentie, dus waarschijnlijk gaat het mij niet lukken (ondanks alle vriendelijke uitleg van Jose Marcelino via Twitter). Wie dat ongetwijfeld wel zou kunnen is de amateur astronoom die eigenlijk op zoek was naar de onlangs kwijt geraakte, geheime, Zuma satelliet en die daarbij per ongeluk de IMAGE satelliet terug vond waarvan de Nasa in 2005 geconcludeerd had dat die “dood” (lees: stuk) was (bron).

Nasa heeft inmiddels bevestigd dat het inderdaad de verloren gewaande satelliet is. Maar ze hebben een probleem dat een beetje lijkt op dat van mij: ze hebben (niet meer) de juiste hardware en software. Die is sinds 2005 namelijk dusdanig gewijzigd dat ze niet zomaar meer in staat zijn om de signalen van de satelliet op te vangen en te verwerken. Mooi toch? 🙂

Voor wie de achterliggende technologie wél snapt, is de serie berichten van Scott Tilley, de man die IMAGE terug gevonden heeft, zeker de moeite waard.

Deel dit bericht:
jan 162018
 

OK, hier wordt ik dus enthousiast van, al is het niet eens echt heel veel goedkoper dan de kant en klare oplossing waar ik vorige week mee geëxperimenteerd heb. Het blijkt namelijk mogelijk om een node met sensor voor het LoRaWAN netwerk / The Things Network te bouwen op basis van een ATtiny85!

Dus, gewoon op basis van die microprocessor, die zo’n 80 eurocent kost als je hem uit China laat komen en die we hier tot nu toe gebruikten om LEDs in een kleine kerstboom aan te sturen of papercircuit kerstkaarten te maken. Diezelfde chip kun je gebruiken als de basis van een meetapparaat waarmee je de lokale temperatuur, vochtigheid en luchtdruk tot kilometers ver door kunt geven.

Ok, ok, je hebt nog een paar andere dingen nodig. Bijvoorbeeld de sensor voor die drie waarden, in dit geval een BME280, die kost zo’n 2,5 euro per stuk. En je hebt natuurlijk ook een chip nodig die het LoRa-deel van de communicatie voor zijn rekening neemt. Er wordt hier gebruik gemaakt van een RMF95  en die kost nog steeds nog een euro of 4-5. Betekent dus dat het meetstation (zonder behuizing, bekabeling, batterijhouder etc) nog steeds zo’n 7-8 euro per stuk kost. Dat is maar een paar euro goedkoper dan die kant en klare oplossing die ik kocht.

Maar in de categorie “omdat het kan” en “omdat het cool is om te zien dat zo’n klein ding zoiets indrukwekkends kan” schreeuwt het natuurlijk om een test (sorry, volgende vakantie duurt nog even). De beschrijving hier gaat nu nog uit van het resetten van pin PB5 zodat het een gewone I/O pin wordt (ipv de reset pin), maar dan kun je daarna niet/slecht heel ingewikkeld de ATtiny85 herprogrammeren. Op het forum wordt al gesproken over een oplossing waarbij dat niet langer nodig is.

Bij de beschrijving staat niet hoe lang deze specifieke constructie mee kan op een set batterijen. Ook dat zou een leuke test zijn. Gaat op het verlanglijstje om te bouwen.

Deel dit bericht:

RP-SMA versus SMA

 Gepubliceerd door om 22:41  Hardware, LoRaWAN
jan 142018
 

Als je een antenne wilt aansluiten op een node voor bv The Things Network dan heb je meestal een kabeltje van het printplaatje naar een SMA aansluiting waar je de antenne op vast draait.

Het is belangrijk om even goed te kijken of daar niet “RP-” (reversed polarity) voor staat, want die twee passen niet op elkaar.

Het idee is dus dat je een SMA Male (bv je antenne), mét pinnetje, aansluit op een SMA Female (het kabeltje naar je printplaat, zónder pinnetje). Heb je echter een RP-SMA antenne, dan heeft de antenne geen pinnetje en moet juist de aansluiting aan de kabel een pinnetje hebben.

Goed, kijk even naar de plaatjes: een SMA Male hoort bij een SMA Female en een RP-SMA Male hoort bij een RP-SMA Female. Andere combinaties gaan in het geval van zo’n antenne / kabel niet werken.

(als je dit nooit nodig gaat hebben in je leven, dan geen probleem, maar ik had een kabeltje stuk en moest een vervangend kabeltje vinden/bestellen)

Deel dit bericht:
jan 132018
 

Time for part 2 of the post about getting the “cheap” Chinese ESP32 + SX1276 board connected to The Things Network.

The picture in this and the other post shows the board with a DHT11 temperature and humidity sensor already connected. I stopped using the small case that was on sale, because with the pinheaders soldered to the board and dupont cables connected to it, it no longer fitted.

Also, I am no longer using the small antenna that was provided with the board. I seem to have accidentally twisted the cable that you use to connect the SMA socket to the U.FL IPX connector on the board. The only suitable antenna I had available, was one that was provided as part of the LoPy kickstarter kits (which apparently is different from the antenna sets they sell now). The antenna I got in the kit is a RP-SMA antenna meaning the cable is also RP-SMA. Long story short: I can connect the LoPy cable + LoPy antenna to the board, but the the provided small antenna won’t fit on the LoPy cable. With the LoPy antenna combi I’ve been able to get about 500 meters range outdoors, combined with the single channel LoPy nanogateway. Which is absolutely not bad at all, also given that I’m fixed not to just one channel there but also to SPF7. I’ll do further comparisons once the replacement cable has arrived.

So, the DHT11 sensor. It helped that I managed to figure out that the provided pinout chart was incorrect. Once I know to which actual ports the DHT11 was connected, it was a matter of integrating the library and code into the existing code.  To keep the number of things that could go wrong manageable, I first tested jut the DHT11 code. I provided an example here. If that doesn’t work, don’t bother with the connection to TTN.

Lees verder….

Deel dit bericht: