This thread initiated to allow comparative discussions of Helium Networks implementation vs classic TTN or Classic LoRaWAN without pollulting/confusing other threads following on from Library post:
1 Like
And waste an awful lot of energy… LoRaWAN gateways consume plenty by themselves, adding crypto miners won’t help to reduce energy consumption. Hopefully everyone deploying these gateways will use solar power to power them…
6 Likes
Helium mining doesn’t use any additional electricity. It’s not bitcoin.
1 Like
full disclosure: After years of hardcore TTN advocacy and support in the States, I recently took a position as Developer Growth Lead at Helium…
With the Helium network now supporting LoRaWAN, I simply cannot ignore the numbers. Please take a look at the coverage map at https://network.helium.com/coverage
I love what TTN has done and continues to do, and I will, of course, continue to be involved in the community both locally and online, but the stateside adoption has been stagnant compared to what Helium has done in a matter of months. I would love to see connectivity between the two networks moving forward…
5 Likes
I shortly sudied Helium and it is an interesting implementation that might have solutions for shortcomings as we have with TTN and TTN Industries. However: Helium is currently only supported for US and US frequencies and therefore not interesting for anyone outside US. too bad.
1 Like
Duty cycle of GW is a major consideration/concern/legal/regulatory issue in many areas vs US so fact that network has Miner/GW’s servicing multiple NS is problem as NS is normally responsible for managing the DC…No one NS in Helium type architecture will have full view of overall GW DC and so there is risk of DC breach, hence only for US or equivalent territories at this time?
This is actually not the case. Each gateway/hotspot must run a companion miner application which the packet forwarder connects to. Data is then routed from the miner to the eventual network server. The miner keeps track of regulatory requirements as well as routing and blockchain related functions, such as participating in proofs of coverage and micro transactions for packets.
1 Like
So if a given NS selects a specific GW to send e.g Join Acccept or an Ack for confirmed payload upload or what ever how will the NS know that the GW has exceeded its DC?.. or does the miner issue a denied/not available message to tell all ‘connected’ NS’s that a given GW is not available for downloads, and for a specific time? (I looked at potential for ‘multi-homing’ GW’s some 4/5 years back for resiliance (fail over if a NS service went off line of out of business - many/most were just early funded start-ups and large corporates were reluctatnt to engage as a result at that time) and to see how GW’s could be exploited for more NS Services to help sweat the deployed asset to greater value, and management of the GW DC by disconnected and none associated NS implementations without any means of co-ordination was always the stumbling block (or at least one of them! 
)
As I said, keeping to US reg requirements is easier (focus on dwell time & Tx power management) than other areas of the world where DC and potentially also LBT requirements might apply? Or is the Miner acting similar to a mini packet brocker?
@kersing, can I ask if you might clean up this thread leaving the original Semtech/Helium PR post above in here but moving rest of exchange to a seperate forum thread for Helium discussion (Helium Network Comparative Discussion ) - not sure if I have right privaleges as a Leader vs Moderator…I will try myself sometime tomorrow otherwise. 
In the current implementation the miner will push back on the NS (router in our terminology) if the duty cycle has been exceeded. It would definitely be possible to send some DC state up from the gateway to the router along with uplink messages and for the router to keep track of that.
Is my interpretation correct that the collective of miners form the logical network server in Helium?
Sort of - there is still the encryption termination point at the router, and the router is ultimately where all the LoRaWAN join credentials live. Miners have no ability to decrypt the packets they are passing to various routers.
I’ve retrofitted one of our EU868 gateways (our solar powered system using RAK7294) to Helium, it’s quite simple really - for now just needed a mapping of EU to US frequencies and data rates. I can post the miner code which does the mapping if anyone is interested - or just wait for official support in about 2 months’
3 Likes
I am interested, thank you.
@illperipherals I do agree on the incentive piece, at $350 a pop, SF is totally covered while there are only 2-3 working TTN gateways even a Raspi gateway is less than half that of the Helium hot spot. Something must be compelling people to buy into it
1 Like
Hi
I will be interested in. I just converted my TTN router to Helium.
I would like to check what options I have.
Thank you
The adverstising video is well done.
But the advert does not seem to be specific about how much you might\could get back to redeem the ‘investment’.
So what is the ‘community’ reporting that they are getting back in ‘tokens’ ?
Anyone know ?
The reddit community has multiple reports. But the number of earned tokens per hotspot is expected to go down as more and more hotspots are deployed. Also, the exchange rate to fiat currencies is fluctuating (as with most blockchain-based coins).
What options did you have in mind? As this is TTN, the options would need to relate to that and as there is close to no coverage in the EU for Helium and it appears to require all sorts of mystery mining & a costly gateway, peering doesn’t seem likely.