Re: [USRP-users] 2955 multiple receivers not working together
I am attaching the .grc file. I have installed gnuradio in windows. Our USRP has gone for repair so can't check the UHD version. Regards, Koyel From: USRP-users on behalf of Marcus D. Leech via USRP-users Sent: Thursday, November 29, 2018 9:28:47 PM To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] 2955 multiple receivers not working together On 11/29/2018 02:20 AM, Koyel Das (Vehere) via USRP-users wrote: Hi, I am trying to receive signals from antennas connected to two RX2 ports of USRP 2955 R. But when the frequency sink pops up there is no signal. Also I want to be able to use 4 receivers of USRP 2955R together in a gnuradio by using 4 ports in a USRP source. Two or more not working but one is working fine. Please suggest solutions. Also 2 for 2954R is working correctly. Regards, Koyel Could you perhaps share the flow-graph that you're using. What version of UHD are you using? test.grc Description: test.grc ___ 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.
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 &node: 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
>>
>>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Bug in timed switching of sample rate
Hi Marcus, is there any update? Best regards, Fabian Am 19.11.2018 um 20:22 schrieb Marcus D. Leech via USRP-users: On 11/19/2018 06:35 AM, Fabian Schwartau via USRP-users wrote: Anyone? This is a quite annoying bug and I am having trouble working around it as I cannot meet my timing requirements. I'm only about 50% certain that sample-rate setting is covered by timed commands. I'll talk to R&D and get back to you on this. Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users: Hello everyone, I am experencing some issues when switching the sample rate. I have two synchronized USRP X310 with a total of 4 TwinRX. I am doing timed commands to jump around in the spectrum with all receivers at the same frequency (SIMO stuff). I also need to switch sample rates in between. When I keep the sample rate constant, everything works fine, but once I switch it between two timed receptions, I get very strange errors. Like I get an end-of-frame after just a part of the samples I requested. It seems like it is not possible to time the sample rate switch command. Here is a debug output of my code which makes it quite clear what happens: (1) Changed sample rate from 1e+07 to 5e+07 (2) Requested 32768 Samples (3) Requested 32768 Samples (4) Requested 32768 Samples (5) Changed sample rate from 5e+07 to 1e+07 (6) Reading 32768 Samples (7) Got only 6553 of 32768 samples at EOF Commands 1-5 are transmitted to the USRP right away using its command buffer. Then my program starts reading the first requested 32768 but gets only 6553, which is precisely 1/5th of the requested samples. I guess this is because he switched sample rate to 1/5th right before executing the first stream command. But the sample rate switch is also timed and should be executed after the three stream commands. I attached the part of the code which is responsible for sending the timed commands to the USRPs. This runs basically in a while(1) in a seperate thread, while there is a seconds thread receiving the data blocks, which produced the lines 6-7 of above output. Is this a bug or feature I don't get? Are set_rx_rate commands not timed when using set_command_time? How can I solve this isse? I need very precise timing and also fast switching between frequencies and sample rates. Best regards, Fabian ___ 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 ___ 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 &node: 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] Is there any method for X310 to support 122.88M Sampling rate?
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. So, I'd say, you're not going to implement this as a rational resampler. So, either find some sampling rate close enough for your system to work (for example, if your system can work with a 2% sample rate error, go for 120 MHz sampling rate, and things become much easier! Interpolate by 3, decimate by 5, done, you could implement that as an FPGA resampler yourself, if you find your computer isn't up to doing that conversion). Or, implement an arbitrary resampler. I can't really advise you on that based on the info you gave us: Arbitrary resamplers can become quite computationally intense, and ugly in error bounds, but can often be designed to fit your specific application's needs. So, what application requires a sampling rate of 122.88 MHz? Best regards, Marcus M > > Best Regards, > J.Jeffson > ___ > 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] 2955 multiple receivers not working together
UHD is installed on your computer. You hence *can* check the UHD version that you've installed. On Fri, 2018-11-30 at 09:33 +, Koyel Das (Vehere) via USRP-users wrote: > I am attaching the .grc file. I have installed gnuradio in windows. > Our USRP has gone for repair so can't check the UHD version. > > Regards, > Koyel > From: USRP-users on behalf of > Marcus D. Leech via USRP-users > Sent: Thursday, November 29, 2018 9:28:47 PM > To: usrp-users@lists.ettus.com > Subject: Re: [USRP-users] 2955 multiple receivers not working > together > > On 11/29/2018 02:20 AM, Koyel Das (Vehere) via USRP-users wrote: > > Hi, > > > > I am trying to receive signals from antennas connected to two RX2 > > ports of USRP 2955 R. > > But when the frequency sink pops up there is no signal. Also I want > > to be able > > to use 4 receivers of USRP 2955R together in a gnuradio by using 4 > > ports in a USRP source. Two > > or more not working but one is working fine. Please suggest > > solutions. Also 2 for 2954R is working correctly. > > > > Regards, > > Koyel > > > Could you perhaps share the flow-graph that you're using. What > version of UHD are you using? > > > > ___ > 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] 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 FPGA clear_tx_seqnum behavior
I just wanted to throw this email back out there as it had been biting me again and I didn't realize it. Without making the below mods to split-stream, I can only run a flowgraph one time. After that, things get hosed (split-stream isn't getting reset properly) and I have to reboot. After making the mod, I am working pretty well (small sample size though). - Original Message - Subject: RE: Re: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior From: "Jason Matusiak" Date: 7/2/18 12:03 pm To: "Brian Padalino" Cc: "USRP-users@lists.ettus.com" I found the problem with my one flowgraph that was still not working after I updated my blocks, it was the RFNoC "Split Stream" block. It appears that it was never updated to use these new changes. I sort of modified it based on the addsub block and it seems to work for me, but YMMV. My changed were: - wire [1:0] clear_tx_seqnum; + wire [1:0] clear_tx_seqnum, clear_tx_seqnum_bclk; +synchronizer #(.INITIAL_VAL(1'b0), .WIDTH(2)) clear_tx_sync_i ( + .clk(bus_clk), .rst(1'b0), .in(clear_tx_seqnum), .out(clear_tx_seqnum_bclk)); chdr_deframer_2clk chdr_deframer ( - .samp_clk(ce_clk), .samp_rst(ce_rst), .pkt_clk(bus_clk), .pkt_rst(bus_rst), + .samp_clk(ce_clk), .samp_rst(ce_rst), .pkt_clk(bus_clk), .pkt_rst(bus_rst | clear_tx_seqnum_bclk), chdr_framer_2clk #(.SIZE(MTU)) chdr_framer ( - .samp_clk(ce_clk), .samp_rst(ce_rst | clear_tx_seqnum[i]), .pkt_clk(bus_clk), .pkt_rst(bus_rst), + .samp_clk(ce_clk), .samp_rst(ce_rst | clear_tx_seqnum[i]), .pkt_clk(bus_clk), .pkt_rst(bus_rst | clear_tx_seqnum_bclk[i]), ~Jason - Original Message - Subject: RE: Re: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior Date: 7/2/18 6:54 am To: "Brian Padalino" Cc: "USRP-users@lists.ettus.com" Thanks Brian, that seemed to be the trick, at least for the initial flowgraph I was trying to use (I think I must have missed a block in my second flowgraph). Sadly, I can only run it once and then it doesn't work on the second run, so I need to investigate that next. I feel like I remember something in the mailing list that was similar to that, so I will need to run that down (I am guessing it has something to do with that clear_tx change again). Thanks again, I owe you! Now, if you're working off the latest rfnoc-devel as of today, I believe all you need to do to port from a 2015.4 to 2017.4 design is: - add bus_clk and bus_rst to the axi_wrapper instantiation if you use it - use the chdr_framer_2clk/chdr_deframer_2clk versions instead since CHDR operations changed clock domains If you can't run uhd_usrp_probe and see your block listed after just adding the bus_clk/bus_rst to axi_wrapper, then something else beyond what I've had to debug is probably happening. Hope 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] X310, basicRX - using all channels in real mode with DDC
I notice that the GRC is using RFNoC blocks. Perhaps it would be a good test to implement standard UHD USRP blocks. I think that your functionality is possible with the USRP blocks. Rob On Mon, Nov 19, 2018 at 7:25 AM Gwenhael Goavec-Merou via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > No ideas, advice or anything else to solve my problem? > > Thank > > Gwen > > On Tue, 6 Nov 2018 22:34:27 +0100 > Gwenhael Goavec-Merou via USRP-users wrote: > > > On Tue, 06 Nov 2018 15:42:10 -0500 > > "Marcus D. Leech" wrote: > > > > > On 11/06/2018 12:23 PM, Gwenhael Goavec-Merou wrote: > > > > On Tue, 06 Nov 2018 12:09:02 -0500 > > > > "Marcus D. Leech" wrote: > > > > > > > >> On 11/06/2018 10:24 AM, Gwenhael Goavec-Merou wrote: > > > >>> On Tue, 06 Nov 2018 09:40:09 -0500 > > > >>> "Marcus D. Leech via USRP-users" > wrote: > > > >>> > > > On 11/06/2018 04:12 AM, Gwenhael Goavec-Merou via USRP-users > wrote: > > > > Hi, > > > > > > > > My environment is: > > > > USRP: X310 with basicRX (currently one but 6 in a near future) > > > > UHD: 3.13.1.0-rc1 > > > > GNURadio: 3.7.13.4-r2 > > > > gr-ettus: master branch, up to date > > > > > > > > I need to sample 4 real signal / USRP and to demodulate / > decimate > > > > before transfer to the PC. > > > > > > > > I have created a GNURadio flow with: > > > > - 2 Radio (id 0 and 1), configured with 2 channels > > > > - 2 DDC (id 0 and 1), with 2 channels, with a center frequency > fixed > > > > to XX MHz > > > > - 4 complex To Real; > > > > - 1 QT Gui with 4 inputs. > > > > > > > > Each channel of each radio is connected to an DDC input (radio0 > > > > channel 0 to DDC0 input 0, radio0 channel 1 to DDC0 input 1, > etc.) > > > > > > > > With this setup and with an input configured as XX + YY MHz (to > have a > > > > beatnote) I'm able to see a sinusoid on the qt for all channels > (if I > > > > plug / unplug an input signal the corresponding plot is equal to > 0 or > > > > displays the signal). > > > > But: > > > > 1/ the console panel display continuouly messages about channels > > > > overrun 2/ the data flow is not continuous (visible in qt plot) > (I > > > > suppose is due to 1/ ) > > > > 3/ channels are not aligned (I suppose is due to 1/ and/or 2/ > > > > > > > > Theorically, by reading HDL files for the X310 firmware it's > seems > > > > possible to use this configuration. > > > > > > > > Then, how to fix my issue? > > > > - Is it a USRP/UHD limitation? > > > > - gr-ettus seems not heavily upgraded, is something must be > modified > > > > in this repository? > > > > - I am just wrong somewhere on my design? > > > > > > > > Thank you very much > > > > > > > > Gwen > > > > > > > What is the sample rate as delivered to the PC? What kind of > PC? > > > >>> The sample rate is 3MS/s for each channels after DDC (200MS/s > before due > > > >>> to the ADC). > > > >>> My PC is a Lenovo thinkpad x230 with a 1Gb ethernet card. > > > Overrun means that your PC isn't keeping up with the sample flow. > > > > > > >>> I've just done several test with only 2 channels : > > > >>> - 2 radio, 1 channel/radio and 2 DDC with 1 input (first on > radio0, a > > > >>> second radio1) : > > > >>> - data continuous (but not synchronized) > > > >>> - no message on display panel > > > >>> - 2 radio, 1 channel/radio and 1 DDC with 2 input : > > > >>> - console panel displays continuouly "Ooverrun on chan 0" > > > >>> - data not continuous > > > >>> - after a short time : freeze > > > >>> - 1 radio with 2 channels and 1 DDC with 2 input : > > > >>> - console panel displays continuouly "Ooverrun on chan 0" > and > > > >>> "Ooverrun on chan 1" > > > >>> - data not continuous. > > > >>> - 1 radio with 2 channels and 2 DDC with 1 input : > > > >>> - console panel displays continuouly "Ooverrun on chan 0" > > > >>> - data not continuous. > > > >>> > > > >>> So, the first test seems to show it's possible with my computer to > > > >>> receive 2 channel 3MS/s without overrun. Other tests seems to show > a > > > >>> problem for radio and/or for DDC to send or receive the full speed > ADC > > > >>> flow. > > > >>> > > > >>> Thank. > > > >>> > > > >>> Gwen > > > >> The only immediate comment I have is that 3Msps is not a valid rate > for > > > >> the DDC with a 200Msps input--rates must be an integer fraction > > > >> of the input sample rate. > > > > Tested with 2Msps this the same result... > > > >> It would be helpful if you shared your flow-graph for the cases that > > > >> don't work. > > > > joined > > > > > > > > Gwen > > > Also, in your Radio BLock, you have "E310: 2 channels" selected, which > > > very likely doesn't work with X310. > > > > > I've checked multiple time the flow-graph, top_block.py, do grep in > gr-et
Re: [USRP-users] Bug in timed switching of sample rate
On 11/30/2018 06:11 AM, Fabian Schwartau via USRP-users wrote: Hi Marcus, is there any update? Best regards, Fabian Still being worked. Am 19.11.2018 um 20:22 schrieb Marcus D. Leech via USRP-users: On 11/19/2018 06:35 AM, Fabian Schwartau via USRP-users wrote: Anyone? This is a quite annoying bug and I am having trouble working around it as I cannot meet my timing requirements. I'm only about 50% certain that sample-rate setting is covered by timed commands. I'll talk to R&D and get back to you on this. Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users: Hello everyone, I am experencing some issues when switching the sample rate. I have two synchronized USRP X310 with a total of 4 TwinRX. I am doing timed commands to jump around in the spectrum with all receivers at the same frequency (SIMO stuff). I also need to switch sample rates in between. When I keep the sample rate constant, everything works fine, but once I switch it between two timed receptions, I get very strange errors. Like I get an end-of-frame after just a part of the samples I requested. It seems like it is not possible to time the sample rate switch command. Here is a debug output of my code which makes it quite clear what happens: (1) Changed sample rate from 1e+07 to 5e+07 (2) Requested 32768 Samples (3) Requested 32768 Samples (4) Requested 32768 Samples (5) Changed sample rate from 5e+07 to 1e+07 (6) Reading 32768 Samples (7) Got only 6553 of 32768 samples at EOF Commands 1-5 are transmitted to the USRP right away using its command buffer. Then my program starts reading the first requested 32768 but gets only 6553, which is precisely 1/5th of the requested samples. I guess this is because he switched sample rate to 1/5th right before executing the first stream command. But the sample rate switch is also timed and should be executed after the three stream commands. I attached the part of the code which is responsible for sending the timed commands to the USRPs. This runs basically in a while(1) in a seperate thread, while there is a seconds thread receiving the data blocks, which produced the lines 6-7 of above output. Is this a bug or feature I don't get? Are set_rx_rate commands not timed when using set_command_time? How can I solve this isse? I need very precise timing and also fast switching between frequencies and sample rates. Best regards, Fabian ___ 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 ___ 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] 2955 multiple receivers not working together
On 11/30/2018 04:33 AM, Koyel Das (Vehere) wrote: I am attaching the .grc file. I have installed gnuradio in windows. Our USRP has gone for repair so can't check the UHD version. Regards, Koyel The attached works for 4 channels just fine with my local UHD installation. twinrx_test.grc Description: application/gnuradio-grc ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior
Hey Jason, I haven't followed your thread thoroughly, but I thought I'd comment something that could be of help, even though the code you included is apparently from July: I wouldn't use a standard synchronizer for a one-clock pulse signal such as clear_tx_seqnum. Instead, I'd recommend using Ettus's own pulse synchronizer: pulse_synchronizer clear_tx_sync_i ( .clk_a(bus_clk), .rst_a(bus_rst), .pulse_a(clear_tx_seqnum), .busy_a(), .clk_b(ce_clk), .pulse_b(clear_tx_seqnum_bclk) ); Regards, Leo On Fri, Nov 30, 2018 at 2:04 PM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > I just wanted to throw this email back out there as it had been biting me > again and I didn't realize it. Without making the below mods to > split-stream, I can only run a flowgraph one time. After that, things get > hosed (split-stream isn't getting reset properly) and I have to reboot. > > After making the mod, I am working pretty well (small sample size though). > > > > - Original Message - > > Subject: RE: Re: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior > > From: "Jason Matusiak" > Date: 7/2/18 12:03 pm > To: "Brian Padalino" > Cc: "USRP-users@lists.ettus.com" > > I found the problem with my one flowgraph that was still not working after > I updated my blocks, it was the RFNoC "Split Stream" block. It appears > that it was never updated to use these new changes. I sort of modified it > based on the addsub block and it seems to work for me, but YMMV. > > My changed were: > > - wire [1:0] clear_tx_seqnum; > + wire [1:0] clear_tx_seqnum, clear_tx_seqnum_bclk; > > +synchronizer #(.INITIAL_VAL(1'b0), .WIDTH(2)) clear_tx_sync_i ( > + .clk(bus_clk), .rst(1'b0), .in(clear_tx_seqnum), > .out(clear_tx_seqnum_bclk)); > > chdr_deframer_2clk chdr_deframer ( > - .samp_clk(ce_clk), .samp_rst(ce_rst), .pkt_clk(bus_clk), > .pkt_rst(bus_rst), > + .samp_clk(ce_clk), .samp_rst(ce_rst), .pkt_clk(bus_clk), > .pkt_rst(bus_rst | clear_tx_seqnum_bclk), > > chdr_framer_2clk #(.SIZE(MTU)) chdr_framer ( > - .samp_clk(ce_clk), .samp_rst(ce_rst | clear_tx_seqnum[i]), > .pkt_clk(bus_clk), .pkt_rst(bus_rst), > + .samp_clk(ce_clk), .samp_rst(ce_rst | clear_tx_seqnum[i]), > .pkt_clk(bus_clk), .pkt_rst(bus_rst | clear_tx_seqnum_bclk[i]), > > ~Jason > > > - Original Message - > Subject: RE: Re: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior > Date: 7/2/18 6:54 am > To: "Brian Padalino" > Cc: "USRP-users@lists.ettus.com" > > Thanks Brian, that seemed to be the trick, at least for the initial > flowgraph I was trying to use (I think I must have missed a block in my > second flowgraph). > > Sadly, I can only run it once and then it doesn't work on the second run, > so I need to investigate that next. I feel like I remember something in > the mailing list that was similar to that, so I will need to run that down > (I am guessing it has something to do with that clear_tx change again). > > Thanks again, I owe you! > > > Now, if you're working off the latest rfnoc-devel as of today, I believe > all you need to do to port from a 2015.4 to 2017.4 design is: > > - add bus_clk and bus_rst to the axi_wrapper instantiation if you use it > - use the chdr_framer_2clk/chdr_deframer_2clk versions instead since > CHDR operations changed clock domains > > If you can't run uhd_usrp_probe and see your block listed after just > adding the bus_clk/bus_rst to axi_wrapper, then something else beyond what > I've had to debug is probably happening. > > Hope this helps. > > Brian > > ___ > 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] Is there any method for X310 to support 122.88M Sampling rate?
Thanks very much for advice. My application is about sampling design for FFT about 5G SDR implementation, but I may still try arbitrary resampler. Best Regards J.Jeffson -- Origin message -- >From："Brian Padalino" >To：marcus.muel...@ettus.com >Subject：Re: [USRP-users] Is there any method for X310 to support 122.88M >Sampling rate? >Date：2018-12-01 00:39:27On 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
