How to transfer the most information in a LoRaWan (EU868) Uplink message using only 1 byte in the payload?

End Devices (Nodes)
1

Has anyone come up with the cleverest way to cram information into a LoraWan EU868 Uplink payload of 1 byte by also using fPorts 1-223) and perhaps time-synchronization at the node for some sort of time-slot encoding of the data?

Im thinking 1 byte is 256 values x 223 fPort numbers = 57,088 values.

Then node sending timeslots, over 1 hr period, 00, 20, 30, 40, 50 mins past hr (5 slots)
and sub-minute: 00, 20, 40 seconds past the minute (3 sub-slots)
3x5 =15 time slots

(Yes jitter these transit times and distribute off-sets amongst nodes and traffic/SF plan nodes to reduce collisions and overloads at certain times).

Does that give me 15 x 57,088 = 856,320 values per hour with just a 1 byte payload?

P

2

You are aware of your legal airtime limits per device?

Suggest you search for ‘lorawan ttn airtime limits’ - not even sure the post is TTN related sorry

3

Hi jezd,
Thanks for your comment.

Yes, im aware of the TTN airtime limits;

According to the calculator here https://avbentem.github.io/airtime-calculator/ttn/eu868/1

An EU868 uplink of 1 byte, at SF7/125KHz, would allow for average of 27 messages per hour per node.

What I am proposing is 1 message per hour, per node. So I think it is pretty much within the requirement.

The basic ideas is to send this information:
Sensor ID 6,
Temp:25C,
Humidiy:40%,
Barometric pressure: 1015mb

We send one unconfirmed uplink message (at least 60 mins after the last, but only if any of the values have changed at the node sensors) and encoded it as follows:

Transmit time: UTC HR:20m:20s (+/-5 seconds) - this special time decodes as 1015-990 = 25/2 which is represented by the 25th 5mb value from UTC HR:00:00 (in steps of 20m and sub-steps of 20 seconds.

fPort 62: - 6 it our sensor ID, 2 is temp tens of degrees C
Payload:54 - 5 is ones of degrees C, 4 is humidity in tens percent.

Three data points in 1 LoraWan Byte per hour, per node.
P

P

1 Like
4

1 byte payloads don’t make a lot of sense.

If you do that, your airtime is overwhelmingly determined by the 13 bytes of protocol overhead. Eg, at SF-10 a 0-byte payload costs 289 ms, overwhelmingly consisting of overhead.

There is a funny artifact of the 4/5 coding however, in that you can put 1 payload byte in with the protocol headers and still be at 289 ms.

If you put two bytes in, your at 330 ms - seemingly doubling your capacity at 10% cost.

But due to the 4/5 coding groups, it actually turns out that you can send 6 bytes and still be at 330 ms - it’s only when you get to the 7th byte that you add another coding group and the airtime bumps up again.

Efficient packing within packets is useful, but you’re better off sending a 6 byte packet less frequently, than playing games to try to get in 1 byte especially if those games in any way increase the number of times you need to transmit.

(it does get a bit more complicated if MAC commands are crammed into the FOpts)

1 Like
5

It would allow for two bytes, so you’ve wasted half your potential.

I think the time slots idea is going to cause significant issues as the device would need a clock which doesn’t make for a very low power device.

No, using your maths, it gives you 1 value per hour which can be, time sync allowing, between 0 and 856,319.

6

Thanks, Interesting.
im really trying to find a best fit between Cayenne LPP and a custom payload. i need my data to be maximum 60 minutes old for my application.
I guess I will go for packed LPP and using FPorts for Sensor ID

7

Correct, 1 Value per hour, in that range.

8

That doesn’t make sense.

Put all of your readings in the same packet, so you only pay the overhead once.

Distinguish them by position in the packet, without any inserted metadata such as Cayene adds.

Distinguish one node from another via its LoRaWan identity

9

One of the worlds least efficient formats.

Plenty of other ideas for getting a payload small on various recent topics if you do a search.

Bit packing is good.

And as we have 7 bits available on the port, at worst that can be a mask to the contents of the payload.