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: Bandwidth of USRP N210's low pass filter (Jeon)
2. Re: Bandwidth of USRP N210's low pass filter (Marcus M?ller)
3. How do I modify the xml files in the x310? (Swanson, Craig)
4. build environment (Mark Napier)
5. Windows uhd_find_devices (Mark Napier)
6. Changing center frequency automatically (Haile Berhe)
7. Re: Windows uhd_find_devices (Marcus D. Leech)
8. Re: Windows uhd_find_devices (Mark Napier)
9. Re: build environment (Marcus M?ller)
10. Re: External Reference (Ian Buckley)
11. Re: gr-scan & usrp (rv pellarin)
12. Re: gr-scan & usrp (Marcus M?ller)
13. Re: gr-scan & usrp (rv pellarin)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 May 2016 01:55:06 +0900
From: Jeon <[email protected]>
To: USRP users mailing list <[email protected]>
Subject: Re: [USRP-users] Bandwidth of USRP N210's low pass filter
Message-ID:
<CACfn7v7goArr=zbewlrzupacuifo2eit17dw-lq5y1p6m3h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus and all USRP users,
Thanks for your detailed answer.
> So, to get a 1MHz wide piece of spectrum, you just set the sampling rate
to 1MS/s. The filtering necessary to give you that bandwidth, alias-free,
is done in the FPGA automatically.
So, to summarize, bandwidth of a signal that I can obtain is limited by a
sampling rate value of USRP source block?
My question seems to be lengthy and tedious, but I think that one sentence
is very short and clear.
And I am really sorry for referencing that ruby forum things.
I'll check every reference when posting a thread since now.
Regards,
Jeon.
2016-05-27 20:30 GMT+09:00 Marcus M?ller <[email protected]>:
> Hi Jeon:
>
> first off: please don't cite ruby-forum.com. It's a rip-off of the GNU
> Radio mailing list archive[1], made to look like and act like a forum. The
> truth is, however, that answers posted on that forum don't reach the GNU
> Radio mailing list, and hence will not be answered. That's why we're trying
> to actively ignore that website to oblivion :)
> So, your article can also be found at [2], your picture at [3], just for
> future readers.
>
> Picture [2] doesn't show an important aspect however: It neglects where
> the boundary between motherboard and daughterboar is. I added a beige
> background behind everything on the daughterboard so it's clearer:
>
>
> So, I don't really 100% know where that picture originated from, but it
> mixes USRP architecture with the implementation of a specific
> daughterboard. Not all daughterboards have 20MHz I/Q filters (=40MHz
> complex baseband), not all daughterboards have that
> LNA/attenuator/LNA/Drive Amp architecture, it's not even that back in 2013,
> all daughterboards that were in heavy use and recommended for new designs
> would be full duplex!
>
> So this might really not be the picture of choice to understand how a USRP
> works internally.
>
> So:
> > If so, is it guaranteed that I can see a 20 MHz-band-limited signal
> through LabView or GNU Radio?
>
> No, this depends on the daughterboard you use (and of course on the
> sampling rate you request, as Nyquist dictates).
>
> > In addition, that band-limiting value 20 MHz, can it be changed to a
> more wider value,
>
> The question whether the baseband filter is adjustable depends on the
> daughterboard. However, there's no Ettus daughterboard with a 20MHz
> adjustable filter in existence.
>
> Also, you generally don't have to do that! The interpolators/decimators in
> the FPGA have correct, adjustable, opaque-as-possible digital filters that
> reduce your signal's bandwidth to what you ask for as sampling rate. So, to
> get a 1MHz wide piece of spectrum, you just set the sampling rate to 1MS/s.
> The filtering necessary to give you that bandwidth, alias-free, is done in
> the FPGA automatically.
>
> > e.g., 40 or 80 MHz via software-level configuration?
>
> Definitely not, not even with hardware modifications. That would break
> functionality.
> The I and Q bandwidths sum up to be the complex baseband bandwidth; if you
> used 80 MHz as filter bandwidth, you'd need to sample the I and Q branch
> with 160MS/s each ? and the N210's ADC runs at 100MS/s.
>
> Is it possible you have a specific problem you're trying to solve? Could
> you explain that problem?
>
>
> Best regards,
> Marcus
> [1] http://lists.gnu.org/archive/html/discuss-gnuradio/
> [2]
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00006.html
> [3]
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/pngrQSlnNrAs8.png
>
>
>
>
> On 27.05.2016 13:01, Jeon via USRP-users wrote:
>
> Dear USRP users,
>
> According to [this article](https://www.ruby-forum.com/topic/4416797) and
> [this image](https://www.ruby-forum.com/attachment/8707/usrp_arch.png),
> does the second generation USRP (e.g., N210) have a low pass filter with
> bandwith of 20 MHz on a receiving chain?
>
> If so, is it guaranteed that I can see a 20 MHz-band-limited signal
> through LabView or GNU Radio?
>
> In addition, that band-limiting value 20 MHz, can it be changed to a more
> wider value, e.g., 40 or 80 MHz via software-level configuration?
>
> Regards,
> Jeon.
>
>
> _______________________________________________
> USRP-users mailing
> [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/20160529/430f4518/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen2 arch.png
Type: image/png
Size: 15670 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/430f4518/attachment-0001.png>
------------------------------
Message: 2
Date: Sat, 28 May 2016 19:01:23 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Bandwidth of USRP N210's low pass filter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Jeon,
> So, to summarize, bandwidth of a signal that I can obtain is limited
> by a sampling rate value of USRP source block?
Well, the bandwidth is min(f_sample, analog baseband filter bandwidth) ,
not accounting for some filter rolloff. For example, a few older
daughterboards have less than 2x 20MHz filters.
> And I am really sorry for referencing that ruby forum things.
Ah, don't worry! Don't be sorry! I really just wanted to explain why I'm
not using your links, but the ones I looked up from the mailing list
archive :) You've done nothing wrong!
Best regards,
Marcus
------------------------------
Message: 3
Date: Sat, 28 May 2016 18:27:06 +0000
From: "Swanson, Craig" <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: Martin Braun <[email protected]>, Jonathon Pendlum
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [USRP-users] How do I modify the xml files in the x310?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Marcus,
Since I started about a year ago with understanding and using RFNoC, I have
been only using the E310.
Now I am starting to use the X310, and I have three questions.
1. ??I successfully executed the command
uhd_image_loader --args="type=x300,addr=192.168.10.2"
--fpga-path="~/uhd/fpga-src/usrp3/top/x300/build/usrp_x310_rfnoc_fpga_HGS.bit".
But when I execute uhd_usrp_probe --args="addr=192.168.10.2" --init-only? I
get a segmentation fault. That is because I changed the NOC_ID. How do I
update the X310 with my latest .xml files? I am assuming I need to copy over
the .xml files to the X310 from my Home/gr-ettus/grc directory.
2.
When I start using the JTAG Chipscope Xilinx USB cable, I am assuming I have to
make sure my /lib/udev/rules.d/40-uhd-host.rules has a line for the X310.
Where do I get this information?
3.
When executing a flowgraph, is the X310 more like the E310 or the B210? In
other words, do I need to have a Device3 with a Device Address: type=x300?
That is like the E310. For the usrp source and sink, do I need to have a
Device Address with the ethernet address?
Is there a location in the user's manual that addresses these questions for the
X310?
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160528/ec61fc2c/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 28 May 2016 10:57:49 -0400
From: Mark Napier <[email protected]>
To: [email protected]
Subject: [USRP-users] build environment
Message-ID:
<cafs2mbepsodfnfrmflqyonv-fty3lc4jdcvaqkbkj0rhe84...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm an experienced DSP/ASIC guy but a newbie to gnuradio. I've had a USRP1
for years now but anytime I've wanted to do anything real with it I've be
stymied by software stack.
So now I'm working at a company where we are digging into SDR and I have my
hands on a lot of Ettus hardware. The software stack is still a problem.
On my own I've tried to get a working build environment up on my macbook
pro and have given up on that for now. My current effort is trying to use
pybombs to get a VMWare image of Ubuntu 16.04 working and the guys at Ettus
have been helping me. At work we are trying to do something similar with
Windows 10.
Well after all this I have a more basic question for the experienced
developers here. What is your recipe? What OS (version specific), what
exact tools, how do you get your build environment up and running quickly
so that you can do something useful?
Thanks in advance,
Mark Napier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160528/049b4eb7/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 28 May 2016 14:54:44 -0400
From: Mark Napier <[email protected]>
To: [email protected]
Subject: [USRP-users] Windows uhd_find_devices
Message-ID:
<CAFS2mBd+1aq1jWNjLUsFQRPyVAFO=byu9doyqdfkrojvuck...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Have installed the v3.7.9.2/v1.1.1
<http://www.gcndevelopment.com/gnuradio/downloads/installers/v1.1.1/gnuradio_3.7.9.2_win64.msi>
version
"64-Bit Any CPU" on my work Dell Laptop running Windows 7 64-bit from:
http://www.gcndevelopment.com/gnuradio/downloads.htm
Installation seemed to go well.
However I've tried my USRP1 and a B205 with uhd_usrp_probe and
uhd_find_devices. I've tried --args "type=usrp1" b200, b210, b205 and
anything else I can think of from the GNUradio command prompt. Rebooted
the machine. No joy.
Any suggestions?
Thanks in advance,
Mark Napier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160528/5d3fcd48/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 28 May 2016 16:11:09 +0300
From: Haile Berhe <[email protected]>
To: [email protected]
Subject: [USRP-users] Changing center frequency automatically
Message-ID:
<CAHr+hkEWGkPVZK=SV=NYut7NYgoSEqjHvAFnjQbKfMOA3=0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I have been making researches using USRP and GNU radio for a couple of
months now. Today, I have a reached a point where I have no clue how to do
it. I want to change the center frequency of USRP N200 and so that I can
transmit in multiple frequencies simultaneously. There are some suggestions
from some USRP users on the net but none of them happen to be helpful.
Here is the problem in short:
I want to transmit some a signal in the frequency ranges of 200MHz, 500MHz
and 1.3GHz for certain purpose. I could not sum all these frequencies
(using ADD block) and transmit them on a single center frequency as they
are far away from each other. Any suggestions, please?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160528/3f8588cb/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 28 May 2016 16:27:54 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Windows uhd_find_devices
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/28/2016 02:54 PM, Mark Napier via USRP-users wrote:
> Hello,
>
> Have installed the v3.7.9.2/v1.1.1
> <http://www.gcndevelopment.com/gnuradio/downloads/installers/v1.1.1/gnuradio_3.7.9.2_win64.msi>
> version
> "64-Bit Any CPU" on my work Dell Laptop running Windows 7 64-bit from:
>
> http://www.gcndevelopment.com/gnuradio/downloads.htm
>
> Installation seemed to go well.
>
> However I've tried my USRP1 and a B205 with uhd_usrp_probe and
> uhd_find_devices. I've tried --args "type=usrp1" b200, b210, b205
> and anything else I can think of from the GNUradio command prompt.
> Rebooted the machine. No joy.
>
> Any suggestions?
>
> Thanks in advance,
>
> Mark Napier
>
>
Could you perhaps provide more details on error messages you received?
Also, I'll note that the minimum UHD version for B205 is v3.7.9.4.
Installers for the latest UHD release are available here:
http://files.ettus.com/manual/page_install.html#install_win_installer
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160528/d8da7e42/attachment-0001.html>
------------------------------
Message: 8
Date: Sat, 28 May 2016 17:00:19 -0400
From: Mark Napier <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Windows uhd_find_devices
Message-ID:
<CAFS2mBcZp1rfzqZB-j7vno2kEp05Baq=wm4s32pl5a4zsef...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Marcus,
Didn't see the "post installation" procedures. Have loaded the USB driver
and the device manager sees the B205mini.
Have GRC running with the B205 dumping into a waterfall device and looking
that the local FM radio station.
Thanks,
Mark
On Sat, May 28, 2016 at 4:27 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/28/2016 02:54 PM, Mark Napier via USRP-users wrote:
>
> Hello,
>
> Have installed the v3.7.9.2/v1.1.1
> <http://www.gcndevelopment.com/gnuradio/downloads/installers/v1.1.1/gnuradio_3.7.9.2_win64.msi>
> version
> "64-Bit Any CPU" on my work Dell Laptop running Windows 7 64-bit from:
>
> http://www.gcndevelopment.com/gnuradio/downloads.htm
>
> Installation seemed to go well.
>
> However I've tried my USRP1 and a B205 with uhd_usrp_probe and
> uhd_find_devices. I've tried --args "type=usrp1" b200, b210, b205 and
> anything else I can think of from the GNUradio command prompt. Rebooted
> the machine. No joy.
>
> Any suggestions?
>
> Thanks in advance,
>
> Mark Napier
>
>
> Could you perhaps provide more details on error messages you received?
>
> Also, I'll note that the minimum UHD version for B205 is v3.7.9.4.
> Installers for the latest UHD release are available here:
>
> http://files.ettus.com/manual/page_install.html#install_win_installer
>
>
>
> _______________________________________________
> 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/20160528/60280ec7/attachment-0001.html>
------------------------------
Message: 9
Date: Sat, 28 May 2016 23:19:04 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] build environment
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Mark,
so, the Ettus folks are mostly Linux and OS X. I think the same goes for
the majority of the GNU Radio community? there's now a great effort to
make GR work well again under Windows, but I think we can still call
that work in progress.
When it comes to Linux, I think it's a happy mixture of Ubuntu, Fedora,
Arch (probably?), CentOS/RedHat.
Now, freshly, Ubuntu 16.04 + pybombs works pretty neatly nowadays to
give you a flexible from-source installation of the libraries, tools,
and specific GNU Radio out-of-tree modules (i.e. GNU Radio blocks and
GNU Radio applications that are not part of the main GNU Radio source).
So that's what I'd really recommend to give you fresh install. The
beauty of pybombs is that you can have as many installation prefixes as
you want ? say you want to try something that might horribly break your
bleeding edge GNU Radio half of the day, then do some work with a
specific version of UHD, GNU Radio and other half ? and lets you just
select what you need flexibly.
Myself, I'm using Fedora, just out of preference for its system
management tools. Pybombs works on that as well.
So much for what I'd recommend in platforms.
Regarding getting stuff done fast: Well... you're a DSP person, so
you'll possibly agree it's about finding the right balance between math
(because, well, if you can't describe your signals and systems, you
might not get as far), system design (the classical "let's assume these
receivers are all synchronized" vs real world as well as things like
knowing when you want to decimate), and some accumulation of experience
by just trying, especially when the latter can be pretty quick.
That's why, though many GNU Radio and UHD users don't like overly
graphical tools to do their development, often a very GNU Radio
Companion-centric approach is a good idea, not only because it's quick,
but mostly because it's self-documenting, the generated source code is
still readable (and runs without any speed degradation) and it's easy to
document and communicate (and, having a shoddy memory myself, easy to
re-understand) what you did just this morning if you actually have a
flow graph that looks like a directed graph.
You're not alone with your problem of "OK, I've got a USRP, and some
software frameworks, but what now?"; but especially for those who
haven't been doing SDR for a long time, the realization that just
connecting a USRP source to a Qt GUI Waterfall sink does something
/useful/ is a nice thing, and they get to develop their SDR applications
relatively rapidly, as they have instant access to a relatively nice
library of blocks ? whether you want an FFT of arbitrary size, a single
interpolating low pass FIR, or a whole decimating polyphase filterbank.
There's timing recovery and equalizers, Schmitt triggers and whatnot.
So: starting with the GNU Radio companion is definitely a thing worth
doing. You can definitely go pretty far with it, and its ability to
structure things (by putting "subgraphs" into hierarchical blocks, for
example) doesn't even imply that the complexity of your system will
become at one point de facto impossible to handle.
If your demands for a specific block outgrow what can be done by
combining the functionality provided, but you know the DSP behind what
you want to do, it's actually not that hard to write your own GNU Radio
block in C++ or Python. As a matter of fact, GNU Radio has a "daughter
project", the VOLK (Vector-Optimized Library of Kernels) project, which
just contains just C (and occasionally, a bit of different
machine-specific assembler/intrinsics) implementations of typical DSP
basics ? think of the dot product, magnitude squared, trigonometrics,
endianness swaps, interleavers, those kinds of things, so pretty often
you start of by writing a GNU Radio block and then figure out that you
just need to pair-wise multiply a series of complexes, and just go and
use the appropriate VOLK kernel, and get an instant speedup of up to
"pretty much", depending on what hardware you're running on.
So: Really, get your hands dirty. A Ubuntu installation should not take
long, and getting, and using pybombs, to get a running GNU Radio
experimental setup should also be a matter of minutes (on a fast
workstation, considering that by default, GNU Radio and UHD are built
from source, and the rest as far as possible is installed from your
Ubuntu's package repositories automatically). The Guided Tutorials might
not be overly demanding from you in terms of DSP, but they are a pretty
quick way to get started.
Have fun,
Marcus
On 28.05.2016 16:57, Mark Napier via USRP-users wrote:
> Hello,
>
> I'm an experienced DSP/ASIC guy but a newbie to gnuradio. I've had a
> USRP1 for years now but anytime I've wanted to do anything real with
> it I've be stymied by software stack.
>
> So now I'm working at a company where we are digging into SDR and I
> have my hands on a lot of Ettus hardware. The software stack is still
> a problem. On my own I've tried to get a working build environment up
> on my macbook pro and have given up on that for now. My current
> effort is trying to use pybombs to get a VMWare image of Ubuntu 16.04
> working and the guys at Ettus have been helping me. At work we are
> trying to do something similar with Windows 10.
>
> Well after all this I have a more basic question for the experienced
> developers here. What is your recipe? What OS (version specific),
> what exact tools, how do you get your build environment up and running
> quickly so that you can do something useful?
>
> Thanks in advance,
>
> Mark Napier
>
>
>
> _______________________________________________
> 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/20160528/1056c3f9/attachment-0001.html>
------------------------------
Message: 10
Date: Sat, 28 May 2016 22:03:53 -0700
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] External Reference
Message-ID:
<cam_0ocesanh0uscso8t1rvkcwxh3+pe687gvuifdqta3-pt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
...so in default mode, the USRP decides there is no local GPDSO and selects
the on board 10MHz TCXO to discipline the 100MHz TCXO via the AD9510.
Likely in external mode the AD9510 doesn't see your external 10MHz due to
the circuit damage and as a result applies a bias to the TUNE pin of the
100MHz TCXO.
On Fri, May 27, 2016 at 1:33 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/27/2016 04:28 PM, Eric C. via USRP-users wrote:
>
> Yes, that seems to match what I'm seeing. But if I select "default" then
> what happens? I'm getting much better frequency results by selecting
> "default."
>
> Also, I nearly always get the E light to come on, whether I choose
> External or Default. Sometimes it only stays on when I'm receiving data,
> but it almost always is on. Should the E LED be on if I've selected
> "external" but a signal isn't coming in, due to damage?
>
>
> -- Eric C.
>
> Default on N210 means, AFAIR, "GSPDO if there is one, else internal".
>
>
>
>
> On Fri, May 27, 2016 at 2:23 PM, Nick Foster <[email protected]> wrote:
>
>> If you select "external reference" but no clock is available due to
>> damage, the 100MHz master oscillator is free-running, which seems to fit
>> your observations.
>>
>> On Fri, May 27, 2016, 1:16 PM Eric C. <[email protected]> wrote:
>>
>>> Thanks for the input. It was a little hard getting to it but I measured
>>> the resistance on D503 and it was just 50 ohms. So I think I fried that. I
>>> also put a scope at R505 and I didn't see the 10 MHz signal. I verified the
>>> signal was coming in using the proper pin on J510. Looks like my 4V peak to
>>> peak reference clock did some damage. Ugh, this is a bad day. I thought
>>> carefully about the powers input to the receiver but for some reason
>>> totally forgot to check on the strength of the reference clock. (I didn't
>>> follow your procedure yet on checking the other components, I'm not sure we
>>> have all the equipment to do that).
>>>
>>> So I take it that means it's just using the internal oscillator? I also
>>> have a GPS DO that isn't hooked up, but looking at the schematic and board
>>> it looks like that signal comes in in front of the damaged components
>>> anyway, so I'm hosed with that too, right? Plus, we were wanting to use the
>>> same reference for the signal generator and the USRP.
>>>
>>> Does ettus do repairs? I guess I'd have to determine if the cost of that
>>> is worth it to the company.
>>>
>>>
>>> -- Eric C.
>>>
>>> On Fri, May 27, 2016 at 12:17 PM, Nick Foster via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Just get 10MHz at +15dBm into the clock input and see if you see a
>>>> reasonable clock waveform at the output of R535 on a 'scope.
>>>>
>>>> On Fri, May 27, 2016 at 11:08 AM Marcus M?ller <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> 1W (30dBm) are indeed a bit much for the input circuitry. Let's look
>>>>> at this:
>>>>> 1W means an U_eff of about 7V (considering the input impedance for
>>>>> 10MHz should pretty much be 50 Ohm, and [image: $P = \frac{U^2}R
>>>>> \implies U = \sqrt{PR}$]).
>>>>> The two leads "exiting" to the right reach a clock multiplexer [1]
>>>>> which is spec'ed for a maximum input voltage of 3.3V with the supply we
>>>>> drive it.
>>>>>
>>>>>
>>>>>
>>>>> Now, to not exceed that, we have D503 [2] in place, which is
>>>>> basically meant to suppress things > 12V as TVS diode. Check that diode,
>>>>> simply by using a multimeter on the 10MHz ref input (remove all power from
>>>>> the USRP before!). It should show the typical "resistance increase" of any
>>>>> capacitor measured with DC: starting low, than getting progressively
>>>>> higher, reaching some Megaohm value at the end. You might not see that
>>>>> "starting low" moment.
>>>>>
>>>>> Now, 12V > 3.3V, and that's why D501, a bog-normal BAV99T, with a
>>>>> forward voltage of about 1.0V under "normal" circumstances (ie. current
>>>>> limited to 50mA). I think you might have fried that. That one is a bit
>>>>> harder to test, especially since I don't want to damage the clock
>>>>> multiplexer in the process. Hm. A test method for this would be locate
>>>>> R535
>>>>> and R536 on the motherboard, and measure the DC resistance of
>>>>> R535?transformer coil of T501?R536; you can't do that with a single
>>>>> multimeter. You'll need to make a I/U curve for input voltages from -0.7 ?
>>>>> 0V ... 0.7V and see whether you can see a offset "diode" typical behaviour
>>>>> in the current. Make very sure not to touch your voltage source to places
>>>>> that shouldn't get 0.7V. If you don't see that, D501 or the semiconductors
>>>>> in the input stage of the clock plexer are probably damaged.
>>>>>
>>>>> So, in case the diode is damaged, you can try replacing it. Please
>>>>> only do that if you have enough experience with SMD rework ? more often
>>>>> than necessary, people use to much heat with too much air flow in a hot
>>>>> air
>>>>> gun and blow away half of a board's components.
>>>>>
>>>>> If you chose not to try to replace D501, or the input stage is indeed
>>>>> damaged, you could also still use another N2xx and a MIMO cable. I'll not
>>>>> advertise this too much, since no-one tested it, but it's possible you can
>>>>> set the clock source to "mimo", get a Serial-attached-SCSI cable (which
>>>>> has
>>>>> a MIMO-cable-compatible connector), hack it off, find the right pins that
>>>>> connect to what's A8 / A9 in J707 of our N2xx schematic [3, p. 5],
>>>>>
>>>>> At any rate, if you have further problems, or questions,
>>>>> [email protected] is there for you!
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>>
>>>>> [1] U18, SY89545L
>>>>> [2] Semtech uClamp1211P
>>>>> [3] http://files.ettus.com/schematics/n200/n2xx.pdf
>>>>>
>>>>> On 27.05.2016 17:36, Eric C. via USRP-users wrote:
>>>>>
>>>>> I have an N210 that I'm using with a WBX daughter card. In my lab at
>>>>> work we have a high quality 10 MHz reference that I'm inputting to the
>>>>> USRP. I think initially I had it hooked up at too high of a power. But
>>>>> I've
>>>>> since added attenuators and it's at about 11 dBm, comfortably below the 15
>>>>> dB limit (that I should have looked up first).
>>>>>
>>>>> I'm using gnuradio companion and the USRP source block has the time
>>>>> reference set up as external. When I run in this mode, I'm getting quite
>>>>> wrong frequency results (18 kHz off on a signal in the 400 MHz range). But
>>>>> the E light is a steady green while I'm collecting (sometimes it turns off
>>>>> when I'm not receiving though, sometimes it stays on). When I run the
>>>>> uhd_fft application, or change my application to not set the source to
>>>>> external, the results are visibly better. I can't tell how accurate they
>>>>> are, but at least on the sale of observing the spectra they look centered
>>>>> more appropriately.
>>>>>
>>>>> Does that mean I'm using the internal oscillator? Is there something
>>>>> I'm doing wrong? Did I fry the external LO input when I had too high of a
>>>>> signal connected (I think it was just over 30 dBm)?
>>>>>
>>>>> -- Eric C.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing
>>>>> [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
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
>
> _______________________________________________
> 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/20160528/c4126463/attachment-0001.html>
------------------------------
Message: 11
Date: Sun, 29 May 2016 11:18:10 +0200
From: rv pellarin <[email protected]>
To: Patrick Sathyanathan <[email protected]>
Cc: Chris Kuethe <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<cahlh5kejvt-tu3opm6jsqdjfmfl_ihu8fs+xwjtbeoqlrta...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi patrick,
i got it working on kali, but few things remain.
what is the antenna argument to use in order to use the tx/rx antenna?
couldn t find any tips in -h
how do you create an output file, same as before, no tips in -h
thxx for your help!
best rgeards
herve
?
On 25 May 2016 at 10:50, Patrick Sathyanathan <[email protected]> wrote:
> You can try using usrp_spectrum_sense. It is also a scanner between
> specified frequency limits that has a text output, and you can specify a
> threshold level (squelch).
>
> --Patrick
>
> ------------------------------
> Date: Tue, 24 May 2016 08:00:05 +0200
> To: [email protected]
> Subject: Re: [USRP-users] gr-scan & usrp
> From: [email protected]
> CC: [email protected]
>
> hi chris,
>
> i am using it on windows,mostyly, but when it agree to connect on linux vm
> lsusb sees it
>
> using (on winblows) uhd_usrp_probe gives me this result:
>
> C:\WINDOWS\system32>uhd_usrp_probe
> Win32; Microsoft Visual C++ version 12.0; Boost_105600;
> UHD_003.009.002-release
>
> -- Detected Device: B205mini
> -- Loading FPGA image: C:\Program Files
> (x86)\UHD\share\uhd\images\usrp_b205mini_fpga.bin... done
> -- Operating over USB 3.
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 16.000000 MHz...
> -- Actually got clock rate 16.000000 MHz.
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> _____________________________________________________
> /
> | Device: B-Series Device
> | _____________________________________________________
> | /
> | | Mboard: B205mini
> | | revision: 1
> | | product: 30522
> | | serial: 30C7E1D
> | | name: B205i
> | | FW Version: 8.0
> | | FPGA Version: 4.0
> | |
> | | Time sources: none, internal, external
> | | Clock sources: internal, external
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | | Freq range: -8.000 to 8.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: A
> | | | | Name: FE-RX1
> | | | | Antennas: TX/RX, RX2
> | | | | Sensors: temp, rssi, lo_locked
> | | | | Freq range: 50.000 to 6000.000 MHz
> | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
> | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: B205mini RX dual ADC
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -8.000 to 8.000 MHz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: A
> | | | | Name: FE-TX1
> | | | | Antennas: TX/RX
> | | | | Sensors: temp, lo_locked
> | | | | Freq range: 50.000 to 6000.000 MHz
> | | | | Gain range PGA: 0.0 to 89.8 step 0.3 dB
> | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: B205mini TX dual DAC
> | | | | Gain Elements: None
>
>
>
>
>
> i am also able to use it with gqrx and gnuradio without any issues
>
> best regards
> ?
>
> On 23 May 2016 at 21:38, Chris Kuethe <[email protected]> wrote:
>
> OK, that's a better request. This tells us exactly what software you're
> running and gives a very strong indication of where to start debugging.
>
> "FATAL: No supported devices found to pick from."
>
> Here are some things that you can investigate
> 1) do you see the device with lsusb?
> 2) do you see the device with uhd_usrp_probe?
> 3) does this program work with any other receivers (rtlsdr)?
> 4) can you use your receiver with osmocom_fft?
> 5) can you use your receiver with uhd_fft?
>
>
> On Mon, May 23, 2016 at 11:56 AM, rv pellarin <[email protected]> wrote:
>
> hi,
> sorry again for my post, didn t mean to offense you, was busy with kids
> and work, i should have wait before post.
> so here is the soft:
> https://github.com/pinkavaj/gr-scan
>
> got no error when compile, and when i run it, this is what i get as error
> message.
> root@kali:~/Documents/gr-scan/gr-scan-master# ./gr-scan -x 150 -y 175
> linux; GNU C++ version 5.3.1 20160409; Boost_105800;
> UHD_003.009.003-0-unknown
>
> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy redpitaya
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>
> FATAL: No supported devices found to pick from.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
> Using Volk machine: avx_64_mmx_orc
> gr::buffer::allocate_buffer: warning: tried to allocate
> 4 items of size 16000. Due to alignment requirements
> 32 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 16 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 8 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 8 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> ^C
> root@kali:~/Documents/gr-scan/gr-scan-master#
>
>
>
> if you have any clues how to fix it, would be great, seems to be a nice
> prog.
> one thing i ve noticed, they show an example on their website with -o
> filename.csv but in real, this option is not any longer available, pitty,
> was handy
>
>
> thxx for your time, and again, my apologies.
> best regards
>
> herve
>
> On 23 May 2016 at 14:17, Chris Kuethe <[email protected]> wrote:
>
> And rather than posting errors as screenshots (images), either copy the
> text either into an email or stick it on something like pastebin
>
> On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller <
> [email protected]> wrote:
>
> From where did you get your gr-scan? Again, Google points me to multiple
> projects with that name. Which exactly is the one you are talking about?
>
> Also, as I said, you need to be *descriptive*.
> "A lot of errors" helps no-one at helping you. Please apply some more
> effort in reporting problems.
>
> BR,
> Marcus
>
>
> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin <[email protected]>:
>
> hi marcus,
> gr-scan is a linux executable that allow to perform quic radio scan, for
> example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150 &
> 175 mhz and show result.
> unfortunately it see the usrp device but gives lots off error and fail to
> scan.
> idealy i m looking for a solution with my usr that scan and log
> automaticaly, that s why i asked you if some of you succeed to get this
> utility working :)
> thxx for your time marcus.
> best rgeards
> herve
> ?
>
> On 23 May 2016 at 18:53, Marcus M?ller <[email protected]> wrote:
>
> Hi RV,
>
> I like your straightforward attitude, but:
>
> This sounds like you've tried something, and it failed.
> You should definitely describe your problems in greater detail, otherwise
> it'll be hard for people to help you.
> For example, there's several projects out there that are called gr-scan.
> Most of them haven't been updated/maintained in years. Which one are you
> referring to?
>
> What are you trying to do?
>
> Generally, I'd like to encourage you to increase the descriptiveness of
> your mailing list posts; that'll make it much easier to help you fast :)
>
> Best regards,
> Marcus
>
>
> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>
> hi guys,
> have some of you succeed using gr-scan with an usrp device?
> best regards
> ?
>
>
> _______________________________________________
> USRP-users mailing
> [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
>
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
>
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
>
>
> _______________________________________________ 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/20160529/072a616d/attachment-0001.html>
------------------------------
Message: 12
Date: Sun, 29 May 2016 11:52:06 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> how do you create an output file, same as before, no tips in -h
usrp_spectrum_sense does not create an output file.
Really, it /is/ just an /example/. If you want to fulfill a specific
application's needs, you will have to get your hands dirty at designing
your own application.
> what is the antenna argument to use in order to use the tx/rx antenna?
> couldn t find any tips in -h
um... emphasis by me:
./usrp_spectrum_sense.py --help
linux; GNU C++ version 5.3.1 20151207 (Red Hat 5.3.1-2); Boost_105700;
UHD_003.010.git-202-g9e0861e1
Warning: this may have issues on some machines+Python version combinations to
seg fault due to the callback in bin_statitics.
Usage: usrp_spectrum_sense.py [options] min_freq max_freq
Options:
-h, --help show this help message and exit
-a ARGS, --args=ARGS UHD device device address args [default=]
--spec=SPEC Subdevice of UHD device where appropriate
*-A ANTENNA, --antenna=ANTENNA****select Rx Antenna where appropriate*
-s SAMP_RATE, --samp-rate=SAMP_RATE
set sample rate [default=1000000.0]
-g GAIN, --gain=GAIN set gain in dB (default is midpoint)
--tune-delay=SECS time to delay (in seconds) after changing frequency
[default=0.25]
--dwell-delay=SECS time to dwell (in seconds) at a given frequency
[default=0.25]
-b Hz, --channel-bandwidth=Hz
channel bandwidth of fft bins in Hz [default=6250.0]
-l Hz, --lo-offset=Hz
lo_offset in Hz [default=0]
-q dB, --squelch-threshold=dB
squelch threshold in dB [default=none]
-F FFT_SIZE, --fft-size=FFT_SIZE
specify number of FFT bins
[default=samp_rate/channel_bw]
--real-time Attempt to enable real-time scheduling
so, you use it with
-A TX/RX
Best regards,
Marcus
On 29.05.2016 11:18, rv pellarin via USRP-users wrote:
> hi patrick,
> i got it working on kali, but few things remain.
> what is the antenna argument to use in order to use the tx/rx antenna?
> couldn t find any tips in -h
> how do you create an output file, same as before, no tips in -h
> thxx for your help!
> best rgeards
> herve
> ?
>
> On 25 May 2016 at 10:50, Patrick Sathyanathan <[email protected]
> <mailto:[email protected]>> wrote:
>
> You can try using usrp_spectrum_sense. It is also a scanner
> between specified frequency limits that has a text output, and you
> can specify a threshold level (squelch).
>
> --Patrick
>
> ------------------------------------------------------------------------
> Date: Tue, 24 May 2016 08:00:05 +0200
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [USRP-users] gr-scan & usrp
> From: [email protected] <mailto:[email protected]>
> CC: [email protected] <mailto:[email protected]>
>
> hi chris,
>
> i am using it on windows,mostyly, but when it agree to connect on
> linux vm lsusb sees it
>
> using (on winblows) uhd_usrp_probe gives me this result:
>
> C:\WINDOWS\system32>uhd_usrp_probe
> Win32; Microsoft Visual C++ version 12.0; Boost_105600;
> UHD_003.009.002-release
>
> -- Detected Device: B205mini
> -- Loading FPGA image: C:\Program Files
> (x86)\UHD\share\uhd\images\usrp_b205mini_fpga.bin... done
> -- Operating over USB 3.
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 16.000000 MHz...
> -- Actually got clock rate 16.000000 MHz.
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> _____________________________________________________
> /
> | Device: B-Series Device
> | _____________________________________________________
> | /
> | | Mboard: B205mini
> | | revision: 1
> | | product: 30522
> | | serial: 30C7E1D
> | | name: B205i
> | | FW Version: 8.0
> | | FPGA Version: 4.0
> | |
> | | Time sources: none, internal, external
> | | Clock sources: internal, external
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | | Freq range: -8.000 to 8.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: A
> | | | | Name: FE-RX1
> | | | | Antennas: TX/RX, RX2
> | | | | Sensors: temp, rssi, lo_locked
> | | | | Freq range: 50.000 to 6000.000 MHz
> | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
> | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: B205mini RX dual ADC
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -8.000 to 8.000 MHz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: A
> | | | | Name: FE-TX1
> | | | | Antennas: TX/RX
> | | | | Sensors: temp, lo_locked
> | | | | Freq range: 50.000 to 6000.000 MHz
> | | | | Gain range PGA: 0.0 to 89.8 step 0.3 dB
> | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: B205mini TX dual DAC
> | | | | Gain Elements: None
>
>
>
>
>
> i am also able to use it with gqrx and gnuradio without any issues
>
> best regards
> ?
>
> On 23 May 2016 at 21:38, Chris Kuethe <[email protected]
> <mailto:[email protected]>> wrote:
>
> OK, that's a better request. This tells us exactly what
> software you're running and gives a very strong indication of
> where to start debugging.
>
> "FATAL: No supported devices found to pick from."
>
> Here are some things that you can investigate
> 1) do you see the device with lsusb?
> 2) do you see the device with uhd_usrp_probe?
> 3) does this program work with any other receivers (rtlsdr)?
> 4) can you use your receiver with osmocom_fft?
> 5) can you use your receiver with uhd_fft?
>
>
> On Mon, May 23, 2016 at 11:56 AM, rv pellarin
> <[email protected] <mailto:[email protected]>> wrote:
>
> hi,
> sorry again for my post, didn t mean to offense you, was
> busy with kids and work, i should have wait before post.
> so here is the soft:
> https://github.com/pinkavaj/gr-scan
>
> got no error when compile, and when i run it, this is what
> i get as error message.
> root@kali:~/Documents/gr-scan/gr-scan-master# ./gr-scan -x
> 150 -y 175
> linux; GNU C++ version 5.3.1 20160409; Boost_105800;
> UHD_003.009.003-0-unknown
>
> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd
> miri hackrf bladerf rfspace airspy redpitaya
> -- Loading firmware image:
> /usr/share/uhd/images/usrp_b200_fw.hex...
>
> FATAL: No supported devices found to pick from.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
> Using Volk machine: avx_64_mmx_orc
> gr::buffer::allocate_buffer: warning: tried to allocate
> 4 items of size 16000. Due to alignment requirements
> 32 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 16 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 8 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 8 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> ^C
> root@kali:~/Documents/gr-scan/gr-scan-master#
>
>
>
> if you have any clues how to fix it, would be great, seems
> to be a nice prog.
> one thing i ve noticed, they show an example on their
> website with -o filename.csv but in real, this option is
> not any longer available, pitty, was handy
>
>
> thxx for your time, and again, my apologies.
> best regards
>
> herve
>
> On 23 May 2016 at 14:17, Chris Kuethe
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> And rather than posting errors as screenshots
> (images), either copy the text either into an email or
> stick it on something like pastebin
>
> On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> From where did you get your gr-scan? Again, Google
> points me to multiple projects with that name.
> Which exactly is the one you are talking about?
>
> Also, as I said, you need to be *descriptive*.
> "A lot of errors" helps no-one at helping you.
> Please apply some more effort in reporting problems.
>
> BR,
> Marcus
>
>
> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin
> <[email protected] <mailto:[email protected]>>:
>
> hi marcus,
> gr-scan is a linux executable that allow to
> perform quic radio scan, for example ./gr-scan
> -x 150 -y 175 , that ll automaticly scan
> between 150 & 175 mhz and show result.
> unfortunately it see the usrp device but gives
> lots off error and fail to scan.
> idealy i m looking for a solution with my usr
> that scan and log automaticaly, that s why i
> asked you if some of you succeed to get this
> utility working :)
> thxx for your time marcus.
> best rgeards
> herve
> ?
>
> On 23 May 2016 at 18:53, Marcus M?ller
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi RV,
>
> I like your straightforward attitude, but:
>
> This sounds like you've tried something,
> and it failed.
> You should definitely describe your
> problems in greater detail, otherwise
> it'll be hard for people to help you.
> For example, there's several projects out
> there that are called gr-scan. Most of
> them haven't been updated/maintained in
> years. Which one are you referring to?
>
> What are you trying to do?
>
> Generally, I'd like to encourage you to
> increase the descriptiveness of your
> mailing list posts; that'll make it much
> easier to help you fast :)
>
> Best regards,
> Marcus
>
>
> On 05/23/2016 06:29 PM, rv pellarin via
> USRP-users wrote:
>
> hi guys,
> have some of you succeed using gr-scan
> with an usrp device?
> best regards
> ?
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> --
> Sent from my Android device with K-9 Mail. Please
> excuse my brevity.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
>
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
>
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> <mailto:[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/20160529/9ef4fc06/attachment-0001.html>
------------------------------
Message: 13
Date: Sun, 29 May 2016 12:12:56 +0200
From: rv pellarin <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "USRP mailing list ([email protected])"
<[email protected]>
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<cahlh5kgzpzsnq+5wp_v5ts_dxkxoluozrowyehxcdxfuzv7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
thxx a lot, was doing tx\rx that s why it wasn t working
regarding the output i ve simply added > output.csv at the end, and using
space as delimiter, it allows to do a poor logging, but still has some
record
thxx for your time
?
On 29 May 2016 at 11:52, Marcus M?ller <[email protected]> wrote:
> how do you create an output file, same as before, no tips in -h
>
>
> usrp_spectrum_sense does not create an output file.
> Really, it *is* just an *example*. If you want to fulfill a specific
> application's needs, you will have to get your hands dirty at designing
> your own application.
>
> what is the antenna argument to use in order to use the tx/rx antenna?
> couldn t find any tips in -h
>
> um... emphasis by me:
>
> ./usrp_spectrum_sense.py --help
> linux; GNU C++ version 5.3.1 20151207 (Red Hat 5.3.1-2); Boost_105700;
> UHD_003.010.git-202-g9e0861e1
>
> Warning: this may have issues on some machines+Python version combinations to
> seg fault due to the callback in bin_statitics.
>
> Usage: usrp_spectrum_sense.py [options] min_freq max_freq
>
> Options:
> -h, --help show this help message and exit
> -a ARGS, --args=ARGS UHD device device address args [default=]
> --spec=SPEC Subdevice of UHD device where appropriate* -A
> ANTENNA, --antenna=ANTENNA** select Rx Antenna where
> appropriate*
> -s SAMP_RATE, --samp-rate=SAMP_RATE
> set sample rate [default=1000000.0]
> -g GAIN, --gain=GAIN set gain in dB (default is midpoint)
> --tune-delay=SECS time to delay (in seconds) after changing frequency
> [default=0.25]
> --dwell-delay=SECS time to dwell (in seconds) at a given frequency
> [default=0.25]
> -b Hz, --channel-bandwidth=Hz
> channel bandwidth of fft bins in Hz [default=6250.0]
> -l Hz, --lo-offset=Hz
> lo_offset in Hz [default=0]
> -q dB, --squelch-threshold=dB
> squelch threshold in dB [default=none]
> -F FFT_SIZE, --fft-size=FFT_SIZE
> specify number of FFT bins
> [default=samp_rate/channel_bw]
> --real-time Attempt to enable real-time scheduling
>
>
> so, you use it with
>
> -A TX/RX
>
> Best regards,
> Marcus
>
>
> On 29.05.2016 11:18, rv pellarin via USRP-users wrote:
>
> hi patrick,
> i got it working on kali, but few things remain.
> what is the antenna argument to use in order to use the tx/rx antenna?
> couldn t find any tips in -h
> how do you create an output file, same as before, no tips in -h
> thxx for your help!
> best rgeards
> herve
> ?
>
> On 25 May 2016 at 10:50, Patrick Sathyanathan <[email protected]> wrote:
>
>> You can try using usrp_spectrum_sense. It is also a scanner between
>> specified frequency limits that has a text output, and you can specify a
>> threshold level (squelch).
>>
>> --Patrick
>>
>> ------------------------------
>> Date: Tue, 24 May 2016 08:00:05 +0200
>> To: [email protected]
>> Subject: Re: [USRP-users] gr-scan & usrp
>> From: [email protected]
>> CC: [email protected]
>>
>> hi chris,
>>
>> i am using it on windows,mostyly, but when it agree to connect on linux
>> vm lsusb sees it
>>
>> using (on winblows) uhd_usrp_probe gives me this result:
>>
>> C:\WINDOWS\system32>uhd_usrp_probe
>> Win32; Microsoft Visual C++ version 12.0; Boost_105600;
>> UHD_003.009.002-release
>>
>> -- Detected Device: B205mini
>> -- Loading FPGA image: C:\Program Files
>> (x86)\UHD\share\uhd\images\usrp_b205mini_fpga.bin... done
>> -- Operating over USB 3.
>> -- Initialize CODEC control...
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Asking for clock rate 16.000000 MHz...
>> -- Actually got clock rate 16.000000 MHz.
>> -- Performing timer loopback test... pass
>> -- Setting master clock rate selection to 'automatic'.
>> _____________________________________________________
>> /
>> | Device: B-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: B205mini
>> | | revision: 1
>> | | product: 30522
>> | | serial: 30C7E1D
>> | | name: B205i
>> | | FW Version: 8.0
>> | | FPGA Version: 4.0
>> | |
>> | | Time sources: none, internal, external
>> | | Clock sources: internal, external
>> | | Sensors: ref_locked
>> | | _____________________________________________________
>> | | /
>> | | | RX DSP: 0
>> | | | Freq range: -8.000 to 8.000 MHz
>> | | _____________________________________________________
>> | | /
>> | | | RX Dboard: A
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Frontend: A
>> | | | | Name: FE-RX1
>> | | | | Antennas: TX/RX, RX2
>> | | | | Sensors: temp, rssi, lo_locked
>> | | | | Freq range: 50.000 to 6000.000 MHz
>> | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
>> | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Codec: A
>> | | | | Name: B205mini RX dual ADC
>> | | | | Gain Elements: None
>> | | _____________________________________________________
>> | | /
>> | | | TX DSP: 0
>> | | | Freq range: -8.000 to 8.000 MHz
>> | | _____________________________________________________
>> | | /
>> | | | TX Dboard: A
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Frontend: A
>> | | | | Name: FE-TX1
>> | | | | Antennas: TX/RX
>> | | | | Sensors: temp, lo_locked
>> | | | | Freq range: 50.000 to 6000.000 MHz
>> | | | | Gain range PGA: 0.0 to 89.8 step 0.3 dB
>> | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Codec: A
>> | | | | Name: B205mini TX dual DAC
>> | | | | Gain Elements: None
>>
>>
>>
>>
>>
>> i am also able to use it with gqrx and gnuradio without any issues
>>
>> best regards
>> ?
>>
>> On 23 May 2016 at 21:38, Chris Kuethe <[email protected]> wrote:
>>
>> OK, that's a better request. This tells us exactly what software you're
>> running and gives a very strong indication of where to start debugging.
>>
>> "FATAL: No supported devices found to pick from."
>>
>> Here are some things that you can investigate
>> 1) do you see the device with lsusb?
>> 2) do you see the device with uhd_usrp_probe?
>> 3) does this program work with any other receivers (rtlsdr)?
>> 4) can you use your receiver with osmocom_fft?
>> 5) can you use your receiver with uhd_fft?
>>
>>
>> On Mon, May 23, 2016 at 11:56 AM, rv pellarin < <[email protected]>
>> [email protected]> wrote:
>>
>> hi,
>> sorry again for my post, didn t mean to offense you, was busy with kids
>> and work, i should have wait before post.
>> so here is the soft:
>> <https://github.com/pinkavaj/gr-scan>https://github.com/pinkavaj/gr-scan
>>
>> got no error when compile, and when i run it, this is what i get as error
>> message.
>> root@kali:~/Documents/gr-scan/gr-scan-master# ./gr-scan -x 150 -y 175
>> linux; GNU C++ version 5.3.1 20160409; Boost_105800;
>> UHD_003.009.003-0-unknown
>>
>> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
>> bladerf rfspace airspy redpitaya
>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>>
>> FATAL: No supported devices found to pick from.
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>> Using Volk machine: avx_64_mmx_orc
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 4 items of size 16000. Due to alignment requirements
>> 32 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 16 items of size 8000. Due to alignment requirements
>> 64 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 8 items of size 8000. Due to alignment requirements
>> 64 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 8 items of size 8000. Due to alignment requirements
>> 64 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> ^C
>> root@kali:~/Documents/gr-scan/gr-scan-master#
>>
>>
>>
>> if you have any clues how to fix it, would be great, seems to be a nice
>> prog.
>> one thing i ve noticed, they show an example on their website with -o
>> filename.csv but in real, this option is not any longer available, pitty,
>> was handy
>>
>>
>> thxx for your time, and again, my apologies.
>> best regards
>>
>> herve
>>
>> On 23 May 2016 at 14:17, Chris Kuethe < <[email protected]>
>> [email protected]> wrote:
>>
>> And rather than posting errors as screenshots (images), either copy the
>> text either into an email or stick it on something like pastebin
>>
>> On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller <
>> <[email protected]>[email protected]> wrote:
>>
>> From where did you get your gr-scan? Again, Google points me to multiple
>> projects with that name. Which exactly is the one you are talking about?
>>
>> Also, as I said, you need to be *descriptive*.
>> "A lot of errors" helps no-one at helping you. Please apply some more
>> effort in reporting problems.
>>
>> BR,
>> Marcus
>>
>>
>> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin < <[email protected]>
>> [email protected]>:
>>
>> hi marcus,
>> gr-scan is a linux executable that allow to perform quic radio scan, for
>> example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150 &
>> 175 mhz and show result.
>> unfortunately it see the usrp device but gives lots off error and fail to
>> scan.
>> idealy i m looking for a solution with my usr that scan and log
>> automaticaly, that s why i asked you if some of you succeed to get this
>> utility working :)
>> thxx for your time marcus.
>> best rgeards
>> herve
>> ?
>>
>> On 23 May 2016 at 18:53, Marcus M?ller < <[email protected]>
>> [email protected]> wrote:
>>
>> Hi RV,
>>
>> I like your straightforward attitude, but:
>>
>> This sounds like you've tried something, and it failed.
>> You should definitely describe your problems in greater detail, otherwise
>> it'll be hard for people to help you.
>> For example, there's several projects out there that are called gr-scan.
>> Most of them haven't been updated/maintained in years. Which one are you
>> referring to?
>>
>> What are you trying to do?
>>
>> Generally, I'd like to encourage you to increase the descriptiveness of
>> your mailing list posts; that'll make it much easier to help you fast :)
>>
>> Best regards,
>> Marcus
>>
>>
>> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>>
>> hi guys,
>> have some of you succeed using gr-scan with an usrp device?
>> best regards
>> ?
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> <[email protected]>[email protected]
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> _______________________________________________
>> USRP-users mailing list
>> <[email protected]>[email protected]
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> --
>> GDB has a 'break' feature; why doesn't it have 'fix' too?
>>
>>
>>
>>
>>
>> --
>> GDB has a 'break' feature; why doesn't it have 'fix' too?
>>
>>
>>
>> _______________________________________________ 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
>
>
>
> _______________________________________________
> 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/20160529/ad5642e3/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 69, Issue 29
******************************************
