[Discuss-gnuradio] USRP2 reference clock

[Nils Hollmach]

Dear Sir or Madam,

At present I work with 2 different USRPs.
One of
this is the USRP2 and the another one a newer device is the X300.
This
devices communicate each about QPSK and a test algorithm.
For the USRP2
I use the reference input and use reference clock output from 
the x300
device to compensate frequency shift.
If I use the
command
self.uhd_usrp_source.set_clock_source("external",
uhd.ALL_MBOARDS)
, then data communication didn't work.
But If I set the
master clock of the USRP2 to 200Mhz with

self.uhd_usrp_source.set_clock_rate(200e6, uhd.ALL_MBOARDS)
, then the
communication works.
Is it possible to set the master clock at the USRP2
or what
could been the reason? 

best regards___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[Marcus Müller]

Hi Rob,

so, first of all: I recommend doing the compilation on a PC
(cross-compiling). In all experiences I've known of, compiling on
something as weak and RAM-sparse as the Pi takes nights, and needs a lot
of swap memory, making it impractical. Also note that setting up the
cross-compilation environment shouldn't take longer than compiling on
the Pi iself.

So, first of all, what kind of OS are you using on the Pi? Is it
something like debian (in which I'd plainly recommend installing GR from
debian packages, those being relatively up to date, or using debian's
build systems with updated/modified sources), or is it more something
like a classical embeddded OS like an image generated by OpenEmbedded?

Then: GNU Radio comes with an ARMv7/cortex-a8 compatible toolchain file,
which you can use for cross-compilation to such a target; not being an
expert in RPis, I think only the Pi B+ is an ARMv7. Which one are you using?

Then, and that's mostly out of curiosity: Maybe it's easier to help you
find a good way if you tell us what you're planning to do with the
Raspberry Pi and GNU Radio – usually, the Pi is not really the go-to
choice for digital signal processing, so the complexity of SDR you can
do with it is limited, but it might well suit you!

Best regards,
Marcus

On 13.04.2016 04:25, Rob Roschewsk wrote:
>
> Hi all,
>
> I'd like to compile GR from source for a raspberry pi (arm) ... I know
> there are some flags that need to be passed to cmake but I can't find
> a complete list ... or at least a consistent list
>
> Is there a reference I could use???
>
> Thanks!
>
> --> Rob, KA2PBT
>
>
>
> ___
> 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] USRP2 reference clock

[Marcus Müller]

Hi Nils,

So, could you share your flow graph, or a sketch of it?

Especially (asked you on SO, too): Do you use one uhd_usrp_source, or
two? And: how do you tell the source(s) which USRP to use?

To answer the easy-to-answer questions right now:
> Is it possible to set the master clock at the USRP2 or what
> could been the reason?
No, USRP2 has a fixed 100MHz MCR. My suspicion is that you're actually
setting the rate of the X300, or a side effect of trying to set the rate
of the USRP2 helps you here; hence my question for the overall approach.

Best regards,
Marcus


On 13.04.2016 09:26, Nils Hollmach wrote:
>
> Dear Sir or Madam,
>
> At present I work with 2 different USRPs.
> One of this is the USRP2 and the another one a newer device is the X300.
> This devices communicate each about QPSK and a test algorithm.
> For the USRP2 I use the reference input and use reference clock output
> from
> the x300 device to compensate frequency shift.
> If I use the command
> self.uhd_usrp_source.set_clock_source("external", uhd.ALL_MBOARDS)
> , then data communication didn't work.
> But If I set the master clock of the USRP2 to 200Mhz with
> self.uhd_usrp_source.set_clock_rate(200e6, uhd.ALL_MBOARDS)
> , then the communication works.
> Is it possible to set the master clock at the USRP2 or what
> could been the reason?
>
>  
>
> best regards
>
>
>
> ___
> 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] Setting up a new block

[Ankit Saharia]

I looked for setting up a new block in windows version of GNURadio.

I wanted to know whether it is possible or not?

Thank You
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Setting up a new block

[Marcus Müller]

Yes; why not?
Have you gone through the guided tutorials [1]? They explain the process
pretty well.

Just a note: If you're new to GNU Radio, I'd actually recommend using
Linux, for example the liveSDR environment[2], which works without
installation. That will save you a lot of trouble of the kind "oh,
windows doesn't find Python" etc.

Best regards,
Marcus

[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD

On 13.04.2016 12:16, Ankit Saharia wrote:
> I looked for setting up a new block in windows version of GNURadio.
>
> I wanted to know whether it is possible or not?
>
> Thank You
>
>
> ___
> 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] raspi FAQ/HOWTO/recipe ??????

[Rob Roschewsk]

Marcus,

Thanks for responding.

I'm looking to build a headless FM receiver to record and stream public
service communication (fire, police, etc.). We will stream as many channels
as possible that fall into a given passband.

I already have a system running on a PC and now would like to port it to
the PI.

I understand it maybe an "up hill" path, but the thought is to deploy
multiple inexpensive units around a geographic area all feeding a central
streaming server.

The Pi is running Raspian Jesse  I started with the distribution
packages but ran into problems right out of the blocks and thought it would
be best to use the latest code before asking questions :)

I understand cross compiling is the way to go.

Since I brought it up, here was the error I saw when I tried to run the
script that runs on the PC but fails spectacularly on the raspberry pi with
the precompiled packages 

roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py -s 49 noaa.xml
linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0 <0030070030>
-unknown

high=16250 low=16240 span=10
center=16245
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy
Using device #0 Realtek RTL2838UHIDIR SN: 0108
Found Elonics E4000 tuner
Exact sample rate is: 100.026491 Hz
Using Volk machine: generic_orc
VOLK: Error allocating memory (posix_memalign: 22)
VOLK: Error allocating memory (posix_memalign: 22)
VOLK: Error allocating memory (posix_memalign: 22)
Segmentation fault
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] B2xx rates

[Alexander Levedahl]

Hello,

Is there a list of sample rates and associated bandwidths supported by the
B2xx series or a way to generate the list?  E.g., the list for the X310 is
to take 120MHz, 184.32MHz, and 200MHz and divide by an integer.

Thanks,
Alex
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Hi,

I have been trying to do some research using MIMO transmitters and feedback
from a receiver. Specifically, I have two antennas connected to two USRPs,
and I am transmitting the same signal from both of those (MIMO
synchronized) to another USRP and antenna.This receive USRP and antenna
needs to measure its received power, which I then feed back to my computer,
do some processing on it, and then produce a new transmission from the two
antennas on the left, and that keeps going until my loop is done.

What I'm having trouble with is how to set up my self-created block to
transmit from the two synchronized ones with my particular weights but also
receive from the one on the right correctly so that it gives me the proper
received power. Right now, I'm doing both the transmit and receive
processes independently, and it's very difficult to get the proper capture
on the receive side and send it back.

I'm not sure if that makes sense, but that type of feedback has been very
difficult. Note that I've been able to create this loop, block, and
feedback setup with an RSSI circuit and the two transmitters because I can
feedback its reading through USB nicely/if not with a bit of a hack using
minicom. I just can't do it when the receiver is a USRP. I must be missing
something. Thank you for any help.

-- 
Pavan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B2xx rates

[Ron Economos]

The B2X0 series has a programmable master clock. You can set it to 
anything from 200 kHz to 56 MHz.


Ron

On 04/13/2016 05:55 AM, Alexander Levedahl wrote:

Hello,

Is there a list of sample rates and associated bandwidths supported by 
the B2xx series or a way to generate the list? E.g., the list for the 
X310 is to take 120MHz, 184.32MHz, and 200MHz and divide by an integer.


Thanks,
Alex




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B2xx rates

[Ron Economos]

Correction. The master clock rate can be set to anything from 5 MHz to 
56 MHz. The bandwidth is 200 kHz to 56 MHz.


Ron

On 04/13/2016 07:46 AM, Ron Economos wrote:
The B2X0 series has a programmable master clock. You can set it to 
anything from 200 kHz to 56 MHz.


Ron

On 04/13/2016 05:55 AM, Alexander Levedahl wrote:

Hello,

Is there a list of sample rates and associated bandwidths supported 
by the B2xx series or a way to generate the list? E.g., the list for 
the X310 is to take 120MHz, 184.32MHz, and 200MHz and divide by an 
integer.


Thanks,
Alex






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B2xx rates

[Alexander Levedahl]

So, it can be set to say 50.3+pi/10MHz?


On Wed, Apr 13, 2016 at 10:55 AM, Ron Economos  wrote:

> Correction. The master clock rate can be set to anything from 5 MHz to 56
> MHz. The bandwidth is 200 kHz to 56 MHz.
>
> Ron
>
>
> On 04/13/2016 07:46 AM, Ron Economos wrote:
>
>> The B2X0 series has a programmable master clock. You can set it to
>> anything from 200 kHz to 56 MHz.
>>
>> Ron
>>
>> On 04/13/2016 05:55 AM, Alexander Levedahl wrote:
>>
>>> Hello,
>>>
>>> Is there a list of sample rates and associated bandwidths supported by
>>> the B2xx series or a way to generate the list? E.g., the list for the X310
>>> is to take 120MHz, 184.32MHz, and 200MHz and divide by an integer.
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>
>
> ___
> 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] B2xx rates

[Ron Economos]

Yes. I routinely set it to ((800 * 6) / 7) * 4 for DVB-T2 applications.

Ron

On 04/13/2016 08:32 AM, Alexander Levedahl wrote:

So, it can be set to say 50.3+pi/10MHz?


On Wed, Apr 13, 2016 at 10:55 AM, Ron Economos > wrote:


Correction. The master clock rate can be set to anything from 5
MHz to 56 MHz. The bandwidth is 200 kHz to 56 MHz.

Ron


On 04/13/2016 07:46 AM, Ron Economos wrote:

The B2X0 series has a programmable master clock. You can set
it to anything from 200 kHz to 56 MHz.

Ron

On 04/13/2016 05:55 AM, Alexander Levedahl wrote:

Hello,

Is there a list of sample rates and associated bandwidths
supported by the B2xx series or a way to generate the
list? E.g., the list for the X310 is to take 120MHz,
184.32MHz, and 200MHz and divide by an integer.

Thanks,
Alex




___
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] problem with gr-osmosdr so file

[Jason Matusiak]

> I tried blowing away osmosdr and rebuilding, but that doesn't seem 
tohelp. What am I missing here? It objdump on the culprit so, I see:



objdump -x /home/jmat/target/lib/libosmodsp.so.0.0.0


> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to 
handlesection `' [0x 1b]



BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: no group info for section


> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to 
handlesection `' [0x 2e]



objdump: /home/jmat/target/lib/libosmodsp.so.0.0.0: Bad value


> So it looks like a corrupted libosmodsp.so.0.0.0, but why can't 
Irebuild it???


Thought I would check in one more time to see if anyone has had any idea 
how to get past this.  If updated/upgraded gnuradio and no dice.  I've 
trying to do a git clone and install the osmosdr project and no dice.  
Ettus devices work fine, but as soon as I plug in a USB osmosdr device 
(like an RTL dongle), I get the issue from my original post.  Seems like 
a corrupted libosmodsp.so.0.0.0 library file, but I have been unable to 
fix it as of yet.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with gr-osmosdr so file

[Ron Economos]

I'm going to guess it's actually a problem with gr-iqbal. gr-iqbal has a 
submodule for libosmodsp, so the correct build procedure is:


git clone git://git.osmocom.org/gr-iqbal.git
cd gr-iqbal
git submodule init
git submodule update
mkdir build
cd build
cmake ..
make
sudo make install

Ron

On 04/13/2016 09:21 AM, Jason Matusiak wrote:
> I tried blowing away osmosdr and rebuilding, but that doesn't seem 
tohelp. What am I missing here? It objdump on the culprit so, I see:

> objdump -x /home/jmat/target/lib/libosmodsp.so.0.0.0
> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to 
handlesection `' [0x 1b]

> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: no group info for section
> BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to 
handlesection `' [0x 2e]

> objdump: /home/jmat/target/lib/libosmodsp.so.0.0.0: Bad value

> So it looks like a corrupted libosmodsp.so.0.0.0, but why can't 
Irebuild it???


Thought I would check in one more time to see if anyone has had any 
idea how to get past this.  If updated/upgraded gnuradio and no dice.  
I've trying to do a git clone and install the osmosdr project and no 
dice.  Ettus devices work fine, but as soon as I plug in a USB osmosdr 
device (like an RTL dongle), I get the issue from my original post.  
Seems like a corrupted libosmodsp.so.0.0.0 library file, but I have 
been unable to fix it as of yet.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with gr-osmosdr so file

[Jason Matusiak]

Gents, thanks for jumping in!


So in the OP case, the first option was chosen. Best is to just
download libosmodsp and rebuild it on its own. Rebuilding gr-iqbal
won't really do anything.


I ran pybombs uninstall libosmosdr-dsp and then pybombs install libosmosdr-dsp
(the older pybombs) and it all (un)installed fine.  I then ran sudo ldconfig
and tried my gnuradio script again, but got the same error are before.

I'm going to guess it's actually a problem with gr-iqbal. gr-iqbal has a 
submodule for > libosmodsp, so the correct build procedure is: I ran 
pybombs install gr-iqbal and sudo ldconfig, and it installed fine.  I 
ran gnuradio and still got the same errors. So unless I missed 
something, I sadly have more of an issue than it seemed :(.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with gr-osmosdr so file

[Sylvain Munaut]

gr-iqbal can work in two modes :

 - If it finds libosmodsp installed and available on the system, it
will use that and dynamic link to it
 - If it doesn't, then it can use a submodule checkout of it and just
directly build in the required .c file. In that mode, it won't link to
libosmodsp.so at all

So in the OP case, the first option was chosen. Best is to just
download libosmodsp and rebuild it on its own. Rebuilding gr-iqbal
won't really do anything.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B2xx rates

[Ian Buckley]

For what (little) it's worth I removed the H/W constraints in B2x0 that
forced a minimum of 5MHz master clock rate when UHD 3.9.x was released.
Running AD9361 at low clock rates isn't the best way to utilize its
capabilities but it may help for certain niche narrow band applications.

-Ian


On Wed, Apr 13, 2016 at 6:20 AM, Ron Economos  wrote:

> Yes. I routinely set it to ((800 * 6) / 7) * 4 for DVB-T2 applications.
>
> Ron
>
>
> On 04/13/2016 08:32 AM, Alexander Levedahl wrote:
>
> So, it can be set to say 50.3+pi/10MHz?
>
>
> On Wed, Apr 13, 2016 at 10:55 AM, Ron Economos  wrote:
>
>> Correction. The master clock rate can be set to anything from 5 MHz to 56
>> MHz. The bandwidth is 200 kHz to 56 MHz.
>>
>> Ron
>>
>>
>> On 04/13/2016 07:46 AM, Ron Economos wrote:
>>
>>> The B2X0 series has a programmable master clock. You can set it to
>>> anything from 200 kHz to 56 MHz.
>>>
>>> Ron
>>>
>>> On 04/13/2016 05:55 AM, Alexander Levedahl wrote:
>>>
 Hello,

 Is there a list of sample rates and associated bandwidths supported by
 the B2xx series or a way to generate the list? E.g., the list for the X310
 is to take 120MHz, 184.32MHz, and 200MHz and divide by an integer.

 Thanks,
 Alex


>>>
>>
>> ___
>> 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] Docker

[Nicholas McCarthy]

Sorry I'm a few days late to the Docker party (and I don't have the
original thread at hand).

Thanks, Stefan, for sharing your work.  I want to share something similar I
worked up for my stack when Martin released pybombs2 and exposed me to the
"deploy" function.

https://hub.docker.com/r/namccart/pybombs
https://hub.docker.com/r/namccart/pybombs-dev

All the stuff is on github, including a grc docker using the local X11
setup (as Jonathan described) with this pybombs install image.

https://github.com/namccart/docker_grc.git

I think it would be really helpful for the GNU Radio project to support a
standard, basic gnuradio docker install with uhd and grc enabled as well as
an example or two to demonstrate sane ways to run OOT modules on top of
that image.  As Ben mentioned, Docker seems like a pretty energy-efficient
way to approach support for systems like Windows and OSX going forward.
Not having used boot2docker personally, I won't say that it's necessarily
time to retire the live usb image, but I think Docker may evolve quickly
into a pretty obvious replacement, if it hasn't already.  I also appreciate
GNU Radio looking for ways to support users and potential users attempting
to build and deploy applications that reach beyond the immediate
environment of GNU Radio and its core devs.

One problem we have to face, though, is image size.  I'm trying to tackle
that problem by compressing the install for transactions over the wire and
then uncompressing locally for applications (using pybombs2, of course).
This is all a little awkward for docker distribution, but lots of things in
docker are a little awkward.  Developers could build on top by untarring
the prefix, pybombs installing extra recipes (possibly custom recipes) and
then using the deploy command again, all within the same Docker "RUN"
section.  Locally, if you docker build applications beginning with the same
commands to untar the image, then all applications can take advantage of
that layer (you'll have to untar the base image only one time regardless of
how many applications use the base image).  Alternatively, you can docker
run with cmd or entry set to untar the image (and then, presumably, you'll
want to commit the running container locally so you don't have to untar
again).

Does anyone have a better idea for bringing image size down without making
it impossible to build and deploy OOTs?  Those Bistromath images are pretty
tiny... I haven't really looked into the Alpine base image, either.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B2xx rates

[Alexander Levedahl]

Out of curiosity, when you say B2x0, did you mean to exclude the B205
mini?

Alex

On Wed, Apr 13, 2016 at 2:16 PM, Ian Buckley  wrote:

> For what (little) it's worth I removed the H/W constraints in B2x0 that
> forced a minimum of 5MHz master clock rate when UHD 3.9.x was released.
> Running AD9361 at low clock rates isn't the best way to utilize its
> capabilities but it may help for certain niche narrow band applications.
>
> -Ian
>
>
> On Wed, Apr 13, 2016 at 6:20 AM, Ron Economos  wrote:
>
>> Yes. I routinely set it to ((800 * 6) / 7) * 4 for DVB-T2
>> applications.
>>
>> Ron
>>
>>
>> On 04/13/2016 08:32 AM, Alexander Levedahl wrote:
>>
>> So, it can be set to say 50.3+pi/10MHz?
>>
>>
>> On Wed, Apr 13, 2016 at 10:55 AM, Ron Economos  wrote:
>>
>>> Correction. The master clock rate can be set to anything from 5 MHz to
>>> 56 MHz. The bandwidth is 200 kHz to 56 MHz.
>>>
>>> Ron
>>>
>>>
>>> On 04/13/2016 07:46 AM, Ron Economos wrote:
>>>
 The B2X0 series has a programmable master clock. You can set it to
 anything from 200 kHz to 56 MHz.

 Ron

 On 04/13/2016 05:55 AM, Alexander Levedahl wrote:

> Hello,
>
> Is there a list of sample rates and associated bandwidths supported by
> the B2xx series or a way to generate the list? E.g., the list for the X310
> is to take 120MHz, 184.32MHz, and 200MHz and divide by an integer.
>
> Thanks,
> Alex
>
>

>>>
>>> ___
>>> 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] B2xx rates

[Ian Buckley]

OK, to be precise {B200|B205|B200mini|B210} should have the same common
base platform in the FPGA including the interface used for the radio. B230
is different.
If wish to understand further the exact significance of the USRP model
numbers I suggest you start here: http://dilbert.com/strip/1992-04-06

On Wed, Apr 13, 2016 at 12:57 PM, Alexander Levedahl <
alexanderleved...@gmail.com> wrote:

> Out of curiosity, when you say B2x0, did you mean to exclude the B205
> mini?
>
> Alex
>
> On Wed, Apr 13, 2016 at 2:16 PM, Ian Buckley  wrote:
>
>> For what (little) it's worth I removed the H/W constraints in B2x0 that
>> forced a minimum of 5MHz master clock rate when UHD 3.9.x was released.
>> Running AD9361 at low clock rates isn't the best way to utilize its
>> capabilities but it may help for certain niche narrow band applications.
>>
>> -Ian
>>
>>
>> On Wed, Apr 13, 2016 at 6:20 AM, Ron Economos  wrote:
>>
>>> Yes. I routinely set it to ((800 * 6) / 7) * 4 for DVB-T2
>>> applications.
>>>
>>> Ron
>>>
>>>
>>> On 04/13/2016 08:32 AM, Alexander Levedahl wrote:
>>>
>>> So, it can be set to say 50.3+pi/10MHz?
>>>
>>>
>>> On Wed, Apr 13, 2016 at 10:55 AM, Ron Economos  wrote:
>>>
 Correction. The master clock rate can be set to anything from 5 MHz to
 56 MHz. The bandwidth is 200 kHz to 56 MHz.

 Ron


 On 04/13/2016 07:46 AM, Ron Economos wrote:

> The B2X0 series has a programmable master clock. You can set it to
> anything from 200 kHz to 56 MHz.
>
> Ron
>
> On 04/13/2016 05:55 AM, Alexander Levedahl wrote:
>
>> Hello,
>>
>> Is there a list of sample rates and associated bandwidths supported
>> by the B2xx series or a way to generate the list? E.g., the list for the
>> X310 is to take 120MHz, 184.32MHz, and 200MHz and divide by an integer.
>>
>> Thanks,
>> Alex
>>
>>
>

 ___
 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] B2xx rates

[Martin Braun]

Just want to confirm this. The correct rate range is from 220 kHz to
61.44 MHz, or 30.72 MHz for 2x2 mode. The *analog* bandwidth is capped
at 56 MHz.

M



On 04/13/2016 11:16 AM, Ian Buckley wrote:
> For what (little) it's worth I removed the H/W constraints in B2x0 that
> forced a minimum of 5MHz master clock rate when UHD 3.9.x was released.
> Running AD9361 at low clock rates isn't the best way to utilize its
> capabilities but it may help for certain niche narrow band applications.
> 
> -Ian
> 
> 
> On Wed, Apr 13, 2016 at 6:20 AM, Ron Economos  > wrote:
> 
> Yes. I routinely set it to ((800 * 6) / 7) * 4 for DVB-T2
> applications.
> 
> Ron
> 
> 
> On 04/13/2016 08:32 AM, Alexander Levedahl wrote:
>> So, it can be set to say 50.3+pi/10MHz?
>>
>>
>> On Wed, Apr 13, 2016 at 10:55 AM, Ron Economos > > wrote:
>>
>> Correction. The master clock rate can be set to anything from
>> 5 MHz to 56 MHz. The bandwidth is 200 kHz to 56 MHz.
>>
>> Ron
>>
>>
>> On 04/13/2016 07:46 AM, Ron Economos wrote:
>>
>> The B2X0 series has a programmable master clock. You can
>> set it to anything from 200 kHz to 56 MHz.
>>
>> Ron
>>
>> On 04/13/2016 05:55 AM, Alexander Levedahl wrote:
>>
>> Hello,
>>
>> Is there a list of sample rates and associated
>> bandwidths supported by the B2xx series or a way to
>> generate the list? E.g., the list for the X310 is to
>> take 120MHz, 184.32MHz, and 200MHz and divide by an
>> integer.
>>
>> Thanks,
>> Alex
>>
>>
>>
>>
>> ___
>> 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] problem with gr-osmosdr so file

[Martin Braun]

I believe we have the PyBOMBS dependency issues sorted out, so if you
use pybombs (and e.g. 'pybombs rebuild') it will do stuff in the right
order.

M

On 04/13/2016 09:35 AM, Ron Economos wrote:
> I'm going to guess it's actually a problem with gr-iqbal. gr-iqbal has a
> submodule for libosmodsp, so the correct build procedure is:
> 
> git clone git://git.osmocom.org/gr-iqbal.git
> cd gr-iqbal
> git submodule init
> git submodule update
> mkdir build
> cd build
> cmake ..
> make
> sudo make install
> 
> Ron
> 
> On 04/13/2016 09:21 AM, Jason Matusiak wrote:
>> > I tried blowing away osmosdr and rebuilding, but that doesn't seem
>> to help. What am I missing here? It objdump on the culprit so, I see:
>> > objdump -x /home/jmat/target/lib/libosmodsp.so.0.0.0
>> > BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to
>> handle section `' [0x 1b]
>> > BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: no group info for section
>> > BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to
>> handle section `' [0x 2e]
>> > objdump: /home/jmat/target/lib/libosmodsp.so.0.0.0: Bad value
>>
>> > So it looks like a corrupted libosmodsp.so.0.0.0, but why can't
>> I rebuild it???
>>
>> Thought I would check in one more time to see if anyone has had any
>> idea how to get past this.  If updated/upgraded gnuradio and no dice. 
>> I've trying to do a git clone and install the osmosdr project and no
>> dice.  Ettus devices work fine, but as soon as I plug in a USB osmosdr
>> device (like an RTL dongle), I get the issue from my original post. 
>> Seems like a corrupted libosmodsp.so.0.0.0 library file, but I have
>> been unable to fix it as of yet.
>>
> 
> 
> 
> ___
> 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] raspi FAQ/HOWTO/recipe ??????

[Jean Luc]

I've been trying as well to use GR on RPi (model 3), the ultimate purpose
would be radio astronomy. A smaller form factor such as RPI's makes a
remote installation more palatable than a full PC.

I wasn't able to compile it on RPi but compromised on using a more recent
version (3.7.9-3~bpo8+1) taken from jessie-backports. The steps are below.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
8B48AD6246925553 7638D0442B90D010

sudo vi /etc/apt/sources.list and  add the following line:
deb http://ftp.debian.org/debian jessie-backports main

sudo apt-get update
sudo apt-get -t jessie-backports install gnuradio



On the positive side, GR works on RPi3. However, it does keep one core to
100% in many cases. This was with input from an SDR with the 2Msps rate,
though. Actually, one more problem: audio output. That part didn't work
("check topology failed on audio_alsa_sink"); I posted a message on the
list the other day. I cannot say it's a GR problem, could be mine; I have
yet to understand what the problem is.

JL.

On Wed, Apr 13, 2016 at 7:45 AM, Rob Roschewsk  wrote:

> Marcus,
>
> Thanks for responding.
>
> I'm looking to build a headless FM receiver to record and stream public
> service communication (fire, police, etc.). We will stream as many channels
> as possible that fall into a given passband.
>
> I already have a system running on a PC and now would like to port it to
> the PI.
>
> I understand it maybe an "up hill" path, but the thought is to deploy
> multiple inexpensive units around a geographic area all feeding a central
> streaming server.
>
> The Pi is running Raspian Jesse  I started with the distribution
> packages but ran into problems right out of the blocks and thought it would
> be best to use the latest code before asking questions :)
>
> I understand cross compiling is the way to go.
>
> Since I brought it up, here was the error I saw when I tried to run the
> script that runs on the PC but fails spectacularly on the raspberry pi with
> the precompiled packages 
>
> roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py -s 49 noaa.xml
> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0 <0030070030>
> -unknown
>
> high=16250 low=16240 span=10
> center=16245
> gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy
> Using device #0 Realtek RTL2838UHIDIR SN: 0108
> Found Elonics E4000 tuner
> Exact sample rate is: 100.026491 Hz
> Using Volk machine: generic_orc
> VOLK: Error allocating memory (posix_memalign: 22)
> VOLK: Error allocating memory (posix_memalign: 22)
> VOLK: Error allocating memory (posix_memalign: 22)
> Segmentation fault
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[Marcus D. Leech]

On 04/13/2016 11:05 PM, Jean Luc wrote:
I've been trying as well to use GR on RPi (model 3), the ultimate 
purpose would be radio astronomy. A smaller form factor such as RPI's 
makes a remote installation more palatable than a full PC.


I wasn't able to compile it on RPi but compromised on using a more 
recent version (3.7.9-3~bpo8+1) taken from jessie-backports. The steps 
are below.


sudo apt-key adv --keyserver keyserver.ubuntu.com
 --recv-keys 8B48AD6246925553
7638D0442B90D010

sudo vi /etc/apt/sources.list and  add the following line:
deb http://ftp.debian.org/debian jessie-backports main

sudo apt-get update
sudo apt-get -t jessie-backports install gnuradio



On the positive side, GR works on RPi3. However, it does keep one core 
to 100% in many cases. This was with input from an SDR with the 2Msps 
rate, though. Actually, one more problem: audio output. That part 
didn't work ("check topology failed on audio_alsa_sink"); I posted a 
message on the list the other day. I cannot say it's a GR problem, 
could be mine; I have yet to understand what the problem is.


JL.
I'll point out that ARCH generally has up-to-date packages for this 
stuff, including for most of the ARM-based SBCs.


I run ARCH on various Odroid platforms, running radio-astronomy GR 
flow-graphs, with good success.  I run these "headless", without any
  graphical display from the Odroid--it's just the digital radio + 
processing platform.





On Wed, Apr 13, 2016 at 7:45 AM, Rob Roschewsk > wrote:


Marcus,

Thanks for responding.

I'm looking to build a headless FM receiver to record and stream
public service communication (fire, police, etc.). We will stream
as many channels as possible that fall into a given passband.

I already have a system running on a PC and now would like to port
it to the PI.

I understand it maybe an "up hill" path, but the thought is to
deploy multiple inexpensive units around a geographic area all
feeding a central streaming server.

The Pi is running Raspian Jesse  I started with the
distribution packages but ran into problems right out of the
blocks and thought it would be best to use the latest code before
asking questions :)

I understand cross compiling is the way to go.

Since I brought it up, here was the error I saw when I tried to
run the script that runs on the PC but fails spectacularly on the
raspberry pi with the precompiled packages 

roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py
 -s 49 noaa.xml
linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0
-unknown

high=16250 low=16240 span=10
center=16245
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri
hackrf bladerf rfspace airspy
Using device #0 Realtek RTL2838UHIDIR SN: 0108
Found Elonics E4000 tuner
Exact sample rate is: 100 .026491 Hz
Using Volk machine: generic_orc
VOLK: Error allocating memory (posix_memalign: 22)
VOLK: Error allocating memory (posix_memalign: 22)
VOLK: Error allocating memory (posix_memalign: 22)
Segmentation fault



___
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] raspi FAQ/HOWTO/recipe ??????

[Anon Lister]

Have you seen [1]? it looks like he hit all the same issues I did when
building on a pi3(raspberrian, not Debian but you might run into some of
the same). The newer 3, as long as you give it some swap space can get the
compile done in only a few hours with a make -j 3 or 4.

http://lukeberndt.com/2016/compiling-gnuradio-on-a-raspberry-pi/
On Apr 12, 2016 10:25 PM, "Rob Roschewsk"  wrote:

> Hi all,
>
> I'd like to compile GR from source for a raspberry pi (arm) ... I know
> there are some flags that need to be passed to cmake but I can't find a
> complete list ... or at least a consistent list
>
> Is there a reference I could use???
>
> Thanks!
>
> --> Rob, KA2PBT
>
> ___
> 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] Question about packet sequence

[SangHyuk Kim]

Hi all,

I'm wondering about packet sequence.

USRP sends UDP packets which is result of sampling to host PC.


UDP packets tend to be out-of-order at high speed.

My question is:
- When USRP sends UDP packet high speed to host PC, the sequence of these
packets is important ?
- Do host PC reorder these packet ? (Do PC waits for certain packet ?)

Thanks.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about packet sequence

[Laur Joost]

While UDP gives no order guarantee, the USRP still sends them out in order.
The uncertainty comes in cases where routing happens between the USRP and
the host. Still, within a LAN you can expect with relative certainty, that
packets will still arrive in order, as there is usually only one route from
device to host.

1. The sequence of the packets is important. It would be rather bad if two
bunches of samples in your IQ stream suddenly switched places.
2. The host PC network stack does no reordering. It can't, by definition of
UDP, as there's nothing to reorder by.
3. AFAIK, the UHD also does no reordering. However, the packets arriving
from the USRP __are__ numbered. If UHD detects a missing packet, it* prints
a D (to signify a Dropped packet) to stdout, and emits a new rx_time tag
for the next packet.

* Actually, I don't know whether that's UHD or gr-uhd that does this.

Hope it helped
Laur

2016-04-14 8:41 GMT+03:00 SangHyuk Kim :

> Hi all,
>
> I'm wondering about packet sequence.
>
> USRP sends UDP packets which is result of sampling to host PC.
>
>
> UDP packets tend to be out-of-order at high speed.
>
> My question is:
> - When USRP sends UDP packet high speed to host PC, the sequence of these
> packets is important ?
> - Do host PC reorder these packet ? (Do PC waits for certain packet ?)
>
> Thanks.
>
>
>
> ___
> 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] Question about packet sequence

[SangHyuk Kim]

Hi,

I counted number of sending packet in code and wireshark.

I send 400Bytes packet, but wireshark packet be shown about 1500Bytes.

While coded counter shows about 50,000 packets (data packet), wireshark
captured 450,000 packets.

I expected one send() be represented one packet at wireshark.

Why does number of packet shown in wireshark is differ from transmitted
packets ?

Thanks for your help.

2016-04-14 15:20 GMT+09:00 Laur Joost :

> While UDP gives no order guarantee, the USRP still sends them out in
> order. The uncertainty comes in cases where routing happens between the
> USRP and the host. Still, within a LAN you can expect with relative
> certainty, that packets will still arrive in order, as there is usually
> only one route from device to host.
>
> 1. The sequence of the packets is important. It would be rather bad if two
> bunches of samples in your IQ stream suddenly switched places.
> 2. The host PC network stack does no reordering. It can't, by definition
> of UDP, as there's nothing to reorder by.
> 3. AFAIK, the UHD also does no reordering. However, the packets arriving
> from the USRP __are__ numbered. If UHD detects a missing packet, it* prints
> a D (to signify a Dropped packet) to stdout, and emits a new rx_time tag
> for the next packet.
>
> * Actually, I don't know whether that's UHD or gr-uhd that does this.
>
> Hope it helped
> Laur
>
> 2016-04-14 8:41 GMT+03:00 SangHyuk Kim :
>
>> Hi all,
>>
>> I'm wondering about packet sequence.
>>
>> USRP sends UDP packets which is result of sampling to host PC.
>>
>>
>> UDP packets tend to be out-of-order at high speed.
>>
>> My question is:
>> - When USRP sends UDP packet high speed to host PC, the sequence of these
>> packets is important ?
>> - Do host PC reorder these packet ? (Do PC waits for certain packet ?)
>>
>> Thanks.
>>
>>
>>
>> ___
>> 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