RAK3172 Semtech Relay port

Hello,

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.

Thank you!

Welcome to RAK forum @BennuEng ,

Moving to LoRa Basic Modem is in the roadmap, not only for RAK3172 but for the whole RUI3 platform.

We understand the need to move to support other features like the relay, Fuota, etc.

However, there is no definite timeline yet I can share at the moment.

I will forward all these info to the R&D team. We really appreciate what you share and these gotchas.

RUI3 is open source now and hopefully we continue this kind of sharing from our users so we can keep up improving our products.

Btw, right now, we have working support on LoRa Basic Modem on our 2.4Ghz LoRa.

Hi @carlrowan,

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.

Thank you for sharing the update @BennuEng !

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.

Again, congrats on the great progress!

Hi @carlrowan,

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.

Best regards,

Ryan

1 Like

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