Zoekresultaten : lorawan

apr 092017
 

I still wasn’t out of “what if…” scenario’s for the devices I had been playing with in relation to The Things Network / LoRaWAN. Because, although I had used the WiFi (and of course LoRA) capabilities of the LoPy a lot, I had not yet played with its BLE (Bluetooth Low Energy) capabilities. For that I needed something else that could use BLE to connect to it. My iPad Mini, the micro:bit, my desktop machine (thanks to the BLE USB adapter), they all could do that. But I wanted to use the Puck-js buttons that I had for that.

The use-case:  If I press the button on the Puck.js (I have two of them, I can press either of them), then the Puck.js connects over bluetooth to the LoPy. After the connection has been made, the Puck.js sends 1) its device-id 2) the measurement of the light sensor of the Puck.js 3) the measurement of the temperature sensor of the Puck.js and 4) the battery voltage of the Puck-js. Once the LoPy has received those 4 values (encoded as a single HEX-string), it sends it to The Things Network (TTN) via LoRaWAN.

Like with the Adafruit Circuit Playground, one of the challenges was that both devices (the LoPy and the Puck.js) use different programming languages and there were no existing examples that handles the cross platform connection.

I uploaded all code to github.com

Programming the Puck.js

To program the Puck.js, you need the Espruino IDE. I have had my fair share of problems connecting to the Puck.js from within that IDE. It is probably one of the challenges of using BLE as a connection to program. But in the end it got the job done. I wasted most time trying to understand how I can send data from the Puck.js to the LoPy after connecting to it. There was an example using 2 Puck.js to send data, but I could not figure out what the UUID of the PrimaryService and the UUID of the Characteristic for the LoPy that allowed me to write data to it where.

I tried to figure that out using code on the Puck.js, but that didn’t work. In the LoPy code that I found, the service and characteristic were defined like this:

srv1 = bluetooth.service(uuid=b'1234567890123456', isprimary=True)

chr1 = srv1.characteristic(uuid=b'ab34567890123456', value=5)

I finally discovered how these needed to be added in the Puck.js code by using nRF Connect, a free tool for iOS. After setting up the LoPy so that it broadcasts using BLE (see the code below), I connected to the LoPy using the nRF Connect app. It then shows you the correct UUID’s that are in the Send_BT_to_LoPy.js script:

return d.getPrimaryService("36353433-3231-3039-3837-363534333231");

return s.getCharacteristic("36353433-3231-3039-3837-363534336261");

Easy, once you know it.

Note #1:  The Puck.js connects to a device named “LoPy01” so if you change the name of the device in main.py for the LoPy, you also have to change it in the code for the Puck.js
Note #2:  I added the id for the Puck.js in the code, first line. You need to change that to the code for your Puck.js if you have more than 1 Puck.js and want to be able to keep the transmitted values apart afterwards.

Let’s continue with the LoPy.

Lees verder….

Deel dit bericht:
apr 052017
 

One of the challenges left with regards to the LoPy was to find a way to actually connect sensors to the node. I had little luck with the DHT11 temperature/moisture sensor (one of the drawbacks of MicroPython over regular Arduino code is the lack of libraries) and didn’t have any I2C sensors lying around. But I did of course still had the Circuit Playground by Adafruit and I knew how to talk to that one from another device using the hardware serial RX/TX connection because I had already connected it to a micro:bit that way (the posts are here, but in Dutch).

So surely it should be possible to connect it to a LoPy and send the sensor data to The Things Network (TTN) that way? Is was. Not as easy and simple as I had hoped, but in the end it worked. Since it is rather a complex structure, I made a small graphic to explain how all the parts go together.

Let’s start with the easy parts: I have got a LoPy Nano Gateway up and running. That is not a full compliant LoRaWAN gateway, but it takes care of receiving messages send via LoRa / 868 Mhz and relaying them, via WiFi, via my WiFi Router, the internet, to the The Things Network (TTN) backend. That is the regular part.

On the right end lower corner, the action starts with the LoPy Node. It is connected via two cables to the Circuit Playground (CPG). One cable goes from the TX port of the LoPy Node to the RX port of the CPG. The other one goes from the TX port of the CPG to the RX port of the LoPy Node. The LoPy Node sends a signal (a digit ranging from 1 to 10) over the serial connection to the CPG. After the CPG receives the signal, it reads the three build in sensors for light, noise and temperature. It then converts the values to a 12 byte HEX string value and sends that back over the serial connection toe the LoPy Node. After sending the signal, the LoPy node waits a bit, giving the CPG time to return the value, then it reads the values and sends that via LoRa to the first available gateway, in this case the LoPy Nano Gateway on my desk.

After the gateway has delivered the messages to TTN, a Payload function translates the received value back into three individual values. It then send them, via the Integrations option, to the Swagger server where it the is available in JSON format. See, easy peasy. 🙂

I uploaded all the code to Github. You can find it here. The code in the LoPy-flash folder is (of course) intended for the LoPy Node, the code in the Circuit Playground folder needs to be uploaded to the CPG via the regular Arduino IDE. I made some changes to the LoPy node code provided by Pycom: I added the option to have the LoPy Node also connect to your local WiFi. Not necessary, but it makes it easier to debug/connect. If you leave that info blank, it will just ignore. Also, if you take the node outside of the range of you WiFi network, it will just ignore it. Another thing that I changed, is the use of config.py for the Node, so that you only need 1 place to change all the info. Finally I choose OTAA instead of ABP as the authentication for the node.

Lees verder….

Deel dit bericht:
apr 042017
 

At the moment, the console page of The Things Network has some problems getting the Gateway page. It has been reported on the forums, it appears to be a front-end thing, the gateways themselves appear to be working just fine.

So unless you want to get info about your gateway, add a new one, remove or change one, there should be no problem. If you have to do one of these things, you can also use the commandline interface (CLI) using the tool provided here.

It allows you to login using your account, get information about your gateways, add new ones, remove them etc.
The Rx / Tx info shows you the amount of trafic on the gateway (uplink and downlink).
It also offers a MQTT interface if you want to have a look at the data coming in from your devices without having to go to the website.

Besides giving answers, in my case it also raised some new questions:

If you click on the screenshot to enlarge it, you’ll see 2 gateways listed. One (“eui-b827ebffff2e837b”)  is the LoPy Nano Gateway which has been heaving nicely since it actually got connected with an increasing count for Rx because it still is forwarding messages from my nodes here at my desk.

The other one (“eui-b827ebffff2e837b”)  is the single channel Raspberry Pi + Dragino Lora Shield that I at first managed to get online last week, but then at the end of the day stopped working (see here). Now at first, looking at it via the CLI did indeed show that it hadn’t been seen for a while. After removing the gateway and adding it again via the CLI, it did show up as recently seen. And apparently it still sees it.

I noticed that the gateway is working again because my nodes now sometimes list both of the gateways as receiving and transporting their messages:

  

Great. So, it works? Yes, but what I don’t understand yet is why the LoPy Nano Gateway is connected to a “bridge” that is called the “PacketForwarder Backend” while the Raspberry Pi is connected to “staging”. Why the difference? Also, how come that the Rx for the Raspberry Pi seems to be resetting all the time?

There is one thing that could explain the difference: because I am using NAT, I have setup port forwarding for UDP on port 1700 to the LoPy Nano Gateway. I cannot do that for both (I got only 1 externally visible IP address), so I am guessing that the TTN backend can reach the LoPy Nano Gateway, but cannot reach the Raspbery Pi. But does that explain the difference in bridge assignment?

Deel dit bericht:
 Reacties uitgeschakeld voor TTN: If the GUI fails, just go commandline  Tags: , ,
okt 042016
 

ct66n4rxgaapi7wDe middag was voor het Seminar Internet of Things. Een voor SURFnet niet technisch seminar over the Internet of Things. Margo Emmen, een van de spreeksters, werkzaam bij het Huis van Morgen vond het allemaal nog best wel technisch en ik kan me dat een beetje voorstellen gezien haar achtergrond. Maar het enige wat daardoor jammer was, was dat ze de indruk leek te hebben dat ze ons daarom niets te vertellen had. Terwijl zij als gebruikers van internet of things enerzijds bij uitstek de use-cases aanleveren (dementerende senioren), de bestaande toepassingen uittesten (o.a. wuzzialert) én een locatie zijn waar gebruikers uit het veld (in dit geval zorgprofessionals en anderen) terecht kunnen. Em zo’n keten is cruciaal om IoT van speeltje voor nerds te maken tot nuttige toepassingen voor “gewone mensen”. Nou ja, ik vond het zinvol.
Dat gold ook voor het verhaal van de Coöperatieve Universiteit Amersfoort, dat enerzijds een hoog houtje-touwtje karakter had, maar anderzijds wel ook het verhaal van SURFnet over LoRaWAN (“je kunt er eenvoudig mee aan de slag”) bevestigden met hun voorbeelden van hoe burgers onderzoek kunnen doen naar de veranderingen in hun leefomgeving.
Het verhaal van Wienke Giezeman had ik nog niet eerder van hemzelf live gehoord, maar kende ik inmiddels wel al van o.a. het filmpje bij de Kickstarter van The Things Network en de verhalen die ik er intussen over gelezen had. Voor mij kan het wat dit betreft niet snel genoeg zo zijn dat er een landelijk dekkend netwerk via TTN beschikbaar is, dan kun je tenminste er vanuit gaan dat je sensor ook een gateway weet te vinden. Én ik hoop dat hun businessmodel solide genoeg is zodat die backbone dan ook in de lucht kan blijven (zónder dat wij er apart voor hoeven te betalen, als het voor mijn eigen dorpje vergt dat ik een gateway aan mijn schoorsteen zou moeten laten monteren dan vind ik dat prima).
Het verhaal van Paul Havinga van de Universiteit Twente was gewoon indrukwekkend. Als iemand zegt “IoT, dat doen wij al 15 jaar” dan klinkt dat opschepperig. Maar Paul had meer dan genoeg projecten en voorbeelden die hij allemaal maar kort kon aanstippen om te laten zien dát zij dat inderdaad al zo lang doen. Mooi.
En als ik de ene Paul noem, dan kan ik natuurlijk niet anders dan Paul Dekkers van SURFnet ook noemen. De samenvatting die hij vandaag gaf was niets nieuws voor mij, maar hij timmert binnen SURFnet hard aan de weg als het gaat om het toelichten van de technische kant van LoRaWAN.

Kortom, een nuttige dag in Utrecht vandaag. Ik denk dat er nog wel een groot verschil zit tussen het onderwijsmateriaal dat SURFnet wil gaan ontwikkelen op dit gebied en het materiaal dat wij zouden kunnen gebruiken. Immers, IoT is ook zinvol binnen makeronderwijs, binnen techniek onderwijs, is ook stukje van ict-geletterdheid kennis van leerlingen en leraren. Maar dan eigenlijk op het niveau van Margo Emmen, op het niveau van eindgebruikers, op het niveau van “ik heb een uitdaging/probleem, hoe los ik dat op?”, stel je hebt een bootje en je wilt daar een vochtdetector inbouwen, wat dan? Dat moet dan een stapje of 2-3 minder technisch dan wat je een student elektrotechniek zou kunnen leren.

De tweets:
Lees verder….

Deel dit bericht:
sep 142016
 


Het woord “Mesh-netwerken” in titel is eigenlijk helemaal fout, het zijn eigenlijk “Mesh networks” in het Engels over “Vermaasde netwerken” in goed Nederlands. Maar bij vermaasde netwerken zijn er nóg minder mensen die een idee hebben waar ik het over heb. Dus ook nu eerst even wat achtergrond: normaal gesproken als wij met onze laptop, iPad, smartphone of ander draadloos of zelfs bekabeld apparaat verbinding maken met het / een netwerk, dan is er een duidelijke rolverdeling. De laptop, iPad etc. is een node die verbinding maakt met een ander apparaat dat als belangrijkste taak heeft om toegang te verlenen tot het netwerk, tot internet, tot een server etc.
Dat kan een Wifi router zijn die het signaal van jouw apparaat ontvangt en dan doorgeeft via het bekabelde netwerk naar een ADSL router of een andere aansluiting met het internet etc.
Kenmerkend daarbij is dat er een infrastructuur beschikbaar is die daar specifiek voor aangelegd is. Maar wat nou als je sensoren hebt die op plekken moeten kunnen functioneren waar je geen vaste netwerkaansluiting hebt of waar nog geen WiFi-netwerk ligt of geen netwerk waar jij toegang toe hebt? In het bos of gewoon in een stad zelfs?

Dan kun je kiezen voor een netwerktechnologie die een heel groot bereik heeft, zoals bij een LoraWAN of je kunt betalen om toegang te krijgen tot een WiFi-netwerk van een ander of een mobiel netwerk (via GPRS of 3G/4G).
Maar wat nou als het helemaal niet zo noodzakelijk is dat je verbinding maakt met de buitenwereld. Wat als je eigenlijk vooral wilt kunnen communiceren met andere nodes die bij jou in de buurt zijn? Bijvoorbeeld met andere robots (zoals in dit voorbeeld), of wellicht straks zelfs andere zelfsturende auto’s.

Dan is een mesh-netwerk een oplossing. Daarbij is elke node gelijkwaardig aan elkaar en is er geen specifieke infrastructuur voor de onderlinge communicatie nodig. Vroeger, toen al die netwerken via kabels moesten worden aangelegd, was dat moeilijk schaalbaar (alles met alles verbinden via kabels wordt al snel een warboel), maar tegenwoordig met draadloze netwerken (via WiFi, Bluetooth of wellicht straks via Lora) is dat veel eenvoudiger.

De demo hierboven is leuk, het laat goed een sterke eigenschap zien: valt een node uit, dan werken de anderen gewoon verder, komt er eentje bij, dan wordt hij automatisch in het Mesh-netwerk opgenomen. Maar het gaat hier wel om een heel naïef netwerk waarbij elke node automatisch ook de informatie van de andere nodes vertrouwd. En dat zal niet altijd het geval zijn. Ook moeten de pakketten data die rondgestuurd worden niet té groot worden anders is elke node voornamelijk bezig met het afhandelen van de data van de andere nodes.

De code voor bovenstaand voorbeeld is hier op Github te vinden.

Deel dit bericht:

Gedaan: Nerdcafé 6 in Deurne

 Gepubliceerd door om 23:06  Hardware, Internet
jun 222016
 

20160622_183732000_iOSVanavond was de zesde editie van Nerdcafé Deurne georganiseerd door Jeroen van de Nieuwenhof. Sprekers vanavond waren Eugene Tjoa en Mark van der Net. Beiden hadden ze het over data, maar dan met een iets verschillende insteek. Voor beide sprekers geldt als snelle tip: kijk zeker even via de link achter hun naam op hun websites!

Eugene lichtte een aantal mooie toepassingen van open (geo) data toe, o.a. aan de hand van de PDOK-website en de smartcityapp. Zoals gezegd, ook op de eigen site staan mooie voorbeelden, zoals deze visualisatie die mogelijk is dankzij de data uit het Actueel Hoogtebestand Nederland (AHN).

Na de pauze was het de beurt aan Mark die niet alleen over LoRaWAN kwam vertellen, maar aan de hand van de voorbeelden op zijn site een aantal andere voorbeelden van het gebruik van big data, in dit geval verzameld vanuit sociale media, liet zien. Zie bijvoorbeeld deze pagina met informatie over de Babel interactieve installatie.

Daarna ging Mark van der Net in op LoRaWAN als netwerk van apparaten dat ook gebruikt kan worden om data te verzamelen en uit te wisselen. Hij had vanavond zowel een Kerlink IoT Gateway (kost zo’n €1.500) bij zich als een kleine sensor node met o.a. een temperatuursensor en klein zonnepaneeltje (niet zichtbaar op de foto).

20160622_215220_HDR-1

LoRaWAN Sensor node

20160622_215225_HDR-1

Kerlink IoT Gateway

Duidelijk is dat het netwerk zich nog moet bewijzen. De use-cases voor particulieren zijn meestal nogal vergezocht (ik heb geen bootje waarvan ik bang ben dat hij gaat lekken) terwijl bedrijven en gemeenten niet altijd heel snel schakelen met zulke technologieën.
Ik ben benieuwd hoe het zich verder gaat ontwikkelen. Ik vond de investering in een gateway van het The Things Network vorig jaar via Kickstarter een wat te grote gok omdat er zo weinig bekend was over de achterliggende organisatie en het netwerk. Maar als het een beetje meezit krijg ik in augustus (of niet al te lang erna) wel twee LoPy modules (met antennes) via een andere Kickstarter. Dan kan ik er in ieder geval eens mee experimenteren en een gevoel krijgen voor de complexiteit van de technologie.

Al met al was het weer een interessante avond. Voldoende nerds ook weer in de zaal. De volgende editie is na de zomer, in september, dus hou de site van Nerdcafé in de gaten!

Deel dit bericht: