Like a frequency hopper (FHSS) you want it to hit all the tones, and
not send CW.
I haven't examined the codec 2 vocoder bits when no audio is input.
I'm assuming it cycles through all four tones.
I can see where telemetry data would need a scrambler though.
On Fri, Jun 15, 2018 at 12:38 AM Mark
The current version of the Horus Binary modem using both a scrambler and an
interleaver.
Without the scrambler you can end up with long runs of zeros depending on
the payload contents. Maybe it doesn't affect the modem, but it sure
doesn't sound right!
73
Mark VK5QI
On Fri, Jun 15, 2018 at
We've used this FSK modem quite a lot for balloon telemetry and have
wondered from time to time if we need scrambler. So far we have never
found "the smoking gun" which would be the timing estimator falling over.
Having said that I think we may have included a scrambler in one version
of the
On Thu, Jun 14, 2018 at 12:14 AM David Rowe wrote:
>
> Just want to point out that, last time I tested them, the 4FSK waveforms
> work just fine - unmodified and without a scrambler.
It was just a what-if that was suggested as an experiment. I'm over it now.
On Thu, Jun 14, 2018 at 12:14 AM David Rowe wrote:
> This suggests a porting issue to me. Steve - happy to work with you on
> a series of unit tests to take us from x86 FreeDV API cmd line test
> programs to working code on the stm32. It is possible there is some
> corner case that we are
Hi,
Just want to point out that, last time I tested them, the 4FSK waveforms
(FreeDV 2400A, and 800XA) work just fine - unmodified and without a
scrambler.
800XA is being used by people over the air - in fact I'm working with
some UK Hams on exciting high power experiments using simple and
The simplist explanation for this is that if there was only one tone
present (out of the four) , IE in the extreme case, the input to the
modulator was stuck on one symbol value, there demodulator would not
know what tone that was with respect to any of the others, not be able
to derive any
Yes. You can't see it on the FreeDV spectrum display, as that display is
filtered and averaging. But I'm sure an oscillator or two disappears.
This particular scrambler resets itself every frame. It has a starting bit
pattern. So every modem frame starts-off with the same value, and is only
64
The simplist explanation for this is that if there was only one tone
present (out of the four) , IE in the extreme case, the input to the
modulator was stuck on one symbol value, there demodulator would not
know what tone that was with respect to any of the others, not be able
to derive any
I never gave much thought to the raw vocoder bits, so it was an
interesting development.
On Wed, Jun 13, 2018 at 10:27 PM Bruce Perens wrote:
>
> Probably anything that avoids long streams one symbol is going to help here.
Probably anything that avoids long streams one symbol is going to help here.
On Wed, Jun 13, 2018 at 8:20 PM, Steve wrote:
> I played around a bit with the bit scrambler, first to make sure it
> was a two-way function, and then by running the sm1000 scrambled
> result into FreeDV on my x86.
>
>
I played around a bit with the bit scrambler, first to make sure it
was a two-way function, and then by running the sm1000 scrambled
result into FreeDV on my x86.
Without the scrambler, after I was done talking, the frequency error
would waver around +/- and then slide off almost -600 Hz. The SNR
I used a bit version of the horus byte scrambler, and got this:
[image: 4fsk-scrambled.png]
/**
* In-Place 15 bit additive scrambler with 0x4a80 Frame Sync
*
* Sync1 0 0 1 0 1 0 1 0 0 0 0 0 0 0
*
Thanks Adrian,
It wouldn't be compatible, but I am interested in that idea. I'm going
to whip one up and see what it does.
Thanks
On Wed, Jun 13, 2018 at 4:02 PM Adrian Musceac wrote:
>
> Hi Steve,
> You could try scrambling the output of the vocoder. I use a scrambler
> block from GNU radio
>
> By the way those views are via the freedv spectrum display.
>
> What I was thinking was the random numbers are of course hitting all
> the tones equally, whereas the vocoder bits are not as pure, and may
> in fact favor bit combinations over another. Maybe a sequence of the
> same bit
Thanks David,
I wasn't too concerned, except playing into Freedv the modem seems to
lose sync, and the SNR drops away.
I'm also not getting a very loud decoded voice, and if I raise the
SM1000 gain pot it becomes distorted. I might need to test
more on the x86 as you suggest.
Thanks!
the spectrum looks as I would expect.
are your random numbers uniformly distributed ?
I dont know how the spectrum display is generated in the freeDV IE if it
is just taking slabs of samples with some arbritrary FFT boundary, or it
is aligned to the symbol clocks etc. or how many grabs are
Thanks Glen,
By the way those views are via the freedv spectrum display.
What I was thinking was the random numbers are of course hitting all
the tones equally, whereas the vocoder bits are not as pure, and may
in fact favor bit combinations over another. Maybe a sequence of the
same bit
Hi Steve,
I wouldn't be too concerned, spectrums move in mysterious ways.
Couple of ideas:
1/ Try the same test on an x86
2/ Measure the BER of the transmitted signal with calibrated noise,
that's the ultimate test of any modem.
Cheers,
David
On 14/06/18 05:57, Steve wrote:
In modulating
Hi STeve
With all modulation schemes the components are never single spectral
lines, as of course the tones are modulated and thus the modulation will
show depending how the spectrum analysis is captured.
You are right it is a dirty process switching from one to another.
However it is a
In modulating the 4FSK using a random number (rand() % 4) I get this
spectrum:
[image: 4fsk-rand.png]
Looks good. Now if I modulate it with the vocoder bits instead:
[image: 4fsk-voice.png]
Well, isn't that special. I have no idea where those harmonics comes from,
but there is always a pip
21 matches
Mail list logo
