Wrong Cayenne LPP value in JSON while using simulated uplink

[jerylcook (jcook)]

I select, Cayenee LPP as the payload type,
However, I am using my own HTTP endpoint which is configured to process TTN JSON payload…

When I obtain the JSON, I see the parsed Cayenne fields which is cool…

However, the system I am developing for needs to process the raw standardize format of Cayenne LPP HEX that will be originally sent from the devices so I was not expecting to see:
“payload_raw”: “AWcA4QJzKewDiAf92AC+4QAAyA==”,

{
  "app_id": "soil-monitor",
  "dev_id": "soil-sensor-1",
  "hardware_serial": "0088AC7798B946E3",
  "port": 1,
  "counter": 0,
  "payload_raw": "AWcA4QJzKewDiAf92AC+4QAAyA==",
  "payload_fields": {
    "barometric_pressure_2": 1073.2,
    "gps_3": {
      "altitude": 2,
      "latitude": 52.3736,
      "longitude": 4.8865
    },
    "temperature_1": 22.5
  },
  "metadata": {
    "time": "2019-04-06T13:10:11.726174787Z"
  },
  "downlink_url": "https:\/\/integrations.thethingsnetwork.org\/ttn-us-west\/api\/v2\/down\/soil-monitor\/morgua-http-ttn?key=ttn-account-v2.5ldf<redacted>EiUAw"
}

However, I assumed i would see:

“payload_raw”: “MDE2NzAwRTEwMjczMjlFQzAzODgwN0ZERDgwMEJFRTEwMDAwQzg= ”

I was under the assumption the payload_raw would be simply the base 64 encoding of the HEX sent via the ‘simulated uplink’…but I get a decoding error of:

org.apache.commons.codec.DecoderException: Odd number of characters.

Does the simulate uplink work with cayenne lpp? or is my configuration wrong…

[ricaun (Luiz H. Cassettari)]

Hello,
I’m using the same principle, but my application select the directy the payload_fields insted of decode the payload_raw.

"payload_raw":"AWcA5AJzJ74=","payload_fields":{"barometric_pressure_2":1017.4,"temperature_1":22.8}

But when I simulate some uplink I never receive a HTTP request.

[jerylcook (jcook)]

The system i am implementing for can only process Cayenne LPP HEX…not the TTN Payload json which has the payload_fields…

[arjanvanb (Arjan)]

No, your node is not sending hexadecimal, but is sending binary data. So, the Base64 encoded value decodes to a binary value, not to a human readable hexadecimal representation. Next, you can show that as hexadecimal, or decimal, or as Roman numbers, and so on…

AWcA4QJzKewDiAf92AC+4QAAyA== decodes to the value you used in the simulated uplink, which in TTN Console is shown as 016700E1 027329EC 038807FDD800BEE10000C8, being 19 bytes. That matches a Cayenne payload of a temperature (4 bytes: 1 byte for the channel, 1 for the type 0x67, 2 for the value), pressure (4 bytes) and coordinates (11 bytes).

The Base64 you expected is much too long for that. You encoded the hexadecimal text representation, which uses 38 characters to be printed on the screen, 2 characters for each of the 19 bytes. In hexadecimal, the 38 characters of 016700E1 027329EC 038807FDD800BEE10000C would be the 38 bytes 0x3031 3637 3030 4531 3032 3733 3239 4543 3033 3838 3037 4644 4438 3030 4245 4531 3030 3030 4338. But that’s not what the node is sending.

[jerylcook (jcook)]

i don’t have any nodes yet…just using the simulated uplink test…Thanks…I get it now from your explanation(payload_raw is binary , not hex!! duh) I implemented the code on the backend incorrectly , but now it works