Just my two cents worth to hopefully further constructively frame the
discussion...
It seems that there are three broad types of approaches to a would-be
real-world Codec2 implementation:
1) PC/laptop/tablet/smartphone (let's just call this PC for simplicity)
2) SDR
3) embedded hardware
Regardless of which choice, the following building blocks are needed:
a) suitable "glue" to connect to the radio set
b) suitable "glue" to connect to the user's headset/handset of choice
c) modulation and FEC scheme
d) implementation-specific optimization of the Codec2 algorithm
On item (a), there are a plethora of different variations of
interfaces between manufacturers and models. Some radio sets have a
9k6 port; others only have a headset port. Even with a headset port,
there are a myriad of different pinouts, microphone types (dynamic
v.s. electret), microphone sensitivities, audio bandwidths, etc., etc.
Item (b) is linked to item (a). There are a myriad of different
pinouts, microphone types (dynamic v.s. electret), microphone
sensitivities, etc., etc. There has to be a catalog of adapters to
connect Brand X headset to Brand Y radio set.
Item (c) is a development effort in itself. A lot of previous work
exists for various packet radio implementations, although these are
not necessarily tuned for a real-time digital audio link.
Item (d) is at the mercy of development milestones of the Codec2
algorithm and Item (c). (An optimized implementation of Codec2 may
only work on brand A CPU, and for said implementation there may be
enough residual CPU time for modulation scheme X but not Y.)
For a PC-based approach:
This approach has the advantage that there are already a cornucopia of
products to provide soundcard or USB connectivity to a radio set to
address item (a). (However, some of these items will not work as well
on, say, a tablet or smartphone, as these may have been artificially
locked out by the manufacturer.)
Addressing item (b), although possibility inferior to a "proper" ham
headset/handset, there are an even greater variety of microphone +
speaker products for the PC world (including ones built-in to the PC
itself).
On items (c) and (d), the PC has an excess of CPU power and the
easiest path to development. This makes it possible to iterate
repeatedly to refine and experiment on item (c) and not even worry
about trying to expend effort on the optimization. (Tablet/smartphone
devices may also have less CPU power than their PC/laptop relatives.)
For a SDR-based approach:
Item (a) because irrelevant, as the SDR *is* the radio.
Since most SDR approaches involve a PC, item (b) can be addressed the
same as with a PC. The SDR may also have a native headset interface,
and development costs would be amortized over the entire market of the
SDR platform, rather than just pioneering Codec2 users.
Depending on the specifics of the SDR implementation, the modulation
and FEC may be done more in the PC or in dedicated hardware. If the
former, the same advantages of the PC on Item (c) apply to SDR.
SDR potentially offers a major advantage over a PC-based solution in
that the SDR is the radio. (I'm presuming that a PC-based solution is
more of an "in-band" solution that is usurping the normal headset
audio for a modulated alternative.) An SDR approach, however, could
directly modulate at baseband/IF, potentially allowing more modulation
options.
Similarly, if the Codec2 implementation is done in a host PC, the same
advantages of the PC on Item (d) apply to SDR.
A disadvantage to SDR is that the equipment costs are likely much,
much higher. It is at least equivalent to buying a whole additional
radio, which potentially alienates many would-be users.
For an embedded approach:
The long-term advantage of this approach is that it offers the
greatest cost-reduction, portability, and battery life.
However, this is predicated on a decidedly non-trivial amount of
development (loosely equivalent to that invested by a commercial radio
developer).
Items (a) and (b) must be largely developed from scratch, and one must
either pick a subset of interface standard to support in order to
simplify implementation (but risk alienating huge swathes of users
that own Brand Z, etc.) or try to take on the Herculean task of
designing and build a jack of all the trades solution.
Items (c) and (d) are not any easier. As has already been heavily
discussed on the mailing list, these are items still in flux and need
of experimentation to optimize. (Furthermore, a modulation approach
that might work well at one frequency range and bandwidth might be
highly unsuitable for another, causing further fragmentation of
effort.)
One variant of the embedded approach would be to convince the
developer of an existing AMBE product to modify it to use a near
plug-in Codec2 replacement to the existing AMBE chip. With such a
variation, one would inherit all the development effort to address
items (a) through (d). The cost of entry is still high (a product
revision), but not nearly as high as trying to do all of this from
scratch. However, the Innovator's Dilemma applies: what incentive
exists for an established manufacturer to introduce a new incompatible
product that might alienate existing users (and IC suppliers)?
On Tue, Nov 29, 2011 at 1:28 PM, Bruce Perens <bruce@...> wrote:
|