Ok! I guess you have got it. I was just clarifying so we all were on the same page. Hope you weren’t insulted.

Every reply is appreciated, every reply is helpful in a different way. Collectedly with all the replies, it usually lead to a solution one way or the other. This is a great community because of you guys!

 

06 ASCII encoded would be two bytes:
0x30
0x36

You can reduce the number of bytes by a factor of 2 by sending straight binary, e.g. 0x06.

He has said several times that he can't. He has NO control over the comm channel protocol, which accepts only the ASCII codes for the 16 hex characters plus two specific control codes (SOF, and EOF). If he sends anything else to the comm module, it will simply ignore it.

 

The first byte are sub group of the device, there are other devices on the same channel as well. I forgot that myself when I first try using smaz lib.

So the SUB needs to stay.

I think I will combine 2 - 3 raw bytes by lookup table, take away one or two raw byte that doesn't need to send that often. it should solve my problem.

So for the fields that you want to combine, how many possible allowed combinations are there? You will need ceiling(log_2(N)/4) characters for N combinations. So you really need to take the time to determine how many possible combinations there are.

 

Hi team

Just wondering if a way to compress short string, something like these:


I am running out of bandwidth... some data are missing... and I don't have control over buffer size / speed of the communication channel.

I have tried this: https://github.com/antirez/smaz, and my string actually enlarge by 7%

You seem to have a very constrained comms channel. May I ask why the channel is so restricted?

 

You seem to have a very constrained comms channel. May I ask why the channel is so restricted?

It's a system designed by an engineer many many years ago. Maybe between 15 - 20 years. It's still been used, and it's reliable. I personally think the design is brilliance (at the time).

1. It's low cost, all the device interface with it just need 2 transistor and a low cost MCU with pin interrupt
2. Multiple master, priority is build into the physical level, similar to CAN bus (dominant bit and recessive bit stuff)
3. Low baud rate is properly limited by the bus distance required at the time.

 

Ok, that makes good sense. I take it you have timing requirements you need to meet.

 

Ok, that makes good sense. I take it you have timing requirements you need to meet.

Yes, if you are referring to the packets, they need to be "real time" relative to the system.

 

I wish I could help but if you are collecting unpredictable data I can't see how you get around the problem. No chance of tokenising any of it?

 

I wish I could help but if you are collecting unpredictable data I can't see how you get around the problem. No chance of tokenising any of it?

No, can't tokenizing any of it. It's a multiple masters bus, they all send unpredictable data. But I think I have a solution now, there are a couple bytes that are not "real time", so I can take them out. And as other members suggested, I can work out the maximum possible combination I actually need, and pack all the bits together.

I should be able to reduce about 5-6 bytes, I just need to do the actual work to make it happen now

 

No, can't tokenizing any of it. It's a multiple masters bus, they all send unpredictable data. But I think I have a solution now, there are a couple bytes that are not "real time", so I can take them out. And as other members suggested, I can work out the maximum possible combination I actually need, and pack all the bits together.

I should be able to reduce about 5-6 bytes, I just need to do the actual work to make it happen now

That's good news. I hope it goes well.