Use FCntUp as a pulse counter?

Application Development
1

I know that the metadata can’t be accessed in the decoder.

I have made LoRaWAn devices for use on farms and mostly it doesn’t matter if the odd packet goes missing, but in some cases like a rain gauge, or flow meter, a missed packet compromises the accuracy. In these case a data logger with a radio module is usually deployed but these devices (at least the ones I have used) have bigger payloads and use more bandwidth than the standard LoRaWAN nodes hooked up to a sensor.
But… if as the developer notes state “Every time the device transmits an uplink message, the FCntUp is incremented.” and this is sent in metadata for security reasons, does it mean that every compliant LoRaWAN node is already a data lagger by default - if only you could retrieve the metadata?

I know one can retrieve the metadata over HTTP, so there is a way.

This question is more of a thought bubble from a new user about the potential of FCntUp as a data logging tool in addition to the security function, and why FCntUp isn’t used more widely in this way?

(I’m assuming the FCntUp is applied at the device level not the gateway, that’s the way I’ve understood it.)

3

What I want to do in a general sense is use the FCntUP data instead of a data logger. In a situation where a transmission is counting a pulse, then a missing transmission = a missing pulse, but that could be corrected by using the FCntUP sequence variation at the next received transmission.

In the case of rain gauge, flow counter, people counter etc… the action of the uplink, is the data, and by accessing the FCntUP we are in a way, magically accessing the missing data.

I’m wondering why access to the FCntUP isn’t made possible in the decoder? Or am I totally misunderstanding the FCntUP?

1 Like
4

Ah, so it’s more like: Use FCntUp as a pulse counter? (I’ve edited the title and removed some intermediate posts.)

If the pulse frequency is not too high, then: yes, that will work. (I stand corrected; see below!)

The Decoder in the payload formats really only exists to translate an application payload, and the metadata simply is not part of that payload, so I assume it was not even considered. (Also, testing would be much harder.) With or without a Decoder, you still need the MQTT Data API or some integration to actually access the (translated) application payload anyhow, which will give you the metadata as well. It’s not like that with a Decoder, you would no longer need some API or integration to access the data anyhow.

Aside: given the 13 bytes LoRaWAN overhead, an additional small application payload will not affect the total airtime much. Also beware that most SDKs have been deprecated, so when using the MQTT API just don’t bother about any SDK.

MQTT example 
{
   "app_id":"arjanvanb-app-1",
   "dev_id":"arjanvanb-bb-1",
   "hardware_serial":"70B3D5B020035CD1",
   "port":2,
   "counter":7165,
   "payload_raw":"CWUMqw0LDNM=",
   "metadata":{
      "time":"2017-04-27T10:07:27.207187339Z",
      "frequency":868.1,
      "modulation":"LORA",
      "data_rate":"SF7BW125",
      "coding_rate":"4/5",
      "gateways":[
         {
            "gtw_id":"eui-b827ebffff5fe05c",
            "timestamp":532315708,
            "time":"",
            "channel":0,
            "rssi":-57,
            "snr":9,
            "latitude":52.37447,
            "longitude":4.63576
         },
         {
            "gtw_id":"eui-5ccf7ff42f1970ec",
            "timestamp":1284851361,
            "time":"2017-04-27T10:07:26.494026Z",
            "channel":0,
            "rssi":-49,
            "snr":9,
            "rf_chain":1,
            "latitude":52.374523,
            "longitude":4.635771,
            "altitude":4
         }
      ]
   }
}
5

Ok interesting, now I need to get a better understanding of the MQTT Data API, and then I’ll see if I can make it work…

Thanks so much for your help.

6

One day there may be a need to send an answer to MAC command or other packed without application payload and at all not initiated by application.

2 Likes