Cayenne LPP decoding error


#1

My sensor payload data could not be parsed by LoRa APP server, server reports:

"type":“CODEC”,“error”:"read full error: unexpected EOF"

Details:

application/1/node/307441d000000cd1/rx {“applicationID”:“1”,“applicationName”:“altitude”,“deviceName”:“ANT1OTAA”,“devEUI”:“307441d000000cd1”,“rxInfo”:[{“mac”:“31328a30000007de”,“rssi”:-43,“loRaSNR”:25,“name”:“EU433GW”,“latitude”:31.0456,“longitude”:121.3997,“altitude”:0}],“txInfo”:{“frequency”:43357
5000,“dataRate”:{“modulation”:“LORA”,“bandwidth”:125,“spreadFactor”:7},“adr”:false,“codeRate”:“4/5”},“fCnt”:393,“fPort”:2,“data”:“MQMDCG9oIHllYWgh”,“object”:{“analogOutput”:{“49”:7.76},“illuminanceSensor”:{“121”:24936},“humiditySensor”:{“111”:16}}}
application/1/node/307441d000000cd1/error {“applicationID”:“1”,“applicationName”:“altitude”,“deviceName”:“ANT1OTAA”,“devEUI”:“307441d000000cd1”,“type”:“CODEC”,“error”:“read full error: unexpected EOF”,“fCnt”:394}

Data received by LoRa-Gateway-Bridge is:

E…%…|…2…(<…12.0…{“rxpk”:[{“tmst”:2944735325,“freq”:433.57500,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:29,“rssi”:-43,“size”:25,“data”:“QDYhSwYAiAEC0m0HsVCYZIaruvDEUnyNQA==”}]}
12:44:35.081653 IP rdcxuly-Aspire-1830T.1700 > 192.168.1.124.1700: [|radius]

Is this configuration error? Anyone knows?

Regards
Hart


#2

I assume you’ve configured the Cayenne LPP codec?

The base64 data maps to the following byte slice []byte{49, 3, 3, 8, 111, 104, 32, 121, 101, 97, 104, 33}

That is:

  • channel 49, data type 3 (analog out), data 3, 8
  • channel 111, data type 104 (humidity), data 32
  • channel 121, data type 101 (illum.), data 97, 104
  • channel 33, ???

It seems the CayenneLPP payload is corrupted as more data is expected, hence the EOF (end of file) error.

As a reference:

(https://mydevices.com/cayenne/docs/lora/)


#3

Hi Brocaar,

Thanks for the prompt reply!

We’ve checked with the sensor vendor, they are using TLV encoding.

Seems the APP decode this and failed.

BRs//Hart


#4

Hi Brocaar,

We found the issues, the source is encoded by TLV, so we could use TLV to decode them.

Thanks!

BRs//Hart