Wio E5 Dev Board OTAA JOIN Failed

End Devices (Nodes)
1

Hello,

I am using Seeed’s Wio-E5 board and the STM32 CubeMX firmware. Currently I am having an issue connecting to The Things Stack Industries with my end device. Getting the error message, “###### = JOIN FAILED”

My LoRa GW is working fine, I was able to connect another LoRa-E5 dev board with AT commands.

Hardware:
LoRa GW: The Things Indoor Gateway
Seeed LoRa-E5-Dev-Board (wio-E5)
ST-Link from an STM32 Eval board (SWD for flashing)

Software:
STM32CubeIDE, running LoRa-End Node (Version 1.12)
Github repo here: GitHub - danak6jq/Seeed-LoRa-E5: LoRaWAN end node built from scratch using CubeMX for WLE5x in the LoRa-E5
Using HTerm for my serial connection
Ubuntu Distro

The Things Industry End Node Info:
Frequency Plan: United States 902-928 MHz, FSB 2
LoRaWAN Version: LoRaWan Specification 1.0.4
Regional Parameter Version RP002 Regional Parameters 1.0.1

JoinEUI, DevEUI, AppKey all match the same fields in LoraWAN → App → se-identity.h

My end-device page: https://i.imgur.com/i2ihAbs.png
My LoRaWAN middleware: https://i.imgur.com/905hrJi.png
My LoRaWAN application: https://i.imgur.com/7JhwtNm.png

Thank you for any advice. Also if anyone has any suggestions on how to sniff LoRa packets or troubleshoot with logging that would be appreciated as well.

Current Output from LoRa E5 Dev/End-Node:

APPLICATION_VERSION: V1.3.0<\r>
<\n>MW_LORAWAN_VERSION:  V2.5.0<\r>
<\n>MW_RADIO_VERSION:    V1.3.0<\r>
<\n>L2_SPEC_VERSION:     V1.0.4<\r>
<\n>RP_SPEC_VERSION:     V2-1.0.1<\r>
<\n>###### AppKey:      xxxxxxx:<\r>
<\n>###### NwkKey:      xxxxxx<\r>
<\n>###### AppSKey:     xxxxxxxx<\r>
<\n>###### NwkSKey:     xxxxxxxxx<\r>
<\n>###### DevEUI:      xxxxxxxxxx<\r>
<\n>###### AppEUI:      01:01:01:01:01:01:01:01<\r>
<\n>###### DevAddr:     xxxxxxxxx<\r>
<\n>39s121:TX on freq 902500000 Hz at DR 0<\r>
<\n>54s846:MAC txTimeOut<\r>
<\n><\r>
<\n>###### = JOIN FAILED<\r>
<\n><\r>
<\n>###### = RE-TRYING OTAA JOIN```
2

What are you seeing on the TTIG Console page? How close/distant are node and GW?

Also looking at pictures, please amend your code to respect TTN FUP :wink: Rather than continally knocking at the front door best if you arrange a push button to test mode please…

Have you tried with LWS1.0.3 as a little more relaxed and less pernickety so may prove hw all ok before stepping up to try 1.0.4… ?

3

Hi Jeff, thank you for replying.

When I go to the TTIG console I just see “Gateway connection statistics” and nothing else. The distance between the gateway and node is just about 12 inches.

I can try the LWS 1.0.3 let me do that…

How would I respect the TTN Fair Use Policy? Wondering what specifically needs to be amended or what delay time?

4

Far too close - especially when running with US TX power levels! :wink: Search forum for regular advice on recommended min spacing for debug/safe RSSI values - remember this is a Long Range technology and right now devices shouting in each others ears! Would normally say to get RSSI values into -50 → -110 range (best -60 → -105) for sanity when debugging, but as your are not seeing the device TX in TTIG streams suggests you have bigger problems… separate , reduce TX rate to meet FUP, and then we take it from there…

5

image

Recomend you use
https://avbentem.github.io/airtime-calculator/ttn/us915/7
To assess your testing and planned real world application air times…

6

The extensive documentation - particularly the fundamentals section - has all the details.

7

So I went ahead and separated the gateway further away by 50 feet. I increased the duty cycle to 55 seconds to be within fair use. Still I am not able to see any end-node traffic for this specific gateway.

LoRaWAN Link lawyer is running at v1.0.3 for both the end device and firmware.

Within STM32CubeIDE when I debug I can see that the firmware is looping in a transmit part. I scoped the wio-e5 chip itself a bit and can see that UART and power are working normally. Totally baffled why I cant see anything, even with an 8-channel gateway.

Are there any other configurations that could prevent a signal from being found on a gateway? Would it be worth getting a network analyzer or are there any apps available that could do network analyzing for LoRa?

8

The 50 feet is a number that exists in some realm of “what-ever” - it’s getting the RSSI down to around -70 or even less that counts. What distance do you need to get the RSSI to a reasonable level?

How did you calculate that then? US915 interval of a zero byte payload is 133.4s

There are only 8 & 16 channel gateways, anything less is bound to fail. Please confirm that not only are you adhering to the FUP but that you do not possess or every intend to possess or even every imply the existence of a gateway that has anything less than 8 channels.

No, I use LoRa-E5 both dev board and the module on my own PCBs as a matter of routine - they just tend to work.

There is a metric-x-tonne of missing info here - gateway & device console screen shot would be super useful.

9

Given the minimum size of a transmission with the LoRaWAN header included that is questionable. Very questionable.

Wrong frequency being used. Wrong spreading factor being used. Not transmitting at all because of wrong register setup or not matching the wiring, antenna switch (if present) configured wrongly. Wrong output being used (low power when high power is wired to the antenna or vice versa)
Plenty of things that can go wrong.

For cheap debugging, start with a cheap SDR receiver that is able tune to the right frequency to check if anything at all is being transmitted,

10

If you use LoRa-E5 are you able to do a git clone on the master branch and replicate the results through STM32CubeIDE?

For the LoRa gateway console/logging I am not seeing any end-node traffic at this time.

Here are the functions I am able to see running when I run my debugger on my end: https://i.imgur.com/WpfbbOn.png

11

Hard to say, which master branch of which repro are you using?

I can use CubeMX as well.

Please post screen shots on the forum (just drag them on to the entry box) so we don’t have to check the links before following them. It looks pretty typical but I can’t stress enough that if you use a known good code base and configure the LoRaWAN elements per instructions for the firmware & TTN, it works. It’s a well tried & tested module.

Do you have another of these dev boards just in case the one you are using is faulty?

12

Sure, I can run another board. The github repo I am using can be found here: GitHub - danak6jq/Seeed-LoRa-E5: LoRaWAN end node built from scratch using CubeMX for WLE5x in the LoRa-E5

I am also taking kersing’s advice on the SDR receiver just so I can look into the RF signal. According to the code something should be transmitting, so just need to confirm it exists at the correct RSSI.

Also thank you to everyone that is giving advice, LoRa is cool tech but the community seems small and far between. I am happy I found it though :smiley:

13

That one works for me but as the LW v1.0.4 option caused some angst for a co-develop client as various options & settings were submerged with a variety of assumptions on the use of secure elements etc, I’ve stayed with an older release, the original commit of which I can’t trace off-hand. But I did start out with the original commit when it first came out & it evolved from there.

I never got going with the Seeed repro. There is another repro around for BasicMac but it uses the rather old Semtech / LMIC implementation which petered out a long while back.

Recent threads on here indicate that the STMduino setup works well, but sadly the LMn version is somewhat older as well.

As I arrived at the LoRa-E5 via using the older chip sets, particularly the Murata, I’ve got my own config / preferences / hacks in place.

It’s got a lot of moving parts and the serious code bases are huge, complex and provide for all sorts of corporate requirements. I suspect most people stick to an AT based module with a separate MCU and frankly I can’t blame them - I’ve lost days trying to get something working, but then that was usually something that couldn’t be done with AT commands.

I’d try the original commit from Dana on a fresh board after a good sleep and not make to many changes / assumptions. And once you have something working, back it up ten different ways!

14

So I tried uninstalling the existing STM32CubeIDE I was running and running the same LoRa E5 board.
I’m using STM32CubeIDE Version 1.12.0
CubeMX 6.8.0
LoRaWAN Link = v1.0.3

I did see the below uplink right around the same time I sent a transmission (35 minute mark on my serial monitor and a few seconds later this came on the gateway console at 35 minutes plus 20 seconds). The Dev address is different from what’s showing up on my serial monitor though (00:56:D7:BA) vs. console shows FF 5F B2 B7.

image
image1653×857 117 KB

Wondering if there’s an obvious way to eliminate if this is a nextdoor neighbor sending uplinks or myself unwittingly?

image
image1821×778 139 KB

Looking into the RF tool TTN provides, I can see that received signals shot up dramatically when I left my end-device plugged in over night. I’m pretty sure I’m messing up OTAA/TTN configurations (DevEUI, AppKey, etc.) on my side. I’ll try noting all the details of the device with the AT commands and matching up that way.

– Evidence is pointing to me just flashing over the board without getting all the DevAddr/DevEUI details. Looking at the other board I have with AT commands I can see the default is SF10.

15

Not a thing.

As you’ve not shown the serial monitor output, it’s VERY hard to say. No point giving us the web console but not the serial console, so we can’t tell if the Dev Addr is one initially setup in the firmware. The only item to redact in your first post was the AppKey and the NwkKey for OTAA - the rest are transmitted in plain text as the join request. Knowing the Dev Addr would short circuit this.

As for the Dev Addr, TTI are allocated address starting 26 and 27. 00 is for experimental devices. FF is not valid. So I’d conclude you’ve not joined yet.

But if you have, you managed to send four messages sufficiently fast that you’d best go on the run before the FCC put out an APB as that device is breaching all legal limits.

As your gateway doesn’t appear to be registered on TTN, what instance & tenant id are you using? Is the gateway & application/device on the same instance?

I’m not sure I understand what you mean here. You can set it in CubeMX or directly in the firmware. If you want the original valid Seeed EUI you can read the QR code on the top of the module. Or use one allocated when entering a new device.

The default for what? I’m not clear on what your intent is here. Joins are done at SF10, but ADR will dial it back if the signal quality allows.

16

To clarify, STM32CubeIDE has multiple versions that can affect how the firmware performs. I am running version 1.12.0

Here is my serial monitor output:

serial_monitor

The above serial monitor repeats the same version, OTAA, then TX on freq 9025… Hz every 40 seconds. The gateway console on TTI does not show anything in reaction to this.

Thanks for the tidbit about the TTI addresses, didn’t know that.

I should be more precise – I am on The Things Industries, not TTN. That is my mistake for saying TTN. The end-device and gateway are on the same instance. Specifically a Europe 1 cluster, even though I am in the United States.

I have the device’s EUI from the QR code. I meant the DevAdr and setting the DR parameters, but if firmware takes care of those values there’s no issue.

I didn’t realize SF was that dynamic, I thought you set and forget the SF after programming it. Not that it changes depending on the function it’s performing.

17

Erm, ish, for various values of compiler, it’s more what CubeMX gives you that really affects all the files. I’m not sure there’s much mileage in changing these things whilst we are still lacking in basic information:

Please post text as text and please give us more information - seeing the MW log would be useful as well as the App log - version numbers don’t tell us much about frequencies, timings and responses. Looking back there have been several requests for more detail, the volunteers are only issued with so many pleas for detail each month, so we run the risk of running out of asks.

Have you factored in any potential internet delays? Are all the servers set to EU but with all the settings for radio set to US channels etc?

The Dev Addr is set by the LNS. The DR/SF for join is set by the specifications &/or regional parameters.

Perhaps time to revisit https://www.thethingsnetwork.org/docs/lorawan/ ??

Plus this:

18

It occurs to me that there is a minor chance but one that’s easy to try, that the Join EUI is causing issues somewhere deep in the heart of the stack. We know that all zeros as per the LoRaWAN Alliance docs and the hint on the console causes issues with LMIC. I use authorised EUI’s so I’ve never tried all zeros or any other repeating pattern but we have debugged similar on here on several occasions. So it may be worth a try - start creating a device, grab the generated EUI, cancel / delete and then use that for a Join EUI.

19

I used Wio-E5 to local LoRa communicate with other device.

21

Which would be totally off-topic for the TTI funded LoRaWAN forum.

1 Like