Re: [USRP-users] x300 latency over 10GigE
On Wed, Mar 10, 2021 at 12:39 PM Doug Blackburn wrote:
> Brian,
>
> I've seen this using UHD-3.14 and UHD-3.15.LTS.
>
The DMA FIFO block default size is set here in the source code for
UHD-3.15.LTS:
https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L25
And the interface in the header file provides a way to resize it:
https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/host/include/uhd/rfnoc/dma_fifo_block_ctrl.hpp#L33
I'd probably resize it before sending any data to it.
That should help with your latency question I think.
>
> I have performed some follow-on testing that raises more questions,
> particularly about the usage of end_of_burst and start_of_burst. I talk
> through my tests and observations below; the questions that these generated
> are at the end ...
>
> I thought it would be interesting to modify benchmark_rate.cpp to attempt
> to place a timestamp on each buffer that was sent out to see if I could
> observe the same behavior. I haven't seen thorough explanations of what
> exactly the start_of_burst and end_of_burst metadata fields do at a low
> level beyond this posting --
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-November/050555.html
> and a note about start_of_burst resetting the CORDICs (I'd appreciate being
> pointed in the right direction if I've missed it, thank you!) -- so I
> wanted to test the effect on timing when has_time_spec is true and the SOB
> and EOB fields are either false or true. I initially set my test up in the
> following way (I hope the pseudocode makes sense) to make observations
> easy. I watched for the LO on a spectrum analyzer. Per the code below, I
> would expect a burst every 2 seconds if the time_spec was followed ...
>
> ==
> max_samps_per_packet = 50e5; // 100ms at 50 MSPS
> start_of_burst =
> end_of_burst =
> has_time_spec = true;
> while( not burst_timer_elapsed)
> {
> tx_stream->send();
> start_of_burst =
> end_of_burst =
> time_spec = time_spec + 2.0;
> }
>
A few things. I'd expect a burst every 2 seconds if you set sob = true,
eob = true outside the loop, and never change it and only change the
time_spec for every send. Does that not work for you?
Next, The sizing of packets can be really important here. The way the DUC
works is a little unintuitive. The DUC works by creating N packets from 1
input packet. To this end, if you have an extra 1 sample, it will repeat
that small 1 sample packet N times - very processing inefficient.
Furthermore, when I tried doing this I would run into weird edge cases with
the DMA FIFO where the send() call would block indefinitely. My workaround
was to manually zero stuff and keep the transmit FIFO constantly going -
not using any eob flags at all. My system would actually use a software
FIFO for bursts that wanted to go out, and I had a software thread in a
tight loop that would check if the FIFO had anything in it. If it didn't,
it would zero stuff some small amount of transmit samples (1 packet I
believe). If it did, it would send the burst. You may want to do
something similar even with a synchronized system and counting outgoing
samples.
>
> My observations were as follows: if end_of_burst for the prior burst was
> set to true, my code adhered to the time_spec. The value of start_of_burst
> had no effect on whether or not the expected timing was followed. If
> end_of_burst was set to false, the time_spec for the following burst is
> ignored and the packet is transmitted as soon as possible.
>
> I then followed this up with another test -- I replaced
> time_spec = time_spec + 2.0;
> with the equivalent of
> time_spec = time_spec + 0.100;
>
> And set end_of_burst and start_of_burst to true.
>
> I figured if I can run this continuously by setting has_time_spec to
> 'false' after the first burst and easily push data into the FIFO buffer,
> that doing this should not be a problem ... but I'm presented with a stream
> of lates and no actual transmission.
>
> I understand that 100ms is not an integer multiple of packet size returned
> by get_max_num_samps() -- so I tried an integer multiple of the packet
> size, too, with an appropriately updated time_spec. This also resulted with
> a lates through the entire transmit.
>
> So here are my additional questions:
>
> Is the only effect of "start_of_burst = true" to cause the CORDICs to
> reset?
> What is end_of_burst doing to enable a following time_spec to be used?
> What additional work is being performed when I set end_of_burst and
> has_time_spec to 'true' such that I get latest throughout the entire
> attempted transmission?
>
I don't know the answer to these questions. Try the suggestions above and
see if they help you out or not.
Good luck!
Brian
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] x300 latency over 10GigE
On Tue, Mar 9, 2021 at 10:03 PM Doug Blackburn via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello --
>
> I've got some questions re: latency with the x300 over the 10GigE
> interface.
>
> If I use the latency_test example operating at a rate of 50 MSPS, I have
> no issues with a latency of 1ms. The latency test receives data, examines
> the time stamp, and transmits a single packet.
>
> I have an application where I'd like to run the transmitter continuously,
> and I got curious about the latency involved in that operation. My
> application is similar to the benchmark_rate example. I added the
> following lines to the benchmark_rate example at line 256 after the line.
>
> md.has_time_spec = false;
>
>
> if ( (num_tx_samps % 5000) < 4*max_samps_per_packet )
> {
> uhd::time_spec_t expectedTime = startTime + (double) ( num_tx_samps )
> / (double)usrp->get_tx_rate();
> uhd::time_spec_t timeAtLog = usrp->get_time_now();
> timeAtLog = usrp->get_time_now();
> std::cerr << " Actual time " << std::endl;
> std::cerr << " " << timeAtLog.get_full_secs() << " / "
> << timeAtLog.get_frac_secs() << std::endl;
> std::cerr << " Expected time " << std::endl;
> std::cerr << " " << expectedTime.get_full_secs() << " / "
> << expectedTime.get_frac_secs() << std::endl;
> }
>
>
> The intent of this insertion is to log the time at which we return from
> tx_stream->send() and the time at which the first sample of that sent data
> should be transmitted -- at approximately once per second when running at
> 50 MSPS.
>
> After the first second, I consistently saw the following results:
>
> Actual time
> 1 / 0.10517
> Expected time
> 1 / 0.27253
>
> Actual time
> 1 / 0.105419
> Expected time
> 1 / 0.27255
>
> Which indicates to me that there is a latency of approximately 167ms when
> transmitting data. That is, the send() function is returning 167ms earlier
> than I expect the data to actually be transmitted. If I halve the sample
> rate to 25 MSPS, the latency doubles.
>
> What is the source of the latency when running in a continuous mode?
> Initially, I had thought that this might be related to the
> send_buffer_size, but making changes to send_buffer_size seem to not have
> an effect. FWIW, 167ms at 50 MSPS is suspiciously close to the value for
> wmem_max (33554432) suggested in the x300 system configuration ... but
> neither changing that value or send_buffer_size seems to make a difference.
>
> Is this latency tunable?
>
I suspect it's the DMA FIFO which uses the DRAM in the X310 as a buffer.
The default buffer size is 32MB.
Which version of UHD are you using?
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC 4 rfnocmodtool
On Thu, Feb 4, 2021 at 1:15 PM Askar, Ramez via USRP-users < usrp-users@lists.ettus.com> wrote: > Dear Sir or Madam, > > > > I would like to use one of the available FPGA blocks from Ettus – such as > FIR filter -- to customize my FPGA image, and add the corresponding control > driver for C++ application and Gnuradio. However, after creating newmod > with rfnocmodtool, I have tried to add fir filter block, the tool is not > aware about the existing blocks. Instead, the rfnocmodtool has created a > module from scratch called FIR. In other words, it did not import the FIR > module that is offered by Ettus team. Is there any other way of doing this? > How can add a OOT RFNoC FIR control module to gnuradio? > Your request is a little confusing. Do you mind clarifying? Do you want to build a new FPGA image with the RFNoC FIR that Ettus already made, or do you want to create your own custom module which uses a Xilinx FIR filter from their FIR compiler? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc questions:
On Sun, Aug 16, 2020 at 9:35 AM Daniel Ozer via USRP-users < usrp-users@lists.ettus.com> wrote: > first of all thanks for the great answers, > still i have few questions: > > 1. Is the crossbar is capable to transfer data between 2 rfnoc blocks at > maximum rate of the crossbar clock ?(bus_clk=187.5MHZ) > > > "Yes. Each port can handle 200MHz worth of bandwidth, but it cannot > handle full bandwidth from both radios at the same time. You'd need > multiple crossbar ports for that." > Why is the crossbar not capable of handling both radio blocks full > bandwidth at the same time? if each radio block is a different instance it > seems like it should work. > The crossbar is capable of doing it, but one single port on the crossbar can't process all the bandwidth. Figure it's 187.5 MHz at 64-bits wide (8 bytes). That's a total of 1500 MBytes/sec that can be transferred. A single channel that consists of 200 MHz of bandwidth, with I and Q both consisting of 16-bits - so 4 bytes total - is 800 MBytes/sec. Add in another channel, and the single ports bandwidth has been exceeded. Does this make sense to you? > > 3. I have a chain : rfnoc: signal source -> rfnoc: DUC (1M to 200M) -> > rfnoc:radio_block. > how is it possible that the connection between the duc and the radio block > doesn't throw an error because the transfer rate is bigger than the clk > speed of the crossbar ? > > > "The bus widths are different between the two domains. Most everything on > ce_clk is 32-bit IQ samples, whereas the bus_clk domain is 64-bits wide." > I tried to find inside the pre-made rfnoc block such as DUC where 2 IQ > 32bit samples are coupled to 64bit bus and i didn't find . Are the samples > supposed to be coupled before leaving the rfnoc block or it something that > i should implement in my block? > It's handled in the axi_wrapper here: https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/axi_wrapper.v > > > "An easy way to decrease the latency, at the expense of more overhead, is > to simply decrease the packet size. (There's some lower limits here... a > packet size of like 4-10 would probably be troublesome, but I've heard > 60ish is a reasonable number and should decrease latency down to 300 > nanoseconds or so assuming ce_clk 200 MHz) " > How can i decrease the size of the packet in the noc_shell? > SPP is a parameter you can pass into the host code and it should try to limit the sizes of things. You can also force it by instantiating a packet_resizer: https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/packet_resizer.v ... but I would really think about the requirement. There's a header associated with each packet, and the more headers you put on, the lower efficiency you get. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc questions:
On Tue, Aug 11, 2020 at 6:18 AM Daniel Ozer via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi everyone,
> Im just started developing on the usrp X310 platform and i have some
> questions :
>
> 1. Is the crossbar is capable to transfer data between 2 rfnoc blocks at
> maximum rate of the crossbar clock ?(bus_clk=187.5MHZ)
>
Yes. Each port can handle 200MHz worth of bandwidth, but it cannot handle
full bandwidth from both radios at the same time. You'd need multiple
crossbar ports for that.
>
> 2. if i have this theoretical chain : rfnoc: block1 -> rfnoc: block2 ->
> rfnoc: block3 -> rfnoc: block4
> Is every block can send data to the next block at the maximum rate of the
> crossbar clk ?
>
Yes. The crossbar acts as a switch.
>
> 3. I have a chain : rfnoc: signal source -> rfnoc: DUC (1M to 200M) ->
> rfnoc:radio_block.
> how is it possible that the connection between the duc and the radio block
> doesn't throw an error because the transfer rate is bigger than the clk
> speed of the crossbar ?
>
The bus widths are different between the two domains. Most everything on
ce_clk is 32-bit IQ samples, whereas the bus_clk domain is 64-bits wide.
>
> 4. Is it possible to change the crossbar clk to ce_clk=214MHZ instead of
> bus clk ?
>
Maybe, but what would be the point? You'll probably end up not being able
to close timing on the design, but that's just a guess.
>
> 5. I saw in the article (" Measured Latency Introduced by RFNoC
> Architecture" )that the nocshell and the axi wrapper have a big latency
> (100nanosec and 1.7microsec) . There is a way to drop down the latency ?
>
I don't know how to address this. Maybe a link to the article and to
figure out where the "large" latencies are? What is your target latency?
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
On Thu, Aug 6, 2020 at 2:28 PM Jerrid Plymale wrote: > I am seeing a signal strength between -65 and -70 dBm, approximately, even > when transmitting all 0’s. > If you really can't handle any LO leakage, can you switch off-frequency between times you want to transmit? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
On Thu, Aug 6, 2020 at 2:02 PM Jerrid Plymale via USRP-users < usrp-users@lists.ettus.com> wrote: > It does, and actually it has a strength closer to -70 dBm, I had my > markers in the wrong place when I thought the signal was at -100 dBm. > If you transmit all 0's with the gain turned all the way down, what strength do you see coming from the radio on the carrier? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Considerations on resampling inside USRP firmware
On Tue, Jul 14, 2020 at 3:30 PM Richard J. Muri via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > > > I’m working on a project using x310s where different stakeholders desire > different sampling rates, some of which are not natively support by the > x310. One stakeholder wants to put a fractional resampling filter at the > ingress and egress of the FPGA inside the USRP. > > > > For instance, I may be running the USRP at 50 MHz sampling rate. I have an > application that requires a 40 MHz sampling rate. I want to send 1000 > samples (from my application perspective) loopbacked from TX/RX to RX2. > Does it make sense to put a 5/4 upsampler on the transmit chain inside the > FPGA, and then a 4/5 downsampler on the receive? I’m hoping that if I use > the software I have already written as before, the scenario plays out as > follows: > > > > 1. Initialize the USRP to a 50 MHz sampling rate. > > 2. Set md.time_spec using a clock domain agnostic method (e.g. set > it using integer seconds, double fractional seconds). > > 3. Call tx_streamer->send(txbuffer, 1000 samples, md, 0 timeout) in > my TX thread. > > 4. Call rx_streamer->recv(rxbuffer, 1000 samples, md, 0 timeout) in > my RX thread. > > 5. The 1000 sample TX packet hits the upsampler, gets converted to > 1250 samples. > > 6. The USRP works as normal and puts the 1250 samples through the > full TX/RX chain, at the time specified in the metadata timespec (rounded > to whatever nearest tick count can actually be represented by the 20 ns > clock period) > > 7. The 1250 sample receive hits the downsampler, gets converted to > 1000 samples. > > 8. My software gets 1000 samples into rxbuffer > > > > I’m not terribly familiar with the internal workings of the Verilog > firmware. Are there issues I may be missing? Does the custom firmware need > to intercept the CHDR and change the 1000 samples to 1250, or is the 1000 > only used by software for the network communication? > Rational resampling can work with all the tools that Ettus has already provided. I am in the process of putting the finishing touches on a 2/3 and 3/2 resampler for the X310. I will make it publically available very soon. Let me know if you think this will help you. The DUC and DDC do rate changing, so looking at those as examples, you'll notice that really the big thing to do is check out the axi_rate_change block: https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/noc_block_ddc.v https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/noc_block_duc.v https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/axi_rate_change.v For blocks with fixed rates, check out the DEFAULT_N and DEFAULT_M parameters for the Verilog. This eliminates the need to set a register in software, and the logic in the axi_rate_change block is ready to go at reset. Be sure to simulate the block fully beforehand, but that should do it all for you. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] x300 Timeout errors on receiving continuous stream (w/ Redhawk SDR)
On Thu, Jul 2, 2020 at 3:02 PM Lawrence L Elentukh via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > I am experiencing issues where the uhd::recv() function returns a series > of unrecoverable timeout errors, I have seen similar questions on the > mailing list but none that have been resolved or whose resolution helped > me. The front end interfacing with the USRP connects to the device and runs > using STREAM_MODE_START_CONTINUOUS, continually receiving samples. Then our > codebase connects to it via redhawk's waveform connections and the redhawk > usrp_uhd front-end pushes the samples received downstream to our receiver. > The issue is that after a few runs of our code (which doesn't start or stop > the stream from the redhawk frontend), I end up getting time-out errors > from the uhd::recv() return code, and all subsequent attempts to receive > samples see this error. Information about the system is as follows: > > USRP: x310 > Interface: 10GigE, with appropriate MTU and network memory configurations > Sampling Rate: 200e6/6 (33.33MHz) > Single channel Rx > UHD Version: 3.15.LTS > > I am using the Redhawk SDR as a platform, with our own code base as a > receiver, and am attempting to make changes to both my local copy of the > redhawk-usrp_uhd front-end tuner component and our own code to resolve this > issue, however all interactions with UHD are through the redhawk component > (which can be found here: > https://github.com/RedhawkSDR/USRP_UHD/blob/master/cpp/USRP_UHD.cpp#L1582) > > Things I have tried: > * Starting/Stopping stream between receiver runs > * Increasing receive timeout (up to 1 sec) > * Resetting metadata between receives > * Clearing buffers (dropping samples) when not running receiver > > Note: I am able to run the receiver without issue on the first few runs > (for durations up to 20 minutes), however after 3-5 runs, all further runs > end up reporting timeout errors. > This seemed to happen to me if I don't explicitly shut down the stream and keep reading until I get timeouts or no samples received for all streams. Does your application stop the reception of samples explicitly? If so, do you keep reading the samples until they timeout and return 0 samples? Give that a shot and see if it helps. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] AM transmission
On Tue, Jun 23, 2020 at 12:08 PM Marcus D Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > Phase offset as measured against what, and how would that matter for a > not-phase-sensitive modulation? > Maybe the 9361 on the B205 could be attacking the AM as an adaptive DC offset correction. Maybe a low-IF approach should be used to see if the problem goes away? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Multiple DMA_FIFO blocks
On Thu, May 21, 2020 at 2:25 PM Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com> wrote: > Thank you for the response Brian :) > > The throughput is about 11MSamples. > What about to use the AXI_FIFO_LOOPBACK? > No idea about that. Someone else will have to weigh in. Good luck! Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Multiple DMA_FIFO blocks
On Thu, May 21, 2020 at 1:55 PM Carlos Alberto Ruiz Naranjo via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > Is it possible to instance multiple DMA_FIFO blocks? I suppose I have to > do it manually in the x300_core.v. Is there any limitation? > You might need to make more ports on the DDR3 controller. You'll ultimately be limited by the DDR3 controller for throughput. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc build standard image x310 failing
On Wed, May 20, 2020 at 8:35 PM Hodges, Jeff via USRP-users < usrp-users@lists.ettus.com> wrote: > Can someone please tell me what version of uhd and rfnoc are compatible > for building an image on Ubuntu 18.04? > > > > I cannot get any of the UHD releases to properly build a standard rfnoc > image. > > > > sudo ./uhd_image_builder.py fft ddc duc -g -t X310_RFNOC_HG -c -d X310 > --fill-with-fifos > > > > I installed vivado 2018.3 with uhd 3.15.0.0 and get the error: > > > > ERROR: [DRC MDRV-1] Multiple Driver Nets: Net bus_clk_gen/inst/CLK_OUT4 > has multiple drivers: radio_clk_gen/inst/clkout1_buf/O, and > bus_clk_gen/inst/clkout4_buf/O. > > ERROR: [DRC MDRV-1] Multiple Driver Nets: Net > radio_reset_sync/reset_double_sync/synchronizer_false_path/value[9]_9 has > multiple drivers: > radio_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q, > and > ce_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q. > This looks like the problem with uhd_image_builder.py assigning clocks. It should have been fixed most likely here with this commit for the generated code: https://github.com/EttusResearch/fpga/commit/9fb84a15ab8f31e3c056845d2d063a9cc745443e#diff-4ec1b7f14325d1af5ce8a749d9274b29 Can you check to see if your rfnoc generated files have ce_clk = radio_clk in them? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP X310 sample rate of 184.32 MHz
On Mon, May 11, 2020 at 6:20 AM Carlos Alberto Ruiz Naranjo via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > I'm using the USRP X310 with CBX-120. I set the radio sample rate to > 184.32 MHz but I have the following message: > > [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: > 184.32 MHz. Actual rate is: 200 MHz. > > Isn't it possible to set it to that sample rate? > You need to set the master_clock_rate in the arguments of the USRP to be 184.32MHz. https://files.ettus.com/manual/page_configuration.html Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] TX underflows when using multi_usrp vs. two independent tx_streamers
On Thu, May 7, 2020 at 2:58 PM Max via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Michael, > > thank you for the feedback. > Unfortunately the X300 offers just one SFP+, so combining two links > should not be possible. I also don't think the network interface itself > is the bottleneck, considering two independent processes don't seem to > have a problem providing the data. > You can use a dual 10Gbe FPGA image and get dual links on the X300. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Clock Rate problem on N300
On Thu, May 7, 2020 at 11:33 AM Jean Marie Brieussel via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > Normally, the N300 has three programmable clock rate frequencies, 122.88 > MHz / 125 MHz / 153.6 MHz on my N300 I can't seem to have another clock > rate than 125 MHz. See the attached screenshot. > I believe the clock rate and sample rates are different. What are you trying to do? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Setting up an X310 as a signal generator
On Fri, May 1, 2020 at 1:49 PM Jerrid Plymale wrote: > Brian, > > > > I realized I forgot to mention, I am using the multi_usrp API and not the > RFNoC API, so I am actually unable to use the DRAM FIFO. Do you have any > suggestions, or should I work on transitioning the signal generator to an > RFNoC installation of UHD? > I am a little biased since I am more of an FPGA guy than most, so I like the RFnoC API. I am not sure if the DRAM FIFO is used in the multi_usrp API - someone from Ettus might have more information, or there is the code to look at as well. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Setting up an X310 as a signal generator
On Fri, May 1, 2020 at 1:23 PM Jerrid Plymale via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello All, > > > > So I have been trying to set up a USRP X310 as a signal generator for > about a week now, and I’m having some issues. Currently I am using > gnuradio-companion to develop the functionality. I have three sets of > signal sources that are of float type, creating the I and Q values that get > passed to a float to complex block. The output of the three float to > complex blocks go to an add block, which then outputs to a USRP sink. > Currently, the first problem is with underruns, I’m not getting a lot of > them however I am getting breaks in the signal when I pass it to a second > USRP X310. What would be the best approach to make sure my signal is coming > in strong to the second USRP? I am also having issues with increasing the > power of the signal when it is received, is this mainly controlled by the > gain value on the USRP source in gnuradio? What can I do to get my incoming > signal to have more power? > You can try placing a DRAM FIFO in your transmit flow graph as the first thing. That should ensure some tens of milliseconds worth of buffering for your signals and allow for some host jitter without underruns. Do you have an external spectrum analyzer or something that can tell you the power output of the first radio? The receivers should be able to be saturated by your transmitter, so there's definitely a gain issue somewhere. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Modifying RFNoC ddc block for 16 parallel instances
On Wed, Apr 22, 2020 at 6:17 PM Snehasish Kar wrote: > Hello Brian > > Thanks for your response, actually I tried using DDC 1 to n block as given > here, but giving 1 to 8 channels have a timing issue, while generating the > build. So I thought it as an alternative plan. > > > https://gitlab.com/theseus-cores/theseus-cores/-/blob/master/fpga-rfnoc/README.md#dsp-utilsnoc_block_ddc_1_to_n > What was the timing issue? Is it possible for you to break up the logic to help relax timing constraints? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Modifying RFNoC ddc block for 16 parallel instances
On Wed, Apr 22, 2020 at 6:00 PM Snehasish Kar via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello > > I need to have input 16 input and output port from the RFNoC so that I can > custom sample rate for each channel. Is it possible to modify the RFNoC DDC > block and split stream block to achieve this. > Probably not successfully. They are too large by themselves to just instantiate 16 of them. Moreover, having lots of output ports on a block is not really well supported from my experience. Lastly, having 16 blocks just isn't going to work. The crossbar doesn't have enough ports. You're better off making a block with 1 input and 16 outputs, but, as I mentioned before, that is still potentially problematic. Also, the split stream is pretty finicky. I don't believe it conforms to the AXI spec and might cause lockups. Lastly, you need to make sure you adhere to the ~200MHz/AXI port rule of thumb. Do you have a block diagram of what you're trying to achieve? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Cygwin build of E310_SG3
On Mon, Apr 20, 2020 at 2:24 PM Harris, Dan via USRP-users < usrp-users@lists.ettus.com> wrote: > > > Is the windows Cygwin build of the E310_SG3 target being maintained? > > > > I have been following the build instructions and have Vivado 2019.1 > installed. It is failing in multiple points in the generation of the IP. > I had to correct some paths that should have been windows-ized but did not > seem to be in tools/make/viv_hls_ip_builder.mak. > > > > I can build at least one of the components (IP fifo_short_2clk), so I am > somewhat confident that Vivado is installed correctly, and that my ‘source > setupenv.sh’ was done properly. > This seems strange. You need to have Vivado 2018.3 installed for the setupenv.sh to run properly. Try installing 2018.3 and ditching 2019.1 first. Also, just as a point of reference, I've successfully used WSL (linux on windows) to install Vivado and build successfully. Running in cygwin sounds like a real pain, and I fully recommend linux (native or wsl) for building. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UBX 10-500 MHz Question
On Wed, Apr 8, 2020 at 5:49 PM Tillson, Bob (US) via USRP-users < usrp-users@lists.ettus.com> wrote: > so with the UBX-160 on an X310, there is the following caveat: > > > > * The UBX 160 transmitter path has 160 MHz of bandwidth throughout the > full frequency range of the device; the receiver path has 84 MHz of > bandwidth for center frequencies from 10 MHz to 500 MHz. > > > > I guess my question is how does this manifest itself? > Check the schematic block diagram: https://files.ettus.com/schematics/ubx/ubx.pdf > > > If I ask for 100 MHz of BW, do I get 84 or does it fail? > > > > How would I get 84 given the requirement of sample rate be an even divisor > of 200 MHz clock? > > > > If I wanted 100 in that range, would there be any way to get it from a > single channel in that band? Most other cards don’t seem to have the BW in > that range. > It shouldn't fail, and you will just get filtered output. They're just analog filters in the signal path. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to get to know when my buffer is sent?
On Sun, Mar 8, 2020 at 2:15 PM Marek Dopiera wrote: > On 08/03/2020 00:49, Brian Padalino wrote: > > On Sat, Mar 7, 2020 at 6:02 PM Marek Dopiera via USRP-users > > mailto:usrp-users@lists.ettus.com>> wrote: > > I had to do this recently with an X310 application. Originally I tried > > timed bursts where I would give the full burst to UHD and hope it would > > get things sent since the burst was supplied all at once. This was not > > my experience and exposed some bugs which may still be outstanding. > > > > My next approach was to simply have a writer thread which would check a > > transmit buffer/FIFO and, if there was nothing to transmit, would stuff > > a minimal amount of zeros into the data stream. This call to send() of > > the zero stuffed data would fill up the buffers downstream on the device > > until the backpressure from the device naturally limited the > > transmission. This approach worked very well for my application. It > > kept the minimal buffering with almost no overhead and I knew the > > latency through the system was basically the amount of time to consume > > the buffer. > > Hi Brian, > thank you for your response. > > I'm doing pretty much what you described - a FIFO with separate threads, > and pushing to tx_stream::send until it blocks. In my case I'm actually > sending data, not zeros, though. > > I do not have control over how much data gets into the buffers before > tx_streamer::send() starts blocking, though - I'm guessing I can go > lower than that, but for that to work I need to know when the data is > actually sent. > The amount of buffering (software) should be controllable via arguments to UHD, and the amount of buffering in the hardware should be fixed based on which product you're using. Just for clarity, the reason for sending zeros is to maintain and keep a stream with no underflows as well as keep the buffering pipeline full since getting UHD to try to be responsive to sending bursts at a high sample rate without underflows didn't work well for me. What type of response time are you looking for when it comes to sending data versus nothing? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to get to know when my buffer is sent?
On Sat, Mar 7, 2020 at 6:02 PM Marek Dopiera via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > I would like to know when the buffer submitted via > uhd::tx_streamer::send() is actually sent. The reason I need this is to > keep some data outstanding not to starve the device, but make sure there > is as little of it as possible (a large backlog buffered somewhere > wouldn't allow me to change what I'm sending at the last moment, which > is my use-case). > > I'm asking you for help, because I can't find a good way to do it. > > So far, I've come up with these options: > 1. Artificially chop the stream into contiguous bursts and use > tx_streamer::recv_async_msg returning EVENT_CODE_BURST_ACK to get to > know when data actually gets sent. I'm guessing it's unwise to rely on > contiguous bursts being sent together, though, right? > > 2. Use the system clock to estimate how much data is outstanding. I'm > guessing that clock drift will be my enemy here, so it will get tricky. > > Neither of the options sounds like a good idea to me. Do you have any > ideas how to cope with it? > I had to do this recently with an X310 application. Originally I tried timed bursts where I would give the full burst to UHD and hope it would get things sent since the burst was supplied all at once. This was not my experience and exposed some bugs which may still be outstanding. My next approach was to simply have a writer thread which would check a transmit buffer/FIFO and, if there was nothing to transmit, would stuff a minimal amount of zeros into the data stream. This call to send() of the zero stuffed data would fill up the buffers downstream on the device until the backpressure from the device naturally limited the transmission. This approach worked very well for my application. It kept the minimal buffering with almost no overhead and I knew the latency through the system was basically the amount of time to consume the buffer. Good luck. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Run time issue with 3.14.1.1 (X300 with UBX)
On Mon, Jan 13, 2020 at 5:23 AM voonna santosh via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Sam, >I have managed to reproduce this issue and when it happens, here is the > info you have asked for: > > > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: enp3s0f0: mtu 9000 qdisc mq state UP > group default qlen 1000 > link/ether 00:e0:4b:6b:0c:41 brd ff:ff:ff:ff:ff:ff > inet 192.168.40.20/24 brd 192.168.40.255 scope global noprefixroute > enp3s0f0 >valid_lft forever preferred_lft forever > inet6 fe80::2e0:4bff:fe6b:c41/64 scope link >valid_lft forever preferred_lft forever > 3: enp3s0f1: mtu 1500 qdisc mq state > DOWN group default qlen 1000 > link/ether 00:e0:4b:6b:0c:42 brd ff:ff:ff:ff:ff:ff > 4: enp8s0: mtu 1500 qdisc mq state > DOWN group default qlen 1000 > link/ether 00:0c:8b:71:75:78 brd ff:ff:ff:ff:ff:ff > 5: enp15s0: mtu 1500 qdisc mq state UP > group default qlen 1000 > link/ether 00:e0:4b:6b:0c:43 brd ff:ff:ff:ff:ff:ff > inet 192.168.10.20/24 brd 192.168.10.255 scope global noprefixroute > enp15s0 >valid_lft forever preferred_lft forever > inet6 fe80::2e0:4bff:fe6b:c43/64 scope link >valid_lft forever preferred_lft forever > 6: virbr0: mtu 1500 qdisc noqueue > state DOWN group default qlen 1000 > link/ether 52:54:00:07:9b:55 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 >valid_lft forever preferred_lft forever > 7: virbr0-nic: mtu 1500 qdisc pfifo_fast master > virbr0 state DOWN group default qlen 1000 > link/ether 52:54:00:07:9b:55 brd ff:ff:ff:ff:ff:ff > Usually when I see this happen, there has been a drop or an error on the interface. Can you also give the output using the -s flag, so ip -s a? Look for some non-zero number in errors or dropped columns. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Measuring TDOA for Localization
On Thu, Jan 9, 2020 at 6:45 PM Richard Bell wrote: > No I don't need to know phase information. I'm cross correlating the pairs > of receivers and the location of the peak gives me the TDOA. If the > hardware chains across different radios introduce different delays, that > would invalidate the TDOA measurement. So long as the delay is the same > through all the hardware chains, the TDOA estimate will be accurate. Can I > assume the hardware delay through X300 USRPs with the same FPGA image and > set to the same sampling frequency will be the same? > I'd think the group delay should be pretty consistent - at least within 10's of nanoseconds of each other if the setup is identical. What type of variation are you seeing when you perform your cross correlations? How much variation are you able to handle? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Measuring TDOA for Localization
On Thu, Jan 9, 2020 at 12:14 PM Richard Bell via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > I'm working on a TDOA based localization platform using 3 USRP X300's as > receivers. I have them synchronized with a 10 MHz ref and PPS signal > generated by an OctoClock. However, I'm having trouble getting reliable > localization performance through this system. My TDOA measurements are not > what I would expect for the geometry I'm using. > > If I have the USRPs flashed with the same FPGA image and I use the same > sample rate (i.e. 200e6/22 = 9.0909 MHz) across them all, is it possible > the hardware could still be introducing different delays through each > receiver? > Did you calibrate their phases using some type of calibration signal such that you know the relative phase offsets of each radio to each other? Do you need to not know this information? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC Image with OOT Module on X310 - Module not found
On Wed, Jan 8, 2020 at 8:00 AM Felix Greiwe via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi EJ,
>
> thank you for your answer! To make my error more traceable, I created a
> new OOT Module and added the default gain block from rfnoc getting
> started.
>
> I also took your advice and looked at the uhd_image_builder.py script. I
> noticed very strange behaviour, because my print statements suggested,
> that the script did not include my makefile.srcs because it first edited
> the path
>
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/ to
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/rfnoc and a bit later to
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/rfnoc/rfnoc/fpga-src/ .
>
> As you can see two rfnoc's here hence it did not find the makefile.src in
> /fpga-src. The changes (marked with fgr) in the create_oot_include
> here seem to resolve the issue, hopefully helpful for other people too and
> maybe even a major bug?:
>
> def create_oot_include(device, include_dirs):
> """
> Create the include file for OOT RFNoC sources
> """
> oot_dir_list = []
> target_dir = device_dict(device.lower())
> dest_srcs_file = os.path.join(get_scriptpath(), '..', '..', 'top',\
> target_dir, 'Makefile.OOT.inc')
> incfile = open(dest_srcs_file, 'w')
> incfile.write(OOT_SRCS_FILE_HDR)
> if include_dirs is not None:
> for dirs in include_dirs:
> currpath = os.path.abspath(str(dirs))
> if os.path.isdir(currpath) & (os.path.basename(currpath) ==
> "rfnoc"):
> # Case 1: Pointed directly to rfnoc directory
> oot_path = currpath
> elif os.path.isdir(os.path.join(currpath, 'rfnoc')):
> # Case 2: Pointed to top level rfnoc module directory
> oot_path = os.path.join(currpath, 'rfnoc')
> elif os.path.isfile(os.path.join(currpath, 'Makefile.inc')):
> # Case 3: Pointed to a random directory with a Makefile.inc
> oot_path = currpath
> else:
> print('No RFNoC module found at ' +
> os.path.abspath(currpath))
> continue
> if oot_path not in oot_dir_list:
> oot_dir_list.append(oot_path)
> named_path = os.path.join('$(BASE_DIR)',
> get_relative_path(get_basedir(), oot_path))
> incfile.write(OOT_DIR_TMPL.format(oot_dir=named_path))
> if os.path.isfile(os.path.join(oot_path, 'Makefile.inc')):
> # Check for Makefile.inc
> incfile.write(OOT_INC_TMPL)
> elif os.path.isfile(os.path.join(oot_path, 'rfnoc',
> 'Makefile.inc')):
> # Check for Makefile.inc
> incfile.write(OOT_INC_TMPL)
> #elif os.path.isfile(os.path.join(oot_path, 'rfnoc',
> 'fpga-src', 'Makefile.srcs')): # Original
> elif os.path.isfile(os.path.join(oot_path, 'fpga-src',
> 'Makefile.srcs')): # Anders fgr
> # Legacy: Check for fpga-src/Makefile.srcs
> # Read, then append to file
> # curr_srcs = open(os.path.join(oot_path, 'rfnoc',
> 'fpga-src', 'Makefile.srcs'), 'r').read() # Original
> curr_srcs = open(os.path.join(oot_path, 'fpga-src',
> 'Makefile.srcs'), 'r').read() # Anders fgr
> # curr_srcs = curr_srcs.replace('SOURCES_PATH',
> os.path.join(oot_path, 'rfnoc', 'fpga-src', '')) #
> Original
> curr_srcs = curr_srcs.replace('SOURCES_PATH',
> os.path.join(oot_path, 'fpga-src', '')) # Anders fgr
> print('Searching for Makefile.srcs: ' + curr_srcs) #fgr
> incfile.write(OOT_SRCS_TMPL.format(sources=curr_srcs))
> else:
> print('No valid makefile found at ' +
> os.path.abspath(currpath))
> continue
>
> However 30 minutes later in the build I got the next errror and again have
> no idea what to do. My command was:
>
> ./uhd_image_builder.py gain ddc fft -I
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/ -d x310 -t X310_RFNOC_HG -m 6
> --fill-with-fifos
>
> Using Vivado 2018.3 and UHD 3.15.0.0-124-geb448043
>
>
> Erros are:
>
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net bus_clk_gen/inst/CLK_OUT4
> has multiple drivers: radio_clk_gen/inst/clkout1_buf/O, and
> bus_clk_gen/inst/clkout4_buf/O.
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net
> radio_reset_sync/reset_double_sync/synchronizer_false_path/value[9]_9 has
> multiple drivers:
>
> ce_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q,
> and
>
> radio_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q.
> ERROR: [Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design not run.
> ERROR: [Common 17-39] 'opt_design' failed due to earlier errors.
> [00:24:46] Current task: DRC +++ Current Phase: Starting
> [00:24:46] Current task: DRC +++
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
On Fri, Jan 3, 2020 at 1:41 PM Cherif Diouf wrote: > I have this version UHD 3.15.0.git-84-g164d76dc > > but the lines are there whenever you use the ./uhd_image_builder.py > scripts. > Ah, I see it now: https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/tools/scripts/uhd_image_builder.py#L44 Someone at Ettus should probably stop assigning those clocks. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
On Fri, Jan 3, 2020 at 1:14 PM Cherif Diouf via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Jerrid, > > > > Some hints, for info, I am working with the X310 device, but you can > take the big picture. > > > I previously met such issues, those were related to signal re-definitions. > > > The file *rfnoc_ce_auto_inst_x310.v* at lines 19/20 is re-defining the > ce_clk/ce_rst signals by assigning to them radio_clk/radio_rst signals. > The issue here is that ce_clk is a clock of its own and is already defined > in the top block file *x300.v* at lines 259 and 290. My filepath is > rfnoc/src/uhd-fpga/usrp3/top/x300/. > In the 3.15.0.0 code on github I don't see what you're talking about: https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/top/x300/rfnoc_ce_auto_inst_x300.v Looking at the history of the file, it looked like that might have been removed way back in 2016 in commit c98bc14fe0ea2c27a5629a24d47915eb7e0b6700. Jerrid - do you have those lines that Cherif is describing? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
On Thu, Jan 2, 2020 at 11:48 AM Jerrid Plymale wrote: > I am trying to generate a custom RFNoC FPGA Image using this version of > UHD. > OK. So you've checked out fde2a94eb7231af859653db8caaf777ae2b66199 and you're trying to build a regular image with Vivado 2018.3. Correct? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
On Thu, Jan 2, 2020 at 11:42 AM Jerrid Plymale wrote: > Hello Brian, > > > > I have installed UHD 3.15.0.0-124-geb448043 > And this is what you're trying to build? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
On Thu, Jan 2, 2020 at 11:24 AM Jerrid Plymale via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello Marcus, > > So I tried cleaning the uhd-fpga folder as you suggested, however I ended > up getting the same errors and the image still failed to build. I have > attached the build log again in case there was a change within it. > What version of UHD are you trying to build? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IQ-sample with a magnitude larger than 1.0
On Tue, Dec 3, 2019 at 1:53 PM Jeff S wrote: > I'm fairly new to GNURadio, so I may have (most likely) missed it, but I > had the same problem that was fixed by multiplying the complex number going > into my sink by 0.25 to get my QPSK modulation to work on my X310. Since > doing that, I have found references to over driving the TX on this list. > Is the [1, -1] limit an Ettus device limit, or is it a GNURadio limit? And > where is that documented (so I can maybe find what else I'm missing)? > Ettus radios. Normalized complex values: https://files.ettus.com/manual/page_stream.html#stream_datatypes_cpu If the values aren't normalized, it seems difficult to try to figure out what "full scale" means. Right? > > Also, it seems like the consensus is that going [1,-1] is still too much, > and going less than 0.707 may be better. > 3dB sounds like a lot to drop, but 0.1dB or even 0.5dB is probably just fine. This is just the level coming out of the DAC. Further amplification down the line might cause other non-linearity issues, but overall you probably want to exercise as much dynamic range as possible. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IQ-sample with a magnitude larger than 1.0
On Thu, Nov 21, 2019 at 2:49 PM Lindstedt, Ralf via USRP-users < usrp-users@lists.ettus.com> wrote: > We are transmitting samples in bursts of 15360 samples(1ms @ > 15.36Msamples/s). When the magnitudes of the transmitted samples are mostly > larger than 1.0, the received signal, especially the beginning is distorted. > Definitely not recommended. > > > My assumptions is that this distortion happens on the transmitter side. Is > this correct, and if what exactly happens with the data? > Clipping/saturation in the Ettus radios, I believe - but it should be noted that you should be able to transmit > 1.0 magnitude so long as either I or Q being sent isn't larger than 1.0 - but I still don't recommend that either. Which Ettus product and why are you transmitting > 1.0, if you don't mind me asking? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues with RFNoC Component Test Bench
Hey Jon,
On Wed, Nov 13, 2019 at 11:17 AM Jonathan Lockhart
wrote:
> Greetings Brian,
>
> I had noticed that the script was set to use the X300 after I sent the
> email. I switched in the CMakeList.txt file to use the e300 repo, which is
> using the Zynq-7020, which is included in the webpack version of Vivado. I
> unfortunately got the same error prior to the change, included below.
>
> ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
> noc_block_gain_tb
> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>
> Environment successfully initialized.
> BUILDER: Checking tools...
> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
> * Python 2.7.15+
> * Vivado v2017.4.1 (64-bit)
>
> ** Vivado v2017.4.1 (64-bit)
> SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
> IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
>
> CRITICAL WARNING: [Common 17-741] No write access right to the local Tcl
> store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
> XilinxTclStore is reverted to the installation area. If you want to use
> local Tcl Store, please change the access right and relaunch Vivado.
> source
> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
>
This seems bad in general. Maybe because you ran it as sudo before and now
non-sudo?
> # set simulator $::env(VIV_SIMULATOR)
> # set design_srcs $::env(VIV_DESIGN_SRCS)
> # set sim_srcs$::env(VIV_SIM_SRCS)
> # set inc_srcs$::env(VIV_INC_SRCS)
> # set sim_top $::env(VIV_SIM_TOP)
> # set part_name $::env(VIV_PART_NAME)
> # set sim_runtime $::env(VIV_SIM_RUNTIME)
> # set sim_fast$::env(VIV_SIM_FAST)
> # set vivado_mode $::env(VIV_MODE)
> # set working_dir [pwd]
> # set sim_fileset "sim_1"
> # set project_name "[string tolower $simulator]_proj"
> # if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
> # set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
> # if [expr [file isdirectory $sim_complibdir] == 0] {
> # set sim_complibdir ""
> # }
> # } else {
> # set sim_complibdir ""
> # }
> # if [expr ([string equal $simulator "XSim"] == 0) && ([string length
> $sim_complibdir] == 0)] {
> # puts "BUILDER: \[ERROR\]: Could not resolve the location for the
> compiled simulation libraries."
> # puts " Please build libraries for chosen simulator
> and set the env or"
> # puts " makefile variable SIM_COMPLIBDIR to point to
> the location."
> # exit 1
> # }
> # puts "BUILDER: Creating Vivado simulation project part $part_name"
> BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
> # create_project -part $part_name -force $project_name/$project_name
> WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
> ERROR: [Coretcl 2-106] Specified part could not be found.
> INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
> recipe for target 'xsim' failed
> make[4]: *** [xsim] Error 1
> CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
> 'CMakeFiles/noc_block_gain_tb' failed
> make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
> CMakeFiles/Makefile2:131: recipe for target
> 'CMakeFiles/noc_block_gain_tb.dir/all' failed
> make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
> CMakeFiles/Makefile2:138: recipe for target
> 'CMakeFiles/noc_block_gain_tb.dir/rule' failed
> make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
> Makefile:201: recipe for target 'noc_block_gain_tb' failed
> make: *** [noc_block_gain_tb] Error 2
>
> I am assuming this is the part that needs to be changed:
> xc7k410tffg900-2. I am not seeing where this is declared in the
> CMakeList.txt file. Do you know where I would go about changing it in the
> build scripts?
>
Yeah, change it over. I use EJ's repository as a good example for lots of
stuff. Particularly this:
https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/testbenches/noc_block_complextomagphase_tb/Makefile#L14
Just override it in the Makefile like EJ does there.
Let us know how that works out?
Brian
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues with RFNoC Component Test Bench
On Wed, Nov 13, 2019 at 10:54 AM Jonathan Lockhart via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Greetings USRP Users,
>
> I am having another issue with the UHD-3.14 build I can't seem to shake
> down. I have been going through this guide on the KB to learn how to use
> the rfnocmodtool to build new modules for my E312:
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> Unfortunately, when I get to the point of using the test bench, I get the
> following error.
>
> ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ sudo make
> noc_block_gain_tb
> [sudo] password for ettus_sdr:
> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>
> Environment successfully initialized.
> BUILDER: Checking tools...
> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
> * Python 2.7.15+
> * Vivado v2017.4.1 (64-bit)
>
> ** Vivado v2017.4.1 (64-bit)
> SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
> IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
>
> source
> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
> # set simulator $::env(VIV_SIMULATOR)
> # set design_srcs $::env(VIV_DESIGN_SRCS)
> # set sim_srcs$::env(VIV_SIM_SRCS)
> # set inc_srcs$::env(VIV_INC_SRCS)
> # set sim_top $::env(VIV_SIM_TOP)
> # set part_name $::env(VIV_PART_NAME)
> # set sim_runtime $::env(VIV_SIM_RUNTIME)
> # set sim_fast$::env(VIV_SIM_FAST)
> # set vivado_mode $::env(VIV_MODE)
> # set working_dir [pwd]
> # set sim_fileset "sim_1"
> # set project_name "[string tolower $simulator]_proj"
> # if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
> # set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
> # if [expr [file isdirectory $sim_complibdir] == 0] {
> # set sim_complibdir ""
> # }
> # } else {
> # set sim_complibdir ""
> # }
> # if [expr ([string equal $simulator "XSim"] == 0) && ([string length
> $sim_complibdir] == 0)] {
> # puts "BUILDER: \[ERROR\]: Could not resolve the location for the
> compiled simulation libraries."
> # puts " Please build libraries for chosen simulator
> and set the env or"
> # puts " makefile variable SIM_COMPLIBDIR to point to
> the location."
> # exit 1
> # }
> # puts "BUILDER: Creating Vivado simulation project part $part_name"
> BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
> # create_project -part $part_name -force $project_name/$project_name
> WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
> ERROR: [Coretcl 2-106] Specified part could not be found.
>
It's a silly question, but do you have a license for the kintex 7 410T part
on that machine?
You can probably get around this by targeting something that is supported
by the free web pack as long as it's 7-series fabric (zynq 7020 had worked
for me in the past).
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Crossbar and Block data rates
On Thu, Sep 19, 2019 at 11:18 AM Felix Greiwe wrote: > Hi Brian, > > thank you for your help. > > I have on question left. You say the crossbar is non blocking. Does that > mean it can supply multiply RFNoC Blocks with input data at once at its > full bus_clk speed? Or does it switch between the ports so that some > blocks have to wait until its their turn to get data? > AXI is a packetized system, but once a packet is ready, as long as there is a 1:1 relationship between ingress and egress, then things should be full rate across all ports. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Crossbar and Block data rates
On Thu, Sep 19, 2019 at 9:39 AM Felix Greiwe via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello together, > > I have some questions concerning clock speeds and the corresponding data > rates on a USRP x310 (FPGA). As far as I know, there are two different > clock speeds on the FPGA, the ce_clk=200MHz, and the bus_clk - I did not > find clock speed for this one. > The ce_clk is 214.286 MHz and is usually associated with a 32-bit AXI interface. The bus_clk is 187.5MHz and is usually associated with a 64-bit AXI interface. If you build an FPGA image, you can find these values in post_route_timing_summary.rpt that Vivado spits out in your build directory. > > Is it true, that the ce_clk drives my rfnoc blocks and thus my in- and > outgoing data rate of each single block (using sc16 samples) is 200MHz*32 > Bit/10^9 = 6,4 GBit/s? > It can, and usually does - but just slightly higher as noted above. > > I read, that all the RFNoC Blocks are connected to the crossbar which is > driven by the bus_clk. First of all: Is this the case? > If so, how is the crossbar able to handle the in and output data of each > RFNoC Block at once? How many Bytes can it process with each clock? > > Take for example the flowgraph > > SignalGenerator ->RFNoC-Gain -> RFNoC-DMAFIFO-> RFNoC-DUC-> RFNoC-Radio > > which has already four RFNoC Blocks connected to the crossbar, which in my > head are 25,6 GBit/s data on the crossbar at once which seems way to much > to handle. > > I think I really miss a point here and would be grateful for some > explanation. > The crossbar doesn't block other ports and is more like a packet switch. Since it's a linear flow, the crossbar doesn't have any issue handling each individual path bandwidth. Only when 2 packets have to go to the same crossbar egress do things become more complicated. I hope this makes sense. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD not showing USB version through which my X310 is connected
On Wed, Jul 24, 2019 at 8:11 AM Rodolphe Bertolini via USRP-users < usrp-users@lists.ettus.com> wrote: > I apologize if this is a duplicated email. > > Hello community, > > uhd_usrp_probe (and all the others commands) doesn't log the USB version > to which the USRP is operating. > > Instead it gives me the following: > > $ uhd_usrp_probe > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; > UHD_3.14.1.0-release > [INFO] [X300] X300 initialization sequence... > [INFO] [X300] Maximum frame size: 1472 bytes. > [INFO] [X300] Radio 1x clock: 200 MHz > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000) > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s) > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s) > [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001) > [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001) > [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) > [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) > [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0) > [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0) > _ > / > | Device: X-Series Device > | _ > |/ > | | Mboard: X310 > | | revision: 11 > | | revision_compat: 7 > [...] > > Any thought? > The X310 has a USB JTAG connection but that isn't really handled through UHD. What are you hoping to do over USB with UHD on an X310? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Testbench for custom block with AXI_CONFIG_BUS
On Mon, Jul 22, 2019 at 5:18 PM Brian Padalino wrote: > On Mon, Jul 22, 2019 at 5:12 PM Brian Padalino > wrote: > >> You just need to write_reg() and use an address of SR_AXI_CONFIG for >> everything other than the last value, and use SR_AXI_CONFIG_TLAST for the >> last one. >> >> That should push the valid high on the config line for each write you do, >> and then on the last write both valid and tlast will be held. >> > > Sorry, looking at my testbench I should have been more clear. > > I defined AXI_WRAPPER_BASE to 128. > I defined SR_AXI_CONFIG as AXI_WRAPPER_BASE + 1. > I defined SR_AXI_CONFIG_TLAST as SR_AXI_CONFIG + 1. > > In axi_wrapper, I instantiate: > > SR_AXI_CONFIG and assign it SR_AXI_CONFIG, and I also put > NUM_AXI_CONFIG_BUS to 1. > ... and I meant SR_AXI_CONFIG_BASE is the parameter to set on axi_wrapper. I shouldn't be so quick to reply. Haste makes waste. Again, apologies for not being clear. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Testbench for custom block with AXI_CONFIG_BUS
On Mon, Jul 22, 2019 at 5:12 PM Brian Padalino wrote: > You just need to write_reg() and use an address of SR_AXI_CONFIG for > everything other than the last value, and use SR_AXI_CONFIG_TLAST for the > last one. > > That should push the valid high on the config line for each write you do, > and then on the last write both valid and tlast will be held. > Sorry, looking at my testbench I should have been more clear. I defined AXI_WRAPPER_BASE to 128. I defined SR_AXI_CONFIG as AXI_WRAPPER_BASE + 1. I defined SR_AXI_CONFIG_TLAST as SR_AXI_CONFIG + 1. In axi_wrapper, I instantiate: SR_AXI_CONFIG and assign it SR_AXI_CONFIG, and I also put NUM_AXI_CONFIG_BUS to 1. Sorry for not being complete in my previous email. Good luck. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Testbench for custom block with AXI_CONFIG_BUS
You just need to write_reg() and use an address of SR_AXI_CONFIG for everything other than the last value, and use SR_AXI_CONFIG_TLAST for the last one. That should push the valid high on the config line for each write you do, and then on the last write both valid and tlast will be held. Brian On Mon, Jul 22, 2019 at 3:51 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > I am wondering how to write a testbench for a block that uses the > AXI_CONFIG_BUS to load a vector of coefficients - just as it is done in > noc_block_window.v (I'm not sure why there is no tesbench file for > noc_block_window in the repo??). Are there any examples that show how to > load these coefficients from the testbench? > Thanks. > Rob > ___ > 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] Writing and reading from ddr3 in usrp x310
On Sun, May 12, 2019 at 6:34 AM Daniel Ozer via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > Im trying to write and read data from the ddr3 ram in the usrp x310 using > the fpga. > I wasn't able to find if there is any other blocks that use the ram (in > the defualt image ) . > Also are there any rfnoc blocks that uses the ram ? Thx > The DRAM FIFO and the Relay blocks are the only two I am aware of personally. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Relationship between IQ values, gain and noise on B205mini transmitter
On Thu, May 9, 2019 at 1:03 PM Michael Deacon wrote: > I hope this is what you are looking for. Would clipping here be an > indication of saturation? > Not quite. You may be able to look at the CCDF of the output and see if it hits a brick wall versus the "good" picture. I'd much prefer to see an IQ constellation diagram. For OFDM it'll just look like a big Gaussian meatball unless you hit some clipping or weirdness, then you'll see it square up or look strange. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Relationship between IQ values, gain and noise on B205mini transmitter
What does the signal look like in the time domain? Is it driving the amplifier on the B205mini into saturation? Brian On Wed, May 8, 2019 at 7:57 PM Michael Deacon wrote: > I added some attenuation. The overload is gone but the condition persists. > > > > Thanks, > > > > Mike > > > > *From:* Brian Padalino > *Sent:* Wednesday, May 8, 2019 4:37 PM > *To:* Michael Deacon > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Relationship between IQ values, gain and > noise on B205mini transmitter > > > > On Wed, May 8, 2019 at 7:28 PM Michael Deacon via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Hello, > > > > I have a simple transmitter consisting of a file source connected to a > USRP sink (attached image radio.png). The file contains interleaved > floating point IQ representing a few seconds of LTE. The IQ amplitude > values are normalized between +1.0 and -1.0. The sink is configured to > 60db, 7.5MHz sample rate, 385MHz center frequency and 5MHz bandwidth. The > output looks exactly like the original on a spectrum analyzer (see attached > good.jpg). If I turn up the gain on the sink or increase the amplitude of > the IQ data I get what looks to be noise on either side of the signal > spectrum (see attached bad.jpg). Any idea what is going on here? > > > > Your bad.jpg picture has the spectrum analyzer saying OLVD. Try changing > your reference level of the spectrum analyzer to be higher so you don't > saturate the input of the spectrum analyzer. > > > > Tell us if that fixes it for you. > > > > Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Relationship between IQ values, gain and noise on B205mini transmitter
On Wed, May 8, 2019 at 7:28 PM Michael Deacon via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > > > I have a simple transmitter consisting of a file source connected to a > USRP sink (attached image radio.png). The file contains interleaved > floating point IQ representing a few seconds of LTE. The IQ amplitude > values are normalized between +1.0 and -1.0. The sink is configured to > 60db, 7.5MHz sample rate, 385MHz center frequency and 5MHz bandwidth. The > output looks exactly like the original on a spectrum analyzer (see attached > good.jpg). If I turn up the gain on the sink or increase the amplitude of > the IQ data I get what looks to be noise on either side of the signal > spectrum (see attached bad.jpg). Any idea what is going on here? > Your bad.jpg picture has the spectrum analyzer saying OLVD. Try changing your reference level of the spectrum analyzer to be higher so you don't saturate the input of the spectrum analyzer. Tell us if that fixes it for you. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] how can i receive 2 different signals with the USRP B210
On Wed, May 8, 2019 at 5:43 AM Marwa Boukhari via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > I want to send and receive a Signal at the frequency 900MHz with the > Channel 0 , and want to receive another Signal from the generator at the > frequency 5,68GHz with the other channel. > I tried to realize this but it didn't work. > Has someone maybe an idea what's the problem is. > The two receivers use a shared LO, so this won't work. To receive two different frequencies, you need two radios. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B210 mini I/Q imbalance?
Since it's AM, try shifting your center frequency by a little bit. Extract the envelope the same way, though. My thought is the DC cancellation circuitry in the 9361 is killing your AM waveform, so use a low-IF approach instead. Brian On Sun, May 5, 2019 at 1:05 PM franz kurniawan via USRP-users < usrp-users@lists.ettus.com> wrote: > I reduced to -40db, -50db and have the same result.. > > I attached the pictures of b200mini vs other SDR with the same signal > generator.. > > I expect the same result with the 'other SDR' result.. > The IQ data of b200 is seems to be incorrect (imbalance? ) > > I have tried the uhd of these version : > v3.14.0.0-rc3 , > release_003_007_001, > release_003_010_001_000 > > But all have the same result.. > > I tried to disable the set_auto_iq_balance to both false and true, but > have no effect.. > > Thank you > > On May 5, 2019 11:27 PM, "Marcus D Leech" wrote: > > -20dBM is loud. Try backing the generator down to -40dBm > > > Sent from my iPhone > > On May 5, 2019, at 12:14 PM, franz kurniawan > wrote: > > I set the generator at -20db and b200 gain at 50.. > I check that there is no cutoff at the usrp output and the input to AM > demod block.. > > Below are the setting of uhd block in gnuradio > Samp rate 500k > Output type float32 > Sync PC clock > Clock rate 10 Mhz external > Freq 121MHz > Gain 50 > Ch0 Bandwidth 20 > > > Thank you > > On May 5, 2019 11:05 PM, "Marcus D Leech" wrote: > >> What output level for the generator? What gain setting on the b205? >> >> >> Sent from my iPhone >> >> On May 5, 2019, at 11:58 AM, franz kurniawan >> wrote: >> >> So, i try to make AM receiver.. >> And the resulted demodulated audio was distorted from its original >> signal.. >> So, at this experiment i used signal generator to make AM with sine wave >> modulated signal.. >> I expect to get pure sine wave signal after AM demod process.. >> However, the sine wave is distorted as attached picture >> >> I compared with another brand SDR and can get my expected signal.. >> So i guess there is some problem with the b210mini >> >> Thank you >> >> >> >> On May 5, 2019 10:28 PM, "Marcus D. Leech via USRP-users" < >> usrp-users@lists.ettus.com> wrote: >> >> On 05/05/2019 10:53 AM, franz kurniawan via USRP-users wrote: >> >>> Dear USRP users, >>> >>> I used b210mini and encounter I/Q imbalance as below picture.. >>> As a result, the analog signal demodulation was distorted and result a >>> crappy sound.. >>> I >>> Is there any workaround regarding this issue? >>> >>> Thank you >>> >>> >>> Not sure what you mean. The I/Q seem to be about 90deg out of phase wrt >> one another, which is exactly what you'd expect. >> >> Could you describe what it is you're trying to do? Something with an >> audio demodulator? >> >> >> >> ___ >> 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 mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Vivado versions for RFNoC
2017.4 is the latest version that is supported I believe. Brian On Sun, May 5, 2019 at 6:36 AM Sam mite via USRP-users < usrp-users@lists.ettus.com> wrote: > I want to know what are the current supported vivado versions for X300 and > X310 and also for E310 and E320 for generating RFNoC images? > -- > > Best Regards, > > Sam > ___ > 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] 9361 Sample Rate question
On Fri, Apr 26, 2019 at 6:09 AM Chintan Patel via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > On the B210 devices which use the AD9361, what is the granularity on the > sample rate supported? I know the max sample rate is 61.44MHz, and that the > BBPLL that drives the ADC sample clock allows for a varying rates, but I am > trying to find what are the values that are actually supported. In other > words, if I set rate = 5.2Msps (or any arbitrary number), what determines > whether I will get that exact rate or a different closest-possible rate? > The code for calculating the BBPLL is here: https://github.com/EttusResearch/uhd/blob/7fab6b807ef5b86c97577170b7b5fdc667e3fa20/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp#L1158 Check UG-570 and the BBPLL section for a block diagram, but the code with the modulus and VCO min/max values should give you at least a decent understanding of what you can hit with the device. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] get_time_now() blocking?
On Tue, Apr 23, 2019 at 2:06 PM Fabian Schwartau via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everyone, > > I just found another strange thing. Can get_time_now() be in any case > blocking? Like long blocking? It takes more than 1 second to return! > I am heavily using timed commands, but I tried a clear_command_time() > before calling get_time_now() with no effect. It would also make no > sense at all to be able to set a command time for get_time_now(). > According to documentation the command just reads the registers in the > USRPs and returns them - no need to wait for anything. > Any ideas? > Reading registers isn't the fastest thing in the world, but you shouldn't be utilizing get_time_now() heavily for a real time system. Taking a second sounds like something is wrong, but I'm still curious why you're constantly asking for the time. The idea behind that is to understand the current time the radio has, figure out what you want to do when you first start a stream or do something, then use sample counting to understand when things are supposed to be happening. So, why do you keep asking for the time? What's the use case you're trying to figure out? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0
On Tue, Apr 9, 2019 at 12:13 PM Tillson, Bob (US) via USRP-users < usrp-users@lists.ettus.com> wrote: > I see this a lot with short waveforms as it is much more impactful. > > When you submit samples, there are previous samples within the buffer > (there always are) and the "entire" waveform doesn’t always come out, seems > like hysteresis. I usually prepend and postpend samples and do some timing > bookkeeping to account for added samples. > > There's group delay within the HB filters and the CIC filters that need to be flushed out with appended zeroes. Have you tried appending zeroes to the end of your short burst to flush the filter states? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0
On Tue, Apr 9, 2019 at 11:46 AM Michael R. Freedman wrote: > I'm generating samples at 2MHz. > What Ettus radio are you using? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0
On Tue, Apr 9, 2019 at 11:35 AM Michael R. Freedman via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > > I am doing timed streaming. It appears to me that there are several > "zero" samples getting to the DAC prior to my waveform and as a result, > my waveform is being truncated. Has anyone else seen this? > Are you going through any of the interpolation filters or producing samples at the target DAC rate for your system? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC DDC/Radio block/port restrictions
On Tue, Mar 19, 2019 at 1:52 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > Are there restrictions regarding which DDC ports must be connected to > which Radio ports. I am using an X310/UBX with a custom C++ rfnoc > application and would like to do the following: > Radio_0:port0 -> DDC_0:port0 > Radio_1:port0 -> DDC_0:port1 > Unfortunately, this fails (using default FPGA image) with a recv() after > about 3K samples. If I simply change the 2nd link above to the following, > then everything is fine. > Radio_1:port0 -> DDC_1:port1 > > Why is the first config invalid? If this is a bug, is it presently being > worked on? > Radio produces samples at 200Msps. Each AXI bus port is 64-bits wide and around 180-ish MHz. So you are limited by the AXI bus bandwidth. Does that make sense? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Problem with usrp-2900 and GNU Radio
You've got a dual-install issue here. On Sat, Mar 9, 2019 at 2:35 PM Thomas Lavarenne via USRP-users < usrp-users@lists.ettus.com> wrote: > uhd_probe seems good, but same error in GNU Radio.. (RuntimeError: > RuntimeError: Expected FPGA compatibility number 14, but got 16:) > > $ uhd_usrp_probe > [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; > UHD_3.15.0.git-60-g98d2572a > Note the UHD version here. And in the previous e-mail with the error, you have: linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown You can't have these two things installed simultaneously. Resolve this and you resolve your issue. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Problem with usrp-2900 and GNU Radio
On Sat, Mar 9, 2019 at 1:45 PM Thomas Lavarenne via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > I'm new here and pretty new with usrp. I'm trying to use usrp-2900 with > GNU Radio and Ubuntu 18.04, but i have this problem (latest driver uhd from > source): > > ''' > linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown > > -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... > -- Detected Device: B200 > -- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done > -- Operating over USB 3. > Traceback (most recent call last): > File "/home/user/top_block.py", line 166, in > main() > File "/home/user/top_block.py", line 154, in main > tb = top_block_cls() > File "/home/user/top_block.py", line 78, in __init__ > channels=range(1), > File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line > 122, in constructor_interceptor > return old_constructor(*args) > File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line > 2683, in make > return _uhd_swig.usrp_source_make(*args) > > *RuntimeError: RuntimeError: Expected FPGA compatibility number 14, but > got 16:The FPGA build is not compatible with the host code build.* > Please run: > > "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py" > > >>> Done > > Any ideas accepted! > Have you tried running: $ sudo /usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py As the message suggests? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] [Discuss-gnuradio] continous Tx voice transmission
On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller wrote: > I've had rather longish discussions on how to solve this; essentially: > for something that actually *solves* the issue (instead of postponing > it), as Ian said, you'd need to have clock domain crossing ability. > Could message passing from the real-time blocks solve this issue in a flexible way? Imagine the following: blocks connected to actual hardware use the computer wall clock to try to determine an average sample clock as it relates to the CPU clock. The USRP source block would be able to determine how many samples/(sec of CPU clock) were coming in and Audio sink blocks would be able to determine how many samples/(sec of CPU clock) were being consumed. The same idea for Audio sources and USRP sinks. Since the blocking calls for USRP or Audio blocks could be wrapped in a high precision timer, once any initial buffering had been filled up, the rate should settle out. The modified blocks could then send a message of actual sample rate to whoever needed to listen, and the appropriate sample rate could be figured out in the "resampling FIFO". What am I missing? Why won't this work? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP x310 with multi_usrp and RFNoC
On Fri, Feb 22, 2019 at 6:19 PM Martin Braun wrote: > This pokes a register in the STC3. It'll pull the FPGA into reset. You > then need to wait a bit before the FPGA is back up. > So it's a forced reload of the FPGA from the onboard image. To use this in software, I'd issue the command, then try to ping the device until it responds. Then I would re-load my application from there? Thanks, Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP x310 with multi_usrp and RFNoC
On Wed, Feb 20, 2019 at 7:45 PM Jonathon Pendlum wrote: > Hi Armin, > > You can reset X3x0 series devices via a register write with the following > command (this is in to your UHD src directory): > firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058 > --data=1. > Can you elaborate a little bit on what this register does, and why the UHD software might not always poke it to reset it? Thanks, Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP x310 with multi_usrp and RFNoC
On Tue, Feb 19, 2019 at 12:07 PM Armin Schmidt wrote: > Thanks for your replay! Hm, yes I've thought also about to use > STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app > also after a crash. Ok, it should never happen, but one can never guarantee > that case. Do you have an idea, how to deal with such cases? I think it's a > bug in UHD, because in the version 3.9 was that never a problem. > >From my conversations with Ettus, getting the radios to a known good state after a crash is not something they are prioritizing. My recommendation to you is that you reload the FPGA over JTAG every time before starting your application such that it is always in a known good/initial state. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP x310 with multi_usrp and RFNoC
On Tue, Feb 19, 2019 at 5:42 AM Armin Schmidt via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hallo,
> We're about to migrate from multi-usrp-application with UHD 3.9 and
> custome FPGA to UHD 3.14 with RFNoC. We are using the USRP x310 with
> daughterboards ubx-160. Everything seems to work fine except that when we
> stop our application in the terminal with ctrl-c, a new startup is only
> possible after a powercycle of all USRP's.
> The problem is, that we can connect our RFNoC-blocks and start streaming,
> but without a powercycle the recv() function starts after several
> successfully received packets to produce continuously the following error
> and hangs in this state:
> [ERROR] [STREAMER] The receive packet handler failed to time-align packets.
> 1002 received packets were processed by the handler.
> However, a timestamp match could not be determined.
>
> For me it is not clear, where to search for the problem. We set sudo
> sysctl net.core.rmem_max=33554432.
>
> Following our code for initializing the USRPS and RFNoC:
>
> //===
> //Setup a RX usrp device:
> //===
> multiUSRP =
> uhd::usrp::multi_usrp::make(parser.value("args").toStdString());
> //create multi-USRP
>
> QThread::sleep(1); //allow for some setup-time
>
> if(parser.value("args") == "") //show default values
> {
> uhd::device_addr_t hint("");
> std::vector addresses =
> ((multiUSRP->get_device())->find(hint));
> QString address =
> QString::fromUtf8((addresses[0].to_string()).c_str());
> QStringList addressList = address.split(",");
> QString args = addressList[0] + ",";
>
> for(int i = 0; i < addresses.size(); i++)
> {
> address =
> QString::fromUtf8((addresses[i].to_string()).c_str());
> addressList = address.split(",");
> args += "addr" + QString::number(i) + "=" +
> (addressList[1].split("="))[1] + ",";
> }
>
> args += "master_clock_rate=" +
> QString::number(multiUSRP->get_master_clock_rate());
>
> qInfo() << endl << "Creating the RX usrp device with: " << args;
> }
>
> else
> {
> qInfo() << endl << "Creating the RX usrp device with: " <<
> parser.value("args");
> }
>
> usrpDevice = multiUSRP->get_device3();
> usrpDevice->clear();//reset device streaming state (resets blocks
> after a stream)
>
> //==
> //Create block controls:
> //==
> std::vector blocks;
> std::string agc0_id, ddc0_id, psd0_id, agc1_id, ddc1_id, psd1_id,
> radio_args, agc_args, ddc_args, streamargs;
> ddc0_id = "DDC_0";
>
> //Initialize Radio-blocks:
> //
> QStringList rx_channel_strings = (parser.value("channels")).split(",");
> numChannels = rx_channel_strings.size();
> QVector radio_ctrls;
>
> qInfo() << endl;
>
> //initializes all m radio controls:
> for(int i = 0; i < numChannels; i++)
> {
> uhd::rfnoc::block_id_t radio_ctrl_id(qFloor(i/2), "Radio", (i %
> 2)); //create on USRP x the radio object for channel 0 or 1
>
> radio_ctrls.append(usrpDevice->get_block_ctrl(radio_ctrl_id));
> //this line will faile, if radio is not available
>
> qInfo() << "Using USRP: " << qFloor(i/2) << ", channel: " << (i %
> 2) << endl;
> }
>
> //radio_ctrl->set_args(radio_args);
>
> //Set clock-source:
> /*for(int i = 0; i < numChannels; i++)
> {
> radio_ctrls[i]->set_time_source("external");
> radio_ctrls[i]->set_clock_source("external");
> }*/
> //radio_ctrls[0]->set_time_next_pps()
>
> multiUSRP->set_time_source("external");
> multiUSRP->set_clock_source("external");
> multiUSRP->set_time_unknown_pps(uhd::time_spec_t(0.0));
> QThread::sleep(1); //wait for pps sync pulse
>
> //check time synchronization across all motherboards
> if (multiUSRP->get_time_synchronized())
> {
> qInfo() << endl << "Time Synchronization across all Motherboards
> done";
> }
>
> else
> {
> qInfo() << endl << "Time Synchronization across all Motherboards
> failed";
> throw "Time Synchronization across all Motherboards failed";
> }
>
> //set the RX-antenna:
> for(int i = 0; i < numChannels; i++)
> {
> radio_ctrls[i]->set_rx_antenna("RX2", 0);
> }
>
> QThread::sleep(1); //allow for some setup-time
>
> //this->set_rx_gain((parser.value("gain")).toDouble());
> //this->set_rx_freq((parser.value("freq")).toDouble());
>
>
> //=
> //Set-up streaming:
> //=
> uhd::device_addr_t streamer_args(streamargs);
> std::vector rx_channel_nums;
>
> rx_graph = usrpDevice->create_graph("rx_graph");
>
> for(int i = 0; i < numChannels; i++)
> {
> /*
> //Check if agc0-block is available:
> if(!usrpDevice->has_block(agc0_id))
>
Re: [USRP-users] X300 REF OUT drive capability
Check U530 on page 11, A1: https://files.ettus.com/schematics/x300/x3xx.pdf It's a FIN1002 LVDS receiver. Datasheet says 16mA max: http://www.mouser.com/ds/2/149/FIN1002-108110.pdf Brian On Tue, Feb 12, 2019 at 11:16 AM Jason Roehm via USRP-users < usrp-users@lists.ettus.com> wrote: > How much current can the X300 REF OUT port drive? I have another device > that has a reference input with a relatively low input impedance, and I > want to ensure that it can source enough current to properly drive it. > > Thanks. > > Jason > ___ > 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] 2 DMAfifo blocks?
On Mon, Jan 28, 2019 at 3:42 PM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > Is it possible to have two different DMAFifo RFNoC blocks on an X310? I > am not worried about the resources so much as how to implement it (I know > that I cannot add it to the uhd_image_builder as it is a special case). > It interfaces directly to the DDR3 controller, so you will need some arbitration between the read/write banks of the DDR3 controller. That might be an option for the DDR3 controller itself? Otherwise, I don't think there's anything problematic about it from an implementation perspective? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N310 Band Pass filter frequencies
On Fri, Dec 21, 2018 at 11:49 AM David Bengtson wrote: > So I dug into this (On a 10k piece of equipment?) and came up with the > following bands > > 1: 3000 to 6000 > 2: 2200 to 2800 > 3: 1650 to 2200 > 4: 1400 to 1575 > 5: 700 to 1000 > 6: 500 to 530 > plus 1 unfiltered path. > Also looks like the web datasheet has some information, though it may be slightly different than what you found (page 3 of the PDF): https://www.ettus.com/content/files/USRP_N300_Datasheet_V4_Web.pdf > > Below 500 MHz, there's an 84 MHz passband based the up-conversion stage > there. > This seems like an unusual collection of passbands, in addition to > having big gaps between filter passbands. > I'm curious is someone from Ettus could comment on the design intent > behind this selection. > I'm also curious to know if these passbands have been swept with a > Network analyzer to see if there's any untoward > interaction between the highpass/lowpass filter structures used to > derive the bandpass characteristics > It would be nice to have those sweeps similar to what is published on the E310 product page: https://www.ettus.com/content/USRP_E3xx_RX_Filter_Graph_Web.png https://www.ettus.com/content/USRP_E3xx_TX_Filter_Graph_Web.png Maybe the E310 and N310 share similar Minicircuits filters placed back to back? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N310 Band Pass filter frequencies
On Fri, Dec 21, 2018 at 7:51 AM David Bengtson via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi- > > The N310 receiver has a set of switchable bandpass filters on the > receiver inputs. I've looked through the N310 knowledge base, and > haven't come across any documentation on these filter bandwidths. Is > there a list of the nominal passband filter bandwidths for the N310 > receiver filter banks somewhere? > Daughterboard schematics: https://kb.ettus.com/N300/N310#Schematics Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Faster way to send asynchronous data to RFNoC block
On Wed, Dec 19, 2018 at 6:22 PM J M wrote: > Some of that makes sense to me. Do you know of an open source example > where something similar to this is done? > No, but it shouldn't be too bad to try and simulate. Make a top block with 2 sets of AXI streaming associated with bus_clk, then instantiate a noc_shell for each port each with their own ID to it. Then the one port can be associated with RAM initialization, and the other port can be for streaming data. I'm sure it'll potentially expose some strange interactions between things, but one problem at a time, right? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Faster way to send asynchronous data to RFNoC block
On Wed, Dec 19, 2018 at 4:24 PM J M wrote: > Potentially, yes the full 200 MHz > Ah, yes. Then you'd need 2 connections to the crossbar. If you didn't need all 200MHz, then you could get away with 2 ports off the same crossbar connection as well. I think you would just have each connection be a different block ID that shows up, and internally you are just able to share everything. Externally it would look like 2 different blocks, though, and you would have to know how to work with them in conjunction with each other. Does that make sense? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Faster way to send asynchronous data to RFNoC block
On Wed, Dec 19, 2018 at 4:06 PM J M wrote: > The block is performing some signal processing on incoming samples > streaming from a radio block, but the signal processing is based on the > data stored in the ram. It would be ideal to be able to swap out the RAM > while the block is streaming, though loading it once at start is better > than what we have now. > > This is a good suggestion, however in the meantime to get it loaded more > quickly at the start. It seems if it was feasible, having a second AXI > stream interface would be cleaner, but I don't know if it's possible. > How much data are you processing on the AXI stream? Is it the full 200MHz worth of bandwidth? Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Faster way to send asynchronous data to RFNoC block
On Wed, Dec 19, 2018 at 12:53 PM J M via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > I'm trying to load a RAM inside an RFNoC block, and doing this via > register writes takes about a minute and half. > > So, looking for a quicker way to load up the data from the RAM, thought > about a second input to the RFNoC block and source it from the file. In > this way, the RFNoC block would have two inputs, one which would be source > from the radio block, and the second from file, but the file would only run > through once to load the RAM. > > Unfortunately, I haven't found any RFNoC examples that have 2 inputs that > are not tied together (such as the add/sub block). Does anyone know of a > good example of doing this through RFNoC, or if it is even possible? Or is > there another mechanism for sending a bunch of data across that I'm > overlooking? > Can you describe the life cycle of your block for us a little bit in more detail? If you are loading RAM once and only once before starting any streaming, you could potentially use a register to choose which mode you are in, and then the incoming stream can be pushed to RAM, then the register is cleared once you are sure there is nothing more to write into RAM. Unfortunately, without knowing more about your life cycle and how you intend to use the block, I am not sure the above suggestion would actually work. Brian ___ 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: Stream using both channels to different radios simultaneously
On Wed, Dec 5, 2018 at 4:13 PM Max Thomas via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > When attempting to stream different waveforms using both channels of the > replay block simultaneously to two radios on the same USRP (X310) there are > under-runs. Any ideas why this is happening? The replay block works as > expected when using either channel 0 or channel 1, but fails when > attempting to stream channel 0 and channel 1 simultaneously. > I believe the DRAM connected to the FPGA can't handle 400MHz of bandwidth. It might be able to work if you decimated to 100MHz streams and interpolated each radio by 2x. Is that a possibility? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc problem with custom DDC inputs.
Hey Carlos,
On Tue, Dec 4, 2018 at 1:16 PM Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com> wrote:
> Hi Brian,
>
> I have finished the DDC block 1:8 and it works perfectly!! :) :)
>
Congratulations!
>
> Now I am in my final step, a 2:16 DDC block:
> - Channels 0:7 connected to input 0.
> - Channels 8:15 connected to input 1.
>
> The verilog module works, but I have a problem with the UHD driver. I have
> timeout on chan 8,9,10...15.
> When I use GNURadio Signal Source it runs fine, but when I use rfnoc Radio
> block no.
>
> I have tried (device3_io_impl.cpp) :
>
> ...
> // Update args so args.args is always valid for this particular
> channel:
> args.args = chan_args[stream_i];
> size_t mb_index = block_id.get_device_no();
> size_t suggested_block_port = args.args.cast("block_port",
> rfnoc::ANY_PORT);
> // printf("Puerto: %i\n",suggested_block_port);
> // change
> // size_t radio_block_port = args.args.cast("radio_port",
> rfnoc::ANY_PORT) ;
> size_t radio_block_port = 0;
>
> if (stream_i<8){
> radio_block_port = 0;
> }
> else{
> radio_block_port = 1;
> }
> ...
>
> (( I recognize that I am not an expert on the driver)) :/
>
Unfortunately, you've gone outside my experience and knowledge. Good luck,
and please keep us posted if you are able to figure out how to get it to
work. It sounds like a fun and interesting block you're working on.
Brian
PS - Do you plan on open sourcing the block?
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X310's sample rate
On Tue, Dec 4, 2018 at 10:35 AM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > I have a X310 with a pair of CBX-130s installed and am running RFNoC. The > flowraph looks like this: > > > Radio (running at 200MHz) -> DDC (200MHz down to 50MHz) -> splitter -> > off to some other blocks. > > What is weird to me is that I wasn't thinking and I set the sample_rate to > to be the master_clock_rate (200MHz in this case), but the CBX-120 only has > a sample-rate of 120MHz. This process seems to work and my flowgraph is > running as I expect it should. There are no warning or errors from UHD > when I run this saying that I had an incorrect sample_rate. > The 120 is the analog filter bandwidth of the radio card. The samplerate is very limited on the X310 to be either 200MHz or 184.32MHz and must be set during device initialization, I believe. > > Now, if I leave the master_clock_rate alone, but set the sample_rate to be > 120MHz, the flowgraph barfs immediately and I get timeouts non-stop. > > So I am guessing that there is a concept between the > master_clock_rate/sample_rate, or some combination of them and the DDC that > I am missing. > Need to use integer division to get to 120MHz, and that isn't going to happen from 200MHz or 184.32MHz. Take master_clock_rate and divide by positive integers, and that's how you get valid sample rates. Moreover, if you want to ensure good passband behavior, it should be even, and if you want better passband behavior, it should be divisible by 4. In the even cases, halfband FIR filters are used instead of strictly a CIC filter, which has some passband rolloff. Hopefully this helps. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Can I use chained DDCs?
Hey Jason, On Mon, Dec 3, 2018 at 11:50 AM Jason Matusiak < ja...@gardettoengineering.com> wrote: > Brian, > > I am not sure what the issue is here. I don't think it is the chained DDC > anymore as I can see the issue with the single DDC using multiple different > bitfiles. > > I wasn't re-tuning the Fc anywhere, I was just dropping the sample rate > from 120MHz down to something I could handle. Right now I am not touching > the CORDIC modifications at all. > Are you trying to change the samplerate at runtime after starting the stream? In my experience, ever since around the time the the DDC moved from a CORDIC to using a DDS, dynamically changing the samplerate at runtime after starting a stream is broken and causes strange behavior. In my experiences, it's been timeouts. > > What version of UHD are you running for your applications? > I think I settled on 3.13.0.1 release as my stable base, and I have a few patches applied. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Can I use chained DDCs?
On Mon, Dec 3, 2018 at 11:32 AM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > Actually, upon further review, I can get this to happen with the stock XG > image and as simple flowgraph as possible. > > If I run the stock image as non-RFNoC seems to be fine, so it has > something to do with me using RFNoC. > > I tried switing to HG, but I see the same issues. > > Has anyone else experienced this? I find it hard to believe that this is > happening for everyone else, but I can't figure out why it would happen > with the stock image. My specs are: > [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-28); > Boost_105300; UHD_4.0.0.rfnoc-devel-702-geec24d7b > > > > - Original Message - > Subject: Can I use chained DDCs? > From: "Jason Matusiak" > Date: 12/3/18 7:23 am > To: "Ettus Mail List" > > I have a flowgraph where I use 3 different DDCs on an X310. There is a > dual DDC that is connected to the two radios on the X310. Then I have 2 > single DDCs chained off of that first one. I built these DDCs to only have > a single input/output on them. > > The dual DDC still only has one AXI input port to it, so it can't handle 2 radios worth of stuff going into it. Right? This seems weird to me. > > The flowgraph will work, but sometimes won't. What I see is that things > sometimes get tuned off center. I have a tone that I am putting out on a > different device, I fire up my flowgraph, and I see the tone in both paths > (that is an example, it doesn't always work on every first run). I stop > the flowgraph and run again. This time it may work, or it might be > off-tuned. If I re-tune the radio via Qt, I can see the signal elsewhere. > Why would this be? > > One more piece of information. When it is off-tuned, it isn't always the > same place. Sometimes it is only off by 100s of kHz, sometimes it is off > my 10s of MHz. This is VERY odd to me. Any advice? > > I run a modified FPGA with a modified such that I have: Radio -> Single Channel DDC -> Modified Multiple Output DDC -> Host, and I heavily utilize changing the center frequencies of each of those DDC's. It works flawlessly. In your RFNoC application, how are you changing that center frequency of the downstream DDC's? Are you sure you've appropriately translated the frequency to whatever new baseband from the first DDC? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Is there any method for X310 to support 122.88M Sampling rate?
On Fri, Nov 30, 2018 at 11:29 AM Marcus Müller via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi J. Jeffson, > > to answer quickly: see below. > On Fri, 2018-11-30 at 11:36 +0800, 蒋逸凡 via USRP-users wrote: > > Hi all > > I'm trying to use USRP X Series (2943/2954) in my project. I > > want to try 122.88MHz sampling rate, but ettus.com says that only > > 200MHz and 184.32MHz and the corresponding integer divisor. > > > exactly. > > > Is updating fpga image by uhd_image_downloader.py helpful? > > > > no. > > > Is there any way to re-write fpga image so that it can > > support? > > no. This is a restriction of the clocking architecture and analog > components. > > > > Really appreciate if someone suggests me some solution to it. > > Hm, if my head calculation doesn't betray me: > 122.88 MHz = 2¹⁶ · 5⁴ · 3¹ Hz >200 MHz = 2 · 10⁸ Hz >= 2⁹ · 5⁸ Hz > > Hence, 200 MHz / 122.88 MHz = 2⁻⁷·5⁴·3⁻¹ > > So you could build a rational resampler that interpolates by 2⁷·3 = 384 > and decimates by 5⁴ = 625. > > That is not a nice filter! > > Don't know if I'd generally recommend an MCR of 184.32 MHz but, let's > try: > > 184.32 MHz = 2¹⁵ · 5⁴ · 3² Hz > > Hence, 184.32 MHz / 122.88 MHz = 2⁻⁶ · 5⁴ · 3⁻² > So you could build a rational resampler that interpolates by 2⁶·3² = > 576 > and decimates by 5⁴ = 625. > > So, that's even worse. > Something seems off here. 184.32 * 2 / 3 = 122.88 That shouldn't be too terrible to do on the host system, or to potentially even build into an FPGA? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc problem with custom DDC inputs.
Hey Carlos,
The attached patch is what I used applied to 3.13.0.1 I want to say. You
get the idea.
To get the controller, I use get_block_ctrl(uhd::rfnoc::block_id_t(0,
"NAME", 0)) since there is only one instance, for me, in my radio.
When setting up the uhd::device_addr_t, I populate: block_port%d,
radio_id%d, and radio_port%d where block_port%d is the output block you're
looking at streaming from.
Hope this is helpful.
Good luck.
Brian
On Fri, Nov 30, 2018 at 4:34 AM Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com> wrote:
> Hello Brian,
>
> I have finished the FPGA code. I got a DDC 1:2 but I have problems with
> 1:8. I think I have your same problems: /
>
> *thread[thread-per-block[0]: ]: LookupError:
> KeyError: [0/Radio_0] sr_write(): No such port: 2*
>
> In rfnoc code:
>
>
>
>
>
> *std::vector >
> upstream_radio_nodes =
> blk_ctrl->find_upstream_node();
> UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " <<
> upstream_radio_nodes.size();for(const
> boost::shared_ptr : upstream_radio_nodes)
> {node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID,
> xport.send_sid.get_src(), block_port);}*
>
> I've found your post (
> http://ettus.80997.x6.nabble.com/USRP-users-Multiple-Output-RFNoC-Block-td9587.html
> ), but I'm stuck on the same point.
> Could you give me any suggestions?
>
> Thank you!! :)
>
>
>
>
> El mié., 28 nov. 2018 a las 16:17, Carlos Alberto Ruiz Naranjo (<
> carlosruiznara...@gmail.com>) escribió:
>
>> Ok! Thank you :)
>>
>> El mié., 28 nov. 2018 a las 16:13, Brian Padalino ()
>> escribió:
>>
>>> On Wed, Nov 28, 2018 at 9:43 AM Carlos Alberto Ruiz Naranjo <
>>> carlosruiznara...@gmail.com> wrote:
>>>
Thank you! I already have enough work to continue :)
One last thing. In the split_stream module, did you concat tuser with
m_axis_data_tuser with m_axis_data_tdata?
>>>
>>> No tuser at that point. Just the stream part - tdata, tlast, tvalid,
>>> and tready.
>>>
>>>
I'm curious about you election. Why do you think that version 0 is
better than version 1?
>>>
>>> Not really sure. It is just the way I ended up. I think either way
>>> will work. Whichever way makes sense to you, try it out! Have fun! :)
>>>
>>> Brian
>>>
Allow-multiple-RX-output-ports.patch
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc problem with custom DDC inputs.
On Wed, Nov 28, 2018 at 9:43 AM Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com> wrote: > Thank you! I already have enough work to continue :) > > One last thing. In the split_stream module, did you concat tuser with > m_axis_data_tuser with m_axis_data_tdata? > No tuser at that point. Just the stream part - tdata, tlast, tvalid, and tready. > > I'm curious about you election. Why do you think that version 0 is better > than version 1? > Not really sure. It is just the way I ended up. I think either way will work. Whichever way makes sense to you, try it out! Have fun! :) Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc problem with custom DDC inputs.
Hey Carlos, On Tue, Nov 27, 2018 at 6:18 PM Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com> wrote: > Hello Brian, > > Thank you very much for answering, I am spending a lot of time on this and > I do not see the way out. > > I am following your advice, I have removed the 3 inputs of FPGA code, but > I am having problems. > > I have doubts with: > > - str_sink_tvalid and str_sink_tready[line 165] > - str_src_tready [line 166] > - sample_in_tready [line 297] > - sample_out_tready [line 301] > I solved this by having N axi_wrappers - one for each output I wanted. I then only wire the inputs into axi_wrapper0 and no inputs into the other axi_wrappers - just the outputs. I then send the stream tdata from axi_wrapper0 to an nsplit_stream_fifo which does the 1:N conversion for me. I have 8 outputs, and I had to make changes to UHD to support writing to the appropriate ports inside of the block, but that is a different issue altogether. Note that it's very easy to fill up the FPGA using multiple output ports. Lots of FIFOs get instantiated. Good luck! Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] rfnoc problem with custom DDC inputs.
On Mon, Nov 26, 2018 at 12:14 PM Carlos Alberto Ruiz Naranjo via USRP-users wrote: > Hello, > > I have customized the rfnoc DDC. I have: > > - 4 inputs (0,1,2,3). > - 4 outputs (0,1,2,3). > - 4 independently tunable DDCs. > - Input 0 connected to outputs 0,1,2,3. > - Input 1,2,3 disconnected. > > I attach a diagram. > > But I do not know how to connect inputs 1,2,3 to a null source for . Any > ideas? > If you don't plan on using those inputs for anything, just don't make them. Make 1 input, 4 outputs. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC FFT block scaling
On Mon, Nov 19, 2018 at 2:47 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > Can anyone offer advice regarding the RFNoC FFT scaling argument? It is > not clear to me if this argument should always be left alone or if it > should be adjusted as needed by the user for various signal types and FFT > lengths. I was expecting the latter, but my experimentation today gives me > no confidence in doing so. > > The default value is 1706. I have been trying other values with bizarre > results. Using the example "rfnoc_fft" that comes in the gr-ettus/examples > folder, I get seemingly normal results with this set to 1706. But, if I > change it to 1705, I get very strange behavior. And, look out if you > choose 2048. See attached. In all cases, the signal source was a 125kHz > exponential with Gaussian noise (which is the default behavior of this GR > flowgraph). > Look at the value in hex not decimal. It's telling the FFT algorithm which stages to prune back the output. 1706 = 0x6aa = 0b011010101010. If you run with all 0's, you risk overflowing internally. An overflow error comes out, but I am not sure it's captured really well with the FFT. If you want to be ultra conservative, then scale back every stage and you won't get the integration gain that the FFT provides on the block size. It definitely does depend on the FFT length, but it seems like every other stage with a radix-4 works decently well? It's the SCALE_SCH parameter in the IP block: https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf Hope this helps. Good luck! Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate
On Tue, Oct 30, 2018 at 11:25 AM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote: > > Is there a way to query the amount of data in the FIFO so that I can wait > until it clears? > > I don't believe so. > There's a method in the core (host side code and FPGA code) but it isn't brought out to the controller: https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L168 The controller is here: https://github.com/EttusResearch/uhd/blob/master/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp Add a method and you should be able to, using RFNoC, query the current FIFO usage. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X300 TX Pulse odd behavior
It would depend on the daughterboard being used with the X300 I believe. Which daughterboard are you using? Brian On Tue, Oct 16, 2018 at 7:23 PM Ryan Marlow wrote: > Hey Brian, > Thanks for the suggestion. I think that idea should work for me. Is there > anywhere that documents the X300 TX ramp up time? > Best, > Ryan > > On Tue, Oct 16, 2018 at 6:28 PM, Brian Padalino > wrote: > >> Maybe ramp up time for the transmitter? >> >> If you send 2.5us worth of 0's before your 1000 samples, do you see the >> appropriate number of pulse burst length? >> >> This method would be a compromise between the two methods you described. >> Does that work for you? >> >> Brian >> >> On Tue, Oct 16, 2018 at 6:19 PM Ryan Marlow via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hey All, >>> I am trying to transmit a series of pulses with the X300 and am seeing >>> some odd behavior. I want to transmit a set number of samples in a pulse, >>> let's say 1000. At 200 MSPS (the tx rate in the radio core) I would expect >>> this burst to last approximately 5us. Yet, when I receive the data, I see a >>> burst that is shorter by half, approx 2.5 us. To send these bursts, I am >>> sending a timed burst of 1000 samples to the Radio with significant space >>> in between. Odder still, when I increase my pulse to 2000 samples, >>> expecting a pulse of 10 us, it is shortened again by 2.5 us, making the >>> pulse 7.5 us. I can confirm with an ILA that the Radio core is receiving >>> all pulsed samples and they are passed to the daughterboard interface. Is >>> there an obvious explanation for this behavior that I am overlooking? >>> One solution I have devised is generating a constant stream of data in >>> place of the gaps between pulses that contain zero'd data. So it would look >>> like this >>> Data x 1000 -> zeroes in place of gaps -> repeat. >>> In my original method, the transmitter is only active during the pulses. >>> In the alternative solution, the transmitter is active the whole time. >>> This solution gives me the behavior that I want but I am curious as to >>> why the pulses are shortened. >>> >>> Thanks, >>> Ryan Marlow >>> >>> -- >>> Ryan L. Marlow >>> R L Marlow Consulting LLC >>> rlmarlow.com >>> ___ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> > > > -- > Ryan L. Marlow > R L Marlow Consulting LLC > rlmarlow.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X300 TX Pulse odd behavior
Maybe ramp up time for the transmitter? If you send 2.5us worth of 0's before your 1000 samples, do you see the appropriate number of pulse burst length? This method would be a compromise between the two methods you described. Does that work for you? Brian On Tue, Oct 16, 2018 at 6:19 PM Ryan Marlow via USRP-users < usrp-users@lists.ettus.com> wrote: > Hey All, > I am trying to transmit a series of pulses with the X300 and am seeing > some odd behavior. I want to transmit a set number of samples in a pulse, > let's say 1000. At 200 MSPS (the tx rate in the radio core) I would expect > this burst to last approximately 5us. Yet, when I receive the data, I see a > burst that is shorter by half, approx 2.5 us. To send these bursts, I am > sending a timed burst of 1000 samples to the Radio with significant space > in between. Odder still, when I increase my pulse to 2000 samples, > expecting a pulse of 10 us, it is shortened again by 2.5 us, making the > pulse 7.5 us. I can confirm with an ILA that the Radio core is receiving > all pulsed samples and they are passed to the daughterboard interface. Is > there an obvious explanation for this behavior that I am overlooking? > One solution I have devised is generating a constant stream of data in > place of the gaps between pulses that contain zero'd data. So it would look > like this > Data x 1000 -> zeroes in place of gaps -> repeat. > In my original method, the transmitter is only active during the pulses. > In the alternative solution, the transmitter is active the whole time. > This solution gives me the behavior that I want but I am curious as to why > the pulses are shortened. > > Thanks, > Ryan Marlow > > -- > Ryan L. Marlow > R L Marlow Consulting LLC > rlmarlow.com > ___ > 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] Transmit Thread Stuck Receiving Tx Flow Control Packets
I have rebuilt the FPGA using Juan Francisco's suggestion in the DMA FIFO,
and since then I haven't run into the problem using UHD v3.13.0.1.
His patch was:
OUTPUT2: begin
// Replicated write logic to break a read timing critical path for
read_count
read_count <= (output_page_boundry < occupied_minus_one) ?
output_page_boundry[7:0] : occupied_minus_one[7:0];
-read_count_plus_one <= (output_page_boundry <
occupied_minus_one) ? ({1'b0,output_page_boundry[7:0]} + 9'd1) : {1'b0,
occupied[7:0]};
+read_count_plus_one <= (output_page_boundry <
occupied_minus_one) ? ({1'b0,output_page_boundry[7:0]} + 9'd1) : ({1'b0,
occupied_minus_one[7:0]} + 9'd1);
Brian
On Mon, Oct 8, 2018 at 1:28 PM Michael West wrote:
> Hi Alan,
>
> Try increasing the TX ring buffer for the network interface and make sure
> the CPU governor is not throttling the CPU (i.e. set to "performance" and
> not "on demand" or "powersave").
>
> The samples per packet for TX was reduced because the larger frame size
> was actually resulting in even more underruns in testing. That does mean
> more smaller packets are creating more load on the CPU to process the
> network interrupts and the above settings will help tune the system to
> better handle that load. We are looking at ways to increase the TX frame
> size back to where it was and reduce that load, but it will take
> significant changes to accomplish that and those changes probably won't be
> available for a while.
>
> Regards,
> Michael
>
> On Wed, Sep 5, 2018 at 1:22 PM Alan Conrad via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I tried Brian’s suggestion to rebuild UHD and the FPGA off of the commits
>> he suggested (thanks Brian). However, with this combination I am getting
>> significantly more underruns than I did previously, even with the benchmark
>> rate program. Here’s the output of benchmark_rate that I got originally
>> with UHD 4.0.0.rfnoc-devel-788-g1f8463cc.
>>
>>
>>
>> ./benchmark_rate --rx_rate 100e6 --tx_rate 100e6 --channels="0,1"
>>
>>
>>
>> Benchmark rate summary:
>>
>> Num received samples: 2016651900
>>
>> Num dropped samples: 0
>>
>> Num overruns detected:0
>>
>> Num transmitted samples: 2005972016
>>
>> Num sequence errors (Tx): 0
>>
>> Num sequence errors (Rx): 0
>>
>> Num underruns detected: 562
>>
>> Num late commands:0
>>
>> Num timeouts (Tx):0
>>
>> Num timeouts (Rx):0
>>
>>
>>
>> And now I get this with UHD 3.14.0.HEAD-31-g98057752.
>>
>>
>>
>> Benchmark rate summary:
>>
>> Num received samples: 2001309816
>>
>> Num dropped samples: 0
>>
>> Num overruns detected:0
>>
>> Num transmitted samples: 1841996424
>>
>> Num sequence errors (Tx): 0
>>
>> Num sequence errors (Rx): 0
>>
>> Num underruns detected: 353655
>>
>> Num late commands:0
>>
>> Num timeouts (Tx):0
>>
>> Num timeouts (Rx):0
>>
>>
>>
>> One difference I did notice between these two versions of UHD is the
>> maximum samples per packet returned from the get_max_num_samps() function
>> for both the Rx and Tx streams. With the version from the rfnoc-devel
>> branch, I get 1996 samples for both the Rx and Tx streams. But, the UHD
>> 3.14.0 version gives 1996 samples for the Rx stream but only 996 samples
>> for the Tx stream. I’m not sure if this is causing the additional
>> underruns.
>>
>>
>>
>> In any case, was a change made to limit the number of transmit samples
>> per packet? Are there additional network configurations that I need to
>> make to increase the maximum samples per packet for the Tx stream or to
>> limit the underruns with these versions of UHD and the FPGA firmware? BTW,
>> setting “spp” in the transmit stream args does not allow more than the 996
>> samples per packet.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Alan
>>
>>
>>
>>
>>
>> *From:* Brian Padalino
>> *Sent:* Tuesday, August 28, 2018 8:57 PM
>> *To:* Alan Conrad
>> *Cc:* USRP-users@lists.ettus.com
>> *Subject:* Re: [USRP-users] Transmit Thread Stuck Receiving Tx Flow
>> Control Packets
>>
>>
>>
>>
>>
>> On Tue, Aug 28, 2018 at 4:02 PM Alan Conrad via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi All,
>>
>>
>>
>> I’ve been working on an application that requires two receive streams and
>> two transmit streams, written using the C++ API. I have run into a problem
>> when transmitting packets and I am hoping that someone has seen something
>> similar and/or may be able to shed some light on this.
>>
>>
>>
>> My application is streaming two receive and two transmit channels, each
>> at 100 Msps over dual 10GigE interfaces (NIC is Intel X520-DA2). I have
>> two receive threads, each calling recv() on separate receive streams, and
>> two transmit threads each calling send(), also on separate transmit
>> streams. Each receive thread copies samples into a large circular buffer.
>> Each transmit thread reads samples from the buffer to be sent in the send()
>> call.
Re: [USRP-users] RFNoC loopback
On Wed, Sep 26, 2018 at 10:36 AM Daniel Rauschen via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > I have a question regarding a RFNoC loopback in plain UHD. > > I am familiar with [1] and I have a working solution with gr-ettus and > python. The problem is, I can not figure out how to connect the blocks > in plain UHD. Does anyone have a working example in UHD for a RFNoC > loopback? > > Connecting in UHD/c++ fails with following error: "Error: RuntimeError: > On node 0/Radio_0, output port 0 is already connected."... > > Any help is highly appreciated :) > You didn't show us how you tried to connect them? Can you attach your source file? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] DMA FIFO Resizing
Hey Marcus, On Mon, Sep 24, 2018 at 5:22 PM Marcus Müller wrote: > Hello Brian, > > so, the power-of-two FIFO sizes pretty much happen because you can only > divide addresses by full bit prefixes. That seems to be reflected in > noc_shell.v; not quite sure how deep the changes would have to go to > get rid of that restriction. > Can you point me to the appropriate lines of code for this restriction? Thanks, Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] DMA FIFO Resizing
I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the installation of UHD as of current master: https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt It seems like this is just a simple oversight, so I modified it locally. I've been running doing some latency experiments and modifying the size of the DMA FIFO using the resize() method: https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65 And it seems there's a bit of a restriction on the sizing associated with the FIFO: https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263 I see it currently says that the FIFO needs to be >8k, and it has to be a power of 2. If either of those criteria fails, an exception is thrown. A few requests: (1) Can you not throw an exception, but print a warning and resolve the criteria? For example, if I ask for < 8k, up it to 8k and print a warning it's been upped. If I ask for a non-power of 2, can you print a warning and up to to the next supported power of 2? Think of this like a request for a sample rate - if you can't get the exact one, you get what's close and the user can query the actual value? (2) Speaking of powers of 2, why is this a requirement? Can it be any value that is a multiple of a 4k page boundary? Is there something inside the FPGA logic that doesn't allow this to happen? Powers of 2 can be a large buffer size changes. Thanks, Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNOC: AXI Wrapper Configuration busses
On Thu, Sep 6, 2018 at 2:43 PM Pratik Chatterjee via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > Can anyone please provide some insight on the use of configuration buses > in the axi wrapper - why and when would we want to use them? Do they > complement the axis stream signals (m_axis and s_axis) in any way? Thank > you, > I've seen them used when you need to provide tlast along with some configuration data. Specifically, I've seen it used in the FIR filter and window functions where you have reloadable coefficients that have a specific length to it, but potentially unknown. It's slow since really it's just a wrapper around the register writes that also happens to issue tlast when you write to the appropriate register. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] FPGA Repository and Stability
On Tue, Sep 4, 2018 at 6:55 PM Ashish Chaudhari wrote: > On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users > wrote: > > Recently there was a significant change to the noc_block_vector_iir > > (specifically the vector_iir): > > > > > > > https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187 > > > > It's a pretty significant re-write of the block, and this behavior has me > > asking a few questions: > > > > 1) Can anyone at Ettus expand on the reason for the major re-write? It > > appears that the block itself worked previously so it seems like > re-writing > > it was a lot of effort to potentially add new bugs to things which > weren't > > there previously. > > > > There were several reasons that contributed to the re-writing that > block. First off, there was a bug in the delay line implementation > that needed to be fixed. Secondly, we wanted to improve the > readability and resource utilization of blocks where users hand-write > their DSP (as opposed to using third-party AXI-Stream IP). The old > approach was to implement a DSP algorithm using basic operations like > addition, multiplication, rounding, etc each with AXI-Stream > handshaking. This has the following drawbacks: 1) The code is a bit > hard to read because the AXI-Stream stuff takes up code real-estate 2) > It's hard to let the tools infer DSP primitives automatically because > AXI-Stream can get in the way of the standard Xilinx-intended control > sets. 3) The AXI-Stream logic takes up more fabric resources. The > Vector IIR block is the first block that wraps AXI-Stream around the > entire DSP algorithm instead of around basic functions. This is the > way we intend to write future blocks with hand-implemented DSP. The > change is actually a step forward in terms of stability because the > API to the actual DSP kernel is much simpler and intuitive, and is > much closer to how FPGA DSP implementation is taught. The simpler API > also makes it easy for the Xilinx tools to perform > optimization/mapping because AXI-Stream handshaking is not in the way. > Don't get me wrong, AXI-Stream is great, we are just changing the > granularity at which we implement it. > Why start with this block instead of just blocks going forward? I saw the addition of the biquad - great! But, ideally, you'd fix the bug in the delay line and move on if that's what drove people looking into the behavior to begin with? I prefer less AXI streaming interfaces as well, but it just seems like a poor idea to rewrite an already written block and change something out from underneath everyone. > > 2) Why wasn't this re-written block added as a second option for a > vectored > > IIR implementation? There are 64-bits worth of RFNoC block ID's out > there. > > I understand if you don't want to support specific RFNoC blocks anymore, > and > > want to move onto new ones, but can you retire them in a better, more > > thought out way? Moving them to a deprecated folder is fine and giving > one > > or two releases to get people to move away is fine, but please stop > gutting > > and re-writing something like it hasn't completely changed. There are > > people who may want to stick with the old way of doing things (the old > > DDC/DUCs are another recent re-write that could have been handled > better). > > Please give us a chance at trying to maintain stability. > > > > Other than fixing the delay line issue, we did not change the behavior > of the block. We also did not change the software or FPGA interface to > the block. All that changed was the implementation, and that does not > warrant a new block or a deprecated copy. You can argue that if > something/anything changes in a piece of functional code, that it is > inherently unstable. However, that applies to everything from a one > liner bugfix to complete rewrite. That said, if you noticed a bug in > the code, then we will absolutely need to and will fix it. > > In general, RFNoC is still evolving and we are slowly cleaning up > interfaces to reach a point where we are confident that it is easy to > use and it efficiently supports what our customers want to do. We > always try to balance improvements with backwards compatibility, but > there are cases where we cannot guarantee compatibility. In those > cases we will try to minimize the incompatible changes, and increment > the compatibility number to ensure that changes don't go unnoticed to > software. None of that was true for this particular block change. > No offense, but you're wrong in many ways. From an implementation standpoint, your re-write isn't a drop-in replaceme
Re: [USRP-users] FM Spectrum Capture, to many zeros?
On Tue, Sep 4, 2018 at 11:28 AM Jeremy Foran via USRP-users < usrp-users@lists.ettus.com> wrote: > Thanks Fabian, > > I have tried a few different values for timeout as per your recommendation > and none seem to have an affect: > 2.0 > 1.0 > 0.5 > 0.25 > 0.001 > > All have about the same result of ~50% of the samples contain a zero. > > Ive also tried setting the sample sizes from fc32 to sc16 with more or > less the same result. > > What would be a normal amount of zeros to receive from a stream like this? > %1? %10? > Can you link us to a small example you can upload somewhere? It would be enlightening to see what you're talking about in terms of samples. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] FPGA Repository and Stability
Recently there was a significant change to the noc_block_vector_iir (specifically the vector_iir): https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187 It's a pretty significant re-write of the block, and this behavior has me asking a few questions: 1) Can anyone at Ettus expand on the reason for the major re-write? It appears that the block itself worked previously so it seems like re-writing it was a lot of effort to potentially add new bugs to things which weren't there previously. 2) Why wasn't this re-written block added as a second option for a vectored IIR implementation? There are 64-bits worth of RFNoC block ID's out there. I understand if you don't want to support specific RFNoC blocks anymore, and want to move onto new ones, but can you retire them in a better, more thought out way? Moving them to a deprecated folder is fine and giving one or two releases to get people to move away is fine, but please stop gutting and re-writing something like it hasn't completely changed. There are people who may want to stick with the old way of doing things (the old DDC/DUCs are another recent re-write that could have been handled better). Please give us a chance at trying to maintain stability. I've tried to emphasize stability previously, and it seems like the host side tries, almost to a fault, to maintain ABI compatibility and stability, but the FPGA side seems to have a complete disregard for stability. It would be really nice if someone from Ettus could answer the two questions I posed. Thanks, Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Phase Representation: Using Xilinx CORDIC IP with RFNoC
On Tue, Sep 4, 2018 at 9:15 AM Jon Pendlum via USRP-users < usrp-users@lists.ettus.com> wrote: > Hey Steve, > > The complex_to_mag_phase 32-bit output is a concatenation: [31:16] phase, > [15:0] magnitude. There is also complex_to_magphase_int16_int24 if you want > 24-bit phase, mag. The phase value is in scaled radians. If you want a > different phase precision, you will need to create a new CORDIC IP > instance. Using the data with RFNoC, you have two options: 1) choose a > precision that will work with the built in UHD converters. see: > https://files.ettus.com/manual/page_converters.html or 2) handle the > conversion on your own. In either case, AXI Wrapper expects 32-bit data, so > you can concatenate or sign extend your data however works best for you. > To expand on Jon's answer, adding your own converter is pretty easy to do, though I must admit I am not an expert. Attached is what I had to do when receiving a u32 type from a magnitude squared representation from a custom block. Note that if you want to make very complicated typed to pass into a send() or recv() call, that can also work. You just need to register them the same way. One point of confusion I have, though, is when dealing with OOT modules which describe their own converters. It isn't clear to me, but there needs to be a destructor defined: uhd::convert::converter::~converter(). To get things to compile for me, I just defined ~converter() to be nothing since no resources were allocated, but if there are multiple OOT blocks with converters in them (think fancy controller blocks with singular static registrations with libuhd at construction or library loading), each trying to define that destructor, I don't know how this is supposed to work. As an experiment, for documentation, and to be complete, can someone from Ettus write a converter going both ways for the 32-bit concatenation that Jon described - [31:16] phase, [15:0] magnitude on the RFNoC side, and complex float on the host side? Both transmit and receive? I think that would be a good code example to have. Thanks, Brian converter_example.cpp Description: Binary data ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Use same RFNoC block twice
On Fri, Aug 31, 2018 at 2:54 PM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hey everybody,
>
> I've got a question. I have a RFNoC block that has a unique NoC ID as a
> parameter, but is instantiated twice in my design (same situation as the
> Radio Cores or DDC/DUC blocks, that share the same NoC ID but are connected
> to different Crossbar ports when included more than once in the design).
>
> In my software tests I take control of both radio cores separately by
> doing this:
>
> uhd::rfnoc::block_id_t radio_ctrl_id0(0, "Radio", radio_id0); // RX0
> (DB-A)
> uhd::rfnoc::block_id_t radio_ctrl_id1(0, "Radio", radio_id1); // RX1
> (DB-B)
> uhd::rfnoc::radio_ctrl::sptr radio_ctrl0 = usrp->get_block_ctrl<
> uhd::rfnoc::radio_ctrl >(radio_ctrl_id0);
> uhd::rfnoc::radio_ctrl::sptr radio_ctrl1 = usrp->get_block_ctrl<
> uhd::rfnoc::radio_ctrl >(radio_ctrl_id1);
>
> And I'm taking control of custom, generic blocks like this:
>
> uhd::rfnoc::block_ctrl_base::sptr myblock_ctrl;
> if (usrp->has_block(cubepacketizer_blockid)) {
> myblock_ctrl = usrp->get_block_ctrl(myblock_id);
> blocks.push_back(myblock_ctrl->get_block_id());
> }
>
> What should I do now if, in this example, myblock_id is instantiated twice
> in my core, and I need to get a controller for one of each blocks?
> (For instance, to process two different signal paths, coming from both
> Radio Cores).
>
Your block ID will be (0, "CustomBlock", 0) for the first instance, and (0,
"CustomBlock", 1) for the other instance.
auto custom_ctrl0 =
usrp->get_block_ctrl(customblock_id0)
To get the custom control block. Just like the radio example.
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Transmit Thread Stuck Receiving Tx Flow Control Packets
On Tue, Aug 28, 2018 at 4:02 PM Alan Conrad via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi All,
>
>
>
> I’ve been working on an application that requires two receive streams and
> two transmit streams, written using the C++ API. I have run into a problem
> when transmitting packets and I am hoping that someone has seen something
> similar and/or may be able to shed some light on this.
>
>
>
> My application is streaming two receive and two transmit channels, each at
> 100 Msps over dual 10GigE interfaces (NIC is Intel X520-DA2). I have two
> receive threads, each calling recv() on separate receive streams, and two
> transmit threads each calling send(), also on separate transmit streams.
> Each receive thread copies samples into a large circular buffer. Each
> transmit thread reads samples from the buffer to be sent in the send()
> call. So, each receive thread is paired with a transmit thread through a
> shared circular buffer with some mutex locking to prevent simultaneous
> access to shared circular buffer memory.
>
>
>
> I did read in the UHD manual that recv() is not thread safe. I assumed
> that this meant that recv() is not thread safe when called on the same
> rx_streamer from two different threads but would be ok when called on
> different rx_streamers. If this is not the case, please let me know.
>
>
>
> On to my problem…
>
>
>
> After running for several minutes, one of the transmit threads will get
> stuck in the send() call. Using strace to monitor the system calls it
> appears that the thread is in a loop continuously calling the
>
> poll() and recvfrom() system calls from within the UHD API. Here’s the
> output of strace attached to one of the transmit threads after this has
> occurred. These are the only two system calls that get logged for the
> transmit thread once this problem occurs.
>
>
>
> 11:19:04.564078 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
>
> 11:19:04.664276 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL,
> NULL) = -1 EAGAIN (Resource temporarily unavailable)
>
> 11:19:04.664381 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
>
> 11:19:04.764600 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL,
> NULL) = -1 EAGAIN (Resource temporarily unavailable)
>
> 11:19:04.764699 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
>
> 11:19:04.864906 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL,
> NULL) = -1 EAGAIN (Resource temporarily unavailable)
>
>
>
> This partial stack trace shows that the transmit thread is stuck in the
> while loop in the tx_flow_ctrl() function. I think this is happening due
> to missed or missing TX flow control packets.
>
>
>
> #0 0x7fdb8fe4fbf9 in __GI___poll (fds=fds@entry=0x7fdb167fb510,
> nfds=nfds@entry=1, timeout=timeout@entry=100) at
> ../sysdeps/unix/sysv/linux/poll.c:29
>
> #1 0x7fdb9186de45 in poll (__timeout=100, __nfds=1,
> __fds=0x7fdb167fb510) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
>
> #2 uhd::transport::wait_for_recv_ready (timeout=0.10001,
> sock_fd=) at
> /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_common.hpp:59
>
> #3 udp_zero_copy_asio_mrb::get_new (index=@0x55726266f6e8: 28,
> timeout=, this=)
>
> at /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_zero_copy.cpp:79
>
> #4 udp_zero_copy_asio_impl::get_recv_buff (this=0x55726266f670,
> timeout=) at
> /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_zero_copy.cpp:226
>
> #5 0x7fdb915d48cc in tx_flow_ctrl (fc_cache=..., async_xport=...,
> endian_conv=0x7fdb915df600 (unsigned int)>,
>
> unpack=0x7fdb918b1090
> uhd::transport::vrt::if_packet_info_t&)>)
>
> at
> /home/aconrad/rfnoc/src/uhd/host/lib/usrp/device3/device3_io_impl.cpp:345
>
>
>
> The poll() and recvfrom() calls are in the
> udp_zero_copy_asio_mrb::get_new() function in udp_zero_copy.cpp.
>
>
>
> Has anyone seen this problem before or have any suggestions on what else
> to look at to further debug this problem? I have not yet used Wireshark to
> see what’s happening on the wire, but I’m planning to do that. Also note
> that, if I run a single transmit/receive pair (instead of two) I don’t see
> this problem and everything works as I expect.
>
>
>
> My hardware is an X310 with the XG firmware and dual SBX-120
> daughterboards. Here are the software versions I’m using, as displayed by
> the UHD API when the application starts.
>
>
>
> [00:00:00.49] Creating the usrp device with:
> addr=192.168.30.2,second_addr=192.168.40.2...
>
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_4.0.0.rfnoc-devel-788-g1f8463cc
>
>
>
> The host is a Dell PowerEdge R420 with 24 CPU cores and 24 GB ram. I
> think the clock speed is a little lower than recommended at 2.7 GHz but
> thought that I could distribute the work load across the various cores to
> account for that. Also, I have followed the instructions to setup dual 10
> GigE interfaces for the X310 here,
>
Re: [USRP-users] RFNoC fifo filling up
On Wed, Aug 22, 2018 at 5:32 PM Jason Matusiak < ja...@gardettoengineering.com> wrote: > Brian, I really only want to send data when appropriate. I don't have the > code in front if me at the moment, but I can have tvalid high while I wait > for tready, right. So I don't see why it would be an issue if I change > tdata while tvalid is high and tready is low. > Changing tdata after tvalid was asserted while tready is low is a violation of the AXI4 streaming spec I am pretty sure. Don't do this. > > But I've spent the last two days trying to debuf this before I found out > it was the axi fifo filling up. It is weird to me that it is slowly falling > behind. It makes me feel like tlast maybe has something to do with it. > The computation clock for the rfnoc blocks is around 214MHz. The radio sends stuff out at 200MHz, so you will always produce more and faster than the radio can keep up naturally. It's inherent in the system. Are you saying you are producing samples which should have gone out of the radio by the time you're making more, and the downstream FIFO's are not cleared out? This is a different problem altogether. I guess, if you can go back to the beginning, what exactly is happening that you are not sure about? Did you find this out using just simulation, or did you instrument an ILA inside the FPGA and are observing actual signals in the FPGA showing this phenomenon? Sorry for the confusion, but I think I misunderstood your original issue. Clarification is good to have. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC fifo filling up
On Wed, Aug 22, 2018 at 3:53 PM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > This is a long shot, but I have been fighting with my rfnoc block the last > few days trying to figure out why it won't work. I am basically combining > the threshold block and the siggen block (so it takes in values, and spits > out data based on the siggen parameters). > > My block has been spitting some samples on startup and then just stops. > Digging around, what I can see is that the axi_fifo_short's FIFO primitive > is filling up. If I add debug to my testbench, I can see that my data is > slowly losing the war on reading as fast as I am writing. Once it is full, > I end up in a deadlock it appears. > > Since this is somewhat custom, there probably isn't a good answer, but > does anyone have a suggestion where to look into this? The main module > where I think my axi_interfaces are getting screwed up somehow (on my end) > is the axi_async_stream.v module. > > ANY help would be appreciated > It sounds like you want your siggen block to be able to produce samples without following the flow control coming back to you (tready). Unfortunately, you can't. You need to obey tready and stop the generation of samples accordingly. Is this what's happening? Your siggen block kicks off, and at some point, tready goes low, but you still want to push tvalid and tdata out? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNOC transmission setup
On Fri, Aug 10, 2018 at 5:03 PM Anton Schlegel via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I am having trouble setting up the transmission chain with RFNOC on an
> X310. I was able to transmit and receive using multi_usrp on B205.
>
> For transmission, I understand that the RFNOC process will be
> DmaFIFO->DUC->Radio. Then I can create a tx_streamer and transmit the
> needed information.
>
> When creating a DUC block to connect, would I follow a similar process to
> the creation of a Radio block like in the "rfnoc_rx_to_file.cpp" example?
> Or would I just create a block_ctrl_base with the blockid set to the
> correct DUC block? If I follow a similar process to the Radio block
> mentioned above, what parameters would I have to set? Also, for DmaFIFO I
> can create with block_ctrl_base, correct?
>
I've used the following:
printf( "Creating USRP with: %s\n", usrp_args.c_str() ) ;
auto usrp = uhd::device3::make(usrp_args) ;
// Blank graph for connecting blocks
auto tx_graph = usrp->create_graph("TX") ;
// Host -> Radio -> Antenna
auto ctrl_radio =
usrp->get_block_ctrl(uhd::rfnoc::block_id_t(0,
"Radio", 1)) ;
auto ctrl_duc = usrp->get_block_ctrl(uhd::rfnoc::block_id_t(0, "DUC")) ;
auto ctrl_dmafifo = usrp->get_block_ctrl(uhd::rfnoc::block_id_t(0,
"DmaFIFO")) ;
auto blockid_radio = ctrl_radio->get_block_id() ;
auto blockid_duc = ctrl_duc->get_block_id() ;
auto blockid_dmafifo = ctrl_dmafifo->get_block_id() ;
// Connect the graph Host -> DMA FIFO -> DUC -> Radio
tx_graph->connect( blockid_dmafifo, blockid_duc ) ;
tx_graph->connect( blockid_duc, blockid_radio ) ;
// Settings here
ctrl_duc->set_arg("input_rate", 200.0e6) ;
ctrl_duc->set_arg("output_rate", 200.0e6) ;
// Generate the TX stream, complex floats going in from the host, and
s16 complex in the FPGA
uhd::stream_args_t stream_args("fc32", "sc16") ;
// DUC is the target of the host connection stream
uhd::device_addr_t target ;
target["block_id"] = blockid_dmafifo ;
stream_args.args = target ;
stream_args.channels = std::vector(1) ;
auto tx_stream = usrp->get_tx_stream(stream_args) ;
// Tune to the frequency of interest
ctrl_radio->set_tx_frequency(920.0e6, 0) ;
printf( "Actual frequency: %14.8f\n", ctrl_radio->get_tx_frequency(0) )
;
Then just use the tx_stream as you normally would.
Also you can set the input_rate or other parameters of the DUC or other
blocks as you see fit.
Good luck.
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD API
On Mon, Aug 6, 2018 at 3:37 AM TIMMEN Koen < koen.tim...@thalesaleniaspace.com> wrote: > Brian, > > > > I am not sure if I have stated my problem clearly. So I will reformulate: > My HDL module which I have verified using testbenches needs to be > controlled from the UHD API. However, I have trouble doing this. Following > the two examples available from the source directory I connected my blocks > as follows (using uhd:rfnoc::graph::connect(), without creating a streamer): > > > > SIGGEN à DUC à RADIO > > > > However, the USRP device does not transmit any samples. > > > > As I indicated, I am not sure whether or not to generate a stream. Because > I don’t know what it is intended for. Should I for example create a stream > object to manage the sample flow from the SIGGEN to the DUC? Or will it > suffice to use uhd::rfnoc::graph::connect(). Or do I need to use both? > Sorry for the confusion. No, you just need to connect the graph together and the blocks should be stitched together. > > > Then finally, once I have initialized and connected all blocks, how do I > indicate to the radio it can start transmitting samples? The SIGGEN block > generates samples after I write in a certain user register. It then stores > these samples in a FIFO, which should offload the samples to the next block > as soon as this activates ‘tready’. But I’m not sure if this ever happens > or if the ‘tready’ signal might not be linked correctly for example. > You just need to write to the appropriate register. To verify the tready signal in your design, you can use the internal logic analyzer in Vivado and check out what the core internally is doing. > > > Hopefully now I indicated my struggles a bit better, if anything is > unclear please don’t hesitate to let me know. > Yes, it was more clear. Sorry for the confusion. Hopefully this is more clear. Brian > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
