The HIP-51 (Helium Improvement Proposal #51) starts a new way for Helium network. When it has started about 2 years ago, Helium has been designed to propose a global LoRaWan network. But, has I explained at the beginning of this journey, it’s not just a network, its the uberization of the telecom industry. In other words, once you find a good way to transform an industry, there is no reason to just transform on of its services, better is to transform all.
Telecom are not single network, they have IoT networks with LoRaWAN, NB-IoT, LTE-M, they have some WiFi services and 4G/5G services. The HIP-51 is basically a way to go that multi-service direction to compete with telecom industry.
I’ll detail in this post the way this is working (as much as I understood it, reading the HIP-51 currently under vote), and try to explain what will be the impact on the network and tokens.
The Helium router (aka console) is the LoRaWan network server. In a previous post I described how to setup a Helium router / console. In this post I will give you some details of what you can see in the grafana monitoring dashboard and this will help you to understand better how the network works to process the LoRaWan packets. We are going to detail what is an offer, a packet and the different monitoring information we can get from the router.
Helium is an open network, decentralized, there is a wide range of option you can do as a user, like creating your own private router to have your devices encrypted end-to-end. You can also make your LoRaWan traffic to be routed from Helium network to your own network when you are a LoRaWan network provider. Let’s take the exemple of a Telco with a LoRaWan network, let’s name it B’telco and imagine B’telco have an existing network in France. Imagine they want to extends their coverage worldwide, eventually reduce their local cost by removing some redundancy in the cities. In a such case, they can roam traffic over helium.
This means that the data of B’telco devices will be acquired by helium router, exactly as a Helium data, and then it will be routed to B’telco network server transparently. That way, the customer will have a better coverage and the B’telco cost for this worldwide extension will be really low.
In this blog post, I’ll explain how this roaming feature works and what is needed to deploy it.
Until now, all the Helium data-only hotspot I have been tested where DiY devices. They are not really complicated to manage but they are not ready-to-go, so you need to manually on-role them with a wallet and some complex CLI operation for the non-experts. This SenseCAP M2 is the first one I’m testing, ready-to-go or close to be ready-to-go (that does not means it is the only one existing).
As it is a Data-Only hotspot, it means it does not participate to the Proof of Coverage, as a consequence, there is no related rewards for this device. This device only earn the DC (Data Credit) for transferring the communications, so $1 for 100.000 packets. Before getting question, this have no return on invest in a crypto point of view. This has been made to help supporting professional applications on the Helium network.
After reviewing different Helium miner like RAK, Sensecap, Kerlink, Nebra… now comes the Cotx-X3 miner. This miner has a long story and a bad reputation, due to something not really clean the maker did with the first units.
This is not related to the hardware quality and I’ve been happy to buy some of them for reviewing it. This miner is a full miner, based on a standard design using a Raspberry Pi 4. It has the particularity of having a front screen and an audio jack ! Don’t laughs, the reason is simple, this device has a different usage before becoming an helium miner.
I’m currently building a tool to monitor and alarm a fleet of hotspots (stay tuned) and it currently uses the Helium API (api.helium.io). But helium APIs are a bit overloaded and not made to support high rate querying from each of the application any member of the community is developing. So I’ve been decided to make my own instance of ETL and API for my own purpose. This is the experience I’ll describe in this blog post:
In a previous blog post about 18 month ago, I designed my first Low Cost LoRaWAN Solar Gateway. This year, I did some updates to create a new version to support Helium Data-Only Hotspot (basically it works for any LoRaWAN networks like TheThingsNetwork).
In this version, I’m using a RAK wisegate Lite gateway, it is a bit more power consuming than the TTIG but can work on any LoRaWAN network. I’ve also changed the outdoor enclosure to get a larger and single battery.
You will also see that I’ve been updated the monitoring dashboard to get something better and free of charge. Two of them are in production. One is already deployed as an upgrade of the 1st one and the second one is in the testing phase. The First version has been on the field for more than a year. It has been offline about 10 days during that year, due to the weather conditions. This is a service level of 98,29% from its start until now. With the larger battery I’m expecting to resolve some of the small service interruption I’ve issued during last winter.
Kerlink is a LoRaWan hardware player since the first ages of this technology. This French company has equipped most of the operator’s network and is used to propose high quality industrial products.
The iFemToCell is not a new product. It exists since a couple of years and I already tested the IFemToCell 4 years ago. Recently the company has created a Helium edition we are going to review in this blog post.
This is an interesting device as it is a kind of hybrid between a light miner and a full miner. Even if the Kerlink platform is powerful, it is far away the power of a raspberry Pi and certain operations like consensus group can’t be performed. As this is now delegated to Validator, this difference have no impact on rewards. In another hand, this device is consuming less power and it is possible to power it with sun more easily. This is quite interesting.
Let see what is this device and what is specific during its deployment.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.