Hi all,
This may or may not be related to chirpstack, but since i am in the middle of deploying a rather urgent customer project, any help / hints would be deeply appreciated.
My problem is as follows: using ChirpStack to collect data from custom built nodes where the LoRaWAN part is derived from ST LRWAN 1.3.1 codebase, the following happens. Compiling the firmware with Region set to EU868 everything is hunky dory and traffic flows smoothly all the way up to App Server. Joins and uploads are 100% succesfull so apparently everything is in order.
When switching the project (and GW conf) to US915 and recompiling, again a functional application is created. However, this time every join attempt is consistently discarded at the Gateway (IMST packet forwarder) due to CRC error.
What is very curious is, that i can take the original ST demo app, compile it on a nucleo-l476RG with a SX1272MB2xAS shield, and the demo works nicely in both Regions, no CRC errors or at least rarely.
Both nodes have the exact same ST MCU and same Semtech SX1272 radio, with essentially identical HW and SW implementation. Specifically, the Region settings are unmodified between implementations.
So, to recap:
Both nodes work 100% with Region EU868 settings.
Only the original nucleo demo app works with US915 setting. The custom node does transmit and the frequencies look OK as far as the channel allocations are concerned. Also the frequencies do overlap with those the gateway is monitoring. However, every RF packet (Join Request) received at the gateway is discarded due to “CRC ERROR”. This is clearly noted in the GW logs.
file diff comparison shows that the ST HAL drivers and the LoRaWAN middleware are essentially identical between projects. The only difference is that is have moved the devEUI, joinEUI and keys to EEPROM storage where they are #defines in the original demo. But that’s it and those mods clearly work as intended.
I have traced the SPI traffic on the custom node and the Join Request data to be transmitted matches exactly what the nucleo demo is sending. And in any case a difference here would not in itself cause a CRC error.
I don’t expect anyone to pull the answer out of a hat, but any experiences around this topic could be valuable, so if you have insight into the issue, i would be grateful for your comments.
Hmmm, a lot going on there so it’s hard to point in any one direction with confidence.
However, assuming that 1) the Chirpstack builds for both frequencies are ok, and 2) the nodes are behaving as they should (correct libraries, freq bands etc), I see one component not discussed in your question: the gateway.
If it were me, I would check
Is the NW server configured to push down the correct frequency bands for US915?
Can the gateway (packet forwarder?) accept these bands?
Are you using the one gateway to server both regional bands? If so, I imagine this could be a problem?
Finally, it is possible that in your region the US band freq ranges may be being used by other services. It may be very noisy, and hence the data corruption. Try testing this at different times of the day/days of the week.
Thanks for the very relevant suggestions. I did not mention those specifically but did in fact check and most of them are in order. I assume when you write NW server, you mean the Gateway profile in ChirpStack? The GW profile is set for channels 0…7. Since the nucleo app works OK, i assume that cannot be too far off the mark.
You are of course correct in that the US band is occupied with other stuff here and i do see occasional spurious RF packets in the GW log. Fortunately my test site is in a relatively quiet radio environment so interference (in both directions) is quite low.
Actually, the plot thickens, because i have found at least a partial cause for the issue: the custom device uses PA_BOOST as the RF output to antenna, whereas the nucleo uses the regular RFO. Curiously, the output pin selection (a #define in the source code) has been wrong for the custom device all this time, yet the EU region setting has worked flawlessly. That may be due to the close proximity of the GW of course.
After correcting that the CRC error went away and now US915 join requests are correctly received and passed on. I can see from the application live monitor that JoinRequests come in and a JoinAccept is generated and sent down. However, those never appear at the device. Instead i consistently get a RxTimeout even when the channels match according to what each end logs/prints on console.
Again, the nucleo app does work and joins the network with barely a missed packet. So my feeling is that the GW cannot be badly wrong but who knows. The original bug was one that no-one could have logically deduced just from the symptoms.
So, the exercise continues and as before, any suggestions are very welcome.
Additionally to the reply above: i just checked and now there is at least consistency: neither of the nodes is able to see a JoinAccept message even though one is sent for both of them. Don’t know that i changed anything in the nucleo, GW or service, so there is one more mystery to solve
And no, i am not trying to serve both Regions from one GW. I just swap configurations according to what Region i am testing.
snspinn, your suggestion turned out to be spot on; the frequency and/or data rate assignments were incorrect. The error was due to incorrectly naming the profile in network server config as US902_928 (or whatever it was. Anyway something someone suggested on a web forum). Once i changed it to “US915” as i thought it should be, all problems went away.
So thanks for the help and case closed.