Further explain about receiving packets using 2 daughterboads in 2 framer sink didn't work correctly

GNU Radio
1

Here is my staff,
I’m using two USRPs both with two daughterboards rfx400 and rfx2400. One
USRP only transmit and the other USRP only receive at a time. The two
daughterboads on one USRP receive or transmit at the same time.I
modified
the codes of gnuradio-examples/digital to do the work.
The transmit part worked well. But the receive path didn’t work
correctly.
Only the framer_sink of rfx2400 side work. The other side of rfx400 can
receive the signal(I set --log-rx-power, and see the power of rfx400
received, it shows that the signal is received.) But the framer_sink of
rfx400 didn’t work.

my connect flow graph is
#for side a
self.connect( (di,0), self.chan_filt_a, self._demodulator_a,
self.correlator_a, self.framer_sink_a )
self._watcher_a = _queue_watcher_thread_a(self._rcvd_pktq_a,
self._rx_callback_a)
#for side b
self.connect( (di,1), self.chan_filt_b, self._demodulator_b,
self.correlator_b, self.framer_sink_b )
self._watcher_b= _queue_watcher_thread_bself._rcvd_pktq_b
self._rx_callback_b)

I switch the connect of deinterleave output to test each receive side
flow
graph such as
self.connect( (di,1), self.chan_filt_a, self._demodulator_a,
self.correlator_a, self.framer_sink_a )
self.connect( (di,0), self.chan_filt_b, self._demodulator_b,
self.correlator_b, self.framer_sink_b )

The rfx400 side didn’t work all the same, and the rfx2400 work fine just
like before. Then I can say the two path of connection is both working
well.
And the rfx400 side is no wrong until connect to the
self._demodulator_a.

Have anyone ever do the same experiment of receiving packets using both
daughterboard? Can anyone tell me what’s the mistake I made?
I use the USRP with the two daughterboards in multi_fft.py(I modified
it)
that work well. I think maybe some part of the demodulator, correlator
or
framer sink does’nt work for multi daughterboard?

–
View this message in context:
http://www.nabble.com/Further-explain-about-receiving-packets-using-2-daughterboads-in-2-framer-sink-didn't-work-correctly.-tp22682442p22682442.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

I’m encountering the same problem over where I am, and have come to the
same conclusion.

3

actualy, I set the wrong mux value so that the wave form is very bad.
And I
set mux to 0x2310, it now work well.

James B.-2 wrote:

Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/Further-explain-about-receiving-packets-using-2-daughterboads-in-2-framer-sink-didn't-work-correctly.-tp22682442p23551427.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

William Sherman wrote:

Ok the problem was I set my decimation too high (256), even though on
the faq it says I can go [8, 256]. I tried it with 128 and it worked.

Yet I am able to receive packets generated by my own usrp (usrp
transmits and receives its own packet) correctly. Does performance of
dbpsk modulation decrease with increased decimation so that a packet
generated from another usrp some distance away has really bad
performance?

5

Ok the problem was I set my decimation too high (256), even though on
the faq it says I can go [8, 256]. I tried it with 128 and it worked.

6

William Sherman wrote:

William Sherman wrote:

Ok the problem was I set my decimation too high (256), even though on
the faq it says I can go [8, 256]. I tried it with 128 and it worked.

Yet I am able to receive packets generated by my own usrp (usrp
transmits and receives its own packet) correctly. Does performance of
dbpsk modulation decrease with increased decimation so that a packet
generated from another usrp some distance away has really bad
performance?

Under ideal conditions, the lower the bit rate, the better the
performance should be. However, real radios have a frequency offset.
When you lower the data rate (i.e. increase the decimation rate), the
same absolute frequency offset in Hz will look like a bigger and bigger
fraction of the signal bandwidth. If you lower the signal bandwidth
enough, the frequency error might put the signal completely out of the
receiver bandwidth.

The normal way to solve this is to add an algorithm that will scan the
receiver frequency in order to find signals. The gnuradio examples do
not do this. Thus, you will sometimes find that you get better
performance at higher data rates than you get with lower data rates.

Matt