Hi all,
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 matching HW and SW implementation. Specifically, the Region settings are unmodified between implementations.
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.
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.
I have traced the SPI traffic on the custom node and the Join Request data to be transmitted by the radio matches exactly what the nucleo demo is sending. And in any case a difference here would not in itself cause a CRC error.
Are there specific settings in the radio CRC calculation that could be the root cause of this difference?
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.
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 matching HW and SW implementation. Specifically, the Region settings are unmodified between implementations.
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.
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.
I have traced the SPI traffic on the custom node and the Join Request data to be transmitted by the radio matches exactly what the nucleo demo is sending. And in any case a difference here would not in itself cause a CRC error.
Are there specific settings in the radio CRC calculation that could be the root cause of this difference?
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.