I think you're on to something here.
One quick thought that occurs to me is that for some of the gain, I see no reason forward error correction couldn't be used within the IP payload, at least for a few dB of gain (has this been tried?)
Both coding (e.g., FEC) and bandwidth expansion are common methods of improving code gain. Bit interleaving and FEC are routinely used in spread spectrum communications.
Of course, the FEC probably won't help the header information very much, but doesn't IP broadcast use a small set of broadcast IP addresses? Thus, it might be possible for payload-based FEC to know a-priori what will be in the header and basically correct for it. Then there's simply the matter of the reduced bandwidth due to the FEC, but it might be possible for that to look just like good old Ethernet shared-bandwidth-based conjestion (but I'm no IP guy so I could be talkin' out my arse here).
Right, both the header and equally important the burst header (which precedes any payload and synchronizes the SS HW correlator and clocks) will not be aided by FEC. Improved coding is generally more effective overall than increased bandwidth spreading, but unless the receiver HW can synch with the transmitted signal then coding cannot be an aid. So, in very noisy environments, where the statistical probability of channel noise corrupting the burst header is high, adding FEC may not be sufficient to enable reliable communications. However, FEC will almost certainly be easier than increasing the code length, which is tied to the HW correlator design.
steve
