That makes sense. Thank you so much for all of your help!! It's much appreciated and has helped me understand what's going on a lot better as well.
On Sun, Jan 24, 2021 at 4:59 PM Jeff Long <willco...@gmail.com> wrote: > You're not seeing anything on the gui sinks because they only show you > periodic snapshots (except for gr-fosphor if you have that installed) and > the bursts fall between the snapshots. Inspectrum lets you see every sample > in a recorded file. > > I'm not going to have time to try out the RX part, but make sure the RF > path is sane (attentuators, levels, verify using a File Sink or other > method) and then build up the RX one piece at a time. You may have to learn > about the internals of packet_rx, and use various debug blocks/gui sinks to > figure out what's going on. GRC makes it look like you can drag-and-drop > and make a radio. > > On Sun, Jan 24, 2021 at 6:39 PM Jada Mariano Berenguer <beren...@uci.edu> > wrote: > >> 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 <willco...@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 <beren...@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 <willco...@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 < >>>>> beren...@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 <willco...@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 < >>>>>>> beren...@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 >>>>>>>> <https://lists.gnu.org/archive/html/discuss-gnuradio/2018-06/msg00254.html> >>>>>>>> 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 >>>>>>>> <https://wiki.gnuradio.org/index.php/USRP_Sink>', 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 >>>>>>>> <https://drive.google.com/file/d/1n8SdwjbZebE4Mf4nufTUUnEALPNR0yDF/view?usp=sharing> >>>>>>>> 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 :) >>>>>>>> >>>>>>>> >>>>>>>>
