Best way to split a large message

#1

I have a sensor, well 3 sensors that return 192 bytes. In most situations the average, max, min and a couple of other things will be sent however once in a while I will need to transmit the entire array.

If the signal is good this is not a problem because using SF7 and SF8 we can sent 222bytes but if the rate drops for whatever reason or if the unit is in a fringe area and the rate drops to SF10, FS11 or SF12 the transmission limits drop to 51 bytes.

Do i need to then assemble each part packet then do a LoRaWAN.send();?

Or is there a better way to handle this?

Is there a way to check what DR is being used prior to sending a packet?

#2

Apologies, the comments and PR referred to below target the CubeCell AB02/s LoRaWan runtime only. There are a couple of minor changes that were not propagated to all regions, thus might be an issue for NON US915 regions.

RE: get current data rate
A set data rate API was recently introduced, but not a get API.

LoRaWAN.setDataRateForNoADR(rate);

I believe there are some issues with setting data rate dynamically, especially if you are subject to Adaptive Data Rate.

There is a pull request pending that attempts to resolve some of this (set/get of data rate) along with a couple of other error path issues. At this point I don’t know that the PR code is implemented totally correctly or within the Heltec guidelines. ( My standard disclaimer of course)

You are welcome to give it a shot, but again it has not been approved nor condoned by Heltec.
Pull Request #142

As far as splitting the packet,I thought I heard from a webinar that SemTech “might” have some split/reassemble suggested code in a repo somewhere but did not take note of it. When the video recording is released in a few days I’ll comment back here if there is something of interest.
(edit) They might have been referring to over the air update https://github.com/ARMmbed/mbed-lorawan-update-client
Which is way over kill for what you need.

#3

Thank you @leroyle I will check out the update and give that a try. I am kind of stuck with the AR as we dont know where the units will end up or what the enviroment is like. I may see about just dropping it to the lowest rate or maybe using AR until it gets a connection then fix it to that.

I think you are right, that is total overkill but may be able to find some ideas in amongst that code.

#4

Which Sensor returns 192 bytes?

When each Sensor returns 10 values a 4 Byte you have 40 Bytes to transmit.

I think you can compress the data.

Greetings

E_T

#5

@ernst.schulz
We have an array of 3 Panasonic Grid Eye sensors bound together in an 8 X 24 block.
Each pixel outputs a temperature range between -20 ~ +100 (14bit) values. I have reduced the resolution so we only get 8bit’s per sensor 0 ~ 255 rather than use the real temperature data.

#6

Ok i understand!

  1. Is it necessary to transfer all the data or is it sufficient to transfer the result of an evaluation (Human detection)?

  2. Another solution would be to use data compression on the 64 values.

E_T

#7

@ernst.schulz

Thankfully the full data set is not required to be sent all the time and notmal opperation is just the agrogated heat values. The only time the full data set is required is during the installation in order to check the coverage area and display it on a heat map and if the temperature in a specific area has exceeded the set trigger levels for those zones.

I will have a look at a couple of compression options however last time I tried one out when we built a string of 200+ DS18B20’s we did not see much saving and is still was not able to get down to the 51byte limit for the Iridium communications.

B

#8

Hey just throwing out more ways of coping with this, since it’s a fun problem:

  1. Send the baseline once per time period (day?), then send deltas. Even an XOR (current vs baseline) and then do simple RLE compression on that would help, although the worst case might still blow the limit.
  2. Constrain the range of the sensors (so still have full precision, but scale it so 0-255 means a 25.0 degree range, or some such). Actually you’ve done that, but you could go further/variable bit length. byte alignment is easy but inefficient. How much accuracy do you really need? (this is rhetorical :slight_smile:
  3. Send the sensor readings in three messages, possibly w/different ports since that’s a “free” indicator (get’s sent anyway). You can read them all at once (so same time domain) and send them sequentially with a bit more work on the cubecell side. Some failure modes of not getting all the messages in a set start to appear though.
  4. Filter the zero/irrelevant values, at the cost of a tag to describe which values you’re sending. I don’t know the application of the temperatures you’re sending but hey it’s an idea. You could send a bitmap of the values you’re sending, for example.
  5. Use larger pixels, aggregate max or mean values of adjacent pixels together e.g. do you need the full resolution or just the field of view?
  6. Anyone else? There must be more embedded techniques applicable here.
1 Like