@jmarcelino could you tell me the exact steps you followed? I’m struggling with the same exact setup. Newbie here. the .json file is merged into the ttn repo an the account is set on the ttn site itself.
error: The following untracked working tree files would be overwritten by merge:
B827EBFFFE386695.json
Please move or remove them before you can merge.
Aborting
Not sure what to do next.
So far, I’ve cloned the ic880 repo, the start.sh file didn’t have the reset pin reference since it was the master file. I ran " sudo ./install.sh spi " and get that error at the end when i select Yes to use the remote config file. But start.sh now changes to the spi branch, so I can edit the reset pin, which I think was mentioned is 7 for the risinghf adapter?
a bit confused and lost about what I’m doing wrong. any help is appreciated.
Man this worked awesome for me. I bought the RHF0M301 standalone board last year and have been using jumper wires to bodge the thing together. That was annoying, so I went about looking for the RHF4T002 board only to find that they flat out refuse to sell it except as part of the gateway bundle. Finally ran into this post, had the PCB made, and finally got around to assembling it today. Everything works just like it should! Thanks for taking the effort to design this and then share it with us here!
error: The following untracked working tree files would be overwritten by merge:
B827EBFFFEFCDAA2.json
Please move or remove them before you merge.
Aborting
But I have a question, if I use only wifi without ethernet, how do I do when I register my gateway on TTN?
Should I put the Mac address of wlan0 or the one of eth0?? Because when I run : sudo ./install.sh spi
I get : Detected EUI XXXXXXXXXXXXXXXX from eth0 but I don’t use eth0 at all…
You ‘normally’ use the ethernet mac to derive the eUI - even if not using it to connect - unless using a RPi 0w of course! The (RPi) script grabs the network i/f info and uses that to derive the code.
The reality is it basically doesn’t matter what your gateway EUI is, so long as:
Nobody else is using it, which is the benefit of basing it on an allegedly unique-in-the-world network MAC
You use the same one when registering and in all attempts to run the gateway; that’s the challenge of using a network interface on a board that might have more than one network interface…
One good strategy: let the MAC-based derivation run once then hard-code the result in the configuration file. Just don’t clone the card from one gateway to make another, without changing that(!)
The (RPi) script grabs the network i/f info and uses that to derive the code.