NL7559KW7: LoRa_Communicatie

LoRa-Netwerkverbinding

De gebruikelijke PWS- en Domotica-communicatieverbindingen met de frequentiebanden 433MHz, 868MHz en WiFi (=2,4GHz/5,0GHz) hebben als belangrijke, praktische eigenschap dat de effectieve reikwijdte erg beperkt is:
- 100m is al heel veel,
- zelden een onbelemmerde, ongedempte zichtlijn tussen zender en ontvanger
- de verbinding verslechtert als er obstakels zijn (= demping) in de vorm van muren, planten, gaas, glas, gordijnen, meubels, e.d.
- met veel gebruikers voor een bepaalde frequentieband is onderlinge storing te verwachten, met corruptie&uitval van communicatie en/of verlaging van de data-snelheid.
PWS-verbindingen zijn nagenoeg altijd ster-verbindingen direct tussen de sensoren en een specifiek, bijbehorend basisstation.
WiFi-verbindingen lopen ook direct met ster-verbindingen direct tussen randapparaten en specifieke, gekozen WiFi-Toegangspunten, voor meteo en Domotica meestal met die toegangspunten in je eigen lokale data-netwerk; bij uitzondering een verbinding over een extern data-netwerk.
ALS de verbinding goed werkt, dan kun je met de bovengenoemde technieken dataverbindingen opzetten van hoge snelheid & hoog datavolume.

LoRa(WAN) werkt ook op 868MHz, maar gebruikt een specifieke techniek & architektuur waardoor voor communicatie veel grotere (LongRange)-reikwijdte kan worden gerealiseerd: over kilometers, wel tegen inleveren van datasnelheid & -volume.
Voor LoRa-Communicatie is de ketenopbouw zoals hiernaast geschetst:
- aan het begin van de keten de EndDevices
- aan het eind van de keten de Applications
- zowel EndDevices als Applications kunnen bij de Gebruiker staan, en ook eventueel een Gateway (voor een directere, betere verbinding), maar de Gateways en vooral de Network&Application Servers staan gebruikelijk 'elders/extern'
- de verbinding vanuit End-Devices wordt automatisch opgebouwd a.h.v. gevonden Gateways.
Bij LoRa-Communicatie zijn de langere verbindingslijnen op zich geen probleem, maar je moet voor de 'externe' onderdelen wel aansluiten bij een beschikbaar 'extern' LoRa-netwerk.
Dat aansluiten is nog niet triviaal, want 'nogal' experimenteel cq. gebruikers-onvriendelijk, dus vooral voor 'kenners'.

KPN biedt een zakelijk, nagenoeg landelijk dekkend LoRa-netwerk.
Zoals te zien op nevenstaand kaartje is de bedekking vanuit het KPN LoRa_Netwerk voor onze locatie met postcode 7559KW in orde.

Gebruik van het KPN LoRa-Netwerk is naar keuze, óf met een 'Developer-account', óf als Contracted Customer met een abonnement.
De 'Developer-account' is van beperkte duur (6 maanden), met beperkte functionaliteit via het DevPortal:
- verbinding in een kortere 'proeftijd' naar een voorgedefinieerd Dashboard
- die verbinding is voor 1 file-soort (JSON)
De opzet is daarbij dat in de 'proeftijd' de Gebruiker deze opzet gebruikt voor uitwerken & testen van een eigen functionele configuratie.
Na de 'proeftijd' met het Dashboard kan de Gebruiker dan overgaan naar een eigen, beproefde, ruimere configuratie,
na aflopen van de Developer-account eventueel bij KPN als Contracted Customer.

TTN is een onbetaalde dienst die voor opbouw en werking afhankelijk is van de Gateways en Servers die door vrijwilligers en sponsors worden geplaatst en onderhouden.
De 3 plaatjes hieronder tonen op de landkaart (zonder resp. met bedekkingsdiagrammen) de voor mij beschikbare, externe TTN-Gateways.
Een dichtstbijzijnde Gateway van TTN in noordelijke richting is blijkbaar niet meer actief, de dichtsbijzijnde Gateway in richting OZO is nog niet gemeten,
en de volgende TTN-Gateway zit op ruim 3 km afstand
=> nog geen directe 'lucht'-verbinding zichtbaar van onze locatie naar TTN.

LoRa-Devices

MARVIN Development Kit
Als beginpunt voor mijn LoRa-configuratie is een Marvin IoT-Ontwikkelboard aangeschaft met kortlopend Developer-abo bij KPN.
Dat is een ESP-board met daarop een 868MHz-communicatieboardje voorzien van 5 Grove-connectors voor snelle/eenvoudige aansluiting van sensoren e.d.
Aangestuurd door een Arduino-sketch.
USB-Voeding via een printrand-aansluiting of via een micro-USB:
de printrand-aansluiting is gedacht voor directe verbinding met een Powerbank of met een Powered USB-hub.
Mijn intentie is toepassing als Class_A Device voor een 'remote meteo-sensor' met voeding uit batterij en/of zonnecel.

Voor een eerste, functionele invulling is een redelijk nauwkeurige T&H-sensor van type SHT31D aangesloten.
Het EndDevice-pakket (= MARVIN + SHT31D + PowerPack) is in een 'Marvin-bus' geplaatst
[= 'gerecyclede' bus van vijverzout met gaten aan de onder- en bovenkant voor de benodigde luchtstroom]
Met deze device-configuratie en geschikte Gateways e.d. kan worden getest waar dit concept zinvol inzetbaar is:
op de data-bestemming (= Endpoint) zou daaruit een melding van temperatuur en vochtigheid moeten verschijnen.

De uitgevoerde testen met de 'Marvin-bus' en het KPN-netwerk zijn:
1. bovengronds op diverse locaties in het huis
=> wisselvallig resultaat
2. ondergronds in de kruipruimte
=> slecht resultaat
3. buiten aan de noordkant van het huis in een aangepaste behuizing
=> redelijk resultaat
4. rondrijden door Nederland voor testen van mobiel gebruik
=> vaak beter resultaat dan thuis

De extra behuizing beschermend tegen neerslag en zoninstraling bestaat uit een cover met halve 'schoteltjes' om zon en regen ruim weg te houden van de 'Marvin-bus'.
De grafiek laat zien dat testen 3 en 4 in principe met het KPN-proefabo netjes werken.

Ook geprobeerd aan te sluiten op het TTN_V2_netwerk.

Conclusies/Status:

Verbinding van EndDevice naar KPN werkt t/m Endpoint (zonder lokale Gateway)
Verbinding van EndDevice naar TTN_V2 werkt tot aan de TTNConsole (na plaatsing van de Gateway_LPS8),
zolang verbonden met Seriele Monitor
=> Feasibility van 'Marvin-bus' is aangetoond

ToDo:

Omdat TTN_V2 is vervangen door TTS_V3, moet de firmware van de 'Marvin_bus' en van de LPS8-Gateway worden bijgewerkt
'Marvin-bus' voor TTS-verbinding moeten kunnen worden losgemaakt van Seriële Monitor i.v.m. toekomstig stand-alone bedrijf
Daarna poging met de 'Marvin-bus' i.c.m. de lokale TTN-Gateway om een LoRa-sensor in de kruipruimte te plaatsen
Powermanagement voor de 'Marvin-bus' uitwerken met accu-voeding en/of zonnevoeding-met-accu, Slaap-mode en lagere uploadfrequentie,
zodat in een vaste opstelling langdurig continubedrijf mogelijk wordt (met streeftijd voor bedrijf op 1 lading > 6 maanden)
Packaging verbeteren (nadat Powermanagement aanzienlijk is verbeterd)
Grondwaterpeiler aan Marvin-PCB koppelen (in combinatie met bijv. 2*SHT31, 1*Grondvocht-indicator en 1* Bladvocht-indicator),
voor autonome positionering van een sensorenset voor meting van temperatuur & vocht op grotere afstand buiten de invloedsfeer van de bebouwing.

Dragino LSN50-SensorNode
Als vervolg is voor mijn LoRa-configuratie een LSN50v2D20 aangeschaft voor testen met TTS_V3.
Dat is een IP-weerbestendige doos met een 868MHz-communicatieboardje, en in versie D20 met een DS18B20 als temperatuursensor.
Batterij-voeding voor zelfstandige werking gedurende meerdere jaren: aansluiting van externe voeding is optioneel mogelijk.
Mijn intentie is ook hiervoor toepassing als Class_A Device voor een 'remote meteo-sensor' met voeding uit batterij en/of zonnecel.
De infrastructuur, instellingen en firmware van het communicatiebordje maken uitbreiding cq ombouw mogelijk also het een LSN50v2S31 is,
met een SHT31 als T&H-sensor, meerdere DS18B20_thermosensors en ook ADC-ingangen voor analoge devices.

Voor een eerste, functionele testinvulling is een LSN50v2D20 nu binnenshuis in continu-bedrijf.
Met deze device-configuratie en geschikte Gateways e.d. kan worden gekeken waar dit concept zinvol inzetbaar is:
op de data-bestemming zou daaruit een melding van temperatuur en vochtigheid moeten verschijnen.

De uitgevoerde testen met LSN50vD20 en het TTN-netwerk_V3 zijn:
1. bovengronds op diverse locaties in het huis
2. ondergronds in de kruipruimte
3. buiten aan de noordkant van het huis

Geen aangepaste behuizing nodig, maar bij hittegolf is wel temperatuurgevoeligheid geconstateerd, resulterend in uitval:
de hermetisch gesloten behuizing lijkt daaraan schuldig i.v.m. blokkade van ventilatie voor koeling.
Daarom voor buitengebruik beter om ook hiervoor een cover te gebruiken met gestapelde, halve 'schoteltjes' om zon en regen ruim weg te houden.

Conclusies/Status:

Verbinding van EndDevice LSN50v2D20 naar TTS_V3 werkt stand-alone t/m Endpoint Datacake.

ToDo:

Packaging verbeteren voor buitengebruik door toevoegen van behuizing met Covers
Interfacedoosje bouwen voor eenvoudig extern aansluiten aan LSN50 van SHT31, meer DS18B20 en ADCs,
als support van een mini-PWS.
Via AT-commando's de LSN50v2D20 omzetten naar configuratie alsof een LSN50v2S31
Grondwaterpeiler aankoppelen aan de ADC-ingang,
voor positionering via LoraWAN op grotere afstand meer buiten de invloedsfeer van de bebouwing.

Gateway-interfaces

Volgens de dekkingskaarten en de testen op deze locatie wel goede dekking met KPN, maar (nog?) niet met TTN:
=> een eigen TTN-Gateway nodig met verbinding via internet-interface

Testen met de 'Marvin-bus' geplaatst in de kruipruimte onder ons huis valt negatief uit:
geen externe verbinding te krijgen met beide netwerken.
Mogelijke oorzaak:

aanzienlijke r.f.-demping door de positie achter muren en onder de vloer
nog extra r.f.-demping door de Tonzon-isolatie (d.m.v. luchtkussen met alu-bekleding)

Bovengronds in en rond het huis en in de auto (ook dwars door Nederland!) heeft de 'Marvin-bus' wel overal KPN-verbinding,
zolang het powerpack blijft voeden ......
De data gaat in de 'proeftijd' online naar een Endpoint-URL,
waarmee het bijbehorende Mendix_Dashboard nevenstaande grafiek levert,
met weergave van max. 6 meetpunten/uur voor Temp&Vocht (met variërende intervallen).

Plaatsing van een eigen, lokale Gateway (b)lijkt de enige werkende oplossing voor betrouwbaar verbinding maken met het TTN-Netwerk.
Dragino Gateway type LPS8 heeft 8 kanalen, zodat ook geen aandacht nodig is m.b.t. kanaalkeuze naar de Nodes/EndDevices.
Deze Gateway_LPS8 als een lokaal toegangspunt aan het LAN en maakt(e) via internet verbinding met het TTN_V2-netwerk.
Na storing deze interface-rol overgenomen door een vergelijkbare Femto Gateway, nu verbindend met het TTS_V3_netwerk.

Conclusies/Status:

Gateway_LPS8 functioneerde voor verbinding met TTN_v2
Gateway_LPS8 voor TTN_v2 nog niet gekoppeld voor 'Marvin_SHT31-bus' naar externe applicaties
na overgang van TTN_v2 naar TTS_v3 de Gateway_LPS8 & Marvin_SHT31 nog niet overgezet
[en tot die activiteit uitgeschakeld]
bij opnieuw opschakelen van de Dragino LPS8-Gateway voor gebruik met LSN50v2D20 (b)lijkt deze defect:
van Dragino's Helpdesk hints gekregen hoe eventueel te herstellen
als oplossing is een Femto Gateway ingeschakeld:
uitlezing van LSN50vD20 via TTS_V3 t/m Datacake als Endpoint is OK

ToDo:

Dragino Gateway_LPS8 met Marvin_SHT31 opnieuw opstarten, en instellen voor TTS_V3
Gateway_LPS8 als 2e gateway boven in huis plaatsen (o.i.d.) voor betere, aanvullende dekking voor LoraWAN met TTS_V3
Functionele verbinding voor Marvin_SHT31 volgens OSI-model met strakker ritme uitwerken voor de
keten Node/EndDevice => Gateway => TTS_v3 => Domoticz
Mogelijk eenvoudigst passende interface vanaf de Marvin_SHT31 via TTS_V3 naar externe applicaties is via HTTP_Integration
Functionele verbinding voor LSN50 via FemtoGateway en TTS_V3 naar externe applicaties uitwerken

De websectie voor Experimenten begint hier

Sitemap/ Jumplist voor deze website, incl. links to english versions of pages