I stumbled upon your very nice analysis while trying to understand how ‘useful’ the Helium network actually is. To elaborate on this, I think quite some of the real data packets are used for Coverage Mapping, which seems to be quite popular. It is promoted by the 10000 DC you get for free when creating a new account on the Helium Console. However, I would not call this a real use-case, as it purely for the benefit of the network itself (and maybe the fun). Also, I suspect people to buy DC when HNT is low, and then let a sensor transmit meaningless data to their own hotspot in case of more favorable HNT price.
On another note, with the upcoming Data-Only Hotspots, would it be possible to simultaneously connect them to TTN? If we could somehow encourage the miners to do this…
There was a very profitable arbitration “attack” in Q3 2020 that allowed people to get a much higher reward for receiving traffic than the cost for bying DC for that traffic (link). It was closed witin a month or so. That method did not even require the exchange rate to change.
The method you describe would be less efficient than just buying HNT (for fiat money) when HNT is low and sell HNT when it is high. (Just like you can with any currency, stock or commodity) No need (or use) to go the extra step through DC.
Hi, an update on the Helium network’s real data traffic:
Despite the spectacular growth of the network (50k new gateways/hotspots per month, currently 834k), the data traffic has seen a sharp drop in early May, with a current average 6.7M packets per day (vs TTN 48.9M), and barely 18% of the Helium hotspots seeing any real traffic at all.
Average daily value generated by the traffic (via Data Credits) is USD 428.23, still well below the price of a single Helium mining hotspot. Yet, the network continues to magically reward earnings of 2.5M HNT per month, worth about USD 23M.
So-called ‘Data-Only Hotspots’ account for less than 0.2% of all hotspots but recently take almost 70% of the data traffic. I’ve tried to raise this on the Helium discord but get no feedback.
So, you can install their gateway-rs tool on your PC, spend USD 40 equivalent or so for onboarding, run any packet forwarder emulator “sending the packets” with, for instance, Senet’s devaddrs, and voila… You’re “earning” 2 DC per every 24 bytes. Helium’s dev. lead confirmed this schema works
So, without reading or attempting to understand the details, if I understand the gist of this in oder to solve a problem of their own making they are now attempting to develop and push a change to the LoRaWAN spec to be adopted by the L-A that will then potentially impact all LoRaWAN networks further complicating what was a relatively simple and straight forward system I fully understand there may be a need to change/update system/software for my Helium kit as part of that specific network and its ‘fork’ but to force further change on my/my clients TTN, Chirpstack, Loriot, TTI, Digimodo, Actility, Senet, Orange, KPN, Fastnet, Bouygue T, Orbi……private networks, etc etc or whatever systems is a bit rich and feels selfish/self serving…… just saying! Part of me almost hopes they see some push back….I know standards and specifications evolve through need and through developing solutions to identified problems or security issues, but….
Sorry, I may be stupid but what is the relevance of your message after this statement? If I would chose not to read anything on a topic, the consequence would be that I would be silent.
I think @Jeff-UK was trying to say - “Here’s my summary of a complex topic without me going right down the rabbit hole” - both of us have recently acquired a “money from thin air” box and are wading through the reality of it all - which is very much an alternative universe skewed away from actually using LoRaWAN for real with many inexplicable communiques that appear to be fire fighting their way towards some actual utility.
At present I don’t even know how to shut down my gateway so I can move it in the office to a more appropriate location. The “rules” prohibit us being able to SSH in to it, which transpires that you can’t then setup any form of management of the gateway of your own. And as the console has recently been restricted to a maximum of 10 devices because they don’t want volume users (who pay to transfer data) to place a burden on their central servers.
It is very surreal and sadly at present they seem to be winning the marketing war.
Yep, this is known as the “lying Serving Network Server (sNS)”. Today, the Serving Network Server (sNS) cannot prove that a frame forwarded by a Forwarding Network Server (fNS) has been successfully accepted or not. It could be randomly generated, it could be an actual device whose session is gone, it could be a retransmission, it could be received by other forwarding networks so sNS may not pay out to all fNS, etc etc.
To address this, there’s a solution that is currently being discussed in the LoRa Alliance Technical Committee. It has been proposed by other members and is now back on the table. The idea is twofold:
Forwarding in two steps: an offer and the actual data transfer. The offer will contain public metadata: DevAddr, FCnt, a new hash and the MIC, but not the actual FRMPayload. This allows sNS to do device matching (with MIC check) and other decisions to buy the frame, and then go back to fNS to get the actual payload. This requires that the MIC is no longer based on the FRMPayload, so there’s a second change needed:
The MIC should be calculated as cmac(k, hash(phy_payload))[0:3] instead of cmac(k, phy_payload)[0:3]. This means that if sNS only knows the hash, it can do the MIC check for device matching. This is a change in LoRaWAN that is only going to be possible with LoRaWAN 1.2.0. I can’t comment more on this publicly at the moment.
Back on-topic. Now with the expected collapse of the economic model of running Helium hotspots and the lack of actual use of Helium as a network server, it may be time to evaluate what we can learn from this and what we can apply to The Things Network.
Background story:
As some of you know, in 2017 we prototyped a value exchange with our own coin (Wavelet) on top of Ethereum with builtin support in our V2 stack. We showed it to some key community members and decided to kill it because people indicated that they didn’t put up gateways to make money, and that value contribution in TTN is not only putting up gateways but also answering forum posts, organizing meetups, writing articles, etc. So what we did was limited to gateway owners getting paid in Wavelets directly but anonymously by application owners who made use of their gateways. The V2 stack was the authority by submitting to/from transactions to a blockchain.
What can we learn? A few or my hypothesis:
There’s no sustainable economic model behind setting up individual gateways for someone else. It may work for some nationwide operators (Orange, Swisscom) and it may not work for others (Proximus, Bouygues Telecom, Sigfox). Even for those operators for whom it does seem to work, it’s probably not standalone LoRaWAN that makes it worth it, but rather being a one stop shop for connectivity and packaged deals.
Implementing LoRaWAN the way it is meant to be and making sure your LNS is feature complete, is still key to success. Like we struggled from 2015 to 2019 with our V1 and V2 stacks, Helium is now struggling with limited LoRaWAN support, prioritizing precious developer resources on blockchain mining rather than supporting LoRaWAN completely (1.0.4, class B and C, multicast) and in a stable way
Making shiny marketing material and using random blockchain terms that nobody really understands works works really well. In any case, the coverage map is pretty nice, as well as the realtime stats
Proof of coverage can be pretty useful for knowing where gateways are and whether they are online, even if there’s no or very little LoRaWAN traffic around. We can pretty easily implement this by transmitting uplink frames from gateways that are received by other gateways. We don’t need cryptograhpic challenges and verifications.
What else can we learn? What can we apply?
But I guess you did expect this before buying the money from thin air box, right? I’m honestly curious here. You knew enough about economics and LoRaWAN that you can’t buy a box for 500 and make 500 profit per month, right?
Sort of, I wasn’t expecting some miraculous alternative to TTS but it’s very hard to look from the outside and see the reality.
Absolutely, the thinking behind the economics run thus:
When purchased (a RAK GoldSpot) about two months ago the ROI just leaving it turned on was ~24 months, which was a bonus. ROI has sagged a lot of late, maybe if I move it to the dining room where it will then be in a different hex which will get more bonus points (I think) and if I run around with a device doing some mapping (I think). Or put it on a decent antenna to get some range for proof of coverage (I think) - bearing in mind that the roof already looks like GCHQ so I’d rather not.
Once I got one, it turns out I can register a new user account and get some credits for creating my new device and then transfer them across the office from a random device to the gateway. But I’ve actually got better things to do at present.
The real value to me is in the authoritative knowledge and being able to clearly demonstrate use of the network - it will take just one enquiry where the prospect is interested in the Helium network to pay for itself - either (sadly) by running with it with a view to moving to TTI or just getting them on to TTI/TTN from the start.
Use of LoRaWAN is my niche, I do LoRa P2P, WiFi & 2.4GHz as well plus a bit of GSM, BLE & Iridium - so from my perspective, knowing the reality of the different offerings is rather important.
I believe we’ll see some 100K used Helium miners (and a lot of accessories), competitively priced (way less than $100), on eBay relatively soon. It may be a time to prepare something like reflashing guidelines
Their gateways don’t have GPS, and that’s “by design”. So, sorry, no chances for Class B. Interesting that one of the largest water meters manufacturers in the US seems to be pretty interested in this feature (so it seems Helium didn’t put enough effort into market research).
I fully understand there may be a need to change/update system/software for my Helium kit as part of that specific network and its ‘fork’ but to force further change on my/my clients TTN, Chirpstack, Loriot, TTI, Digimodo, Actility, Senet, Orange, KPN, Fastnet, Bouygue T, Orbi……private networks, etc etc or whatever systems is a bit rich and feels selfish/self serving…… just saying! Part of me almost hopes they see some push back….I know standards and specifications evolve through need and through developing solutions to identified problems or security issues, but….