Hi all,
One of the parts of the specifications for c2_gmsk; the VHF/UHF gmsk modem for codec2; are "sync-markers", codes that are inserted into the stream for ... euh ... syncronisation. Looking at how we want to go into the future for the codec; we are looking at reviewing the current "pre-draft" that we have now and that has been implemented in the current version of the modem. For that, we would need some help of the list. First some background information: - In the current specification, the gmsk modem is based on the following structure. -> a "segment": 24 bits. -> a "block": 4 segments: 96 bits; equivalent to 20 ms (@4800 bps) -> a "frame": a number of blocks combined to make one functional blocks. - Currently, the following frames have been specified: -> a header (5 blocks) -> a voice-frame (2 blocks): 40 ms of audio (1400 bps, FEC 1/3) The first segment of every block contains the syncronisation pattern: a fixed 24 bit pattern. - Currently, the sync-patterns are defined: -> header -> voice-frame -> end-of-stream -> repeated end-of-stream What is the function of the syncronisation patterns: - to be able to detect bitslips: where a bit has been inserted or removed in the received stream due to small differences in speed between the sender and receiver. Currently, a bitslip of 1 or 2 bits in either direction (i.e. bits removed or added) can be detected and corrected - to be able to have a receiver tune into a stream when the header has not been received (i.e. when it tunes into a stream in the middle of a QSO) - signal the "end-of-stream". Based on this, the requirements of the sync-pattern has been: - to be as random as possible. I.e., to have a bit-pattern that is unlickly to occur also in the middle of a stream. (this is to facilitatie requirement 2 (tune into an ongoing stream). For that reason, the sync-patterns now chosen have been generated by an online "random-number generator": https://qrng.anu.edu.au/RawBin.php The use of these random numbers has also resulted in codes that where also good for the "bit-slip" requirements. (i.e. that the codes are sufficiently different from the same pattern shifted 1 or 2 bits to the left or right). Now, looking into the future; we are looking at the possibility to really expand the number of sync-patterns. Currently, these are the patterns we have in mind: - header + extended header - voice FEC 1/3, voice FEC 1/2, voice FEC 2/3 + voice no FEC (adding data into the unused part of the frame) - raw data - end + repeated end If we add some room for extension, we can settle for 16 possible patterns. Because of the fact that these sync-patterns will determine how the rest of the frame will be processed; correct detection of these codes is an important element. So, what does this mean? We are looking for 16 codes, all 24 bits wide; with the following requirements - As different as possible: any combination of twp codes should have a hamming distance (number of bits that are different) as much as possible - be as random as possible: to have as less change as possible that it will also show up in the stream itself. This is for the "be able to tune into a ongoing stream" use Also note that there is always a 192 bit "scrambling" pattern (8 random patterns) that is applied to the voice frames; so it is usefull to also compair the sync pattern with these scrambling patterns. - bit as different as possible of itself, shifted one or two bits to the right or left: this is needed for detecting "bitslip" This means: have as less as possible repetition, all-1, all-O, "10" or "01" sequences. An additional requirement (althou probably much less important): - be as different as possible from the "shifted" versions of the other codes. (simular to requirement 1 above, but compairing the code with the "shifted" version of the other codes; "shifted" meaning one or two bits shifted to the left or right. Now, we can now go back to the random-number generator above and generate some numbers and check how well they all fit these criteria. But perhaps somebody has a better idea on how to tacke this problem. 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
