Hi Robert,
Because it is a gmsk modem for VHF/UHF, not a multicarrier modem. :-) There are actually two modem-projects for codec2: one for HF based on the typical multicarrier modulation and one for VHF/UHF which is based on GMSK. GMSK is actually very simple: you just modulate a bittrain on a FM modulator. "1" -> +0.5 V, "0" -> -0.5V. Add some low-pass filters on transmit to reduce bandwidth and on receive to reduce noise and you have your modem that can pump 4800 bps over a FM channel of about 7 to 8 Khz wide. (if used on the 9k6 port of a transceiver). However, this does mean that syncronisation has to be done INSIDE the stream itself, by adding certain fixed patterns in the stream. The only trick is to find the patterns that work best for the requirements. 73 Kristoff - ON1ARF On 08-09-12 03:48, Robert Staton wrote: > If you have 96 bits of data, why not use 48 carriers? Then all bits are > transmitted simultaneously, and you know where the start is by way of the > pilot carrier. > > > On Sep 7, 2012, at 9:30 AM, Kristoff Bonne <[email protected]> wrote: > >> 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 > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
