This has been discussed a number of times and generally is a bad idea (please search previous discussions for the reasons why). As LoRaWAN bandwidth is a fraction of a usual internet connections bandwidth is isn’t useful unless you are on a metered connection. And even then it’s a bad idea…
A further analysis of the 7,000 most active Helium hotspots that handle 90% of the real data traffic:
- Europe sees about 60% of the total traffic, with Serbia, Greece and France each over 10%
- the USA only sees 10%
- full list on Github with map
For the most active Helium countries (in terms of real data traffic), i compared with number of TTN gateways:
(note: i did not use the new TTN API for this analysis as i could not find the country in there, the old https://www.thethingsnetwork.org/gateway-data/country/ still seems to work)
Belgrade, Athens, and Paris seem to have dense and active Helium networks.
9 Likes
Brilliant work, shedding light on this. The concentration into a few (54?) hotspots might suggest clusters of hotspots where they are all seeing the same very active node(s) broadcasting and being very active generating apparently lots of traffic… how geographically dispersed are say the top 50,100, or 150 hotspots wrt activity?
Ultimately the killer for me here is your assessment that:
- The average DC value of the total traffic per day was USD 191
And this on a network they claim to be mining $millions per week across the full estate? How will all that HNT ever get spent and consumed (not least what has already been accumulated!), unless some clever person plans on cashing out some how (ponzi?). Note ‘net searching for HNT exchange and cashing in options seems to generate 10x links for buying HNT vs selling them 
Unless there is some future volume method for using HNT for trade or other commercial transactions outside of using data on the Helium Network surely this is going to end in tears by bedtime? ( or is it that I simply don’t get all this crypto currency nonsense & hype?! 
)
I commented on private thread to some of the other mods how there has recently been significant growth in coverage as shown on Coverage Map here in UK and near me, at least along major transport routes, suggesting increased real coverage, despite lots of fakes appearing late last year and early this…then disappearing again…I seen numbers ramping again over last week but sure many still fake/returning fakes…including the one that comes and goes virtually in my back garden! (I’m sure I would have noticed and which shows no coverage on the heat map despite fact I know it should cover some of the local tracks that the heat map indicates). Time for a chat with the neighbours!
That coverage map doesn’t seem to have many helium hotspots on it. Recommend checking out the community-run coverage mapping service at mappers.helium.com or the actual blockchain explorer itself at explorer.helium.com which shows the on-chain asserted location of the hotspots and their beacons.
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…
Hmmmm, now that’s an idea!
No, not at all, all sorts of technical & legal complications, see forum discussions for the details.
Thanks for taking the time to do and share your work.
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.
A few weeks ago, Helium started to update its traditional mining hotspots to ‘Light Hotspots’, effectively removing them from the blockchain as it was becoming, surprise surprise, impractical.
Details at GitHub - tomtobback/helium-data-traffic: script to analyse data traffic on the Helium network by accessing the blockchain API
9 Likes
I’m not sure if these hotspots really exist 
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
1 Like
Regarding this whole topic - it seems there’s nothing to compare TTN with yet
And there’s a lot of other funny issues. Their server just doesn’t work well enough yet. There’s no network. Nothing ready for production use.
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….
"
Upcoming
The team’s focus in the coming weeks (usual disclaimers apply):
…
- Scaling out roaming services
-
LoRaWAN roaming protocol support
…
"
Taken from Console Updates- v2.2.10 | Helium Engineering Blog
So, the L-A doesn’t seem to agree with their idea
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.
They do. I build one myself and after a year of data transfer, I still cannot purchase a pizza out of my earnings.
2 Likes
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.
2 Likes
A bit off-topic…
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 ofcmac(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?
9 Likes
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.