UnconfirmedDataDown & DataUp

Hi there.

I used the Hex code “8200” to disable the buzzer on the T1000-A from SenseCAP.

It was successfully sent from the queue, and everything is working fine. I then switched back to “None” in the “Codec” tab, as I don’t need confirmation messages.

Since then, I have been getting the error message “UnconfirmedDataUP” (see below), as well as “UnconfirmedDataDown”.

Thank you for your help.

      • m_type:“UnconfirmedDataUp”
      • major:“LoRaWANR1”
    • :arrow_forward:

mic: 4 items
* 0:17
* 1:13
* 2:143
* 3:255

  • :arrow_forward:

payload:{} 3 keys
* f_port:0
* :arrow_forward:

fhdr:{} 4 keys
* devaddr:“4800081e”
* f_cnt:10
* :arrow_forward:

f_ctrl:{} 6 keys
* ack:false
* adr:true
* adr_ack_req:false
* class_b:false
* f_opts_len:0
* f_pending:false
* f_opts: 0 items
* :arrow_forward:

frm_payload: 1 item
* :arrow_forward:

0:{} 1 key
* :arrow_forward:

LinkADRAns:{} 3 keys
* ch_mask_ack:true
* dr_ack:true
* tx_power_ack:true

  • :arrow_forward:

rx_info: 1 item

  • :arrow_forward:

0:{} 9 keys
* context:“7SM2GA==”
* crcStatus:“CRC_OK”
* gatewayId:“f96997857975cefa”
* gwTime:“2025-01-28T20:45:08.075+00:00”
* :arrow_forward:

metadata:{} 9 keys
* gateway_h3index:“8c1fb460c9837ff”
* gateway_id:“11tcwZXaUg43ULmRz6PM9aJmdKVTfJVsY4xqagQSKVVscuHBYSy”
* gateway_lat:“48.825070580129015”
* gateway_long:“2.237454549007108”
* gateway_name:“high-vermilion-wolf”
* network:“helium_iot”
* regi:“EU868”
* region_common_name:“EU868”
* region_config_id:“eu868”
* nsTime:“2025-01-28T20:45:08.160350806+00:00”
* rssi:-86
* snr:14.5
* uplinkId:52883

  • :arrow_forward:

tx_info:{} 2 keys

  • frequency:867900000
  • :arrow_forward:

modulation:{} 1 key
* :arrow_forward:

lora:{} 3 keys
* bandwidth:125000
* codeRate:“CR_4_5”
* spreadingFactor:7

The formatting of this got messed up a bit. But regardless I’m still confused on a few points here:

  1. Codecs don’t determine whether an uplink is confirmed or not, they only decode the data packet into readable values.
  2. Unconfirmed data up is not an error, it just means that the device is not expecting a response from the server after each uplink, this is typical lorawan usage.
  3. The ‘error’ you shared looks to me like a proper uplink.

From my point of view it I think everything is working, it might just be that you are not sure what to expect here. The device determines whether an uplink is confirmed (meaning it is expecting a downlink after) or unconfirmed, perhaps your hex command just changed the type of uplinks it is sending if you were not seeing this before?