[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bob Vincent
Subject: [Discuss-gnuradio] Fwd: Re: FSK now (really) working at 100kbit/sec
Date: Mon, 28 Feb 2005 14:28:50 -0500

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]