The RAK2287 is based on the “new” SX1302 chip. This chip is different to the previous SX1301 chip as it has its own unique ID. Depending on the Packet Forwarder being used, the gateway may have an ID based on the Raspberry Pi, the ID extracted from the SX1302 chip or the ID set in the global_conf.json file.
I would start by inspecting the global_conf.json file
This may also give some insight into what’s happening
Hummm if you use the chip ID to register a GW and card later fails and needs replacement - e.g. if it goes deaf after a nearby lightning strike (not close enough to kill whole GW) what happens to that GW registration? Spares and mapping could be a wrinkle… Also in a broader (non TTN as only 8 channels supported) deployment what if you deploy a dual conc 16 channel or duplicated 8 channel GW…what would you use for reg - mixing GW MAC, Chip ID etc could get confusing for large estate management…! (Bit off topic for the thread but new features triggers questions and thoughts… )
Thank you for the responses. To answer the questions asked:
I’ve tried two known-good nodes transmitting into the RAK2287. Neither has had any success.
The gateway ID is shown when I run “sudo gateway-config”:
Yes, I checked legacy forwarder when registering
In terms of the global_conf.json file, I have used the one provided with the kit. I’ve just had a look in there (/opt/ttn-gateway/packet-forwarder/lora_pkt_fwd/global_conf.json) and found that there is a line setting “gateway_ID” to “AA555A0000000000”:
However, in the same directory there is a file called local_conf.json which has this (and only this) in it:
Perhaps the local_conf overwrites the global_conf??
I hope some of what I’ve said has been useful! Thanks for any further help you can offer.
I’ve tried it in /opt/ttn-gateway/packet-forwarder/lora_pkt_fwd/ so far. Hitting tab at the point you suggest doesn’t resolve. If I type the command you’ve suggested in full it says: Unit lora_pkt_fwd.service could not be found.
The problem was that the RAK2287 didn’t have a DNS server configured. The dhcpcd.conf file didn’t have any entries for domain_name_servers so dns requests were going unresolved. I’ve added a line to the dhcpcd.conf file to specify a domain name server and it’s working now.
I don’t have a RAK7244 so you may need to tweak what I say here. The issue for my kit seems to be that the supplied code needs to access a URL but isn’t able to look up the IP address for that URL, because no DNS server is listed in the supplied dhcpcd.conf file. Basically you need to tell the Pi where your DNS server is. You need to add something along the lines of static domain_name_servers=x.x.x.x
to your dhcpcd.conf file, where x.x.x.x is the IP address of a/your DNS server. My dhcpcd.conf file has a section at the bottom saying “don’t edit these lines” so I added it earlier in the file. That seemed to do the job.