Payload problems with OTAA only

Hey everyone,

So I have a weird thing going on…
I use the I-CUBE-LRWAN1 v1.2 in combination with the STM32: B-L072Z-LRWAN1 develop board.

When I register this device under ABP and enter all the keys etc… I have no problem and all my payload comes in.
However, when I register the device under OTAA, and enter all the keys etc… the device gets actived and receive a JOINED message. But after that the payload is not received by the things network.

The keys I enter are:
LORAWAN_DEVICE_EUI <- Device EUI
LORAWAN_JOIN_EUI <- Application EUI
LORAWAN_APP_KEY <- APP key
LORAWAN_NWK_KEY <- APP key

I set
OTAA = 1 ;
public network = true;
static device eui =1;
LORAWAN_APP_PORT = 2;
LORAWAN_DEFAULT_CLASS = class A
LORAWAN_APP_DATA_BUFF_SIZE = 64
LORAWAN_DEFAULT_CONFIRM_MSG_STAT = LORAWAN_UNCONFIRMED_MSG
APP_TX_DUTYCYCLE = 10000

When I scan my UART, every time the device sends a package in ABP it arrives, but in OTAA I can only join but when the device sends payload nothing happens in the things network console.

Anyone has experienced something like this?

P.S. in the past I never had this problem with OTAA with Things Network.

Thanks in advance…

OK what the hell is this…

I am struggeling 4 hours with this, at one point I am like, ok you know what… I just make a post on the forum… and 5 minutes later 23 payload packages comes in…

payload

like how is this possible…

msg
Look… only the 6th payload message comes through…

It even counts 6 frames…

I’m unsure if you still have a question, but once joined, an ABP node behaves the same as an OTAA node. Once joined, there is really no difference in the packets it sends; see also OTAA then ABP - #5 by arjanvanb.

Any chance you’re using a single-channel test gateway?

So thats the weird thing… everytime my node sends a package in ABP, the package is nicely displayed in the console.

However with OTAA, for example, sometimes for 1 hour or so no packages comes in, and then all of a sudden 20 packages. To sum it up, it show payload randomly in the console, however the frame count is accurate.

So I see in the UART that the node sends 10x a message, and the 11th message is displayed in the TTN console with a counter 11.

I use the Things gateway.

My best guess would be that it’s all a coincidence, and not really related to ABP versus OTAA. (Like: on a few occasions the MQTT latency was quite high; Getting “LORA: TXPKT failed, too late!” in TTN Gateway’s serial output .)

To rule out it’s just a hiccup of only TTN Console, I’d try MQTT to see if that shows the same issue.

Thanks for the Feedback.

Will keep you posted if I find out something interesting.

I’ve been told that some people have issues with version 1.2.0 of the STM cube implementations. I have similar issues where it takes some time before it starts sending actual messages.

I haven’t tried it myself, but apparently earlier versions 1.1 seem to work. It’s something you could try.

I’ve had similar issues using the ST LoRAWAN Discovery board with TTN. Typically I’ll see the join via serial and then TTN misses the first [insert random # here] payloads. Not sure what region your using but switching to US_915 helped me a bit (was previously using hybrid) but it still fails to display all of the payloads.
I never found an actual solution as I’ve been developing on Comcast’s network server since then.

Just to add to the confusion, in the following case, I think all data is actually received nicely, but the problem is about seeing the packets in TTN Console:

Well I have the same issue in the developer area of Dutch network provider KPN.

No clue whats going on, is it maybe typical that not al the TX messages are accepted by the provider?

ok… maybe this is just a simple:

https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html

thingy now…

But it was different last week Thursday, guess the TTN had a bad day or something.