Hallo Patrick,
I'm sorry for the late reply. It's been a strange couple of weeks. Op 01-12-11 20:00, Patrick Strasser schreef: > 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. Good idea. > 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. I agree that people have different requirements, but -as some point- you need to have code to be able to experiment. The specs will then follow automatically. But a programmer does need at least a basis of specification on which to base herself. >> 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. I don't know. I would agree in the context of a full-duplex link (say an internet VOIP call) where delay is a major issue. If we limit ourselfs to ham Digital Voice, it will be half duplex communication. This means that delay is much less of an issue. If the user has audio coming out of her radio 100ms, 300 ms or 500 ms after the first signal actually comes in over FF is -in my opinion- not a real problem. Based on this fact, I think this does open some possibilities making the system more robust, even at the expense of some additional delay, llike interleaving over multiple frames. > 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? This will be one of the areas where there can be different technologies can be used on different bands. I would prefer to start with simple 4.8 Ksymbol/second gmsk as that is something that is well known in the ham world (software, hardware, ....) on VHF and UHF and for which hardened code is available. If we have that, we can start to experiment and work upwords from there on. One issue that is important is the S/N ratio that is needed for any system. It is quite tempting to use a 12.5 Khz channels to achieve higher bitrates, but this would require more transmission power and therefor reduce the range of the system. As far as I know, D-STAR has actually been limited to 6.25 Khz bandwidth; exactly to be able to provide as least a range equivalent to analog FM. That would also be a good target to aim for. If somebody, using a HT, can work a analog FM repeater with his portable but cannot do so with a digital system, we have a big problem. > 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? An interesting question. Does it merrit to use dynamic FEC? An "over" can be quite long (several minutes), the radio channel quality can vary a lot quite during that periode. Again, remember that this is a half-duplex link. Full duplex systems can continuesly feed back BER information to the sender (the mobile phone systems do) , but that's not an option for us. So, there are two options: - either we stick to a fixed FEC system for simplicity. - Or we make the specification more flexible and signal the FEC system that is used in the header. Do we do this per stream, per frame or per multiple of frames. I think we should -at this stage- not make the specification overly complex. Let's just start with just signaling the FEC-system of the stream in the header and that this would remain valid for the whole of the stream and only define one or a very limited number of FEC options. Also important in this that, if you make FEC dynamic, either you have to mandate one or a number of FEC systems by specification, or you have to provide a way for one side to signal the other side what FEC systems it supports (just like SIP includes a handshacking system to signal what codecs are supported by the receiver). > * Scrambling > Not sure how much scrambling would benefit. Would be helpfull for > spectrum whitening. Necessary? I don't know. In essence, scrambling is necessairy to avoid receivers losing syn when the sender is transmitting long repetitions of all-0 or all-1. During the normal speech process, that shouldn't happen as changing speech should normally result in quite a changing bitpattern. It depends on how certain pieces of audio (say silence, or when sending a DTMF tone) look like after being encoded in codec2 and FECencoded. . Anycase, as it doesn't really cost that much (just a couple of exor operations), why not? >> - a formal description of the protocols > Possible available radio protocolls/systems: > * D-Star > * FDMDV > * openDIGI > * unarDV v1, v2 I would prefer to stick to D-STAR as much as possible, so not to make the developers of the repeater and node-software can reuse their existing code as much as possible. >> 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? I think, very simple: stream it out of a local radio and tune a D-STAR radio to that frequency. In essence, I do not think this would be to difficult - change certain fields in the header (checksum, "voice/data" bit, "flag 3", invert order of callsign information, ... - change the "syncronisation" pattern (i.e. the pattern that is send every 21 frames) so that a radio that tunes in in the middle of a D-STAR stream is unable to "sync" to it. >> - 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?) I have a pandaboard (ARM cortex A9) and a friendlyarm mini2440 (ARM920T without FPU). Realtime encoding/decoding codec2 is possible on a pandaboard without to much issues. >> - 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. For this, the most important element in this is the license applied to the hardware design. If it is published as open source hardware (creative commons) WITHOUT the "NC" clause; this means that everybody can just take the design, contact some engineering company in China or whereever, and ask them to make a make a couple of hunderd / thousand units at very low prices. If you look at all current D-STAR hardware implementation out there, we always see the same thing: a very serious problem on the "supply" side of the equasion. One single ham, a small group or a small company that is by far not able to keep up with demand. Only big (commercial) manufactoring companies are able produce any product in the kind of quantities that are a real thread to i-com or D-STAR. And, yes, this means that commercial companies will make money from your work and your design. But does that matter? Commercial companies also make money from open source software. That's exactly the reason why they use it and why it has become so successfull. Almost any new embedded device you buy thesedays (routers, NAS, basestation, set-top-boxes, mediaplayers, internet-radio, VPN server, ...) runs on linux or some other FreeOS. In the linux world, they have a world for that: "world domination". Linux DID achieve this, simply by allowing commercial companies to make money from it. The arduino and its shields, the beagleboard and all the quadcopters are all examples off open source hardware following the same trend. > Regards > Patrick 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
