De afgelopen weken stond bij ons een LoRaWAN Proof-of-Concept centraal. Deze PoC centreert rond de uitdaging van tracking. We willen mobiele objecten redelijk kunnen volgen. Het hoeft niet exact, maar wel ongeveer. De lat moet dus net hoog genoeg. Alleen dan kunnen we de voordelen van een heel laag batterij verbruik ook benutten in de toepassing.
Deze IoT toepassing heeft Nederland als werkgebied. Om daar nu mee aan de slag te kunnen, is de keuze voor het LoRaWAN netwerk van KPN logisch. Het netwerk heeft volgens zeggen landelijke dekking, waarbij er momenteel verdichting plaatsvindt.
Ons doel is niet om de netwerk kwaliteit te meten, maar we merken wel aan den lijve dat het in ontwikkeling is; de dekking wisselt sterk per locatie. Het meest frustrerend was dat er tot een week geleden geen dekking was rond ons kantoor. En we zitten nog wel midden op het high-tech Kennispark. Gelukkig hebben we ook testlocaties met dekking, en is ook ons kantoor sinds kort ook LoRaWAN gebied geworden.
Naast dekking is er nog een hele serie parameters die de communicatie kunnen verbeteren of frustreren. LoRaWAN “out-of-the-box” werkt, maar niet optimaal. En deels kan dat ook niet, aangezien optimalisatie ook samenhangt met de applicatie. De standaard instellingen passen bij een statische toepassing, terwijl onze applicatie mobiel is. Zo werkt Automatic Data Rate alleen goed in stilstand, en kan het zelfs tegenwerken bij beweging.
Daarnaast vraagt LoRaWAN je heel goed na te denken over de regelmaat en de data die je verstuurt. Door de 1% duty cycle die samenhangt met de 868 MHz regelgeving kun je maar af en toe iets sturen; zeker omdat retries van gemiste berichten ook meetellen. Een LoRaWAN bericht duurt tot 1,5 seconde. 1% betekent dat er tussen de berichten gemiddeld minimaal 150 seconden zit. Als je 130 km/uur rijdt zit er ruim 5 km tussen twee opeenvolgende punten. Past dat in de applicatie? In onze applicatie hoeven de positie niet heel nauwkeurig te weten. Deze PoC gaat ons laten zien of we het hier mee redden.
Tijdens de testen lopen we ook op een andere manier tegen de lage duty cycle op. Als je ontwikkelt wil je graag veel data punten hebben, met allerlei verschillende settings. Maar we hebben, als we geluk hebben, één data puntje elke 2,5 minuut. Even wat testen kost dus een hele tijd. In een tijd waarin alles ultra high speed is, is LoRa echt weer terug naar de tijd als ultra low speed.
Nu is dat ook wat LoRa en de andere IoT technieken beloven. Het gaat niet om de hoge snelheid, maar de lage kosten in hardware en batterijgebruik. De nieuwe uitdaging is daarmee eigenlijk ook weer een oude bekende. We moeten weer heel zuinig zijn op wat je stuurt. Minimale overhead door protocollen, berichten slim coderen en vooral goed nadenken over de applicatie. Wanneer heeft deze welke informatie nodig. En daarbij heel veel tijd reserveren om het goed te optimaliseren en te testen.