I’d suggest you put some debug print statements in to see at what point the EUI’s change in the flow of code.
1 Like
i was desperately looking for the solution on using a RPi4-5 with the Raspberry Pi HAT with the SX1262 radio module which have been promoted by waveshare as a LoRaWAN complaint, but can’t find any library implementing LoRaWAN protocol for RPi board, just a LoRa and waveshare is not helping my anyhow. I have a LoRaWAN iKerlink gateway and a TTN account, and used a RAK4630 module (i belive it has the same chip, so i’m pretty sure the radio module is lorawan comliant) to send messages and some other industrial sensors. i do some calculation and measurement using a RPi and would like to send the data from time to time directly from it to TTN. is there any chance you can help me to find out how i can use them together?
TL::DR Get a LoRaWAN module that can be controlled overt UART to use with a Raspberry Pi.
The SX1262 is a LoRa RF Tranceiver. Think of it as the device that handles the RF Phy layer capturing or creating the RF signals and passing them on to a controlling MCU.
LoRaWAN - as you note - is a protocol (amongst other things at the higher system level) - that runs over LoRa (and potentially FSK) modulation as the carrier. The LoRaWAN protocol - at the node level - is implemented as a software stack (e.g. LMIC, LoRaMAC_Node or what ever), which then runs on a MCU - often the same one used to manage the SX1262 Xcr. You can buy LoRa Radio modules - these do not run LoRaWAN themelves - or you can buy LoRaWAN modules - these integrate the LoRa Xcr & and MCU running a suitable LoRaWAN stack. (GIYF as is TTN Forum!) Often these are controlled over a UART interface vs the direct SPI i/f used for running the SX12xx radio and often implement an ‘AT’ like command structure making the interface and control ‘simple’ and abstracted from the managing sensor system.
As you will no doubt have read across the forum (search) the LoRaWAN stack has some quite exacting (and deterministic) requirements wrt timing of operation if it is to run reliably. Therefore the general rule is to run the Stack on a seperate controller or ensure that if running any local management or application code that it is set to a lower priority and to ensure it will not interfere with the correct functional operation of the LoRaWAN stack. For that reason we dont run LoRaWAN Stacks on general purpose PC type systems or Linux like implementations where there is no way of absolutely controlling the processor’s operation and ensuring that any multitasking activities even just OS housekeeping fn’s let alone application/user code or interupts from interfering with the precise operation of the LoRaWAN Stack. RPi’s - whilst great for running the Packet Forwarder and other supporting functions of a LoRaWAN Gateway - are generally considered unsuitable for implementing a LoRa Node directly. Whilst great for running complex sensor system and implementing local/edge data processing and ‘intelligence’ that allow data reduction to sending a simple ‘alarm’ like data message over LoRa or LoRaWAN, they shouldnt be generally used as the LoRaWAN controller but rather should be complimented by a seperate LoRaWAN modem, that takes care of this critical functionality.
You do not provide a link to the Waveshare product you have to hand but assuming it is this one
Documented here
You will note it is clearly called out as a LoRa HAT NOT a LoRaWAN HAT, and indeed in the device introduction it states:
“This product uses a private protocol and does not support LoRaWAN.”
Why? That’s both why are you looking for a solution with a Pi as the main MCU with all the perils detailed above and why have you reached desperation point?
The HAT that is linked to above has some interesting commentary about the difference between chip sets that is amoungst the purist 
I’ve seen for a while, only rivalled by the @ebyteiot who probably fed them the info.
The OTHER board, https://www.waveshare.com/sx1262-lorawan-hat.htm, is just the radio. If you compile the RPi to use a real-time kernel and/or strip out as many processes as possible you may well end up with a reasonably reliable device. Finding a LW stack that runs on the Pi that can drive an SX1262 is a matter of using Google. But it still begs the question, why?
Not sure quite how rude I think such a move is, but it appears we’ve been spurned by @lpwan23, possibly for asking relevant questions stemming from us knowing what we are doing, and the discussion has moved over to RadioLib.
Which is ironic, as the primary maintainer & his testing sidekick are on here, along with grown ups that know stuff, thereby giving access to a wider body of knowledge. 
Closing this now that we are in the weeds over on GitHub: Help with LoRaWAN implementation on Raspberry Pi 5 with the Waveshare SX1262 HAT · jgromes/RadioLib · Discussion #1187 · GitHub
I’m not active there but where he says (his last post at time of reading):-
“i use the raspberry pi to collect some data out from the sensors and do some calculation and was looking to be able to send the data from time to time from Raspberry Pi directly to LoRaWAN network.”
Please tell him:
Some folk just wont take advice 
If he has a problem with the Waveshare ‘HAT’ then tell him “return it or get them to provide a suitable library and implementation that is assured to work, meet timing and wont screw the netwok for the rest of us!” What he is doing is common and not unusual - do it myself - he’s just going about it in a poor and unsupported way…
Closing.
She, as it happens, has been prompted to pony up more info that wasn’t replied to here. As they say up this end, “you can’t teach pudding”.