Re: [Discuss-gnuradio] Pybomb installation error

[Anon Lister]

How much RAM do you have? With higher parallelization, uhd requires a good
bit of RAM during compile. Idk what pybombs does to calculate the level to
use, if you can override it try with only 1 thread being passed to make.
On Apr 21, 2016 8:52 PM, "Shahnaz Shirazi"  wrote:

Hi,
I updated Pybombs to latest today and then run install command.
Got bellow error

c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: ***
[lib/CMakeFiles/uhd.dir/transport/nirio/niusrprio_session.cpp.o] Error 4
make[2]: *** Waiting for unfinished jobs
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2

PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
PyBombs.monitor_process() - DEBUG - Return value: 2

PyBombs.Packager.source - ERROR - Problem occurred while building package
uhd:
Process returned value: 2

PyBombs.install - ERROR - Error installing package uhd. Aborting.

Bug report is attached

Thanks,
Shahnaz


On Thu, Apr 21, 2016 at 8:53 AM, West, Nathan 
wrote:

> This was a bug that's been fixed recently.
> https://github.com/gnuradio/pybombs/commit/38ed9d169ed67ef090e6015b07c4918f7c112209
>
> On Thu, Apr 21, 2016 at 11:23 AM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>>
>> I ran it, but it thinks that -v is a recipe and it errors out there.  If
>> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
>> get:
>> 
>> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
>> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
>> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
>> PyBombs.Packager.source - DEBUG - In cwd -
>> /home/jmat/gnuradio/src/uhd/build
>> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
>> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" 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
>> uhd:
>> Process returned value: 1
>> PyBombs.install - ERROR - Error installing package uhd. Aborting.
>> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
>> 
>>
>>
>> ___
>> 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] Pybomb installation error

[Shahnaz Shirazi]

Hi,
I updated Pybombs to latest today and then run install command.
Got bellow error

c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: ***
[lib/CMakeFiles/uhd.dir/transport/nirio/niusrprio_session.cpp.o] Error 4
make[2]: *** Waiting for unfinished jobs
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2
PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
PyBombs.monitor_process() - DEBUG - Return value: 2
PyBombs.Packager.source - ERROR - Problem occurred while building package
uhd:
Process returned value: 2
PyBombs.install - ERROR - Error installing package uhd. Aborting.

Bug report is attached

Thanks,
Shahnaz


On Thu, Apr 21, 2016 at 8:53 AM, West, Nathan 
wrote:

> This was a bug that's been fixed recently.
> https://github.com/gnuradio/pybombs/commit/38ed9d169ed67ef090e6015b07c4918f7c112209
>
> On Thu, Apr 21, 2016 at 11:23 AM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>>
>> I ran it, but it thinks that -v is a recipe and it errors out there.  If
>> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
>> get:
>> 
>> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
>> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
>> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
>> PyBombs.Packager.source - DEBUG - In cwd -
>> /home/jmat/gnuradio/src/uhd/build
>> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
>> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" 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
>> uhd:
>> Process returned value: 1
>> PyBombs.install - ERROR - Error installing package uhd. Aborting.
>> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
>> 
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>


README.Bugs
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Anon Lister]

You'll prolly run into same prob with hackrf. I did when I tried to use
pybombs for some reason the other day. It's looking for the cmakelists file
in the root, it's in host or something similar. I ended up just building
everything by hand. And deleting pybombs.
On Apr 21, 2016 7:20 PM, "Shahnaz Shirazi"  wrote:

> as suggested run it without gr-osmosdr  and with -v
> below is the error.
>
> PyBombs.Packager.source - DEBUG - In cwd - /home/shahnaz/Lab3/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/shahnaz/Lab3  -Wno-dev'
> CMake Error: The source directory "/home/shahnaz/Lab3/src/uhd" 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
> uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd. Aborting.
>
> same error but this time for UHD folder.
> going to uninstall the pybombs and try it again.
>
>
> On Thu, Apr 21, 2016 at 8:06 AM, James Humphries <
> james.humphr...@ettus.com> wrote:
>
>> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Shahnaz Shirazi]

as suggested run it without gr-osmosdr  and with -v
below is the error.

PyBombs.Packager.source - DEBUG - In cwd - /home/shahnaz/Lab3/src/uhd/build
PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_INSTALL_PREFIX=/home/shahnaz/Lab3  -Wno-dev'
CMake Error: The source directory "/home/shahnaz/Lab3/src/uhd" 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
uhd:
Process returned value: 1
PyBombs.install - ERROR - Error installing package uhd. Aborting.

same error but this time for UHD folder.
going to uninstall the pybombs and try it again.


On Thu, Apr 21, 2016 at 8:06 AM, James Humphries 
wrote:

> 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] Feedback with Transmitters and Receiver

[Derek Kozel]

Hi Pavan,

This is a USRP/UHD question really so I'm including the usrp-users mailing
list. If you're not already the list already then you should certainly join
as that's a better resource for questions about UHD/USRPs.

1) Any SMA cable will work. For the best performance their electrical
lengths should be the same. In practice this usually means equal physical
lengths of the same type of coax. This ensures that the signals arrive at
the same time (and phase).

2) Most radio systems don't have GPS timebases available and use various
protocol level methods for aligning their clocks, if needed. In a very
simple system the receiver could simply listen continuously until it
receives a full message, then transmits a response if needed. Look up Time
Division Multiplexing and Frequency Division Multiplexing. This is an area
where there are nearly as many possibilities as there are radio systems.

3) Once you connect all the Octoclock signals then in GNU Radio you can
select the Clock and Time sources to be External and the Sync to be Unknown
PPS. Your pair of units connected via a MIMO cable are special, the master
should have the External time and clock sources, the companion USRP should
have MIMO selected for time and clock. The Sync should still be Unknown PPS.

Here's a page that talks about synchronization of USRPs. Read this, get
your hardware all setup, and try setting up a basic GRC flowgraph with your
three radios. Think of what tests you could use to verify that both your
MIMO cabled radios are transmitting at the same time. You should look into
timed commands in UHD and tags in GNU Radio.

http://files.ettus.com/manual/page_sync.html
https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf

If this is your first use of USRPs and GNU Radio then I'd suggest reading
through the tutorials available online and not get too focused on MIMO
until you feel comfortable with the basics of the environment and tools
that you have.

http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

Once you've given this a try let us know if you have additional questions.

Regards,
Derek


On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli 
wrote:

> Hi Derek,
>
> Thanks for getting back to me. So, I do have an Octoclock, so I think
> we're getting somewhere and this is starting to make more sense. A few
> follow up questions:
>
> 1.) Do I need special cables to connect all of the units to the Octoclock,
> or are they robust SMA cables?
>
> 2.) I feel like this seems particularly involved to send a signal from a
> transmitter to a receiver. I am assuming most non-MIMO, non-beamforming
> related tasks have always used your second option of using the GPSDO kits?
> I purchased an Octoclock knowing I would do MIMO experiments, but obviously
> I'm guessing more conventional communication techniques (like a simple BPSK
> or QPSK between tx and rx) would have probably used the GPSDO kits?
>
> 3.) Once I connect them all to the Octoclock, then I don't need to a
> protocol level time synchronization, right? Once they're all synchronized
> and I see that in the plots, then I guess the next step would be to figure
> out how to implement my actual feedback loop. At that point, then I would
> need to figure out how to do burst mode to transmit and receiver timed
> signals? Would this end up needing to be one flow graph or would I have to
> use two flow graphs? (One for to and one for rx, the way I am doing it now)
>
> Thank you again for all the help. I think I'm starting to understand what
> I need in the setup.
>
> On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel 
> wrote:
>
>> Hello Pavan,
>>
>> I think we both are starting to understand the setup and the problem.
>> Here are the two hardware solutions:
>>
>> Connect a shared 1PPS signal to *both* the master USRP of your MIMO
>> cabled pair and to the receiver (For example using an octoclock:
>> https://www.ettus.com/product/details/OctoClock-G)
>>
>> OR
>>
>> Connect GPS referenced 1PPS signals to both the master USRP of your MIMO
>> cabled pair and the receiver (For example using two of the GPSDO kits:
>> https://www.ettus.com/product/details/GPSDO-KIT)
>>
>>
>> There are many ways of implementing a protocol level time synchronization
>> in software/DSP. The paper I linked to talks about one way, there are
>> certainly others. I do not know of any example projects implementing them
>> though so you would have to develop your own.
>>
>> Regards,
>> Derek
>>
>> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli 
>> wrote:
>>
>>> Hi Derek,
>>>
>>> I'll answer your questions in-line, because I think what you are saying
>>> is beginning to make me understand what I need:
>>>
>>>
>>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel 
>>> wrote:
>>>
 Hello Pavan,

 Are you trying to create a shared timebase between the two USRPs
 without having a shared 1PPS or GPS 

[Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Hi Derek,

Thanks for getting back to me. So, I do have an Octoclock, so I think we're
getting somewhere and this is starting to make more sense. A few follow up
questions:

1.) Do I need special cables to connect all of the units to the Octoclock,
or are they robust SMA cables?

2.) I feel like this seems particularly involved to send a signal from a
transmitter to a receiver. I am assuming most non-MIMO, non-beamforming
related tasks have always used your second option of using the GPSDO kits?
I purchased an Octoclock knowing I would do MIMO experiments, but obviously
I'm guessing more conventional communication techniques (like a simple BPSK
or QPSK between tx and rx) would have probably used the GPSDO kits?

3.) Once I connect them all to the Octoclock, then I don't need to a
protocol level time synchronization, right? Once they're all synchronized
and I see that in the plots, then I guess the next step would be to figure
out how to implement my actual feedback loop. At that point, then I would
need to figure out how to do burst mode to transmit and receiver timed
signals? Would this end up needing to be one flow graph or would I have to
use two flow graphs? (One for to and one for rx, the way I am doing it now)

Thank you again for all the help. I think I'm starting to understand what I
need in the setup.

On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel > wrote:

> Hello Pavan,
>
> I think we both are starting to understand the setup and the problem. Here
> are the two hardware solutions:
>
> Connect a shared 1PPS signal to *both* the master USRP of your MIMO cabled
> pair and to the receiver (For example using an octoclock:
> https://www.ettus.com/product/details/OctoClock-G)
>
> OR
>
> Connect GPS referenced 1PPS signals to both the master USRP of your MIMO
> cabled pair and the receiver (For example using two of the GPSDO kits:
> https://www.ettus.com/product/details/GPSDO-KIT)
>
>
> There are many ways of implementing a protocol level time synchronization
> in software/DSP. The paper I linked to talks about one way, there are
> certainly others. I do not know of any example projects implementing them
> though so you would have to develop your own.
>
> Regards,
> Derek
>
> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli  > wrote:
>
>> Hi Derek,
>>
>> I'll answer your questions in-line, because I think what you are saying
>> is beginning to make me understand what I need:
>>
>>
>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel > > wrote:
>>
>>> Hello Pavan,
>>>
>>> Are you trying to create a shared timebase between the two USRPs without
>>> having a shared 1PPS or GPS reference? You are still not using enough
>>> detail for us to understand fully.
>>>
>>
>> To clarify, my setup is two USRPs connected via MIMO cable, and then
>> another USRP acting as a receiver. So are you asking whether I'm trying to
>> create a shared timebase between the two-USRP *unit* (because they are
>> MIMO cabled) and the receiving USRP without having a shared 1 PPS or GPS
>> reference? I think my answer to that must be yes, because I have not done
>> anything else but connect them to the computer via ethernet and just have
>> two of them connected via MIMO cable and the other one by itself. I'm
>> assuming I need to have a shared reference between the transmit USRPs and
>> the receive USRP, so how would I be able to do that? This could certainly
>> be one of my problems.
>>
>>>
>>> In Figure 5 both USRPs are connected with a MIMO cable and so have both
>>> shared frequency and time bases. What is your weight block doing to the
>>> sample stream? Is it a time delay block? I don't know what gnuradio would
>>> do if you specified 10*sample_rate as the delay there as that's likely to
>>> be a very large number of samples.
>>>
>>
>> My weight block is applying a normalized magnitude phase correction to
>> each antenna's transmitted signal, so, yes, it is essentially creating a
>> time delay. Each weight is a complex value with magnitude 1 and a
>> calculated phase. You are saying this could be a problem if it's
>> calculating a value that is too high?
>>
>>>
>>> If you have both USRPs connected with a time synchronization (shared
>>> 1PPS, GPSDO, or MIMO cable) and have your flowgraph configured correctly,
>>> then you can just use timed commands to the USRP_alpha to start
>>> transmitting at time X and USRP_beta to start receiving at time X and you
>>> will see your signal. You can then move to using burst mode using tags to
>>> define the number of samples to send/receive along with timed commands to
>>> send/receive bursts of samples. This works because the clocks in both USRPs
>>> will be aligned to each other.
>>>
>>
>> I feel like there are two steps here. First, I need to get the
>> 

Re: [Discuss-gnuradio] AMD HSA and digital signal processing

[Tom Rondeau]

On Thu, Apr 21, 2016 at 2:38 PM, Piotr Krysik  wrote:

> Hi all,
>
> Lately I came across something called HSA (Heterogeneous System
> Architecture) that is used in new AMD APU's (CPU's with integrated graphics
> processor). In general it enables CPU and GPU cores to share the same
> memory space. Exchange of data between them is therefore a matter of
> sending a pointer.
>
> Many times I've heard that bottleneck of data transfer between CPU and GPU
> is main obstacle for application of massive GPU's processing power for
> signal processing. HSA seems to be the solution.
>
> The idea is great but what surprises me is that although AMD processors
> with HSA are present for over two years I haven't heard of anyone using it.
>
> GNU Radio could potentially benefit from HSA. But have anyone on the list
> used it? If yes - what was your experience?
>
> P.S. I've sent the same e-mail few hours earlier but as of now it hasn't
> appeared on the list. I'm sorry in advance if the post is doubled.
>
> --
> Best Regards,
> Piotr Krysik
>


Piotr,

Yes, I'm aware of the HSA efforts, and yes, there is some possibly
significant advantages for GNU Radio here to make use of these kinds of
co-processors.

One reason you haven't seen much discussion of this is because you have it
slightly wrong about this being present in AMD processors for 2 years.
While AMD has had the concepts there for a while, the HSA Foundation only
recently certified their architecture, and AMD's processor Carrizo that
came out last year (and has recently started showing up in off the shelf
systems) is the first with the official HSA architecture. This info is
straight from the HSA Foundation's president from a conference in mid March.

It can be difficult to get too excited about a technology like that which
is still evolving and limited to a small subset of processors.

But it would be interesting now, for instance, to see someone look into
experimenting with a "volk-hsa" that starts to see about taking advantage
of the concept.

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

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

Hello Pavan,

I think we both are starting to understand the setup and the problem. Here
are the two hardware solutions:

Connect a shared 1PPS signal to *both* the master USRP of your MIMO cabled
pair and to the receiver (For example using an octoclock:
https://www.ettus.com/product/details/OctoClock-G)

OR

Connect GPS referenced 1PPS signals to both the master USRP of your MIMO
cabled pair and the receiver (For example using two of the GPSDO kits:
https://www.ettus.com/product/details/GPSDO-KIT)


There are many ways of implementing a protocol level time synchronization
in software/DSP. The paper I linked to talks about one way, there are
certainly others. I do not know of any example projects implementing them
though so you would have to develop your own.

Regards,
Derek

On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli 
wrote:

> Hi Derek,
>
> I'll answer your questions in-line, because I think what you are saying is
> beginning to make me understand what I need:
>
>
> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel 
> wrote:
>
>> Hello Pavan,
>>
>> Are you trying to create a shared timebase between the two USRPs without
>> having a shared 1PPS or GPS reference? You are still not using enough
>> detail for us to understand fully.
>>
>
> To clarify, my setup is two USRPs connected via MIMO cable, and then
> another USRP acting as a receiver. So are you asking whether I'm trying to
> create a shared timebase between the two-USRP *unit* (because they are
> MIMO cabled) and the receiving USRP without having a shared 1 PPS or GPS
> reference? I think my answer to that must be yes, because I have not done
> anything else but connect them to the computer via ethernet and just have
> two of them connected via MIMO cable and the other one by itself. I'm
> assuming I need to have a shared reference between the transmit USRPs and
> the receive USRP, so how would I be able to do that? This could certainly
> be one of my problems.
>
>>
>> In Figure 5 both USRPs are connected with a MIMO cable and so have both
>> shared frequency and time bases. What is your weight block doing to the
>> sample stream? Is it a time delay block? I don't know what gnuradio would
>> do if you specified 10*sample_rate as the delay there as that's likely to
>> be a very large number of samples.
>>
>
> My weight block is applying a normalized magnitude phase correction to
> each antenna's transmitted signal, so, yes, it is essentially creating a
> time delay. Each weight is a complex value with magnitude 1 and a
> calculated phase. You are saying this could be a problem if it's
> calculating a value that is too high?
>
>>
>> If you have both USRPs connected with a time synchronization (shared
>> 1PPS, GPSDO, or MIMO cable) and have your flowgraph configured correctly,
>> then you can just use timed commands to the USRP_alpha to start
>> transmitting at time X and USRP_beta to start receiving at time X and you
>> will see your signal. You can then move to using burst mode using tags to
>> define the number of samples to send/receive along with timed commands to
>> send/receive bursts of samples. This works because the clocks in both USRPs
>> will be aligned to each other.
>>
>
> I feel like there are two steps here. First, I need to get the
> transmitting USRPs (which are conneced via MIMO cable) to time sync to each
> other (which I believe I have done through using USRP sink in GRC and
> setting the second channels time and clock to MIMO cable?), and second, I
> need to get the receive USRP to receive at the same time. So, just as
> above, I need to get my receive USRP to be on the same time as my transmit
> USRPs? Once I'm able to do that, then I can do burst mode to transmit and
> receive timed signals, as you are mentioning?
>
>>
>> If you do *NOT* have a shared time source for each radio, for instance
>> they are far apart and do not have GPS references, then you need to do some
>> sort of protocol level alignment to create a shared understanding of time
>> between them. A frequently used method is for USRP_alpha to transmit a
>> beacon with a known period (say once every 10 seconds). All other USRPs
>> then receive for longer than 10 seconds to be guaranteed to receive the
>> beacon (assuming they're within range of the transmission). When the
>> receiving USRPs detect the incoming beacon they align their local time to
>> the master (Beacon transmitting) USRP.
>>
>
> I guess a similar question to the above: can I have a shared time source
> between the transmit USRPs (which are already MIMO cabled to each other)
> and the receive USRP? It seems like that would be easier to do than going
> through this protocol level alignment, but maybe it's not possible given my
> setup.
>
>>
>> Here's a quick paper talking about this topic. The technique is widely
>> used.
>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>>
>>
>> I hope this helps and is applicable to your need. If you have 

Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?

[Michael Skaggs]

Aha! You were correct. I was parsing the header incorrectly. However, even
after parsing, and the more accurate values (now accurate to 10e-6), it
appears the recorded RF data sets are still are offset from each other by
an amount of nearly 2.5e-3 seconds. Any idea why this would be? It's
strange, especially considering that the are synchronized to the same PPS,
and I think the time is with reference to the pulse.

Michael

Michael Skaggs
M.S. - Computer Engineering
LinkedIn  | Resume
 | Research Cluster 
University of Maryland, Baltimore County

On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech  wrote:

> On 04/21/2016 11:41 AM, Michael Skaggs wrote:
>
>> I'm trying to time/sample synchronize RF recordings with two B200minis. I
>> am using the detached Metadata File Sink in GRC. Both recordings are at
>> 30MSps and both B200mini boards are synchronized to the same 1PPS signal.
>>
>> My issue is this, when I extract the data from the Metadata header file,
>> the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which,
>> with a recording at 30MSps, this will only give me a sample alignment
>> accuracy to 10e-4(s)*30(MS/s) = 30,000 samples.
>>
>> If I'm attempting to align the two recordings by samples or time, this is
>> not nearly accurate enough. Is there a way that I can get more accuracy out
>> of my metadata header or a way that I can synchronize the recordings of
>> these B200minis?
>>
>> Thanks,
>> Michael
>>
>> The precision of the timestamps from UHD should have a precision of
> whatever the master-clock is on the device--how are you interpreting
>   the rx_time tag?  It's two parts--a uint64 with the full-seconds
> portion, and a double-precision float for the fractional part.
>
>
>
> ___
> 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] AMD HSA and digital signal processing

[Piotr Krysik]

Hi all,

Lately I came across something called HSA (Heterogeneous System Architecture) 
that is used in new AMD APU's (CPU's with integrated graphics processor). In 
general it enables CPU and GPU cores to share the same memory space. Exchange 
of data between them is therefore a matter of sending a pointer.

Many times I've heard that bottleneck of data transfer between CPU and GPU is 
main obstacle for application of massive GPU's processing power for signal 
processing. HSA seems to be the solution.

The idea is great but what surprises me is that although AMD processors with 
HSA are present for over two years I haven't heard of anyone using it.

GNU Radio could potentially benefit from HSA. But have anyone on the list used 
it? If yes - what was your experience?

P.S. I've sent the same e-mail few hours earlier but as of now it hasn't 
appeared on the list. I'm sorry in advance if the post is doubled.

--
Best Regards,
Piotr Krysik


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

Re: [Discuss-gnuradio] Multiple Inputs in Tagged Stream Block

[Jingyi Sun]

Hi Martin,

I did more tests, including* trying to recreate tagged_stream_mux* as an
out-of-tree block. My block is called mux, but everything else (.cc, .c,
.xml), are exactly the same. I copied and pasted everything from github,
minus the name.

*It gives me the same error. *

I suspect the source code that my installed binary version of GNU Radio is
based on is different from the one used to originally create
tagged_stream_mux block that comes with GNU Radio.

Do you know if there is a specific person I can contact who would know
about tagged_stream_block source code? Or do you think there's something
else I haven't thought of.

I'm not sure what else I can try right now, and would be willing to try
anything you (or anyone else) might have to suggest.

Thanks,
Jenny


On Thu, Apr 21, 2016 at 2:02 PM, Martin Braun 
wrote:

> On 04/20/2016 04:48 PM, Jingyi Sun wrote:
> > tagged_stream_mux works when substituted for my block, so I think all of
> > my inputs are tagged streams. Also, my inputs are coming from the
> > outputs of OFDM_frame_equalizer, which I think propagates tagged streams?
>
> Yes.
>
> M
>
> > I think it's an error somewhere in the code, but the changes I mentioned
> > are the only changes I made between the block working and the block not
> > working.
> >
> > My code is based on OFDM_frame_equalizer, but without the actual signal
> > processing part. I will fill in my own signal processing after I know I
> > can at least pass one out of three inputs along so that the outputs are
> > the same as if this new block were bypassed.
> >
> >
> >
> >
> > On Wed, Apr 20, 2016 at 6:24 PM, Martin Braun  > > wrote:
> >
> > The tagged_stream_mux is an example of this kind of block. As Andrej
> > points out, you need to make sure every input signal is actually a
> > tagged stream.
> >
> > Cheers,
> > M
> >
> > On 04/20/2016 03:12 PM, Andrej Rode wrote:
> > > Hello Jenny,
> > >
> > > I can try to help you, but I'm not quite sure if I am right. If I
> > am wrong I
> > > will be corrected soon.
> > >
> >  Generating: "/home/jenny/Tutorials/rx_ofdm.py"
> >  Executing: "/home/jenny/Tutorials/rx_ofdm.py"
> >  Using Volk machine: sse4_2_64_orc
> >  gr::log :FATAL: geese_vcvc0 - Missing a required length tag on
> > port 1 at
> >  item #0
> >  thread[thread-per-block[46]: ]: Missing
> > length tag.
> > >
> > > This error tells you that your block is missing a length tag in
> > one of his
> > > inputs. A Stream Tag on the first sample is a requirement for a
> > tagged stream
> > > block. This Stream Tag has to provide information about how much
> > input data
> > > your block has to process.
> > > I assume you don't have an tagged stream on each of your inputs
> > and this
> > > causes a problem for your tagged stream block.
> > >
> > > Best you provide a screenshot of your example flowgraph (the
> > relevant parts).
> > > Based on the error it is nothing inside of your block but the way
> > you are
> > > trying to feed it with samples.
> > >
> > > Best Regards,
> > > Andrej
> > >
> > >
> > >
> > > ___
> > > 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] BER & constellation plot for OFDM transmit/receive

[Jingyi Sun]

What do you mean by "hard-decision" equalizer, and "drop them down"?

Thanks so much!!

On Thu, Apr 21, 2016 at 2:01 PM, Martin Braun 
wrote:

> That's because the equalizer used is a hard-decision equalizer. You can
> write your own equalizers and drop them down for better results; that's
> something I've been meaning to do for a while, but haven't found the
> time yet.
>
> Cheers,
> M
>
> On 04/20/2016 09:56 PM, Jingyi Sun wrote:
> > Hope pictures below give more context.   Has anyone seen this happen
> before?
> >
> > To reword the part of our question about constellation plots a little,
> > does anyone know when the constellation block would output just four
> > single points?
> >
> > The problem we’re currently facing is that the constellation plot does
> > not even really show up -/there’s not even a giant blob to indicate
> > noise/. Instead, we get only 4 points, one in each of the four locations
> > you’d expect for a QPSK signal - but only those 4 points./It almost
> > feels like the constellation plot stops triggering after these first
> > four points/, and that’s why we don’t receive anymore data. *We’re using
> > a free trigger on the positive slope, centered at 0, *which I feel
> > should trigger at least something even if it’s just noise.  We have also
> > tried other trigger methods, which output either 4 points, 5 points (1
> > additional point in the center), or just 1 center point.
> >
> >
> > ​
> > ​
> > ​
> >
> > On Mon, Apr 18, 2016 at 5:01 PM, Jingyi Sun  > > wrote:
> >
> > We are not compensating for any lost packets, although we would be
> > aware of them thanks to the packet number. Could you tell us if
> > there’s a block to do this, or would we need a custom block?
> >
> >
> > Also, could you tell us why the constellation diagram is not
> > displaying properly?
> >
> >
> > Thanks,
> >
> > Jenny
> >
> >
> >
> > On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun
> > > wrote:
> >
> > Are you comparing the correct packets? E.g., if packets get
> > lost, do you
> > take that into account?
> >
> > M
> >
> > On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> > > Hi everyone,
> > >
> > > We are working on an experiment for a conference paper
> deadline in two
> > > weeks, and need to transmit and receive OFDM packets and want
> to study
> > > the constellation diagram and BER.
> > >
> > > I put together a flow graph consisting of an *OFDM transmitter
> > block*
> > > and an *unpacked OFDM receiver* based on the online example
> > rx_ofdm.grc.
> > > Here's how I'm trying to measure constellation diagram and BER:
> > >
> > >   * I inserted a QT constellation sink right before the
> > constellation
> > > decoder on the payload IQ stream, but it does not seem to
> output
> > > anything meaningful. The plot just shows single, clean
> points, which
> > > I am pretty sure does not correspond to real data. I
> suspect that
> > > the plots are not triggering properly, but am not sure.
> > >
> > >   * For BER, we tried several different configurations, and
> > they mostly
> > > give BER = 0.5 (i.e. random).  Our leading theory is that
> we're not
> > > comparing the data at the correct points in the flow
> graph. Any
> > > suggestions as to what the BER inputs should be would be
> helpful.
> > >
> > > We've been running some diagnostics that seem to eliminate our
> > > communication channel as the problem:
> > >
> > >   * We are transmitting the data over-the-air at 915 MHz using
> > > two omnidirectional antennas, placed roughly 1 meter
> apart. The
> > > output spectra at the transmitter output and receiver
> input are
> > > attached - all signals are comfortably above the noise
> floor.
> > >   * From the tag debug output, we see that the OFDM packet
> > headers are
> > > being received. For example, we can see when the packets
> are
> > > received, the packet numbers, as well as the channel
> estimation tap
> > > values. We take this to mean that we are receiving data
> > > successfully, and that our difficulties regarding BER and
> > > constellation diagram are something we're executing
> incorrectly in
> > > the software.
> > >
> > >
> > > The relevant annotated GRC block diagrams are attached.
> > >
> > > Thanks so much,
> > > Jenny
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> >   

Re: [Discuss-gnuradio] Adaptive Modulation and Coding

[Martin Braun]

Ankit,

you'll need to be a bit more specific with what you're asking. I would
suggest reading this page for some pointers on how to formulate
questions:
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors

We'll be happy to help you, but right now it's not clear what you're asking.

M

On 04/18/2016 11:03 PM, Ankit Saharia wrote:
> Hello all,
> 
> I am working on OFDM in Wimax and is trying to change the modulation
> scheme in oFDM mod automatically.
> 
> I am able to do it manually using a selector block but not automatically.
> 
> I tried using WX GUI Slider but that was not working.
> 
> Any Suggestions?
> 
> Thankyou
> Ankit
> 
> 
> ___
> 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] Multiple Inputs in Tagged Stream Block

[Martin Braun]

On 04/20/2016 04:48 PM, Jingyi Sun wrote:
> tagged_stream_mux works when substituted for my block, so I think all of
> my inputs are tagged streams. Also, my inputs are coming from the
> outputs of OFDM_frame_equalizer, which I think propagates tagged streams?

Yes.

M

> I think it's an error somewhere in the code, but the changes I mentioned
> are the only changes I made between the block working and the block not
> working. 
> 
> My code is based on OFDM_frame_equalizer, but without the actual signal
> processing part. I will fill in my own signal processing after I know I
> can at least pass one out of three inputs along so that the outputs are
> the same as if this new block were bypassed.
> 
> 
> 
> 
> On Wed, Apr 20, 2016 at 6:24 PM, Martin Braun  > wrote:
> 
> The tagged_stream_mux is an example of this kind of block. As Andrej
> points out, you need to make sure every input signal is actually a
> tagged stream.
> 
> Cheers,
> M
> 
> On 04/20/2016 03:12 PM, Andrej Rode wrote:
> > Hello Jenny,
> >
> > I can try to help you, but I'm not quite sure if I am right. If I
> am wrong I
> > will be corrected soon.
> >
>  Generating: "/home/jenny/Tutorials/rx_ofdm.py"
>  Executing: "/home/jenny/Tutorials/rx_ofdm.py"
>  Using Volk machine: sse4_2_64_orc
>  gr::log :FATAL: geese_vcvc0 - Missing a required length tag on
> port 1 at
>  item #0
>  thread[thread-per-block[46]: ]: Missing
> length tag.
> >
> > This error tells you that your block is missing a length tag in
> one of his
> > inputs. A Stream Tag on the first sample is a requirement for a
> tagged stream
> > block. This Stream Tag has to provide information about how much
> input data
> > your block has to process.
> > I assume you don't have an tagged stream on each of your inputs
> and this
> > causes a problem for your tagged stream block.
> >
> > Best you provide a screenshot of your example flowgraph (the
> relevant parts).
> > Based on the error it is nothing inside of your block but the way
> you are
> > trying to feed it with samples.
> >
> > Best Regards,
> > Andrej
> >
> >
> >
> > ___
> > 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] BER & constellation plot for OFDM transmit/receive

[Martin Braun]

That's because the equalizer used is a hard-decision equalizer. You can
write your own equalizers and drop them down for better results; that's
something I've been meaning to do for a while, but haven't found the
time yet.

Cheers,
M

On 04/20/2016 09:56 PM, Jingyi Sun wrote:
> Hope pictures below give more context.   Has anyone seen this happen before?
> 
> To reword the part of our question about constellation plots a little,
> does anyone know when the constellation block would output just four
> single points? 
> 
> The problem we’re currently facing is that the constellation plot does
> not even really show up -/there’s not even a giant blob to indicate
> noise/. Instead, we get only 4 points, one in each of the four locations
> you’d expect for a QPSK signal - but only those 4 points./It almost
> feels like the constellation plot stops triggering after these first
> four points/, and that’s why we don’t receive anymore data. *We’re using
> a free trigger on the positive slope, centered at 0, *which I feel
> should trigger at least something even if it’s just noise.  We have also
> tried other trigger methods, which output either 4 points, 5 points (1
> additional point in the center), or just 1 center point.
> 
> 
> ​
> ​
> ​
> 
> On Mon, Apr 18, 2016 at 5:01 PM, Jingyi Sun  > wrote:
> 
> We are not compensating for any lost packets, although we would be
> aware of them thanks to the packet number. Could you tell us if
> there’s a block to do this, or would we need a custom block? 
> 
> 
> Also, could you tell us why the constellation diagram is not
> displaying properly?
> 
> 
> Thanks,
> 
> Jenny
> 
> 
> 
> On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun
> > wrote:
> 
> Are you comparing the correct packets? E.g., if packets get
> lost, do you
> take that into account?
> 
> M
> 
> On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> > Hi everyone,
> >
> > We are working on an experiment for a conference paper deadline in 
> two
> > weeks, and need to transmit and receive OFDM packets and want to 
> study
> > the constellation diagram and BER.
> >
> > I put together a flow graph consisting of an *OFDM transmitter
> block*
> > and an *unpacked OFDM receiver* based on the online example
> rx_ofdm.grc.
> > Here's how I'm trying to measure constellation diagram and BER:
> >
> >   * I inserted a QT constellation sink right before the
> constellation
> > decoder on the payload IQ stream, but it does not seem to output
> > anything meaningful. The plot just shows single, clean points, 
> which
> > I am pretty sure does not correspond to real data. I suspect 
> that
> > the plots are not triggering properly, but am not sure.
> >
> >   * For BER, we tried several different configurations, and
> they mostly
> > give BER = 0.5 (i.e. random).  Our leading theory is that we're 
> not
> > comparing the data at the correct points in the flow graph. Any
> > suggestions as to what the BER inputs should be would be 
> helpful.
> >
> > We've been running some diagnostics that seem to eliminate our
> > communication channel as the problem:
> >
> >   * We are transmitting the data over-the-air at 915 MHz using
> > two omnidirectional antennas, placed roughly 1 meter apart. The
> > output spectra at the transmitter output and receiver input are
> > attached - all signals are comfortably above the noise floor.
> >   * From the tag debug output, we see that the OFDM packet
> headers are
> > being received. For example, we can see when the packets are
> > received, the packet numbers, as well as the channel estimation 
> tap
> > values. We take this to mean that we are receiving data
> > successfully, and that our difficulties regarding BER and
> > constellation diagram are something we're executing incorrectly 
> in
> > the software.
> >
> >
> > The relevant annotated GRC block diagrams are attached.
> >
> > Thanks so much,
> > Jenny
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> 

Re: [Discuss-gnuradio] Pybomb installation error

[Martin Braun]

It should... is the commit Nathan mentioned in your installation?

M

On 04/21/2016 08:56 AM, Jason Matusiak wrote:
>> This was a bug that's been fixed recently.
> https://github.com/gnuradio/pybombs/commit
>> /38ed9d169ed67ef090e6015b07c4918f7c112209
> 
> 
> What is weird though is that I pulled down a fresh pybombs this morning,
> shouldn't that commit have taken effect already?
> 
> 
> ___
> 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 Overwrites UHD With Old Version

[Martin Braun]

On 04/21/2016 07:36 AM, West, Nathan wrote:
> The next thing I tried was using pybombs to install uhd and gnuradio
> but once again, I ended up with a UHD version that was too old to
> use with my B200Mini.
> 
> Now that's not supposed to happen.

Well, if you apt-get install gnuradio and it pulls in UHD too, then that
would clobber whatever's on the system, and that probably won't support
the B200mini. It depends on how pybombs was set up, if a proper prefix
was defined and if none of the current defaults were changed (i.e.,
where all hw drivers and GNU Radio default to source builds).

BTW, if someone is interested in providing an SDK recipe for x-compiling
for the RPi, that would be great and I'd be happy to assist.

M


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

Re: [Discuss-gnuradio] GNU Radio Overwrites UHD With Old Version

[Hughes, Jeremy Jay]

Thank you so much for your quick response! I will take your advice with 
pybombs. Have great day.


Jeremy


From: West, Nathan 
Sent: Thursday, April 21, 2016 10:36:42 AM
To: Hughes, Jeremy Jay
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNU Radio Overwrites UHD With Old Version

On Thu, Apr 21, 2016 at 9:25 AM, Hughes, Jeremy Jay 
> wrote:

I am trying to install GNU Radio and UHD on a Raspberry Pi 2 so that it will 
work with a USRP B200MIni. I am using the newest version of Raspbian-Jessie on 
the Raspberry Pi. I can get GNU Radio installed using

> sudo apt-get install gnuradio

The problem is that the UHD provided with this is too old.  Will there be a 
updated package added to apt-get anytime soon?

This is a question for whoever packages GNU Radio for Raspbian. I would guess 
not. I recommend reading up on packaging practices of whatever distribution you 
use (in this case Raspbian, based on Debian). Most distros including Debian 
"freeze" packaged software at the version that was current whenever the 
distro's release freeze date is, and will update bug fixes, but not do 
wholesale release changes (essentially maintaining a stablei ABI so 
*everything* doesn't need to recompile). This avoids a *ton* of head aches.


The next thing I tried was installing UHD from source first and then installing 
GNU Radio after. I can get the UHD driver installed so that it will see the 
B200Mini but once I install GNU Radio it overwrites the UHD I installed from 
source.

This is ambiguous. Did you apt-get install gnuradio? Again, this is a packaging 
thing for sanity. Your distribution's binary build of GNU Radio depends on your 
distribution's binary build of UHD and it will be installed.


The next thing I tried was using pybombs to install uhd and gnuradio but once 
again, I ended up with a UHD version that was too old to use with my B200Mini.

Now that's not supposed to happen.


Is there a way to get GNU Radio and a new version of UHD to work on the 
Raspberry Pi 2?  Any help would be greatly appreciated.

Make sure you remove *everything* you've done to date, then start over from 
scratch with pybombs. apt-get remove gnuradio and uhd. remove your source 
install of UHD, remove your pybombs install of everything. Clear out your 
pybombs prefix and try again with pybombs. In general don't mix source and 
binary installs.


Thank you for your time,


Jeremy Hughes


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

Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?

[Marcus D. Leech]

On 04/21/2016 11:41 AM, Michael Skaggs wrote:
I'm trying to time/sample synchronize RF recordings with two 
B200minis. I am using the detached Metadata File Sink in GRC. Both 
recordings are at 30MSps and both B200mini boards are synchronized to 
the same 1PPS signal.


My issue is this, when I extract the data from the Metadata header 
file, the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). 
Which, with a recording at 30MSps, this will only give me a sample 
alignment accuracy to 10e-4(s)*30(MS/s) = 30,000 samples.


If I'm attempting to align the two recordings by samples or time, this 
is not nearly accurate enough. Is there a way that I can get more 
accuracy out of my metadata header or a way that I can synchronize the 
recordings of these B200minis?


Thanks,
Michael

The precision of the timestamps from UHD should have a precision of 
whatever the master-clock is on the device--how are you interpreting
  the rx_time tag?  It's two parts--a uint64 with the full-seconds 
portion, and a double-precision float for the fractional part.




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

Re: [Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

> This was a bug that's been fixed recently. 
https://github.com/gnuradio/pybombs/commit 

> /38ed9d169ed67ef090e6015b07c4918f7c112209 



What is weird though is that I pulled down a fresh pybombs this morning, 
shouldn't that commit have taken effect already?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Anon Lister]

-v has to go before install. Ran into this the other day.
On Apr 21, 2016 11:29 AM, "Jason Matusiak" 
wrote:

> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>
> I ran it, but it thinks that -v is a recipe and it errors out there.  If
> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
> get:
> 
> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
> PyBombs.Packager.source - DEBUG - In cwd -
> /home/jmat/gnuradio/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" 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
> uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd. Aborting.
> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
> 
>
> ___
> 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

[West, Nathan]

This was a bug that's been fixed recently.
https://github.com/gnuradio/pybombs/commit/38ed9d169ed67ef090e6015b07c4918f7c112209

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

> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>
> I ran it, but it thinks that -v is a recipe and it errors out there.  If
> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
> get:
> 
> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
> PyBombs.Packager.source - DEBUG - In cwd -
> /home/jmat/gnuradio/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" 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
> uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd. Aborting.
> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
> 
>
>
> ___
> 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] Higher Accuracy Metadata Header?

[Michael Skaggs]

I'm trying to time/sample synchronize RF recordings with two B200minis. I
am using the detached Metadata File Sink in GRC. Both recordings are at
30MSps and both B200mini boards are synchronized to the same 1PPS signal.

My issue is this, when I extract the data from the Metadata header file,
the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which,
with a recording at 30MSps, this will only give me a sample alignment
accuracy to 10e-4(s)*30(MS/s) = 30,000 samples.

If I'm attempting to align the two recordings by samples or time, this is
not nearly accurate enough. Is there a way that I can get more accuracy out
of my metadata header or a way that I can synchronize the recordings of
these B200minis?

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

Re: [Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

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

I ran it, but it thinks that -v is a recipe and it errors out there.  If 
instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, 
i get:


PyBombs.Packager.source - DEBUG - Configuring recipe uhd
PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '', 
'builddir': '/home/jmat/gnuradio/src/uhd/build'}

PyBombs.Packager.source - DEBUG - In cwd - /home/jmat/gnuradio/src/uhd/build
PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake .. 
-DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" 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 uhd:

Process returned value: 1
PyBombs.install - ERROR - Error installing package uhd. Aborting.
jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$


___
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] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Hi Derek,

I'll answer your questions in-line, because I think what you are saying is
beginning to make me understand what I need:


On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel  wrote:

> Hello Pavan,
>
> Are you trying to create a shared timebase between the two USRPs without
> having a shared 1PPS or GPS reference? You are still not using enough
> detail for us to understand fully.
>

To clarify, my setup is two USRPs connected via MIMO cable, and then
another USRP acting as a receiver. So are you asking whether I'm trying to
create a shared timebase between the two-USRP *unit* (because they are MIMO
cabled) and the receiving USRP without having a shared 1 PPS or GPS
reference? I think my answer to that must be yes, because I have not done
anything else but connect them to the computer via ethernet and just have
two of them connected via MIMO cable and the other one by itself. I'm
assuming I need to have a shared reference between the transmit USRPs and
the receive USRP, so how would I be able to do that? This could certainly
be one of my problems.

>
> In Figure 5 both USRPs are connected with a MIMO cable and so have both
> shared frequency and time bases. What is your weight block doing to the
> sample stream? Is it a time delay block? I don't know what gnuradio would
> do if you specified 10*sample_rate as the delay there as that's likely to
> be a very large number of samples.
>

My weight block is applying a normalized magnitude phase correction to each
antenna's transmitted signal, so, yes, it is essentially creating a time
delay. Each weight is a complex value with magnitude 1 and a calculated
phase. You are saying this could be a problem if it's calculating a value
that is too high?

>
> If you have both USRPs connected with a time synchronization (shared 1PPS,
> GPSDO, or MIMO cable) and have your flowgraph configured correctly, then
> you can just use timed commands to the USRP_alpha to start transmitting at
> time X and USRP_beta to start receiving at time X and you will see your
> signal. You can then move to using burst mode using tags to define the
> number of samples to send/receive along with timed commands to send/receive
> bursts of samples. This works because the clocks in both USRPs will be
> aligned to each other.
>

I feel like there are two steps here. First, I need to get the transmitting
USRPs (which are conneced via MIMO cable) to time sync to each other (which
I believe I have done through using USRP sink in GRC and setting the second
channels time and clock to MIMO cable?), and second, I need to get the
receive USRP to receive at the same time. So, just as above, I need to get
my receive USRP to be on the same time as my transmit USRPs? Once I'm able
to do that, then I can do burst mode to transmit and receive timed signals,
as you are mentioning?

>
> If you do *NOT* have a shared time source for each radio, for instance
> they are far apart and do not have GPS references, then you need to do some
> sort of protocol level alignment to create a shared understanding of time
> between them. A frequently used method is for USRP_alpha to transmit a
> beacon with a known period (say once every 10 seconds). All other USRPs
> then receive for longer than 10 seconds to be guaranteed to receive the
> beacon (assuming they're within range of the transmission). When the
> receiving USRPs detect the incoming beacon they align their local time to
> the master (Beacon transmitting) USRP.
>

I guess a similar question to the above: can I have a shared time source
between the transmit USRPs (which are already MIMO cabled to each other)
and the receive USRP? It seems like that would be easier to do than going
through this protocol level alignment, but maybe it's not possible given my
setup.

>
> Here's a quick paper talking about this topic. The technique is widely
> used.
> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>
>
> I hope this helps and is applicable to your need. If you have more
> questions please try drawing your desired system and maybe include a
> timeline of events that you expect the radios to do. Attaching your
> existing flowgraphs, either as photos using GRC's screen capture feature
> (file>screen capture) or the actual GRC file, also helps us understand what
> exactly you are working with.
>

I had to take down the setup because I am moving labs, but I will send some
flowgraphs and the diagram of the system next week. Thank you again for
being so patient and trying to help me. I think I'm just a bit lost on a
few of the simple things, but once those are figured out, then I think it
should be smoother sailing.

>
> Derek
>
> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli 
> wrote:
>
>> Hi Martin,
>>
>> I guess I have a few questions:
>>
>> 1.) Are there any examples in the gnuradio codebase/flowgraph repository
>> that show how to do synchronized feedback between two USRPs? In other
>> words, I send a signal from 

Re: [Discuss-gnuradio] FILE SINK Binary file error

[Marcus Müller]

Hi Ernest,

that question is asked pretty frequently, so here is a FAQ:

https://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink

Best regards,
Marcus

On 21.04.2016 15:47, ERNEST MATEY wrote:
> ‎Hi Experts,
>
> I attached the output of my file sink. 
> I was expecting a chain of binaries. 
> I want to plot this on matlab. 
> File - Source can replay this signal though
> But how I can I see the binary chain? Is this what is should be. All I
> see are strange letters.  
> What is happening 
>
> Thank you
> Ernest.  
>
> Sent from my BlackBerry 10 smartphone.
> *From: *Richard Bell
> *Sent: *Friday, April 15, 2016 3:44 AM
> *To: *discuss-gnuradio@gnu.org
> *Subject: *[Discuss-gnuradio] gr-osmosdr python question
>
>
> I'm new to using gr-osmosdr and I'm trying to implement the equivalent
> set of USRP function calls for a HackRF
>
> set_center_freq(target_freq)
> get_sensor("lo_locked")
>
> which amounts to measuring how long it takes to command a frequency
> change and lock at the new frequency.
>
> The set_center_freq function happens to be the same, but I don't know
> where to find documentation or example code that shows the get_sensor
> equivalent, or if it's even needed. Would someone direct me to an API
> manual for gr-osmosdr, or source code that defines these things?
>
> Thanks,
> Rich
>
>
>
>
> ___
> 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] Pybomb installation error

[Jason Matusiak]

> 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

Re: [Discuss-gnuradio] GNU Radio Overwrites UHD With Old Version

[West, Nathan]

On Thu, Apr 21, 2016 at 9:25 AM, Hughes, Jeremy Jay 
wrote:

> I am trying to install GNU Radio and UHD on a Raspberry Pi 2 so that it
> will work with a USRP B200MIni. I am using the newest version of
> Raspbian-Jessie on the Raspberry Pi. I can get GNU Radio installed using
>
> > sudo apt-get install gnuradio
>
> The problem is that the UHD provided with this is too old.  Will there be
> a updated package added to apt-get anytime soon?
>
This is a question for whoever packages GNU Radio for Raspbian. I would
guess not. I recommend reading up on packaging practices of whatever
distribution you use (in this case Raspbian, based on Debian). Most distros
including Debian "freeze" packaged software at the version that was current
whenever the distro's release freeze date is, and will update bug fixes,
but not do wholesale release changes (essentially maintaining a stablei ABI
so *everything* doesn't need to recompile). This avoids a *ton* of head
aches.


> The next thing I tried was installing UHD from source first and then
> installing GNU Radio after. I can get the UHD driver installed so that it
> will see the B200Mini but once I install GNU Radio it overwrites the UHD I
> installed from source.
>
This is ambiguous. Did you apt-get install gnuradio? Again, this is a
packaging thing for sanity. Your distribution's binary build of GNU Radio
depends on your distribution's binary build of UHD and it will be installed.


> The next thing I tried was using pybombs to install uhd and gnuradio but
> once again, I ended up with a UHD version that was too old to use with my
> B200Mini.
>
Now that's not supposed to happen.


> Is there a way to get GNU Radio and a new version of UHD to work on the
> Raspberry Pi 2?  Any help would be greatly appreciated.
>

Make sure you remove *everything* you've done to date, then start over from
scratch with pybombs. apt-get remove gnuradio and uhd. remove your source
install of UHD, remove your pybombs install of everything. Clear out your
pybombs prefix and try again with pybombs. In general don't mix source and
binary installs.

>
> Thank you for your time,
>
>
> Jeremy Hughes
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Overwrites UHD With Old Version

[Hughes, Jeremy Jay]

I am trying to install GNU Radio and UHD on a Raspberry Pi 2 so that it will 
work with a USRP B200MIni. I am using the newest version of Raspbian-Jessie on 
the Raspberry Pi. I can get GNU Radio installed using

> sudo apt-get install gnuradio

The problem is that the UHD provided with this is too old.  Will there be a 
updated package added to apt-get anytime soon? The next thing I tried was 
installing UHD from source first and then installing GNU Radio after. I can get 
the UHD driver installed so that it will see the B200Mini but once I install 
GNU Radio it overwrites the UHD I installed from source. The next thing I tried 
was using pybombs to install uhd and gnuradio but once again, I ended up with a 
UHD version that was too old to use with my B200Mini. Is there a way to get GNU 
Radio and a new version of UHD to work on the Raspberry Pi 2?  Any help would 
be greatly appreciated.


Thank you for your time,


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

Re: [Discuss-gnuradio] stream_mux tag propagation

[Andrej Rode]

Hi Merlin, 

> Is that a bug in stream_mux? It means that the streams cannot be demuxed by
> looking at the tags.

There is no special processing for stream tags in stream_mux. It simply takes 
the input streams and copies them input-wise into the output buffer. Stream 
tags are propagated according to their initial offset at the input. And there 
you get behaviour you described.

Did you have a look at tagged_stream_mux ? Maybe it will serve your needs? It 
sounds not unreasonable to have a switch to change tag propagation in 
stream_mux to your desired behaviour. Or is it a major breakage to the tag 
propagation policy?

Best Regards, 
Andrej








signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] stream_mux tag propagation

[Merlin Chlosta]

Hi all,

I stumbled across the stream_mux tag propagation. In my understanding, tags are 
associated with one item and should be associated with the same item after 
processing, if possible. The stream_mux block however does not propagate tags 
like that:

Say we mux two tagged streams A and B, while A has packet_len_a=2 and B 
packet_len_b=3.

A: a1 a2 a1 a2 a1 …
---^-^-^---Tag packet_len_a=2
B: b1 b2 b3 b1 b2 …
---^^--Tag packet_len_b=3

packet_len tags are associated with a1 / b1 (denoted with ^).
When muxed with the scheme (2, 3), the muxed stream looks like that:

a1 a2 b1 b2 b3 a1 a2 b1 …
^-^-^-^--   Tag packet_len_a=2
^^^--   Tag packet_len_b=3

The tags got associated to different items! "packet_len=2" is associated with 
every second item, "packet_len=3" with every third item, instead of a1 / b1.

I would assume a correct tag propagation to look like this:
a1 a2 b1 b2 b3 a1 a2 b1 …
^--^-   Tag packet_len_a=2
--^--^---   Tag packet_len_b=3

Is that a bug in stream_mux? It means that the streams cannot be demuxed by 
looking at the tags.

A basic python flowgraph is attached, it prints tags and their offsets after 
stream_mux processing.
#!/usr/bin/env python2

from gnuradio import gr
from gnuradio import blocks
import pmt

class test_mux_stream(gr.top_block):
	def __init__(self):
		gr.top_block.__init__(self)
		self.tb = gr.top_block()

		src_data_a   = 10*[1,1]
		src_data_b   = 10*[2,2,2]
		#expected_result = 10*[1,1,2,2,2,]

		src_a = blocks.vector_source_f(src_data_a)
		src_b = blocks.vector_source_f(src_data_b)
		tag_stream_a = blocks.stream_to_tagged_stream(gr.sizeof_float, 1, 2, 'packet_len_a')
		tag_stream_b = blocks.stream_to_tagged_stream(gr.sizeof_float, 1, 3, 'packet_len_b')

		mux = blocks.stream_mux(gr.sizeof_float, (2, 3))
		dst = blocks.vector_sink_f()

		self.tb.connect(src_a, tag_stream_a)
		self.tb.connect(src_b, tag_stream_b)
		self.tb.connect(tag_stream_a, (mux,0))
		self.tb.connect(tag_stream_b, (mux,1))
		self.tb.connect(mux, dst)
		self.tb.run()

		print(dst.data())

		# check the tags
		tags = dst.tags()
		for tag in tags:
			print("Key: " +pmt.to_python(tag.key)
+" Value: " +str(pmt.to_python(tag.value))
+" Offset: " +str(tag.offset) )

if __name__ == '__main__':
	try:
		test_mux_stream().run()
	except [[KeyboardInterrupt]]:
		pass
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Scrambler and Descrambler

[rynorli]

Hi everyone! I m trying to build a simple communication system with trellis
code and gmsk modulation. Before the scrambler and descrambler blocks were
added into the flow graph, the system worked well but after that the
transmission failed. I've read the document of the block but still cant not
figure out where the problem is.This is my flow graph and if you know how to
use the scrambler plz tell me. Every help will be appreciate!!
  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Scrambler-and-Descrambler-tp59649.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