Payload decoding results in empty field

Hello all,

I’m in the process of completing a migration from the V2 servers to V3 and while I don’t think my issue has to do directly with the migration, if I need to post this under the V2 to V3 migration, I can.

Everything seems to be working fine with the exception of payload decoding. I’ve pasted my code below and while I am not a JS coder, it has been working. Now I get the following result in “Data Preview” after receiving an uplink message:

“Payload: { } 35352E303032342E3830 FPort: 1”

I’ve been testing this both with “real” payloads and with the simulated payload function in the console with the same result. Here’s what I expect to see now and prior to the migration for that specific payload:

“Payload: { field1: “55.00”, field2: “24.80”} 35352E303032342E3830 FPort: 1”

Uplink Payload Formatter Code:

function decodeUplink(bytes) {
  // Modified for 10 bytes, 2 values in 1 payload
  var decoded = ""; 
  var H = "";
  var T = "";
  // Decode entire payload
  for (var i = 0; i < bytes.length; i++) { 
    decoded += String.fromCharCode(parseInt(bytes[i])); 
  // Split payload:
  // Humidity first:
  for (var n = 0; n < i/2; n++) {
   H += decoded[n];
  // Temp second:
  for (var p = n; p < decoded.length; p++) {
   T += decoded[p];
  // Return values:
  return {
	  field1: H,
	  field2: T

Any tips/observations are greatly appreciated.

Are you certain your JSON is valid? ( im not a JS coder either :stuck_out_tongue: )
should be:

    	"field1": 55.00,
    	"feld2": 24.80

I would like to suggest you use CayenneLPP .

I just updated the payload decoder to see if adding quotation marks changes anything and unfortunately it does not.

Thank you for the suggestion of Cayenne, but my understanding of it is that it does not support a free plan for over 10 devices. For the system we are designing, we expect to be above 15 nodes within the next year and the department (University-based) that will be handling the system does not have a budget for a monthly/annual subscription service.

1 Like

Well… I just meant using cayenne lpp as your payload only… you are not married to the Cayenne Platform just because you choose to encode your payload using the Cayennee LPP, and have TTN decode it.

Oh, I wasn’t aware it would work without the myDevices backend. Thank you, I’ll look into it right away.

Please do because your current ascii encoded messages waste a lot of airtime. Always use a binary format to transfer numeric values.

I’d suggest you start with the v3 template and add to it from there as at present your return isn’t structured in the way that v3 needs it to be

Right, I noticed I had left off the “data” block and I just found the “Payload Formatters” documentation. I’m pursuing the CayenneLPP solution at the moment, but I seem to have run into another issue.

Approximately every 60 seconds (per the “Live Data” timestamps) a “Console: Network Error The stream connection was lost due to a network error” will trigger with a resolution of “Console: Stream reconnected The stream connection has been re-established” 5-6 seconds later. If necessary I can start another thread, but I’m not sure if this is a connected issue or not.

Thank you all for your help thus far.

This is entirely your browser / computer / ISP and the servers not talking to each over in time. Nothing to do with actual LoRaWAN. Every 60 seconds is a bit much so you may want to see what’s up with your browser / computer / ISP.

Thank you, I was worried that I had missed something in the V2 => V3 migration. Whatever the network errors were, they seem to have resolved themselves over the weekend.

I am still stuck as far as my original problem goes, however. I am using an Arduino MKR WAN 1310 as my end device and I cannot get the CayenneLPP or TheThingsNetwork Arduino libraries to play nicely with the hardware. I would like to use it as it seems perfect for our situation, however with my original issue still in place I cannot even begin to troubleshoot the problems.

Currently, I have this payload decoder in place:

function decodeUplink(bytes) {

  var result = ""; 
  for (var i = 0; i < bytes.length; i++) { 
   result += String.fromCharCode(parseInt(bytes[i])); 
  return {
    data: {"field1": result},
    warnings: [],
    errors: []

Just as a test case for simulated messages. And, as in the original issue, no matter what I put in as a payload, I receive an,

Payload { field1: "" }

I’m fairly certain the JavaScript isn’t the issue (could be very wrong there, not my strongest language) and I believe I am as close the original V3 template as possible. Any ideas as to what I’m missing?

You are still decoding ascii text. Don’t use ascii to transport numeric data as it is a huge waste of airtime.
Next, have you tried sending Cayenne LPP format messages and using the build in decoder? TTN V2 and V3 both allow you to choose this decoder. No need to write your own JavaScript one.


I understand that this is still encoding ascii and I understand that using this method practically would be a colossal waste. I am not using this to transmit messages. I am using the “Simulate Uplink” feature of the console. I am trying to troubleshoot the issue of the empty payload field by breaking the problem down to it’s most basic pieces, in this case: the decoder. Why would it be decoding " " when there is clearly a payload there?

Yes, I have tried using CayenneLPP, however I am unable to get it working properly. As I mentioned earlier, I believe the issue lies with my end device, the Arduino MKR WAN 1310. I have tried several variations of the example in TheThingsNetwork library, here, but I am unable to get TheThingsNetwork library to configure my end device properly. It loops through each channel on the device before exiting with an error. I was never able to get my end device to connect using the TTN library in a sketch.

I have tried modifying the most basic “LoRaSendAndReceive” example with the CayenneLPP, but I believe the MKRWAN library modifies the payload so that it is unreadable to the decoder. When I tried this, I was able to connect but there was a decoding error (using the built-in Cayenne Decoder) every time. Maybe there’s some combination of the JS decoder and Cayenne to explore there, but I feel like that defeats the purpose of Cayenne. Does anyone have any experience using a MKR WAN 1310 and CayenneLPP?

Hint: Look at the template that v3 provides and compare & contrast with your code.

You’re trying to troubleshoot a type of conversion issue quite likely unique to a source data type you shouldn’t be using at all.

Why should people help you accomplish something you shouldn’t be doing?

Breaking the problem down to the useful essence would be working with simulated test payloads containing sensible numeric values, bitmaps, or concise enums - not ASCII.

Simulate appropriate packets, not inappropriate ones.

TheThingsNetwork library is for nodes based on microchip modules. You should just use the CayenneLPP files, not the example for different hardware,
Or you search with google for the keywords Arduino and CayenneLPP and you might find something like GitHub - ElectronicCats/CayenneLPP: Library for Arduino compatible with Cayenne Low Power Payload .
Examples again depend on specific LoRaWAN hardware but should provide plenty of guidance on how to fill a buffer with data. That buffer can be used as variable for the transmit function of your specific LoRaWAN stack.

There is also the rather brilliant TTN docs which sadly are being moved around but this is the relevant bit.

The OP doesn’t have to try LPP, perhaps just not send ASCII and perhaps review the difference between their JS and the actual JS template.

The current LPP decoder does not support the “newer” objects as found in ie. ElectronicCats repo.

What can I do to get more objects implemented in V3 ?
Is it this library that’s used in V3 - GitHub - TheThingsNetwork/go-cayenne-lib: CayenneLPP in Go ??
And the code in “lorawan-stack” that needs some hacking?


Welcome to the forum - this thread is less relevant than the other one you posted on so please continue there - we prefer to keep to one thread per discussion so it doesn’t split readers time.