[SOLVED] Send more than 11 bytes 915 MHz - LORAWAN

[andrelmbraga1]

Using Wireless Stick Lite I’m trying to send more than 11 bytes to TTN using HT-M02 as gateway.

Until now I have changed in commissionig.h the LORAWAN_APP_DATA_SIZE to 12 in order to test, but without succeced.

> ```
> * User application data buffer size
> */
> #define LORAWAN_APP_DATA_MAX_SIZE                           64
> /*!
>  * User application data buffer size
>  */
> #if defined( USE_BAND_433 ) || defined( USE_BAND_470 ) || defined( USE_BAND_470PREQUEL ) || defined( USE_BAND_780 ) || defined( USE_BAND_868 )
> #define LORAWAN_APP_DATA_SIZE                       16
> #elif defined( USE_BAND_915 ) || defined( USE_BAND_915_HYBRID )
> #define LORAWAN_APP_DATA_SIZE                       11
> #endif
> ```

[andrelmbraga1]

I was digging in the internet and I found this:

So I tried to change the DATARATE at commissioning.h

/*!

• Default datarate
  */
  //#define LORAWAN_DEFAULT_DATARATE DR_0
  //#define LORAWAN_DEFAULT_DATARATE DR_4

I didnt have success, so I tried to disable the ADR. Changing:

*!

• LoRaWAN Adaptive Data Rate
• \remark Please note that when ADR is enabled the end-device should be static
  */
  #define LORAWAN_ADR_ON 0

Also no success with this modification.

@Supporter @Saber

[Saber]

Hi, I read your post and went to test.
LORAWAN_APP_DATA_SIZE in the commissionig.h file does not seem to affect the number of upstream bytes.
Because I found that LORAWAN_APP_DATA_SIZE is only called in downstream, it is used in some downstream testing code.

To this end, I did a US915 uplink data test. In the case of significantly larger than 11 bytes, the server still received the data completely.

Wish you have a nice day~

[andrelmbraga1]

Hello @Saber I’m not sure which server are u using. However I ll do a parallel with TTN. I think the “data:” that you are seeing correspond to the “payload” that I can see at the GATEWAY TRAFFIC page. Over there I also can see some payload but in my side I my not sure if it corresponnd to the msg[] at the node side.

In my TTN Payload Format:

function Decoder(bytes, port) {
// Decode plain text; for testing only
return {
myTestValue: String.fromCharCode.apply(null, bytes)
};
}

In my Application Data:

Could you try at TTN, using OTAA_OLED example, and using this decoder function ? Or if u use another could u share?

[Saber]

Hi, I think there seems to be something wrong with your decoding script?
Maybe the parameter type in myTestValue: String.fromCharCode.apply (null, bytes) is incorrect?

I used the chirpstack server in my tests, which is an open source project.
https://www.chirpstack.io

[andrelmbraga1]

@Saber I’m almost sure that the decoding is not the problem. When I’m using mcci-catena arduino-lmic
(https://github.com/mcci-catena/arduino-lmic) it works as you can see:

When I am using Heltec library it works with less than 11 bytes as I said before but if I put 12 or more it stops to send the payload. That is a HUGE problem for me. I’m really trying to stay with HELTEC because of your support however if it doesn’t work I ll need to change the library.

My Heltec ESP32 Dev-Boaards is on 1.0.9 Version (last).

@Saber are you using 915 MHz? I have just tried also with ChirpStack and I found the same problem! Whith 11 bytes or less works ok:

When I use more than 12 bytes or more:

I really cant find why this is happen!!

[Saber]

Hi:
After this I did a detailed test and found the problem you said.
When there are more than 11 bytes in 915Mhz, the node payload is missed.
But I need to add that missed messages only appear in the first uplink after the node enters the network, after which my node load can be correctly received by the server.
This is indeed a bug. I am looking into the cause of this bug. I will deal with it as soon as possible after I find the cause. Thank you for your support.

[Saber]

Hi:
I think I have found the problem and have a proper solution.
In US915MAC, the initial DataRate defaults to DR0 (0). In “ValidatePayloadLength”, the payload length is verified based on the DR.

!
When DR is 0, the maximum load length is specified according to “MaxPayloadOfDatarate” as 11.

So the best solution is to change the default DR of US915 to DR1 or DR2 or DR3.
Please check the pictures for specific changes.

Thank you again for your support of our products!
Wish you have a nice day.

[andrelmbraga1]

@Saber I did exactly that yesterday. I was coming to post this solution and works like a charm.

I was just wondering two things:

1 - If the ADR is active, is there any chance to ADR function change the ADR to DR_0 automatically ?
2 - If the device goes to DR_4 it can’t join this is another problem when we desire a payload bigger then 125.

But now I can go further in my tests. Thank you very much for your time and services.

[leroyle]

Is there an API we can call to change the DR on the fly?
Let’s say I have one large initial packet, but then can immediately drop back to smaller packets.
(LoRa newbie, so I hope this makes sense)