Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Device address for USRP (Marcus D. Leech via USRP-users)
2. ERROR_CODE_BAD_PACKET after resuming a flowgraph
(Jared Dulmage via USRP-users)
3. Re: ERROR_CODE_BAD_PACKET after resuming a flowgraph
(Marcus D. Leech via USRP-users)
4. Re: USRP B200 "recv pacet demuxer unexpected sid"
(Michael West via USRP-users)
5. Re: Build USRP X310 FPGA code (Ben Hilburn via USRP-users)
6. Re: how to find the revision number of USRP N210
(tides anugraha via USRP-users)
7. Antenna connector type for USRP N210
(tides anugraha via USRP-users)
8. Re: Antenna connector type for USRP N210
(Marcus D. Leech via USRP-users)
9. (no subject) (asad umer via USRP-users)
10. Re: Device address for USRP (Martin Braun via USRP-users)
11. Re: ERROR_CODE_BAD_PACKET after resuming a flowgraph
(Martin Braun via USRP-users)
12. Sampling + Clock rates (Was: (no subject))
(Martin Braun via USRP-users)
13. Re: [Discuss-gnuradio] mytx.cpp (Martin Braun via USRP-users)
14. Re: (no subject) (Mike Jameson via USRP-users)
15. B210 channel assignment (Stefan Ereth via USRP-users)
16. Re: (no subject) (jason sam via USRP-users)
17. Re: (no subject) (Mike Jameson via USRP-users)
18. Re: [Discuss-gnuradio] Sample rate in GRC
(Mike Jameson via USRP-users)
19. HDSDR on USRP N210 installation failed
(tides anugraha via USRP-users)
20. Missing FPGA images on uhd_003.007.001-release_Win32
installer (Stefano Speretta via USRP-users)
21. Re: Missing FPGA images on uhd_003.007.001-release_Win32
installer (Mike Jameson via USRP-users)
22. Re: Missing FPGA images on uhd_003.007.001-release_Win32
installer (Stefano Speretta via USRP-users)
23. Re: Missing FPGA images on uhd_003.007.001-release_Win32
installer (Marcus D. Leech via USRP-users)
24. Re: Missing FPGA images on uhd_003.007.001-release_Win32
installer (Nicholas Corgan via USRP-users)
25. Can't get a signal from USRP B200 (Michal Jakubiak via USRP-users)
26. Re: Can't get a signal from USRP B200
(Marcus D. Leech via USRP-users)
27. Re: Missing FPGA images on uhd_003.007.001-release_Win32
installer (Nicholas Corgan via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Mon, 12 May 2014 14:18:05 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: asad umer <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Device address for USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 05/12/2014 02:05 PM, asad umer wrote:
> Yes u r right but if there is only one channel i am using then there
> are also 2 options:I can attach my antenna to either channel A or
> channel B...then it will automatically detect?
You're confusing "channels" and "antennas".
The B210 supports two channels, corresponding to subdevices A:A and A:B.
For the RX side of each of those subdevices, it can either use RX2 or
TX/RX as the place to attach the antenna. This is in support of the
ability to use half-duplex, where the antenna on the TX/RX port is
switched between the RX and TX halves of the corresponding channel.
If you're doing full-duplex, then configure the RX channel to attach to
the RX2 antenna port. The TX channel will *always* be on the RX/RX port.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 2
Date: Mon, 12 May 2014 11:33:32 -0700
From: Jared Dulmage via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] ERROR_CODE_BAD_PACKET after resuming a flowgraph
Message-ID:
<ofa4aab690.aa0b3591-on88257cd6.0065f28f-88257cd6.0065f...@notes.aero.org>
Content-Type: text/plain; charset=UTF-8
I'm using a USRP1 w/ UHD 3.005.003 through gnuradio 3.7.3 on windows 7 x64.?
All software compiled from source w/ MSVC 2010.
I have encountered an issue very similar to that in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-April/001061.html.
Using the C++ api, I create a flowgraph (starting with a usrp_source block) to
estimate the frequency offset of an received signal, stop the flowgraph, adjust
the RX center frequency of the usrp and then restart to measure the residual
offset.? Upon restarting the flowgraph I get a limitless list of errors:
UHD Error:
? The receive packet handler caught an exception.
? RuntimeError: usb rx6 transfer status: 3
UHD source block got error code 0xf
Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
There was no resolution (that I could find posted) to the issue reference
above.? I have confirmed the issue exists with Windows 7.
I appreciate any advice on resolving or further debugging this issue.
Jared.
------------------------------
Message: 3
Date: Mon, 12 May 2014 14:55:13 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ERROR_CODE_BAD_PACKET after resuming a
flowgraph
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 05/12/2014 02:33 PM, Jared Dulmage via USRP-users wrote:
> I'm using a USRP1 w/ UHD 3.005.003 through gnuradio 3.7.3 on windows 7 x64.
> All software compiled from source w/ MSVC 2010.
>
> I have encountered an issue very similar to that in
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-April/001061.html.
>
> Using the C++ api, I create a flowgraph (starting with a usrp_source block)
> to estimate the frequency offset of an received signal, stop the flowgraph,
> adjust the RX center frequency of the usrp and then restart to measure the
> residual offset. Upon restarting the flowgraph I get a limitless list of
> errors:
>
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 3
> UHD source block got error code 0xf
>
> Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
>
> There was no resolution (that I could find posted) to the issue reference
> above. I have confirmed the issue exists with Windows 7.
>
> I appreciate any advice on resolving or further debugging this issue.
>
> Jared.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
There's no need to stop the flow-graph just to change frequency. Just
assume that the first little bit after you change frequency is rubbish
and discard it.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 4
Date: Mon, 12 May 2014 13:35:16 -0700
From: Michael West via USRP-users <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200 "recv pacet demuxer unexpected
sid"
Message-ID:
<cam4xkrqwnyaup216luzjh4ykvyy3wf1meu72ccwj1fh9vy9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Mark,
To answer your initial question: The sid is the stream ID (contained in
the first 4 bytes of a data packet). The error is stating that a data
packet was received by UHD that had an unknown sid. There can be many
causes of the error, so I wouldn't be too quick to blame any one thing.
Thank you for the information already provided. Please tell us more about
the timing of the error and sequence of operations that is resulting in the
error. Is the error seen on the first run or only on subsequent runs? If
only on subsequent runs, how long do you wait between runs? Does it occur
if you unplug and replug the device between runs? Do you see it only after
executing certain commands/operations?
The more you can provide about the sequence of operations and timing, the
better chance we will have to reproduce the issue and help resolve it.
Best regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com
On Thu, May 8, 2014 at 5:01 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/08/2014 07:54 PM, Mark Cottrell via USRP-users wrote:
>
> On Fri, May 9, 2014 at 11:46 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 05/08/2014 07:39 PM, Mark Cottrell via USRP-users wrote:
>>
>>>
>>> Are you running up-to-date UHD and matching firmware? What OS? What
>>> controller?
>>>
>>> We have seen it in Ubuntu 13.10 running UHD_003.007.000-1-stable and
>>> Debian jessie running UHD_003.007.001-14-g1d2e8d39. Both of the PCs have
>>> Intel motherboards, with the following USB controllers:
>>> Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host
>>> Controller (on the Ubuntu 13.10 machine)
>>> Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host
>>> Controller (on the Debian Jessie machine)
>>>
>>> The ubuntu machine has uhd installed from repos, so I would expect the
>>> firmware to be up-to-date. The firmware on the debian machine was
>>> installed using uhd_images_downloader.
>>>
>>> Thanks,
>>> Mark
>>>
>>> Thanks. Sorry for more questions, but:
>>
>> What sample rates were you using?
>>
>
> 240KHz, with master_clock_rate=30720000, using the default complex
> float32 datatype
>
>
>> Were there any other devices on the same controller port that might have
>> been consuming USB bandwidth?
>>
>
> just a microsoft keyboard and mouse
>
>
>> Were you using the as-supplied cable, or a different one?
>>
>
> we're using the supplied USB3 cable
>
>
>>
>> If you use an external power supply (do you have one?) on the B200, does
>> the problem persist or get better?
>>
>
> we were powering it off the bus, but have now connected an external
> power supply to see if there is any improvement
>
>
>>
>> Just trying to get some notion of the "shape" of the problem.
>>
>>
>>
>> Thanks again for taking the time to provide the data.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140512/8c93a60f/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 12 May 2014 13:39:24 -0700
From: Ben Hilburn via USRP-users <[email protected]>
To: Luong Tan Phong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Build USRP X310 FPGA code
Message-ID:
<caoevzk+azdkawg5rghysnebq+deayn48asrg_s2kch5ye+o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Luong -
I notice that you are using the older versions of the FPGA and host code.
Try downloading the latest UHD (which is 3.7.1+), and the newest images.
Also, please try using the images we provide to see if the errors persist
in the official images, too.
Cheers,
Ben
On Sat, May 10, 2014 at 12:54 AM, Luong Tan Phong via USRP-users <
[email protected]> wrote:
> Hi list,
>
> I've builded USRP X310 FPGA code (downloaded on github at Apr-15-2014)
> with HGS configure by Xilinx ISE 14.7 on Ubuntu to create
> usrp_x310_fpga_HGS.bit file and burn it to USRP X310.
> After that, I can't run my application with X310 by error:
>
> *linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.000-123-g87b068ed*
>
> *Using Volk machine: avx_32_mmx_orc*
>
> *-- X300 initialization sequence...*
>
> *-- Determining maximum frame size... 1472 bytes.*
>
> *-- Setup basic communication...*
>
> *-- Loading values from EEPROM...*
>
> *-- Setup RF frontend clocking...*
>
> *-- Radio 1x clock:200*
>
> *-- Detecting internal GPSDO.... Found an internal GPSDO*
>
> *-- Initialize Radio control...*
>
> *-- Performing register loopback test... pass*
>
> *-- Sync DAC's.*
>
> *-- Performing register loopback test... pass*
>
> *-- Sync DAC's.*
>
> *-- Initializing clock and PPS references...*
>
> *Traceback (most recent call last):*
>
> * File "/home/ktd/top_block.py", line 101, in <module>*
>
> * tb = top_block()*
>
> * File "/home/ktd/top_block.py", line 58, in __init__*
>
> * channels=range(1),*
>
> * File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor*
>
> * return old_constructor(*args)*
>
> * File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 1765, in make*
>
> * return _uhd_swig.usrp_source_make(*args)*
>
> *RuntimeError: RuntimeError: The gpsdo PPS was not detected. Please check
> the PPS source and try again.*
>
> My application is OK with usrp_x310_fpga_HGS.bit file downloaded from
> http://files.ettus.com/binaries/maint_images/archive/uhd-images_003.007.000-70-gfcc85c95.zip
> Could you help me to fix it, please?
>
> Best regards,
>
> LTP
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140512/fd1a5659/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 13 May 2014 09:49:30 +0700
From: tides anugraha via USRP-users <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] how to find the revision number of USRP N210
Message-ID:
<CA+a=GO4Kg6hmDOFTH4P=w1LptR9sxT6ge=bjzb-yw4wloff...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the information,
The problem already solved, by running uhd_usrp_probe command in windows
command prompt. It shows the version of USRP: N210r4.
Regards,
Tides
On Mon, May 12, 2014 at 10:07 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/12/2014 11:02 AM, Mike Jameson via USRP-users wrote:
>
> The revision number should be on the N210 motherboard which can be
> accessed by unscrewing and sliding off the N210's outer shell.
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Email: [email protected]
> Web: http://scanoo.com
>
>
> On Mon, May 12, 2014 at 8:48 AM, tides anugraha via USRP-users <
> [email protected]> wrote:
>
>> Hi All,
>>
>> I'm very new to USRP, i'm trying to setup HDSDR using USRP N210. And
>> refer to:
>> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#use-the-net-burner-tool,
>> it is stated that "Determine the revision number from the sticker on the
>> rear of the chassis. Use this number to select the correct FPGA image for
>> your device."
>>
>> In which part of the stickers i can find the revision number
>> information? because there is 4 column available: M/N, P/N, S/N, & MAC. And
>> none of that column give the information regarding the revision number of
>> USRP N210.
>>
>> Can anyone help?
>>
>> Thanks & Best Regards
>>
>> Tides
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Also, if the N210 was purchased new in the last couple of years, it's
> overwhelmingly like to be a Rev4 board.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/f01dee49/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 13 May 2014 09:55:53 +0700
From: tides anugraha via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] Antenna connector type for USRP N210
Message-ID:
<CA+a=go6rktmvnoxaqfaintmd8co4fsqto_p1v0abc4xjk1t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I'm doing a research on OpenBTS using USRP N210. In order to extend the
coverage of OpenBTS, i want to modify the external antenna for USRP N210.
Can anyone tell me the type of connector for USRP N210? Right now i'm using
VERT900 antenna provided by ettus.
Thanks & Best Regards,
Tides
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/ce02459e/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 12 May 2014 22:58:41 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Antenna connector type for USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 05/12/2014 10:55 PM, tides anugraha via USRP-users wrote:
> Hi All,
>
> I'm doing a research on OpenBTS using USRP N210. In order to extend
> the coverage of OpenBTS, i want to modify the external antenna for
> USRP N210.
>
> Can anyone tell me the type of connector for USRP N210? Right now i'm
> using VERT900 antenna provided by ettus.
>
> Thanks & Best Regards,
>
> Tides
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Standard "normal" SMA connectors.
Many WiFi antenna use RP-SMA. Don't use those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140512/7a0ec11a/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 13 May 2014 12:45:01 +0500
From: asad umer via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] (no subject)
Message-ID:
<CAEhLvxTpRhdK2XW_j2sTR7jPKF1CLU69Zanw-nmwF-F2P=d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What is the range of sample rate for B210??I knew it to be 5-61.44MHz,but
when i gave the rate of 50MHz i got the following warning in GRC:
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 50.000000 MSps
Actual sample rate: 32.000000 MSps
OOOOOOOOOOOOOOOOOOOOOOOOOOOOO
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/fe726559/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 13 May 2014 09:53:26 +0200
From: Martin Braun via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Device address for USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12.05.2014 20:18, Marcus D. Leech via USRP-users wrote:
> On 05/12/2014 02:05 PM, asad umer wrote:
>> Yes u r right but if there is only one channel i am using then there
>> are also 2 options:I can attach my antenna to either channel A or
>> channel B...then it will automatically detect?
> You're confusing "channels" and "antennas".
>
> The B210 supports two channels, corresponding to subdevices A:A and A:B.
>
> For the RX side of each of those subdevices, it can either use RX2 or
> TX/RX as the place to attach the antenna. This is in support of the
> ability to use half-duplex, where the antenna on the TX/RX port is
> switched between the RX and TX halves of the corresponding channel.
>
> If you're doing full-duplex, then configure the RX channel to attach to
> the RX2 antenna port. The TX channel will *always* be on the RX/RX port.
Before there's any nitpicking, Marcus meant the TX/RX port (or "antenna
name").
Martin
------------------------------
Message: 11
Date: Tue, 13 May 2014 09:56:58 +0200
From: Martin Braun via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ERROR_CODE_BAD_PACKET after resuming a
flowgraph
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 12.05.2014 20:33, Jared Dulmage via USRP-users wrote:
> Using the C++ api, I create a flowgraph (starting with a usrp_source
> block) to estimate the frequency offset of an received signal, stop
> the flowgraph, adjust the RX center frequency of the usrp and then
> restart to measure the residual offset. Upon restarting the
> flowgraph I get a limitless list of errors:
>
> UHD Error: The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 3 UHD source block got error
> code 0xf
>
> Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
>
> There was no resolution (that I could find posted) to the issue
> reference above. I have confirmed the issue exists with Windows 7.
>
> I appreciate any advice on resolving or further debugging this
> issue.
Hi Jared,
a couple of questions:
- Is there are reason to use 3.5.3? If you use a more recent version, do
things become more stable?
- When you say you stop and restart the flow graph, do you actually do a
start(), stop(), wait(), start() on the same flow graph object?
Thanks!
Martin
------------------------------
Message: 12
Date: Tue, 13 May 2014 09:59:56 +0200
From: Martin Braun via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] Sampling + Clock rates (Was: (no subject))
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 13.05.2014 09:45, asad umer via USRP-users wrote:
> What is the range of sample rate for B210??I knew it to be
> 5-61.44MHz,but when i gave the rate of 50MHz i got the following
> warning in GRC:
Right now, if you want to sample at 50 Msps, you need to set the clock
as well, e.g.:
$ benchmark_rate --args master_clock_rate=50e6 --tx_rate 50e6
This will only work across USB3.
Martin
------------------------------
Message: 13
Date: Tue, 13 May 2014 10:02:57 +0200
From: Martin Braun via USRP-users <[email protected]>
To: [email protected], "'[email protected]'"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] mytx.cpp
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 13.05.2014 09:35, ??? wrote:
> Hello all
> I write a c++ document mytx.cpp and i place it into the
> uhd/host/build/examples.And then what should i do to let it run?Should i
> type the "make" command in the shell or do other things?Thank you.
> Best regards,
> Xianda
You don't have to put it in examples, but you can use the CMakeLists.txt
file in this directory to figure out how to set up a build environment.
The usual flow of cmake, make will compile your program then.
Martin
------------------------------
Message: 14
Date: Tue, 13 May 2014 09:50:09 +0100
From: Mike Jameson via USRP-users <[email protected]>
To: asad umer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] (no subject)
Message-ID:
<CAJcjmiSkaEJSTBV9XaUoXGx4kGb0==tqollroq1mfldbsnz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The sample rate must be within the limits of your USB speed.
Try the following from
http://files.ettus.com/uhd_docs/manual/html/usrp_b200.html:
uhd_usrp_probe --args="master_clock_rate=50e6"
Also:
uhd_fft --args="master_clock_rate=50e6" --samp-rate=1e6
Mike
On Tue, May 13, 2014 at 8:45 AM, asad umer via USRP-users <
[email protected]> wrote:
> What is the range of sample rate for B210??I knew it to be 5-61.44MHz,but
> when i gave the rate of 50MHz i got the following warning in GRC:
>
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 50.000000 MSps
> Actual sample rate: 32.000000 MSps
> OOOOOOOOOOOOOOOOOOOOOOOOOOOOO
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/6fd95ad6/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 13 May 2014 11:03:56 +0200
From: Stefan Ereth via USRP-users <[email protected]>
To: <[email protected]>
Subject: [USRP-users] B210 channel assignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all,
I try to capture samples of both channels from a B210 and save them in separate
files. The Problem is that the channel assignment is different after retuning.
I connected a signal generator to channel 1 and let channel 2 open. Normally
the file "measure0" should always contain my signal and "measure1" noise. But
out of 20 times the signal is 17 times in "measure0" and 3 times in "measure1".
I appreciate any advice on resolving or further debugging this issue.
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi.cpp
Type: application/octet-stream
Size: 13957 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/2e15e850/attachment-0001.cpp>
------------------------------
Message: 16
Date: Tue, 13 May 2014 14:07:34 +0500
From: jason sam via USRP-users <[email protected]>
To: Mike Jameson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] (no subject)
Message-ID:
<CAEhLvxQ74zT4Ytcmh-YzNQpj+sEhvuEoAXDTxqV5JE=+rm3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
After changing the clock rate..it is still giving the same error?What clock
source should be selected in parameters?
On Tue, May 13, 2014 at 1:50 PM, Mike Jameson <[email protected]>wrote:
> The sample rate must be within the limits of your USB speed.
>
> Try the following from
> http://files.ettus.com/uhd_docs/manual/html/usrp_b200.html:
>
> uhd_usrp_probe --args="master_clock_rate=50e6"
>
> Also:
>
> uhd_fft --args="master_clock_rate=50e6" --samp-rate=1e6
>
> Mike
>
> On Tue, May 13, 2014 at 8:45 AM, asad umer via USRP-users <
> [email protected]> wrote:
>
>> What is the range of sample rate for B210??I knew it to be 5-61.44MHz,but
>> when i gave the rate of 50MHz i got the following warning in GRC:
>>
>> UHD Warning:
>> The hardware does not support the requested RX sample rate:
>> Target sample rate: 50.000000 MSps
>> Actual sample rate: 32.000000 MSps
>> OOOOOOOOOOOOOOOOOOOOOOOOOOOOO
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/677a0f06/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 13 May 2014 10:14:20 +0100
From: Mike Jameson via USRP-users <[email protected]>
To: jason sam <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] (no subject)
Message-ID:
<cajcjmisq1backpg3qsyd_ctvewsa-uk65zsykh2efzb9-af...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Assuming you are talking about GRC, in the 'UHD source' block look for the
'Device Addr' box and insert "master_clock_rate=
50e6"
The clock source can be left as default unless you are using an external
10MHz reference input into the B210.
Mike
On Tue, May 13, 2014 at 10:07 AM, jason sam via USRP-users <
[email protected]> wrote:
> After changing the clock rate..it is still giving the same error?What
> clock source should be selected in parameters?
>
>
> On Tue, May 13, 2014 at 1:50 PM, Mike Jameson <[email protected]>wrote:
>
>> The sample rate must be within the limits of your USB speed.
>>
>> Try the following from
>> http://files.ettus.com/uhd_docs/manual/html/usrp_b200.html:
>>
>> uhd_usrp_probe --args="master_clock_rate=50e6"
>>
>> Also:
>>
>> uhd_fft --args="master_clock_rate=50e6" --samp-rate=1e6
>>
>> Mike
>>
>> On Tue, May 13, 2014 at 8:45 AM, asad umer via USRP-users <
>> [email protected]> wrote:
>>
>>> What is the range of sample rate for B210??I knew it to be
>>> 5-61.44MHz,but when i gave the rate of 50MHz i got the following warning in
>>> GRC:
>>>
>>> UHD Warning:
>>> The hardware does not support the requested RX sample rate:
>>> Target sample rate: 50.000000 MSps
>>> Actual sample rate: 32.000000 MSps
>>> OOOOOOOOOOOOOOOOOOOOOOOOOOOOO
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/c1124aa3/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 13 May 2014 10:21:30 +0100
From: Mike Jameson via USRP-users <[email protected]>
To: jason sam <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Sample rate in GRC
Message-ID:
<CAH2kTJ5WEd7X5QYV=cQpMb9G3DbAomp6d9ggOk7SADejaPR=k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The "channel bandwidth" setting can be left at "0" which sets it
automatically.
Mike
--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: [email protected]
Web: http://ettus.com
On Tue, May 13, 2014 at 10:11 AM, jason sam <[email protected]> wrote:
> What about the channel bandwidth?
>
>
> On Tue, May 13, 2014 at 2:09 PM, Mike Jameson <[email protected]>wrote:
>
>> If you want 1e6 Hz (1MHz) of receive bandwidth at a center frequency of
>> 2.4e9 Hz (2.4GHz) then you just set the center frequency to 2.4e9 and
>> sample rate to 1e6 in the UHD source block in GRC.
>>
>> Mike
>>
>> On Tue, May 13, 2014 at 10:04 AM, jason sam <[email protected]> wrote:
>>
>>> I am confused about the sample rate in GRC...if i am RXing a signal by
>>> USRP B210 at 2.4 GHz then the sample rate should be 4.8GHz??But USRP B210
>>> uses a direct conversion RX and shifts the signal to 0Hz,so what should be
>>> the criteria for setting the sample rate?
>>> Another option could be ton set it double the channel
>>> bandwidth??i.e.(56*2)MHz
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/be767df1/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 13 May 2014 16:55:59 +0700
From: tides anugraha via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] HDSDR on USRP N210 installation failed
Message-ID:
<CA+a=go7al-gwlzrfkp5mck+_nxzdajyz_wz27op1dao9k-3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Is there anyone who had experience installing HDSDR with USRP N210, i had a
problem when installing ExtIO_USRP+FCD + BorIP-1.1.1_Setup.
When it comes to the Zadig install driver windows, and click the options
menu & select list all devices i don't see my USRP N210 in the list.
When i choose to select one of the interface in the list, suddenly my usb
mouse stop working normally, it seems that i choose the wrong interface &
when i execute HDSDR it shows error message:
Can anyone suggest how to resolve this issue?
p.s : i have already run uhd_find_devices.exe & uhd_usrp_probe.exe in
windows command prompt & work normally, & i also successfully update the
firmware.
Thanks & Best Regards
Tides
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/39518783/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 13 May 2014 14:30:38 +0200
From: Stefano Speretta via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Missing FPGA images on
uhd_003.007.001-release_Win32 installer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello all,
I tried today to install UHD on a Windows 32 bit machine and just
noticed that the FPGA images are not present (and neither you can select
to install them on the installer application). They are simply not
present in the installer while they are there in the 64-bit version (the
installer size is also ~5Mb compared to ~23 Mb of the 64-bit version).
Regards,
Stefano
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: [email protected]
Web: www.isispace.nl
------------------------------
Message: 21
Date: Tue, 13 May 2014 13:33:52 +0100
From: Mike Jameson via USRP-users <[email protected]>
To: Stefano Speretta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Missing FPGA images on
uhd_003.007.001-release_Win32 installer
Message-ID:
<CAJcjmiR2etp82T-Fb7QCyGCZnzYiSc_NPRVnNe+k=ou8tfo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You have to run the uhd_images_downloader.py script:
http://files.ettus.com/uhd_docs/manual/html/images.html#uhd-images-downloader
Mike
--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: [email protected]
Web: http://ettus.com
On Tue, May 13, 2014 at 1:30 PM, Stefano Speretta via USRP-users <
[email protected]> wrote:
> Hello all,
> I tried today to install UHD on a Windows 32 bit machine and just noticed
> that the FPGA images are not present (and neither you can select to install
> them on the installer application). They are simply not present in the
> installer while they are there in the 64-bit version (the installer size is
> also ~5Mb compared to ~23 Mb of the 64-bit version).
>
> Regards,
> Stefano
>
> --
> Stefano Speretta
> ISIS - Innovative Solutions In Space BV
> Molengraaffsingel 12-14
> 2629 JD Delft
> The Netherlands
>
> Phone: +31(0)15 256 9018
> Fax: +31(0)15 257 3969
> E-mail: [email protected]
> Web: www.isispace.nl
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/d7bf18f8/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 13 May 2014 14:56:34 +0200
From: Stefano Speretta via USRP-users <[email protected]>
To: Mike Jameson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Missing FPGA images on
uhd_003.007.001-release_Win32 installer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
but then why they are only present in the Windows x64 bit version installer?
I am trying to figure out which should be the "standard" way and I see
the installer for the Windows x86 and x64 version being different (one
having images and the other not having them).
All Linux packages were requiring the user to run the python script you
mentioned but this has never been the case for Windows. Will this be the
case in the future?
Stefano
On 5/13/2014 14:33, Mike Jameson wrote:
> You have to run the uhd_images_downloader.py script:
>
> http://files.ettus.com/uhd_docs/manual/html/images.html#uhd-images-downloader
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Ettus Research Technical Support
> Email: [email protected] <mailto:[email protected]>
> Web: http://ettus.com
>
>
> On Tue, May 13, 2014 at 1:30 PM, Stefano Speretta via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello all,
> I tried today to install UHD on a Windows 32 bit machine and just
> noticed that the FPGA images are not present (and neither you can
> select to install them on the installer application). They are
> simply not present in the installer while they are there in the
> 64-bit version (the installer size is also ~5Mb compared to ~23 Mb
> of the 64-bit version).
>
> Regards,
> Stefano
>
> --
> Stefano Speretta
> ISIS - Innovative Solutions In Space BV
> Molengraaffsingel 12-14
> 2629 JD Delft
> The Netherlands
>
> Phone: +31(0)15 256 9018
> Fax: +31(0)15 257 3969
> E-mail: [email protected] <mailto:[email protected]>
> Web: www.isispace.nl <http://www.isispace.nl>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: [email protected]
Web: www.isispace.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/8ac136b5/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 13 May 2014 09:31:40 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Missing FPGA images on
uhd_003.007.001-release_Win32 installer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/13/2014 08:56 AM, Stefano Speretta via USRP-users wrote:
> but then why they are only present in the Windows x64 bit version
> installer?
> I am trying to figure out which should be the "standard" way and I see
> the installer for the Windows x86 and x64 version being different (one
> having images and the other not having them).
> All Linux packages were requiring the user to run the python script
> you mentioned but this has never been the case for Windows. Will this
> be the case in the future?
>
>
> Stefano
I believe that, going forward, the standard approach will be to require
the use of the downloader. But perhaps Nick, who packages these, will
add his two cents when the folks from California show up in a couple
of hours.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/f7837e74/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 13 May 2014 07:22:31 -0700
From: Nicholas Corgan via USRP-users <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Stefano Speretta
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Missing FPGA images on
uhd_003.007.001-release_Win32 installer
Message-ID:
<CAGCyN2MA59aUn7+Qi=oq1azuhdstmfgbcoyfhkyw1t5jx+v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It looks like there was a hiccup in our packaging system.
Thanks for pointing this out, it will be remedied shortly.
On Tue, May 13, 2014 at 6:31 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/13/2014 08:56 AM, Stefano Speretta via USRP-users wrote:
>
> but then why they are only present in the Windows x64 bit version
> installer?
> I am trying to figure out which should be the "standard" way and I see the
> installer for the Windows x86 and x64 version being different (one having
> images and the other not having them).
> All Linux packages were requiring the user to run the python script you
> mentioned but this has never been the case for Windows. Will this be the
> case in the future?
>
>
> Stefano
>
> I believe that, going forward, the standard approach will be to require
> the use of the downloader. But perhaps Nick, who packages these, will
> add his two cents when the folks from California show up in a couple of
> hours.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Nicholas Corgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/6ba52d46/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 13 May 2014 18:14:28 +0300
From: Michal Jakubiak via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] Can't get a signal from USRP B200
Message-ID:
<CADjeeEe=upC02j-_pLh_g+o=hkLED--_+nvOgGNi=NLiw=b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I got my hands on my 1st USRP (it's a B200) and wanted to pick up some
radio waves today, but no cigar. I used the uhd_fft.grc example from
gnuradio. The only thing I changed was removing the IP address from the
source block.
Unfortunately I can't get any signal out of it. The spectrum I see has no
peaks and doesn't change when I remove the antenna. On top of that, the
example works only for a little while before crashing.
Here's GRC's output:
<<< Welcome to GNU Radio Companion 3.7.3 >>>
Loading: "/home/mehow/uhd_fft.grc"
>>> Done
Showing: "/home/mehow/uhd_fft.grc"
Generating: "/home/mehow/uhd_fft.py"
Executing: "/home/mehow/uhd_fft.py"
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-36-g9ed3becc
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32 MHz
-- Actually got clock rate 32 MHz
-- Performing timer loopback test... pass
Using Volk machine: avx_64_mmx_orc
Exception in thread Thread-7:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/mehow/uhd_fft.py", line 192, in _chan0_lo_locked_probe
val = self.uhd_usrp_source_0.get_sensor('lo_locked')
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3016, in get_sensor
return _uhd_swig.usrp_source_sptr_get_sensor(self, *args, **kwargs)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/dboards/A/rx_frontends/A/sensors/lo_locked
UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: usb rx8 transfer status: 5
Form: <class 'gnuradio.wxgui.forms.forms.text_box'> ->
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xError translating value: "2424050000.0"
EnvironmentError: IOError: Failed to read AD9361 (-4: LIBUSB_ERROR_CODE
-4)
Enter a float with optional scale suffix. E.g., 100.1Mf
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf
###############
## This error is repeated MANY times.
###############
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf
terminate called after throwing an instance of 'uhd::runtime_error'
what(): RuntimeError: usb tx4 submit failed: LIBUSB_ERROR_NO_DEVICE
>>> Done
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/01a82bc2/attachment-0001.html>
------------------------------
Message: 26
Date: Tue, 13 May 2014 11:25:41 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Can't get a signal from USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/13/2014 11:14 AM, Michal Jakubiak via USRP-users wrote:
> I got my hands on my 1st USRP (it's a B200) and wanted to pick up some
> radio waves today, but no cigar. I used the uhd_fft.grc example from
> gnuradio. The only thing I changed was removing the IP address from
> the source block.
> Unfortunately I can't get any signal out of it. The spectrum I see has
> no peaks and doesn't change when I remove the antenna. On top of that,
> the example works only for a little while before crashing.
>
> Here's GRC's output:
>
> <<< Welcome to GNU Radio Companion 3.7.3>>>
>
> Loading: "/home/mehow/uhd_fft.grc"
> >>> Done
>
> Showing: "/home/mehow/uhd_fft.grc"
>
> Generating: "/home/mehow/uhd_fft.py"
>
> Executing: "/home/mehow/uhd_fft.py"
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-36-g9ed3becc
>
> -- Operating over USB 3.
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 32 MHz
> -- Actually got clock rate 32 MHz
> -- Performing timer loopback test... pass
> Using Volk machine: avx_64_mmx_orc
> Exception in thread Thread-7:
> Traceback (most recent call last):
> File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
> self.run()
> File "/usr/lib/python2.7/threading.py", line 763, in run
> self.__target(*self.__args, **self.__kwargs)
> File "/home/mehow/uhd_fft.py", line 192, in _chan0_lo_locked_probe
> val = self.uhd_usrp_source_0.get_sensor('lo_locked')
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3016, in get_sensor
> return _uhd_swig.usrp_source_sptr_get_sensor(self, *args, **kwargs)
> RuntimeError: LookupError: Path not found in tree:
> /mboards/0/dboards/A/rx_frontends/A/sensors/lo_locked
>
>
> UHD Error:
> An unexpected exception was caught in a task loop.
> The task loop will now exit, things may not work.
> RuntimeError: usb rx8 transfer status: 5
> Form:<class 'gnuradio.wxgui.forms.forms.text_box'> ->
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 5
> UHD source block got error code 0xf
>
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 5
> UHD source block got error code 0xError translating value: "2424050000.0"
> EnvironmentError: IOError: Failed to read AD9361 (-4: LIBUSB_ERROR_CODE
> -4)
> Enter a float with optional scale suffix. E.g., 100.1Mf
>
>
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 5
> UHD source block got error code 0xf
>
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 5
> UHD source block got error code 0xf
>
>
> ###############
> ## This error is repeated MANY times.
> ###############
>
>
>
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 5
> UHD source block got error code 0xf
> terminate called after throwing an instance of 'uhd::runtime_error'
> what(): RuntimeError: usb tx4 submit failed: LIBUSB_ERROR_NO_DEVICE
>
> >>> Done
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
What happens when you use just uhd_fft -- that should be installed under
/usr/local/bin
uhd_fft -a type=b200 -s 2.0e6 -g 50 -f <your-frequency-here>
Also, what type of USB-3.0 controller do you have?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/de6c4dd7/attachment-0001.html>
------------------------------
Message: 27
Date: Tue, 13 May 2014 08:34:09 -0700
From: Nicholas Corgan via USRP-users <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Missing FPGA images on
uhd_003.007.001-release_Win32 installer
Message-ID:
<CAGCyN2N75UO_rMkwxtSvwh=s5pvjdznc-f6-zvzudz90cfj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This issue should be fixed now.
On Tue, May 13, 2014 at 7:22 AM, Nicholas Corgan <[email protected]>wrote:
> It looks like there was a hiccup in our packaging system.
>
> Thanks for pointing this out, it will be remedied shortly.
>
>
> On Tue, May 13, 2014 at 6:31 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 05/13/2014 08:56 AM, Stefano Speretta via USRP-users wrote:
>>
>> but then why they are only present in the Windows x64 bit version
>> installer?
>> I am trying to figure out which should be the "standard" way and I see
>> the installer for the Windows x86 and x64 version being different (one
>> having images and the other not having them).
>> All Linux packages were requiring the user to run the python script you
>> mentioned but this has never been the case for Windows. Will this be the
>> case in the future?
>>
>>
>> Stefano
>>
>> I believe that, going forward, the standard approach will be to require
>> the use of the downloader. But perhaps Nick, who packages these, will
>> add his two cents when the folks from California show up in a couple of
>> hours.
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> Nicholas Corgan
>
--
Nicholas Corgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140513/320af1c9/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 45, Issue 12
******************************************
