BTW, besides using FM this waveform is also perfectly useable with a
simple double sideband modulator..

On 04/10/2020 10:58 PM, Jeroen Vreeken wrote:
> So here are some first BER experiments.
> I made a few small improvements to the demodulator (thanks to the
> measurements).
> But basicly it is still the same.
> I used the fm.m modulator and demodulator.
>
> ber
>
> The amount of measurement points is still a bit limited, and since I
> only use about 24seconds of audio data the numbers are not realy
> accurate as of 16dB (from then on the BER is 0, since there are around
> 1e+5 bits in the file that makes sense).
> Since fm.m introduces noise compared to the carrier this is not a true
> Eb/N0 value.
> If I am correct the defaults for fm.m limit the bandwidth to 16kHz so
> the Eb/N0 should be 4.2dB higher for a 6000 bps rate.
>
> A funny coincidence: shifting this plot 4.2 db more or less gives the
> same plot as David got for his Bell 202 simulation.
> Except ofcourse that this is 5 times more bits going through the same
> channel.
>
> ber ebn0
>
> I am going to do some more measurements: I want to see the effects of
> scrambling and I also want to try some different pulse shapes.
> The current shape is a raised cosine in the time domain, but a raised
> cosine in the frequency domain should allow a smaller bandwidth. Since
> the fm.m demodulator already cuts of most of the high frequencies it
> seems we don't really need them and not sending them would allow more
> energy to go into the usefull data.
> Btw, the article 'The Shape of Bits to Come'
> (https://www.qsl.net/n9zia/a108/index.html) was some great inspiration
> to me years ago when I was trying to decode cubesat data.
>
> 73,
> Jeroen
>
>
> On 04/08/2020 12:00 AM, David Rowe wrote:
>> This simulation:
>>
>>   https://github.com/drowe67/codec2/blob/master/octave/fsk.m
>>
>> Was used to compare non-coherent 2FSK to a AFSK over FM, it includes an
>> analog FM modem simulation fm.m (equivalent of a VCO/discrimator).  The
>> fm.m module has optional voice band filters.
>>
>> mancyfsk.m is similar, but with manchester encoder baseband signal,
>> which I think is similar to what is being used in this work.
>>
>> Reason I mention this is that the best way to compare the effect of any
>> signal processing step (like a scrambler) is to measure the bit error rate.
>>
>> Cheers,
>> David
>>
>> On 8/4/20 7:12 am, Jeroen Vreeken wrote:
>>> Indeed, I use the packet port of my ft-817, so the signal goes almost
>>> directly to the oscilator and almost directly from the discriminator.
>>> It might also work over the audio ports as the bandwidth might fit if
>>> the filters are not to tight.
>>> But then you would have to compensate for the pre/de-emphasis. I haven't
>>> tried that yet.
>>>
>>> The bit stuffing is indeed to make sure we don't go near DC, and to make
>>> sure there are enough 'flips' to recover the bit timing.
>>> The scrambler looks nice, but we would have to find a balance between
>>> lots of zeroes (easy to sync) and a perfect spectrum.
>>> I'll try some variants on the air soon.
>>> Also note that the frames generated with the test program are not
>>> varying much, a stream with real-world data might look different.  But
>>> the pictures you showed both don't look that bad...
>>>
>>>
>>> On 04/07/2020 11:24 PM, Steve wrote:
>>>> I believe it is just direct FSK of the FM oscillator. +/- some
>>>> deviation. Using the data port of most modern VHF radios.
>>>> So on receive you just slice the ratio detector (discriminator output).
>>>>
>>>> The bit-stuffing keeps from long runs of a high or low. My experiment
>>>> is to replace bit stuffing with a scrambler, but I haven't found all
>>>> the places to remove the bit-stuffing :-)
>>>>
>>>> On Tue, Apr 7, 2020 at 4:08 PM David Rowe <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>     Hi Steve,
>>>>
>>>>     >From what I understand (please feel free to correct me Jeroen)
>>>>     this is a
>>>>     baseband PAM waveform over analog FM.  I'm haven't seen any
>>>>     theoretical
>>>>     analysis of these schemes, but we did measure some a few years back:
>>>>
>>>>       http://www.rowetel.com/wordpress/?p=4663
>>>>
>>>>     Cheers,
>>>>     David
>>>>
>>>>     On 7/4/20 5:58 pm, Steve wrote:
>>>>     > What would be expected here? Say about 9.5 dB Eb/N0 at 10E-5? I
>>>>     think
>>>>     > that's what the G3RUH modem got.
>>>>     >
>>>>     > It will definitely fill up the channel! :-)
>>>>     >
>>>>     > On Tue, Apr 7, 2020 at 2:43 AM David Rowe <[email protected]
>>>>     <mailto:[email protected]>
>>>>     > <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>>>     >
>>>>     >     Steve and Jeroen - it would be interesting to measure the
>>>>     modem BER (or
>>>>     >     Packet Error Rate) performance.  Steve - we could use
>>>>     cohpsk_ch to
>>>>     >     inject measured amounts of noise.
>>>>     >
>>>>     >     Cheers,
>>>>     >     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
>>>
>> _______________________________________________
>> 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

_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to