[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Re: FSK now (really) working at 100kbit/sec
From: |
Eric Blossom |
Subject: |
[Discuss-gnuradio] Re: FSK now (really) working at 100kbit/sec |
Date: |
Mon, 28 Feb 2005 03:59:00 -0800 |
User-agent: |
Mutt/1.5.6i |
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