Open Vestibule22 opened 3 years ago
@Vestibule22 perhaps it might be better to add support for various different lora gateway concentrators in a similar way to how they did it here https://github.com/jpmeijers/ttn-resin-gateway-rpi
@shawaj That is currently what we are looking into and seeing what would be the best approach for this. This could be a fork for 2287 or different repo that handles the 2287 vs the 2245.
@Vestibule22 maybe just easier to use environment variables, in my opinion.
@shawaj This will all depend on if it causes issues with the hotspot itself. Those of us with an Alpha code to run a DIY miner could lose our availability to mine HNT if there is any changes to the miner portion. We are open to suggestions on approach as I am not well versed in the changes needed. Just trying to be able to allow the 2287 to work with this repo.
I know @just4give noticed areas that would need to be updated but I am not sure how he plans to approach this or if he is open to suggestions to do this the easiest way possible.
@Vestibule22 @shawaj This is what we were discussing over discord , using ENV variable sounds better than multiple repos. Unfortunately I am having a bit time constraint due to some other priorities. Anyone wants to volunteer the change?
I can probably work on it a bit with the team from Balena (I'm from @balena_io too in case it wasn't obvious)
@ryanteck is from @PiSupply and has been playing with this too.
What is the discord server link?
@just4give @shawaj I am more than happy to help but I sadly do not have a lot of experience with this coding and what not. But I am happy to help test as I have the equipment. The only thing that I am concerned about will be if this requires a new image or something else that could cause my already active diy hotspot to stop working and cannot use the alpha code I got anymore. Also the Discord channel is on the Helium Discord under Hotspot DIY Hardware here - https://discord.com/channels/404106811252408320/730246424666832947
@Vestibule22 are you running on balenaCloud? If so it should be possible to to update without losing anything.
But I'd definitely backup your SD card as well.
@shawaj I will definitely do that when we are ready to test. I also have an extra Pi or 2 laying around that I can test that it is functioning first before testing on my live hotspot. We can still build a DIY but it just will not mine or be asserted. But the packet forwarder can still route packets.
@Vestibule22 how do you get the key for allowing mining that changes it from a DIY to a miner?
@shawaj We had to get an alpha code that is placed into your assertion commands below. They were added using the HostOS terminal on the Balena Cloud.
docker exec miner miner txn add_gateway owner=YOURWALLET --payer 14fzfjFcHpDR1rTH8BNPvSi5dKBbgxaDnmsVPbCjuq9ENjpZbxh
helium-wallet --format json onboard ADD_GW_MINER_OUTPUT --onboarding CODE --commit
docker exec miner miner txn assert_location owner=YOURWALLET location=LAT,LON --payer 14fzfjFcHpDR1rTH8BNPvSi5dKBbgxaDnmsVPbCjuq9ENjpZbxh
helium-wallet --format json onboard ASSERT_GW_MINER_OUTPUT --onboarding CODE --commit
@shawaj The alpha program shut unfortunately by the time you let me know so I can't get a key to test.
@Vestibule22 We use a 2247 on our Gateway HAT for Raspberry Pi, no modifications except changing the reset pin was neccesary. The LoRa part seems to work as my concentrator's lights turn on correctly for RX and the log seems correct.
Edit: it wouldn't be hard for me to push a fix to make it so the reset pin is easily changed with a variable. However helium start issuing more keys then it wouldn't really matter.
That is correct the alpha program is over now but I already have mine mining with a 2245. I bought a 2287 to change out the 2245 as it was mentioned that the 2287 was built by the helium team. So there was a chance it would operate better than the 2245 that @just4give used in this repo. Now we are working on what can be done to add the 2287 to the Balena set up that he used for the 2245. There will be no additional keys for alpha but I am already running an active DIY hotspot with an alpha code but I cant just put the 2287 on top with this repo sadly. So trying to figure out what can be done.
Ahh sorry my mistake, I didn't see it was the 2287.
From my memory the 2287 does require significant changes as it's using the SX1302 IC instead.
Yea exactly that is what we noticed skimming through documents that utilize the 2287. But @shawaj thought there could be a way to use the environment variables. That way it would allow for multiple types of LoRa setups. Of course this is really for anyone looking to upgrade an already existing alpha code diy hotspot. Unless a Beta Program happens.
Yeah i'm not fully sure regarding that, from the best I knew a different packetforwarder was being used for the SX1302 but I might be wrong. I'd predict for the two different chips that two different repos could be an easier route. Then an envrionment variable to support different gateways reset pins.
@ryanteck this one allows the 2245 or 2287 https://github.com/balenalabs/basicstation/
That was my suggestion as well. Mainly due to the amount of changes that were needed for the 2287. When I spoke to a few people from Helium they mentioned the 2287 was the one they helped build for Helium specifically. So I wanted to upgrade to that one in hopes it helps my hotspot. The thought was using a different repo for the gateways themselves, leaving the miner the same across the board since there is no adjustments to that specifically. From there, anyone wanting to upgrade could just copy the specific gateway repo to their existing setup.
@Vestibule22 is there plans to allow more devices onto the network as miners?
There is a HIP I believe that is discussing the possibility of a Beta Program but is still being discussed
https://github.com/helium/HIP/issues/87 This is the HIP currently being discussed about giving additional onboarding codes
Ah nice. There is also this one which is relevant for production ones instead of DIY https://github.com/helium/HIP/pull/86
Yea here is also the blob of the discussion with more details in it as well. https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md There discussions about this so it could still happen. So of course when that does happen, many might want to use a 2287 or like myself, upgrade the LoRa setup to maximize our efficiency. There could also be new tech that comes out over time that further increases this as well.
@ryanteck would the Security pHAT work on the Nebra Smart Gateway? Could be a nice way to store swarm keys in a secure element...
Yea here is also the blob of the discussion with more details in it as well. https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md There discussions about this so it could still happen. So of course when that does happen, many might want to use a 2287 or like myself, upgrade the LoRa setup to maximize our efficiency. There could also be new tech that comes out over time that further increases this as well.
I'd be interested in the actual difference, the main benefit of the SX1302 is the power. I notice that RAK say receiving power is the same but transmission is slightly more powerful but then in the smallprint that for local regulations it'll likely be run at the same power if not lower. So realistically there might be no benefit.
@ryanteck would the Security pHAT work on the Nebra Smart Gateway? Could be a nice way to store swarm keys in a secure element...
I don't see why it won't if I remember right, however I don't think the keys could be stored with it as they have to be added to the wallet.
The one thing that they also mentioned is the heat that is given off between the 2245 and the 2287. The 2245 puts off a lot of heat while the 2287 stays cool. My guess is this helps keep the pi from throttling due to high heat. Which in turn can cause the hotspot to under perform due to the overheating.
@ryanteck I better chase up that order of 2287 modules for testing 😜
I guess the keys could be passed to the wallet via a request to the TPM. But not sure if that fits in with the current protocol setup. Maybe not. And whilst it doesn't stop physical attacks it would be better than storing keys in plain text on an SD card...IMO
Yea thats fair @shawaj but I do have to say that most people have them in their homes or in locked enclosures. Also we added a web interface in the repo that lets you backup your swarm key. So that may be something to look at down the road but I dont think its a big issue right now. Mainly bc you would still need the alpha code to reassert to a new location if someone took it. Otherwise it wouldnt mine.
Another interesting repo - https://github.com/bottxrnife/helium-2287-w
@Vestibule22 agreed - just was thinking around safety in the HIP and ways to improve it. I was more thinking for in the future when the onboarding codes are auto-generated for example
@shawaj I did notice that one as well but it was a lot of digging to find exactly what they were doing in that one. I wish I could just use one of these repos but if I do, there is a chance I lose the ability to make money from my DIY hotspot
@shawaj Any update on progress on this? I have everything ready for any testing if needed.
@shawaj So I was speaking to a few people on the DIY Discord Channel and they mentioned that I should be able to use a different repo and just build from there. However, they mentioned I would have to backup my swarm key and then restore it on the new setup. Do you happen to know how I can take a file from my computer and put it back onto the Pi through Balena Cloud Terminals? Or would I have to SSH into it?
@Vestibule22 what repo are you using currently for this?
Because that will change where the swarm keys are stored. For example using this repo they are in /var/data/miner/swarm_key
As declared here: https://github.com/just4give/helium-dyi-hotspot-balena-pi4/blob/9551145d69ffb0fa37525fd92fb0e466d3e77108/web/server.js#L20
Reviewing files to handle packet forwarder for 2287. Will need updated Config files and updated Packet Forwarder. Might also need some adjustments to the loragw_spi.native.c but I did not see anything that popped out to me.