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 072017

What happens if you take a LoRaWAN node with you in a train while you travel across the Netherlands for about 2,5 hours? I did not know and wanted to find out today because I had to be in Zwolle for a meeting.

So I charged a big external battery (with 2 USB ports), drilled a couple of holes in a plastic container to guide through the micro-USB connectors, and put in some bubble foil inside for safe transport. I drilled another hole to connect the external antenna for the LoPy node. Besides the LoPy, I put the Marvin in the box, with the temperature/humidity sensor on the outside of it. Not that it really mattered, today was going to be about finding gateways while I was on the road.

Things did not look good for the experiment though in the morning. The Things Network (TTN) backbone was acting up again. That was a bummer, because I still had to change the code on the LoPy. It had the code installed for the Circuit Playground and I wasn’t planning on bringing that also. So I changed the code to a simple “send a number every 30 seconds” but was not able to test it before leaving for the train.

To make matters more balanced: I decided to have the Marvin connect to the KPN network (still got 60 days left on my free trial), but the Hookbin.com server decided that today was a good day to refuse to work. And I needed a place to store the data sent by the Marvin. Luckily I found loggly.com another site that you can use as a destination for KPN nodes. I think it is better than Hookbin btw because it keeps more records and even the free plan should be enough for most people. Another nice thing was that Loggly also can act as an HTTP-integration for TTN, so I could collect both the data sent via KPN and the data sent via TTN in one single place. Quick tip: Loggly provides you with an http:// url for the endpoint, KPN doesn’t accept http:// but you can simply change the provided url to https:// and then it works.

OK, into the train. I wasn’t really sure what to expect. A train means lots of metal and a fast moving object (and nodes).

Lees verder….

Deel dit bericht:
apr 062017

Tegen de tijd dat ik het mailtje gisterenavond zag had ik ook al de follow-up mail met als titel “Let op: Phishing mail verzonden” in mijn mailbox met de waarschuwing om de mail gewoon te verwijderen. Maar het is/was een dusdanige phishing e-mail dat ik hem hier ook even wil plaatsen als waarschuwing en voorbeeld.

Normaal gesproken zijn phishing mails die ik ontvang namelijk gemakkelijk te herkennen: ze komen van een bank waar ik geen rekening heb, vragen informatie die ik nooit via de mail zou sturen, bevatten taal en spelfouten, etc.

De mail van gisteren was echter geschreven in foutloos Nederlands, bevatte in de “Beste” mijn volledige voornaam en achternaam én was verstuurd van een domeinnaam die leek op die van mijn werkgever: “han-hogeschool.nl” (i.p.v. han.nl)

De mail vroeg niet om mijn bankgegevens, maar had een link naar een pagina op (eveneens) han-hogeschool.nl die er exact zo uitziet als de schermpje waarmee ik normaal gesproken ook inlog:


De ene is de echte, de andere niet. Als je goed naar de adresbalk kijkt in de screenshots kun je zien welke wat is. Ik heb even niet getest wat er gebeurt als ik (onjuiste of juiste) inloggegevens in zou vullen, maar ik kan het de collega’s die hier wél voor gevallen zijn absoluut vergeven. Want hoe vaak vul je zo’n schermpje niet in? En in dit verband is het ook nog heel logisch, want je verwacht dat het nodig is om in te loggen om bij een interne pagina te komen waar je je keuze moet aangeven.

Overigens: via Internet Explorer, de standaard browser van de HAN, wordt de pagina netjes weergegeven. Met Chrome zie je wél snel dat er van alles mis is omdat ze de afbeeldingen en CSS bestanden gewoon heel brutaal bij de HAN rippen. En die gebruiken https:// terwijl de rest van de pagina via http:// uitgeleverd wordt. Chrome vindt dat niet fijn.

Goed, dit was een phishing aanval op HAN mailadressen. Ik neem aan, gezien de inhoud van de mail, alleen gericht op medewerkers. Maar als iemand zoveel moeite neemt om een aanval voor te bereiden, dan zou het me niet verbazen als ze zoiets ook op andere plekken gaan proberen. Het is een indrukwekkende combinatie van sociale manipulatie (je doet dingen die heel logisch lijken) en technische uitvoering. Dus let op!

p.s het domein is bij GoDaddy.com geregistreerd via domainsbyproxy.com, dus achterhalen wie hier achter zit zal wel nooit lukken denk ik.

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 052017

Ik luister niet zo heel vaak naar podcasts, maar een tweet van Astrid Poot zorgde ervoor dat ik vandaag tijdens het werken tóch kennis maakte met “Lekker samen kletsen“. Aflevering 9, als heb ik 8 (waarvan Astrid dacht dat het 7 was) ook geluisterd want Soundcloud speelt gewoon door als je niet op stop klikt.

Waarom kwam ik bij de podcast? Nou, vanwege de vraag van Astrid in haar tweet “kun je praten over maken zonder te maken? kun je expert zijn zonder ervaring?” Het lijkt een open deur waar het antwoord dan op zou zijn “nee, natuurlijk niet!”. Maar het ligt wat mij betreft toch wat genuanceerder, en Peet Sneekes (de andere stem die je in de podcast hoort) probeert dat ook in de podcast wel voorzichtig aan te stippen.

En even voor de 100% duidelijkheid: dit is geen zure blogpost. Ik ben het niet 100% met Astrid eens en ga dat in tekst (getypte woorden) proberen onder woorden te brengen als onderdeel van het gesprek dat je over dingen kunt hebben waarbij je het niet 100% met elkaar eens bent. 🙂

Kijk, maakonderwijs, maken, maker education, is van nature een tastbaar ding. Dus logisch dat je dan zou zeggen “dat moet je dóen om te kunnen waarderen”. Maar het is wat mij betreft wat minder zwart/wit. Vroeger, toen ik nog naar Nederlands voetbal op de tv keek, kreeg ik van mijn kinderen wel eens commentaar als ik mijn beurt commentaar gaf op het spel van het Nederlands elftal. Ik kon het immers ook niet beter, sterker nog, mij laten voetballen levert waarschijnlijk meer kwetsuur op dan een paar buitenspeelbenen. Mag ik er dan geen mening over hebben? Of omgekeerd: als ik wél voetbal, ben ik dan automatisch beter in staat om er een mening over te hebben?

Terug naar maakonderwijs: ik heb van tijd tot tijd verschillende petten op: ik ben een geek die het leuk vind om dingen uit te proberen (vaker met software dan met “spullen” moet kunnen hoop ik), ik ben ouder van twee tieners (en ben het helemaal met Astrid eens als het gaat over de rol van ouders op dit gebied, los daarvan: het is gewoon leuk!) en ik ben onderzoeker bij een kenniscentrum. Mijn ervaringen op de ene plek, helpen mij op de andere plek.  Als onderzoeker wordt ik geacht ook “in de boeken” te duiken (er zijn best al veel boeken die relevant zijn voor maakonderwijs hoor!), tijd om zelf dingen te maken is er in die rol niet altijd. Geeft ook niet, want op zo’n moment wil ik vooral ook zien wat anderen doen, wat leerlingen doen, wat collega’s doen, niet altijd is het dan handig om “samen” te klooien. Dat doe ik dan wel weer op andere momenten, thuis, met de kinderen bijvoorbeeld.
Het er bij halen van theorie is daarnaast ook belangrijk. Want daaruit kun je namelijk leren wat anderen ook al verzonnen hebben en wat toen wel of juist niet werkte. Dan hoeven we niet steeds opnieuw het wiel uit te vinden.

Dus ik denk dat het gelukkig niet zo’n harde scheiding is. Een “expert” die heel stellig is in dingen op dit gebied mag van mij ook wel met stellige onderbouwing komen (ik zal niet zeggen “bewijzen”). De opmerkingen “ja, want ik ben docent” of “ja, want ik werk in de praktijk” is dan voor mij daarbij ook niet genoeg om me te overtuigen. Dus een “super praktische expert” zoals het in de podcast genoemd wordt is voor mij ook een verzinsel. Er wordt gesteld “Kun je denken over de realiteit, zonder in de realiteit te zijn” en anders dan Astrid en Peet denk ik dat dat wél kan. Ik zou mijn werk heel erg saai vinden als dat het enige was wat ik zou mogen doen (en niet alleen als het over maakonderwijs gaat), maar dat is wat anders. 🙂

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:
apr 032017

Laat ik beginnen met de breed gedragen constatering dat het werken met paper circuits toch nog best heel wat moeilijker is dan dat je zou denken als je de filmpjes die online staan ziet. Wat dat betreft is het ook maar goed dat ik 5 rollen van 30 meter besteld heb, want er zal nog wel wat tape “verbruikt” worden.

Maar…de opmerking dat ik natuurlijk na het weekend ook wel een paar voorbeelden wilde hebben om te laten zien, was voldoende stimulans om te volharden.

Ikzelf was er voor het debuggen, als mensen een voorbeeld zoeken van een debug-activiteit die niet met programmeren te maken heeft: laat leerlingen met paper circuits aan de slag gaan! 😉

Ik weet zeker dat ze dan ook leren om nauwkeurig te werken en planmatig te werk te gaan. Want als je niet nauwkeurig bent, dan is je stroomkring al bij de eerst bocht onderbroken en als je niet planmatig te werk gaat bestaat je project vooral uit frustratie om led lampjes die verkeerd om zitten of stroomkringen die niet sluiten.

Maar natuurlijk is het ook gewoon leuk. Waar Marit meteen aan het tekenen sloeg en begon met een mooie voorkant, dacht Niek na over parallelschakelingen van ledjes met aparte knopjes per led en combineerde Josine bestaande kaarten met ledjes en zorgde voor batterijhouders (van papier).

De kopertape die we hebben blijkt tweezijdig te geleiden, dat is handiger dan tape die alleen aan de bovenkant geleidt. Het vastplakken van leds met plakband blijkt niet zo handig, het contact is minder sterk dan nodig, beter is het om ook daar kopertape te gebruiken.

Lees verder….

Deel dit bericht:
apr 022017

If there is a thing that is dislike most, than it is giving up on a technical problem before it is solved. So, although this weekend a late cold finally managed to make me sleep more than usual, I did manage to spend some time with The Things Network, the LoPy Nano Gateway and the Marvin Node.

So, one thing that really can kill your debugging efforts is the fact that the backbone for The Things Network is rock solid stable. I don’t know whether that just is the case during the weekend, but like last week, this weekend there were some outages. There is no single status page that you can check, so that makes it a bit hard. But I’m starting to learn that if the console page act oddly, like failure to show the gateways that I defined, or if suddenly everything is displayed is disconnected, it might just be that they are having problems on their end.
Who am I to complain about a free service? I know, still, an automated page that tells me if I need to just wait and do other stuff, would be nice.

But during the uptime, I was able to get some more stuff working.

First of all: the code that Alex used in the video does work, just make sure you select “Packet forwarder”.

Another thing to know is that the default abp_node.py script has this code:

for i in range (200):
s.send(b'PKT #' + bytes([i]))
rx = s.recv(256)
if rx:

Basically it just sends 200 packages within a short time and then stops. So if you don’t know that, you’ll think the node stopped working. It does, but on purpose. Now if you reset the LoPy, it will start again, but the TTN backbone will ignore that data because the LoPy will start again with package #0, and the backbone will already have a package #0. The quick solution during testing is to reset the frames counter for the device.

Also, the test script is nice for testing, but LoRaWAN was not build for a rapid stream of data, so make sure you read the post about the TTN Fair Access Policy, even with small messages at close range, the 500 messages (of 10 bytes each) per day at SF7 means max. 1 message per (about) 3 minutes, the script sends one every 10 seconds. Granted, it stops after 200 messages, but if you repeat that 2-3 times during testing, you go above that.
For me, testing it on my own Nano Gateway, the chances that I “steal” airtime from other nodes is small, but if you’re using someone else’s gateway, you could be causing problems for other nodes being unable to get their messages through.

But like I said in the title, the weekend showed there is still some love left. I managed to get a few more things working with my two nodes.

Lees verder….

Deel dit bericht:
apr 012017

Afgelopen week kwam de kopertape binnen (5 rollen van 30 meter), dus dit weekend wat tijd vinden om er mee aan de slag te gaan. Ik heb voor mezelf en voor de kinderen even wat bronnen / inspiratie verzameld:

Het is niet noodzakelijk om al de bovenstaande bronnen te bekijken, start met de basis (bv via de info bij Pauline) en experimenteer van daaruit verder.

Natuurlijk zijn er ook filmpjes om te bekijken:

Er zijn er meer, ik vind bovenstaande filmpjes al een aardige intro, variërend van eenvoudig/handig, tot stap voor stap en ingewikkeld (met solderen en een ATTiny85 er in).

Ze moeten nog beginnen, dus nog geen foto’s van resultaten, zodra die er zijn, komen die natuurlijk ook weer.

Deel dit bericht:
mrt 312017

If your are used to learning stuff without there being a clear manual available, without a teacher that gives you a step by step breakdown of what to do, like when you like to experiment and play with electronics or ict, then you know how frustrating the process of trial and error can be to get something to work. And how rewording it is when it does work in the end.

There are limits however. And LoRaWan in combination with The Things Network (TTN) is really testing my limits with this regard. Because it turns out it is really tough to get it to sort of work, even though it looked easy at first, and I am not sure anymore whether this is good and a way to learn all the ins and outs of LoRaWAN and TTN or whether it just is not worth it (yet).

So, what is the current situation?

  1. On Monday I wrote about connecting the Marvin node to KPN, that worked surprisingly good and was easy to do. Connecting the LoPy as a node to KPN was just as easy. But since KPN is a paid solution and I don’t have a use-case that warrants that amount of money, I kept on looking.
  2. On Tuesday I wrote about setting up a single channel gateway for TTN. That worked also, but only for half a day. At the moment, I understand it sort of was surprising that it worked at all, though online information isn’t always very clear whether failure is by design or by accident, in particular because that info was from before I got the gateway online. Currently, that gateway shows as connected in the TTN console, but no data has been transferred by it since it disconnected Tuesday evening.
  3. Yesterday, there was a live broadcast by Alex from Pycom where he was going to explain how you can use the LoPy as a “Nano Gateway” for TTN. If you watch it, you’ll see that even for Alex, getting the LoPy acting as a gateway is not easy and not something that he could totally do from start to finish during a livestream. I tried to follow the steps that Alex outlines, wasted a couple of hours last night and by the looks of it by accident, the gateway started to accept broadcasts by both the second LoPy and the Marvin node. However…
  4. The LoPy Nano Gateway still is online, data from both of the nodes is being displayed in the console page for the gateway (see image), but not always and none of that data (except for the first few hours) is displayed at the data page for the nodes. So basically I now have a functioning gateway and still no data from the nodes.

Give up or go on?

Personally I don’t have any use-case for nodes that need to be in a location where there is no WiFi. Yes, WiFi uses a lot of battery power, but for the more battery sensitive stuff, 433Mhz transmission also works, and I have got plenty of those lying around.
Yes, I know that Single Channel Gateways or Nano Gateways are not LoRaWAN compliant. So, I cannot blame TTN if they don’t (fully) support them. And nobody is forcing me to use their free infrastructure.
But I am someone that would be willing to spend the couple of hundred euros needed to put a gateway on my house, either by building one for 200 euros or buying one for 400 euros, but with this little succes (and love) in a test setup, that is not going to happen. Because I really don’t know if spending that money would fix all the current problems.

So for now, my home village will have to do without TTN capabilities. I did post a question on the Pycom forum, maybe Alex can shed some light on the problems, maybe he has suggestions, other than that, I don’t know what to test for now.
If someone has a spare gateway lying around that he wants to borrow or donate to get Deurne (NL) on the TTN map, let me know!

Deel dit bericht: