Hi David I think whether one can do better than FM in the real world 100% depends on exactly how you compare apples for apples. This is common mistake. (not really a mistake, but not right) . For people comparing digital to analog for 30dB SNR, well digital will win every time. But if comparing for analog = 12dB SNR, analog will often win over commerical deployed technologies.
Timing estimators and multiple modems it what I use these days. I'll estimate the clock and then run between 4 and 8 modem passes with different timing, and pick the one that gives the lowest error correction workload. Easy when you've got a 70K logic cell FPGA, but still possible on STM32-4, I think you need to come up with a clever way to run the demod sufficiently to decide what timing estimation is a decent candidate, and then run the other 90% of the modem... (rather than what I do which si run say 8 complete copies of the modem in parallel) . I think all DSTAR is incoherent, simple slicing (comparator) decoding. Quite awful and suboptimal. *** For a common FM radio, you have : 12dB octave high pass below 300Hz (corner at 330 Hz). flat to 500Hz 6dB per octave (roughly ) to 3kHz. (IE @ 1kHz you are 6dB up) . Then brick wall at 3kHz. The DC response will kill you trying to get GMSK without extra edge generation. Hence the OFDM modem does very well. For an FM radio adaptor, I'd encourage you to pursue a water filling technique. Maybe 125Hz bins 1st Bin start = 375Hz >> 625 Hz, 64QAM (18 bits) 750-1500 Hz = 16QAM (28 bits) 1625-3125 Hz = QPSK (24 bits) maybe....72 bits x 125 = 8750 bps Golly that's quite a bit ! Transmit a PN or chirp at frame start for channel equalisation. Does not have to be done very often as it is a BASEBAND equaliser, not a RF channel equialiser. The 64QAM and 16 QAM would enable a hierarchical approach for those constellations. How you would map the bits to the codec important bits, I have not thought about much. just ideas..... On 20/12/2014 1:32 PM, David Rowe wrote: > Hi Glen, > > I just played around with the timing (Toff variable) in gmsk.m. At the > 1% BER, Eb/No = 6dB point the demod BER hardly changes with +/-10% > timing error, and the BER doesn't double (1dB implementation loss) until > I plug in a timimg error of -30%, +20%. > > So I'd say we have a good shot at getting an ideal-performance timing > estimator running. That 1981 paper suggest looking at the difference > between the Re and Im arms, or we could even just try sampling at 10 > different timing offsets and look at some statistic like the eye > opening. I'm guessing that no raised root cosine filter makes life > easier than PSK. > > I wonder if phase estimation is hard for GMSK?. I'm not even sure what > DStar does for that, have to read the spec. There is some implied phase > information in that logic at the end of the coherent demod, IIRC the way > phases evolve can be modelled as OQPSK following some sort of state > machine. Only certain state changes are allowed. > > I think it might be worth pushing this simulation through to the point > where it can be tested over real VHF channels using stored files. We > could then try using a regular FM radio and an SDR and see what sort of > gain we can get over over FM. > > Not sure what to do about a transmitter ..... not sure if we can rely on > a FM modulator to generate GMSK accurately. Maybe a SSB radio using > upconverted stored files of GMSK? At 1200 bit/s that would be 1200 Hz > wide. However we couldn't reproduce FM That way using the same tx/rx. > > I like the name G-star! > > Cheers, > > David > > On 20/12/14 11:13, glen english wrote: >> Hi David >> 1- Any FM demodulated process. If it's post demod, there will be the >> threshold. >> that's right - no one cares about low CNR 'cause it is unusable. >> 2 - and you got to do carrier recovery very quickly for burst transmissions. >> 3- I think good speech quality if the system allows for it at the VHF is >> just as important as HF. Probably estimated SNR would be enough to >> decide to use the extra bits. >> It's a matter of coming up with a good scheme for codec2 to provide >> better quality with say 2 x the bits. >> 4- With a tighter rolloff, finding those clock spectral lines is always >> going to be more difficult than if there is , at the extreme, zero rolloff. >> >> For my G-star system which I am fiddling with for VHF, I have your >> codec2 @ 1000 bps , FM discriminator detection and block product turbo >> coding. You need to deal with the clicks and improve threshold >> performance for it to all be worthwhile, and the FEC satisfactory does that. >> >> I have not spent the time yet to sort your codec to provide 1) >> hierachical performance and b) unequal protection of certain bits (IE I >> have not spent the time to understand which bits are most important- >> except for the obvious which is the MSBs are always more important than >> the LSBs ! >> >> cheers >> >> >> On 20/12/2014 11:24 AM, David Rowe wrote: >>> Thanks Glan, I was hoping some one with a solid comms background would >>> take a look at those recent posts. Some questions: >>> >>> 1/ Re the post-FM scenario, do you mean using FM radios with through >>> their "data" (discriminator) port? Thanks, I had wondered what those >>> detectors look like a low CNRs. Clicks don't sound like much fun. >>> >>> That might be why the non-coherent demod I described first in the post >>> is popular - it works whenever the current FM radios do. So no one >>> notices the loss of low CNR modem performance. >>> >>> 2/ Thanks for the tip on low CNR clock recovery, not something I've had >>> to look at yet with MSK, although I've achieved good results with PSK >>> modems. (G)MSK is pretty close to OQPSK. I might try some clock >>> recovery simulations at low CNRs and see how we go. That 1981 paper had >>> near ideal results in their practical modem 30 years ago, so suspect it >>> can be done with a non-post FM (ie SDR) radio. We might need >>> differential detection for phase recovery, I haven't looked into that yet. >>> >>> 3/ Yep, the hierarchical scheme is what I'm currently looking at for HF, >>> in particular pushing the speech quality lower for poor channels. >>> Thinking the opposite for VHF. With plenty of bandwidth on VHF we can >>> just send a sub-carrier at say 6dB lower (even with GMS) for >>> supplementary info. It could have a simple checksum or we could >>> estimate SNR. >>> >>> 4/ What technical problem does MSK/RRC MSK make easier than GSMK? >>> Agreed we've got plenty of bandwidth. >>> >>> 5/ I'm thinking of a couple of modems. One that gets through standard >>> FM or data port radios, and a high perf SDR based mode. They could have >>> the same bit rate and protocol, and the rx could auto-detect the >>> waveform in use. >>> >>> Cheers, >>> >>> David >>> >>> On 20/12/14 10:04, glen english wrote: >>>> Hi David >>>> >>>> Good analysis. I think though there needs to be some clarifications >>>> (having done a few of these in my professional capacity) >>>> >>>> 1) 10dB over analog FM .?Not so fast ! I reckon 3dB worse at best. >>>> You'll need to clarify whether you are using a a post FM detected >>>> output, because the threshold effect will knock you over. >>>> >>>> 12dB SINAD wont occur much before 6dB CNR, depending on the limiter and >>>> demodulator characteristics.. The clicks will be numerous and this will >>>> knock out many bits, especially as you narrow the post detection >>>> bandwidth, the click length will cover more symbols. >>>> So the best you might do is on par with analog FM isf ising post >>>> detected output. >>>> >>>> My guess is it will be 3dB worse than 25kHz FM for the first 6dB, and >>>> then of course much much better. >>>> >>>> Even if you do demod pre the FM demod and limiter, clock recovery of >>>> GMSK for coherent detection, especially down in the noise is HARD. In my >>>> experience, this is the undoing. >>>> >>>> So GMSK is generally accepted as simple with a tradeoff. No free lunch. >>>> Most engnieers come to the same conclusion. YOu limit and FM demod, >>>> which is a simple receiver, you give away the low signal low CNR operation. >>>> >>>> HOWEVER ! >>>> We've got plenty of bandwidth,so why not just MSK, or RRC MSK ? There >>>> is no need to close the eye with the tight filter, we've got no need for >>>> narrow bandwidth >>>> >>>> That is unless you want to get it through a standard FM radio. >>>> >>>> I've long been a proponent (and in my private communicationss with you) >>>> I've always been in favour of a hierarchical codec and modulation. >>>> >>>> That is the lower bit rate codec is encoded and transmitted very robust, >>>> so when the goign is really tough, it still works. >>>> Bits that provide the codec more precision are transmitted in a layer >>>> that requires a higher SNR, and are used when available. I expect that >>>> because of the no FEC nature, there will need to be some sanity check >>>> on whether those higher order bits are useful. >>>> >>>> IE when the going is really tough, the quality is low but it works. >>>> But then the signals are good, the quality improves. >>>> This is the current advanatage of wideband FM (25kHz) over digital >>>> systems. For most digital systems, we get stuck with the LCD. >>>> >>>> But you are correct, the GMSK does not easily lend itself to >>>> hierarchical schemes. >>>> >>>> >>>> glen >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 20/12/2014 7:22 AM, David Rowe wrote: >>>>> This week I've been working on GMSK modem simulations: >>>>> >>>>> http://www.rowetel.com/blog/?p=3824 >>>>> >>>>> - David >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>>>> Get technology previously reserved for billion-dollar corporations, FREE >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Freetel-codec2 mailing list >>>>> Freetel-codec2@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>>>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> Freetel-codec2@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > -- - Glen English RF Communications and Electronics Engineer CORTEX RF & Pacific Media Technologies Pty Ltd ABN 40 075 532 008 PO Box 5231 Lyneham ACT 2602, Australia. au mobile : +61 (0)418 975077 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
