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

[Eric Blossom]

Matt and I spent some time looking at the FSK code over the weekend.

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.

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