A quick example, you have a sensor that sends a single metric every minute. Suppose that you can pack that info (sensor id, metric type and data) in 32 bytes. You're looking at about 1.2MB/month of data (8 times your 144K), which will come to about $40/month.
Quite expensive for a single data point, but I can imagine several use cases where that cost can be easily justified.
But I get your point, also you can always do a lot of things to save on bandwidth, like do not send info which is not interesting (i.e. no point in sending 100s of "no fire was detected" messages).
Btw, anyone here knows if there's compression schemes designed specifically for small data packets? Gzip and others would be overkill as headers vastly exceed payload size. Just using raw LZ77 may work but it's 2022 so there's probably a specific thing for that already.
Also, what about data that follows a specific format, like only integer numbers, it would be nice to have an algorithm that takes a "string" of 32-bit ints and gives you back a binary buffer with a smaller lossless representation of it.
Not sure there is any automatic solution for compression here. If you know your own use case you are in the best position to choose where to sacrifice accuracy with a lossy compression scheme. But this relies on understanding of the accuracy of the input data, possible ranges of values, importance of accuracy in different fields etc. Not sure how an automated algorithm could take these real world constraints into account.
A clever compression algo can't help you if you try compress 4 doubles, but in reality you only needed byte precision on some fixed 0-100% range.
Something like msgpack might be able to compress ints to some degree since it can represent them as smaller data types.
Zstd dictionary mode? At small sizes using a dictionary is generally the way to go.
I suppose you haven't worked with such constraints before, so that's why you think this needs 32 bytes. In reality, 4 or 6 will likely do.
Send diff in metric value if applicable, use variable-length encoding to not waste bytes. Allocate bits and not whole ints to things (like metric type). ID is already part of lower level protocol - the address, so you do not need it
Because we need to put nearly arbritrary data into our NB-IoT UDP socket, Inmarsat or Swarm, saving bytes let’s us pack more data into a message so we can send fewer messages: saving money and increasing reliability (because if you miss a Swarm upload time you can have hours before the next one, for example, or our Simcom modem might hit a black spot and such)
But it's associated with crypto so people hate it.
It also undercuts everything by a factor of 100x and is ubiquitous in US and western Europe.
PS: Saying LORA is "ubiquitous" in the US oversells it quite a bit. It is quite available in cities but most rural areas are completely devoid of coverage, see [2].
[1] https://cointelegraph.com/news/critique-on-helium-s-6-5k-mon...
[2] https://scwcontent.affino.com/AcuCustom/Sitename/DAM/031/Sen...
* you can buy helium hotspots for $100 now, on par with other lora gateways
* " vast majority of the income of the project" is vague and incorrect. The hotspot OEMs (of which there are 50+) receive sales revenue, not "the project".
* You're referencing a Senet chart, which is actually a roaming partner on Helium. This isn't actually a helium coverage map.
I will correct myself on the coverage, about 98% of Americans are covered, not 98% of land in America. Oops. America is a big place.
You get terminal identification from the carrier, no need to waste precious packet space on identifiers. And it's probably also a waste to encode field names into your packet - just record fields at the same offset every time. If 16 bits of precision is enough for you (it likely is) you can squeeze 16 metrics (or 16 time series recordings of the same metric) into every packet.
