Uplink confirmation message

Samuel-ZDM commented 2 years ago

Hello. It's me bothering you again.

I was doing a research on why every uplink message is sent a downlink in The Things Stack, being a confirmation message of received uplink.

In this research I found that it is the format of the uplink that indicates to send a downlink as confirmation.

In your tests did this happen too?

Thank you very much in advance.

Samuel-ZDM commented 2 years ago

https://github.com/ricaun/LoRaWanPacket/blob/5eb36c999efa77949b01da28aa3a67a87f052cc0/src/LoRaWanPacket.cpp#L484

Looking at this line from your library I believe that an uplink is being sent without confirmation, right?

I don't know what could be causing this. I'm thinking it might be the gateway. Or it could be in the format of the uplink being sent that could be influencing the sending of downlinks.

Does confirmation also occur in your applications?

Samuel-ZDM commented 2 years ago

I tried to make some changes to the package format but got no result. Every uplink continues to send a downlink. In the code it says it's not to send, but it's sending, I don't know why.

ricaun commented 2 years ago

Actually the confirmation is defined by the FCtrl byte.

The first byte define if the payload is requesting a confirmation message, and then the node/gateway response with the FCtrl set.

Usually the node response right away the confirmation, on the code I did not implement that, the next message the FCtrl byte is set and send to the server.

Maybe the server is send some other configuration, like what frequency/delay the node should work, maybe the server wants a confirmation for that.

Samuel-ZDM commented 2 years ago

I understood!

So would I have to change the value of FCtrl for this to work or would I have to change the message format entirely? I thought it was the 0x40 value that was not being sent correctly.

I'll see if I can make the changes. Thank you very much.

ricaun commented 2 years ago

Here I forcing to change the FCtrl.

https://github.com/ricaun/LoRaWanPacket/blob/5eb36c999efa77949b01da28aa3a67a87f052cc0/src/LoRaWanPacket.cpp#L234-L239

Probably is not only a confirmed request.

Do you have the server downlink to share?

Samuel-ZDM commented 2 years ago

Message type = data PHYPayload = 60E72C0C268B0E00060330000071033000FF0102B06B3D6683CE

(PHYPayload = MHDR [1] | MACPayload [..] | MIC [4]) MHDR = 60 MACPayload = E72C0C268B0E00060330000071033000FF0102B06B

Would it be this? I got this from the other issue I posted.

ricaun commented 2 years ago

By: https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=60E72C0C268B0E00060330000071033000FF0102B06B3D6683CE

Message Type = Unconfirmed Data Down
   Direction = down
        FCnt = 14
   FCtrl.ACK = false
   FCtrl.ADR = true

Is an unconfirmed message, and probably is something with the ADR on.

Need to find how to disable this ADR, I supposed the FCtrl = 0x00 should not request ADR configuration...

ricaun commented 2 years ago

Message type = data PHYPayload = 60E72C0C268B0E00060330000071033000FF0102B06B3D6683CE

(PHYPayload = MHDR [1] | MACPayload [..] | MIC [4]) MHDR = 60 MACPayload = E72C0C268B0E00060330000071033000FF0102B06B

Would it be this? I got this from the other issue I posted.

The server is receiving what payload?

enum {
    // Bitfields in frame control octet
    FCT_ADREN       = 0x80,
    FCT_ADRACKReq   = 0x40,
    FCT_ACK         = 0x20,
    FCT_MORE        = 0x10,   // also in DN direction: Class B indicator
    FCT_OPTLEN      = 0x0F,
};

Maybe the node is requesting ADR by mistake, the node should send 0x00 on the FCtrl.

Samuel-ZDM commented 2 years ago

Message Type = Data
  PHYPayload = 40C6B20C2600020001C37E8E798028D9B067E78198A7263DC722B0

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 40
  MACPayload = C6B20C2600020001C37E8E798028D9B067E78198A726
         MIC = 3DC722B0

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = C6B20C26000200
       FPort = 01
  FRMPayload = C37E8E798028D9B067E78198A726

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 260CB2C6 (Big Endian)
       FCtrl = 00
        FCnt = 0002 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Up
   Direction = up
        FCnt = 2
   FCtrl.ACK = false
   FCtrl.ADR = false

This is what the gateway received. 016700E202688503… This is on the TTN V3 server. I can't get the entire payload

Samuel-ZDM commented 2 years ago

Screenshot_20210930_161412

ricaun commented 2 years ago

40C6B20C2600020001C37E8E798028D9B067E78198A7263DC722B0 looks fine.

I don't know how to make this server configuration stop...

Probably need to send a specific configuration or something...

Samuel-ZDM commented 2 years ago

I tried looking at the beelanMX library to compare the submission but couldn't find a difference.

Because from what I've seen the maximum number of downlink messages per day is 10, so if you get confirmation only 10 uplink can be sent.

ricaun commented 2 years ago

Something was wrong on the code.

Now shold work, just update the library.

ricaun commented 2 years ago

The server still send some downlink and I didn't found whats for yet.

60F5A80D26810300064398503E
60F5A80D26810300064398503E

ricaun commented 2 years ago

The server is asking for the MAC DevStatusReq.

https://docs.loriot.io/display/LNS/Device+status+DevStatusReq

ricaun commented 2 years ago

I add IsDevStatusReq to send a response to the server. Kinda work, I still need to test with a new device and validate if works.

ricaun commented 2 years ago

Now looks like it's working fine!

Samuel-ZDM commented 2 years ago

Perfect! I haven't tested it yet, but I will.

Thank you very much.

ricaun / LoRaWanPacket

Uplink confirmation message #6