Re: [USRP-users] sc16 - complex to numpy float
Here's a way in Python you can pull in SC16 and recover the FC32 from a
file. It'll scale the values from the INT16_MAX back to -1.0 to 1.0 too in
one shot.
import numpy
file="somefile.iq"
dat = numpy.fromfile(file, dtype=numpy.int16)
data = dat[0::2]/32767.0 + 1j*dat[1::2]/32767.0 # ::02 says every other
starting at 0
Maybe that'll help?
On Fri, Sep 6, 2019 at 11:51 AM Michael Dickens via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Joel - IIRC UHD takes and provides std::complex values that are
> in (-1.0,+1.0), meaning that the minimum (most negative) value is
> -1.0+epsilon and the maximum (most positive) value is 1.0-epsilon, where
> "epsilon" is the smallest positive 32-bit float value (approximately
> 1.17549e-38).
>
> If you're looking just for conversion from sc16 (aka
> "std::complex") to std::complex in C++ (note that "float"
> is 32-bits in C++), you could do something like the following (which should
> work with pretty much any C++ standard):
>
> {{{
> #include
> #include
> #include
>
> static float scale_factor = float(1) /
>float(std::min(int16_t(-std::numeric_limits::min()),
>std::numeric_limits::max()));
>
> std::complex sc16_to_float (const std::complex& input) {
> return std::complex
> (std::real(input) * scale_factor,
>std::imag (input) * scale_factor);
> }
> }}}
>
> There are, obviously, more efficient ways to do this. I believe that VOLK
> provides CPU optimized functions something along the lines of the above
> code. Hope this is useful! - MLD
>
> On Fri, Sep 6, 2019 at 8:47 AM J Subash via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Imad,
>>
>>
>> Thanks very much for your reply. Unfortunately that solution does not
>> work.
>>
>> Because if it reads 4 bytes (two int16_t in C/C++ parlance; > world) which for argument sake holds 15, 16 (which are integers). These are
>> then cast as floats which makes them 15.0 and 16.0 and then when viewed as
>> np.complex64 becomes 15.0 + 16.0j.
>>
>>
>> I have had a look at the converters section in the uhd API (
>> https://github.com/EttusResearch/uhd/tree/master/host/lib/convert) but
>> can't get my head around the code.
>>
>>
>> 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
Re: [USRP-users] How to periodically write files using USRP and GNUradio
I folks, to complete the timing set, I also just added another timer module to gr-filerepeater. This one you can give a time-of-day (hours/minutes/seconds) and a duration and it'll generate a positive state transition when the specified time is reached every day, then a 0 state transition when the specified duration expires. So if you wanted to write to a file starting at 3am for 15 minutes, this would be the way to do it without having to wake up! On Thu, May 2, 2019 at 9:35 AM GhostOp14 wrote: > Ali, I just pushed a couple of updates. Let's see if that fixes it for > you. > > I added: > 1. [Timer] Some thread safety to the timer module. I also noticed in my > flowgraph if I went to the top block options and turned on "realtime > scheduling" it was generally more accurate on the timing (makes sense). > 2. [File Sink] Added a proper gnuradio stop() function to make sure files > get properly closed on exit. (Burns me every time swig doesn't > guarantee that C++ destructors get called so you really need to clean up in > stop(). I just get lazy sometimes) > > Anyway do a fresh git pull and let me know if that fixes any of your > issues or if you still experience them. > > > > On Wed, May 1, 2019 at 8:52 PM GhostOp14 wrote: > >> Thanks Ali, >> >> I'll take a look at what you found with inconsistencies and see if I can >> hunt them down. >> >> >> >> On Wed, May 1, 2019 at 5:35 PM Ali Dormiani >> wrote: >> >>> Hello GhostOp14 and USRP users, >>> >>> Your oot blocks are amazing. They do exactly what we need in a clean >>> way. In testing, we have found that there are rare anomalies though (occur >>> like a rare Poisson process). >>> >>> 1. Sometimes the advanced file sink will create an empty file of 0 >>> bytes. >>> >>> 2. Sometimes the state timer messes up. We avoid a runaway data capture >>> by using the 'max file size' parameter in the advanced file sink. >>> >>> Overall, this solution is very good and eliminates a lot of variables >>> from our experiments. All of our USRP devices are initialized once and >>> constantly stream data (only some of which is saved). Our phase calibration >>> is a lot more consistent now. >>> >>> Thank you again for providing these oot blocks on Github. My own custom >>> embedded python block was inelegant and inconsistent. >>> >>> Cheers, >>> >>> Ali >>> >>> >>> On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Morning everyone, not sure my note yesterday hit the list correctly so >>>> I'm trying again. >>>> >>>> Mark: I have a solution for you. I added a new block yesterday to >>>> gr-filerepeater (pybombs or github). There's now a state timer block >>>> that'll generate a message based on block-specified timing. Trigger time, >>>> cycle time, etc. gr-filerepeater also has a new file sink block I've added >>>> in the past couple of weeks specifically to address the same kind of >>>> problem. You can feed the timer msg out to the new sink msg in. The new >>>> block will then key off the state (1/0) in the msg metadata and start/stop >>>> writing to a file. You can specify a directory and a base file name, then >>>> every time a new file write is started it'll append a timestamp. Should >>>> exactly match up to what you're trying to accomplish. I'll post on the >>>> gnuradio list as well since they're gnuradio blocks. >>>> >>>> >>>> >>>> On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: >>>>> > Hey all, >>>>> > >>>>> > I'd like to know how to write short files of streamed USRP data >>>>> > periodically using GNUradio. For instance, I'd like the USRP to >>>>> > automatically record 5 seconds of data every 10 minutes. It does not >>>>> > matter to me whether the USRP is constantly on and most of the data >>>>> is >>>>> > being discarded, or if the USRP wakes up every 10 minutes to record >>>>> > the data before sleeping. Whichever is easiest to achieve is fine by >>>>> > me. Does anyone have experience doing this kind of thing? >>>>> > >>>>&
Re: [USRP-users] How to periodically write files using USRP and GNUradio
Ali, I just pushed a couple of updates. Let's see if that fixes it for you. I added: 1. [Timer] Some thread safety to the timer module. I also noticed in my flowgraph if I went to the top block options and turned on "realtime scheduling" it was generally more accurate on the timing (makes sense). 2. [File Sink] Added a proper gnuradio stop() function to make sure files get properly closed on exit. (Burns me every time swig doesn't guarantee that C++ destructors get called so you really need to clean up in stop(). I just get lazy sometimes) Anyway do a fresh git pull and let me know if that fixes any of your issues or if you still experience them. On Wed, May 1, 2019 at 8:52 PM GhostOp14 wrote: > Thanks Ali, > > I'll take a look at what you found with inconsistencies and see if I can > hunt them down. > > > > On Wed, May 1, 2019 at 5:35 PM Ali Dormiani wrote: > >> Hello GhostOp14 and USRP users, >> >> Your oot blocks are amazing. They do exactly what we need in a clean way. >> In testing, we have found that there are rare anomalies though (occur like >> a rare Poisson process). >> >> 1. Sometimes the advanced file sink will create an empty file of 0 bytes. >> >> 2. Sometimes the state timer messes up. We avoid a runaway data capture >> by using the 'max file size' parameter in the advanced file sink. >> >> Overall, this solution is very good and eliminates a lot of variables >> from our experiments. All of our USRP devices are initialized once and >> constantly stream data (only some of which is saved). Our phase calibration >> is a lot more consistent now. >> >> Thank you again for providing these oot blocks on Github. My own custom >> embedded python block was inelegant and inconsistent. >> >> Cheers, >> >> Ali >> >> >> On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Morning everyone, not sure my note yesterday hit the list correctly so >>> I'm trying again. >>> >>> Mark: I have a solution for you. I added a new block yesterday to >>> gr-filerepeater (pybombs or github). There's now a state timer block >>> that'll generate a message based on block-specified timing. Trigger time, >>> cycle time, etc. gr-filerepeater also has a new file sink block I've added >>> in the past couple of weeks specifically to address the same kind of >>> problem. You can feed the timer msg out to the new sink msg in. The new >>> block will then key off the state (1/0) in the msg metadata and start/stop >>> writing to a file. You can specify a directory and a base file name, then >>> every time a new file write is started it'll append a timestamp. Should >>> exactly match up to what you're trying to accomplish. I'll post on the >>> gnuradio list as well since they're gnuradio blocks. >>> >>> >>> >>> On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: >>>> > Hey all, >>>> > >>>> > I'd like to know how to write short files of streamed USRP data >>>> > periodically using GNUradio. For instance, I'd like the USRP to >>>> > automatically record 5 seconds of data every 10 minutes. It does not >>>> > matter to me whether the USRP is constantly on and most of the data >>>> is >>>> > being discarded, or if the USRP wakes up every 10 minutes to record >>>> > the data before sleeping. Whichever is easiest to achieve is fine by >>>> > me. Does anyone have experience doing this kind of thing? >>>> > >>>> > -Mark >>>> > >>>> > >>>> > >>>> > -- >>>> > Mark Wagner >>>> > University of California San Diego >>>> > Electrical and Computer Engineering >>>> > >>>> > >>>> If you're using Gnu Radio, you can simply use the file sink, and have >>>> it >>>> record to "/dev/null" most of the time, then have something (perhaps via >>>>the XMLRPC built-in feature) change the filename to whatever your >>>> desired filename is, and then revert it back to "/dev/null". >>>> >>>> I think I said the same thing on the discuss-gnuradio mailing list a >>>> few >>>> days ago. >>>> >>>> The usrp-users mailing list isn't the best place to ask Gnu Radio >>>> questions, a question like this, which is inherently radio-type >>>> agnostic, probably >>>>belongs on the discuss-gnuradio mailng list, because it's more about >>>> "how do I make Gnu Radio dance". >>>> >>>> >>>> >>>> ___ >>>> 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] How to periodically write files using USRP and GNUradio
Thanks Ali, I'll take a look at what you found with inconsistencies and see if I can hunt them down. On Wed, May 1, 2019 at 5:35 PM Ali Dormiani wrote: > Hello GhostOp14 and USRP users, > > Your oot blocks are amazing. They do exactly what we need in a clean way. > In testing, we have found that there are rare anomalies though (occur like > a rare Poisson process). > > 1. Sometimes the advanced file sink will create an empty file of 0 bytes. > > 2. Sometimes the state timer messes up. We avoid a runaway data capture by > using the 'max file size' parameter in the advanced file sink. > > Overall, this solution is very good and eliminates a lot of variables from > our experiments. All of our USRP devices are initialized once and > constantly stream data (only some of which is saved). Our phase calibration > is a lot more consistent now. > > Thank you again for providing these oot blocks on Github. My own custom > embedded python block was inelegant and inconsistent. > > Cheers, > > Ali > > > On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Morning everyone, not sure my note yesterday hit the list correctly so >> I'm trying again. >> >> Mark: I have a solution for you. I added a new block yesterday to >> gr-filerepeater (pybombs or github). There's now a state timer block >> that'll generate a message based on block-specified timing. Trigger time, >> cycle time, etc. gr-filerepeater also has a new file sink block I've added >> in the past couple of weeks specifically to address the same kind of >> problem. You can feed the timer msg out to the new sink msg in. The new >> block will then key off the state (1/0) in the msg metadata and start/stop >> writing to a file. You can specify a directory and a base file name, then >> every time a new file write is started it'll append a timestamp. Should >> exactly match up to what you're trying to accomplish. I'll post on the >> gnuradio list as well since they're gnuradio blocks. >> >> >> >> On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: >>> > Hey all, >>> > >>> > I'd like to know how to write short files of streamed USRP data >>> > periodically using GNUradio. For instance, I'd like the USRP to >>> > automatically record 5 seconds of data every 10 minutes. It does not >>> > matter to me whether the USRP is constantly on and most of the data is >>> > being discarded, or if the USRP wakes up every 10 minutes to record >>> > the data before sleeping. Whichever is easiest to achieve is fine by >>> > me. Does anyone have experience doing this kind of thing? >>> > >>> > -Mark >>> > >>> > >>> > >>> > -- >>> > Mark Wagner >>> > University of California San Diego >>> > Electrical and Computer Engineering >>> > >>> > >>> If you're using Gnu Radio, you can simply use the file sink, and have it >>> record to "/dev/null" most of the time, then have something (perhaps via >>>the XMLRPC built-in feature) change the filename to whatever your >>> desired filename is, and then revert it back to "/dev/null". >>> >>> I think I said the same thing on the discuss-gnuradio mailing list a few >>> days ago. >>> >>> The usrp-users mailing list isn't the best place to ask Gnu Radio >>> questions, a question like this, which is inherently radio-type >>> agnostic, probably >>>belongs on the discuss-gnuradio mailng list, because it's more about >>> "how do I make Gnu Radio dance". >>> >>> >>> >>> ___ >>> 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] How to periodically write files using USRP and GNUradio
Morning everyone, not sure my note yesterday hit the list correctly so I'm trying again. Mark: I have a solution for you. I added a new block yesterday to gr-filerepeater (pybombs or github). There's now a state timer block that'll generate a message based on block-specified timing. Trigger time, cycle time, etc. gr-filerepeater also has a new file sink block I've added in the past couple of weeks specifically to address the same kind of problem. You can feed the timer msg out to the new sink msg in. The new block will then key off the state (1/0) in the msg metadata and start/stop writing to a file. You can specify a directory and a base file name, then every time a new file write is started it'll append a timestamp. Should exactly match up to what you're trying to accomplish. I'll post on the gnuradio list as well since they're gnuradio blocks. On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: > > Hey all, > > > > I'd like to know how to write short files of streamed USRP data > > periodically using GNUradio. For instance, I'd like the USRP to > > automatically record 5 seconds of data every 10 minutes. It does not > > matter to me whether the USRP is constantly on and most of the data is > > being discarded, or if the USRP wakes up every 10 minutes to record > > the data before sleeping. Whichever is easiest to achieve is fine by > > me. Does anyone have experience doing this kind of thing? > > > > -Mark > > > > > > > > -- > > Mark Wagner > > University of California San Diego > > Electrical and Computer Engineering > > > > > If you're using Gnu Radio, you can simply use the file sink, and have it > record to "/dev/null" most of the time, then have something (perhaps via >the XMLRPC built-in feature) change the filename to whatever your > desired filename is, and then revert it back to "/dev/null". > > I think I said the same thing on the discuss-gnuradio mailing list a few > days ago. > > The usrp-users mailing list isn't the best place to ask Gnu Radio > questions, a question like this, which is inherently radio-type > agnostic, probably >belongs on the discuss-gnuradio mailng list, because it's more about > "how do I make Gnu Radio dance". > > > > ___ > 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] Fwd: How to periodically write files using USRP and GNUradio
Hi Mark, If you look at gr-filerepeater (https://github.com/ghostop14/gr-filerepeater or from pybombs), I just recently added an advanced file sink to the module. One thing it has is a message port that you can pass a state key in the metadata to (1 to record, 0 to stop).The block will also automatically roll a timestamp into the filename when it starts a new file so it doesn't overwrite your historical ones. Give me a day or so and I'll add a new block to generate the message packets to do "x minutes on, y minutes off". I'll add it to the gr-filerepeater module. It's been on my list for a while anyway. On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote: > > Hey all, > > > > I'd like to know how to write short files of streamed USRP data > > periodically using GNUradio. For instance, I'd like the USRP to > > automatically record 5 seconds of data every 10 minutes. It does not > > matter to me whether the USRP is constantly on and most of the data is > > being discarded, or if the USRP wakes up every 10 minutes to record > > the data before sleeping. Whichever is easiest to achieve is fine by > > me. Does anyone have experience doing this kind of thing? > > > > -Mark > > > > > > > > -- > > Mark Wagner > > University of California San Diego > > Electrical and Computer Engineering > > > > > If you're using Gnu Radio, you can simply use the file sink, and have it > record to "/dev/null" most of the time, then have something (perhaps via >the XMLRPC built-in feature) change the filename to whatever your > desired filename is, and then revert it back to "/dev/null". > > I think I said the same thing on the discuss-gnuradio mailing list a few > days ago. > > The usrp-users mailing list isn't the best place to ask Gnu Radio > questions, a question like this, which is inherently radio-type > agnostic, probably >belongs on the discuss-gnuradio mailng list, because it's more about > "how do I make Gnu Radio dance". > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC On B210
I second RFNoC for the B series would be great. They're an incredibly popular and affordable series and I feel a little left out of the capabilities of RFNoC due to the Spartan6. Bringing the Artix to the B-series or supporting the Spartan6 could both be options I'd love to see. (Just a community vote :) ) On Thu, Jun 28, 2018 at 6:56 PM, Peter Sanchez via USRP-users < usrp-users@lists.ettus.com> wrote: > Thank you > > On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley wrote: > >> There is no conceptual reason why you can’t build an RFNoC design on >> B210, it uses the same USRP3 base architecture and FPGA source >> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all the >> implementation work for RFNoC is done using Xilinx’s Vivado design tools >> which support only the newer FPGA architectures like Zynq (Artix) and >> Kintex…Spartan6 users are stuck with ISE14 forever, so in practical terms, >> no, it’s not possible without you completely recreating all that >> infrastructure. >> >> -Ian >> >> > On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> > >> > Hi All, >> > Is it possible to generate RFNoC blocks for the B210? I can't find a >> lot of information about it. Can some one show me the URL if there is a >> website talking about it? >> > >> > Cheers >> > ___ >> > 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] USRP B-Series Issue with USB LTE Adapter Connected
I think I found the fix. On the USB2 bus, backing the USRP sample rate down from 8 MSPS to 7.4 MSPS made the issue go away. This is just speculation on my part, but even though there was no IP-based traffic to the LTE card, it was still communicating with the host (status, keepalive, something). The 8 MSPS rate was probably the max that the setup could handle and the added LTE USB communications was just enough to disrupt the USRP recv transfer. Backing the recv size down gave a little more bandwidth back to the bus to avoid the overrun. I wasn't running into it on the other systems since they had a more capable CPU and had USB3 buses. So this brings up a couple of questions... 1. When a stream recv is requested is it held in a memory buffer on the USRP such that the recv call retrieves it in bulk blocks? Or does it truly need to be processed by the recv loop within a fixed time window so the stream can continue to operate on the USRP (hence the overruns)? 2. I had adjusted the recv timeout from the default (0.1) to 0.2 to try to give it more time for the transfer but that hadn't helped. Given the scenario above what does that timeout actually adjust? I think I have my solution but any insights would be great. Thanks! On Mon, Jun 25, 2018 at 12:28 AM, Ian Buckley wrote: > Perhaps try 'sudo lsusb -v' with and without the LTE modem plugged in and > see if that reveals any more clues? > Does uhd_usrp_probe work when the LTE modem is plugged in? > > > On Jun 24, 2018, at 7:14 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > > On 06/24/2018 10:08 PM, GhostOp14 wrote: > > Hi Marcus, tried that too. No luck. Powered the USRP separately, then > tried powering the LTE separately. Same result. It's as if it can't read > block data on the USB bus when the LTE is connected. There's no data going > through the LTE so I'm not sure how that's possible. Especially since it > works fine as soon as I pull the LTE adapter out. > > Well, I'm going to go with "it's the LTE adapter". > > > > On Sun, Jun 24, 2018 at 5:24 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 06/24/2018 04:25 PM, GhostOp14 via USRP-users wrote: >> >>> Hi folks, >>> >>> I have a weird issue I've been attempting to troubleshoot for a bit and >>> I'm stuck. >>> >>> So setup: >>> USRP B205 connected to a Raspberry Pi 3 (so USB 2 mode) >>> Huawei E3372 USB LTE adapter connected as well >>> Running the latest Raspbian (stretch) >>> >>> Problem: >>> I'm using C++ code to read stream blocks from the device (800,000 >>> samples with the USRP set to 8 MSPS, so basically 1 ms of data). Without >>> the LTE it works fine, I get only infrequent overruns and the rest of the >>> logic works fine. As soon as the LTE is plugged in and the corresponding >>> ethernet interface is up, the recv call can't get a whole block of data >>> (recv returns 0 bytes). If I ifconfig down the interface or unplug the LTE >>> it goes back to working just fine. Plug it back in or ifconfig up the >>> interface, problem returns. Of note, there is another network connection >>> up on the wifi so the LTE is getting a lower priority in the routing table >>> and there isn't any data going across it (I confirmed it with the >>> statistics in ifconfig for that interface). >>> >>> So troubleshooting so far: >>> I'm running the latest UHD code (3.11.1 - Just git pulled the latest >>> today and rebuilt it). >>> Works fine on Ubuntu 16.04. No issues with both connected (so it's not >>> my code :)) >>> There doesn't appear to be any firmware updates to apply to the Huawei >>> (always worth a shot) >>> The huawei_cdc_ncm linux driver doesn't appear to have had any updates >>> in the past couple years (so doesn't look like a linux driver update) >>> Nothing showing up from dmesg or in /var/log/syslog or /var/log/messages >>> related to failed recv's. >>> Made sure there wasn't any data going over the LTE to rule out it's >>> doing large data transfers >>> I tested with other USB devices in place of the LTE. Works fine. So >>> not the port or a general USB issue. >>> I tried opening the device with num_recv_frames=1024 to see if that >>> would help, no luck. >>> I also tried increasing the timeout from the default 0.1 to 0.2 on the >>> recv call with no luck there either. >>> >>> Any suggestions? >>> >>> So, two thoughts: >> >> The rPi USB power supply isn't really up to the t
Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected
uhd_usrp_probe seems to come back fine. It sees the 205. I'm seeing it on another separate Pi with a different LTE adapter too so I think it rules out the instance of both I have being the culprit. I'll have some time tomorrow night to do some more debugging. I'll take a look at the lsusb output. I also have a B210 I can try and see if I get the same results. Do you know if the USB on the USRP uses bulk transfers and is there anything you're aware of in the USB spec that can interfere with them? I'll post my results after I give it a shot tomorrow. On Mon, Jun 25, 2018 at 12:28 AM, Ian Buckley wrote: > Perhaps try 'sudo lsusb -v' with and without the LTE modem plugged in and > see if that reveals any more clues? > Does uhd_usrp_probe work when the LTE modem is plugged in? > > > On Jun 24, 2018, at 7:14 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > > On 06/24/2018 10:08 PM, GhostOp14 wrote: > > Hi Marcus, tried that too. No luck. Powered the USRP separately, then > tried powering the LTE separately. Same result. It's as if it can't read > block data on the USB bus when the LTE is connected. There's no data going > through the LTE so I'm not sure how that's possible. Especially since it > works fine as soon as I pull the LTE adapter out. > > Well, I'm going to go with "it's the LTE adapter". > > > > On Sun, Jun 24, 2018 at 5:24 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 06/24/2018 04:25 PM, GhostOp14 via USRP-users wrote: >> >>> Hi folks, >>> >>> I have a weird issue I've been attempting to troubleshoot for a bit and >>> I'm stuck. >>> >>> So setup: >>> USRP B205 connected to a Raspberry Pi 3 (so USB 2 mode) >>> Huawei E3372 USB LTE adapter connected as well >>> Running the latest Raspbian (stretch) >>> >>> Problem: >>> I'm using C++ code to read stream blocks from the device (800,000 >>> samples with the USRP set to 8 MSPS, so basically 1 ms of data). Without >>> the LTE it works fine, I get only infrequent overruns and the rest of the >>> logic works fine. As soon as the LTE is plugged in and the corresponding >>> ethernet interface is up, the recv call can't get a whole block of data >>> (recv returns 0 bytes). If I ifconfig down the interface or unplug the LTE >>> it goes back to working just fine. Plug it back in or ifconfig up the >>> interface, problem returns. Of note, there is another network connection >>> up on the wifi so the LTE is getting a lower priority in the routing table >>> and there isn't any data going across it (I confirmed it with the >>> statistics in ifconfig for that interface). >>> >>> So troubleshooting so far: >>> I'm running the latest UHD code (3.11.1 - Just git pulled the latest >>> today and rebuilt it). >>> Works fine on Ubuntu 16.04. No issues with both connected (so it's not >>> my code :)) >>> There doesn't appear to be any firmware updates to apply to the Huawei >>> (always worth a shot) >>> The huawei_cdc_ncm linux driver doesn't appear to have had any updates >>> in the past couple years (so doesn't look like a linux driver update) >>> Nothing showing up from dmesg or in /var/log/syslog or /var/log/messages >>> related to failed recv's. >>> Made sure there wasn't any data going over the LTE to rule out it's >>> doing large data transfers >>> I tested with other USB devices in place of the LTE. Works fine. So >>> not the port or a general USB issue. >>> I tried opening the device with num_recv_frames=1024 to see if that >>> would help, no luck. >>> I also tried increasing the timeout from the default 0.1 to 0.2 on the >>> recv call with no luck there either. >>> >>> Any suggestions? >>> >>> So, two thoughts: >> >> The rPi USB power supply isn't really up to the task of supply >> spec-maximum power to each power. Perhaps your LTE device (combined with >> B205) is drawing too much power. >> >> The USB bus bandwidth is *per controller*, and perhaps there just isn't >> enough aggregate bandwidth left to service both devices. >> >> The B205 has no external-power input, as I recall, but it's mostly >> designed for USB3.0, where the per-port power is higher. >> You might try one of those "power booster" USB2.0 "Y" cables, and plug >> the "power only" plug into a 5.0V USB power supply. >> >> >> >> ___ >> 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] USRP B-Series Issue with USB LTE Adapter Connected
Hi folks, I have a weird issue I've been attempting to troubleshoot for a bit and I'm stuck. So setup: USRP B205 connected to a Raspberry Pi 3 (so USB 2 mode) Huawei E3372 USB LTE adapter connected as well Running the latest Raspbian (stretch) Problem: I'm using C++ code to read stream blocks from the device (800,000 samples with the USRP set to 8 MSPS, so basically 1 ms of data). Without the LTE it works fine, I get only infrequent overruns and the rest of the logic works fine. As soon as the LTE is plugged in and the corresponding ethernet interface is up, the recv call can't get a whole block of data (recv returns 0 bytes). If I ifconfig down the interface or unplug the LTE it goes back to working just fine. Plug it back in or ifconfig up the interface, problem returns. Of note, there is another network connection up on the wifi so the LTE is getting a lower priority in the routing table and there isn't any data going across it (I confirmed it with the statistics in ifconfig for that interface). So troubleshooting so far: I'm running the latest UHD code (3.11.1 - Just git pulled the latest today and rebuilt it). Works fine on Ubuntu 16.04. No issues with both connected (so it's not my code :)) There doesn't appear to be any firmware updates to apply to the Huawei (always worth a shot) The huawei_cdc_ncm linux driver doesn't appear to have had any updates in the past couple years (so doesn't look like a linux driver update) Nothing showing up from dmesg or in /var/log/syslog or /var/log/messages related to failed recv's. Made sure there wasn't any data going over the LTE to rule out it's doing large data transfers I tested with other USB devices in place of the LTE. Works fine. So not the port or a general USB issue. I tried opening the device with num_recv_frames=1024 to see if that would help, no luck. I also tried increasing the timeout from the default 0.1 to 0.2 on the recv call with no luck there either. Any suggestions? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
