Elsys ERS: Partial payload recived

Hi, I’m having issue with Elsys ERS, where sometimes only part of payload data seems to be received.
The expected data from sensor is

  1. Temperature
  2. Rh
  3. Motion
  4. CO2
  5. Battery voltage (VDD)

However some times when data only some of the 5 data-values are received, example only temperature and rh is received.
As I don’t see reason why sensor should sometimes only send part of data I assume that the data is lost somewhere in transit.

Example of complete data-package:

Example of data-package from same sensor with Co2 and Battery data missing:

Appreciate if someone has idea why this happen and how to avoid it.

If you look at the base64 packet early in each dump, you’ll see that one is longer than the other.

If you look down at the end, you’ll see that the full one was sent at DR4, and the partial at DR0

Most likely, DR0 is so slow that sending the full data packet would require more time on air than considered polite, or even more than legally allowed in your location, so the sensor is instead sending an abbreviate packet instead. This gets particularly harsh at low data rates where just the LoRaWAN headers, framing, and checksum can take up a large amount of time.

What might be in the abbreviated packet (just the beginning, or everything packed in a different formate with less resolution) is entirely up to the designers of the sensors.

You need to find out what the shorter packet is actually supposed to contain and make sure your are decoding it properly.

Something that is a little unfortunate is that both packets seem to use the same fPort. Hopefully that means that the shorter one is just a truncated version of the longer; when I do distinct formats for low data rates I use a different port to let the decoder know it needs to handle them differently. Technically you could key off the expected packet length, but that feels like the kind of thing that might be more easily broken when someone makes a “trivial” change.

Thanks a lot for that explanation @cstratton. What would cause the node to drop data-speed to DR0?I
notice this typically happens when it seems that some messages has been not recived. I.e. I have setup the sensor to send a message every 5 minutes, then there is not message for 20 min and after that comes a partial message (at DR0).

A node using ADR will typically roll back the data rate (increase the spreading factor) if it doesn’t get confirmation from the network in a certain amount of time.

The question of course would be why it doesn’t - bad antennas, long range or lots of noise, unreliable receive window timing on the node, flaky Internet backhaul between the gateway and server…

Thanks, solved it by limiting minimum data rate to DR2.

solved it by limiting minimum data rate to DR2.

Beware that may mean that you receive no data at all under conditions adverse enough for DR1 or DR0 to have been the necessary choice.

A better solution would be to pack the data more optimally so it fits within the limits of a slow low data rate packet. Or to have more than one type of packet, each of which individually fits and contains a subset of measurements. But these require changing the node firmware.

It’s also not entirely clear how you have limited the data rate. If you limit the ADR data rate, that may change what is commanded. But it may not stop the node from scaling back to DR1 or DR0 on its own, if it doesn’t get an occasional ack when using DR2.

I don’t really have the option change the packing of the data, as it depend on sensor manufacturer, in this case Elsys. I limited it by changing min-speed in the sensor-settings to 2, which is the default setting (min 2 max 4) for US frequency plan.

At least allow DR1, that has more than twice as much room for application data as DR0, because the overall packet size that fits in the allotted time doubles while the amount of it consumed by LoRaWAN headers stays the same.

Thanks, I may try, however at current I’m mostly using EU band where I don’t have this issue.