Having used both TTN and Helium, I must admit, Heliums onboarding interface is easier to use. They don’t have many options to choose from(no ABP activation for example) which simplifies things greatly. And best of all, I have coverage where I live in London, UK. 4-5 Helium gateways pick up my transmissions. At best, on TTN, I have only had one gateway pick up my transmission(apart from my own) and at best it happened very rarely.
1 Like
About the issue of Helium traffic potentially causing congestion on the TTN network
The Semtech UDP Packet Forwarder running on my Dragino LPS8 allows me to filter on DevAddr, so i could put 26 there to accept only TTN packets, correct? The Basics Station configuration does not provide such filter, or is it smarter by default? (it’s not stable on my LPS8 so i stopped using it)
You can put the filter value of “26” in there - but it doesn’t seem to work. Still all other data were forwarded to TTS.
Please dont as TTN kindly also allows use of e.g. experimental nodes which start 00 or 01 (under ABP? - I dont believe Helium allows ABP, only OTAA), also with systems like Packet Broker or other roaming mechanisms available in LoRaWAN land there may be ‘foreign’ devaddrs which will still be legitimately handled through your GW and then processed in the back end under roaming areements and then routed to their home networks and where in exchange the ‘foreign’ network also sees TTN & TTI addresses and routes them back home. Filtering would potentially break these arrangements as well as potentially breaking the TTN Manifesto permitting open fair access without technical or use case restrictions (which is what filtering would be), subject always to potential FUP enforcement. If you search Forum you will see filtering often comes up in discussions - typically every few months, and usually where someone wants to ‘protect’ their GW and only allow their own traffic vs full community access but they would still want to use the full backend services that are provided free for us all by TTI/TTN…
2 Likes
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.