Re: Packet Loopback Example Using USRP

[Jada Mariano Berenguer]

Okay, so do the bursts of digital data mean that the USRP Sink is able to successfully get the packet as input and transmit it? 

If so, when I run the packet_usrp.grc flowgraph, why do I not see the USRP Source receive anything? For example, the graphs that represent the USRP Source's output never change. I would expect it to change when it receives a packet of data. Also, if the USRP source was receiving something, wouldn't the Packet RX block decode the packet and print the contents to the terminal using the Message Debug block?

On Sun, Jan 24, 2021 at 2:04 PM Jeff Long <willcode4@gmail.com> wrote:

Yes, that shows bursts of digital data, which is what your tx produces. Use a smaller FFT size to see more detail in the time domain.

On Sun, Jan 24, 2021 at 4:44 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

So, from my understanding you added a File Sink that took in the USRP Source's output to the packet_usrp_tx.grc flowgraph? I tried to recreate what you did and opened the file with Inspectrum and a screenshot of the results is attached. I'm not sure if this is what you got, or what it means. I may be saving it to the File Sink incorrectly, so I attached a screenshot of the File Sink parameters as well. 

Also, what do you mean by 'What happens if you ignore this and keep working' ? Because if I run the packet_usrp.grc flowgraph for a while and ignore the U's printing out, it doesn't give me the result that I expect. The result that I expect would be similar to the result when running the packet_loopback_hier.grc file. 

Thanks again for your continued help!

On Sun, Jan 24, 2021 at 12:03 PM Jeff Long <willcode4@gmail.com> wrote:

Best I can tell (recording raw samples from the USRP Source to a File Sink, then viewing it with inspectrum), it works and the single 'U' per burst is spurious. The docs would lead you to believe you shouldn't see this. Nothing stands out as wrong in the GRCs. What happens if you ignore this and keep working?

On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Okay, thanks for the tip. Attached in this email is a flowgraph that only does TX (packet_usrp_tx.grc). I'll continue to look into the problem and see if I can find any solutions myself as well, but again I'm pretty new to GNURadio and USRP. If anyone can help me figure out the problem, it'd be greatly appreciated!! I've also attached the packet loopback example using the USRP with both TX and RX (packet_usrp.grc), the original packet loopback example without USRP (packet_loopback_hier.grc), and the packet_tx and packet_rx flowgraphs as well. 

On Sat, Jan 23, 2021 at 4:36 AM Jeff Long <willcode4@gmail.com> wrote:

Recommend you find the simplest flowgraph that demonstrates this problem. For example, do TX only. Once you find that minimal case, post the actual GRC file somewhere so someone can try it out. It's really difficult to look through a bunch of parameters in a screenshot and try to guess what's happening, unless it's something really obvious.

On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Hi again, I have a previous message thread regarding this problem, but I kept forgetting to 'reply all' to include the GNURadio email to keep it on the thread and my questions got kind of disorganized, so I wanted to start fresh with a new one and will make sure to reply all in the future. 

So, I found a packet_loopback example (under the directory: examples/digital/packet) from this message thread and it says that I can replace the Channel Model block with the USRP source and sink blocks to try to send packets over the air (a screenshot of the original packet_loopback example and my modified packet_loopback example is attached as well). This is exactly what I want to do, but I'm running into some issues with the USRP sink. 

I believe the problem has to do with the way that the USRP sink is receiving the packets. I believe it deals with 'bursty transmission', and so I specified the USRP sink's 'TSB tag name' parameter to 'packet_len', which is what the packet_tx block specifies as the length tag name (I've also attached a screenshot of the packet_tx flowgraph). I confirmed that the tag name is 'packet_len' by using the Tag Debug block. 

Also, I've attached a video link here of what happens when I run the program. It seems like the USRP receives the packet here and there because of the short 'bursts' shown on the middle graph. Also, I noticed that there's a 'tG' printed in the terminal window (a screenshot of this is attached as well) when the program is first run. What does this mean? I also know that it's experiencing a lot of underruns, which is essentially the problem I'm trying to solve. It must do with the way the USRP sink is configured to receive the packets. 

Are there any other parameters that need to be set? 

Thanks so much in advance!! I appreciate any help :)