I had a really brief glimpse into code which raised couple of questions:
* Do you have Forward Error Correction (FEC)? Maybe sacrificing bytes for FEC to reduce whole frame re-transmissions might be worth it?
* CPU time is cheap. How about trying multiple different compression algorithms (or parameters) to find the optimal for given data? Some things might compress differently (text vs. binary) or not compress at all.
@stephen And more:
* Can the Hostname in Packet be other than 8 bit ASCII? E.g. 5 bit Baudot (might be too short) or 6 bit code (e.g. BCD six-bit code). This might provide 6 byte saving (2x Hostname) with 5bit code or 4 byte savings with 6bit code.
@oh8hub This is a good idea - I'll look into it some more. All I really need is uppercase letters, numbers, and slashes. 5 bit would be slightly too short, but I could make it work with 6 bits.
@oh8hub No FEC, though I'm thinking of adding it. I mainly designed the protocol for VHF use, so I think it would be less useful since VHF is a lot more of an all-or-nothing frequency. (There's a pretty narrow window where some bits flip, but not a lot)
I'm not sure how much of a difference it would make to use difference types of compression, but I've been considering sending the data non-compressed if it's better(already-compressed files results in sending slightly more data otherwise)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!