The Helium Explorer is mainly a tool for HNT miners, due to widespread location spoofing it does not show real network coverage (see previous posts and denylist). So in order to understand the real network coverage, i built a GPS tracker (see below), configured it for the Helium network, and attached a few integrations to the device:
- Helium Cargo is a mapping tool for real-time tracking
- Helium Mappers shows the actual network coverage of the Helium network, contributed by volunteers (as we’re doing here)
- Coverage Map is similar to Mappers but 3rd party, also volunteers
- my own ThingsBoard instance to store and visualise data
Conclusions so far:
- 6 hotspots confirmed (nobody else in HK has contributed any data to Mappers)
- coverage over open sea is quite good; however, in the city streets, even close to hotspots, it seems quite poor
Helium is built around rewarding hotspots, but has no incentives to prove actual coverage for devices although they recognise it is the only real world value of the network.
For network users, the map proves the real-world coverage that hotspots provide. This is like looking at the Verizon or T-Mobile map when evaluating phone plans, but for business users. This real world evidence at the scale and resolution offered by our map gives prospective network users the information they need to make decisions about their deployments. As an example, this map is what someone like Lime scooters would look to before they sign a contract. In short, a robust map means high priced customers, which means adoption, which means the network grows and the token value increases.Helium Coverage mapping
What do we know about fake hotspots? The Hotspotty app allows us to show the denylist: for the Hong Kong/Shenzhen area, 1,405 of the 3,356 online hotspots are known fake, that is more than 40%!
Unfortunately Hotspotty does not let us filter the non-denylist hotspots, but from my previous experiments i knew there were some real hotspots in Victoria Harbour. I built a LoRaWAN tracker device including a GPS, to be able to push data to the Helium Cargo mapping platform. I added a u-blox NEO-6M GPS module to the LoRaWAN prototype that i described here and took it into Central Hong Kong.
The Helium console is quite a slick interface. It showed me more than 50 uplinks where received by hotspots today, but from the gaps in the blue frame counters we can see that many frames were not received by the network. I did reset the device a few times, resulting in a new join and reset of the frame counter. Initially, i forced the device to use SF7, as recommended by TTN for mapping (showing worst-case-scenario coverage). The join uses SF10 by default, and that worked, but no SF7 frames were received, so i disabled the forcing, and then the frames started to be received, using SF9 and SF10. I added a function to decode the incoming bytes into the required json format for Cargo and Mappers. I also enabled Multiple Packers, to see all the hotspots that received my frames.
In Helium Cargo you can follow your tracking device (blue) and see some real-time data, displayed over the Mappers background (green hexes). We took the tracking device on a ferry from Central to Mui Wo, hence the locations in the sea.
Helium Mappers shows the expected network coverage in each of its green hexes, and clicking on them shows which hotspot covers the area. The grey hexes are supposed to have hotspots but it’s clear that many of those locations are fake hotspots because they did not receive any of my device’s data, while my device is configured to ‘buy’ packets from all hotspots that received my frames (‘multiple packets’ setting).
So far i have confirmed the existence of 6 Helium hotspots in Hong Kong, and the Helium Console makes it easy to list them in the Coverage tab:
As a further experiment, i have also linked my Helium network device to an HTTP integration that sends its data to my favourite IoT platform Thingsboard.io where i can visualise the data in my own dashboards. The data json that comes in needs a bit of scripting to extract the decoded payload into telemetry keys, this is easily done in a dedicated rule chain.