Hi all, As expected (but always nice to see in practice) 6000bps with scrambler instead of bit stuffing results in a near identical BER curve. (Just small deviations up and down as can be expected from inserting random noise) So now we have 5400bps available for voice. Or a little bit more for data if a suitable codec choice needs less. I also reworked the transmit part a bit to use a raised cosine spectrum. Since the receiver is already filtering at 3kHz it has no impact on the BER as simulated. But in a real world scenario it allows more transmit power to go in the part of the spectrum that is actually usefull and the higher frequencies also don't have any chance to mess things up later. spectrum
73s, Jeroen On 04/12/2020 11:32 PM, Steve wrote: > Hello David, > > I see it as an alternative to bit stuffing. Both are methods designed > to improve the demodulation. > > I think the HDLC AFSK was standard for 1200 but it seems every higher > bit rate went with a scrambler. Maybe since they were already high > bandwidth for the channel, it reduced co-channel interference. This > particular scrambler has a minimum complexity, and designed for frames > of data. > > I think that BER shouldn't be worse, but the spectrum power should be > more uniform. No beeps and squawks. It sounds like white noise. If you > listen to the original modem audio it has a beat to it, where the > scrambled does not. > > The Sync symbols will have to be sent unscrambled obviously. > > FM isn't designed for long range anyway, it is a wide-band mode > much like AM with double side-bands, converting the 6 kbps into 20 kHz > for transmission. If it's not full quieting, you are probably going to > need more power, which is cheap at class-C. > > Steve > > On Sun, Apr 12, 2020 at 3:14 PM David Rowe <[email protected] > <mailto:[email protected]>> wrote: > > Hi Steve and Jeroen, > > I was wondering why you wanted to use a scrambler? > > I understand the main reason is making the synchronisation algorithms > work better. For example if your data source is all 1's, the timing > estimator can't work out where each bit stops and starts. > > Anyhoo, if it does make a difference in your application, you'll > see it > in the BER results. > > Thanks, > David > > > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
