We are working on porting the v1.0.4 lorawan stack implementation with support for Relay’s (GitHub - Lora-net/SWL2001 at feature/relay) onto the STM32WL platform, specifically for the RAK3172 module.
I understand that this Semtech port might be out of scope for the RAK forum, but I figured this might provide a good insight on the RAK3172 hardware or any gotcha’s we’re missing, along with providing some insight for future Relay porter’s.
We have successfully tested a relay Tx and relay RX proof of concept with the Nucleo-L476rg + sx1262mb2cas development kit with the help from the TTN team.
We have also ported the Semtech stack to the Nucleo-WL55JC development board that uses the STM32WL55JC (has an embedded sx1262). This works on the desktop so far.
We are in the process of porting the stack to the RAK3172. The difference between this unit and the Nucleo development board is that is does not have a TCXO just a crystal, and it only has the HP antenna port connected. So no LP RF switch. We have configured the Semtech stack with the correct crystal tuning registers, and hardware configuration (RF switch, etc.) that works on this board with the STM Lora stack.
Here is a summary of the issue we’re seeing:
The RAK3172 will take multiple join attempts to connect to the network (TTN). After it has joined the network will no longer receive any uplinks.
Uplinks are being sent from the RAK3172, but the gateway or network is not seeing them.
In comparison the STM32Wl Nucleo development kit will join in the first couple of requests, and all uplinks will be received.
We have ordered in the TCXO version of the RAK3172 to test this week and will post the results here in this is the issue.
Our current theory:
The lack of a TCXO is causing issues with the channel frequencies along with the use of the high power output. Have see other posts where the sx1262 has a heating issue skewing the channel frequencies. However, this same hardware works without issue with the STM Lora stack, so there must be a configuration issue with the Semtech stack if this is the issue.
Only having the HP RF port and no LP port is not correctly handled in the stack. At the top level this seems as simple as configuring the GPIO for the RF switch for Tx and Rx mode and setting the RF configuration register to use the HP port. However, perhaps under the hood the Semtech stack expects a LP RF port to be available on the hardware.
Could this be a mismatch on the MAC commands coming back to configure the node after joining or with ADR? It seems that because we have such an issue joining in the first place the frequencies or packet must be off from the start.
We have seen a note from Deviceroy where there are issues with the join process in the US where the payload is too large for DR0. " Any surprises in the code?
Yes, it’s a first version built on a very intelligent but theoretical tech specification. Some things can only be discovered by trying to build one. One of the surprises was the Join process in the US. The payload is inherently too large for the Join sequence in DR0. We are told that this is being addressed by Semtech and the LoRa Alliance. Our experience with Semtech is that they take these things seriously and work quickly to provide a quality resolution. In the meantime, we’ve implemented a couple of workarounds like starting with DR4 (in USA) and lingering on-air for a few minutes for ADR to take over and improve the data rate. Other regions don’t appear to be affected by this issue." Could this be a related issue? We’re not sure how to configure the system to achieve this, and might have to reach out to DeviceRoy to see what they did.
Any insight in using and porting the new Relay stack with the RAK3172 and these types of gotchas would be very helpful. I have not found any resources yet on another team porting the Semtech stack to the RAK3172.
We have some updates here in our testing. We now have the RAK3172-TCXO version up and running with the Semtech Relay stack. It seems that the join and uplink issues were from the combination of using the Semtech stack with a standard crystal (vs the TCXO). There are differences in the configuration to be able to use the crystal that we were either not porting correctly, or the Semtech stack wasn’t handling correctly.
For now the simple solution is to use the TCXO version.
When it comes to relay, you and your team is ahead of us. We are glad that RAK3172-T works well.
Btw, do you plan to share your port to public (as open source project) or it is internal and for your own business case? As for relay device, we do not have that offering yet but if we got customer inquiry, we can direct them to you. Or if the port using RAK3172-T is open source, we can direct interested users to it. Also at the same time, we can study your port and maybe implement them in the future too in RUI3 LoRa Basic Modem.
For now the relay port project is for a customer so we can’t release it publicly. However, we’re certainly open to help out any teams having issues with the setup and they can feel free to reach out directly.
Hi @BennuEng,
I’ve been looking into porting the relay enabled Semtech LBM for the Nucleo-WL55JC. Was wondering if you could share any insights in how you performed this?
Any tips would be much appreciated.
Best regards
Even
Hi @Hopeless,
Thank you for the message. There are quite a few small details we had to work through for the port to get it to work reliably. I’ll send you a private message and we can setup a call if helpful.
We found the Semtech stack in comparison to the RAK/STM stack extremely sensitive to timing (application service timing, interrupts, clocks, servicing too fast, servicing too slow, etc) here are a few areas we had to work through:
Must use a TCXO with the chip.
For reliability the verbose terminal logs over UART had to be disabled as they effect timing. This was more apparent on the Relay Rx node.
We had to remap the way interrupts work to the radio. The Semtech stack expects GPIO interrupts, where the STM32 uses it’s own internal interrupt for the radio. The clearing of the radio status inside of the interrupt won’t work, so you need to set a flag and read/clear the interrupt status after the interrupt.
We could not service our application, and the radio stack at the same time as the radio interrupts/timing must always take priority. We found it easier to hold off on any heavy application processing/interrupts until the radio transmission event was complete. So if you’re having uplink/downlink/join issues try to only run the radio and no other interrupts/application code to see if its a priority/timing issue.
We did not try to get FUTOA working, it requires a fair amount of flash memory, so we disabled this in our implementation. In all cases the flash mapping will have to be updated in the Semtech stack as it requires writing directly to flash for non-volatile data (Lorawan dev-nonces, etc).
The TCXO timing will have to be adjusted for your application as the TCXO requires a power up time for stability.
The TXCO voltage will have to be adjusted for your application.
We had issues with the RNG peripheral working reliably, there are some issues with this unit faulting on the STM32s so we ended up using a software RAND.
In the STM32/RAK stack we had hardset the data rate to DR1 (larger packet size). This did not work in the Semtech stack reliably, we had to support DR0 and DR1 packet sizes to allow joining and the ADR to work correctly.
I’m working on an interesting project where we’re porting the LoRaWAN v1.0.4 stack with relay support from Semtech’s GitHub (feature/relay branch) onto the STM32WL platform, particularly targeting the RAK3172 module. We’ve successfully validated our relay Tx and Rx proof of concept using the Nucleo-L476RG and SX1262MB2CAS development kit, and have also managed to port the stack to a Nucleo-WL55JC board, which uses the STM32WL55JC with an embedded SX1262. Transitioning to the RAK3172 has presented unique challenges.