Bruce,
On 13-04-13 07:20, Bruce Perens wrote: > Hm. How do you recover the clock, then? Especially if you have a test > signal that's all 0's or all 1's? Well, as it is implemented now (which is more-or-less a copy of the D-STAR modulator I took from Jonathan G4KLX software) is like this: (this is actually part of the talk I give on D-STAR and GMSK, I should really make a webcast out of this and put it on the net). - the bitrate of the GMSK stream is 4800 bps, audio sampling is done at 48000 ksamples / second. So, for every GMSK bit, 10 audio-samples are received. The question is this: "what audio-sample do you use to determine the value of a demodulated bit?" - What you want to achieve is this: See page 57 of http://villazeebries.krbonne.net/DSTARGMSK-OSB/OSB-voordracht-2.pdf, this is the dump of audio-samples as received by the gmsk-demodulation code from the radio, i.e. from the output of a "9k6" port of a FM receiver. The idea is to look for transitions from 0 to 1 or from 1 to 0. Then go 5 samples further and you should have either a positive or negative "maximum". That value will determine the demodulated bit. If no transition is found, just look 10 samples after the previous maximum. The process -as coded by Jonathan- uses a software PLL-circuit. It works on in slightly different way: - You have a counter "c" that goes from 0 to 99, in steps of 10. (so wrapping around at 100). This counter is the "timebase": 0 to 99 in steps of 10 is the equivalent to 10 samples. (*) The goal is to have the timebase to go from one "maximum" to another. Look at the slide on 57 of the PDF. Every "dot" on the line on the graph is a audio-sample (as taken from the FM demodulator output). What we want to have is that "c" will be 0 at one "maximum", go up to 90 (one sample before the next maximum) and then wrap around to 0 again at the next sample (which is the next maximum). This is done like this: As indicated, 0 to 100 in steps of 10 are the 10 audio-samples between each maximum. If the GMSK bit that is received changes, this is seen as a change of the voltage on the FM demodulator, and -in our case- a change in the sign of the audio-samples. In theory, this happens in the middle between two maxima, so when the value of "c" is equal to 50 (halfway between 0 and 99), or that's what we want it to have. So, we have a very simple rule: if the value of the input audio sample changes sign (i.e. in the middle between two maximum of different sign), we change the value of "c". -> If "c" is more then 50, we decrease it with 1, shifting the timebase slightly back -> if "c" if less then 50, we increase it with 1, shihfting the timebase slightly forward. That way, we try to keep the timebase intween two maxima, applying a correction if needed every time a received bit changes. If two concequative bits are equal, there is no correction mechanism and everything depends on the stability of the clocks in the computer and audio-dongle. However, it is not that because you receive a bitpattern of -say- 16 bits of equal value, that the clock will completely be lost. To drive up the number of bitchanges, scrambling is applied on the stream. c2gmsk has 16 scrambling-patterns (per 40 ms block) that are applied in round-robin order. Also, there is also a mechanism in the modem that tries to detect bitshift in the stream using the sync-patterns that do are present in the stream. The current implentation should be able to detect and correct up to two bitshifts per 40 ms audio-block (i.e. 192 bits). (*) see function "demodulate" in file "a_dspstuff.h" of the GMSK api package. Do note that the code uses other values: the counter goes up from 0 to 3200, in steps of 320. The "correction-value" is 10. > NRZI without bit-stuffing would improve the low frequency issue over > mapping 1 and 0 directly to the + and - shift, and would not cost any > bits. It would still have a problem if for some reason there was a > long run of 1's or 0's, but we typically won't have that with the > codec+FEC. It's easy to try. There already is quite some randomisation of the stream due to the scrambling-patterns, but it surely is something we try out. I think we can apply this quite easy in the API and then run this throu (say) gnuradio for analysis. > Thanks > Bruce 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
