18 june test and Repeaters
18 juni nodes
T1000 Companions
| Name & Lokatie | Public Key | Eigenaar | Preset | Version | Dakrepeater toegevoegd? |
|---|---|---|---|---|---|
| Calandhal | 8b9cc8bff9763dd33b5239cf50bf5b6c1af6d66b1800bb761ed1b142e3270c1b | Coen | NL | 1.16.0 | Ja |
| Kazerne Osdorp | 283cc75a0875f53fd38eeaa58f4a81a91dfedf38455a8c73f084482e15b635bb | Thijs | NL | 1.16.0 | Ja |
| Kazerne Nico | 92a7f95e0608193d1423b3d3735dcad5e34f8ab404193b15dbc4c88c02cf0e36 | Henk | NL | 1.16.0 | Ja |
| Boomspijker | be0757d425d74e7316697af7d7e73be283e0e1f5dc3bc7dae0c24ef84dec3176 | Fabian | NL | 1.15.0 | Ja |
| Amstel 1 | xxx | Eva | NL | 1.16.0 | Ja |
P1 Repeaters
| Name | Lokatie | Public Key | Short Code | Preset | Version | Region set?* | Coordinates |
|---|---|---|---|---|---|---|---|
| 18 juni - Calandhal | Calandhal | D2AFDFC4A4166D18CF322339A4D5ECA683BC2860EB6FF7801580AAD5ACC846A7 | 1 | NL | 1.15.0 | nl-ams | 52.3540, 4.8074 |
| 18 juni - Kazerne Nico | Kazerne Nico | DED43470A30092B4BE78B9FD852BE3594C46A98ABB348A2BB2DA78C4D27941F5 | 3 | NL | 1.15.0 | nl-ams | 52.3701, 4.9095 |
| NPN 004 | JvG | 6ED25B011C324D839E23854FF10E13F14271FA2C29966FF77FD786F87584768C | 4 | NL | 1.16.0 | nl-ams | 52.3715, 4.8434 |
| AMS01 | Stopera | 1165023ee477dbd95ffd416121ef238f4859ca33bde39ff2db98e56df4c64625 | nvt | NL | 1.15.0 | nl-ams | 52.3685, 4.9004 |
| AMS03 | Boomspijker | 021bc6fa42d97d33732501a619348c0f15ef94c1774290f25dba5152d5d8870d | nvt | NL | 1.15.0 | nl-ams | 52.3720, 4.9035 |
| Noorderhof Solar 2 | Coen's hous | 01c84f800c24ef039f5bf8188eb5a579d5857adb8b569e873191749c1a7067b7 | NPN 005 | NL | 1.16.0 | nl-ams | 52.3752, 4.8218 |
| NPN - Kazerne Osdorp Repeater | Kazerne Osdorp | 47B232CC396D001DFB71A695B666F0512A0FB6257D08D0C288657DF83989E70E | nvt | NL | 1.16.0 | nl-ams | 52.3665, 4.8025 |
| 18 juni - Kazerne Osdorp | Kazerne Osdorp | 38c917cb9d2c35b227ab56d80cc95877787348acc2f2f4d7ab1583187db96d20 | nvt | NL | 1.16.0 | nl-ams | 52.366530, 4.802480 |
Region set?* = Amsterdam only. We set:
region def eu|* nl nl-ams nl-nh-ams|* nl nl-ams
region save
Part of the NPN Crisiscommunicatie research programme (lead: AMS Institute; partners TU Delft, ProcoliX, City of Amsterdam).
In one paragraph
On 18 June 2026, the City of Amsterdam and the Safety Region Amsterdam-Amstelland (VRAA) will run a multimodal field test of alternative crisis-communication technologies between fixed sites across the city. As a low-cost add-on, we measure whether a LoRa mesh network (MeshCore) can carry short crisis messages across Amsterdam during a power outage. To do this we deploy a small network of repeaters for realying and passive "observer" nodes that quietly log every radio packet they hear. The goal: a real-world, city-scale dataset on mesh coverage, message routing and delivery — both on the Dutch MeshCore network and on an isolated network.
What is being tested
Can a city-operated LoRa mesh reliably pass messages between emergency support points in a neighbourhood and coordination points at fire stations, across ~6 km of urban terrain, with no internet and no mobile network? We measure this on the radio layer: which links are strong, which fail, how far traffic reaches, and which route messages take through the mesh.
We do this twice: once using all the available infrastructure of the wider Dutch MeshCore community, and — in the second half of the test — only on our own infrastructure.
Setup
- Sites: three emergency support points (Amstel 1, De Boomspijker, Calandhal) and two coordination points (fire stations Nico and Osdorp), plus P1 relay repeaters on high rooftops.
- Radios: MeshCore on SenseCAP T1000 hand-held nodes (participants) and SenseCAP P1 solar repeaters (rooftops).
- Channel: a single shared group channel.
- Two measurement blocks (the network switches frequency at ~14:30):
- Block 1 — community frequency (869.618 MHz): the mesh shares the air with the wider Dutch MeshCore community network.
- Block 2 — isolated frequency (tbd): the test network runs alone, with no outside traffic.
Comparing the two shows how a shared vs. a dedicated frequency affects coverage and reliability.
The observer network
Six battery-powered observer kits (a Raspberry Pi paired over Bluetooth with a passive MeshCore node) are placed at the sites and at a high mid-point between the two fire stations. They do not transmit; they only listen and write, for every packet they receive: a timestamp, signal strength (RSSI) and quality (SNR), a packet fingerprint, and the routing path (the chain of relay nodes a message hopped through). After the test the logs are merged and decrypted offline, producing:
- a coverage map (which locations heard which messages),
- link-quality statistics per connection,
- flood depth (how many nodes relayed each message),
- a delivery rate against a known schedule of sent messages,
- and message routes plotted on a map, by matching node prefixes to GPS locations.
What the data can — and cannot — say
The observers measure the radio layer, which is a strong proxy for reachability and link quality, but not the same as an application-level "delivered" confirmation. Because the two frequency blocks run sequentially (different times of day) and the community load is uncontrolled, frequency differences are reported as observed on the day, not as a clean causal result. Honest scope is part of the method.
Why it matters
During a long power outage, ordinary phone and internet networks fail. A citizen-operated LoRa mesh is one candidate to keep neighbourhoods connected to emergency services. This measurement delivers the first real, city-scale evidence of how such a mesh behaves under real urban conditions — a reusable, low-cost blueprint for the larger field-lab runs planned at Marineterrein in 2026–2027.
All data sets will be published here on the wiki for anyone to download and analyze under a free non-commercial license.
