STM32 LoRa Discovery Kit (B-L072Z-LRWAN1) on TTN US 915 Hybrid


I’ve been searching around and digging through the example project files for the STM32 Discovery kit and have been completely unsuccessful in getting the device to connect to TTN here in the US on 915 Hybrid using the End_Node example. The gateway and network sever are all operating correctly as we have serval hundred nodes running w/o issue.

I had no issue getting the device connected on Loriot network just by enabling the ‘REGION_US915_HYBRID’ variable in the project, so I can logically conclude that this is related to the TTN use of SubBand 1 Channels 8-15 (903.9 - 905.3) by default on the gateways running on 915 Hybrid. Loriot defaults to SubBand 0 as do most of the other network servers for the US.


So my question is for those that are familiar with the example code for this kit, how do you configure the project to use by default the same settings of TTN gateways for SubBand 1 Channels 8-15? Has anyone been successful in using this kit in the US on TTN? I have seen the Arduino libraries for this board, but for the time being I am trying to stick the I-CUBE LRWAN project files and libraries.

Lastly, I am not an experienced hardware engineer but I am happy to learn so if there are resources that better document and explain the use of the SubBands for the SX1276 for developers please feel free to link to those resource. Thanks in advance!

1 Like

I’ve not been able to get it to do anything useful either… So i’m gonna follow this thread and hope someone even smarter can help us.

I just built up the hardware based on this write-up using US 915 Hybrid, and I am not able to get joins.
(I actually get eight pairs of join request/join accepted in TTN Console, but the terminal to the board reports join failure)
Hope I am overlooking something obvious here.

Waiting for Provision ready…
0000: Contiki>
Starting Intelligent Asset Tracker for LoRaWAN version 1

Trial start: 19
Press button to trigger position reading.
Looking for accelerometer…
LSM6DSL not present.
Starting LoRaWAN stack… wait for join complete
LoRa stack init
SXX1272 radio version: 22
Set ADR ON: 0
Set public network: 0
Device join method=OTAA
DevEui: XXX
AppEui: XXX
AppKey: XXX
Send JOIN request… 0
Device state: SLEEP
Device JOIN failed

The Arduino Code over here is using the same LoRaMac-node as a basis as the I-CUBE-LRWAN code from ST, but with a lot of fixes. Perhaps you can simply transfer the fixes.

First off US915_HYBRID is a bad idea, as it’s using the first 16 channels (not 8). And it’s fixed to use the first 16 channels. So kind of useless. There is no way for a regular gateway to send the channel mask during the JOIN_ACCEPT, so with a good probability about half of your packets get lost.

You’d really want to setup the channels masks before you attempt the join. The code in LoRaWANClass::setSubBand shows how to do that.

Not sure whether this is all you need to do though. Had a miserable time getting all the kinks sorted out with this code to make it really work well.

@GrumpyOldPizza first off, thank you for taking the time to respond and for the open source work you have done with the Arduino libraries and developer kits. Your response and my review of the linked files answers a ton of questions, so thank you. It also raises a bunch more! However, I will take another pass at modifying the region files with the fixers you provided. My only follow up question at this time is that the LoRa Mac region files you linked to do not include a US 915 Hybrid but rather refer to just US 915. Is this semantics? Meaning, you are using the US 915 source to create the sub band information for an 8 channel hybrid environment? Thanks again.

Yes, I ditched US915_HYBRID. Mainly because it’s 16 channels, and hardcoded to channels 0-15(. Not sure this is useful for any practical purpose.

What you want is US915 with only a block of 8 channels enabled. And for that you simply need to hack up the RegionUS915.c code so that the proper ChannelsDefaultMask is restored (or whatever the name was) instead of the hardcoded values, and then you need to set the current channels mask and the default channels mask to your subband (before you join). The rest of the code changes in RegionUS915.c are structural, or sneaky optimizations (like the code in RegionUS915NextChannel()), which you don’t really need to get going.

Hi guys,
I am totally new to both STM32 LoRa Discovery Kit (B-L072Z-LRWAN1)
I have programed the node and it is running. I can view the message using Tera Term terminal.
I have also opened the LinkLabs gateway using the same terminal.

I can’t figure out how to see the STM32 device’s message on the gateway.
Can anyone help?


really… you mean in the TTN console ?

no. on my linklabs gateway first then to the ttn console

I would like to sniff the packets from the STM32L0 board using the linklas gateway

I have registered a Kerlink IoT Station gateway on ttn but my status shows “not connected”. Any help?

No I’m sorry… no clue
Was it visible/connected before or never ?

never connected bebore

but this is way off topic in this thread :sunglasses:

thanks. I followed the instruction and done with that but on the ttn console, my status is “not connected”

EU handler ?

yes 868

May I ask which gateway are you using?

We are using RPI3 + iC880A-SPI concentrator but as soon as the GW has two nodes sending data relatively fast (around every 500 ms) the gateway only receives messages from one node as if it is unable to receive from two simultaneously. SFs are different so that can’t be a problem.

I’m working with last STM32CubeExpansion_LRWAN_V1.3.0 and TheThingsNetwork can’t recognize Join requests. I have tryed an old example of a STM32 Workshop (see link below) and AT_Slave example is completly working.
I have tried with V1.2.x and it doesn’t work either. Something happens with the new loramac stack.

See the MOOC lab archive:

It would be helpful if you could explain if the join requests are being received by a gateway or not.

If they are, providing their details - raw packet payload as base64 or hex - would be very helpful. This is not private information, as it is exactly what goes over the air and could be received by anyone else with an antenna.

Finally are you seeing the join requests in the TTN console at all?