Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/mcci-catena/arduino-lmic/pull/395 below:

Lost payload in first uplink after a confirmed downlink · Issue #395 · mcci-catena/arduino-lmic · GitHub

Testing downlink confirmation with current code (commit #6427a03) on EU868 with TTNv2 i found a strange effect. Not sure if this is a bug in LMIC, or maybe TTN or even my application.

Reproducable show case:

1. Sending 1 byte of payload as confirmed downlink from TTN console to device
2. Device receives payload correctly and sends ack
3. Ack is correctly shown in TTN console
4. The next unconfirmed uplink initiated by the device with (in my example) 17 bytes payload given to LMIC_setTxData2() results in an uplink with NO payload, that means, the payload is lost.

23081882: TXMODE, freq=867700000, **len=15**, SF=7, BW=125, CR=4/5, IH=0

I decoded the packet which is seen on the gateway in step 4.

Assuming hex-encoded packet
405E250126A00E0054D7E595

Message Type = Data
  PHYPayload = 405E250126A00E0054D7E595

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 40
  MACPayload = 5E250126A00E00
         MIC = 54D7E595

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = 5E250126A00E00
       FPort = 
  FRMPayload = 

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 2601255E (Big Endian)
       FCtrl = A0
        FCnt = 000E (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Up
   Direction = up
        FCnt = 14
   FCtrl.ACK = true
   FCtrl.ADR = true

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4