Re: [Discuss-gnuradio] question about bandwith B210 - USB3

[James Humphries]

Hello,

What are the specifications of your host computer (processor, RAM, SSD or
hard drive, etc)? What type of USB controller are you using?

-Trip

On Thu, Jun 30, 2016 at 6:48 PM, Przemek Lewandowski 
wrote:

> Hello
>
> I need to generate as wide bandwith as possible. Yes I know that this is
> waste of energy, but beside this simple example I want to put some other
> channels.
>
> On my USRP B210 I can afford now about 18 MS.
> I read on Ettus page that B200 can tx about 40 - 60 MS - depends on USB
> driver.
>
> So 15 MS is 3 times slower :) Im very beginer with filters at gnu radio so
> I suppose that default filters can be not so good optimized and propably I
> will need it to fix it manually.
>
> What do You think ???
>
> This is my graph:
> https://www.dropbox.com/s/xzwvb0dm25ubh5i/bandwith_test2.grc.png?dl=0
>
> All The Best.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[James Humphries]

Hi Shahnaz,

Could you run the install step again but with the verbose flag (-v)?

$ pybombs [-p myprefix] install gnuradio gr-osmosdr -v

It might produce more helpful debugging information. Can you post the
relevant output here when it hits the error?

-Trip

On Wed, Apr 20, 2016 at 9:12 PM, Shahnaz Shirazi 
wrote:

> Hi All,
>
> I'm trying to install Gnu radio through Pybombs.
> I followed the steps from instruction as listed below without error until
> step 4.
> Quickstart
>
> For the impatient:
>
>1. Install PyBOMBS as per the previous section
>2.
>
>Add a list of recipes, e.g. by running
>
>$ pybombs recipes add gr-recipes 
> git+https://github.com/gnuradio/gr-recipes.git
>$ pybombs recipes add gr-etcetera 
> git+https://github.com/gnuradio/gr-etcetera.git
>
>3.
>
>Create a prefix (a place to store your local installation):
>
>$ pybombs prefix init /path/to/prefix -a myprefix
>
>All commands after this will use myprefix as the default prefix. You
>can change the default prefix later by runningpybombs config
>default_prefix NEWPREFIX
>4.
>
>Start installing:
>
>$ pybombs [-p myprefix] install gnuradio gr-osmosdr
>
>
> After step 4 I'm getting the below error:
>
> *CMake Error: The source directory "/home/shahnaz/Lab3/src/osmo-**sdr"
> does not appear to contain CMakeLists.txt.*
> *Specify --help for usage, or press the help button on the CMake GUI.*
> *PyBombs.monitor_process() - DEBUG - Thread signaled termination or
> returned*
> *PyBombs.monitor_process() - DEBUG - Return value: 1*
> *PyBombs.Packager.source - ERROR - Problem occurred while building package
> osmo-sdr:*
> *Process returned value: 1*
> *PyBombs.install - ERROR - Error installing package osmo-sdr. Aborting.*
>
> I don't know why the osmo-sdr folder is not getting build correctly.
> when I look at the folder  the Cmake file is under
> "/home/shahnaz/Lab3/src/osmo-sdr/software/libosmosdr"  subfler not in the
> main folder.
>
> Did some one now how can I fix it?
>
>
> Thanks,
> shahnaz
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[James Humphries]

Hi Jason,

I replied to the other thread as well, but could you also do this to see if
its the same error?

Could you run the install step again but with the verbose flag (-v)?

$ pybombs [-p myprefix] install gnuradio gr-osmosdr -v

It might produce more helpful debugging information. Can you post the
relevant output here when it hits the error?

-Trip

On Thu, Apr 21, 2016 at 10:42 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> > I don't know why the osmo-sdr folder is not getting build correctly.
> > when I look at the folder  the Cmake file is under
> "/home/shahnaz/Lab3/src/osmo-sdr/software/libosmosdr"  subfler not in the
> main folder.
>
> FWIW, I am having the exact same issues.  I am running Ubuntu 14.04 and
> installed pybombs via the git clone method (not pip).
>
> --
> ~Jason
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Handling of IQ files

[James Humphries]

Hi Henry,

There is a script, read_complex_binary.m, that is included with gnuradio.
You can use that with Octave or Matlab to read the I/Q recordings from a
file as a time vector.

-Trip

On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton  wrote:

> Is there any simple formula for plotting spectrum (finding the intensity
> of each frequency component, Hertz by Hertz) from IQ recordings?
> Specifically I need to know how to read an IQ file and somehow dissect
> clusters of samples. I’ve written programs that deal with large amounts of
> data from files, so I think this shouldn't be too hard. I want to write my
> program so that it takes in a multi-hour IQ file and averages it like the
> 24-hour band averaging on the University of Twente WebSDR site. This would
> allow users to average an IQ file over time and see the most active
> frequencies and times. There’s no utility for this yet, and I’d like to
> write it and release it on my blog.
>
> On a side note: is it possible to go “frame-by-frame” in an IQ file? For
> example, to follow the hops of a 900-MHz FHSS device.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs2 github repository

[James Humphries]

Hi Varun,

PyBOMBS2 is now just PyBOMBS:

https://github.com/gnuradio/pybombs/issues

pybombs1 is now listed at pybombs_legacy.

-Trip

On Mon, Mar 7, 2016 at 2:03 PM, Varun Kumar  wrote:

> Hi,
> I've been using GNURadio for past 1 year, and I decided to look into
> PyBOMS2 issues for GSoC'16, but the github link mentioned on GSoC ideas'
> page(http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCIdeas), says
> 404 not found(https://github.com/gnuradio/pybombs2/issues).
>
> Link to pybombs2's repository would help.
>
> Regards,
> Varun
>
>
> --
> Varun Kumar
> B Tech ECE 3rd year
> Roll No. 2013169
> Student Council 2015-16 | Web Admin | ECE'13 Representative
> 
> http://home.iiitd.edu.in/~varun13169/
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue_stream_cmd, Segmentation Fault

[James Humphries]

Hi Zhihong,

4ae7a6015ba719a4720f61cc6f3857de2ebda89f is the commit hash that refers to
a specific commit on the GNU Radio repository.

If you built GNU Radio recently (I believe this commit was last August),
then you should be OK.

-Trip

On Wed, Feb 10, 2016 at 6:42 PM, Zhihong Luo  wrote:

> Hi Martin,
>
> What I want to do is to use the stream command to receive data, put it
> into the file, rest for like 2s, then start receiving again. I think I can
> do this by using multiple NUM SAMPLE AND DONE commands?
>
>  I don"t really understand the stop() here, I am using it because the
> manual seems to say so?  Previously, I simply called the issue-stream-cmd
> function before the flow graph start, but the file grew large very rapidly,
> so I was thinking maybe the stop() is the right way to do it. Now I have no
> idea how to call it.
>
> Sorry, but what is 4ae7a6015ba719a4720f61cc6f3857de2ebda89f ?
>
> Thanks a lot,
> Zhihong
> 2016年2月10日星期三，Martin Braun  写道：
>
>> Which version are you running? 4ae7a6015ba719a4720f61cc6f3857de2ebda89f
>> should fix this issue.
>>
>> Also, is this really what you want to happen? If you just call
>> issue_stream_cmd() with a STOP command, it will stop, but all the data
>> will still flow through the graph, instead of getting flushed.
>> Especially as you are stopping and starting the flow graph.
>>
>> My guess is you don't really need stop() here.
>>
>> Cheers,
>> M
>>
>>
>> On 02/10/2016 03:07 PM, Zhihong Luo wrote:
>> > Hi All,
>> >
>> > In the manual, it says to use issue_stream_cmd:
>> >
>> > After starting the flow graph, the user should call stop()
>> > <
>> https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a0863bc16f7c84adf4cddf5d53124450e
>> >on
>> > this block, then issue any desired arbitrary stream_cmd_t structs to the
>> > device
>> >
>> > Therefore, I tried to stop() then issue the stream command, but it ran
>> > into segmentation fault. My code is:
>> >
>> > uhd::stream_cmd_t
>> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>> >  size_t num_requested_samples= 1;
>> >  stream_cmd.num_samps = size_t(num_requested_samples);
>> >  stream_cmd.stream_now = true;
>> >  stream_cmd.time_spec = uhd::time_spec_t();
>> > ...
>> > std::cout << "starting flow graph" << std::endl;
>> > tb->start();
>> > usrp_source->stop();
>> > usrp_source->issue_stream_cmd (stream_cmd);
>> >
>> > Even if I delete the issue_stream_cmd line, there is still a
>> > segmentation fault. Can someone point out where I made a mistake?
>> Thanks.
>> >
>> > Zhihong Luo
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] power amplifiers on TX

[James Humphries]

Hi Daniel,

The output power of the USRP is controlled by the TX gain setting. Keep in
mind that the output power of the USRP is not calibrated and will vary from
device to device. Some may have higher output power than others.

Isolation between the transmit and receive sections of the USRP is a pretty
big issue. I have issues with a very modest TX amp (~15dB) and am putting
out just over +20dBm. An external switch was the only way to get the
isolation needed. I guess some circulators also have pretty good isolation,
but they aren't very cost effective for the isolation you will need.

Which USRP are you using? You'll need to properly shield the RF sections as
well.

I'm on Marcus' side with that output power, that's a scary high output. I
start to sweat at 10W... :) Good luck with your experiments.

-Trip

On Wed, Dec 30, 2015 at 4:43 PM, Daniel Pocock  wrote:

>
>
> On 30/12/15 22:24, Marcus Müller wrote:
> > Hi Daniel,
> > Cannot stress this enough:
> > Don't try to do everything to the max right from the start. Sure, 100mW
> > is a lot less than what can do in the licensed bands, but then again,
> > not coming from an amateur background, 120W right out scare me. Please
>
> Maybe some clarification is in order:
>
> - need to check if the power amp's output is proportionate to the input
> power
>
> - does the USRP and GNU Radio provide a way to manage output power
> (power into the amp), or is it always constant at 100 mW?
>
> - it is legal - e.g. 400W is the limit in the UK and regs are similar in
> other countries for fully licensed hams:
>
> http://www.ofcom.org.uk/static/archive/ra/publication/ra_info/br68r11/br68.htm
>
> > make sure no more than -15dBm are fed into the USRP RX. So at an output
> > power of 120 W ~= 51dBm, you need isolation of at least 66dB between
> > your TX antenna and the RX port of your USRP for the TX frequency. Also,
> > considering you're buying a device that can potentially cover 70MHz to
> > 6GHz, spending lots of money on a powerful amplifier that can but
> > operate on a few MHz really sounds like an unbalanced investment. Maybe
> > reduce the output power (unless you want to do moon bounce, maybe), and
> > get separate filters, just to keep the option of not operating in
> > 144-147MHz; your whole operational range is much smaller than the amount
> > of spectrum you can control with the USRP at once.
> >
>
> Agreed - many people would be satisfied with something up to 50W,
> similar to a mobile rig, this was just the first thing Google found when
> I included "100 mW" in my search query.
>
> I have had SAREX contacts with 5W from a handheld device and J-pole, but
> that was in Australia where the population is very thinly distributed
> and I could have been the only person transmitting.  There were no
> nearby mountains (unlike my current QTH) and no tall buildings.  In a
> densely populated region like Europe, more power may appeal to some people.
>
> > Of you're not going to use two highly directive antennas for RX and TX
> > to achieve isolation:
> > You will either need an RX/TX switch (that you should definitely control
> > using the USRPs GPIO pins, which can be programmed to certain states
> > when transmitting, receiving or doing full duplex) to isolate RX from TX
> > when transmitting, or an extremely expensive circulator-based device.
> >
> > To be honest, you seem to be throwing money at your problem, that partly
> > including having a bit of uncertainty what you want to do. I'd rather
> > start small, buy the USRP, and maybe a preselective filter, experiment a
> > bit with "short links", then invest in antennas, filters, switches and
> > or amplifiers as you build up wishes and experience.
> > My feeling is that you'd probably want to first RX only on different
> > bands with different antennas, see what's possible with and without
> > preselection, then decide on one or two bands, get more specific filters
> > for these, switches, and then an amp.
> > Don't start with something that you can use to defrost your antenna, and
> > then try to figure out where you fried which parts of your rig.
>
> Thanks for this feedback, I wasn't going to go out and buy this first, I
> just wanted to start putting together a vision of what the big picture
> looks like and what all the pieces will cost.
>
> Buying an amp that can fry an egg is a poor substitute for having the
> right antenna.  On the receive side, this fact is obviously even more
> unavoidable.
>
> Regards,
>
> Daniel
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd_sink samp rate(sps)

[James Humphries]

Hi Ekko,

The sample rate has to be some fraction of the clock rate divided by an
integer. The clock rate on the E310 defaults to 32MHz I believe, so 32MHz
divided by 4 gives you 8 Msps. The system will get you as close as it can
to the desired sample rate. You can set the clock rate to something else to
achieve the 10 Msps rate that you want (try setting it to 30MHz).

-Trip

On Tue, Dec 1, 2015 at 10:17 AM, Ekko  wrote:

> hello
> when i set the uhd_sink or uhd_source samp rate to 10M
> i got that
> The hardware does not support the requested TX sample rate:
> Target sample rate:10.00 MSps
> Actual sample rate: 8.00 MSps
> then i set it to other value,some of them is ok,some not,
> i know that the max samp rate of e310 is not 8M
> so i want to know what value is ok for the uhd_sink or uhd_source
> between the min to max samp rate.
>
> i do not find it on manual page,but i got this message.
>
> thank you
>
> --Ekko
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] running error

[James Humphries]

Hi Kerry,

Did you hook your computer back up to the internet before you ran
uhd_images_downloader.py?

-Trip

On Mon, Nov 30, 2015 at 3:22 PM, kerry  wrote:

> Hi,all:
>
> I try to run an example about gnu radio. The runtime errors are captured
> as:
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> FATAL: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
> path!
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>
>
> 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.
>
>
> >>> Done
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>
> 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.
>
>
> >>> Done
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> FATAL: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
> path!
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>
>
> 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.
>
>
> >>> Done
>
> 
>
> But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".
>
> It said that
>
> Images destination:  /usr/local/share/uhd/images
> Downloading images from:
> http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
> Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
> Downloader raised an unhandled exception: request() got an unexpected
> keyword argument 'stream'
> You can run this again with the '--verbose' flag to see more information
> If the problem persists, please email the output to: supp...@ettus.com
> -
>
> Could anyone tell my why? Thx.
>
> -Kerry
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Complex Demodulation

[James Humphries]

Hi Roee,

The USRP is not expecting any particular type of data. The USRP is a direct
conversion transceiver that operates on I and Q samples, so in theory, you
should be able to generate/receive any type of signal. If you input a
cosine to the USRP, in will generate the in-phase and quadrature components
of that signal. For a simple cosine input, you get I(t)=cos(w0t) and
Q(t)=sin(w0t) components.

Yes, the USRP performs low-pass filtering, but this is to remove
out-of-band noise and other signals. It is not to suppress the side-bands
like you would see in a system that only samples the in-phase signal
components. Remember, we are down-converting to baseband, so the low-pass
filter actually filters from -BW/2 to +BW/2 (where BW is your total
bandwidth, in this case, it is usually your sample rate). Those 'mirror'
images don't exist in this system since both the positive and negative
frequency components can be uniquely determined with the I/Q components of
the signal. If you were to just zero out either the I or Q component, then
you would see your mirror images in frequency again.

-Trip

On Mon, Nov 16, 2015 at 2:52 AM, Roee Bar <ro...@ece.ubc.ca> wrote:

> Hi James,
>
> Thank you very much for your time and effort!
>
> Your explanation of the USRP complex modulation/demodulation is equivalent
> to what I originally described.
>
> Since my experiments show that the receiver did not always received what
> was transmitted, I thought there was something wrong with my assumptions
> about the complex demodulation, but my understanding was correct.
>
> I believe the reason for the inconsistency between my sent signal and the
> received signal is that my original signal was not single-side-band, or,
> not ‘proper’ IQ signal.
> Taking your example, if I wanted to transmit cos(w0*t), I transmitted
> s(t)=cos(w0*t), instead s(t)=cos(w0*t)+j*sin(w0*t). In that case, I
> received I(t)=cos(w0*t) but Q(t) was not zero (sometimes it was something
> like sin(w0*t) but not always).
>
> So I guess the USRP receiver performs some low pass filtering which
> removes the lower-side-band or something similar.
>
> Can anyone confirm that the USRP expects single-side-band signals so I can
> put this issue to rest?
>
> Thanks in advance,
> Roee
>
>
>
>
>
> On 13 Nov 2015, at 19:40, James Humphries <james.humphr...@ettus.com>
> wrote:
>
> Hi Roee,
>
> That's a great question! There are lots of explanations on the topic, but
> I'll try to show just some basics of the USRP (and is applicable to any
> direct conversion transceiver). For completeness sake, I'm going to include
> a lot more information than you probably need here. I've just copied over
> some figures from my thesis work to help explain some things.
>
> Since the USRP is operating as a direct conversion transceiver, converting
> from RF to baseband (and vice versa), we need a way to be able to determine
> both the negative and positive frequency components of our signal. As you
> know, with only real samples, you cannot distinguish between the positive
> and negative frequency components due to the ambiguity in phase. To fix
> this, we need to decompose our signal into an In-Phase (Real, I) and
> Quadrature (Complex, Q) components. With these components, we can form a
> phase vector on a complex plane. Each sample in this system will consist of
> an In-Phase and Quadrature component. These components are 90 degrees out
> of phase, as shown on the complex plane below:
>
> 
> ​
>
> With this method to represent our signal, we can determine the negative
> and positive frequency components of the signal and perform complex phase
> modulation techniques (among many other advantages). Luckily, we already
> have two functions that are in quadrature, sine and cosine.
>
> Let's say we do have a complex signal, s(t), that we want to transmit.
> This signal is composed of the I/Q components, so we'll say s(t) = I(t) +
> Q(t). The key here is that the I component is multiplied by a cosine term
> and the Q component is multiplied by a sine term. I've included a diagram
> below to illustrate:
>
> 
> ​
> The two terms are then added into a single output and transmitted. For
> example, let's say we want to transmit a cosine signal, cos(wmt). The I
> component is cos(wmt), but the Q component is sin(wmt). When we mix our
> signals up, we end up with:
>
> sout(t) = cos(wmt)*cos(wot) - sin(wmt)*sin(wot)  (minus sign due to -90
> degree phase shift from LO) (wm is signal frequency, wo is oscillator
> frequency)
>
> Using some trig identities, this expands to:
>
> sout(t) = 1/2 * [ cos(wmt-wot) + cos(wmt+wot) ] - 1/2 * [ cos(wmt-wot) -
> cos(wmt+wot) ]
>
> The first and third cosine terms cancel, leaving you with just the s

Re: [Discuss-gnuradio] USRP Complex Demodulation

[James Humphries]

I'm referring to the receiver. It's essentially two receivers in parallel,
one mixing down with the local oscillator (cosine) and the other mixing
down with the same local oscillator, but phase shifted -90 degrees (sine).
This is how it generates two components for the input signal. Of course,
you can only input a real signal, but the receiver can generate both the I
and Q components in the 'dual' receiver mode. This is similar to how a
vector network analyzer (VNA) operates.

Did the images I sent on the first e-mail come through ok? They were pretty
basic, but show the layout of the transmitter and receiver.

-Trip

On Mon, Nov 16, 2015 at 5:47 PM, Roee Bar <ro...@ece.ubc.ca> wrote:

> Thanks James,
>
> What do you mean by “USRP will generate the in-phase and quadrature
> components”? Are you referring to the USRP receiver or transmitter? I am
> feeding the USRP transmitter with a real only signal s(t)=cos(w0*t), why
> does the received signal has an imaginary component (i.e. Q(t) is not zero)?
>
> Thanks again,
> Roee
>
>
> On 16 Nov 2015, at 14:34, James Humphries <james.humphr...@ettus.com>
> wrote:
>
> Hi Roee,
>
> The USRP is not expecting any particular type of data. The USRP is a
> direct conversion transceiver that operates on I and Q samples, so in
> theory, you should be able to generate/receive any type of signal. If you
> input a cosine to the USRP, in will generate the in-phase and quadrature
> components of that signal. For a simple cosine input, you get I(t)=cos(w0t)
> and Q(t)=sin(w0t) components.
>
> Yes, the USRP performs low-pass filtering, but this is to remove
> out-of-band noise and other signals. It is not to suppress the side-bands
> like you would see in a system that only samples the in-phase signal
> components. Remember, we are down-converting to baseband, so the low-pass
> filter actually filters from -BW/2 to +BW/2 (where BW is your total
> bandwidth, in this case, it is usually your sample rate). Those 'mirror'
> images don't exist in this system since both the positive and negative
> frequency components can be uniquely determined with the I/Q components of
> the signal. If you were to just zero out either the I or Q component, then
> you would see your mirror images in frequency again.
>
> -Trip
>
> On Mon, Nov 16, 2015 at 2:52 AM, Roee Bar <ro...@ece.ubc.ca> wrote:
>
>> Hi James,
>>
>> Thank you very much for your time and effort!
>>
>> Your explanation of the USRP complex modulation/demodulation is
>> equivalent to what I originally described.
>>
>> Since my experiments show that the receiver did not always received what
>> was transmitted, I thought there was something wrong with my assumptions
>> about the complex demodulation, but my understanding was correct.
>>
>> I believe the reason for the inconsistency between my sent signal and the
>> received signal is that my original signal was not single-side-band, or,
>> not ‘proper’ IQ signal.
>> Taking your example, if I wanted to transmit cos(w0*t), I transmitted
>> s(t)=cos(w0*t), instead s(t)=cos(w0*t)+j*sin(w0*t). In that case, I
>> received I(t)=cos(w0*t) but Q(t) was not zero (sometimes it was something
>> like sin(w0*t) but not always).
>>
>> So I guess the USRP receiver performs some low pass filtering which
>> removes the lower-side-band or something similar.
>>
>> Can anyone confirm that the USRP expects single-side-band signals so I
>> can put this issue to rest?
>>
>> Thanks in advance,
>> Roee
>>
>>
>>
>>
>>
>> On 13 Nov 2015, at 19:40, James Humphries <james.humphr...@ettus.com>
>> wrote:
>>
>> Hi Roee,
>>
>> That's a great question! There are lots of explanations on the topic, but
>> I'll try to show just some basics of the USRP (and is applicable to any
>> direct conversion transceiver). For completeness sake, I'm going to include
>> a lot more information than you probably need here. I've just copied over
>> some figures from my thesis work to help explain some things.
>>
>> Since the USRP is operating as a direct conversion transceiver,
>> converting from RF to baseband (and vice versa), we need a way to be able
>> to determine both the negative and positive frequency components of our
>> signal. As you know, with only real samples, you cannot distinguish between
>> the positive and negative frequency components due to the ambiguity in
>> phase. To fix this, we need to decompose our signal into an In-Phase (Real,
>> I) and Quadrature (Complex, Q) components. With these components, we can
>> form a phase vector on a complex plane. Each sample in this system wil

Re: [Discuss-gnuradio] Connecting two USRP B200 radios

[James Humphries]

For RX gain, you will probably need around 20-40dB. Yes, you should place
the 30dB attenuator in line with your connection. You should be able to
slowly increase the transmit gain until you see the signal. Double check
that the correct ports on each board on in use, a green light will light up
when the corresponding port is activated. Again, all these settings are
application specific, so it may take some experimentation to get the
correct settings for your case.

-Trip

On Fri, Nov 6, 2015 at 12:40 PM, Ashish Pasha Sheikh <apshe...@mtu.edu>
wrote:

>
> For transmission , I am using Tx/Rx port on first B200 radio ...
>
> For receiver part , I am using Rx port ..  I was using MATLAB as a
> platform .  Do you mean that i should use atleast  gain of 15 and place an
> attenuator of 30 dB and connect to Receiver (rx port) ... how much Rx gain
> i should keep in my settings??
>
> ash
>
> On Fri, Nov 6, 2015 at 10:57 AM, James Humphries <
> james.humphr...@ettus.com> wrote:
>
>> Hi Ash,
>>
>> Yes, you need to use an attenuator if you are connecting the B200's
>> directly together with a cable. I would recommend at least 30dB of
>> attenuation, but that depends on your settings. It is recommended that you
>> do not input more that -15 dBm into the receiver of the B200, as this can
>> damage the device.
>>
>> With that said, what settings are you using? I see you have 8dB gain for
>> transmit (you may need to increase this), what about receive on the other
>> B200? Which port are you using to receive on the B200 (TX/RX or RX2)?
>>
>> -Trip
>>
>> On Fri, Nov 6, 2015 at 10:46 AM, Ashish Pasha Sheikh <apshe...@mtu.edu>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> i am new to the world of SDR. I currently have two USRP B200 radios. I
>>> would like to connect the Tx port of one SDR to Rx port of second SDR using
>>> a cable to visualize the transmitted bits.
>>>
>>> I am generating random bits with Ts=1/1 and 50 samples per frame.
>>> Using a rectangular pulse shaping with 20 pulse length it would output
>>> me a samples with data rate of 200KHz. I am transmitting the baseband
>>> signal with gain of 8 and interpoaltion factor 512 over a 432e6 frequency.
>>>
>>>
>>> now i want to visualize the signal by receiving it on another B200 radio
>>> . I receive complete noise irrespective of whether i am transmitting (or)
>>> not. So can i connect the two B200 radios using a cable so as to see the
>>> clean recevieed spectrum..
>>>
>>> In this case I believe i should use a attenuator in between the
>>> cables.Can you please point more on this ? can i drectly connect without an
>>> attenuator??
>>>
>>>
>>> Ash
>>> undergrad student,
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Connecting two USRP B200 radios

[James Humphries]

Hi Ash,

Yes, you need to use an attenuator if you are connecting the B200's
directly together with a cable. I would recommend at least 30dB of
attenuation, but that depends on your settings. It is recommended that you
do not input more that -15 dBm into the receiver of the B200, as this can
damage the device.

With that said, what settings are you using? I see you have 8dB gain for
transmit (you may need to increase this), what about receive on the other
B200? Which port are you using to receive on the B200 (TX/RX or RX2)?

-Trip

On Fri, Nov 6, 2015 at 10:46 AM, Ashish Pasha Sheikh 
wrote:

> Hello everyone,
>
> i am new to the world of SDR. I currently have two USRP B200 radios. I
> would like to connect the Tx port of one SDR to Rx port of second SDR using
> a cable to visualize the transmitted bits.
>
> I am generating random bits with Ts=1/1 and 50 samples per frame.
> Using a rectangular pulse shaping with 20 pulse length it would output
> me a samples with data rate of 200KHz. I am transmitting the baseband
> signal with gain of 8 and interpoaltion factor 512 over a 432e6 frequency.
>
>
> now i want to visualize the signal by receiving it on another B200 radio .
> I receive complete noise irrespective of whether i am transmitting (or)
> not. So can i connect the two B200 radios using a cable so as to see the
> clean recevieed spectrum..
>
> In this case I believe i should use a attenuator in between the cables.Can
> you please point more on this ? can i drectly connect without an
> attenuator??
>
>
> Ash
> undergrad student,
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to use an external PPS reference in B200?

[James Humphries]

Hi Julio,

You need to instruct the USRP which reference to use. See this page in the
UHD manual:

http://files.ettus.com/manual/page_sync.html

Are you using a GNU Radio flowgraph? Or are you writing code directly using
the GNU Radio python API or UHD C++ API?

-Trip

On Mon, Oct 19, 2015 at 1:12 PM, Julio Hector Aguilar Renteria <
jhagui...@gmail.com> wrote:

> Hi, All
>
> How to use an external GPS reference in the USRP B200 ?, I do some extra
> configuration on the USRP B200?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio installation script

[James Humphries]

You can try to run again as:

./build-gnuradio -v

That will output a bunch of extra info. Hopefully it will show error why
build failed.


As an alternative, you could try pybombs.

http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart

Just run these commands:

git clone git://github.com/pybombs/pybombs
cd pybombs
./pybombs install gnuradio

That will install uhd and gnuradio (among some other things) and it could
take a few hours. Just make sure you follow directions on the site to setup
the environment correctly after it (hopefully) completes.

-Trip

On Tue, Sep 22, 2015 at 8:25 AM, Mike Gilmer <mike.gil...@gmail.com> wrote:

> I've gotten further along but it still failed.  Here's the output
>
> +++
> Failed to find package 'libzmq1-dev' in known package repositories
> <-- I noted this in my previous post
> SOME THINGS MAY NOT BUILD AS A RESULT
> Checking for package libzmq
> Checking for package libzmq-dev
> Checking for package python-requests
> Done checking packages
> Checking for library libusb ...Found library libusb
> Checking for library libboost ...Found library libboost
> Checking for library libcppunit ...Found library libcppunit
> Checking for library libfftw ...Found library libfftw
> Checking for library libgsl ...Found library libgsl
> Done
> This script will fetch Gnu Radio version 3.7/maint from the
> repositories, along with compatible
> extras.
> Is this OK?y
> Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
> via the Internet
> ===> THIS MAY TAKE QUITE SOME TIME <=
> Fetching Gnu Radio via GIT...Done
> Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr,
> gr-iqbal, hackrf, bladeRF and airspy) via GIT
> Done
> Starting function uhd_build at: Tue Sep 22 00:10:59 EDT 2015
> Building UHD...
> => THIS WILL TAKE SOME TIME <=
>
> UHD build apparently failed
> Exiting UHD build
> ++
>
> Again, I appreciate the help!
>
> -Mike
>
> On Mon, Sep 21, 2015 at 11:48 PM, Mike Gilmer <mike.gil...@gmail.com>
> wrote:
> > I'm running 14.04 and yes I have Internet access (that was part of the
> > aforementioned "drama")
> >
> > I ran the update/upgrade and reran the script and now things are
> "different"
> >
> > This seems like it may take a while. I'll report back when it's done.
> >
> > Hmm.. so far one error - it couldn't find libzmq1-dev; I don't know
> > what that'll mean
> >
> > Thanks!
> >
> > Mike
> >
> >
> >
> > On Mon, Sep 21, 2015 at 11:27 PM, James Humphries
> > <james.humphr...@ettus.com> wrote:
> >> Hi Mike,
> >>
> >> Did you update your package manager? Usually helps when I get errors.
> >>
> >> sudo apt-get update && sudo apt-get upgrade
> >>
> >> Also, make sure build-essential is installed (Do this after update and
> >> upgrade).
> >>
> >> sudo apt-get install build-essential
> >>
> >> -Trip
> >>
> >> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer <mike.gil...@gmail.com>
> wrote:
> >>>
> >>> All,
> >>> I recently asked the list some questions about getting GNU Radio up
> >>> and running on a Windows machine (using cygwin). It became obvious
> >>> there would be a lot of hurdles, for which the community would not be
> >>> able to offer much help. So...
> >>>
> >>> I have installed Ubuntu on a PC ( in a dual boot configuration with
> >>> Win7 ) <-- this is its own drama LOL
> >>>
> >>> I tried to follow the "Installing GNU Radio step(s) outlined on
> >>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
> >>> using the script via
> >>> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
> >>> ./build-gnuradio && ./build-gnuradio
> >>>
> >>> and I get a bunch of errors :
> >>> Checking for package libfontconfig1-dev
> >>> Failed to find package 'libfontconfig1-dev' in known package
> repositories
> >>> SOME THINGS MAY NOT BUILD AS A RESULT
> >>> Checking for package libxrender-dev
> >>> Failed to find package 'libxrender-dev' in known package repositories
> >>> SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption
> >>>
> >>> etc..
> >>>
> >>> It appears that a major step is missing or broken.  Can someone help
> me on
> >>> this?
> >>>
> >>> Thanks!
> >>>
> >>> Mike
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio installation script

[James Humphries]

Hi Mike,

Did you update your package manager? Usually helps when I get errors.

sudo apt-get update && sudo apt-get upgrade

Also, make sure build-essential is installed (Do this after update and
upgrade).

sudo apt-get install build-essential

-Trip

On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer  wrote:

> All,
> I recently asked the list some questions about getting GNU Radio up
> and running on a Windows machine (using cygwin). It became obvious
> there would be a lot of hurdles, for which the community would not be
> able to offer much help. So...
>
> I have installed Ubuntu on a PC ( in a dual boot configuration with
> Win7 ) <-- this is its own drama LOL
>
> I tried to follow the "Installing GNU Radio step(s) outlined on
> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
> using the script via
> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
> ./build-gnuradio && ./build-gnuradio
>
> and I get a bunch of errors :
> Checking for package libfontconfig1-dev
> Failed to find package 'libfontconfig1-dev' in known package repositories
> SOME THINGS MAY NOT BUILD AS A RESULT
> Checking for package libxrender-dev
> Failed to find package 'libxrender-dev' in known package repositories
> SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption
>
> etc..
>
> It appears that a major step is missing or broken.  Can someone help me on
> this?
>
> Thanks!
>
> Mike
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reporting experience of installation from source of GnuRadio-3.7.8

[James Humphries]

Hi Daniele / Marcus,

I'll add my experience as well. I have been testing installs of Ubuntu
15.04 in a VMware virtual machine. I limit it to 2GB of RAM. I was using
pybombs to install UHD + GNURadio. Install would halt at a certain point
(no error) every time. Solution was to limit make to 2 threads (pybombs
default is 4). Everything went smoothly from there. I agree that 4GB is
probably a better number for development, though.

-Trip

On Sat, Sep 19, 2015 at 6:07 PM, Marcus Müller 
wrote:

> Hi Daniele,
>
> good point!
> The problem is that the amount of RAM you'd need depends on quite a lot
> of factors, from compiler version over boost dependencies, even when
> running make single-threaded (not as "make -j8" or so).
>
> Generally, 2GB sounds like it'd be too little for development
> workstation usage nowadays, I agree.
>
> Best regards,
> Marcus
> On 18.09.2015 16:12, Daniele wrote:
> > Hi!
> > I just want to share my experience of installing gnuradio-3.7.8 on a PC
> with
> > debian stretch (test version).
> > Initially, the PC was equipped with only 2 GB of RAM and the installation
> > finished with an error. (To be more precise, after performing "cmake
> ../" in
> > the build directory and executing the command "make").
> > After several attempts I gave him back the "make" command to read the
> error
> > messages.
> > Then compile resumed without problems. This suggested to me that could
> be a
> > problem of RAM. Adding another 2 GB of RAM to the same PC everything
> worked
> > properly.
> > I suggest that it would be necessary to point out this requirement in the
> > notes describing the installation process. (I read this item only about
> > those who want to use the DVD with a live distribution containing
> gnuradio).
> >
> > I hope this notes could be useful.
> >
> > Daniele
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio