Re: [USRP-users] Plagued by sporadic TX underruns on some systems, B200
Hi Mark-Jan, Thanks for your response. On 03/05/2019 00:02, Mark-Jan Bastian wrote: > For more in-depth USB debugging, there are external USB 2.0 and 3.x > hardware bus analysers available, for example from the swiss company > ellisys.com. I have experience in USB protocol analysis from a previous job, and know the Ellisys tools among others. As a consequence, I have an idea about what effort it implies to look at the problem from that angle (one could call this a "bottom-up approach"), and I won't go that way. > Some things can be very subtle, for example this (quite amazing) > 2013 ethernet PHY bug: > https://www.theregister.co.uk/2013/02/06/packet_of_death_intel_ethernet/ > Very tough engineering by the affacted customer, who made it reproducable > and fixed by a simple EEprom update from the vendor. Interesting story, but I hope it is not a parallel to my situation, and that a simpler approach will fix it. > Pure theory: What if this intermittent issue would be an issue with a > certain sequence of packetlengths, some of them on the boundary of the > maximum size for that endpoint and endpointtype, that are not handled > properly at one or both sides, causing a glitch/retransmission/faillure, > resulting in the application-level visible underruns ? > How would you measure that ? How could you optimize the packetlengths > so that the issue is quicker to reproduce ? Or avoid the issue by > anticipating and avoiding such packetsequences ? It's a possible hypothesis, but I don't see how to test it easily. >> Could CPU frequency scaling lead to interruptions? > > It would leave that off [...] I'd love to, but it's not clear to me how to achieve that nowadays with the intel_pstate driver: https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html It's probably not even possible anymore given that the cpu and voltage scaling responsiblity got moved into the processor itself. mpb ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Timed frequency switching on multiple channels not possible
Sorry for the late answer, I was busy. I tried that including a one second sleep after it but it does not help. Am 26.04.2019 um 18:30 schrieb Marcus D. Leech via USRP-users: On 04/26/2019 12:07 PM, Fabian Schwartau via USRP-users wrote: Ohh.. you are right, I did not do that in the example code. But the problem is the same in my main application, where I do. As I said, the 180° phase shift is probably somehow related and not that easy to reporduce. So the spectrum or I/Q swap should be the main issue here and I hope that this will also solve the 180° phase swap. Interestingly the phase is correct, if I set the frequency twice for each channel with a little delay in between. Could you try something? Insert a set_time_next_pps() into the code in initalization--this should align the TOD clocks in both internal DSP radio modules. Am 26.04.2019 um 18:02 schrieb Marcus D. Leech via USRP-users: On 04/26/2019 11:36 AM, Fabian Schwartau via USRP-users wrote: Hi, I am am using LO sharing. So there should not be any phase offset and no mirrored spectrum, no matter when the USRP comes around to change the frequency. Even not using LO-sharing, the spectrum should NOT be mirrored. The apparent I/Q swap issue I agree should not happen, and I have a query in to R&D about it. Am 26.04.2019 um 17:12 schrieb Marcus D. Leech via USRP-users: On 04/26/2019 05:13 AM, Fabian Schwartau via USRP-users wrote: Hi, a couple of days ago I filed a bug report which caused the USRPs to switch but noone has responded yet. I did now encountered other problems wich might be related to that issue. Can somone from Ettus (or someone else) take a look at that? Bug report is here: https://github.com/EttusResearch/uhd/issues/271 Best regards, Fabian So, the original design reason for timed-commands was to support simultaneous tuning (and assertion of a resynch pulse) across *multiple USRPs*, in support of reducing/eliminating mutual phase offset among identically-hardwared USRPs, for daughtercards that supported phase-resynch. When you use timed commands within a single USRP, hoping for similar effects, you won't get them, because the commands in the queue are *necessarily* executed sequentially. Even if there was a "parallel execution" structure within the FPGA to handle the commands, most of the commands you care about ultimately end up on an SPI or I2C bus, and those are inherently serial, and multiple devices (synthesizers, variable-gain amplifiers, clock-plls) typically share a single such bus on a per-slot basis. In order to have "true parallelism" *within* a single USRP, you'd need dedicated control buses to each device that is controlled by I2C/SPI/whatever, *in addition* to parallel execution within the FPGA. When you're setting a bunch of PLL synthesizers sequentially, you can expect that they won't agree on phase, even when being driven by a common clock. The mechanism for achieving phase coherence with TwinRx is to use LO sharing. https://kb.ettus.com/TwinRX This app-note talks about LO sharing with TwinRX https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Plagued by sporadic TX underruns on some systems, B200
On Mon, May 06, 2019 at 09:36:34AM +0200, Matthias Br??ndli wrote: > > Pure theory: What if this intermittent issue would be an issue with a > > certain sequence of packetlengths, some of them on the boundary of the > > maximum size for that endpoint and endpointtype, that are not handled > > properly at one or both sides, causing a glitch/retransmission/faillure, > > resulting in the application-level visible underruns ? > > How would you measure that ? How could you optimize the packetlengths > > so that the issue is quicker to reproduce ? Or avoid the issue by > > anticipating and avoiding such packetsequences ? > > It's a possible hypothesis, but I don't see how to test it easily. The ellisys protocol analyser supports an external trigger, and does support recording the USB enumeration, then pause and record into a circular buffer for indefinite time. Then the trick is to wait and detect your underrun, in your UHD apllication, and send a charachter to a usb serialport conncted via another usb hostcontroller/root port, to this coaxial trigger input. Configure the trigger to stop capturing, and analyse the USB traffic around the underrun. This timestamping is not perfect, but you should be in a few 10s msec of the underrun. If there is a USB bulk endpoint underrun visible in the ellisys log, other ways of filling that endpoint in time could be tried, in hostcontroller driver, libusb, uhd, or your application. Scheduling and prioritisation of all software components can be double-checked. Mark-Jan ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B200 Overrun
@Marcus Muller What are the settings of usrp_spectrum_sense that you use? Sampling rate :16e6Min_freq 2.4e9max_freq 2.5e9BW 15625 Hz FFT 1024 On Monday, 6 May, 2019, 12:53:49 am IST, Rensi Mathew wrote: Yes USB 3.0. The OS is Ubuntu 16.04 LTS 64-bit Intel® Core™ i5-4570 CPU @ 3.20GHz × 4 Disk 309.6 GB Memory 3.6 GiB Could it because of memory problem?The yellow/orange light in the system blinks when USRP runs(showing heavily loaded). RensiOn Saturday, 4 May, 2019, 10:09:03 am IST, Robin Coxe wrote: Are you using USB 3.0? USB 2.0 will max out at about 8 Ms/s. Robin Coxe | Chief R&D Program Manager, SDR | Santa Clara, CA | 408.610.6363 From: USRP-users on behalf of Rensi Mathew via USRP-users Sent: Friday, May 3, 2019 9:17 PM To: Vsr Ravi via USRP-users Subject: [USRP-users] B200 Overrun Dear sirI am using B200 SDR to run the program usrp_spectrum_sense.py with a sampling frequency of 16e6.I think I am using a fairly low sampling rate. Still I am getting some ''. Could someone tell me the possible reasons for the same? And how I can avoid the same? Thanking youRensi Sam ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 numpy missing?
Thanks Neel, I will keep an eye out for updates. From: Neel Pandeya Sent: Saturday, May 4, 2019 1:23 AM To: Jason Matusiak Cc: Ettus Mail List; Chris Gobbett Subject: Re: [USRP-users] E320 numpy missing? Hello Jason and Chris: I understand your frustration. We are working on instructions for adding GNU Radio support to the E320, and we will provide you with a filesystem. We should have something ready for you by the middle of next week. I can be your point-of-contact on this issue, and feel free to contact me directly. I will make a follow-on post as well to update the mailing list. --Neel Pandeya On Thu, 2 May 2019 at 08:07, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Chris, It is a shame that the E320 doesn't seem to have complete support, but maybe someone from Ettus will chime in at some point (though it has already been over a month since you posted). As of now, these are paperweights in our office and I have to switch gears to a different project with a different vendor until it gets updated. I am not sure who we can even ping at Ettus on the embedded front in case they aren't monitoring the mailing list. Do you have a contact there on the embedded side? You don't happen to have a series of steps posted somewhere that you use to try to get the E320 to a usable state do you? From: USRP-users mailto:usrp-users-boun...@lists.ettus.com>> on behalf of Chris Gobbett via USRP-users mailto:usrp-users@lists.ettus.com>> Sent: Wednesday, May 1, 2019 9:21 PM To: Ettus Mail List Subject: Re: [USRP-users] E320 numpy missing? I've had similar problems since this post in March, and still waiting on a 'clean' way forward http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-March/059332.html In the interim I've done lots of cross-compiling and also stealing libraries/binaries from working E310 images; many of the included binaries seem gimped or a step down from what was on the E310. - Original Message - From: "Jason Matusiak" mailto:ja...@gardettoengineering.com>> To: "Philip Balister" mailto:phi...@balister.org>>, "Ettus Mail List" mailto:usrp-users@lists.ettus.com>> Cc: Sent: Wed, 1 May 2019 14:40:16 + Subject: Re: [USRP-users] E320 numpy missing? I just double-checked and ENABLE_PYTHON is on in my system (which was apparently the default since I didn't spell it out in my cmake command). From: Jason Matusiak Sent: Wednesday, May 1, 2019 10:36 AM To: Philip Balister; Ettus Mail List Subject: Re: [USRP-users] E320 numpy missing? I actually was using a .sh file from earlier in April, but pulling down the most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see pretty much any site-packages in the sysroot. Those things seem to be there automatically when using the .sh info with the e310 files. I will try including python in the cmake path (which I've never needed to do before), but is that going to be enough? I feel like the back-and-forth you and I had last year with the rocko build for the E310 were for pretty similar issues. But honestly, I need to look back at the emails for the exact issues at the time. From: Philip Balister mailto:phi...@balister.org>> Sent: Wednesday, May 1, 2019 10:31 AM To: Jason Matusiak; Ettus Mail List Subject: Re: [USRP-users] E320 numpy missing? On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote: > I also get a "ImportError: No module named sip" when I try to run: > uhd_siggen_gui > > So I think a few things might be missing from the cross-compile setup. I took a few minutes and looked at the current state of the BSP. It looks like you might have this image: https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb I forget where numpy is the gnuradio dependency tree, but I'm going to guess if you enable python support in gnuradio (yes it might be possible to use gnuradio without python) you will need numpy to build/run. Philip > > > From: Jason Matusiak > Sent: Wednesday, May 1, 2019 8:46 AM > To: Ettus Mail List > Subject: E320 numpy missing? > > Finally got my E320 in and I cross-compiled a new setup. I tried to fire up > my flowgraph (which works fine on an E310) and it is complaining about numpy > missing. > > If I do a search from / on the E320, the only numpy that is showing up is: > /usr/include/boost/python/numpy > > If I do a search from a good E310 in / I see: > ./usr/lib/python2.7/site-packages/numpy > ./usr/lib/python2.7/site-packages/numpy/core/include/numpy > ./usr/lib/python2.7/site-packages/Cython/Includes/numpy > ./usr/include/boost/python/numpy > > > Back on the host machine, my E320 cross-compile prefix shows numpy: > ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy > > My good E310
[USRP-users] Bursty packet transmission
Hi,
I am using USRP N210 for bursty packet transmission, and have difficulty to
understand "tx_md.end_of_burst = true" in C++ code. I am attaching my code
at the end and hope someone can help.
The problem is:
1. when I comment out "tx_md.end_of_burst = true" and use the function for
transmission periodically, my receiver can decode the packet successfully.
But it seems that it can only detect N - 1 packet, where N is the number of
packets that I sent at the transmitter. For example, when I send 3 packets,
the receiver can only decode 2 packets, and so forth. Not sure what is the
reason behind this.
2. When I uncomment "tx_md.end_of_burst = true" (either the one inside the
WHILE loop or outside one), my receiver cannot decode the packets anymore.
When I use spectrum analyzer to see the signal, I can see that the
transmitter does send the signal into the air and the waveform shape looks
right. However, the signal cannot be decoded.
Any suggestions?
Thank you!
Hua
=
size_t sdr_dev::usrp_transmit(vector*> tx_buff_ptr, size_t
requested_num_samps) {
tx_md.start_of_burst = true;
tx_md.end_of_burst = false;
tx_md.has_time_spec = false;
tx_md.time_spec = uhd::time_spec_t(1.0); //0.1
//the first call to send() will block this many seconds before sending:
timeout = seconds_in_future + 0.1; //timeout (delay before transmit +
padding)
vector*> tx_buff_ptr_tmp = tx_buff_ptr;
size_t acc_num_samps = 0; //number of accumulated samples
size_t total_num_samps = requested_num_samps;
while(acc_num_samps < total_num_samps) {
size_t samps_to_send = total_num_samps - acc_num_samps;
if (samps_to_send > tx_max_num_samps) {
samps_to_send = tx_max_num_samps;
}
else {
//tx_md.end_of_burst = true;
}
for (int i = 0; i < tx_buff_ptr.size(); i++) tx_buff_ptr_tmp[i] =
&tx_buff_ptr[i][acc_num_samps];
//send a single packet
size_t num_tx_samps = tx_stream->send(tx_buff_ptr_tmp,
samps_to_send, tx_md, timeout);
//do not use time spec for subsequent packets
tx_md.has_time_spec = false;
tx_md.start_of_burst = false;
acc_num_samps += num_tx_samps;
}
//tx_md.end_of_burst = true;
tx_stream->send("", 0, tx_md);
return acc_num_samps;
}
==
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] E320 Auto-Booting function not working?
Following the steps from the E320 getting started guide [1], I'm not having any luck with the unit auto booting when power is applied The command "eeprom-set-flags 0x1" seems to take effect successfully, and sets the value of MCU_FLAGS[0] to 0x1 (noting that the default value is 0x8, which I'm assuming means auto boot is "off") . This is also verified as holding its value between power cycles, by looking at the output of the eeprom-dump command. But... removing power to the unit, then applying power again doesn't result in the unit booting by itself. Anyone had any experience with this and/or able to offer help? I'm hesitant to trial-and-error different values into eeprom-set-flags, for fear of breaking something... :) Cheers,Chris [1] https://kb.ettus.com/E320_Getting_Started_Guide [1] Links: -- [1] https://kb.ettus.com/E320_Getting_Started_Guide ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
