Hello. Using End_Node sample application from ST…LRWAN v.1.2.3 I see only first Uplink contain the payload:
Second and all next Uplink messages is empty:
From device log I see that Uplink Frame with data size in 8 bytes was sent on Port 2.
Does anyone saw the same problem?
Where to look to troubleshoot such strange things?
Thanks for any suggestion and help!
Messages sent on fPort zero are network management messages, they do not contain any application data, but merely flags and mac commands.
If you examine those you may find out why these are being exchanged, It’s likely that either an uncompleted handshake there is holding things up, or that the application side of your node program is not yet trying to send any new data, so only this link management information is currently flowing.
Also, if you send a zero length message, the ST LoRaWAN stack forces fPort to 0.
This is actually kind of annoying, as I wanted to use 0 length messages to certain ports acknowledge certain actions. Now I have to send an extra useless byte.
The 4/5 coding typically used means there’s actually no airtime difference between a 13 byte packet (ie, headers only) and a 14 byte one. However, fOpts could bump the non-application portion above 13 bytes.
Looks like problem is in End_Node sample application. In file lora.c function:
bool LORA_send(lora_AppData_t* AppData, LoraConfirm_t IsTxConfirmed)
doing a check of AppData buffer (actually size of this buffer!!!)
if( LoRaMacQueryTxPossible( **AppData->BuffSize**, &txInfo ) != LORAMAC_STATUS_OK )
And instead of send my payload go to send an empty frame:
{
// Send empty frame in order to flush MAC commands
…
And such behavior I found not only in B-L072Z_LRWAN dev board, but also in Dragino LoRa I/O Controller LT-33222-L. I think Dragino device used the same STM32 library inside.
Will go deep to research why an empty frame was sent each minute except first time after OTAA Join. Maybe something is related to ADR settings between LoraServer and devices.
That sounds like a “how things are supposed to work” not a “problem”
If there is a problem, it’s perhaps that the exchange of MAC command traffic isn’t completing.
Actually it is a “problem” then “things not working as they should to do”.
But, seems I found the source of my problem!
As I say the function make a decision to send empty frame based of size of application buffer:
if( LoRaMacQueryTxPossible( data->BuffSize, &txInfo ) != LORAMAC_STATUS_OK )
{
// Send empty frame in order to flush MAC commands
As soon as I decreased the number of my payload from 8 bytes to 6 (2 bytes, Carl!) it start to work.
Looks like “macPayload” with 2 “channelMaskAck” (loraserver sent 2 “LinkADRReq” with ack - first with disable all 16 channels and second with enable 8 of them) do not left a space for my own “frmPayload”.
Surprising that the MAC command ACKs are that big. I guess you are running at a very low data rate.
Anyway, it seems like the actual issue would only be if this keeps happening packet after packet.
If that is the case, then the problem you need to understand and solve is why the interchange of MAC commands and acks is not completing. That really should only be an in frequent event (possibly with retries) not something that keeps happening over and over and over again.
Yes. In each Downlink/Uplink I see MAC commands for masking channels and ADR.
I thought it’s should be there, but after your message I suppose something wrong in my loraserver settings.
I am still learning…
In US915 Regional Parameters recommendation for Join is DR0, but all my Uplink transfer using DR0.
Looks like ADR is not working…
Probably you are not achieving a round trip exchange of messages, hence the MAC command keep repeating and ADR never ramps up the data rate.
The thing to figure out is what exactly is failing, and why.
The most useful things you can do are to put some debug logging in the node firmware, and to examine the MAC level contents of the uplink and downlink packets.
I did debug of LoRaMAC library line by line and found this strange comment in code.
So, on any “LinkADRReq” from server the end-node return “adrAckReq” = false.
// We call the function for information purposes only. We don't want to
// apply the datarate, the tx power and the ADR ack counter.
LoRaMacAdrCalcNext( &adrNext, &datarate, &txPower, &adrAckCounter );
In file LoRaMacAdr.c the “datarate” is selected maximum from requested and hard coded min (DR0 by default):
datarate = MAX( datarate, minTxDatarate );
if( datarate == minTxDatarate )
{
*adrAckCounter = 0;
adrAckReq = false;
}...
Is anybody familiar with Semtech LoRaMAC lib and how it should to used in US915 region?
Thanks.