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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
