I love the concept - I've been working on something similar myself using an MMDVM (with custom programming) and a pair of Icom mobile transceivers. My only com

I love the concept - I've been working on something similar myself using an MMDVM (with custom programming) and a pair of Icom mobile transceivers. My only comments from reading the protocol spec -- and I need to emphasize, this is one British ham's opinion and is worth precisely what you paid for it, i.e. nowt :) - Data whitening is a great addition. Too few ham protocols use this, and as a result it's a pain to find suitable transceivers (other than ham-spec ones) for them on the used market. - Forward error correction scheme looks a bit weak. Nice compared to most ham protocols though (which sometimes just have a CRC). The main thing is, if you get a burst error which straddles two blocks, you lose block N's CRC and block N+1's first few data bytes -- which would be uncorrectable. - It'd be nice to see some narrowband modes, maybe 8Kbps in a 12k5 narrow channel or 16Kbps in a 25kHz channel. With 45kHz deviation 360kbps 4GMSK (Mode 22), you're looking at 270kHz bandwidth. That's pretty darn wide! So wide, in fact, it wouldn't be reasonably usable in the UK if you wanted to adhere to the RSGB Bandplan. I think it should be possible to get some pretty big improvements in error correction by using a better error-correction code (POCSAG's (31,21)BCH code would be a good starting point) and employing bitwise interleaving. The idea is -- you'd add the error correction first, then interleave the bits. This means that when you deinterleave things at the other end, any burst errors will become single-bit errors in multiple codewords. Single-bit errors are much easier to fix than bursts! 8:1 interleaving with POCSAG's error-correction scheme would give a 21-byte packet size inside a 32-byte transmitted block (giving ~67% efficiency or ~33% overhead). It'd be able to correct up to a 16-bit error burst thanks to (31,21)BCH's ability to correct 2 erroneous bits. This is, actually the same method used by the FLEX-TD paging protocol (documented in ARIB standard RCR STD-43) :) 73's, de M0OFX :) EDIT: Forgot to show my working, oops! The GFSK occupied bandwidth formula I used was from here: https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2015/02/17/calculation_of_theo-S9wI https://www.silabs.com/community/wireless/proprietary/knowle... (bear in mind GMSK is GFSK with the requirement that the modulation be phase-synchronous, i.e. data changes only occur when the IF/RF is at zero phase) I just calculated the OBW of Mode 24 (4GMSK 500ksym/sec). 750kHz! That'd be 30 of the 25kHz Digital Comms channels... yikes. I'd expect complaints from local hams about the QRM.