I hope you’re all doing well. I’m using the RAK11310 to create a basic node and would like to seek advice on a particular issue I’m encountering.
I’ve been working on my project and used this example code (link) as my foundation. So far, everything is going smoothly, but I have come across a minor inconvenience.
The DevEUI is currently hardcoded into the board, which makes it a bit tedious when deploying multiple boards. I was wondering if there’s a way to obtain the DevEUI of the onboard modem programmatically.
I have an old example for the RAK11310 that implements AT commands to setup LoRa and LoRaWAN without the need to hardcode anything. The code is in RAK11310 BSP repo
2023-05-18 16:14:12 --> ============================
2023-05-18 16:14:12 --> RAK11300 AT Command Firmware
2023-05-18 16:14:12 --> SW Version 1.0.0
2023-05-18 16:14:12 --> LoRa(R) is a registered trademark or service mark of Semtech Corporation or its affiliates.LoRaWAN(R) is a licensed mark.
2023-05-18 16:14:12 --> ============================
2023-05-18 16:14:12 --> LoRaWAN status:
2023-05-18 16:14:12 --> Auto join disabled
2023-05-18 16:14:12 --> OTAA enabled
2023-05-18 16:14:12 --> Dev EUI E660CCC14B624D30
2023-05-18 16:14:12 --> App EUI 304D624BC1CC60E6
2023-05-18 16:14:12 --> App Key E660CCC14B624D30304D624BC1CC60E6
2023-05-18 16:14:12 --> NWS Key E660CCC14B624D30304D624BC1CC60E6
2023-05-18 16:14:12 --> Apps Key E660CCC14B624D30304D624BC1CC60E6
2023-05-18 16:14:12 --> Dev Addr 4634AD7D
2023-05-18 16:14:12 --> Repeat time 120000
2023-05-18 16:14:12 --> ADR disabled
2023-05-18 16:14:12 --> Public Network
2023-05-18 16:14:12 --> Dutycycle disabled
2023-05-18 16:14:12 --> Join trials 5
2023-05-18 16:14:12 --> TX Power 0
2023-05-18 16:14:12 --> DR 3
2023-05-18 16:14:12 --> Class 0
2023-05-18 16:14:12 --> Subband 1
2023-05-18 16:14:12 --> Fport 2
2023-05-18 16:14:12 --> Unconfirmed Message
2023-05-18 16:14:12 --> Region 0
2023-05-18 16:14:12 --> Network not joined
2023-05-18 16:14:12 --> ============================
2023-05-18 16:15:38 --> AT?
2023-05-18 16:15:38 --> AT?
2023-05-18 16:15:38 -->
2023-05-18 16:15:38 --> +++++++++++++++
2023-05-18 16:15:38 --> AT command list
2023-05-18 16:15:38 --> +++++++++++++++
2023-05-18 16:15:38 --> AT?..AT commands
2023-05-18 16:15:38 --> ATR..Restore default
2023-05-18 16:15:38 --> ATZ..Trig a MCU reset
2023-05-18 16:15:38 --> AT+APPEUI..Get or set the application EUI
2023-05-18 16:15:38 --> AT+APPKEY.Get or set the application key
2023-05-18 16:15:38 --> AT+DEVEUI.Get or set the device EUI
2023-05-18 16:15:38 --> AT+APPSKEY.Get or set the application session key
2023-05-18 16:15:38 --> AT+NWKSKEY.Get or Set the network session key
2023-05-18 16:15:38 --> AT+DEVADDR.Get or set the device address
2023-05-18 16:15:38 --> AT+CFM.Get or set the confirm mode
2023-05-18 16:15:38 --> AT+JOIN.Join network
2023-05-18 16:15:38 --> AT+NJS.Get the join status
2023-05-18 16:15:38 --> AT+NJM.Get or set the network join mode
2023-05-18 16:15:38 --> AT+SENDFREQ.Get or Set the automatic send time
2023-05-18 16:15:38 --> AT+SEND.Send data
2023-05-18 16:15:38 --> AT+ADR.Get or set the adaptive data rate setting
2023-05-18 16:15:38 --> AT+CLASS.Get or set the device class
2023-05-18 16:15:38 --> AT+DR.Get or Set the Tx DataRate=[0..7]
2023-05-18 16:15:38 --> AT+TXP.Get or set the transmit power
2023-05-18 16:15:38 --> AT+BAND.Get and Set number corresponding to active regions
2023-05-18 16:15:38 --> AT+MASK.Get and Set channels mask
2023-05-18 16:15:38 --> AT+BAT.Get battery level
2023-05-18 16:15:38 --> AT+RSSI.Last RX packet RSSI
2023-05-18 16:15:38 --> AT+SNR.Last RX packet SNR
2023-05-18 16:15:38 --> AT+VER.Get SW version
2023-05-18 16:15:38 --> AT+STATUS.Show LoRaWAN status
Reading through how these examples work, it seems that the DevEUI is being generated as a function of the Pico’s device ID rather than being built into the modem. Have these DevEUI’s been assigned to some block, or should we be managing that ourselves?
Additionally, the DevEUI that AT-Command.ino spits out is different to the one printed on the label of the RAK11300. The label is also identical between the 2 chips we have, whereas they should be unique. Can the values on the label just be ignored?
As default, if there is no DevEUI saved in the flash, it generates one from the device ID.
Once you setup the DevEUI over AT command it will save this EUI in the flash and use it in the future.
Every WisBlock Core has a unique DevEUI on its label. I am using this to set it once with AT command.
Unless you do a flash erase, this DevEUI will survive firmware updates or firmware changes.
Can you send me a picture of the two devices with “identical” labels? That should never happen.
