Improving my payload strategy

1

image
Hi,
I’m using a TTN Uno with my own gateway. Payloads (pic attached) are:-

  • My 7 byte payload consists of 4 arduino digital input pins plus 3 A/D readings. This is sent whenever there is a change of input. It’s one byte per pin, rather than one bit per pin simply because I haven’t worked out how to do that yet!
  • My 3 byte payload is the 3 A/D readings again. Sent every hour, once testing is done.

I will have multiple nodes. End goal is to:

  • Identify which pin on which node has detected an event
  • Be able to send an SMS to alert someone
  • Graph the hourly voltage readings.

I would appreciate any words from the wise to point me in the right direction. I’ve done plenty of reading but maybe I’m not getting my search terms right. I guess the first question is - How do I differentiate between the 3 byte vs 7 byte payloads? If I consolidate all the inputs into a single byte then the same question applies I believe.

I would welcome any pointers, appreciating that it’s a slightly open ended request, but I don’t have enough feel yet for the architecture to ask specific stuff.

Thanks in advance. Some great answers in here. Hopefully I’ll be answering some soon.

2

I think the usual approach is to use different ports for the different message types, like use port 1 for the digital inputs and use port 2 for the hourly voltage readings.
You can’t use port 0, it’s reserved for MAC commands.

Be aware that LoRaWAN can be lossy, so it’s possible that you miss a message. And it would be annoying if that was the message that should have triggered an alert.

What you could do instead of sending a single bit right when an event occurs, is send a count of the number of events on a specific pin, so even if you missed a message, your backend code can tell that an event occurred later on because the event count changed.

Have a look at the payload of the TBMS100 motion detector, this device immediately sends a message when movement is detected. As long as movement keeps getting detected, it sends a another message every 10 minutes. If movement is no longer detected, it sends a message 5 mins after the last event. The payload has an event count. The payload also contains a minutes-since-last-movement field, so even if you missed the first message you can reconstruct the moment of the movement later.

1 Like
3

Thanks for that. Rather than consolidating the bytes I think I’ll have 1 bit for current status & use the other 7 bits for a rolling count to 128 of events, as you suggested.