Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal
Hi Jeff, I use burst mode all the time (mostly on N310 but X310 as well). I usually prefer a `packet_length` tag instead of SOB --> EOB. As Marcus mentioned, as soon as the first sample goes into the USRP sink, you start transmitting and need to sustain your sample rate. To ensure that you provide enough samples, I'd recommend to start with a vector source and a defined signal. Or use a PDU with a PDU to tagged block to control the frequency of your individual packets. A sine wave with increasing amplitude is probably a very useful signal. And I assume you're aware that bursts should be preceeded and followed by some zero values to ensure everything is in a steady state as soon as your real data is transmitted. The proposed signal would be really useful to debug these issues. Cheers Johannes On 21.01.21 19:34, Jeff S via USRP-users wrote: Here's an output of a sine wave which replaced the spikey one: I think that shows what I believe you were explaining, that the SOB/EOB doesn't work like I thought. I was using them as packet identifiers and assumed the USRP would wait for the whole packet to begin transmission, but your description seems to indicate that tx_sob turns the radio on and tx_eob turns the radio off (maybe a simplification?) and just streams whatever it sees during that time. And during that time, the buffer may be empty because data isn't produced fast enough. The time between the segments of the sine wave show the delay from one call of the work function to the next. There is a delay within the source that slows the output of the data, and since I thought the SOB/EOB combination would only transmit after the EOB was received, I did not think it would be a problem. It obviously is. I now have to think of a way to do that with random length data. Maybe add a tx_time to provide some delay before transmission? Jeff *From:* Marcus Müller *Sent:* Thursday, January 21, 2021 10:29 AM *To:* Jeff S ; usrp-users *Subject:* Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal Hi Jeff, thanks for clarifying! Yes, that should work. Also, your GR version definitely has support for SOB/EOB. Generally, I'd expect this to work; only misconception I see is that the Sink doesn't start sending when it sees the EOB; it starts sending at SOB, and stops expecting and sending samples to the USRP at EOB. Could you try replacing your very "spikey" signal with something like a sine, so to see whether we might be seeing turn of/off behaviour? Best regards, Marcus On 21.01.21 16:34, Jeff S wrote: Thanks, Marcus. Of course, I forgot the important version information. I'm currently using v3.7.13.5. We are also doing some RFNoC work, which we had some issues upgrading a while back, so we were holding off until it matured more. I'll ask our team if they want to try and upgrade to 3.8 again. I'm sure my description wasn't clear, so I'll try and clarify a little better based on your feedback. I created the Random Source, and it is sending approximately 10,000 samples to the UHD USRP Sink as one message, with a tx_sob at the start and a tx_eob at the end. My thought was that the sink would not transmit anything until the EOB was received. The way GNURadio seems to be running, I'm getting [noutput_items == 4096], so it takes three calls to the work function to deliver all 10K samples of one message to the Sink. I only want one burst from the sink of those 10K samples. What I am receiving seems to be three transmissions that make up the one sample. The length of the three transmissions seem to correspond to the value of noutput_items I was seeing. The mention of 100 ms between bursts was only indicating how fast the modulator was being requested to transmit a single message. So if I only requested one message, there would have been one group of three signals seen in the Rx signal. Hope that clarified what I was trying to convey a little better. Regards, Jeff -- *From:* Marcus Müller *Sent:* Thursday, January 21, 2021 9:06 AM *To:* Jeff S ; usrp-users *Subject:* Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal Hi Jeff, which version of GNU Radio are you using? Judging by the looks of your flow graph it's the (now legacy) 3.7, but *if* I remember correctly (it's really been a while), the SOB/EOB functionality appeared *somewhen* in 3.7.x; it might be worth trying your exact same application in GNU Radio 3.8 (or 3.9). Conceptually, it's important to note that after tx_sob you need to supply the full burst of samples: I think you're doing that, but then again, you say you get three data bursts 100 ms apart, so I'm not sure about that, to be honest. The USRP sink can't guess that you want three bursts of samples to be sent as one; it starts streaming as
Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal
Hi, Johannes! Is the packet_length vs SOB/EOB more of a preference, or are there some underlying reasons to go with packet_length? This is the first time I have used burst mode, so I'm just learning all the details of it. I started with packet_length, but I wasn't getting my expected results and switched to SOB/EOB. I apparently wasn't getting my expected values due to the delay in my code and my misunderstanding of burst mode. Fixing where I was getting the significant delay in my work function has seemed to clear up my expected signal. I was considering a vector source, but the size of the vector may be variable and that seems like it could pose a challenge. I did use a [stream to vector]-->[vector to stream] to create a makeshift buffer to test if the delay was in my source or somewhere else. That also proved that my source was the cause of the delay. I was not aware of needing the zeros before and after the signal, but it's obvious (as soon as you pointed it out). It makes total sense. Is there a rule of thumb you use for setup time? I haven't searched yet. PDU is something else I have not used much, but I thought it might prove useful here. I need to read up on it and do some experimenting to see what I can do with it. Thanks for the help, Johannes. You and Marcus have been a great help! Jeff From: USRP-users on behalf of Johannes Demel via USRP-users Sent: Friday, January 22, 2021 2:47 AM To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal Hi Jeff, I use burst mode all the time (mostly on N310 but X310 as well). I usually prefer a `packet_length` tag instead of SOB --> EOB. As Marcus mentioned, as soon as the first sample goes into the USRP sink, you start transmitting and need to sustain your sample rate. To ensure that you provide enough samples, I'd recommend to start with a vector source and a defined signal. Or use a PDU with a PDU to tagged block to control the frequency of your individual packets. A sine wave with increasing amplitude is probably a very useful signal. And I assume you're aware that bursts should be preceeded and followed by some zero values to ensure everything is in a steady state as soon as your real data is transmitted. The proposed signal would be really useful to debug these issues. Cheers Johannes On 21.01.21 19:34, Jeff S via USRP-users wrote: > Here's an output of a sine wave which replaced the spikey one: > > > > I think that shows what I believe you were explaining, that the SOB/EOB > doesn't work like I thought. I was using them as packet identifiers and > assumed the USRP would wait for the whole packet to begin transmission, > but your description seems to indicate that tx_sob turns the radio on > and tx_eob turns the radio off (maybe a simplification?) and just > streams whatever it sees during that time. And during that time, the > buffer may be empty because data isn't produced fast enough. > > > The time between the segments of the sine wave show the delay from one > call of the work function to the next. There is a delay within the > source that slows the output of the data, and since I thought the > SOB/EOB combination would only transmit after the EOB was received, I > did not think it would be a problem. It obviously is. > > > I now have to think of a way to do that with random length data. Maybe > add a tx_time to provide some delay before transmission? > > > Jeff > > > > *From:* Marcus Müller > *Sent:* Thursday, January 21, 2021 10:29 AM > *To:* Jeff S ; usrp-users > *Subject:* Re: [USRP-users] SOB/EOB Burst Mode on X310 Splitting Signal > Hi Jeff, > > thanks for clarifying! > > Yes, that should work. Also, your GR version definitely has support for > SOB/EOB. > > Generally, I'd expect this to work; only misconception I see is that the > Sink doesn't > start sending when it sees the EOB; it starts sending at SOB, and stops > expecting and > sending samples to the USRP at EOB. > > Could you try replacing your very "spikey" signal with something like a > sine, so to see > whether we might be seeing turn of/off behaviour? > > Best regards, > Marcus > > On 21.01.21 16:34, Jeff S wrote: >> Thanks, Marcus. >> >> Of course, I forgot the important version information. I'm currently using >> v3.7.13.5. We >> are also doing some RFNoC work, which we had some issues upgrading a while >> back, so we >> were holding off until it matured more. I'll ask our team if they want to >> try and upgrade >> to 3.8 again. >> >> I'm sure my description wasn't clear, so I'll try and clarify a little >> better based on >> your feedback. >> >> I created the Random Source, and it is sending approximately 10,000 samples >> to the UHD >> USRP Sink as one message, with a tx_sob at the start and a tx_eob at the >> end. My thought >> was that the sink would not transmit anything
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
Hi Rob, Thanks for your assistance. On 21/01/21 22:49, Rob Kossler wrote: > Also, regarding building in-tree, are you opposed to building in-tree as even > a temporary test case? It's not too difficult to do. I am not > talking about the > FPGA code - just the block controller HPP / CPP. I am not, especially as a temporary solution. I just fear the possible implicated burden in the long run compared to OOT when propagating those blocks to multiple hosts. Do you have documentation on how to properly build the block controller cpp/hpp in-tree? I guess I'll have to rebuild the whole UHD? I was just pulling binaries provided by my distribution. -- Cédric Hannotier ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
On Thu, Jan 21, 2021 at 4:49 PM Cédric Hannotier via USRP-users
wrote:
> On a side note:
> Are we forced to implement a custom controller for each RFNoC block?
> I was expecting that I could just write the verilog part
> and use the basic noc_block_base controller to manage my blocks in C++,
> using regs()->peek32/poke32 to set my registers etc.
> But from above, it seems that it does not forward the issue_stream_cmd
> by default? Is that correct?
For very basic RFNoC block prototyping, you should be able to use the
default noc_block_base implementation if you are willing to access
your NoC block's functionality via register reads and writes and deal
with some additional complications when dealing with multiple custom
RFNoC blocks. You should be able to get a reference to the block by
calling get_block() on your rfnoc_block object--this method returns a
noc_block_base::sptr.
The bit that's complicated is that get_block() takes a block_id_t,
which consists of the device number, block name, and instance (e.g.,
'0/MyBlock#0' when represented as a string). Generally, the name is
assigned to the block in the custom block controller via the
UHD_RFNOC_BLOCK_REGISTER_DIRECT() macro. If the block is not
registered via this macro, as is the case when using noc_block_base
directly, the block will be assigned the unimaginative but technically
correct name of 'Block'. Thus, if you want to use multiple different
custom RFNoC blocks without custom block controllers in this manner,
you will need to verify that when you call get_block("0/Block#n"), it
is the block that you expect. You can call get_noc_id() on the
noc_block_base that is returned and ensure that the 32-bit ID indeed
represents the block that you wish to control.
Unless specifically overridden, the default behavior of a
noc_block_base-derived object, I believe, is to forward actions
(stream commands) using the ONE_TO_ONE forwarding policy, which means
to forward the action to the same port on the opposite edge (so to
output port #N if the action is received on input port #N, and vice
versa). Consult the documentation of uhd::rfnoc::node_t and
forwarding_policy_t for more details.
Best regards,
Aaron
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Add Xilinx IP in OOT RFNoC UHD4.0
Yes, I have done it. I'll share an example with you. Putting your IP in-tree is also an option. Thanks, Wade On Thu, Jan 21, 2021 at 5:01 PM Cédric Hannotier via USRP-users < usrp-users@lists.ettus.com> wrote: > Dear all, > > On 08/01/21 18:58, Cédric Hannotier via USRP-users wrote: > > Dear all, > > > > I am following the RFNoC on UHD4.0 wiki [1], > > but there is no mention on how to add Xilinx IPs in the OOT. > > > > When following [2], > > after copy-pasting from "host/example/rfnoc-example", > > and following [3] to setup basic shell env/script, > > how can I add for example IP "xilinx.com:ip:mult_gen:12.0"? > > > > Furthermore, how do I add that IP "module wise" or "block wise", > > i.e. inside rfnoc-example or inside rfnoc-example/fpga/rfnoc_block_gain? > > > > There is viv_create_ip [3], but it just creates the tree, > > it does not link that new IP with the current OOT tree. > > > > [1] https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 > > [2] > https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Creating_Your_Own_OOT_Module > > [3] https://files.ettus.com/manual/md_usrp3_vivado_env_utils.html > > Unfortunatly, I am still facing that issue. > Has anyone managed to add a Xilinx IP into an OOT RFNoC block? > > -- > > Cédric Hannotier > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
> On 21/01/21 22:49, Rob Kossler wrote: > > Also, regarding building in-tree, are you opposed to building in-tree as > > even > > a temporary test case? It's not too difficult to do. I am not > > talking about the > > FPGA code - just the block controller HPP / CPP. > > I am not, especially as a temporary solution. > I just fear the possible implicated burden in the long run > compared to OOT when propagating those blocks to multiple hosts. > Do you have documentation on how to properly build > the block controller cpp/hpp in-tree? > > I guess I'll have to rebuild the whole UHD? > I was just pulling binaries provided by my distribution. Based on Aaron's other email, it sounds like your plan of running without a custom block controller should work and that the default block controller should forward actions (I'm guessing that issue_stream_cmd is an action but not positive). So, maybe we're on the wrong path. But, if you are able to run ddc->issue_stream_cmd() rather than rx_stream->issue_stream_cmd() and get better results, then that is a good sign that the issue_stream_cmd is never making it to the DDC. If you decide you want to build an in-tree custom controller, here are my thoughts. Yes, you would need to build UHD from source. But, after building once, you could add additional blocks without rebuilding the whole UHD. My procedure is the following: - copy the HPP into host/include/uhd/rfnoc/ - update the CMakeLists.txt file in that folder to incorporate my new file - copy the CPP into host/lib/rfnoc/ - update the CMakeLists.txt file in that folder to incorporate my new file - run make -jN from the host/build/ folder (it will notice the changes to CMakeLists and build just your files & re-link the UHD library) ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
