[USRP-users] Re: Center frequency drift on USRP B-series even with Octoclock
Hi Aneesh, Thanks for your comment. I used a Intel(R) Core(TM) i7-8850H CPU for the B-series experiment (which is somewhat weaker than the "AMD Ryzen 9 3900X 12-Core Processor" I used with the X310s, but the sampling rate was only 1MHz in both cases, so it should be fine). The software is basically a (self-made) JVM-based controller that communicates over sockets with a (self-made) C++-based server that uses UHD 4.0 under the hood. The whole thing is running on CentOS/Fedora. I attached the terminal outputs in case it helps, but I don't see any overruns/underruns. As for the use case, I'm trying to use this to compare phase offsets across different receiver locations (given a fixed transmitter), so I need a constant (and ideally zero) frequency offset, otherwise the IQ vector keeps rotating back and forth as the frequencies drift apart. Best regards, Viktor On 6/3/21 8:53 PM, aneesh patel wrote: Viktor, Cool benchmark. Do you have some specifics on what's driving the b-series like host CPU specs, software, any stdout output like overruns etc.? There seems to be an issue with the external clock implementation on the b series unless that's actually how it's supposed to look (!). For the for factor, power, price, etc. I'd say the internal looks pretty good for *most things. Best of luck. Hopefully someone with experience chines in on the setup! Aneesh Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> On Thu, Jun 3, 2021 at 7:37 AM, Viktor Erdelyi wrote: Dear all, First post here. I have done some measurements with USRP B-series and X-series, and I noticed that, in the case of the B-series, the center frequency drifts even with an Octoclock 10MHz REF. (The drift is smaller than without Octoclock, though.) Is this expected? Is the X-series just so much better, or is there something else going on? Details of the experiment: * I sent a sine wave (constant I, constant Q) from one USRP to another at 5.9GHz and looked at the spectrogram of the received signal. The ideal result of such an experiment would be a straight vertical line at 0 Hz (i.e. 5.9GHz). * I added an image of the relevant spectrograms below. The left side of the figure is TX = USRP B205, RX = USRP B210, internal vs. external (Octoclock) REF. The right side of the figure is TX = USRP X310, RX = (another) USRP X310, internal vs. external (Octoclock) REF. * The two X310s have UBX-160 daughterboards. * I check for LO_locked and ref_locked before doing TX/RX. I would appreciate any insights. Thanks, Viktor ___ USRP-users mailing list -- usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com <mailto:usrp-users-le...@lists.ettus.com> === Controller output === 19:25:00.237 [main] INFO USRPNativeClient - Setting 10MHz REF source to external 19:25:00.239 [main] INFO USRPNativeClient - Setting PPS source to internal 19:25:00.240 [main] INFO main.radio.USRPMaker - Configuring USRP B205mini for TX... 19:25:00.241 [main] INFO USRPNativeClient - Setting TX subdevice to A:A 19:25:00.273 [main] INFO USRPNativeClient - Setting TX Gain to 60.0 19:25:00.316 [main] INFO USRPNativeClient - Setting TX SamplingRate to 1 MHz 19:25:00.676 [main] INFO USRPNativeClient - Setting TX Antenna to TX/RX 19:25:00.677 [main] INFO USRPNativeClient - Setting TX Bandwidth to 5.6E7 19:25:00.679 [main] INFO USRPNativeClient - Setting up TX streamer 19:25:02.622 [main] INFO USRPNativeClient - Setting 10MHz REF source to external 19:25:02.629 [main] INFO USRPNativeClient - Setting PPS source to internal 19:25:02.630 [main] INFO main.radio.USRPMaker - Configuring USRP B210_RF_A for RX... 19:25:02.630 [main] INFO USRPNativeClient - Setting RX subdevice to A:A 19:25:02.663 [main] INFO USRPNativeClient - Setting RX Gain to 76.5 19:25:02.705 [main] INFO USRPNativeClient - Setting RX SamplingRate to 1 MHz 19:25:03.157 [main] INFO USRPNativeClient - Setting RX Antenna to RX2 19:25:03.158 [main] INFO USRPNativeClient - Setting RX Bandwidth to 5.6E7 19:25:03.202 [main] INFO USRPNativeClient - Setting up RX streamer 19:25:03.270 [DefaultDispatcher-worker-2] INFO USRPNativeClient - Setting USRP time to 0.0 NOW 19:25:03.273 [DefaultDispatcher-worker-3] INFO USRPNativeClient - Setting USRP time to 0.0 NOW 19:25:03.315 [DefaultDispatcher-worker-3] INFO USRPNativeClient - Getting USRP time --> 0.002631 19:25:03.315 [DefaultDispatcher-worker-1] INFO USRPNativeClient -
[USRP-users] Re: Center frequency drift on USRP B-series even with Octoclock
You're right Marcus, 0.9GHz seems to be better indeed (see image). Also thanks for the input on the B205 PLL. May I ask in what way phase noise can affect the signal's frequency? According to an NI webpage [1], it "deals with very short time scales and produces effects that look more like unwanted modulation changing the shape of the waveform rather than a wandering frequency". Am I missing something? [1] https://www.ni.com/en-us/innovations/white-papers/20/global-synchronization-and-clock-disciplining-with-ni-usrp-293x-.html Thanks, Viktor ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: tx_samples_from_file warnings for ettus x310
In my experience, the "[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping." message appears (pretty much always?) even without optical fiber (just plain 1Gbps Ethernet or PCI-express), and even at 1Msps, when using the X310, but the application still works. Viktor On 6/8/21 3:59 AM, Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV via USRP-users wrote: Hi Marcus, Yes the "> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping." Is still there when I just tried at 2Msps, the "[WARNING] [RFNOC::GRAPH::DETAIL]" message is gone however. Not sure if that's one to be concerned about or not. Thanks for your response! Casey -Original Message- From: Marcus D Leech Sent: Monday, June 7, 2021 2:25 PM To: Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV Cc: USRP-users@lists.ettus.com Subject: Re: [USRP-users] tx_samples_from_file warnings for ettus x310 Does the error happen at lower sample Rates? I’m thinking that perhaps the tx_samples_from_file example hasn’t been properly converted to the newer RFNOC infrastructure that’s underneath. Sent from my iPhone On Jun 7, 2021, at 1:32 PM, Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV via USRP-users wrote: Hello all, While trying to confirm if the x310 (UBX-160) can work with a singlemode fiber optic 10Gbe I have been using the tx_samples_from_file and rx_samples_to_file. The rx_sample_from_file seems to go over alright writing 500ms worth of data down at 200Msps, but the Tx side gives me two warnings that I have not been able to track down in documentation or on message boards. As an aside in readout you'll see a few underflows as well - while I did most of the performance upgrades (aside from DPDK which is still pending), I'm calling samples from file from an older HDD, I'm upgrading over to an SSD in next day or two so I am banking on that mitigating that issue, hence why I'm also limited to about 500ms at a time to test PS anyone have experience using the single mode fiber optic cabling and transceiver over 10Gbe? Most of Ettus literature says they've only tested over multimode, but the longer distances allotted by using single mode make it an appealing option for my system. $ ./tx_samples_from_file --args 'addr=192.168.40.2' --file usrp_samples.dat --freq=24 --lo-offset 10 --gain 0 --rate 2 Creating the usrp device with: addr=192.168.40.2... [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107400; UHD_4.0.0.HEAD-release [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300] Radio 1x clock: 200 MHz Using Device: Single USRP: Device: X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: UBX RX RX Channel: 1 RX DSP: 1 RX Dboard: B RX Subdev: Unknown (0x) - 0 TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: UBX TX TX Channel: 1 TX DSP: 1 TX Dboard: B TX Subdev: Unknown (0x) - 0 Setting TX Rate: 200.00 Msps... Actual TX Rate: 200.00 Msps... Setting TX Freq: 2400.00 MHz... Setting TX LO Offset: 0.10 MHz... Actual TX Freq: 2400.00 MHz... Setting TX Gain: 0.00 dB... Actual TX Gain: 0.00 dB... Checking TX: TXLO: locked ... [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. UU Done! [WARNING] [RFNOC::GRAPH::DETAIL] Cannot forward action tx_event from 0/Radio#0:INPUT_EDGE:0, no neighbour found! Casey Wolsieffer Research Electrical Engineer - Signature Physics Branch Cold Regions Research & Engineering Laboratory 72 Lyme Rd, Hanover NH 03755 (603) 646-4254 (office) ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Center frequency drift on USRP B-series even with Octoclock
For the record: I got my hands on a second B210, and I can confirm that, in terms of keeping the center frequency synced, the B210+B210+Octoclock combination indeed performs much better than the B205mini+B210+Octoclock combination. Thanks for the insights! Viktor On 6/4/21 9:31 PM, Brian Padalino wrote: On Fri, Jun 4, 2021 at 2:21 AM Viktor Erdelyi mailto:vik...@ist.osaka-u.ac.jp>> wrote: You're right Marcus, 0.9GHz seems to be better indeed (see image). Also thanks for the input on the B205 PLL. May I ask in what way phase noise can affect the signal's frequency? According to an NI webpage [1], it "deals with very short time scales and produces effects that look more like unwanted modulation changing the shape of the waveform rather than a wandering frequency". Am I missing something? It should be noted the B205 doesn't really have an analog PLL like the B200/B210/X-series. Check the schematic: https://files.ettus.com/schematics/b200mini/b200mini.pdf <https://files.ettus.com/schematics/b200mini/b200mini.pdf> The VTCXO is fed by a 16-bit DAC and the FPGA does some counting to try to keep it locked, but it doesn't have the feedback loop that the actual analog PLL does. Kind of comparing apples with oranges at that point. Brian ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] RIO FIFO error on X310 over PCI-express
Dear all, I'm using 2 USRP X310s over PCI-express (connected to the same computer, running UHD 4.0, compiled from source on CentOS Stream, kernel 4.18). If I specify mboard 0 for one multi_usrp and mboards 0 and 1 for another multi_usrp, I get the following error: "RuntimeError: x300_impl: Could not initialize RIO session. A Configure FIFO, Stop FIFO, Read FIFO, or Write FIFO function was called while the host had acquired elements of the FIFO. Release all acquired elements before configuring, stopping, reading, or writing. (Error code -63083)" If I try again after this, it says the FPGA is busy, then the uhd_find_devices starts not reporting the serial number at all for one of the devices. The error appears every time I run this configuration, and also breaks the RIO interface in a way that requires a computer reboot to make it work again. After rebooting, if I add both mboards 0 and 1 to both multi_usrp objects, then everything works. I attach two logs where you can see the UHD call sequences for the bad and good configurations. Note that there is no multithreaded access to UHD before the error appears. Please let me know if you have any ideas what might cause this. Thanks, Viktor [2021-06-14 19:37:29.201521] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'init serial=31BA24F' [2021-06-14 19:37:29.201571] [0x7f531b01b700] [info]Creating the usrp device with: >>serial=31BA24F<<... [INFO] [UHD] linux; GNU C++ version 8.4.1 20200928 (Red Hat 8.4.1-1); Boost_106600; UHD_4.0.0.0-0-unknown [INFO] [X300] X300 initialization sequence... [INFO] [X300] Connecting to niusrpriorpc at localhost:5444... [INFO] [X300] Using LVBITX bitfile /home/verdelyi/sw/uhd-images-4.0/usrp_x310_fpga_HG.lvbitx [INFO] [X300] Radio 1x clock: 200 MHz [2021-06-14 19:37:32.559848] [0x7f531b01b700] [info]Multi-USRP object: Single USRP: Device: X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: UBX RX RX Channel: 1 RX DSP: 1 RX Dboard: B RX Subdev: UBX RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: UBX TX TX Channel: 1 TX DSP: 1 TX Dboard: B TX Subdev: UBX TX [2021-06-14 19:37:32.559950] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:32.561135] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setClockSource_10MHzREF external' [2021-06-14 19:37:32.629721] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:32.670958] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setClockSource_PPS external' [2021-06-14 19:37:32.671115] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:32.752755] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setTXSubdevice' [2021-06-14 19:37:32.752788] [0x7f531b01b700] [info]Setting TX subdevice to A:0 on mboard 0 [2021-06-14 19:37:32.759450] [0x7f531b01b700] [info]1 devices, 1 TX channels [2021-06-14 19:37:32.759474] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:32.841755] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setTXGain 20.0' [2021-06-14 19:37:32.841795] [0x7f531b01b700] [info]Setting TX Gain: 20.00 dB... [2021-06-14 19:37:32.841870] [0x7f531b01b700] [info]Actual TX Gain: 20.00 dB... [2021-06-14 19:37:32.841898] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:32.923763] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setTXSamplingRate 100.0' [2021-06-14 19:37:32.923794] [0x7f531b01b700] [info]Setting TX Rate: 1.00 Msps... [2021-06-14 19:37:32.923860] [0x7f531b01b700] [info]Actual TX Rate: 1.00 Msps... [2021-06-14 19:37:32.923885] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:33.005762] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setTXAntenna TX/RX' [2021-06-14 19:37:33.005809] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... [2021-06-14 19:37:33.087760] [0x7f531b01b700] [info] [Session-remoteport-45512] Received control command: 'setTXBandwidth 1.6E8' [2021-06-14 19:37:33.087791] [0x7f531b01b700] [info]Setting TX Bandwidth: 160.00 MHz... [2021-06-14 19:37:33.087815] [0x7f531b01b700] [info]Actual TX Bandwidth: 160.00 MHz... [2021-06-14 19:37:33.087838] [0x7f531b01b700] [info] [Session-remoteport-45512] Waiting for command... Accepting connections... New client session [2021-06-14 19:37:33.129054] [0x7f5319017700] [info] [Session-remoteport-455
[USRP-users] Re: UHD 4.1.0.0 released!
Dear all,
Has the LO sharing API changed in UHD 4.1? I have used the following
code in UHD 4.0 to share LOs on a USRP X310 with 2 TwinRX installed, and
it worked (all 4 channels were in sync, i.e. more or less consistent
phase offset). Now if I switch to UHD 4.1, channels 0 and 1 keep
drifting away from channels 2 and 3. It seems like the RF A and RF B
frontends are not in sync, but the 2 channels within them are in sync.
// based on https://github.com/EttusResearch/uhd/issues/237
usrp->set_rx_lo_export_enabled(true,uhd::usrp::multi_usrp::ALL_LOS,0);
usrp->set_rx_lo_source("companion",uhd::usrp::multi_usrp::ALL_LOS,1);
usrp->set_rx_lo_source("external",uhd::usrp::multi_usrp::ALL_LOS,2);
usrp->set_rx_lo_source("external",uhd::usrp::multi_usrp::ALL_LOS,3);
Thanks,
Viktor
On 7/1/21 11:33 PM, Aaron Rossetto wrote:
Hello USRP community,
On behalf on everyone at NI/Ettus Research, I am very proud to
announce the release of UHD 4.1, the latest version of the USRP
Hardware Driver! As my colleague Haydn Nelson posted to the list
earlier in the week, UHD 4.1 offers support for the newest member of
the USRP family, the NI Ettus USRP X410. This new generation of USRP
provides the highest performance of any USRP to date, sporting 4x4
TX/RX channels, 400 MHz instantaneous bandwidth per channel, and a
tunable range from 1 MHz to 7.2 GHz, to name just a few of its
best-in-class features. Check out the Ettus Research website[1] to
learn more about the X410. Beyond support for the X410, however, UHD
4.1 also provides numerous bug fixes and stability improvements
benefitting the entire stable of USRP devices. See the changelog
associated with the v4.1.0.0 tag[2] for a more comprehensive list of
changes.
While we strive to ensure the highest quality of UHD releases, it is
possible that some gremlins may have found their way into the process.
We appreciate your patience and understanding as we shake out any
remaining bugs. If you encounter problems, please let us know by
filing a issue against UHD on the GitHub repo[3] or by posting to the
USRP-users mailing list so that we can get it resolved.
Finally, we hope to see you in person or virtually at GNU Radio
Conference 2021[4], taking place 20-24 September 2021.
With best regards,
Aaron Rossetto
[1]
https://www.ettus.com/introducing-the-most-advanced-sdr-the-ni-ettus-usrp-x410/
[3] https://github.com/EttusResearch/uhd/issues/
[USRP-users] Assertion fail when destroying tx streamer (UHD 4)
Hi all,
I get an undecipherable assertion failure when running the following
simple code using a 1Gbps Ethernet link. The error happens when t1 goes
out of scope, every time I run the application. What am I missing?
int main(int argc, char *argv[]) {
uhd::device_addr_t devAddresses("addr=192.168.10.2");
auto usrp = uhd::usrp::multi_usrp::make(devAddresses);
uhd::stream_args_t stream_args("fc32", "sc16");
stream_args.channels.push_back(0);
{
auto t1 = usrp->get_tx_stream(stream_args);
std::cout << "t1 alive" << std::endl;
}
std::cout << "t1 dead, OK" << std::endl;
return 0;
}
The output and the error is as follows:
[INFO] [UHD] linux; GNU C++ version 11.0.1 20210324 (Red Hat 11.0.1-0);
Boost_107500; UHD_4.0.0.0
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
t1 alive
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
/usr/include/c++/11/bits/stl_vector.h:1045: std::vector<_Tp,
_Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
_Alloc>::size_type) [with _Tp =
boost::detail::adj_list_genboost::vecS, boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t> >, boost::vecS, boost::vecS,
boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t>, boost::no_property,
boost::listS>::config::stored_vertex; _Alloc =
std::allocatorboost::vecS, boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t> >, boost::vecS, boost::vecS,
boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t>, boost::no_property,
boost::listS>::config::stored_vertex>; std::vector<_Tp,
_Alloc>::reference =
boost::detail::adj_list_genboost::vecS, boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t> >, boost::vecS, boost::vecS,
boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t>, boost::no_property,
boost::listS>::config::stored_vertex&; std::vector<_Tp,
_Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()'
failed.
./quickRun.sh: line 8: 47138 Aborted (core dumped)
./$OUTNAME
Environment:
Fedora 34 x64
UHD 4.0.0.0
USRP X310 w/ UBX-160 x 2
Thanks,
Viktor
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Assertion fail when destroying tx streamer (UHD 4)
Hi Marcus,
Thanks for your comment. Unfortunately I won't be able to try this for a
while (due to an unexpected stay-home order after COVID close contact),
but I tried something similar earlier, so I will explain that.
I created and configured a USRP object, used it, and then created a new
one, assigning it to the same shared_ptr. In this case, the shared_ptr
goes out of scope and gets destroyed, but the application keeps running
and tries to use the new object. In that case, I sometimes get an
additional error saying something like "attempting to reconnect Rfnoc
block", but ultimately (maybe after another destruction/recreation
cycle) it fails with the same error I sent earlier. Basically, the error
seems to be triggered by the destruction of a streamer object, and
whatever rfnoc cleanup that entails internally. Could it be that I
should wait/sleep after destroying a streamer to let the rfnoc magic
complete before attempting to create a new streamer or quitting the
application?
P.S. also note that the code I sent earlier does not print "t1 dead,
OK", meaning that it crashes before the return statement.
Thanks,
Viktor
On 7/7/21 11:49 PM, Marcus D. Leech wrote:
On 07/07/2021 09:09 AM, Viktor Erdelyi wrote:
Hi all,
I get an undecipherable assertion failure when running the following
simple code using a 1Gbps Ethernet link. The error happens when t1
goes out of scope, every time I run the application. What am I missing?
int main(int argc, char *argv[]) {
uhd::device_addr_t devAddresses("addr=192.168.10.2");
auto usrp = uhd::usrp::multi_usrp::make(devAddresses);
uhd::stream_args_t stream_args("fc32", "sc16");
stream_args.channels.push_back(0);
{
auto t1 = usrp->get_tx_stream(stream_args);
std::cout << "t1 alive" << std::endl;
}
std::cout << "t1 dead, OK" << std::endl;
return 0;
}
The output and the error is as follows:
[INFO] [UHD] linux; GNU C++ version 11.0.1 20210324 (Red Hat
11.0.1-0); Boost_107500; UHD_4.0.0.0
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
t1 alive
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
/usr/include/c++/11/bits/stl_vector.h:1045: std::vector<_Tp,
_Alloc>::reference std::vector<_Tp,
_Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp =
boost::detail::adj_list_genboost::vecS, boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t> >, boost::vecS, boost::vecS,
boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t>, boost::no_property,
boost::listS>::config::stored_vertex; _Alloc =
std::allocatorboost::vecS, boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t> >, boost::vecS, boost::vecS,
boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t>, boost::no_property,
boost::listS>::config::stored_vertex>; std::vector<_Tp,
_Alloc>::reference =
boost::detail::adj_list_genboost::vecS, boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t> >, boost::vecS, boost::vecS,
boost::bidirectionalS,
boost::propertyuhd::rfnoc::node_t*>,
boost::propertyuhd::rfnoc::graph_edge_t>, boost::no_property,
boost::listS>::config::stored_vertex&; std::vector<_Tp,
_Alloc>::size_type = long unsigned int]: Assertion '__n <
this->size()' failed.
./quickRun.sh: line 8: 47138 Aborted (core dumped)
./$OUTNAME
Environment:
Fedora 34 x64
UHD 4.0.0.0
USRP X310 w/ UBX-160 x 2
Thanks,
Viktor
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
What happens if you sleep for perhaps 1 second prior to exiting?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
