I recently purchased RAK2287 boards (SPI variant), with Raspberry Pi adapters, running on Raspberry Pi 4 carriers. I have followed the instructions to install/run Chirpstack according to the Quick Start Guide. From what I can see, the software stack is starting successfully, but I am not receiving packets on the concentrator from a custom LoRaWAN node (the same packets are visible on a nearby RAK7249 gateway).
I have snooped the MQTT packets (mosquitto_sub -t ‘#’), and run lora_pkt_fwd (through ‘start.sh’ script) on the command line. I never see any indication of received packets in either of these places. The lora_pkt_fwd seems to be configured to forward only packets with valid CRCs (I have confirmed on the RAK7249 that the CRCs on the node’s packets are valid).
What do you see? Hopefully you see that the process continues running (make sure you don’t have another copy started by a daemon!), periodic stats messages including acks from the server (in this case the gateway bridge), and ideally some received messages - at least if you keep watching through the time when your other gateway confirms a node has transmitted.
Where did you get your global_conf.json? Do the startup messages for the packet forwarder show EU868 frequencies?
Have you set the sync word preamble to the same of public or private network on both nodes and gateways?
What sorts of signal RSSI are you seeing for the nodes on the other gateway?
Thanks for your response. I changed two things according to your advice, and I can now see that the lora_pkt_fwd is receiving the RF packets.
I changed the name of the start.sh script that launches lora_pkt_fwd to stop whatever is relaunching it from relaunching it as soon as I kill it. I could then be sure that my instance of lora_pkt_fwd was the only one running.
I changed the global.conf (that came with the RAK image) to declare the network private (it was public), to match the setting in my end node. This seems to have resolved the problem - I can now see that the lora_pkt_fwd is finally recognising the end node’s packets (observing the periodic status output that shows how many packets have been received). When I set this back to public, the lora_pkt_fwd no longer receives the packets.
How does the private/public relate to the sync word/preamble? Is it the radio or the LoRa Packet Forwarder that is filtering the public/private? I would ideally like to see all LoRa packets (public and private).
Its done in the concentrator chip hardware, and I don’t think there’s any formal way to get both. It’s possible there might be an undocumented except for mention in a register map setting which could allow looser matching (I see the occasional mismatched packet leak through already), but you don’t want to waste decoder instances chasing noise that isn’t any sort of LoRa packet at all, either.
Basically the hardware is designed to support a network, not a band survey. In fact the concentrator chip can’t measure channel activity energy the way a node radio can.