Re: [USRP-users] RFNOC REPLAY streaming to two UBX
Hi Rob, Thank you once again for answering my question! I have one more question? Did you change anything in the default FPGA image, in order to be able to sustain a maximum 125 MS/s for 4 channels on N310, or 200 MS/s for 2 channels on X310? By looking into x310_rfnoc_image_core.yml and the same is for n310_rfnoc_image_core.yml, I can notice that replay is connected over the crossbar to DUC. The Connection would look something like PCIe -> CrossBarSwitch ->* Replay -> CrossBarSwitch *-> DUC -> Radio. I can imagine that it would be more efficient to connect Replay directly to the DUC. PCIe -> CrossBarSwitch ->* Replay -> DUC -*> Radio. However, I am not sure, would that work with the new design due to the clock domain crossings? Kind Regards, EMil On Tue, Oct 6, 2020 at 3:40 PM Rob Kossler wrote: > Hi Emil, > With UHD 4.0, this works. And, the latest FPGA images from Ettus include > the Replay block on the X310 (in the past, this was just for the N310) so > you don't even have to build your own image. And, the latest FPGA images > provide access to the full 1GB ram such that you could store arb waveforms > for 2 channels with memory depth of 125M samps for each channel. > > I verified that I could play 4 channels at 125 MS/s from the UHD 4.0 > Replay block on the N310. I believe that I also verified 2 channels at 200 > MS/s on the X310, but I don't remember for certain. > > Rob > > On Tue, Oct 6, 2020 at 7:00 AM Emil Bjelski via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi All, >> >> I am investigating the option to stream samples from RFNOC_REPLAY block >> to two UBX-160 MHz cards with full speed (i.e. 200 Msps for each board). >> I would also like to support timing control for both of these two >> transmissions. >> >> I am planning to use new RFNOC architecture and UHD 4.0. >> However, before diving deeper I would like to hear from you if this is >> possible to be done in straightforward manner with the newest RFNOC >> developments. >> >> I see from the previous posts >> ( >> http://ettus.80997.x6.nabble.com/USRP-users-transmitting-on-two-channels-with-replay-block-td13915.html >> ). >> That with older RFNOC design and UHD 3.xxx streaming from RFNOC was >> limited to a single UBX radio. >> Meaning that an FPGA image with 2 Replay blocks was needed in order to >> stream samples to two UBXs radios. >> >> What would be the easiest way to proceed with new UHD 4.0? >> >> Thanks in advance on the answers, >> >> Emil >> ___ >> 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] RFNOC REPLAY streaming to two UBX
No. I did not change anything in the default image. It is true that the default image is routed such that the Replay block uses dynamic routing through a streaming endpoint to stream data to the DUC. Each Replay block port connects to an individual endpoint such that there is not a bandwidth limitation for the Replay block as a whole. But, I think there is no reason why you couldn't link the Replay block statically as you suggested below if you build a new image (I don't think there is any issue with clock domain crossings). The downside of this routing is that you cannot "bypass" the Replay block in case you wanted to do so. Also, it is pretty flexible to have the Replay block dynamically routed as it is in the default image. For example, in addition to using it as arb memory for signal transmission (which is my primary use case), I can also see a use case for using it instead in the receive chain to record a burst of incoming receive data. Thus, even if your host did not have a fast link (perhaps only 1GbE), you could record a receive snapshot to the replay block memory at high rate (until filled) and then download the samples over the slow connection to the host PC. Rob On Thu, Oct 8, 2020 at 4:55 AM Emil Bjelski wrote: > Hi Rob, > Thank you once again for answering my question! > > I have one more question? > > Did you change anything in the default FPGA image, in order to be able to > sustain a maximum 125 MS/s for 4 channels on N310, or 200 MS/s for 2 > channels on X310? > > By looking into x310_rfnoc_image_core.yml and the same is for > n310_rfnoc_image_core.yml, I can notice that replay is connected over the > crossbar to DUC. > The Connection would look something like > PCIe -> CrossBarSwitch ->* Replay -> CrossBarSwitch *-> DUC -> Radio. > > > I can imagine that it would be more efficient to connect Replay directly > to the DUC. > PCIe -> CrossBarSwitch ->* Replay -> DUC -*> Radio. > > However, I am not sure, would that work with the new design due to the > clock domain crossings? > > Kind Regards, > > EMil > > On Tue, Oct 6, 2020 at 3:40 PM Rob Kossler wrote: > >> Hi Emil, >> With UHD 4.0, this works. And, the latest FPGA images from Ettus include >> the Replay block on the X310 (in the past, this was just for the N310) so >> you don't even have to build your own image. And, the latest FPGA images >> provide access to the full 1GB ram such that you could store arb waveforms >> for 2 channels with memory depth of 125M samps for each channel. >> >> I verified that I could play 4 channels at 125 MS/s from the UHD 4.0 >> Replay block on the N310. I believe that I also verified 2 channels at 200 >> MS/s on the X310, but I don't remember for certain. >> >> Rob >> >> On Tue, Oct 6, 2020 at 7:00 AM Emil Bjelski via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hi All, >>> >>> I am investigating the option to stream samples from RFNOC_REPLAY block >>> to two UBX-160 MHz cards with full speed (i.e. 200 Msps for each board). >>> I would also like to support timing control for both of these two >>> transmissions. >>> >>> I am planning to use new RFNOC architecture and UHD 4.0. >>> However, before diving deeper I would like to hear from you if this is >>> possible to be done in straightforward manner with the newest RFNOC >>> developments. >>> >>> I see from the previous posts >>> ( >>> http://ettus.80997.x6.nabble.com/USRP-users-transmitting-on-two-channels-with-replay-block-td13915.html >>> ). >>> That with older RFNOC design and UHD 3.xxx streaming from RFNOC was >>> limited to a single UBX radio. >>> Meaning that an FPGA image with 2 Replay blocks was needed in order to >>> stream samples to two UBXs radios. >>> >>> What would be the easiest way to proceed with new UHD 4.0? >>> >>> Thanks in advance on the answers, >>> >>> Emil >>> ___ >>> 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
[USRP-users] Replay block time commands
Hi, http://ettus.80997.x6.nabble.com/USRP-users-X310-Replay-Block-and-receiver-timming-td11818.html >From this post and at the time the replay block did not support time-commands. >Is the functionality now available. And did anyone test it? Cherif ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B210 USRP object creation
Thanks Marcus, I have had a look at the GPIO example source. It contains some useful code, but I have not compiled and run it. Other example code in “Synchronising USRP Events using Timed Commands (17 April 2020)” has been used in the OOT block. 1) I have configured my B210(NI) EEPROM with the correct USB vid = 0x2500 and pid = 0x0814. The device is clearly identifiable and usable over USB3. 2). I have tried to identify the USRP using the following code prior to making an object:- uhd:: device_addr_t hint; hint[“serial”] = “3150322”; uhd:: device_addrs_t dev_addrs = uhd:: device::find(hint); 3). Or the following to create the object directly:- uhd::usrp::multi_usrp:: sptr device = uhd::usrp::multi_usrp::make(“vid=0x2500, pid=0x7814”); The codes are placed in the OOT constructor, compile and link with the appropriate headers. In both cases the flow-graph fails to run with the usual ‘block’ attribute error message. There are no USRP source or sink blocks in the flow-graph that could possibly conflict. Regards, David From: Marcus D. Leech via USRP-users Sent: Wednesday, October 7, 2020 6:20 PM To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] B210 USRP object creation On 10/07/2020 10:08 AM, David Taylor (manx.net) via USRP-users wrote: Hi. I am trying to exercise the GPIO bits on my B210 and to run other UHD member functions in a C++ OOT block. Can anyone provide me with a suitable make (object) statement for use with this transceiver. Many thanks, David Taylor You might look at the "gpio" example code that comes with the UHD source. ___ 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
[USRP-users] Custom RFNoC block test with UHD C++ (UHD-3.15.LTS)
Hi, I am trying to test my RFNoC gain block, the one from the ‘Getting Started with RFNoC Development’ guide, through the UHD C++ API on an E310 (I'm using UHD-3.15.LTS, I know that UHD 4.0 has just been released but I would appreciate it if someone could help me with this version). I'm quite sure that the bitstream I generated is correct, when loading the image and then running uhd_usrp_probe, the name I used in the gain.xml file shows up among the other RFNoC blocks. Also, when doing *gain_block_ctrl->sr_write()* and then checking the value through the readback register with *gain_block_ctrl->user_reg_read32()* everything seems to work fine. What I'm trying to figure out is how to transmit and receive samples from the block, I've tried a couple of ways and I'm still not getting a good result. First, I tried to send a packet with 200 samples to the block (*tx_stream->send(&tx_buff, tx_buff.size(), tx_md,0.5)*, with tx_stream obtained through a device3 usrp object, including *tx_stream_args.args["block_id"] = "gain"* and *tx_stream_args.args["block_port"] = "0"* in the tx stream arguments, the *tx_md* (metadata) set up with *tx_md.start_of_burst = false, tx_md.end_of_burst = false* and *tx_md.has_time_spec = false*, and I didn't use the radio at all this way. When trying to receive (*rx_stream->recv(&rx_buff, rx_buff.size(), rx_md, 5.0, true)*, including the *"block_id"* and *"block_port" *arguments in the rx stream like in the tx, and in mode *STREAM_MODE_NUM_SAMPS_AND_DONE*), and I got an *ERROR_CODE_TIMEOUT*. Then, I tried this time connecting the RFNoC Radio block to the gain block with an *rfnoc::graph* and setting the radio and gain *"block_id"* and *"block_port" *arguments in the tx stream. When doing *recv()*, I got an unknown error: "Receiver error: Unknown error code: 0x30" (does someone know what this means?) when checking the *rx_md.error_code*. However, *recv()* returned 200, like if it had received the samples I sent, but the rx buffer was empty. I also tried using the RFNoC Replay block, but didn't get anywhere either. Does anyone know if this block is supported in the E310? (this was asked in the mailing list a while ago in http://ettus.80997.x6.nabble.com/USRP-users-RFNoC-Replay-block-for-E310-td11156.html, but I'd like to know if someone has tested it since then). Lastly, I tried using threads, one with the *recv()* waiting for samples and the main program thread doing the *send()*, but I wasn't lucky again. I got this other unknown error: "Receiver error: Unknown error code: 0x3ce8e2b0". So, which would be the best way to test my block? Again, I only want to see that samples enter and exit multiplied by the gain value to understand how I can work with RFNoC blocks from C++. Also, I'm confused about this, when sending samples to the block its result should be kept in the FIFO that then UHD reads from, so I understand that there should be no reason for an active tx streamer to be streaming while doing the *recv()*, because the *recv() *should just read the result from the FIFO, or am I getting something wrong? Any help would be appreciated. Thanks in advance, Jorge ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B210 USRP object creation
On 10/08/2020 12:51 PM, David Taylor (manx.net) via USRP-users wrote: Thanks Marcus, I have had a look at the GPIO example source. It contains some useful code, but I have not compiled and run it. Other example code in “Synchronising USRP Events using Timed Commands (17 April 2020)” has been used in the OOT block. 1) I have configured my B210(NI) EEPROM with the correct USB vid = 0x2500 and pid = 0x0814. The device is clearly identifiable and usable over USB3. 2). I have tried to identify the USRP using the following code prior to making an object:- uhd:: device_addr_t hint; hint[“serial”] = “3150322”; uhd:: device_addrs_t dev_addrs = uhd:: device::find(hint); 3). Or the following to create the object directly:- uhd::usrp::multi_usrp:: sptr device = uhd::usrp::multi_usrp::make(“vid=0x2500, pid=0x7814”); The codes are placed in the OOT constructor, compile and link with the appropriate headers. In both cases the flow-graph fails to run with the usual ‘block’ attribute error message. There are no USRP source or sink blocks in the flow-graph that could possibly conflict. Regards, David COuld you just use one of the standard test tools like "rx_samples_to_file" and specify "type=b200" in the device arguments? There should NEVER have been any reason to change the VID and PID on the device. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] New mender instructions?
Hi, What is the new mender command to use on the N310 under UHD 4 file system? The -rootfs option from the following instructions is not a valid option. root@ni-n3xx-serial:~# mender -rootfs /home/root/usrp_n3xx_fs.mender ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Replay block time commands
I use the Replay block with timed commands. I have tested it and it seems to work fine. In general, I would say the Replay block functions best in UHD4, but I think that it will also work with timed commands in 3.15 (with bandwidth limitations imposed by 3.15 RFNoC architecture). Rob On Thu, Oct 8, 2020 at 10:51 AM Cherif Diouf via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > > > http://ettus.80997.x6.nabble.com/USRP-users-X310-Replay-Block-and-receiver-timming-td11818.html > > > From this post and at the time the replay block did not support > time-commands. Is the functionality now available. And did anyone test it? > > > Cherif > ___ > 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] Custom RFNoC block test with UHD C++ (UHD-3.15.LTS)
On Thu, Oct 8, 2020 at 1:33 PM Jorge Arroyo Giganto via USRP-users wrote: > I am trying to test my RFNoC gain block, the one from the ‘Getting Started > with RFNoC Development’ guide, through the UHD C++ API on an E310 (I'm using > UHD-3.15.LTS, I know that UHD 4.0 has just been released but I would > appreciate it if someone could help me with this version). > > I'm quite sure that the bitstream I generated is correct, when loading the > image and then running uhd_usrp_probe, the name I used in the gain.xml file > shows up among the other RFNoC blocks. Also, when doing > gain_block_ctrl->sr_write() and then checking the value through the readback > register with gain_block_ctrl->user_reg_read32() everything seems to work > fine. > > What I'm trying to figure out is how to transmit and receive samples from the > block, I've tried a couple of ways and I'm still not getting a good result. > > First, I tried to send a packet with 200 samples to the block > (tx_stream->send(&tx_buff, tx_buff.size(), tx_md,0.5), with tx_stream > obtained through a device3 usrp object, including > tx_stream_args.args["block_id"] = "gain" and > tx_stream_args.args["block_port"] = "0" in the tx stream arguments, the tx_md > (metadata) set up with tx_md.start_of_burst = false, tx_md.end_of_burst = > false and tx_md.has_time_spec = false, and I didn't use the radio at all this > way. When trying to receive (rx_stream->recv(&rx_buff, rx_buff.size(), rx_md, > 5.0, true), including the "block_id" and "block_port" arguments in the rx > stream like in the tx, and in mode STREAM_MODE_NUM_SAMPS_AND_DONE), and I got > an ERROR_CODE_TIMEOUT. Try setting the tx end-of-burst to true. Also, the block_id maybe should be "gain_0" rather than "gain". I'm not confident in these suggestions, but worth a try. > Then, I tried this time connecting the RFNoC Radio block to the gain block > with an rfnoc::graph and setting the radio and gain "block_id" and > "block_port" arguments in the tx stream. When doing recv(), I got an unknown > error: "Receiver error: Unknown error code: 0x30" (does someone know what > this means?) when checking the rx_md.error_code. However, recv() returned > 200, like if it had received the samples I sent, but the rx buffer was empty. Can you try "rfnoc_rx_to_file" which allows you to specify your custom block name on the command line and it will insert your block between the Radio and the rx_streamer? > I also tried using the RFNoC Replay block, but didn't get anywhere either. > Does anyone know if this block is supported in the E310? (this was asked in > the mailing list a while ago in > http://ettus.80997.x6.nabble.com/USRP-users-RFNoC-Replay-block-for-E310-td11156.html, > but I'd like to know if someone has tested it since then). As far as I know, the Replay block does not work for the E310. > Lastly, I tried using threads, one with the recv() waiting for samples and > the main program thread doing the send(), but I wasn't lucky again. I got > this other unknown error: "Receiver error: Unknown error code: 0x3ce8e2b0". > > So, which would be the best way to test my block? Again, I only want to see > that samples enter and exit multiplied by the gain value to understand how I > can work with RFNoC blocks from C++. > > Also, I'm confused about this, when sending samples to the block its result > should be kept in the FIFO that then UHD reads from, so I understand that > there should be no reason for an active tx streamer to be streaming while > doing the recv(), because the recv() should just read the result from the > FIFO, or am I getting something wrong? The various rfnoc blocks do have input/output FIFOs such that if the number of samples is small (such as 200 in your case), they can stay in the FIFO until you get around to calling recv(). But, if it is a continuous stream coming from the Radio, the FIFOs will fill very quickly if you are not consuming the data at the same rate by using recv(). ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B210 USRP object creation
Point taken. - I didn’t actually check the original default values of the VID and PID, but they were reset according to the table provided, so that they could be tested as arguments in the make statement below. “About the Motherboard and Daughtercard EEPROM on USRP Devices (5th August 2020)” The aim is to be able to manipulate some GPIO bits in the block work function and to align events using the 1PPS input. Regards, David GD4FMB From: Marcus D. Leech via USRP-users Sent: Thursday, October 8, 2020 7:53 PM To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] B210 USRP object creation On 10/08/2020 12:51 PM, David Taylor (manx.net) via USRP-users wrote: Thanks Marcus, I have had a look at the GPIO example source. It contains some useful code, but I have not compiled and run it. Other example code in “Synchronising USRP Events using Timed Commands (17 April 2020)” has been used in the OOT block. 1) I have configured my B210(NI) EEPROM with the correct USB vid = 0x2500 and pid = 0x0814. The device is clearly identifiable and usable over USB3. 2). I have tried to identify the USRP using the following code prior to making an object:- uhd:: device_addr_t hint; hint[“serial”] = “3150322”; uhd:: device_addrs_t dev_addrs = uhd:: device::find(hint); 3). Or the following to create the object directly:- uhd::usrp::multi_usrp:: sptr device = uhd::usrp::multi_usrp::make(“vid=0x2500, pid=0x7814”); The codes are placed in the OOT constructor, compile and link with the appropriate headers. In both cases the flow-graph fails to run with the usual ‘block’ attribute error message. There are no USRP source or sink blocks in the flow-graph that could possibly conflict. Regards, David COuld you just use one of the standard test tools like "rx_samples_to_file" and specify "type=b200" in the device arguments? There should NEVER have been any reason to change the VID and PID on the device. ___ 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] B210 USRP object creation
On 10/08/2020 03:33 PM, David Taylor (manx.net) via USRP-users wrote: Point taken. - I didn’t actually check the original default values of the VID and PID, but they were reset according to the table provided, so that they could be tested as arguments in the make statement below. “About the Motherboard and Daughtercard EEPROM on USRP Devices (5th August 2020)” The aim is to be able to manipulate some GPIO bits in the block work function and to align events using the 1PPS input. Regards, David GD4FMB Ok, so presumably you're using Gnu Radio, since you're talking about "block work functions". So this issue straddles the two universes--UHD/USRP and Gnu Radio. I'd encourage you to use the UHD test tools to confirm sanity of your setup and then move on to a stupid-simple flow-graph with standard blocks. Once THAT works, then one can think about grabbing the usrp source/sink "object" and being able to use it in your own processing "block". There used to be a way to do this even within GRC but I fear that it was a custom block (perhaps from the old gr-balint set of blocks) that would allow you to grab an object handle and pass it as a variable into your own functions. It's something I've wanted to do myself from time to time. Of course if you're coding in "naked" GR, without using GRC, it's easy. But GRC uses a "data flow" model, and is less "procedural", so it gives an added layer of abstraction that makes it difficult to do what you want to do. The gr-uhd module provides GPIO functions: https://www.gnuradio.org/doc/doxygen-v3.7.9.1/classgr_1_1uhd_1_1usrp__block.html#ab09502e1c8c43a546616b9a998f137f1 But they aren't exposed in any meaningful way into GRC that I know of. I'll note that in GR3.9, there is support for something called "code snippets" which would let you "dip down into the lower layers" without having to post-facto edit generated Python code. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
