[USRP-users] usrp x300 multiple addresses and multiple streamers
Hi All, I'm using a USRP x300 configured with two WBX-120 daughterboards and the XG firmware version from the UHD 3.13. The link with the host pc is done with two 10GBe connections. In my C++ application I have the necessity of receiving and streaming signals to both daughterboards at the same time from four different threads. To do so, I'm making the multi_usrp object using primary and secondary address and getting each tx/rx streamer (each with a single channel) inside a thread. Everything is working except that the UHD api is using only one of the two 10Gbe interfaces for communicating with the USRP, limiting the bandwidth I can use. The only way I found to make the dual 10GBe link to work is initializing a streamer object with multiple channels; thing that I would like to avoid. is there a way to tell the UHD api which address to use for each streamer? Thanks in advance. ___ 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
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.
Am Di., 19. Feb. 2019 um 14:47 Uhr schrieb Brian Padalino <
bpadal...@gmail.com>:
> 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);
>>
Re: [USRP-users] E310 RFNoC FFT Overrun Issue
Ramazan, As Sylvain said, RFNoC Fosphor is another great choice. There already exists flowgraphs in gr-ettus/examples/rfnoc for the E310 as well (see rfnoc_fosphor_network_host.grc and rfnoc_fosphor_network_usrp.grc). Jonathon On Wed, Feb 20, 2019 at 12:22 AM Sylvain Munaut <246...@gmail.com> wrote: > Just throwing it out there, but have you looked at rfnoc-fosphor ? > > I mean capturing and processing large bandwidth spectrum and > decimating it to low bandwidth data is kind of exactly what it does. > > Cheers, > > Sylvain > > On Tue, Feb 19, 2019 at 4:19 PM Jonathon Pendlum via USRP-users > wrote: > > > > Hi Ramazan, > > > > The VectorIIR RFNoC block implements a vector of low pass single-pole > IIR filters. The idea is that the spectral content of each FFT bin in the > time direction is low frequency enough that you can low pass filter > (VectorIIR) and decimate (Keep one in N) without significant loss of > information. > > > > Jonathon > > > > On Tue, Feb 19, 2019 at 11:30 PM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > >> > >> Ramazan, > >> > >> The timeout channel 0 error is using a timeout that RFNoC is throwing. > There is a timeout built in that can be ignored if you are purposely > dropping a bunch of samples in the RFNoC domain (which I do in a few > flowgraphs). If you dig through the mailing list, someone pointed to where > in the code this gets printed; they comment it out so they don't have to > see it. It is pretty annoying to me when I am trying to drop samples on > purpose, but I haven't commented it out since I want to see it if I wasn't > trying to drop samples. My money is on your keep-1-in-n tripping this up. > >> > >> > >> > >> > >> > >> > >> From: USRP-users on behalf of > Ramazan Çetin via USRP-users > >> Sent: Tuesday, February 19, 2019 7:11 AM > >> To: Jonathon Pendlum; usrp-users@lists.ettus.com > >> Subject: Re: [USRP-users] E310 RFNoC FFT Overrun Issue > >> > >> > >> Hi Jonathon, > >> > >> Thanks you for your suggestions. I have achieved getting 60 MHz > spectrum samples to file on ARM processor using; > >> > >> RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N > -> File Sink > >> > >> It just getting overflows after 4-5 seconds such as "overrun on chan > 0". Is this because of RFNoC side or processor side ? > >> > >> Also, Keep 1 in B block works as using packets not samples this is also > perfect for me. I will not lose FFT bins. > >> > >> But i can not much understand Vector IIR part. Why is it used and good > for FFT outputs? Is it for averaging results ? > >> > >> Thank you for your time. Best regards. > >> > >> Ramazan > >> > >> On 11.02.2019 08:09, Jonathon Pendlum wrote: > >> > >> Hi Ramazan, > >> > >> I would suggest first testing with a signal generated with GNU Radio. > For example, use a Fast Noise Source + Low Pass Filter to crudely simulate > receiving a wide band signal. See what it looks like without running it > through RFNoC. Then replace the RFNoC radio block with those blocks and > look at the result. > >> > >> You should also consider using the ZeroMQ blocks to forward data over > Ethernet to a host PC to view your data in real time. Look at the gr-ettus > example flowgraphs rfnoc_fft_network_usrp (runs on E310) and > rfnoc_fft_network_host (runs on host PC). > >> > >> One guess I can make is try increasing the FFT RFNoC block gain. By > default, it is set to a very conservative value, so try changing it to 21. > That gain value sets the Xilinx's FFT IP core scaling schedule, which you > can read about here: > https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf > (see SCALE_SCH on page 15, the core uses Radix-4). You can also try > adjusting it with a slider in real time. Note that it may behave a bit odd > as it is not a linear mapping due to the scaling schedule format. > >> > >> The overflows are due to either the ARM processors cannot keep up with > the processing load or the SD card write speed is too slow. Try increasing > N in Keep One in N. > >> > >> Jonathon > >> > > ___ > > 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] E310 RFNoC FFT Overrun Issue
Just throwing it out there, but have you looked at rfnoc-fosphor ? I mean capturing and processing large bandwidth spectrum and decimating it to low bandwidth data is kind of exactly what it does. Cheers, Sylvain On Tue, Feb 19, 2019 at 4:19 PM Jonathon Pendlum via USRP-users wrote: > > Hi Ramazan, > > The VectorIIR RFNoC block implements a vector of low pass single-pole IIR > filters. The idea is that the spectral content of each FFT bin in the time > direction is low frequency enough that you can low pass filter (VectorIIR) > and decimate (Keep one in N) without significant loss of information. > > Jonathon > > On Tue, Feb 19, 2019 at 11:30 PM Jason Matusiak > wrote: >> >> Ramazan, >> >> The timeout channel 0 error is using a timeout that RFNoC is throwing. >> There is a timeout built in that can be ignored if you are purposely >> dropping a bunch of samples in the RFNoC domain (which I do in a few >> flowgraphs). If you dig through the mailing list, someone pointed to where >> in the code this gets printed; they comment it out so they don't have to see >> it. It is pretty annoying to me when I am trying to drop samples on >> purpose, but I haven't commented it out since I want to see it if I wasn't >> trying to drop samples. My money is on your keep-1-in-n tripping this up. >> >> >> >> >> >> >> From: USRP-users on behalf of Ramazan >> Çetin via USRP-users >> Sent: Tuesday, February 19, 2019 7:11 AM >> To: Jonathon Pendlum; usrp-users@lists.ettus.com >> Subject: Re: [USRP-users] E310 RFNoC FFT Overrun Issue >> >> >> Hi Jonathon, >> >> Thanks you for your suggestions. I have achieved getting 60 MHz spectrum >> samples to file on ARM processor using; >> >> RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N -> >> File Sink >> >> It just getting overflows after 4-5 seconds such as "overrun on chan 0". Is >> this because of RFNoC side or processor side ? >> >> Also, Keep 1 in B block works as using packets not samples this is also >> perfect for me. I will not lose FFT bins. >> >> But i can not much understand Vector IIR part. Why is it used and good for >> FFT outputs? Is it for averaging results ? >> >> Thank you for your time. Best regards. >> >> Ramazan >> >> On 11.02.2019 08:09, Jonathon Pendlum wrote: >> >> Hi Ramazan, >> >> I would suggest first testing with a signal generated with GNU Radio. For >> example, use a Fast Noise Source + Low Pass Filter to crudely simulate >> receiving a wide band signal. See what it looks like without running it >> through RFNoC. Then replace the RFNoC radio block with those blocks and look >> at the result. >> >> You should also consider using the ZeroMQ blocks to forward data over >> Ethernet to a host PC to view your data in real time. Look at the gr-ettus >> example flowgraphs rfnoc_fft_network_usrp (runs on E310) and >> rfnoc_fft_network_host (runs on host PC). >> >> One guess I can make is try increasing the FFT RFNoC block gain. By default, >> it is set to a very conservative value, so try changing it to 21. That gain >> value sets the Xilinx's FFT IP core scaling schedule, which you can read >> about here: >> https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf >> (see SCALE_SCH on page 15, the core uses Radix-4). You can also try >> adjusting it with a slider in real time. Note that it may behave a bit odd >> as it is not a linear mapping due to the scaling schedule format. >> >> The overflows are due to either the ARM processors cannot keep up with the >> processing load or the SD card write speed is too slow. Try increasing N in >> Keep One in N. >> >> Jonathon >> > ___ > 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] E310 RFNoC FFT Overrun Issue
Hi Ramazan, The VectorIIR RFNoC block implements a vector of low pass single-pole IIR filters. The idea is that the spectral content of each FFT bin in the time direction is low frequency enough that you can low pass filter (VectorIIR) and decimate (Keep one in N) without significant loss of information. Jonathon On Tue, Feb 19, 2019 at 11:30 PM Jason Matusiak < ja...@gardettoengineering.com> wrote: > Ramazan, > > The timeout channel 0 error is using a timeout that RFNoC is throwing. > There is a timeout built in that can be ignored if you are purposely > dropping a bunch of samples in the RFNoC domain (which I do in a few > flowgraphs). If you dig through the mailing list, someone pointed to where > in the code this gets printed; they comment it out so they don't have to > see it. It is pretty annoying to me when I am trying to drop samples on > purpose, but I haven't commented it out since I want to see it if I wasn't > trying to drop samples. My money is on your keep-1-in-n tripping this up. > > > > > > -- > *From:* USRP-users on behalf of > Ramazan Çetin via USRP-users > *Sent:* Tuesday, February 19, 2019 7:11 AM > *To:* Jonathon Pendlum; usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] E310 RFNoC FFT Overrun Issue > > > Hi Jonathon, > > Thanks you for your suggestions. I have achieved getting 60 MHz spectrum > samples to file on ARM processor using; > > RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N -> > File Sink > > It just getting overflows after 4-5 seconds such as "*overrun on chan 0*". > Is this because of *RFNoC* side or *processor* side ? > > Also, Keep 1 in B block works as using packets not samples this is also > perfect for me. I will not lose FFT bins. > > But i can not much understand Vector IIR part. Why is it used and good for > FFT outputs? Is it for averaging results ? > > Thank you for your time. Best regards. > > Ramazan > On 11.02.2019 08:09, Jonathon Pendlum wrote: > > Hi Ramazan, > > I would suggest first testing with a signal generated with GNU Radio. For > example, use a Fast Noise Source + Low Pass Filter to crudely simulate > receiving a wide band signal. See what it looks like without running it > through RFNoC. Then replace the RFNoC radio block with those blocks and > look at the result. > > You should also consider using the ZeroMQ blocks to forward data over > Ethernet to a host PC to view your data in real time. Look at the gr-ettus > example flowgraphs rfnoc_fft_network_usrp (runs on E310) and > rfnoc_fft_network_host (runs on host PC). > > One guess I can make is try increasing the FFT RFNoC block gain. By > default, it is set to a very conservative value, so try changing it to 21. > That gain value sets the Xilinx's FFT IP core scaling schedule, which you > can read about here: > https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf > (see SCALE_SCH on page 15, the core uses Radix-4). You can also try > adjusting it with a slider in real time. Note that it may behave a bit odd > as it is not a linear mapping due to the scaling schedule format. > > The overflows are due to either the ARM processors cannot keep up with the > processing load or the SD card write speed is too slow. Try increasing N in > Keep One in N. > > Jonathon > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E310 RFNoC FFT Overrun Issue
Ramazan, The timeout channel 0 error is using a timeout that RFNoC is throwing. There is a timeout built in that can be ignored if you are purposely dropping a bunch of samples in the RFNoC domain (which I do in a few flowgraphs). If you dig through the mailing list, someone pointed to where in the code this gets printed; they comment it out so they don't have to see it. It is pretty annoying to me when I am trying to drop samples on purpose, but I haven't commented it out since I want to see it if I wasn't trying to drop samples. My money is on your keep-1-in-n tripping this up. From: USRP-users on behalf of Ramazan Çetin via USRP-users Sent: Tuesday, February 19, 2019 7:11 AM To: Jonathon Pendlum; usrp-users@lists.ettus.com Subject: Re: [USRP-users] E310 RFNoC FFT Overrun Issue Hi Jonathon, Thanks you for your suggestions. I have achieved getting 60 MHz spectrum samples to file on ARM processor using; RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N -> File Sink It just getting overflows after 4-5 seconds such as "overrun on chan 0". Is this because of RFNoC side or processor side ? Also, Keep 1 in B block works as using packets not samples this is also perfect for me. I will not lose FFT bins. But i can not much understand Vector IIR part. Why is it used and good for FFT outputs? Is it for averaging results ? Thank you for your time. Best regards. Ramazan On 11.02.2019 08:09, Jonathon Pendlum wrote: Hi Ramazan, I would suggest first testing with a signal generated with GNU Radio. For example, use a Fast Noise Source + Low Pass Filter to crudely simulate receiving a wide band signal. See what it looks like without running it through RFNoC. Then replace the RFNoC radio block with those blocks and look at the result. You should also consider using the ZeroMQ blocks to forward data over Ethernet to a host PC to view your data in real time. Look at the gr-ettus example flowgraphs rfnoc_fft_network_usrp (runs on E310) and rfnoc_fft_network_host (runs on host PC). One guess I can make is try increasing the FFT RFNoC block gain. By default, it is set to a very conservative value, so try changing it to 21. That gain value sets the Xilinx's FFT IP core scaling schedule, which you can read about here: https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf (see SCALE_SCH on page 15, the core uses Radix-4). You can also try adjusting it with a slider in real time. Note that it may behave a bit odd as it is not a linear mapping due to the scaling schedule format. The overflows are due to either the ARM processors cannot keep up with the processing load or the SD card write speed is too slow. Try increasing N in Keep One in N. Jonathon ___ 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] Internal reference signal USRP X-series
Hi Marcus, Thank you very much for your answer! I need to synchronise the following devices: - 4 USRPs N-200 - 1 USRP X-310 So I thought of using the internal reference and PPS signal from the X-310 as the input of the Octoclock (not the G) to be able to synchronise everything for a MIMO set-up and other purposes. Do you think it is a good approach? Best regards, Maria Jesus On 19/02/2019 12:32, Marcus D. Leech via USRP-users wrote: On 02/19/2019 06:08 AM, Maria Jesus Cañavate Sanchez via USRP-users wrote: Hi there! I wanted to ask if the USRP X-310 includes an oscillator to create an internal 10MHz reference and 1 PPS signal, even if they are not that accurate, or if the only way to provide these internal signals is by adding the "Board Mounted GPSDO (OCXO)". Yes, the X-310 includes internal oscillators that are actually good enough for a lot of applications. Another thing I wanted to ask is if the Octoclock-G includes a GPS antenna in the same kit or if that must be bought separately to be able to lock it to the GPS signal. Thank you very much in advance! I don't think it includes a GPS antenna, but it is compatible with most active GPS antennae out there. There are dozens and dozens from which to choose in the market, readily available on Amazon and the like. Best regards, Maria Jesus ___ 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] Internal reference signal USRP X-series
On 02/19/2019 06:08 AM, Maria Jesus Cañavate Sanchez via USRP-users wrote: Hi there! I wanted to ask if the USRP X-310 includes an oscillator to create an internal 10MHz reference and 1 PPS signal, even if they are not that accurate, or if the only way to provide these internal signals is by adding the "Board Mounted GPSDO (OCXO)". Yes, the X-310 includes internal oscillators that are actually good enough for a lot of applications. Another thing I wanted to ask is if the Octoclock-G includes a GPS antenna in the same kit or if that must be bought separately to be able to lock it to the GPS signal. Thank you very much in advance! I don't think it includes a GPS antenna, but it is compatible with most active GPS antennae out there. There are dozens and dozens from which to choose in the market, readily available on Amazon and the like. Best regards, Maria Jesus ___ 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] E310 RFNoC FFT Overrun Issue
Hi Jonathon, Thanks you for your suggestions. I have achieved getting 60 MHz spectrum samples to file on ARM processor using; RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N -> File Sink It just getting overflows after 4-5 seconds such as "*overrun on chan 0*". Is this because of *RFNoC* side or *processor* side ? Also, Keep 1 in B block works as using packets not samples this is also perfect for me. I will not lose FFT bins. But i can not much understand Vector IIR part. Why is it used and good for FFT outputs? Is it for averaging results ? Thank you for your time. Best regards. Ramazan On 11.02.2019 08:09, Jonathon Pendlum wrote: Hi Ramazan, I would suggest first testing with a signal generated with GNU Radio. For example, use a Fast Noise Source + Low Pass Filter to crudely simulate receiving a wide band signal. See what it looks like without running it through RFNoC. Then replace the RFNoC radio block with those blocks and look at the result. You should also consider using the ZeroMQ blocks to forward data over Ethernet to a host PC to view your data in real time. Look at the gr-ettus example flowgraphs rfnoc_fft_network_usrp (runs on E310) and rfnoc_fft_network_host (runs on host PC). One guess I can make is try increasing the FFT RFNoC block gain. By default, it is set to a very conservative value, so try changing it to 21. That gain value sets the Xilinx's FFT IP core scaling schedule, which you can read about here: https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf (see SCALE_SCH on page 15, the core uses Radix-4). You can also try adjusting it with a slider in real time. Note that it may behave a bit odd as it is not a linear mapping due to the scaling schedule format. The overflows are due to either the ARM processors cannot keep up with the processing load or the SD card write speed is too slow. Try increasing N in Keep One in N. Jonathon ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Internal reference signal USRP X-series
Hi there! I wanted to ask if the USRP X-310 includes an oscillator to create an internal 10MHz reference and 1 PPS signal, even if they are not that accurate, or if the only way to provide these internal signals is by adding the "Board Mounted GPSDO (OCXO)". Another thing I wanted to ask is if the Octoclock-G includes a GPS antenna in the same kit or if that must be bought separately to be able to lock it to the GPS signal. Thank you very much in advance! Best regards, Maria Jesus ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] USRP x310 with multi_usrp and RFNoC
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))
{
qInfo() << endl << "AGC-block does not exist on current
device!" << endl;
}
uhd::rfnoc::source_block_ctrl_base::sptr agc0_block_ctrl =
usrpDevice->get_block_ctrl(agc0_id);
agc0_block_ctrl->set_args(uhd::device_addr_t(agc_args)); //set
arguments of agc
rx_graph->connect(radio_ctrl_id, channel_Nr,
