[hpsdr] The problem with digital modes

[Shirley Márquez Dúlcey]

>
> I agree that, in that case, we really could use better CODECs. Nearly
> everything we do in ham radio is based on narrow-band frequency-division
> multiplexing. We could certainly stand a bit more time-division
> multiplexing or, better still, frequency-hopping or CDMA spread-spectrum
> multiplexing. I'm not going to hold my breath tho'. That would ensure that
> the spectrum was used more efficiently.
>

A problem with trying to make that switch on HF is that such modes would be
incompatible with the existing users of the bands; you would have to set
aside a band segment for TDMA or spread spectrum use. (Spread spectrum that
used an entire HF band would raise the noise floor of the band and would be
considered undesirable by anybody trying to do weak signal work. FCC rules
don't allow spread spectrum on HF in any case, and nobody has yet proposed
making it legal.) We are seeing some experiments with TDMA on VHF and UHF
frequencies. DMR (and its gussied-up even more proprietary cousin,
MOTOTRBO) uses TDMA to put two voice channels into the space of one. But it
might be better to take an entire band segment and set it aside for
something that worked more like GSM or CDMA rather than intermixing DMR and
analog FM channels.

CDMA historically had the problem of patent encumbrance. Some of the
relevant patents expired recently and others will expire soon, so it may be
time for some new ham work on that mode. One catch is that the spreading
standard would have to be made widely available; otherwise it would
constitute an unauthorized cipher. It's also not clear how the ID
requirement could be met in a CDMA system.

I am not pleased by the proliferation of ham radio modes that use
proprietary technologies - things like PACTOR, or the various digital voice
modes that use the proprietary AMBE codec. The need for that codec spoils
the otherwise basically open DMR standard, and now that the free software
Codec2 is available there is no good reason for hams to be putting their
efforts there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20140512/55710c57/attachment-0003.htm>