Re: [USRP-users] Sync problem in custom DUC
This is the code for the adder (between dds_timed and axi_wrapper):
assign s_axis_data_tvalid2[0] = s_axis_data_tvalid[1] & s_axis_data_tvalid[0
];
assign s_axis_data_tvalid2[1] = s_axis_data_tvalid[1] & s_axis_data_tvalid[0
];
assign s_axis_data_tuser2 = s_axis_data_tuser;
assign s_axis_data_tlast2[0] = s_axis_data_tlast[0];
assign s_axis_data_tlast2[1] = s_axis_data_tlast[1];
assign s_axis_data_tdata2[15: 0] = s_axis_data_tdata[47:32] +
s_axis_data_tdata[15: 0];
assign s_axis_data_tdata2[31:16] = s_axis_data_tdata[63:48] +
s_axis_data_tdata[31:16];
assign s_axis_data_tready_aux = ~|(~{s_axis_data_tready_out[0
],s_axis_data_tready_out[1]} & 2'b11);
assign s_axis_data_tready[0] = s_axis_data_tvalid[0] & s_axis_data_tvalid[1]
& s_axis_data_tready_aux;
assign s_axis_data_tready[1] = s_axis_data_tvalid[0] & s_axis_data_tvalid[1]
& s_axis_data_tready_aux;
El vie., 10 jul. 2020 a las 11:59, Carlos Alberto Ruiz Naranjo (<
carlosruiznara...@gmail.com>) escribió:
> Hi,
>
> I'm customizing the DUC block to do it 2input:1output
>
> input 0 ---> DUC --->
> add ---> output
> input 1 ---> DUC --->
>
> I have added an addsub module between dds_timed and axi_wrapper.
> Apparently it works fine. I can see two tones in the output if the inputs
> are 2 tones.
>
> But I have a synchronization problem. If input_0 is a sine and input_1 is
> a sine with pi phase the output should be 0. And the output is 0, but after
> a while (3 minutes) no. I think that the channels are out of sync before
> the adder.
>
> Any idea about what is happening?
>
> Thank you :)
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Sync problem in custom DUC
Hi, I'm customizing the DUC block to do it 2input:1output input 0 ---> DUC ---> add ---> output input 1 ---> DUC ---> I have added an addsub module between dds_timed and axi_wrapper. Apparently it works fine. I can see two tones in the output if the inputs are 2 tones. But I have a synchronization problem. If input_0 is a sine and input_1 is a sine with pi phase the output should be 0. And the output is 0, but after a while (3 minutes) no. I think that the channels are out of sync before the adder. Any idea about what is happening? Thank you :) ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] timeouts problems with custom DUC multi channel
Thank you Rob :) I have fixed the problem with the adder between axi_rate_change dds_timed. El jue., 4 jun. 2020 a las 0:13, Rob Kossler () escribió: > I think that it is dependent on tvalid because both "a" and "b" need to be > consumed on the same sample. So, the code does not assert tready for > either input until the tvalid is asserted for both inputs. > > On Wed, Jun 3, 2020 at 6:06 AM Carlos Alberto Ruiz Naranjo via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> >> I have modified the DUC block to do it 2inputs-1outputs. The output is >> duc_0 + duc_1. >> >> input_0 ---> duc_0 ---> >> cadd ---> output >> input_1 ---> duc_1 ---> >> >> Apparently it works fine, but after 1 second I have timeout problems and >> the output is weird. >> >> cadd is the Ettus complex adder ( >> https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/cadd.v) >> 3.15LTS >> >> I think that it due the tvalid/tready. If I use ( >> https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/cadd.v#L23 >> ): >> >>assign int_tvalid = a_tvalid & b_tvalid; >> * assign a_tready = int_tvalid & int_tready;* >>assign b_tready = a_tready; >> >> a_tready and b_tready are always '0' and I haven't any output. But if I >> use: >> >>assign int_tvalid = a_tvalid & b_tvalid; >> * assign a_tready = int_tready; //Independent tready* >>assign b_tready = a_tready; >> >> I have the timeout problems. Why is tready dependent of tvalid? >> >> Thank you. >> ___ >> 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] timeouts problems with custom DUC multi channel
Hi, I have modified the DUC block to do it 2inputs-1outputs. The output is duc_0 + duc_1. input_0 ---> duc_0 ---> cadd ---> output input_1 ---> duc_1 ---> Apparently it works fine, but after 1 second I have timeout problems and the output is weird. cadd is the Ettus complex adder ( https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/cadd.v) 3.15LTS I think that it due the tvalid/tready. If I use ( https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/cadd.v#L23 ): assign int_tvalid = a_tvalid & b_tvalid; * assign a_tready = int_tvalid & int_tready;* assign b_tready = a_tready; a_tready and b_tready are always '0' and I haven't any output. But if I use: assign int_tvalid = a_tvalid & b_tvalid; * assign a_tready = int_tready; //Independent tready* assign b_tready = a_tready; I have the timeout problems. Why is tready dependent of tvalid? Thank you. ___ 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
Then I will try with 4 ports in DmaFIFO. Later maybe I will need to add more ports, does anyone have any ideas? 2 DmaFIFO, big FIFO_LOOPBACK? The throughput is about 11MSamples. I would like to know the complex about that, because maybe it doesn't be possible for my project. El jue., 21 may. 2020 a las 22:24, Rob Kossler () escribió: > ok. I'm not sure if there is an upper limit, but I believe you should be > able to have 4 ports because there are 4 ports in the DmaFIFO on the N310. > > On Thu, May 21, 2020 at 4:21 PM Carlos Alberto Ruiz Naranjo < > carlosruiznara...@gmail.com> wrote: > >> Hi Rob, >> >> I'm using UHD-3.15.LTS and I have developed a custom DUC with N inputs >> and 1 output. I have done the same with the DDC (1:N) and it works fine. >> But with the DUC I have the problem with the DMA_FIFO, I need one DMA_FIFO >> channel per DUC channel. I have thought about some solutions and I would >> like to know which would be the best or if they are possible before I >> started developing: >> >> - Increase the DMA_FIFO ports: from 2 to 4. >> - Add another DMA_FIFO. >> - Use FIFO_LOOPBACK with large size. >> >> My graph is: DMA_FIFO(N:N) -> (N:1) DUC -> (1) Radio >> >> Thank you :) >> >> >> >> >> El jue., 21 may. 2020 a las 21:13, Rob Kossler () >> escribió: >> >>> Hi Carlos, >>> I don't quite understand. Which version of UHD are you using? For the >>> UHD 3.15 and earlier, I thought that the typical configuration was indeed >>> host->DmaFIFO->DUC->Radio as you were hoping for. For the current master, >>> I noticed that the DmaFIFO is not included in the statically routed FPGA >>> image. But, aside from the master branch, the DmaFIFO should have 2 ports >>> such that you can connect to two DUC blocks. >>> Rob >>> >>> On Thu, May 21, 2020 at 2:34 PM Brian Padalino via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> 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 >>> ___ 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
Hi Rob, I'm using UHD-3.15.LTS and I have developed a custom DUC with N inputs and 1 output. I have done the same with the DDC (1:N) and it works fine. But with the DUC I have the problem with the DMA_FIFO, I need one DMA_FIFO channel per DUC channel. I have thought about some solutions and I would like to know which would be the best or if they are possible before I started developing: - Increase the DMA_FIFO ports: from 2 to 4. - Add another DMA_FIFO. - Use FIFO_LOOPBACK with large size. My graph is: DMA_FIFO(N:N) -> (N:1) DUC -> (1) Radio Thank you :) El jue., 21 may. 2020 a las 21:13, Rob Kossler () escribió: > Hi Carlos, > I don't quite understand. Which version of UHD are you using? For the > UHD 3.15 and earlier, I thought that the typical configuration was indeed > host->DmaFIFO->DUC->Radio as you were hoping for. For the current master, > I noticed that the DmaFIFO is not included in the statically routed FPGA > image. But, aside from the master branch, the DmaFIFO should have 2 ports > such that you can connect to two DUC blocks. > Rob > > On Thu, May 21, 2020 at 2:34 PM Brian Padalino via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> 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 >> > ___ 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
Thank you for the response Brian :) The throughput is about 11MSamples. What about to use the AXI_FIFO_LOOPBACK? El jue., 21 may. 2020 a las 20:17, Brian Padalino () escribió: > On Thu, May 21, 2020 at 1:55 PM Carlos Alberto Ruiz Naranjo via USRP-users > 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
[USRP-users] Multiple DMA_FIFO blocks
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? Could I increase the size of the AXI_FIFO_LOOPBACK block and replace it by DMA_FIFO in a configuration? Host -> DMA_FIFO -> DUC -> Radio Thank you. ___ 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
Thank you Brian! It runs fine :) El lun., 11 may. 2020 a las 17:08, Brian Padalino () escribió: > On Mon, May 11, 2020 at 6:20 AM Carlos Alberto Ruiz Naranjo via USRP-users > 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
[USRP-users] USRP X310 sample rate of 184.32 MHz
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? Thank you. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD Python API with custom FPGA image
Ok! Thank you :) El jue., 13 dic. 2018 a las 20:26, Marcus D. Leech () escribió: > On 12/13/2018 02:24 PM, Carlos Alberto Ruiz Naranjo wrote: > > My problem is that I use the USRPX310 with: default blocks + 1 custom > > rfnoc blocks. > > > > And I am sharing the USRP with a co-worker who uses the python API > > with defautl blocks. > > > > Could we share the same custom FPGA image? > > > > Thank you. > > > > > Yes, I think this should work -- the multi_usrp abstraction will only > use the "default" blocks, and will likely safely ignore any blocks >that it doesn't "care" about. > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD Python API with custom FPGA image
My problem is that I use the USRPX310 with: default blocks + 1 custom rfnoc blocks. And I am sharing the USRP with a co-worker who uses the python API with defautl blocks. Could we share the same custom FPGA image? Thank you. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD Python API with custom FPGA image
Thanks for the reply. If I add a rfnoc block but keep the others, could I use UHD python API? El jue., 13 dic. 2018 a las 19:37, Marcus D. Leech via USRP-users (< usrp-users@lists.ettus.com>) escribió: > On 12/13/2018 01:21 PM, Carlos Alberto Ruiz Naranjo via USRP-users wrote: > > Hello, > > > > it is posible use UHD python API with a custom USRP X310 image? > > > > Thank you. > > > It very much depends on what type of customization you do. > > Obviously, if you remove functionality that UHD expects to be there, UHD > won't work. > > If you add functionality that you want to be accessible to UHD, you'll > have to modify the host-side UHD libraries to >"understand" said functionality. > > The usual way people do "custom" things with X310 is using RFNoC: > > https://kb.ettus.com/Getting_Started_with_RFNoC_Development > > > > > ___ > 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] UHD Python API with custom FPGA image
Hello, it is posible use UHD python API with a custom USRP X310 image? Thank you. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP1 support: "unknown" daughterboard
Thank you!!! :) El mié., 12 dic. 2018 a las 15:42, Robin Coxe () escribió: > You may have multiple versions of GNU Radio and/or UHD libraries still > installed on your PC. Try navigating to the wherever you installed them > (e.g., /usr/local/lib) and deleting the ones you don’t want by hand. > > > > Robin Coxe | Chief R Program Manager, SDR | Santa Clara, CA | > 408.610.6363 > > -- > *From:* USRP-users on behalf of > Carlos Alberto Ruiz Naranjo via USRP-users > *Sent:* Wednesday, December 12, 2018 4:17 AM > *To:* patchvonbr...@gmail.com > *Cc:* USRP-users@lists.ettus.com > *Subject:* Re: [USRP-users] USRP1 support: "unknown" daughterboard > > Hi Marcus, > > I have changed the version to UHD-3.9.LTS. With *uhd_usrp_probe > --args="type=usrp1" *I haven't erros. But I don't know why the GNURadio > version hasn't changed... I have, with the previous errors : > > *GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-* > *geec24d7b* > > Any idea? > > Thank you. > > El mar., 11 dic. 2018 a las 22:42, Marcus D. Leech via USRP-users (< > usrp-users@lists.ettus.com>) escribió: > >> On 12/11/2018 04:36 PM, Carlos Alberto Ruiz Naranjo via USRP-users wrote: >> > Hello, >> > >> > I have found a USRP1 and I am playing with it. I have this error: >> > >> > carlos@carlos-pc:~$ sudo uhd_usrp_probe --args="type=usrp1" >> > [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; >> > UHD_4.0.0.rfnoc-devel-702-geec24d7b >> > [INFO] [USRP1] Opening a USRP1 device... >> > [INFO] [USRP1] Using FPGA clock rate of 64.00MHz... >> > [ERROR] [DBMGR] The daughterboard manager encountered a recoverable >> > error in init. >> > Loading the "unknown" daughterboard implementations to continue. >> > The daughterboard cannot operate until this error is resolved. >> > AssertionError: m and ref_clock/m >= 1e6 and ref_clock/m <= 2.5e6 >> > in double dbsrx::set_lo_freq(double) >> > at /home/carlos/rfnoc/uhd/host/lib/usrp/dboard/db_dbsrx.cpp:305 >> > >> > _ >> > / >> > | Device: USRP1 Device >> > | _ >> > |/ >> > | | Mboard: USRP1 >> > | | serial: 479b9db3 >> > | | >> > | | Time sources: none >> > | | Clock sources: internal >> > | | Sensors: >> > | | _ >> > | |/ >> > | | | RX DSP: 0 >> > | | | >> > | | | Freq range: -32.000 to 32.000 MHz >> > | | _ >> > | |/ >> > | | | RX DSP: 1 >> > | | | >> > | | | Freq range: -32.000 to 32.000 MHz >> > | | _ >> > | |/ >> > | | | RX Dboard: A >> > | | | ID: DBSRX (0x0002) >> > | | | _ >> > | | |/ >> > | | | | RX Frontend: 0 >> > | | | | Name: Unknown (0x) - 0 >> > | | | | Antennas: >> > | | | | Sensors: >> > | | | | Freq range: 0.000 to 0.000 MHz >> > | | | | Gain Elements: None >> > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz >> > | | | | Connection Type: IQ >> > | | | | Uses LO offset: No >> > | | | _ >> > | | |/ >> > | | | | RX Codec: A >> > | | | | Name: ad9522 >> > | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB >> > | | _ >> > | |/ >> > | | | RX Dboard: B >> > | | | _ >> > | | |/ >> > | | | | RX Frontend: 0 >> > | | | | Name: Unknown (0x) - 0 >> > | | | | Antennas: >> > | | | | Sensors: >> > | | | | Freq range: 0.000 to 0.000 MHz >> > | | | | Gain Elements: None >> > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz >> > | | | | Connection Type: IQ >> > | | | | Uses LO offset: No >> > | | | ___
Re: [USRP-users] USRP1 support: "unknown" daughterboard
Hi Marcus, I have changed the version to UHD-3.9.LTS. With *uhd_usrp_probe --args="type=usrp1" *I haven't erros. But I don't know why the GNURadio version hasn't changed... I have, with the previous errors : * GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-* *geec24d7b* Any idea? Thank you. El mar., 11 dic. 2018 a las 22:42, Marcus D. Leech via USRP-users (< usrp-users@lists.ettus.com>) escribió: > On 12/11/2018 04:36 PM, Carlos Alberto Ruiz Naranjo via USRP-users wrote: > > Hello, > > > > I have found a USRP1 and I am playing with it. I have this error: > > > > carlos@carlos-pc:~$ sudo uhd_usrp_probe --args="type=usrp1" > > [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; > > UHD_4.0.0.rfnoc-devel-702-geec24d7b > > [INFO] [USRP1] Opening a USRP1 device... > > [INFO] [USRP1] Using FPGA clock rate of 64.00MHz... > > [ERROR] [DBMGR] The daughterboard manager encountered a recoverable > > error in init. > > Loading the "unknown" daughterboard implementations to continue. > > The daughterboard cannot operate until this error is resolved. > > AssertionError: m and ref_clock/m >= 1e6 and ref_clock/m <= 2.5e6 > > in double dbsrx::set_lo_freq(double) > > at /home/carlos/rfnoc/uhd/host/lib/usrp/dboard/db_dbsrx.cpp:305 > > > > _ > > / > > | Device: USRP1 Device > > | _ > > |/ > > | | Mboard: USRP1 > > | | serial: 479b9db3 > > | | > > | | Time sources: none > > | | Clock sources: internal > > | | Sensors: > > | | _ > > | |/ > > | | | RX DSP: 0 > > | | | > > | | | Freq range: -32.000 to 32.000 MHz > > | | _ > > | |/ > > | | | RX DSP: 1 > > | | | > > | | | Freq range: -32.000 to 32.000 MHz > > | | _ > > | |/ > > | | | RX Dboard: A > > | | | ID: DBSRX (0x0002) > > | | | _ > > | | |/ > > | | | | RX Frontend: 0 > > | | | | Name: Unknown (0x) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz > > | | | | Connection Type: IQ > > | | | | Uses LO offset: No > > | | | _ > > | | |/ > > | | | | RX Codec: A > > | | | | Name: ad9522 > > | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB > > | | _ > > | |/ > > | | | RX Dboard: B > > | | | _ > > | | |/ > > | | | | RX Frontend: 0 > > | | | | Name: Unknown (0x) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz > > | | | | Connection Type: IQ > > | | | | Uses LO offset: No > > | | | _ > > | | |/ > > | | | | RX Codec: B > > | | | | Name: ad9522 > > | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB > > | | _ > > | |/ > > | | | TX DSP: 0 > > | | | > > | | | Freq range: -44.000 to 44.000 MHz > > | | _ > > | |/ > > | | | TX DSP: 1 > > | | | > > | | | Freq range: -44.000 to 44.000 MHz > > | | _ > > | |/ > > | | | TX Dboard: A > > | | | _ > > | | |/ > > | | | | TX Frontend: 0 > > | | | | Name: Unknown (0x) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > &g
[USRP-users] USRP1 support: "unknown" daughterboard
Hello, I have found a USRP1 and I am playing with it. I have this error: carlos@carlos-pc:~$ sudo uhd_usrp_probe --args="type=usrp1" [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-geec24d7b [INFO] [USRP1] Opening a USRP1 device... [INFO] [USRP1] Using FPGA clock rate of 64.00MHz... [ERROR] [DBMGR] The daughterboard manager encountered a recoverable error in init. Loading the "unknown" daughterboard implementations to continue. The daughterboard cannot operate until this error is resolved. AssertionError: m and ref_clock/m >= 1e6 and ref_clock/m <= 2.5e6 in double dbsrx::set_lo_freq(double) at /home/carlos/rfnoc/uhd/host/lib/usrp/dboard/db_dbsrx.cpp:305 _ / | Device: USRP1 Device | _ |/ | | Mboard: USRP1 | | serial: 479b9db3 | | | | Time sources: none | | Clock sources: internal | | Sensors: | | _ | |/ | | | RX DSP: 0 | | | | | | Freq range: -32.000 to 32.000 MHz | | _ | |/ | | | RX DSP: 1 | | | | | | Freq range: -32.000 to 32.000 MHz | | _ | |/ | | | RX Dboard: A | | | ID: DBSRX (0x0002) | | | _ | | |/ | | | | RX Frontend: 0 | | | | Name: Unknown (0x) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ad9522 | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | RX Dboard: B | | | _ | | |/ | | | | RX Frontend: 0 | | | | Name: Unknown (0x) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: B | | | | Name: ad9522 | | | | Gain range pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | TX DSP: 0 | | | | | | Freq range: -44.000 to 44.000 MHz | | _ | |/ | | | TX DSP: 1 | | | | | | Freq range: -44.000 to 44.000 MHz | | _ | |/ | | | TX Dboard: A | | | _ | | |/ | | | | TX Frontend: 0 | | | | Name: Unknown (0x) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: A | | | | Name: ad9522 | | | | Gain range pga: -20.0 to 0.0 step 0.1 dB | | _ | |/ | | | TX Dboard: B | | | _ | | |/ | | | | TX Frontend: 0 | | | | Name: Unknown (0x) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: B | | | | Name: ad9522 | | | | Gain range pga: -20.0 to 0.0 step 0.1 dB And the same in GNURadio: Executing: /usr/bin/python2 -u /home/carlos/top_block.py [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-geec24d7b [32;1m[INFO] [USRP1] [39;0mOpening a USRP1 device... [32;1m[INFO] [USRP1] [39;0mUsing FPGA clock rate of 64.00MHz... [31;0m[ERROR] [DBMGR] [39;0mThe daughterboard manager encountered a recoverable error in init. Loading the "unknown"
Re: [USRP-users] rfnoc problem with custom DDC inputs.
Hi Brian,
I have finished the DDC block 1:8 and it works perfectly!! :) :)
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)) :/
Thank you :)
El lun., 3 dic. 2018 a las 17:38, Carlos Alberto Ruiz Naranjo (<
carlosruiznara...@gmail.com>) escribió:
> Ok, I had a problem with *radio_block_port. *I had a signed number... :(
>
> I think now it runs. I will pass to 1:8 DCC and later with 2:16 DDC. I
> continue... :)
>
> El lun., 3 dic. 2018 a las 16:09, Carlos Alberto Ruiz Naranjo (<
> carlosruiznara...@gmail.com>) escribió:
>
>> Hello Brian,
>>
>> thanks for your answer! I have returned today and I am testing your
>> changes.
>>
>> I am using grc and I have the error:
>>
>> *thread[thread-per-block[0]: ]: LookupError:
>> KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*
>>
>> I assume the error is in the configuration of uhd::device_addr_t. Can you
>> explain how it works? I have not understood it well, I'm sorry :( :(
>>
>> I am configuring it with grc python block:
>>
>> *self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
>> ",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*
>>
>> I have never tried to change the settings.
>>
>> Thank you in advance!!! :)
>>
>> El vie., 30 nov. 2018 a las 16:58, Brian Padalino ()
>> escribió:
>>
>>> 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 (<
> bpadal...@gmail.com>) 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
Re: [USRP-users] rfnoc problem with custom DDC inputs.
Ok, I had a problem with *radio_block_port. *I had a signed number... :(
I think now it runs. I will pass to 1:8 DCC and later with 2:16 DDC. I
continue... :)
El lun., 3 dic. 2018 a las 16:09, Carlos Alberto Ruiz Naranjo (<
carlosruiznara...@gmail.com>) escribió:
> Hello Brian,
>
> thanks for your answer! I have returned today and I am testing your
> changes.
>
> I am using grc and I have the error:
>
> *thread[thread-per-block[0]: ]: LookupError:
> KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*
>
> I assume the error is in the configuration of uhd::device_addr_t. Can you
> explain how it works? I have not understood it well, I'm sorry :( :(
>
> I am configuring it with grc python block:
>
> *self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
> ",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*
>
> I have never tried to change the settings.
>
> Thank you in advance!!! :)
>
> El vie., 30 nov. 2018 a las 16:58, Brian Padalino ()
> escribió:
>
>> 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
>
>>
___
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,
thanks for your answer! I have returned today and I am testing your changes.
I am using grc and I have the error:
*thread[thread-per-block[0]: ]: LookupError:
KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*
I assume the error is in the configuration of uhd::device_addr_t. Can you
explain how it works? I have not understood it well, I'm sorry :( :(
I am configuring it with grc python block:
*self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*
I have never tried to change the settings.
Thank you in advance!!! :)
El vie., 30 nov. 2018 a las 16:58, Brian Padalino ()
escribió:
> 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
>
___
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 : 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] rfnoc problem with custom DDC inputs.
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] rfnoc problem with custom DDC inputs.
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] When I run DDC rfnoc test with this changes fails. This is the rfnoc DDC modified code. https://pastebin.com/txTXCMyc Thank you!! :) :) El lun., 26 nov. 2018 a las 19:36, Brian Padalino () escribió: > 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
[USRP-users] rfnoc problem with custom DDC inputs.
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?
I have tried a custom split_stream with 1 normal output and 3 outputs with
the null_source module to not consume bandwidth. But I have the error:.
* File "/home/cruiz/repositorios/gr-ettus/examples/rfnoc/rfnoc_siggen.py",
line 68, in __init__self.device3 = variable_uhd_device3_0 =
ettus.device3(uhd.device_addr_t( ",".join(('type=x300', "")) )) File
"/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line 1617, in
makereturn _ettus_swig.device3_make(device_addr)RuntimeError:
EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse error -
EnvironmentError: IOError: Expected SID: 02:30>00:00 Received SID:
00:00>00:00*
This is the code: https://pastebin.com/4SrjXN9G
Thank you!!!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] noc_block_null_source_sink module
Hey Jon, Is it possible to connect this block to an RFNoC port and not use it? Use others. 2018-07-31 4:49 GMT+02:00 Jon Pendlum via USRP-users < usrp-users@lists.ettus.com>: > Hey Jason, > > The block is functionally complete, in fact I think it was the first > block ever made. There is a UHD C++ example, > rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC > xml for GNU Radio needs to be created though. > > Jonathon > > On Wed, Jul 18, 2018 at 4:38 AM, Jason Matusiak via USRP-users > wrote: > > I was having trouble finding information on this block. I could see its > > usefulness in an application I am looking into, but I wasn't sure how > > complete the block was (I don't really see anything using it, nor a GRC > xml > > file for it). > > > > Thanks > > > > ___ > > 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] RFNoC: null source
Hello, how can I connect in RFNoC a port to a null source in GNURadio? Thank you. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Error with multiple block output ports
I have the same problem, any help? ^^ 2017-06-06 13:45 GMT+02:00 Barker, Douglas W. via USRP-users < usrp-users@lists.ettus.com>: > Hello, > > > > Is there any update on our issue? > > > > Thanks > > Doug > > > > *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com] > *Sent:* Monday, May 29, 2017 2:16 AM > *To:* Barker, Douglas W. > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Error with multiple block output ports > > > > Try fixing these issues, especially the first one, and see if that helps: > > > > - In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels > instead of 3. > > - In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is set > to have only two active outputs. > > > > On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W. < > douglas.bar...@jhuapl.edu> wrote: > > Jonathon, > > > > I’ve attached the XML files that I was using. > > > > > > Thanks! > > Doug > > > > *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com] > *Sent:* Thursday, May 25, 2017 3:46 PM > *To:* Barker, Douglas W. > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Error with multiple block output ports > > > > Hi Doug, > > > > Can you share your Noc Script XML file? > > > > > > > > Jonathon > > > > On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Hello, > > > > I’m starting a new thread for this problem. I get an error when trying to > use more than 2 output ports on a RFNoC block. I’ve designed a CE that has > 9 output ports and when starting the gnuradio flowgraph it errors out. > When I reduce the ports to 2 it works. If I increase the ports to 3 it > errors out. > > > > I then made a simple modification to the ‘noc_block_split_stream’ block > that is provided to have three output ports (also modified the associated > XML files). It error out as well, in the same way. This test has > Radio->DDC-SplitStream->host. Below are the messages produced by gnuradio > when starting. Can the folks at Ettus please take a look as it appears to > be a bug in UHD. I’ve attached the modified ‘noc_block_split_stream.v’ > file so you can easily reproduce the error. > > > > Thanks > > Doug > > > > > > Generating: '/home/dm/Documents/doug_rfnoc/top_block.py' > > > > Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py > > > > [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; > Boost_106300; UHD_4.0.0.rfnoc-devel-316-g24b98579 > > [32;1m[INFO] [X300] [39;0mX300 initialization sequence... > > [32;1m[INFO] [X300] [39;0mDetermining maximum frame size... > > [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes. > > [32;1m[INFO] [X300] [39;0mSetup basic communication... > > [32;1m[INFO] [X300] [39;0mLoading values from EEPROM... > > [32;1m[INFO] [X300] [39;0mSetup RF frontend clocking... > > [32;1m[INFO] [X300] [39;0mRadio 1x clock:200 > > [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0... > > [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s) > > [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1... > > [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s) > > [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed > > [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed > > [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed > > [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed > > [33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer > sizes, but 1 input ports > > [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test... > > [32;1m[INFO] [CORES] [39;0mTimer loopback test passed > > [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test... > > [32;1m[INFO] [CORES] [39;0mTimer loopback test passed > > DEBUG: output item size: 8 > > [33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain for > this daughterboard. > > INFO: Setting args on 0/DDC_0 (input_rate=2,output_ > rate=100,fullscale=1.0,freq=100.0) > > DEBUG: output item size: 8 > > INFO: Setting args on 0/SplitStream_0 (gr_vlen=1) > > DEBUG: output item size: 8 > > [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0 > > [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0 > > DEBUG: check_topology() > > DEBUG: RFNoC blocks with streaming ports: 1 > > DEBUG: start(): ninputs == 0 noutputs == 3 > > DEBUG: creating rx streamer with: gr_vlen=1,block_id=0/ > SplitStream_0,block_port0=0,block_port1=1,block_port=0 > > DEBUG: creating rx streamer with: gr_vlen=1,block_id=0/ > SplitStream_0,block_port0=0,block_port1=1,block_port=1 > > DEBUG: creating rx streamer with: gr_vlen=1,block_id=0/ > SplitStream_0,block_port0=0,block_port1=1,block_port=2 > > thread[thread-per-block[0]: ]: > LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2 > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com >
[USRP-users] Template error: fosphor_display
Hi!
I have an error with fosphor_display:
Generating: '/home/cruiz/repositorios/sample_rfnoc.py'
Executing: /usr/bin/python -u /home/cruiz/repositorios/sample_rfnoc.py
File "/home/cruiz/repositorios/sample_rfnoc.py", line 147
self.uhd_rfnoc_fosphor_display = Template error: #set $win =
'self._%s_win'%$id
^
SyntaxError: invalid syntax
>>> Done (return code 1)
My UHD version:
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_4.0.0.rfnoc-devel-788-g1f8463cc
I have attached my grc.
Thank you.
sample_rfnoc.grc
Description: application/gnuradio-grc
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Sample Rfnoc
# Generated: Fri Jun 22 10:56:04 2018
##
from distutils.version import StrictVersion
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"
from PyQt4 import Qt
from PyQt5 import Qt, QtCore
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import ettus
import sip
import sys
from gnuradio import qtgui
class sample_rfnoc(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "Sample Rfnoc")
Qt.QWidget.__init__(self)
self.setWindowTitle("Sample Rfnoc")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)
self.settings = Qt.QSettings("GNU Radio", "sample_rfnoc")
if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
self.restoreGeometry(self.settings.value("geometry").toByteArray())
else:
self.restoreGeometry(self.settings.value("geometry", type=QtCore.QByteArray))
##
# Variables
##
self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t( ",".join(('type=x300', "")) ))
self.trise = trise = 1024
self.tdecay = tdecay = 4096
self.samp_rate = samp_rate = 56e6
self.gain = gain = 32
self.freq = freq = 2.45e9
self.fft_size = fft_size = 1024
##
# Blocks
##
self.uhd_rfnoc_streamer_window_0 = ettus.rfnoc_window_cci(
([int(round(32767 * x)) for x in fft.window_blackman_harris(fft_size)]),
self.device3,
-1, -1
)
self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="", # empty
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args='spp=1024',
),
0, -1
)
self.uhd_rfnoc_streamer_radio_0.set_rate(samp_rate)
for i in xrange(1):
self.uhd_rfnoc_streamer_radio_0.set_rx_freq(freq, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_gain(gain, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_dc_offset(False, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_bandwidth(56e6, 0)
self.uhd_rfnoc_streamer_radio_0.set_rx_antenna("RX1", 0)
self.uhd_rfnoc_streamer_radio_0.set_clock_source("internal")
self.uhd_rfnoc_streamer_fosphor_0 = ettus.rfnoc_fosphor_c(
fft_size,
self.device3,
-1,
-1,
)
self.uhd_rfnoc_streamer_fosphor_0.set_arg("enable", 3 if (0 >= 0) else 1)
self.uhd_rfnoc_streamer_fosphor_0.set_arg("decim", max(2, int(samp_rate / (15 * 64 * fft_size
self.uhd_rfnoc_streamer_fosphor_0.set_arg("offset", 0)
self.uhd_rfnoc_streamer_fosphor_0.set_arg("scale", 256)
