De Amerta One Gateway

Architectuur zonder handen aan het werk wordt uiteindelijk theorie.

Op mijn werkbank staat de eerste Amerta One Gateway bijna af: een Raspberry Pi 5 met een RAK2287 LoRa-concentrator, via een USB-interface gekoppeld, in een gegoten aluminium buitenbehuizing. Aan de buitenzijde staat een fiberglass antenne voor de Europese 868MHz-band. Er zit al een 4G-antenne op, maar de modemhardware zelf nog niet. In Nederland hangt het geheel voorlopig gewoon aan bedraad Ethernet en aan USB-C-voeding.

Dat klinkt als een verzameling praktische keuzes rondom een Raspberry Pi in een kast. Voor mij is het iets anders: dit is het punt waar vrijwel alle disciplines van Amerta One samenkomen — radio, Linux, embedded, netwerken, cloud, security, datamodellering, energievoorziening, beheer op afstand en mechanische bouw.

Je kunt ieder onderdeel afzonderlijk begrijpen en toch een systeem bouwen dat in de praktijk niet werkt. Een goede antenne lost geen slechte voeding op. Een betrouwbare cloud lost geen wegvallende uplink op. Een prachtige sensorwaarde is nutteloos wanneer niet meer bekend is wanneer, waar en met welke kalibratie die is gemeten. Juist de overgangen tussen disciplines bepalen of de keten bruikbaar wordt.

Daarom bouw ik deze gateway zelf. Niet omdat een architect ieder gat in een aluminium kast persoonlijk moet boren, maar omdat ik wil weten wat mijn architectuur betekent wanneer er echte kabels, connectoren, voedingen en storingen aan vastzitten.

De gateway is geen doel op zichzelf

Amerta One komt voort uit een eenvoudige maar lastige vraag: hoe laat je boeren eerder zien dat het zoutgehalte in hun water oploopt, voordat de schade pas bij de oogst zichtbaar wordt?

Het eerste toepassingsgebied ligt in rijstvelden op Java, waar verzilting, bodemdaling en zeewaterindringing tegelijk spelen. Amerta One gaat dat probleem niet oplossen — een veldmodule stopt geen bodemdaling en houdt geen zeewater tegen. Wat een veldmodule wel kan, is lokaal meten, veranderingen herkennen en eerder waarschuwen. Daardoor verschuift het moment van handelen naar voren.

De veldmodule moet daarvoor zelfstandig bruikbaar zijn: ook zonder telefoon, dashboard of internet moet een boer lokaal kunnen zien of de situatie veilig is, aandacht vraagt of actie nodig heeft. Tirta Cloud heeft een andere functie — meetreeksen verzamelen over tijd en locaties, zodat trends kunnen worden onderzocht en later gerichtere adviezen ontwikkeld.

Tussen die autonome veldmodules en de cloud zit de gateway.

flowchart LR
    F1["Amerta One<br/>Field Module 1"]
    F2["Amerta One<br/>Field Module n"]

    G["Amerta One Gateway<br/>LoRa edge node"]
    B["Lokale buffering<br/>store-and-forward"]
    U["IP-uplink<br/>Ethernet / 4G / Starlink"]
    C["Tirta Cloud"]
    T["Tijdreeksen en onderzoek"]

    F1 -->|"LoRa"| G
    F2 -->|"LoRa"| G

    G --> B
    B --> U
    U --> C
    C --> T

Dat maakt de gateway geen slim tussenkastje dat toevallig data doorstuurt, maar een grenssysteem. Aan de ene kant kleine autonome apparaten met weinig energie, lage bandbreedte en onregelmatige communicatie; aan de andere kant een IP-netwerk met cloudservices, databases, certificaten en beheerprocessen. Die twee werelden gedragen zich fundamenteel anders.

Het architectuurprincipe: stabiliseer wat generiek is

Ik wil voorkomen dat de gateway voor iedere locatie opnieuw moet worden ontworpen. Daarom splits ik het fysieke systeem in drie delen: de gateway, de energievoorziening en de internetuplink.

flowchart TB
    subgraph POWER["1. Externe voedingsmodule"]
        GRID["Netvoeding"]
        SOLAR["Zonnepaneel<br/>laadregelaar en batterij"]
    end

    subgraph GATEWAY["2. Amerta One Gateway"]
        DC["Gestandaardiseerde DC-ingang"]
        PI["Raspberry Pi 5"]
        RAK["RAK2287<br/>via USB-interface"]
        Q["Lokale queue"]
        IP["Ethernet/IP-interface"]
    end

    subgraph UPLINK["3. Locatiespecifieke uplink"]
        LAN["Bestaand bedraad netwerk"]
        FOURG["4G"]
        STAR["Externe Starlink-module"]
    end

    FIELD["Amerta One<br/>field modules"]
    CLOUD["Tirta Cloud"]

    GRID --> DC
    SOLAR --> DC

    FIELD -->|"LoRa"| RAK
    RAK --> PI
    PI --> Q
    Q --> IP

    IP --> LAN
    IP --> FOURG
    IP --> STAR

    LAN --> CLOUD
    FOURG --> CLOUD
    STAR --> CLOUD

Stabiliseer wat generiek is en isoleer wat per omgeving verandert.

De kern van de gateway verandert nauwelijks wanneer ik van Edam naar Java ga; de voeding en internetverbinding kunnen wel volledig anders zijn. Dit principe komt hieronder een paar keer terug — bij de voeding, bij de uplink en bij de regioconfiguratie — maar het is steeds dezelfde keuze.

De voeding komt bewust in een aparte kast. Netspanning blijft daarmee buiten de gateway, warmte en onderhoudscyclus worden gescheiden, en netvoeding kan later worden vervangen door solar zonder de gateway te verbouwen. De interface is een expliciet contract: afgesproken DC-spanning, maximaal continu- en piekvermogen, waterdichte connector. De exacte waarden leg ik pas vast wanneer het werkelijke energieprofiel is gemeten. Een Raspberry Pi met concentrator en 4G-modem heeft een heel ander belastingprofiel dan een slapende ESP32, en een mobiele modem kan korte pieken veroorzaken die in een gemiddelde nauwelijks zichtbaar zijn maar wel herstarts uitlokken. Eerst meten, dan dimensioneren.

De uplink verschilt per locatie. In Nederland is dat Ethernet. Later komt 4G erbij, en op zeer afgelegen plekken kan Starlink als externe uplink worden gekozen — dat blijft een zelfstandig subsysteem met eigen terminal, montage en voeding; voor de gateway is het uiteindelijk gewoon een Ethernetverbinding. Systeemtechnisch verandert er wel iets wezenlijks: Starlink heeft een veel zwaarder energieprofiel dan de LoRa-gateway zelf, en kan op een autonome locatie de dimensionering van paneel en batterij gaan bepalen.

Fysiek zijn de modules gescheiden, maar operationeel wil ik de toestand van de voeding wél kunnen uitlezen. Ik wil op afstand kunnen zien of de gateway geen data stuurt omdat het netwerk weg is, of omdat de batterij langzaam leegloopt.

Bouwvolgorde: van binnen naar buiten

De 4G-antenne zit er al op, de modemhardware niet. Dat is geen vergeten onderdeel maar een bewuste volgorde:

1. radio lokaal werkend;
2. gatewaysoftware stabiel;
3. cloudtransport via Ethernet;
4. buffering bij netwerkuitval;
5. 4G toevoegen;
6. autonome voeding toevoegen;
7. testen onder echte veldomstandigheden.

Wie tegelijk LoRa, Wi-Fi, 4G, solar, batterijen en cloudsoftware introduceert, weet bij een storing al snel niet meer welke laag de oorzaak is. Bedraad Ethernet is stabiel, voorspelbaar en eenvoudig te analyseren — precies wat je nodig hebt om de rest te kunnen beoordelen. Dat gaat minder spectaculair dan alles tegelijk aansluiten, maar levert veel meer bruikbare kennis op.

4G brengt straks zijn eigen problemen mee: APN-configuratie, dekking, roaming, carrier-NAT, reconnectgedrag, datalimieten, piekverbruik, lokale bandondersteuning. Voor Tirta Cloud hoort het niet uit te maken of een bericht via Ethernet of 4G binnenkomt, dus de applicatielaag mag niet rechtstreeks afhankelijk zijn van een specifieke modem. En de connectiviteitscheck moet verder gaan dan “de interface heeft een IP-adres”: een modem kan geregistreerd zijn terwijl DNS faalt, DNS kan werken terwijl de route naar Tirta Cloud faalt, en de route kan bestaan terwijl de TLS-handshake mislukt.

De RF-keten is meer dan een antenne

Voor LoRa gebruik ik een externe fiberglass antenne van ongeveer 55 centimeter. Bij goedkope antennes worden regelmatig indrukwekkende versterkingswaarden genoemd, en die behandel ik zoals ik in dit project alle fabrieksgetallen behandel: als startpunt voor een eigen meting, niet als vaststaand feit. Net zoals de conversiefactor tussen EC-maten locatiespecifiek is en veldkalibratie vereist, is antennewinst afhankelijk van grondvlak, montagehoogte en omgeving. Uiteindelijk telt wat de complete keten doet:

RAK2287
  → RF-connector
  → eventuele verloopconnector
  → coaxkabel
  → antenneconnector
  → fiberglass antenne
  → montagehoogte
  → fysieke omgeving

Iedere overgang kan verlies of storing introduceren. Een lange coaxkabel maakt hogere montage mogelijk maar kost demping. Een extra adapter vereenvoudigt montage maar voegt een overgang toe. Een goede antenne laag achter een metalen constructie kan slechter presteren dan een bescheidener antenne op een vrije positie.

Daarom test ik niet alleen bereik, maar per testpunt ook RSSI, SNR, pakketverlies, datarate, stabiliteit over tijd, invloed van antennehoogte en begroeiing, gedrag bij slecht weer en verschillen tussen uplink en downlink. Ook connectoren vragen aandacht: SMA, RP-SMA, N-male en N-female lijken op productafbeeldingen overzichtelijk, maar je kunt mechanisch passende connectoren hebben waarvan het middencontact niet klopt. Precies zo’n detail waardoor een systeem er compleet uitziet en toch nauwelijks ontvangst heeft.

LoRa en LoRaWAN zijn niet hetzelfde

LoRa is de radiotechniek waarmee data over relatief grote afstand en met weinig energie kan worden verzonden. LoRaWAN is de netwerklaag daarboven, waarin apparaten, sleutels, berichten, kanalen, joins en de communicatie tussen nodes, gateways en netwerkserver worden georganiseerd.

Tijdens het bouwen is een directe LoRa-verbinding handig: een ESP32 verstuurt een bericht en een ontvanger toont wat binnenkomt. Maar zodra meerdere veldmodules tegelijk moeten communiceren, wil ik niet voor iedere sensor een aparte ontvanger bouwen. Daar komt de concentrator in beeld: de RAK2287 ontvangt van meerdere nodes tegelijk en geeft door aan de softwarelaag.

In mijn uitvoering is de RAK2287 via een USB-interface aangesloten — dus niet als Pi-HAT boven op de Raspberry Pi. De losse RAK2287-concentratormodule communiceert technisch via SPI; de gebruikte carrier/interface maakt deze verbinding via USB beschikbaar aan Linux. Dat lijkt een detail, maar het verandert de opbouw: de concentrator blijft een afzonderlijke module binnen de gateway, los te plaatsen, te testen en te vervangen. De GPIO-header blijft vrij en de interne indeling wordt minder afhankelijk van één mechanische stack.

Belangrijker nog: de gateway hoeft de inhoudelijke betekenis van een sensormeting niet te kennen. Hij mag informatie over de radioverbinding toevoegen, bufferen en transport verzorgen — maar hij moet niet stiekem de enige plek worden waar de betekenis van het hele systeem is opgeslagen.

Software: verantwoordelijkheden, geen monoliet

Een gateway is niet één groot programma. Ik deel de software op in onderdelen die afzonderlijk bewaakt en herstart kunnen worden:

Of dat systemd-services, containers of een combinatie worden, is een implementatiekeuze — ik heb geen principiële voorkeur voor containers omdat het containers zijn. Wat telt is reproduceerbare installatie, versiebeheer, beperkte afhankelijkheden, logging, gecontroleerd herstarten en herstel bij fouten. Een eenvoudig onderdeel dat stabieler als native Linux-service draait, hoeft niet in Docker; een complete ingest- of observabilitystack heeft er juist wel baat bij.

Store-and-forward is een kernfunctie

Een veldgateway mag niet aannemen dat internet altijd beschikbaar is. Ieder ontvangen bericht wordt daarom eerst lokaal veiliggesteld voordat het naar Tirta Cloud gaat.

sequenceDiagram
    participant N as Field Module
    participant G as Gateway
    participant Q as Lokale queue
    participant C as Tirta Cloud
    participant D as Dataopslag

    N->>G: LoRa-bericht
    G->>G: Voeg ontvangstmetadata toe
    G->>Q: Sla bericht persistent op

    alt Cloud bereikbaar
        Q->>C: Verstuur bericht
        C->>C: Valideer identiteit en payload
        C->>D: Sla idempotent op
        C-->>G: Bevestiging
        G->>Q: Verwijder bevestigd bericht
    else Cloud niet bereikbaar
        Q->>Q: Bewaar bericht
        G->>G: Nieuwe poging met back-off
    end

Pas na een geldige bevestiging wordt het lokale bericht verwijderd. De queue moet begrensd en observeerbaar zijn: hoeveel berichten wachten, hoe oud het oudste bericht is, hoe snel de achterstand groeit, hoeveel afleverpogingen mislukken, hoeveel opslag beschikbaar blijft. Bij herstel moet de gateway niet duizenden berichten tegelijk over een instabiele 4G-verbinding duwen — rate limiting en back-off horen bij het ontwerp.

Store-and-forward is geen luxe, maar het verschil tussen tijdelijk offline zijn en data kwijtraken.

Een bericht is nog geen meting

Wanneer de gateway een radiopakket ontvangt, is dat nog geen bruikbare onderzoekswaarde. De field module stuurt device-ID, protocolversie, sequence number, meettijd, EC-waarde, temperatuur, batterijspanning, sensorstatus en firmwareversie. De gateway voegt ontvangstinformatie toe: gateway-ID, ontvangsttijd, RSSI, SNR, frequentie, datarate en eventuele radiofouten. Tirta Cloud valideert daarna identiteit, payloadversie en inhoud.

Conceptueel:

{
  "schemaVersion": 1,
  "deviceId": "amerta-field-0012",
  "sequence": 1842,
  "measuredAt": "2026-07-31T11:45:00Z",
  "measurement": {
    "ecRaw": 2.31,
    "ec25": 2.18,
    "temperatureC": 29.8,
    "batteryV": 12.71,
    "statusFlags": 0
  },
  "firmware": "0.3.1",
  "reception": {
    "gatewayId": "amerta-gw-nl-001",
    "receivedAt": "2026-07-31T11:45:03Z",
    "rssi": -104,
    "snr": 7.2,
    "frequencyHz": 868100000
  }
}

Dit is nog geen definitief contract, maar het laat zien dat ik de meting en de radio-ontvangst uit elkaar houd. Eén meting kan door meerdere gateways worden ontvangen: dan heb ik één meetgebeurtenis en meerdere ontvangstgebeurtenissen. Dat onderscheid is belangrijk voor zowel onderzoek als netwerkbeheer.

Idempotentie. Bij een onbetrouwbare verbinding kan de gateway een bericht opnieuw versturen omdat de bevestiging niet aankwam. De combinatie van device-ID, sequence number en meettijd vormt daarom een unieke sleutel: of hetzelfde bericht één of vijf keer wordt aangeboden, het moet één meting opleveren. Het klinkt als een cloudbegrip, maar het probleem ontstaat in het veld — en dubbele records vervuilen analyses en kunnen later verkeerde alarmen veroorzaken.

Tijd. Een field module kan geen goede klok hebben. De gateway kan na een stroomstoring starten voordat tijdsynchronisatie beschikbaar is. De cloud ziet alleen wanneer een bericht binnenkomt. Ik bewaar daarom drie tijden apart: volgens de field module, ontvangst op de gateway, en ingest in de cloud. Wanneer die sterk afwijken, mag dat niet stilzwijgend worden gladgestreken — de afwijking is zelf informatie. Misschien is de klok fout, misschien kwam een gebufferd bericht twee dagen later aan, misschien is een module herstart.

Ontwerpen voor storingen

Ik ontwerp niet vanuit de aanname dat alles blijft werken, maar bepaal per uitval hoe het systeem zich moet gedragen.

Dit is het deel van architectuur dat je op een PowerPoint-slide nauwelijks voelt en op de werkbank wel. Een slechte USB-C-voeding kan eruitzien als een softwareprobleem. Een losse antenneconnector kan eruitzien als slecht radiobereik. Een volle disk kan eruitzien als een vastgelopen cloudverbinding.

Daarom moet de gateway ook zichzelf kunnen uitleggen. Een systeem dat het veld monitort maar niets over de eigen toestand vertelt, geeft schijnzekerheid. Ik wil op afstand onderscheid kunnen maken tussen: geen sensordata, geen radio-ontvangst, geen internetverbinding, een volle queue, een lege batterij, en een volledig uitgevallen gateway. Zonder dat onderscheid stuur je iemand naar een veld met alleen de mededeling “er komt niets binnen”.

Security begint niet in de cloud

Een Raspberry Pi in een buitenkast is een onbeheerd edge-systeem. Ik ga ervan uit dat iemand fysieke toegang kan krijgen, dat een opslagmedium kapot kan gaan, en dat het internet niet vertrouwd is.

flowchart LR
    subgraph FIELD["Field trust-zone"]
        NODE["Amerta One node"]
    end

    subgraph RADIO["Gateway radiozone"]
        INGEST["LoRa-ingest"]
    end

    subgraph OS["Gateway OS-zone"]
        QUEUE["Persistente queue"]
        ID["Gatewayidentiteit"]
        AGENT["Health- en update-agent"]
    end

    NET["Onvertrouwd IP-netwerk"]

    subgraph CLOUD["Tirta Cloud"]
        API["Beveiligde ingest"]
        PKI["Identiteitsbeheer"]
        DATA["Dataopslag"]
        ADMIN["Beheeromgeving"]
    end

    NODE -->|"Gevalideerd radiobericht"| INGEST
    INGEST --> QUEUE
    QUEUE -->|"TLS / eventueel mTLS"| NET
    NET --> API
    ID --> API
    PKI --> ID
    ADMIN -->|"Outbound beheerpad"| AGENT
    API --> DATA

• Geen publieke beheerpoort. Geen SSH rechtstreeks op internet; beheer loopt via een outbound opgebouwd versleuteld pad. Een gateway achter 4G of Starlink hoeft dan niet publiek bereikbaar te zijn.
• Iedere gateway een eigen identiteit. Geen gedeeld wachtwoord voor alle installaties, maar een eigen certificaat, zodat bij verlies alleen die identiteit wordt ingetrokken.
• Field modules en gateway zijn verschillende trust-zones. Een node mag uitsluitend het meetprotocol gebruiken. Een ontvangen radiobericht kan geen firmware-update afdwingen, geen configuratie wijzigen en geen shell openen — het wordt behandeld als onvertrouwde invoer met een vaste, gevalideerde structuur.
• Updates moeten herstelbaar zijn. Een mislukte update mag niet betekenen dat iemand naar Java moet reizen om een SD-kaart te flashen. Versieerbaar, controleerbaar, terug te draaien.
• Geheimen horen niet in Git. Tokens, sleutels en certificaten hebben een eigen lifecycle, los van de broncode.

De precieze beveiliging van het radiobericht hangt af van de gekozen netwerklaag. Bij LoRaWAN zijn authenticatie en versleuteling onderdeel van het protocol en sleutelbeheer. Bij een eigen directe LoRa-implementatie moet ik die eigenschappen zelf ontwerpen; een radioverbinding is niet automatisch veilig alleen omdat zij LoRa gebruikt.

De metalen kast is onderdeel van het systeem

De behuizing wordt door de leverancier als IP66 aangeboden en heeft koelribben. Ik formuleer dat bewust zo: een lege kast kan als IP66 zijn verkocht, maar nadat ik er gaten, wartels en doorvoeren in heb gemaakt, moet de volledige samenbouw opnieuw aan die eis voldoen. De zwakste doorvoer bepaalt of de gateway werkelijk buiten kan hangen.

Aluminium is mechanisch robuust en de ribben kunnen warmte afvoeren — maar het is ook een uitstekende afscherming voor radiosignalen. De antennes moeten dus naar buiten, en de interne Wi-Fi van de Pi zal slechter functioneren. In Nederland is dat geen probleem omdat ik Ethernet gebruik; ik ontwerp het systeem er verder niet omheen.

Koelribben vergroten het oppervlak, maar dat betekent niet automatisch dat de Pi goed gekoeld wordt: de warmte moet ook werkelijk van de processor naar de behuizing worden geleid. Een metalen kast in directe tropische zon kan bovendien veel warmer worden dan de buitenlucht. Ik meet daarom interne temperatuur tijdens duurtests in plaats van te vertrouwen op het bestaan van ribben. Ook condens blijft een aandachtspunt — IP66 houdt waterstralen buiten, maar voorkomt niet dat tijdens montage vocht binnenkomt of dat drukverschillen ontstaan. Een drukvereffeningsmembraan kan later zinvol worden.

En dan de ruimte. De kast is ongeveer 210 × 130 × 60 millimeter, en dat is krap. Daarin moeten niet alleen printplaten passen, maar ook kabelbuigradius, connectoren, trekontlasting, eventuele DC/DC-conversie, toekomstige 4G-hardware, servicetoegang en voldoende thermische ruimte. Ik ga er serieus rekening mee houden dat deze maat bij de 4G-integratie te klein blijkt; dat is dan geen ontwerpfout maar een meetresultaat. Een component dat op tafel past, past niet automatisch onderhoudbaar in een kast.

Nederland is de testomgeving, Java is de ontwerpcontext

De eerste gateway draait in Nederland in de EU863-870-band via Ethernet. Dat betekent niet dat dezelfde radioconfiguratie zonder verdere controle in een vliegtuig gaat. Voor Indonesië kom je binnen de AS923-familie van regionale LoRaWAN-parameters uit, maar de exacte sub-band, kanaalindeling, vermogensgrenzen en lokale toelating moeten vóór plaatsing expliciet worden vastgesteld. Daarvoor kan een andere radio- en antennevariant nodig zijn. De 4G-hardware moet lokale banden en providers ondersteunen. De energievoorziening moet passen bij netkwaliteit, zoninstraling, temperatuur, gewenste autonomie en lokale beschikbaarheid van accu’s.

Ook onderhoud is lokaal. Een installatie die alleen door mij vanuit Nederland kan worden begrepen, is geen schaalbaar systeem. Daarom wil ik reproduceerbare configuraties, lokale diagnose, duidelijke statusindicatie, vervangbare onderdelen, documentatie in begrijpelijke taal, zo min mogelijk exotische componenten, remote ondersteuning zonder publieke beheerpoorten, en een heldere scheiding tussen generieke en locatiespecifieke instellingen.

Internationaal werken is voor mij niet een Nederlands ontwerp exporteren, maar een stabiele technische kern maken die lokaal aangepast en onderhouden kan worden zonder dat de samenhang verdwijnt. Wanneer er straks meerdere gateways op verschillende locaties staan, denkt Tirta Cloud niet meer in “de gateway” maar in een fleet van edge nodes: met unieke identiteiten, gecontroleerde configuratiedistributie, versierapportage en vervangbaarheid zonder historische data te verliezen. Versie één hoeft dat nog niet allemaal te kunnen — ik wil alleen voorkomen dat versie één een doodlopende straat wordt.

De maatschappelijke keuze zit in de architectuur

Het maatschappelijke doel van Amerta One zit niet alleen in het onderwerp verzilting, maar ook in hoe het systeem is ontworpen. De field module moet lokaal waarde blijven leveren wanneer de cloud niet bereikbaar is; een boer mag niet volledig afhankelijk worden van mijn dashboard om te weten wat er in zijn eigen veld gebeurt.

Data-eigenaarschap hoort evenmin pas in een juridisch document te verschijnen. Wie beheert de meetdata? Wie mag die gebruiken voor onderzoek? Wat gebeurt er wanneer geaggregeerde data commerciële waarde krijgt? Kan toestemming worden ingetrokken? Kan een boer of coöperatie de eigen data exporteren?

Die vragen raken direct aan identiteiten, toegangsrechten, tenantstructuur, bewaartermijnen, exportfuncties, logging van datagebruik en anonimisering. Techniek organiseert altijd macht: wie de gateway, cloud en database beheert, bepaalt voor een groot deel wat zichtbaar wordt en wie toegang krijgt. Daarom zijn data-eigenaarschap, betekenisvolle toestemming en benefit-sharing voor mij technische ontwerpvragen — niet alleen ethische paragrafen aan het einde van een plan.

Waarom ik dit zelf bouw

Ik ben geen specialist die zijn hele loopbaan radio-ontvangers heeft ontworpen, en ook geen installateur die dagelijks buitenkasten bouwt. Mijn kracht zit ergens anders: ik kan software, infrastructuur, netwerken, cloud, IoT, security en organisatie tegelijk bekijken en zien waar de naden zitten.

Juist op die naden lopen projecten vast. Een sensorleverancier ziet dat de sensor meet, een softwareontwikkelaar dat de API beschikbaar is, een netwerkbeheerder dat er een route bestaat, een cloudengineer dat de database draait — en toch kan de hele keten onbetrouwbaar zijn. Dan heb je iemand nodig die niet alleen vraagt of ieder onderdeel op zichzelf werkt, maar of het geheel onder echte omstandigheden blijft functioneren.

Dus ontwerp ik de architectuur én sluit ik de USB-kabel aan. Ik denk na over data-eigenaarschap en controleer ook of de antenneconnector klopt. Ik ontwerp store-and-forward en trek tijdens een test gewoon de netwerkkabel eruit om te zien wat er gebeurt. Niet omdat handwerk automatisch beter is dan denken, maar omdat denken beter wordt wanneer het door de werkelijkheid wordt tegengesproken.

Status

Gebouwd: aluminium buitenbehuizing, Raspberry Pi 5, RAK2287-concentrator via USB-interface, externe 868MHz fiberglass antenne met RF-bekabeling, 4G-antenne, Ethernet en USB-C-voeding voor de testopstelling, eerste lokale hardware-integratie.

In ontwikkeling: Linux-configuratie, radio-interface en packet forwarding, persistente buffering, health monitoring, beveiligde remote toegang, logging en metrics, ingest naar Tirta Cloud, idempotente verwerking, update- en rollbackstrategie, temperatuur- en duurtests.

Volgende stappen: ontvangsttesten met meerdere field modules (RSSI, SNR, pakketverlies, antenneposities, kabel- en connectorverliezen), netwerkuitval simuleren en queueherstel testen, 4G-hardware selecteren en integreren, externe voedingskast ontwerpen en het werkelijke energieprofiel meten, interne temperatuur en condensgedrag meten, exacte regionale radio-uitvoering voor Indonesië vastleggen, Starlink als uplinkoptie onderzoeken.

Technische bronnen en nog te valideren claims

Voor de technische uitgangspunten gebruik ik waar mogelijk primaire documentatie:

• RAKwireless — RAK2287 overview
• RAKwireless — RAK2287 datasheet
• LoRa Alliance — RP002-1.0.5 Regional Parameters
• Raspberry Pi — Raspberry Pi 5 product brief
• Starlink — specifications

De IP66-aanduiding van de behuizing, de opgegeven antennekarakteristiek en andere productclaims uit webwinkels behandel ik voorlopig als leveranciersinformatie. Voor het prototype zijn ze bruikbaar als vertrekpunt, maar niet als vervanging voor eigen metingen of certificering van de uiteindelijke samenbouw. Zodra ik gaten, wartels, connectoren en kabels toevoeg, is niet langer de lege kast maar de complete gateway het systeem dat getest moet worden.

De gateway is nog niet klaar, en dat is eigenlijk het interessantste moment: de fundamentele keuzes zijn zichtbaar, maar nog niet verstopt achter een glad productverhaal. Iedere kabel en foutmelding dwingt mij opnieuw te kijken. Kan de gateway zonder internet? Kan hij uitleggen waarom data ontbreekt? Kan de voeding worden vervangen zonder verbouwing? Kan ik van Ethernet naar 4G zonder de applicatie te herontwerpen? Kan iemand anders deze installatie later onderhouden? Levert de keten uiteindelijk informatie op waar iemand in het veld iets aan heeft?

Dat is voor mij systeemarchitectuur: geen dozen tekenen en technologieën benoemen, maar keuzes uit hardware, software, data, infrastructuur, security, beheer en maatschappelijke verantwoordelijkheid met elkaar verbinden. De gateway zal straks misschien onopvallend aan de rand van een veld hangen — maar in die ene kast komen verschillende werelden bij elkaar.