3 ms·
> Suppose that you can pack that info (sensor id, metric type and data) in 32 bytes I suppose you haven't worked with such constraints before, so that's why yo
by dmitrygr 4y ago
> Suppose that you can pack that info (sensor id, metric type and data) in 32 bytes
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
- vbezhenar 4y agoHow do you use variable-length encoding in a limited-length package? You either allow a situation where this variable-length encoding would not fit in a package and then it's not really clear what to do. Or you just saving bytes for nothing, because you could use fixed-length encoding instead and satellite does not care whether you sent 65 or 69 bytes of data.
- girvo 4y agoAt work we’ve been experimenting with what amounts to a pre-calculated/pre-shared dictionary to allow for compression of small data, but just picking what data you send and it’s representation gets you very very far. 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)