Am 2011-11-29 18:16, schrieb Kristoff Bonne:
I'll try to get an overview of all the parts. Some suggetions and
observations where made, I'll try to collect them, please correct my if
I'm wrong. Maybe this should end up in an wiki, for better integration
of changed content.
Personally I do not think that there is _one_ right way construct a
transmission system for Codec2. Plug it into your Voip system, try it
with HF, VHF, UHF. Channels differ, requirements to delay, quality,
reliability, hardware cost/complexity/performance may be different.
Virtually no to users have the exactly same equipment and configuration
and expectations. So let's see what is possible and which requirements
seem to be common.
> Do do have a number of things missing:
> - choice of additional radio-technology elements (FEC, scrambling,
> interleaving, sync-recuperation, headerframe construction, futur
> options, ...)
Gerenal considerations:
Codec2 works in audio frames of 20ms. Speech communication is sensitive
to delay, so excessive delay should be avoided. Encoding and decoding
take some time (how much exactly?), all the coding/modulation and
decoding as well. In sum it should be less than several 100ms (300?),
and hardware like USB bus, DSP units, eat time as well.
20ms is 50 frames per second, which yields somthing like 2500/50=
bits/frame. Components that process more than that size in one
processing step inevitably introtudce delay. All components should be
considered to handle not more than one frame at a time, except if they
look back in time, like differential encoding. Or in other words,
components should not collect and wait for more than one frame.
There seem to be some suggestions for parts:
* modulation:
The modulation needs at least the bit rate which the selected codec
parametrisation produces. For simplicity, let's assume something in the
range of 2400-5000bit/s, sync/framing and FEC will eat enough.
Non-linear amplifiers are cheaper, not every modulation is robust
against non-linear processing.
+ frequency modulations:
- C4FM
- GMSK
- OFDM?
- SC-FDE?
+ phase modulation
- BPSK, QPSK like in FDMDV
+ amplitude modulation?
* Forward Error Correction (FEC)
Codes which need large blocks to work well introduce delay. FEC
greatly reduces bit error rate, which should easily pay off for the
increased bitrate needed for transmission. Some think that protecting
"important" bits of the frame better than "less important" bits would be
good. Any Idea to implement this?
FEC can be combined with modulation, like with trellis modulation. Less
important bits could go in the later steps of the trellis partitioning.
This has to be carefully coordinated with all blocks that change frame
contents like scrambling, interleaving, or other FEC.
Which FEC would be feasible? Complexity?
* Interleaving
Interleaving should spread possible burst error over the whole frame.
50bit is not that much, but it's worth 20ms. In 20ms an error burst of
5ms means 25% affected bits. Interleaving with more than one frame
introduces delay.
* Scrambling
Not sure how much scrambling would benefit. Would be helpfull for
spectrum whitening. Necessary?
* Framing
Some kind of extra structure to help synchronisation of frames, or
provide extra information about parameters like codec/version and
bitrate would be helpful.
> - a formal description of the protocols
Possible available radio protocolls/systems:
* D-Star
* FDMDV
* openDIGI
* unarDV v1, v2
> - test code and test hardware
> - analysis of actual results of people test-driving the software and
> hardware.:
> Has everbody even made tests codec2 responds to packetloss?
I think this should be packet loss and bit errors. In internet scenarios
one can rely on correct frames, but not on delivery. Jitter, that is out
of time frames, could be a problem, too. Buffering with reordering of
delayed frames introduces delay.
> How well
> does the FEC system work? Does the interleaving-system work well and can
> it be made better?
> - interoperability testing with other DV-users (read: "does it not crash
> D-STAR radios)
Which D-Star implementations could be used to try Codec2?
> - infrastructure software implementation (repeaters, reflectors, PC
> clients, ...)
VoIP systems that can be used with Codec2:
* ?
> - tests of actual "production ready" hardware for this (how much CPU
> power does a board need? Do we forsee additional CPUâ»power in be able to
> add new features later)
Which hardware is currently available for tests?
* Embedded boards:
+ STM32F407 ARM Cortex M4F
+ Panda board (anyone tried?)
* SoC for DV-Dongle like operation - blackbox that does Codec2
* Software radios:
+ USRP/GNU Radio
* Appliance Radios
+ D-Star
* PC
+ with soundcard
+ with modem/TNC
+ VoIP
> - programming APIs
> - and -most importantly- how do make sure the hardware sollution for
> this can be manufactored and sold in tens or hunders of thousands, not
> just a couple of hunderd now and then.
As said before, I do not think that there is _one_ incarnation of Codec2
that will take over the world. It's not like Codec2 is better than every
other codec, or that every thinkable telecommunication usecase would
benefit from Codec2[1]. Let's just see what works.
Regards
Patrick
[1] I think of HDTV with Codec2 audio. That would save bandwith, really! ;->
73 de Patrick
--
Engineers motto: cheap, good, fast: choose any two
QTH: JN77rb http://sat.mur.at/
Patrick Strasser OE6PSE <oe6pse at wirklich priv at>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
