[Discuss-gnuradio] Fwd: Re: FSK now (really) working at 100kbit/sec

[Bob Vincent]

> Subject: Re: FSK
> now (really) working at 100kbit/sec
> Matt and I spent some time looking at the FSK code over the weekend.

Thanks. The gr_simple_correlator fix makes it work a lot better.

> I made a couple of
> changes: reduced the gain in the tx module, fixed
> the problem in gr_simple_correlator.cc that was having it return
> after
> processing only a single sample (ooops!), and added a -N option (no
> graphs) to fsk_tx.py and fsk_rx.py.
>
> Two of these changes reduce CPU consumption.  The other avoids
> causing
> overflow in the FPGA.
>
> Here was my test setup:
>
>   - updated gnuradio-core and gnuradio-examples from CVS.
>   - 1.4 GHz Pentium M laptop, Mandrake 10.1, 2.6.8 kernel.
>   - USRP with an SMA cable connected between one Basic Tx output and
> one
>     Basic Rx input (both on the A side; SMA connector
> closest to the corner).
>
>   - I ran these commands in different windows:
>
>     $ ./fsk_rx.py -f /dev/null -c 10M -r 100k -N
>     $ ./fsk_tx.py -f /boot/vmlinuz -R -c 10M -r 100k
> -N
>
>   In the rx window I'd get "seqno  NNN" with
> increasing contiguous
>   sequence numbers.

CPU problem also seems fixed. 

HOWEVER, there still seems to be a problem with the USRP decimating
filter.
It is more apparent if the data going in is all zeros or ones, but the
same thing happens as before.
Takes longer for the sidebands to build up, but it's the same problem. I
tried cutting back by another factor of 4 with the same result.

I think that perhaps the FIR taps aren't set quite right. 

The new version with the correlator fix runs for several minutes, but the
receiver gives bursts of errors.
Impossible to tell if it's single bit drops because once a bit drops the
sync is thrown off until the next header comes.
The situation improves some drop data rate. Also running small frames (16
bytes per).


> If this is still
> burning too much CPU on your system, try dropping
> down to "-r 50k"  This will drop to 50kbit/sec.
>
> Running at 100 kbit/sec used about 70% of the CPU;  50kbit/sec used
> 35%.
>
> The primary bottleneck is in the rx path and is in the generic (C++)
> implemenation of gr_fir_ccf.   We could use a SIMD version
> of this filter primitive (and/or a smarter demod implementation).
> I suspect that 1Mbit/sec is doable with some algorithmic changes.
> We're currently running the receiver with 8x oversampling.
>
> In the absence of any kind of channel coding, we should probably add
> at least a CRC to the packets.
>
> Bob, I suspect that your socket puzzle is resolved too.  The
> problem
> where the correlator was only processing a single sample would have
> caused the behavior you were seeing.
>
> Eric