robtillaart, unfortunately there is not a lot of room for compression here. The data sent mainly consists of an ID byte to identify the sensor the data is coming from and the data itself (byte or int). But thanks for the idea!
(I do not give up easily) How many sensors are there and how much do they send?
A type of compression can be that if you send the sensor data in a fixed order the ID's can be ommitted, something like an CSV file in which you have a header line and then only lines with data. => approx 50% reduction
HEAD: 1 2 3 4 5
DATA: 10 11 10 23 24
DATA: 10 11 11 23 12
DATA: 10 12 10 23 24
DATA: 10 11 11 24 20
For 2 or more bytes values one can consider relative coding iso absolute coding (two different ways)
ABS: 1000 1001 1003 1005 1009 1004 1002 998 995 1000 (20 bytes)
REL: 1000 (2 bytes ref) 1 3 5 9 4 2 -2 -5 0 (11 bytes) - deltas wrt reference value (value = refvalue + delta)
or
REL: 1000 (2 bytes ref) 1 2 2 4 -5 -2 -4 -3 5 (11 bytes) - deltas wrt previous value (value = prevvalue + delta)
The first one is preferred as it can handle missing bytes better than the second.
furthermore RunLengthEncoding can sometimes be interesting:
RAW: 100 100 100 100 100 100 100 100 100 100 105 106 106 106 106 106 106 (17 bytes)
RLE: 10x100 1x105 6x106 (6 bytes)
And maybe the most important question: Is all the data necessary?
I have seen apps that send data every second to the logserver only to been thrown away as the PC app analyzed per minute
Another way to get better compression is to "cook" (preprocess) sensor readings before sending them. Advantage can be high "compression" ratio's. Drawback is that you don't have the raw data anymore.
Finally you can do some minimal noisefiltering to make the RAW data better compressable.
RAW: 100 101 102 101 102 100 101 102 101 102 102 103 104 103 104 105 104 105 105 105
FILT: 100 100 102 102 102 100 100 102 102 102 102 102 104 104 104 104 104 104 104 104
(this filter keeps the old value as long as the new value = oldvalue +- 1. )
Rob