Adeunis Field Test Device TTN issue

Community Help With My Project Helped
1

Has anyone been using the AdeunisRF Field Test Device using Things Network? I am only getting RSSI, SNR, Battery, Button, Temperature and Shock. The device has got a lock on 9 satellites and is transmitting the GPS in the data packet from what I can see on the TTN console.

Many thanks

Julian

2

HI @Julianlstar and welcome to the Cayenne Community.

If you PM me the device DevEUI, I can check our logs and see if we’re receiving this GPS data and decoding it properly on our end.

3

Thanks for the PM. I think I see what might be up.

I’m seeing plenty of packets in the logs from the Adeunis device – but I’ve noticed the packets seem to be expecting our ‘Adeunis Demonstrator’ codec instead of the 'Adeunis Field Test Device` one. Could you try removing the device from Cayenne, and re-adding it as an Adeunis Demonstrator, and then letting me know if you see the GPS (and the rest of your data) OK?

As for the MiroMico device, which is using the Cayenne LPP format for its payloads, it looks like we’re getting an extra unexpected byte at the end which is why the data is not decoding properly. Here is an example from an actual payload from your device:

We’re getting:
Base64: AXMoCQJnAO4DaG3j
which converts to:
Hex: 01 73 28 09 02 67 00 ee 03 68 6d e3

The issue is with the last segment 03 68 6d e3, which defines the humidity sensor on channel 3. This type only expects a single byte for data, so that e3 is throwing off our codec. When we remove it, it decodes properly:

[
    {
        "channel": 1,
        "type": "bp",
        "unit": "hpa",
        "value": 1024.9,
        "name": "Barometer (1)"
    },
    {
        "channel": 2,
        "type": "temp",
        "unit": "c",
        "value": 23.8,
        "name": "Temperature (2)"
    },
    {
        "channel": 3,
        "type": "rel_hum",
        "unit": "p",
        "value": 54.5,
        "name": "Humidity (3)"
    }
]
4

Many thanks. I have recreated the Adeunis device as a demonstrator and that works now which is great. As far as the Miromico is concerned. Is there a way to deal with the last byte on the Cayenne platform or do we need to do something more involved. Is there a way to see the payload and its associated metadata?

5

@Julianlstar,

Creating code to predict what data to accept and what to reject will really complicate things, and no matter what you do, you’re going to guess wrong.

It wouldn’t be difficult if the payloads were singular, but the LPP payload allows multiple channels and sensor values without wasting bytes on delimiters. Thus IMHO, the codecs are right to reject this data.

Cheers,

Craig

6

I agree. I was a little surprised that the Miromico was sending non-compliant packets in the first place. :confused:

7

I determined that the Loriot gateway adds a padding byte of ‘00’ when the payloads are not even. Ugh.

We were building data radios in the early 90s. Figured we’d be able to get it right by now. It’s 2017!! LOL.

Cheers,

Craig

8

I think @kreggly covered it for the most part, but on the Cayenne side we can’t manipulate the payload received. We can of course adjust our codecs if they don’t match manufacturer-provided specs, but in this case the device is using the Cayenne LPP, our own format.

There isn’t currently a user facing way to see the raw payload data in the Cayenne UI, but if you contact me I’d be happy to extract as little or as much as you’d like from our logs and show you how we’re decoding it as well.