leroyle / asr650x-arduino Goto Github PK

The last changes broke ADR change of data rate, thus network suggested data rate changes were ignored.

Problem report on Heltec forum:

I’m chasing down some anomalies that occur if one tries to transmit a packet that is larger than the currently defined DR maximum. This is one:

cores/asr650x/loramac/mac/LoRaMac.c - ValidatePayloadLength() is not catching payload lengths that exceed the currently defined DR maximum if the fOptsLen parameter is not zero:

The following will demonstrate, this is run on Ubuntu Linux using cc version 9.3.0, although I don’t expect this to matter.

#include <stdio.h>
#include <stdbool.h>

bool checkLen( int userPayloadLen, int fOptsLen, int drLen);

void main() {
int fOptsLen;
int drMaxLen;
int userPackLen;

// max user packet for DR_0 is 11, these are successful
userPackLen = 10;
fOptsLen = 0;
drMaxLen = 11;
checkLen( userPackLen, fOptsLen, drMaxLen);

fOptsLen = 4;
checkLen( userPackLen, fOptsLen, drMaxLen);

// these exceed drMaxLen and should not pass the check
userPackLen = 20;
fOptsLen = 4;
drMaxLen = 11;
checkLen( userPackLen, fOptsLen, drMaxLen);

fOptsLen = 3;
checkLen( userPackLen, fOptsLen, drMaxLen);
fOptsLen = 2;
checkLen( userPackLen, fOptsLen, drMaxLen);

// this one correctly fails to pass the check
fOptsLen = 0;
checkLen( userPackLen, fOptsLen, drMaxLen);

// Just trying a difference DR, max user packet for DR_3 is 242
userPackLen = 243;
fOptsLen = 4;
drMaxLen = 242;
checkLen( userPackLen, fOptsLen, drMaxLen);

// with fOptsLen = 0, catches the packet too large
fOptsLen = 0;
checkLen( userPackLen, fOptsLen, drMaxLen);
}

// lenN application payload length
// fOptsLen
bool checkLen( int lenN, int fOptsLen, int lenPerDataRate)
{
int maxN = lenPerDataRate; // Data rate dependent max
int LORAMAC_PHY_MAXPAYLOAD = 255;

int payloadSize = ( lenN + fOptsLen );

printf("userPayloadLen: %d, fOptsLen: %d\n", lenN, fOptsLen);

// this if statement copied directly from the ValidataPayload() function
if ( ((( payloadSize > maxN ) && (fOptsLen != 0) && (fOptsLen <= maxN)) || ( payloadSize <= maxN )) && ( payloadSize <= LORAMAC_PHY_MAXPAYLOAD ) ) {
printf("\tcheck true, size ok\n\n");
return true;
}
printf("\tcheck false, packet too large\n\n");
return false;
}

We should use LoRa mac layer API to update the data rate and TXpower if needed

Currently the LoRaWAN data rate is set via a #define in the LoRaWAN library file: LoRaWAN_APP.cpp.
The app dev has no way to vary this config setting without modifying the underlying runtime.

The user should be allowed to either use a #define within the app sketch if this must be set a compile time,
alternatively and better would be a library level API to allow the user to dynamically set Data Rate on the fly.

On the first user data transmit after a join:
If a user passes a packet size larger than the maximum allowed for the current Data Rate setting, the runtime dumps a log message which gives the illusion that this first transmit succeeded.

The scenario:
User sets default data rate to DR_0, (max packet size 11)
The join functionality sets the data rate to DR_3, (max packet size 242) for the join attempt.
The join succeeds
The first user packet is sent to the library layer, the packet size is larger than 11, say for instance 13
The library layer validates the packet size against the currently set Data Rate, which is DR_3. At the point The validation occurs the data rate is still set as was required for the join, DR_3.
The library layer dumps a debug message: either
printf("unconfirmed uplink sending ...\r\n");
or
printf("confirmed uplink sending ...\r\n");

The library packages the data to send to the Radio layer. As part of that packaging, resets data rate to the user defined, DR_0

The lower radio layer does check and catch the data size mismatch now that DR has been reset, and fails the send, notifies the library layer, library layer does "not" notify the app layer.

For the second and subsequent transmits, as the Data Rate has been reset, the runtime layer catches the data size mismatch, does not send to the Radio layer, but again does not report failure to upper app layer.
In these cases we do not see the erroneous debug messages, the app layer is unaware.

this is to make sure we implement the resolution to issue 10 for all regions.

Issue # 10: Network specfied Adaptive Data Rate changes were not being honored as expected

We only added the flag for US915

The runtime does two calls to the region API RegionAdrNext().
The first within LoRaMacQueryTxPossible() has a note that it is for information only, not intended to change anything,

The second in PrepareFrame() does an actual check to see if the ADR parameters should change and expects them to change if needed,

Unfortunately that first call has side effects within RegionAdrNext() that result in the data rate note being changed appropriately, can cause TxPower and ChannelsMask to be updated.
But not all of these are not properly preserved for follow-on transmissions.

We added a infoOnly bool parameter to the call to RegionAdrNext() for US915 only, it would need to be moved into the other regions for full support..

There where changes to RegionUS915 radio preamble length which appears to be uncompatible with RegionUS915.

Commit Note:
modified default min Tx Dr. modified tx preamble length

Commit: f314b1c
Date: Jul 9

File: cores/asr650x/loramac/mac/region/RegionUS915.c

Change: preamble length changed from 8 to 14

From: Radio.SetTxConfig( MODEM_LORA, phyTxPower, 0, bandwidth, phyDr,
1, 8, false, true, 0, 0, false, 3e3 );

To: Radio.SetTxConfig( MODEM_LORA, phyTxPower, 0, bandwidth, phyDr,
1, 14, false, true, 0, 0, false, 3e3 );

RegionUS915 concern:

The same LoRaWan document seems to say preamble length should be 8, where does the change to 14 come from?

 https://lora-alliance.org/sites/default/files/2020-06/rp_2-1.0.1.pdf

There does not appear to be any override/work around other than changing the
runtime.

Heltec had already added:
void setDataRateForNoADR(int8_t dataRate);

we need the complimentary:

int8_t getDataRateForNoADR();

It is possible for the LoRaWAN::send() to fail silently, for example if user packet exceeds maximum allowed for currrent data rate.
In this call the app level has not knowledge of the failure. Runtime should give the app developer an opportunity to correct the failure and retry.