Closed simeonyetarian closed 2 years ago
I have been having the same issues, using US915 settings. I will post screenshots when I have time.
This issue only happens when compling on a Raspberry Pi 4. When I compile the uf2 on a Mac, the expected EUI values are transmitted.
simeonyetarian, which platform are you using to compile?
@tnakasaki Thanks for sharing that information! Indeed, I am compiling on a Raspberry Pi 4. Maybe I will try to compile on another device then
Update: I can confirm that compiling on a Windows machine instead of a Raspberry Pi works. So this seems to be specific to the Raspberry Pi
Here are some screenshots that illustrate the aforementioned issue. cmake and make were performed on a Raspberry Pi 4.
config.h
cmake output (configuring for Adafruit's Feather RP2040 board)
Partial make output
TTN gateway data. Note the incorrect values for both JoinEUI and DevEUI, 618A011029890110
Also, in config.h, if LORAWAN_DEVICE_EUI is set to NULL, a correct DevEUI will be transmitted. That is, the same value printed in the default_dev_eui example program. JoinEUI remains incorrect.
These are screenshots of cmake and make performed on a Mac. This compilation produced an executable that functioned correctly.
cmake
make
@simeonyetarian @tnakasaki Looks like it might be related to the version on Arm GCC used.
Based on the screenshots @tnakasaki provided in https://github.com/ArmDeveloperEcosystem/lorawan-library-for-pico/issues/8#issuecomment-889052952, they were using 7.3.1
or 8.3.0
on the Raspberry Pi, but using 9.2.1
on the Mac.
Any chance you could try to use a newer compiler version on the Raspberry Pi?
@simeonyetarian could you please provide the compiler versions you were using Raspberry Pi vs Windows? Thanks.
Hi @simeonyetarian, @tnakasaki,
I've prepared pull request https://github.com/ArmDeveloperEcosystem/lorawan-library-for-pico/pull/12 to resolve this. It would be great if you could try out the change and provide any feedback.
I was facing the same issue with GCC 11.2.1 on Fedora Linux (x86). The PR seems to solve it. With debug mode enabled, the correct DevEui and JoinEui are shown.
Joining the network is not yet working, but that is probably another issue ... ;-)
@ThomasLeister thanks for the feedback on PR #12! I've gone ahead an merged it.
Hi @simeonyetarian, @tnakasaki,
I've prepared pull request #12 to resolve this. It would be great if you could try out the change and provide any feedback.
Sorry for the late response, I've compiled on the Raspberry Pi 4, using the same setup as above. JoinEUI and DevEUI transmit correctly. Thank you so much for your solution!
I've entered my Device EUI, Join EUI and App Key in config.h of the otaa_temperatur_led example but the data that the gateway receives contains a different Device EUI and Join EUI (which are both the same for some reason).
My config.h file:
Minicom output of the Raspberry Pico with RFM95W: (This already shows the wrong Device EUI and Join EUI)
Live data from the gateway with the wrong Device EUI and Join EUI:
I am using The Things Network V3 with EU868 configuration. I've also tried to change LoraWAN MAC version and Regional parameters version in the TTN console, but this has no impact since the minicom output of the pico already shows the wrong Device EUI and Join EUI.
Is there anything I can do to fix this?