LoraWan_OTAA and TheThingsNetwork

WisBlock
1

Hello im using the exsample LoRaWAN_OTAA in Arduino IDE

i Successfully connect to TTN and recived the test message “Hello” .

But now i want to change the payload to my Temperature/Humidity sensor but i don`t know where to begin.

is there a working example with LoRaWAN_OTAA and Temperature/Humidity that i could use?

2

Hei @Shuntmaster

I would suggest you start here:

You might have to adapt one of the examples depending on your particular sensor.

Regards
Vladislav

1 Like
3

while using the OTAA examples, i noticed the following

1- the delay in sending will also apply to OTAA so the first message will be delayed.
#define LORAWAN_APP_INTERVAL 300000

2- the node sends 7 trials of each message and waits for ack. (downlink) as i can see in the console of the things network on both application data and gateway data.
16:40:57.162 -> lmh_send fail count 7
16:41:17.163 -> Sending frame now…
16:41:17.163 -> lmh_send fail count 8
16:41:37.146 -> Sending frame now…
16:41:37.195 -> lmh_send ok count 5
16:41:57.159 -> Sending frame now…
16:41:57.159 -> lmh_send fail count 9

although the messages are all reaching the gateway, the node thinks they are not. how can we disable ack?

4

i changed this variable
lmh_confirm gCurrentConfirm = LMH_CONFIRMED_MSG; to LMH_UNCONFIRMED_MSG
and now it sends the msg only once but i have no clue what this means.
also i still get the downlink…
any documentation on that?

1 Like
5

That is the correct way to do things; you should not used “confirmed” traffic with TTN or really most networks as it is very wasteful of gateway airtime.

also i still get the downlink…

A node will typically receiver a couple of configuration downlinks after joining a network. These will be on port 0 and contain only MAC commands. If you show the specific downlinks they can be explained.

2 Likes
6

Hello Baxter,
To explain a little bit more.
LMH_CONFIRMED_MSG and LMH_UNCONFIRMED_MSG are a LoRaWAN feature.
If you set LMH_CONFIRMED_MSG the node expects a response from the LoRaWAN server that the package was successfully received.
If LMH_UNCONFIRMED_MSG is used, the node does not expect any resonse from the LoRaWAN server.
LMH_CONFIRMED_MSG is like expecting an acknowledgement from the LoRaWAN server.

This has nothing to do with sending packages from the LoRaWAN server to your node.

2 Likes
7

That’s not really accurate.

If confirmed uplink traffic is sent, then a downlink confirmation must be sent (which costs the network a lot of capacity!)

Granted, it’s not the only reason a downlink may be sent - custom downlink messages can be sent in response to uplinks, too.

And also configuration downlinks.

But sending confirmed uplink means that if there isn’t a downlink in response, the node’s stack will either retry, or declare a failure.

Also, it’s “packet” not “package”

2 Likes
8

Hi Bernd,

Ok I disabled to confirm the packet with: LMH_UNCONFIRMED_MSG
but how to avoid sending the response form the LoRaWAN server as it is in this case wasting of airtime.

BR, Jeroen

1 Like
9

Hi @JeroenKl, with the node configured with UNCONFIRMED_MSG, there should be no confirmation downlink that would come from the network server. Although there will be occasional downlink from TTN which is needed for adjusting DR if ADR is enabled.

I am not sure if this is what you mean. In case I am wrong, can you share a screenshot about Lorawan NS response you are talking about.

2 Likes
10

When you set LMH_UNCONFIRMED_MSG while sending, the LoRaWAN server knows that he doesn’t need to acknowledge. The packet sent to the server has a flag that tells whether an acknowledge is required or not:
image

2 Likes
11

Again ofcourse, thanks!

1 Like