Alternate idea: Direct sequence spread spectrum

[Stuart Longland]

Hi all,

Just a silly idea, but maybe one worth pursuing... I've been playing
around with an alternate approach using direct sequence spread spectrum.
Basically using a Barker-13 sequence as a chipping code.

This may or may not be feasible. I haven't checked to see how wide the
carrier is. Attached is a bit of a simulation I've knocked up, it uses
the 'communications' package available from Octave-forge. It seems to
achieve a 1% BER with a 3dB SNR -- apparently a level that's acceptable
for Codec2.

The constellation pattern is an utter mess, since this is a BPSK carrier
running at 18.2kbps -- a screaming pace for HF. It relies on the
autocorrelation of the barker-13 sequence to decode the individual bits.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[car...@gmail.com]

I love the idea of using a Barker-13 sequence! There's built-in redundancy (a slight processing gain), error-correction is inherent in the DSSS correlation, and any noise will get "despread" out.

What does the peak-average power ratio look like?

On Fri, Mar 1, 2013 at 11:34 AM, Stuart Longland <stu...@longlandclan.yi.org> wrote:

Hi all,

Just a silly idea, but maybe one worth pursuing... I've been playing
around with an alternate approach using direct sequence spread spectrum.
 Basically using a Barker-13 sequence as a chipping code.

 It seems to
achieve a 1% BER with a 3dB SNR -- apparently a level that's acceptable
for Codec2.

The constellation pattern is an utter mess, since this is a BPSK carrier
running at 18.2kbps -- a screaming pace for HF.  It relies on the
autocorrelation of the barker-13 sequence to decode the individual bits.

--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.
Visit this group at http://groups.google.com/group/digitalvoice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[David Rowe]

Wow! Nice idea Stuart. Would certainly sort out that freq selective
fading....

- David

[Brian Litzinger]

I think this is a great idea and would be happy to help test.

[Jasmine Strong]

Another way would be to do time-interleaved OFDM- like ISDB-T and friends.

-J.

[Tony Langdon]

On 2/03/13 4:34 AM, Stuart Longland wrote:
> Hi all,
>
> Just a silly idea, but maybe one worth pursuing... I've been playing
> around with an alternate approach using direct sequence spread spectrum.
> Basically using a Barker-13 sequence as a chipping code.
>
> This may or may not be feasible. I haven't checked to see how wide the
> carrier is. Attached is a bit of a simulation I've knocked up, it uses
> the 'communications' package available from Octave-forge. It seems to
> achieve a 1% BER with a 3dB SNR -- apparently a level that's acceptable
> for Codec2.
>
> The constellation pattern is an utter mess, since this is a BPSK carrier
> running at 18.2kbps -- a screaming pace for HF. It relies on the
> autocorrelation of the barker-13 sequence to decode the individual bits.

Have to watch the bandwidth though, In this part of the world, we need
to keep it within 8 kHz for HF. Also, there's the issue of getting it
to air - those running SDR hardware will be fine (just need software :)
). The rest of us with conventional radios would be up for some expense
(not an option for me at the moment).

--
73 de Tony VK3JED
http://vkradio.com

[Stuart Longland]

Indeed. I thought a bit more about it; I'm effectively trying to pump a
20kHz into a phase modulator. This might be a bit quick for a carrier
of ~1600Hz. I'm not sure what the limits are here.

It was more the approach; run a higher bit rate but then just encode
each bit as a barker sequence. We can use this across multiple carriers
to allow the chip rate to be reduced.

I might see if it's possible to up the symbol rate in the existing FDMDV
modem to 350 symbols/second then try encoding each bit of Codec2 using a
Barker-7 sequence.

The sync carrier would probably be left at its existing 50 symbol/second
rate, since we only need to know where each Barker-7 sequence starts and
what half of the Codec2 frame we're decoding.

[Stuart Longland]

On 02/03/13 09:41, Stuart Longland wrote:
> Indeed. I thought a bit more about it; I'm effectively trying to pump a
> 20kHz into a phase modulator. This might be a bit quick for a carrier
> of ~1600Hz. I'm not sure what the limits are here.

Well, I had a closer look into this. I wasn't quite sure what would
happen if something like the above was attempted. In particular, I
wanted to find out if there was some maximum symbol rate that a carrier
at any given frequency could support.

I constructed a simple test which just modulates a clock signal, so a
constant stream of 1's and 0's.

I feed this into a BPSK modulator, then interpolate and pulse-shape the
output of this to get the in-phase and quadrature components which I
then modulate onto a carrier.

I pass this through a 3rd order Butterworth band-pass filter between
500Hz and 2kHz; I figure this is a reasonable approximation of the audio
filtering in a transceiver.

This goes over a AWGN channel, then is filtered again with the same
Butterworth filter at the receiving end.

I de-modulate the carrier, pass it through a matched filter, grab each
symbol then pass that to a BPSK demodulator.

The end result is compared both to the original pulse train, and the
inverted pulse train. This is because of phase ambiguity.

This test is repeated for different SNR values, carrier frequencies and
symbol rates. It seems that, for a given frequency, a carrier will have
an optimum symbol rate independent of the SNR.

Under no-noise conditions; only band-pass filtering, I see carriers that
are on the edge of the band-pass window suffer bit error issues, but the
others are mostly fine. Above 400 symbols per second however, and bit
error rates for carriers below 400Hz hit the roof.

Add some noise in, and anything out side the band-pass window suffers
greatly as you'd expect. The unexpected finding here was that some
combinations of frequency and symbol rate work really well and others
work poorly.

There is a harmonic relation to this, which when you think about it,
makes sense, if the symbol is synchronised with the zero-crossing, it
has less impact on the carrier.

With a 3dB SNR, carriers between 1.2kHz and 1.8kHz still achieve bit
error rates below 10% for symbol rates up to 200 baud. There are other
examples that just don't make any sense.

I'm not certain how to resolve the phase ambiguity in the detection, and
this could be part of what's going on. I think more research is in
order. I've attached the script that I've been using, as well as two of
the graphs produced. Maybe I've made an obvious blooper, or perhaps
there's something in this?

Regards,

[David Rowe]

Hello to any VK stations - Mark VK5Qi and I are doing some test on 7190
right now, also coordinating on freenode IRC #freedv channel.

- David

[Stuart Longland]

On 02/03/13 17:33, David Rowe wrote:
> Hello to any VK stations - Mark VK5Qi and I are doing some test on 7190
> right now, also coordinating on freenode IRC #freedv channel.

Ahh, right in the middle of the contesters. :-)

I have the TS-120S on and I'm on the listen-out.

[VK2JI - Ed Durrant]

On 02/03/13 18:43, Stuart Longland wrote:
> On 02/03/13 17:33, David Rowe wrote:
>> Hello to any VK stations - Mark VK5Qi and I are doing some test on 7190
>> right now, also coordinating on freenode IRC #freedv channel.
> Ahh, right in the middle of the contesters. :-)
>
> I have the TS-120S on and I'm on the listen-out.

Yes can't hear anything apart from SSB contesters in the ARRL DX contest
on that frequency as well.

73 Ed.

[Mark Jessop]

7093

- Mark VK5QI

[Stuart Longland]

On 02/03/13 17:55, Mark Jessop wrote:
> 7093
>
> - Mark VK5QI

Cheers, I'm getting *something*, just nothing my version of FreeDV has
been able to decode. Are we using the grey-coded FDMDV or the old
binary one?

[Mark Jessop]

We're testing some new experimental modulation schemes, with more carriers.

After we're done we'll do some normal freedv.

Join us on IRC, #freedv on Freenode.

- Mark VK5QI

[Tony Langdon]

On 2/03/13 7:23 PM, Mark Jessop wrote:
> We're testing some new experimental modulation schemes, with more
> carriers.

Damn, missed the fun. 6PM Saturday is an awful rime for me - right on
dinner time, followed by drinks and a movie or 3... Tend to not look at
email as often as at other times. :(

[Patrick Strasser]

schrieb Tony Langdon on 2013-03-02 10:32:
> On 2/03/13 7:23 PM, Mark Jessop wrote:
>> We're testing some new experimental modulation schemes, with more
>> carriers.
> Damn, missed the fun. 6PM Saturday is an awful rime for me - right on
> dinner time, followed by drinks and a movie or 3... Tend to not look at
> email as often as at other times. :(

Me too to late. The time is not so bad for Europe, I would have tried to
get some recordings via websdr.org. What about tomorrow? That would be
Sunday morning here. If I knew it 12 hours in advance I'd get up a
little earlier ;-)

Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <patrick at wirklich priv at>

[Stuart Longland]

On 02/03/13 19:57, Patrick Strasser wrote:
> schrieb Tony Langdon on 2013-03-02 10:32:
>> On 2/03/13 7:23 PM, Mark Jessop wrote:
>>> We're testing some new experimental modulation schemes, with more
>>> carriers.
>> Damn, missed the fun. 6PM Saturday is an awful rime for me - right on
>> dinner time, followed by drinks and a movie or 3... Tend to not look at
>> email as often as at other times. :(
>
> Me too to late. The time is not so bad for Europe, I would have tried to
> get some recordings via websdr.org. What about tomorrow? That would be
> Sunday morning here. If I knew it 12 hours in advance I'd get up a
> little earlier ;-)

I tuned in, didn't hear much however. There was maybe one or two
signals that looked like FreeDV, then some very feint SSB.

Still, it gave me an excuse to dust off the old HF rig. Definitely
tricky to tweak the mic gain setting without the ALC kicking up.

[Mark Jessop]

Hi all,

We managed to do quite a bit of testing of some modem modifications,
i'll let David fill everyone in on the results of that.

Some pics from the testing setup are here: http://imgur.com/a/wXOHu

Myself and Andy VK5AKH set up a 40m dipole up the back of the Morialta
Conservation Park in Adelaide, and were using a Codan 2110 Manpack for
most of the testing. We switched to an Icom IC-7000 towards the end to
get a bit more PEP out.
I was using a Signalink USB for interfacing. I haven't had problems with
the frequency response on mine.

The location had a very low noise floor when we started, about S3,
though this rose to S5 as propagated noise started to come in towards
dusk. The 40m band was very active with the ARRL DX contest, though we
found some clear spots to test in.

Cheers,
Mark VK5QI

[David Rowe]

Yes it was a pleasant Summer evening for us. I was set up "portable" in
the back yard with a end fed dipole up a squid pole. I was happy to
find that my FT-817 with 2.5W SSB could talk the 800km to Mark so we
could coordinate the tests. At my end the analog SSB was noisy (beneath
my urban S8 background noise level) but intelligible. Just the sort of
channel I'd like FreeDV to work over.

I generated some modem files with test data sent using 14, 16 & 20
tones. Mark played these files to me over his tx at about 4W average
power and I received them and recorded them.

I can then demodulate this data off line (using the Octave simulation
version of the modem), determine where the bit errors are, and use that
to test 2 new configurations of FreeDV that I am playing with. I
explained the process in the most recent blog post. One of the
configurations uses 600 bit/s FEC with the 1400 bit/s codec, the other
is a 1600 bit/s mode of the Codec that is more robust to errors that the
current, 1400 bit/s mode.

I have the 1600 bit/s configuration ready to test, but the third one
requires some FEC code to be written which will take a few days.
Hopefully one of these configurations will get us closer to the
robustness of SSB over fading channels.

At one stage Mark over-drove his TX. The received file had a lot more
bit errors but it was hard for me to determine the reason when just
looking at the received data or waterfall over a noisy channel. It
would be nice to determine a way to tell if the Tx output is at the
correct level.

When we played the swept sine wave through Marks Tx he saw an output
power of between 4 and 6W on his power meter. That's about 1.8dB. If
it wasn't measurement error, it would be nice to get that a little
flatter.

Cheers,

David