Hi Rick and everybody else.
First of all, thanks for the feedback. On 01-09-12 15:17, Rick Muething wrote: > Yes, Of course there are block codes and convolutional codes. > > Convolutional codes have a memory that is equal in length to the code > length. e.g a K=7 rate 1/2 code (NASA Voyager) has a length of 7 so each > data bit affects the current codec output and the next 6 bits. In practice > this means that you need to supply 6 "flush" bits and send an additional 6 > bits (or use some other tail biting scheme) to get full effectiveness of the > Viterbi (most likely hood) decoder. That can be additional overhead but > sometimes can be "burried" in the leader or inter frame gap so it has > minimal effect. OK, that means that convolutional coding only makes sence for big frames (like the header of a DV-stream); but not the voice itself (especially concidering the small size of a 1400 bps stream). > Very often when the most powerful FEC is desired it is done in layers with > different (complementary) codes. E.g. Viterbi inside code surrounded by a > block code (e.g. Reed Solomon). These can be very effective in some > channels. Modern HF data modes (e.g Pactor 2, 3, 4, WINMOR) often use > layered convolutional and block codes for maximum efficiency and > performance. OK, I understand. But my part in this is the c2_gmsk modem: gmsk-based VHF / UHF. Let's find the best FEC system (patent-free) using todays technologies; but let's not exagerate in this. We are still talking about VHF/UHF!!! My idea was this: - convolutional coding for the header. We are working on a revision of the header which would give still have some additional spare place at the end of the header that is unused. So we can perhaps uses these bits to use a more effective convolutional coding sceme. (I guess higher convolution coding length means a better coding). Do keep in mind that the header is only send once, so I do not know if it makes sence to develop a hyper-complicated sceme just for that. - Voice is normally 56 bits / 50 ms; so block coding is best suited here. As explained, my interest would be three FEC rates: 1/3, 1/2 and 2/3 These rates would be dynamic, depending on the available total bandwidht (4800 bps, 3600 bps or 2400 bps) and the need to transport data alongside the voice communication. - In addition, I would also like to use FEC or FEC-like features for some markers in the stream. (e.g. for the syncronisation patterns to distinguish between the different FEC rates). These sync patterns are now just 24 bit markers without any special meaning; so why not convert it to a 12 bit pattern + a 1/2 FEC. Now, appart from VHF and UHF, I am interested in making the system work well on the lower VHF bands (10 meter, 6 meter, 4 meter; perhaps 12 meter); but for normal "VHF" near line-of-sight propogation. OK, we know that some of these bands can have some nice DX opportunities so it would be nice to be able to support that too; but let's not exagurate here. This is still a VHF/UHF modem. There already is a "hf-modem" in development for codec2 too!!! To deal with the DX propogation on the VHF-low bands, I would limit myself to the 1/3 FEC option (which is already pretty high) and an option to increase the interleaving. (which would then also increase the delay; but as this is only for "DXing", that might be less of an issue. > But this whole coding and FEC thing has to be evaluated using the following: > 1) What is the nature of the channel we are trying to code for. E.g. WGN on > VHF/UHF or poor multipath on HF. Deep fading, burst errors etc. As mentioned above: VHF + UHF; also VHF low; limited support for VHF-low DX. > 2) What is the information content of the source. This is complicated using > CODEC2 since some bits may be more "important" than others (not usually the > case with text) Dave has done a good job of squeezing down the bits so it > may be a reasonable approximation that they are all now of "equal" > importance. That's one of the reasons I like the (128,64) BCH that was mentioned by Robert in an earlier email. If you would stick a 56 frame in a 64 bits frame; you actually have 8 bits that can be used to create additional protection for certain bits in the DV frame (e.g. using a simple hamming code). The BCH coding would then sit on top of that to protect the whole 64 bit structure. And this sceme would probably even fit inside both the 3600 and 4800 bps modem. Of course, if a simular code can be created using LDPC, that's OK for me!!! > 73, > Rick Muething, KN6KB 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
