Using USRPs in transceiver_OQPSK .grc

[oayan]

Hi,

I am using USRPs and downloaded the maint-3.8 branch. To test wireless communication, I have replaced the packet_pad block with USRP source and sink (with packet_pad it is working). However I am not able to receive any packets. I am wondering if someone had the same issue.

Hint: With a manually generated FM receiver flowgraph, I am able to listen to the radio.

OS: Ubuntu 18.04 HW: USRP B200 mini-i GNUradio version: maint-3.8

For easier troubleshooting, this is how the flowgraph looks like.

Any help is appreciated.

[bastibl]

It looks fine to me. Even though I didn't test this exact setup. My understanding is that you connected two SDRs to the flowgraph/network stack. I'd try different gains, check that the antennas are connected to the right port, etc. You disabled the wireshark blocks, so how do you know if it works? Debug output (at what layer)? Are you connected the the Socket PDU?

[oayan]

On this graph it is disabled, but we were checking with both methods you mentioned above ( socket and .pcap). We were able to see incoming packets when we activated packet pad block instead of USRPs.

We did a more detailed test. Our findings are as follows:

• If we transmit from Host A (running GNUradio3.7) to Host B (running GNUradio 3.8), we receive packets successfully
• If we transmit from SDR1 to SDR2 on Host A (running GNUradio3.7), we receive packets successfully.
• Whenever we want to transmit from Host B (running GNUradio 3.8), to any other SDR (either on Host A or Host B), we receive the first packet only and nothing else.

So we believe that, UHD: USRP Source block is working fine, but the UHD: USRP Sink has some issues. Additional information: We get such a warning on terminal "set_min_output_buffer on block 7 to 65536"

[bastibl]

Arg, I made some changes to the transmitter in 3.8, hoping to avoid that frames get stalled in the transmitter. Could you compare the TX configuration in the hierarchical block (OQPSK_PHY). I think I added the Packet Pad block. Could you try without it. (You'd need to change the flowgraph, build it, and then run the transceiver flowgraph).

[oayan]

Hi, we have now tried with the maint-3.9 branch. As you said, the issue seems to be solved, if we disable the "Packet Pad2" block inside the "OQPSK_PHY" hierarchical block. We tried 2 approaches: 1) directly connecting the previous block to the next one instead of packet pad, and it works. 2) Putting a Burst Shaper block, configured just like in the maint-3.7 branch. In both methods, we can transmit and receive.

Do we need a block at this point? What is the purpose of inserting packet pad block there?

[bastibl]

The block adds a bunch of zeros after every frame. This is done for two reasons:

• It avoids that the last symbol of the previous frame interferes with the first symbol of the current frame. Otherwise offsetting Q with regard to I leads to interference. This might not be completely detrimental, i.e., it might still work, but I think it should be avoided and, therefore, I would keep either a Burst Shaper or Packet Pad 2 block there.
• It was supposed to flush the transmitter. I don't remember the details, but I had issues that the last frame was stuck in the transmitter, e.g., I put a frame in the transmitter but nothing is sent; I put in another frame and frame 1 is sent.

I'd suggest to use maint-3.8 to debug and see if these issues persist. Unfortunately, I cannot test it myself at the moment :-/

[oayan]

Yes we had the second point you mentioned before and our investigations were hinting at the packet sink block on the receiver side. Our guess that in line 305 (packet_sink.cc), one of the values, either "count" or "ninput" was incorrect when it gets evaluated there. But we did not manage to solve it in a good way.

[yuanfangzsp]

The block adds a bunch of zeros after every frame. This is done for two reasons:

• It avoids that the last symbol of the previous frame interferes with the first symbol of the current frame. Otherwise offsetting Q with regard to I leads to interference. This might not be completely detrimental, i.e., it might still work, but I think it should be avoided and, therefore, I would keep either a Burst Shaper or Packet Pad 2 block there.
• It was supposed to flush the transmitter. I don't remember the details, but I had issues that the last frame was stuck in the transmitter, e.g., I put a frame in the transmitter but nothing is sent; I put in another frame and frame 1 is sent.

I'd suggest to use maint-3.8 to debug and see if these issues persist. Unfortunately, I cannot test it myself at the moment :-/

Hello, I modified according to your method, but the problem still exists in version 3.8. I can only receive the first frame signal, and the device I used is B210. When I ran the program, I observed that the indicator at the transmitter kept flashing, which should be on all the time in normal state. I used other programs to test, and my B210 works normally. Can you give me some advice?

[bastibl]

I just tested the maint-3.10 branch and found two bugs:

• the RX/TX gains were between [0; 1] but the gain was set to absolute, resulting in 0 RX/TX gain. It should be set to normalized.
• the name of the packet length tag was wrong.

I fixed that with the recent commit in the 3.10 branch. Can you please give this branch a try. I cannot test maint-3.8 at the moment, but any feedback and PRs are appreciated.

[yuanfangzsp]

After my check, the antenna gain is set correctly. But I don't know if the name of the packet length tag is true.The TSB tag name in USRP Sink is set to be "pdu_length" , I wonder if pdu_length is a fixed value? How should I check the name of the packet length tag？ Thank you for your reply.

[bastibl]

pdu_length is probably the default. The flowgraph uses packet_len, which you should try. You can add a Tag Debug block to see what tags are used.