LoRaWAN simulation issues

[dpergarc]

Hi there!

@cslorabox

No, you need to mask to a 32 bit value. That is not an operation which has any direct equivalence in decimal, but it is rather elementary computer programming.

Copy, understood!

@cslorabox

I’m sorry to say that your approach to all of this is a bit haphazard - if you want to end up with a result that has any real meaning, you’re going to need to first take time to better understand how such a network works.

I am aware that a real situation means to follow the LoRaWAN rules, but I insist, it is a simulation sending data through UDP to a TTN stack launched on my computer, so do not worry, I am not breaking the rules (and of course, I am not pretending to do so).

Once this issue has been solved, I will keep working on uplink procedure, that it is the next step, thank you very much for all your support! All of your suggestions have been so helpful!

Kind regards.
Daniel

[cslorabox]

@dpergarc

I am aware that a real situation means to follow the LoRaWAN rules, but I insist, it is a simulation sending data through UDP to a TTN stack launched on my computer, so do not worry, I am not breaking the rules (and of course, I am not pretending to do so).

You really, really missed the point of what you were responding to.

It doesn’t sound like your simulation is modeling the actual behavior of a network.

As a result, your results will be meaningless at best, but it may be far worse if you actually believe or represent them to others as having any sort of meaning.

[dpergarc]

Hi there!

I will try to summarize as much as possible the problem I have. I am developing an application to simulate some LoRaWAN devices, and I need to comunicate them to the TTN platform, using the TTN stack with dockers. Even though both the “stat” and the “join-accept” procedures seems to be all right (the second one thanks to you guys), when I try the “uplink”, a mistake is given from the gateway (I am using the Semtech UDP Packet Forwarder communication). Moreover, the documentation followed in the one regarded to the LoRaWAN v1.0.3.

Let’s see the mistake on the gateway side:

It might be not very relevant, but it is also included a picture of the device side:

In case it may help, I am including the JSON returned by that error:
error.json (1013 Bytes)

More clues:
In order to corroborate that the “join-accept” is working well (or that is what it seems), it can be checked by the print done in my program:
devAddr -> B4634D01
nwkSKey -> 1910482B5841434E6A4FEF4D8999741A
appSKey -> 5E968317B4A01D19C80CDBA349F0732A

By this, has anyone had this kind of mistake? If true, what could it be and how it can be solved? If not, what is the best way to find out what is going on?

Thanks beforehand, looking forward to hearing from you soon.

Kind regards.
Daniel.

[cslorabox]

You have an endian mixup error in your simulated node: notice how when the network is issuing the join accept the bytes of the device address are in the opposite order from what is received in the attempted uplink.

Given that device addresses are not globally unique, you could also potentially get a device not found issue if the MIC of the message does not match due to network session key issues, as it’s getting a matching MIC which validates that the traffic is from the correct instance of the non-unique device address.

But it’s definitely going to be not found when you reverse the byte order of the device address itself as you have in this attempt, so fix that first.

[dpergarc]

Hi there!

First of all, I am truly sorry for creating a new topic for this new issue, I really thought that they could be treated as separated discussions.

Regarding to the current issue:

@cslorabox

But it’s definitely going to be not found when you reverse the byte order of the device address itself as you have in this attempt, so fix that first.

Fixed! My bad! Now the only variables that are lsb are appEUI and devEUI… but I am afraid the same error is given , take a look to the following pictures:

• Gateway:
  

  

• Device:
  

  

Regarding to this, is there something I am missing? Do I have to revise all the LoRaWAN packet? That is to say, these elements:
MHDR | DevAddr | FCtrl | FCnt | FOpts | FPort | FRM Payload | MIC

I will try this sending to the TTN console V2, just in case I could have more clues.

Thanks beforehand, looking forward to hearing from you soon.

Kind regards.
Daniel.

[cslorabox]

See if your traffic validates in the online lorawan packet decoder.

You’ve set yourself a huge project here where re-implementing LoRaWAN from scratch is being treated as a trivially implicit part, rather than the large project it actually is.

You’re going to need to improve your own debugging game quite a bit to get this to work.

Maybe should should spend some time with known good implementations first…

Beware that even once you start generating valid uplinks, you’re still going to have to deal with MAC configuration downlinks correctly, or you’ll get stuck in a loop on those distorting any picture of network performance.

[dpergarc]

Hi there!

After seeking deeply what was going on, I finally achieved sending data to the device itself registered on the ttn stack, just as it is seen in the picture below:

Data in hexadecimal -> 543A32372E30383B483A32362E3436
Data in ascii -> T:27.08;H:26.46

The change was in the fctrl parameter, setting that the adaptive data rate will be used. It is weird, since another value (e.g. 0x00) give me the classical issue Host cluster failed to handle message.

Sorry if this is something trivial for all of you guys, but… Can anyone give me an idea of what this is happening? Am I missing something that might be relevant?

Thanks beforehand, looking forward to hearing from you.

Kind regards.
Daniel.

[kersing (Jac Kersing)]

Even in simulation I think sending ASCII text is not the way to go. It sets a wrong example and won’t match real world where binary encoded data will be transmitted. (Or should be transmitted)

@dpergarc

The change was in the fctrl parameter, setting that the adaptive data rate will be used. It is weird, since another value (e.g. 0x00) give me the classical issue Host cluster failed to handle message .

You are not showing the message so it is hard to comment. Fctrl can be zero as far as I know but other header fields may have impact on what should be there.

@dpergarc

Sorry if this is something trivial for all of you guys, but…

For most forum users this will be something they’ll never encounter as few work on the internals of a LoRaWAN stack. However if you are working on it as you are you should read the LoRaWAN specification front to back and back to front and make sure you understand it. Have you done so?