I have been trying to transmit data between usrp e100 (with RFX2400
daughter board) and a non-usrp device, which has a fixed 4M sample rate.
On e100 side (running in half duplex mode), although data from the
uhd_source will go through a gr.pwr_squelch_cc block before being
demodulated, the device will still continuously overflow at this sample
rate, and judging from the output of the packet_sink, only less than
half of the data is correctly demodulated.
To reduce the computation load of the processor, I tried two methods:
- modify the gr.quadrature_demod_cf block, replace some multiplication
operations with volk-based operations (gr.multiply and gr.multiply_const
modules in gr_blocks);
- use complex_int16 type instead of complex_float32 at uhd interfaces
and modulation / demodulation blocks.
But I got unexpected results after the changes. If I adopt method 1),
the amount of correctly demodulated data is roughly the same as when
using the original demodulation block. And for method 2), the result is
even worse - less data is correctly demodulated.
Could someone please tell me if I did something wrong, or there are
other solutions to this overflow-at-high-sample-rate problem?
On e100, I burned the latest console file system, use
UHD_003.004.000-6795022, and Josh’s next branch of GNU radio,
uhd setup: center frequency 2.416 GHz, sample rate 4M.
BTW, it took almost twice the amount of time to build both uhd and GNU
radio after burning the latest console file system, and the
initialization process of uhd (when device information is printed out)
took a lot longer time than before as well. But what I concerned more is
that much fewer packets could be received, compared with another e100
which has the same flow graph setup but installed previous versions of
tools: file system, UHD_003.004.000-1a25e48, GNU radio 3.5.0. Could it
be caused by some hardware problems? I will greatly appreciate it if
someone could give me a hint on this.
Thanks in advance,