Re: [Discuss-gnuradio] gr-fosphor with pybombs

[Sylvain Munaut]

On Wed, Mar 18, 2015 at 11:47 PM, ben Gee  wrote:
> i should also add that the output of "./pyboms" list shows that gr-fosphor
> IS installed, output below:

Interesting ...

Are you sure you haven't two install of pybombs with different
prefixes that would mix things up ?

If not, I think pybombs keeps a build log somewhere for the various
installed package, try to find it and pastebin it somewhere.

Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] GNU Radio on Android

[Vijay Galbaransingh]

Tom,

As you expected, disabling buffering on the file sink did not have any 
effect. I have fixed the issue though by making two changes to 
opensl_source_impl.cc:
1) change scale_factor to 32768 (1/2^14 doesn't make sense, it causes 
clipping because the volk conversion method divides by scale_factor.)
2) change buffer size (d_size) to 8k (2k was too small, tested 32/44.1/48kHz 
on Nexus 4 and Nexus 7 2012 version.) Without this change the recorded audio 
will be very choppy (dropped samples?)

Vijay

From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: March-18-15 07:11
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android

On Wed, Mar 18, 2015 at 1:46 AM, Vijay Galbaransingh  wrote:
Tom,

What kind of sample rate / setup are you using for your opensl_source? I've
set up a flowgraph that is just an opensl_source (sampling at 48kHz)
connected to a file sink, and when I play back the file through GRC on my
desktop my audio is coming out pretty garbled, as if samples are being
dropped. I've also tried a couple other sampling rates (44.1kHz, 32kHz,
16kHz to name a few.) I'm using a Nexus 4 running Android 5.0.1. Pasted
below is some of my code.

Vijay

Flowgraph code:
JNIEXPORT void JNICALL
Java_com_example_grrecordmic_GrRecordMic_InitFlowgraph(JNIEnv* env, jobject
thiz, jstring jsinkfilename)
{
int rate = 48000;
const char *sinkfilename = env->GetStringUTFChars(jsinkfilename, 0);

global_tb = gr::make_top_block("Record_Mic");

gr::grand::opensl_source::sptr micSource =
gr::grand::opensl_source::make(rate);
gr::blocks::file_sink::sptr fileSink =
gr::blocks::file_sink::make(sizeof(float), sinkfilename, false);

global_tb->connect(micSource, 0, fileSink, 0);

env->ReleaseStringUTFChars(jsinkfilename, sinkfilename);
}

I believe that I used either 32k and/or 44.1k. I was using a Nexus 7, 
though, and the codec might play a significant role with this between the 
two devices.

Perhaps try setting the file sink to unbuffered mode?

fileSink->set_unbuffered(true);

Frankly, I feel like this is unlikely to help, but it'll be interesting to 
know what happens.

Tom


From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: March-17-15 07:37
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android

On Tue, Mar 17, 2015 at 12:10 AM, Vijay Galbaransingh  wrote:
Thanks Tom, that sorted it out. My audio output is a bit choppy but no
matter – time to move on to some more complex flowgraphs in my Android app.

Thanks again,
Vijay

Yes, the skipping in the audio output is a known bug, and  apparently known
to be difficult in Android. It's going to take some kind of double buffering
to fix it at this level. I did not experience any problems with the audio
source, though; I just saved it to a file, brought it back to my computer,
and played it there and it sounded fine.

Tom



From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: March-16-15 06:37
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android

On Mon, Mar 16, 2015 at 3:28 AM, Vijay Galbaransingh  wrote:
Hi Tom,

I have been following your notes on the wiki in an attempt to build a test
app (a dial tone flowgraph.) I'm hitting a snag on the ndk-build step
though -- when I use your example Android.mk listing, the linker isn't
finding any of the static libraries we built (gnuradio, grand, boost, fftw.)
Instead I'm getting a pile of undefined reference errors.

I tried editing the example Android.mk file by adding the following before
the shared library build:

include $(CLEAR_VARS)
LOCAL_MODULE := grand_static_lib #for example
LOCAL_SRC_FILES := /opt/grandroid/lib/libgnuradio-grand.a
include $(PREBUILT_STATIC_LIBRARY)

However I quickly realised that while there are only a few gnuradio
libraries to add this way, there are a ton of boost libraries... Is there a
smarter way to add all the prebuilt .a libraries at once? Or am I headed in
the wrong direction entirely?

Any tips appreciated,
Vijay


Yep, you have to add all of the libraries into the Android.mk file. I've
updated the wiki:

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

You can go there and simply download GrAndroid.mk that does all of this for
you and include it in your Android.mk file. Just follow the instructions.

Hope that helps,

Tom



From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: March-13-15 14:41
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android
On Fri, Mar 13, 2015 at 5:04 PM, Vijay Galbaransingh  wrote:
Hi,

Has a patched version of GNU Radio which runs on Android been released?

I'm working on a project where I'm transmitting information over audio
from a desktop system to an Android device, and s

Re: [Discuss-gnuradio] UHD error: _ZN3uhd6device4findERKNS_13device_addr_tENS0_15device_filter_tE

[Zamrath Nizam]

Hi all,

Please address the last thread I wrote. Meantime, I tried method 3 as well,
where I downloaded 1.5 GB SDK software, but when I execute,

"sudo sh oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh", it
errored as "Error: Installation machine not supported!".

Please be kindly suggest a way to through this.

Thank you.

Zamrath Nizam

On Thu, Mar 19, 2015 at 11:24 AM, Zamrath Nizam 
wrote:

> Hi Muller and Tom,
>
> I used pybombs approach to solve the problem. After the cloning process,
> it gives the following error.
>
> Configuration failed. Re-trying with higher verbosity.
> make: *** No targets specified and no makefile found. Stop.
>
> Could you see a resolution here?
>
> Zamrath
>
> On Wed, Mar 18, 2015 at 7:35 PM, Tom Rondeau  wrote:
>
>> On Wed, Mar 18, 2015 at 9:29 AM, Marcus Müller 
>> wrote:
>>
>>>  Pybombs can't solve a lack of RAM -- it just offers an automated build
>>> procedure.
>>> Search google to find information how to add swap to your system.
>>> However, swap is just RAM that is temporarily exiled to permanent storage.
>>> Now, a microSD card is several orders of magnitude slower than RAM, so
>>> whilst that might allow your build process to work, it will make it slow.
>>>
>>> Best regards,
>>> Marcus
>>>
>>
>> Cross-compiling would be better.
>>
>> We have information on embedded systems here:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
>>
>> Debian also comes with support for cross compilers itself, though we have
>> no direct information on how to use those for building GNU Radio.
>>
>> Tom
>>
>>
>>
>>>
>>>
>> On 03/18/2015 01:39 PM, Zamrath Nizam wrote:
>>>
>>>  Yes, RAM seems to be not up for the compiler's asking rate. I used
>>> 'watch' command to observe it. At peak, free memory drops down to zero.
>>>  BTW, I am interesting to know how to extend RAM in Bananapi (capacity
>>> of Micro SD card is 16 GB), in case pyBOMBS method does not give me a hand.
>>>
>>>  Thanks,
>>> Best,
>>> Zamrath Nizam
>>>
>>> On Wed, Mar 18, 2015 at 5:54 PM, Marcus Müller >> > wrote:
>>>
  If it hangs, that just sounds like the poor ARM is busy; compiling is
 hard! You can check your CPU usage by running "top" in another console.
 If building aborts, you might need to add some swap space, to "extend"
 your RAM (start with 4GB). That will be horribly, horribly slow.

 Greetings,
 Marcus


 On 03/18/2015 01:12 PM, Zamrath Nizam wrote:

 Hi Müller,

  Thank you for the detailed answer you provided. I will surely try one
 of the method you have given above. Meantime, the reason why I went for the
 debian GNURadio was, when GNURadio is built, it halts at around 50%. It has
 been run for 15-20 times. As you have pointed out, it was due to the low
 RAM (1 GB). Sounds first method would be handy to cope with. I will let you
 know after trying above methods.

  Thank you again.

  Best,
 Zamrath

 On Wed, Mar 18, 2015 at 4:55 PM, Marcus Müller <
 marcus.muel...@ettus.com> wrote:

>  Hi Zamrath,
>
> now you're mixing different versions of the same library (UHD).
> The debian GNU Radio was built and linked against the debian UHD, but
> now you're using the Ettus UHD package, so the symbols that the debian GNU
> Radio thought it knew are now unavailable.
> You should uninstall debian's UHD version, when installing the Ettus
> one. You also must uninstall debian's GNU Radio.
>
> You will have to build GNU Radio against the UHD library version
> you're using. You *can* in theory, do that on the bananapi itself, but I
> don't think that is going to be fun (or short) -- after all, it's an
> embedded device, and not a development workstation, so CPU and RAM are
> sparse.
> There are three ways you can go from here: (1) build GNU Radio on the
> bananapi, (2) cross-compile it for the debian armhf port and (3) rolling
> out openembedded and treating your bananapi as a cool embedded device
> rather than a boring slow PC.
>
> Method (1)
> ===
> This should be the easiest path: use pyBOMBS, as it should do
> everything for you[0], and take roughly veery long.
>
> Method (2)
> ===
>
> I think that in the long run, if you want to do software development
> for the bananapi, anyway, setting up a cross-compilation environment will
> be what you want to do.
> However, I'm not really used to doing cross-builds myself; I can only
> outline what you will have to do:
>
> On your (easiest case: debian) workstation:
>
> * Install the appropriate cross toolchain[2], and all the libraries[1]
> lists as necessary in their development version and target-arch (armhf)
> compatible version. I think that will be the hardest part, as it's a bit
> debian specific.
> * Follow [3] . Replace the oe-sdk-toolchain.cmake file with a
> d

Re: [Discuss-gnuradio] OFDM test with USRP

[Marcus Müller]

Hi Henry,
> I have built a tx and a rx grc flowchart for OFDM using USRP. I found
> the range of the amplitude of the input is fairly small in order to
> get it working (i.e., the USRP at the rx end can successfully decode
> the packets.)  I wound if anyone can share some thoughts about this?
> I've been stuck here for several days. 
there's very many factors limiting the decodability of a transmission --
the main being SNR, especially since you get problems the further you
move away, but also aspects like the increased multipath effects, that
the equalizer might or might not be up to compensate.

What you're seeing might be something else, though:
> Through my test, I found the const in multiply_const in the tx part
> (which corresponds to amplitude adjustment) needs to be (0.05, 0.025).
that value definitely has the effect of limiting the sample amplitude
that goes into your USRP. The USRP driver framework maps values from
-1;1 to (DAC_min; DAC_max), basically. Driving the USRP with values
close to (or even over) 1.0 will lead to clipping/gain compression
problems. However, small values of course lead to "weak signal" on
average, leading to low SNR. The OFDM Tx that you use internally uses
apropriate scaling to limit the values to magnitudes <= 1.0, so I'm a
bit surprised your constant is so small.

That is a problem so common in transmitters, especially in OFDM, that
there's an abbreviation for that PAPR - Peak-to-Average Power ratio.
You often combat that by doing appropriate coding, with the aim of
guaranteing that no info symbols that map to time signals with strong
peaks exist. However, that means that you can't use all the information
"capacity" of the OFDM words -- and will be slower in the end. You can
solve that by ignoring the clipped/compressed peaks and fix the
resulting packets by doing error correction -- but that also comes at
the price of less bits per second, since you have to add sufficient
redundancy in the transmitter. Your third option is to just don't care
so much and retransmit broken packets -- for low packet error rates,
that might be sufficient.

I'm a bit surprised, though -- you just feed in random information, and
that should be white, which means that packets with unhealthily high
PAPR are seldom.

You should save the samples that come out of the OFDM mod block using a
file sink, and analyze them later; look for samples with magnitude >1.0
(they shouldn't be there, because the output of the internal IFFT is
scaled with 1/sqrt(fftlen)).
> However, when the const value increases, for example, to 0.06. the PER
> is around 0.0044
That doesn't sound half bad, considering you don't do any equalizing. I
think (I'm not totally sure, was too lazy to look into the source code
just now) that the OFDM implementation (you're using the older one, the
newer one is cooler) doesn't do much on the receiving side to recover
the signal.
Have a look at the rx_ofdm example (in
/usr/[local/]share/gnuradio/examples/digital/, or so). That's a bit more
advanced than your RX.

Greetings,
Marcus

On 03/19/2015 01:34 AM, Henry Jin wrote:
> Hi everyone,
>
> I have built a tx and a rx grc flowchart for OFDM using USRP. I found
> the range of the amplitude of the input is fairly small in order to
> get it working (i.e., the USRP at the rx end can successfully decode
> the packets.)  I wound if anyone can share some thoughts about this?
> I've been stuck here for several days.

>
> To quantify the packet reception performance, I modified
> digital.crc32_bb so that even when the crc test fails, the wrong
> packet is still fed to the output. In this way, I can evaluate the
> packet error rate (PER). Through my test, I found the const in
> multiply_const in the tx part (which corresponds to amplitude
> adjustment) needs to be (0.05, 0.025). In this range, the PER can be
> 0. However, when the const value increases, for example, to 0.06. the
> PER is around 0.0044. When we further increase the const value to
> 0.08, the PER is above 10% or even higher. I guess this is probably
> because the input signal amplitude of the USRP needs to be in a
> certain working range.  However, it seems to me this range is too
> small. Besides, how can I find some numerical statistics about the
> amplitude limitation? On the other hand, if the amplitude is decreased
> to 0.02, many packets will be failed to synchronize. But I do observed
> that the packets successfully synchronized are also correctly decoded.
> In other words, the PER is still 0, but the number of packets
> correctly decoded is actually much smaller than the number of packets
> sent. 
>
> I also tried to enable the two disabled blocks in the files but it is
> of no help.
>
> Thanks for any comments.
>
> link:
> https://www.dropbox.com/s/ndrtide1g73u5ju/grc_ofdm_rx.grc?dl=0
> https://www.dropbox.com/s/8g3kg2tg6pdh0dy/grc_ofdm_tx.grc?dl=0
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists

Re: [Discuss-gnuradio] Channel Model Block in GNU radio

[Marcus Müller]

Hi Merry,

the taps characterize the channel you want to simulate, so you will need
to calculate these based on your mathematical channel model. The
classical multipath channel model is a tapped-delay line-model, and that
kind of directly maps to the concept of filter taps.

Are you sure you do 4 samples per second? That seems to be incredible
little, especially when working with channel impulse responses.

Greetings,
Marcus

On 03/19/2015 06:55 AM, Merry Dominic wrote:
> Hi,
>
> I am working on the channel model block in GNU radio. I am confused in
> setting up the taps.I have a random source that undergoes a QPSK
> modulation at 4 samples per second.Could you please explain me the
> concept under setting the tap values.
>
> I am supposed to use a polyphase clock synchronizer followed by a CMA
> equalizer for analyzing the channel response.
>
> Looking forward for your reply.
>
>
> Thanks
> Merry
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] UHD error: _ZN3uhd6device4findERKNS_13device_addr_tENS0_15device_filter_tE

[Marcus Müller]

Hi Zamrath,

your questions become very specific to your system, and can't easily be
answered by just reading the error texts. You will have to investigate a
bit deeper yourself and at least find out in which context (sub-step)
these things occur.

Greetings,
Marcus

On 03/19/2015 12:12 PM, Zamrath Nizam wrote:
> Hi all,
>
> Please address the last thread I wrote. Meantime, I tried method 3 as
> well, where I downloaded 1.5 GB SDK software, but when I execute,
>
> "sudo sh oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
> ", it
> errored as "Error: Installation machine not supported!".
>
> Please be kindly suggest a way to through this.
>
> Thank you.
>
> Zamrath Nizam
>
> On Thu, Mar 19, 2015 at 11:24 AM, Zamrath Nizam  > wrote:
>
> Hi Muller and Tom,
>
> I used pybombs approach to solve the problem. After the cloning
> process, it gives the following error.
>
> Configuration failed. Re-trying with higher verbosity.
> make: *** No targets specified and no makefile found. Stop.
>
> Could you see a resolution here?
>
> Zamrath
>
> On Wed, Mar 18, 2015 at 7:35 PM, Tom Rondeau  > wrote:
>
> On Wed, Mar 18, 2015 at 9:29 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>>
> wrote:
>
> Pybombs can't solve a lack of RAM -- it just offers an
> automated build procedure.
> Search google to find information how to add swap to your
> system. However, swap is just RAM that is temporarily
> exiled to permanent storage. Now, a microSD card is
> several orders of magnitude slower than RAM, so whilst
> that might allow your build process to work, it will make
> it slow.
>
> Best regards,
> Marcus
>
>
> Cross-compiling would be better.
>
> We have information on embedded systems here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
>
> Debian also comes with support for cross compilers itself,
> though we have no direct information on how to use those for
> building GNU Radio.
>
> Tom
>
>  
>
>  
>
> On 03/18/2015 01:39 PM, Zamrath Nizam wrote:
>> Yes, RAM seems to be not up for the compiler's asking
>> rate. I used 'watch' command to observe it. At peak, free
>> memory drops down to zero. 
>> BTW, I am interesting to know how to extend RAM in
>> Bananapi (capacity of Micro SD card is 16 GB), in case
>> pyBOMBS method does not give me a hand.
>>
>> Thanks,
>> Best,
>> Zamrath Nizam
>>
>> On Wed, Mar 18, 2015 at 5:54 PM, Marcus Müller
>> > > wrote:
>>
>> If it hangs, that just sounds like the poor ARM is
>> busy; compiling is hard! You can check your CPU usage
>> by running "top" in another console.
>> If building aborts, you might need to add some swap
>> space, to "extend" your RAM (start with 4GB). That
>> will be horribly, horribly slow.
>>
>> Greetings,
>> Marcus
>>
>>
>> On 03/18/2015 01:12 PM, Zamrath Nizam wrote:
>>> Hi Müller,
>>>
>>> Thank you for the detailed answer you provided. I
>>> will surely try one of the method you have given
>>> above. Meantime, the reason why I went for the
>>> debian GNURadio was, when GNURadio is built, it
>>> halts at around 50%. It has been run for 15-20
>>> times. As you have pointed out, it was due to the
>>> low RAM (1 GB). Sounds first method would be handy
>>> to cope with. I will let you know after trying above
>>> methods.
>>>
>>> Thank you again.
>>>
>>> Best,
>>> Zamrath
>>>
>>> On Wed, Mar 18, 2015 at 4:55 PM, Marcus Müller
>>> >> > wrote:
>>>
>>> Hi Zamrath,
>>>
>>> now you're mixing different versions of the same
>>> library (UHD).
>>> The debian GNU Radio was built and linked
>>> against the debian UHD, but now you're using the
>>> Ettus UHD package, so the symbols that the
>>> debian GNU Radio thought it knew are now
>>> unavailable.
>>> You should uninstall debian's UHD version, when
>>> installing the Ettus one. You also must
>>> uninstall debian's G

[Discuss-gnuradio] Changing GUI Sink block params on the fly from a custom C++ block?

[Murphy, John]

Hello GNU Radio'ers,

I have a GRC flowgraph with a custom C++ block that feeds a stream of
vectors of floats to the QT GUI Vector Sink. Which particular internal
vector of floats gets streamed out of the custom C++ block is set on
the fly from a QT GUI Chooser. I am using the autoscale on the QT GUI
Vector Sink.

The autoscale is okay but I do come up against shortcomings with it
and I could do better if I could somehow have the C++ code for the
custom C++ block (or the stuff in the GRC flowgraph, but that seems
more difficult to me) call some function to change the QT GUI Vector
Sink Y Axis Min and Max on the fly when the param choosing the vector
is changed.

Would someone please indicate how to do this, if it can be done? And
perhaps provide a link to a similar example on the web to work from,
if such exists?

Thanks,
John

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

Re: [Discuss-gnuradio] GNU Radio on Zedboard

[Philip Balister]

On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote:
> Philip,
> 
> Thank you for letting me using your images. I tried both of them with the *dd
> *command, it took me around 2000 seconds (30 mins) each and after using
> them on the board I get the following message via the UART:
> 
> *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)*
> *mmc boot*
> *reading fpga.bin*
> *spl: error reding image fpga.bin, err - -1*
> *reading system.dtb*
> *spl: error reading image system.dtb, err - -1*
> *reading u-boot.img*
> *spl: error reading image u-boot.img, err - -1*
> *### ERROR ### Please RESET the board ###*

So the first stage boot loader is running, which is good.

It looks for a couple of files which should be there, which is OK.
(fpga.bin and system.dtb)

Then it tries to load u-boot.img which it doesn't find. This is bad.

Can you put the card in a PC and send the list of file in the FAT partition?

Philip


> 
> I got the above message for sdimage-8G-zc702.direct. I get no message for
> the other image.
> 
> What am I doing wrong?
> 
> On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister 
> wrote:
> 
>> On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote:
>>> Hello everyone,
>>>
>>> I'm going through the instructions from here:
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
>>
>> I should go over those carefully, but in the mentime I have some images
>> built for the zedbaord here:
>>
>> https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?dl=0
>>
>> Take the zedboard one, uncompress it and write it to an sd card. Be sure
>> to unmount (not eject) the sd card and run:
>>
>> sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX
>>
>> where sdx is the device the sd card is on.
>>
>> Philip
>>
>>>
>>> to get a working image with gnu radio for my zedboard.
>>>
>>> Unfortunately I can't get the board to boot with this image. I was
>>> wondering if someone can help me.
>>>
>>> what I tried so far ( all failed - can't boot from the SDCard):
>>>
>>> - default settings in the instructions
>>> - renaming u-boot.bin to boot.bin
>>> - renaming u-boot.bin to BOOT.BIN
>>> - renaming uImage--zedboard-zynq7.dtb to devicetree.dtb
>>> - I tried command line as well as gparted gui.
>>>
>>> what I checked:
>>>
>>> - download a linux from XillyBus and boot the board with SDCard -> works
>>>
>>> v/r
>>> Alireza
>>>
>>>
>>>
>>> ___
>>> 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] Changing GUI Sink block params on the fly from a custom C++ block?

[Tom Rondeau]

On Thu, Mar 19, 2015 at 9:26 AM, Murphy, John  wrote:

> Hello GNU Radio'ers,
>
> I have a GRC flowgraph with a custom C++ block that feeds a stream of
> vectors of floats to the QT GUI Vector Sink. Which particular internal
> vector of floats gets streamed out of the custom C++ block is set on
> the fly from a QT GUI Chooser. I am using the autoscale on the QT GUI
> Vector Sink.
>
> The autoscale is okay but I do come up against shortcomings with it
> and I could do better if I could somehow have the C++ code for the
> custom C++ block (or the stuff in the GRC flowgraph, but that seems
> more difficult to me) call some function to change the QT GUI Vector
> Sink Y Axis Min and Max on the fly when the param choosing the vector
> is changed.
>
> Would someone please indicate how to do this, if it can be done? And
> perhaps provide a link to a similar example on the web to work from,
> if such exists?
>
> Thanks,
> John
>

In the Vector Sink's properties, you can set a variable for the y-min and
y-max. When you change the variable (via a slider or in any other way), it
will change the y axis settings.

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

Re: [Discuss-gnuradio] GNU Radio on Android

[Tom Rondeau]

On Thu, Mar 19, 2015 at 3:28 AM, Vijay Galbaransingh  wrote:

> Tom,
>
> As you expected, disabling buffering on the file sink did not have any
> effect. I have fixed the issue though by making two changes to
> opensl_source_impl.cc:
> 1) change scale_factor to 32768 (1/2^14 doesn't make sense, it causes
> clipping because the volk conversion method divides by scale_factor.)
> 2) change buffer size (d_size) to 8k (2k was too small, tested
> 32/44.1/48kHz
> on Nexus 4 and Nexus 7 2012 version.) Without this change the recorded
> audio
> will be very choppy (dropped samples?)
>
> Vijay


Ah, ok, that makes sense. I think I was just playing around with those
parameters and must have checked them in at that state.

I'll make those updates to the repo.

Thanks.
Tom



>
> From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of
> Tom
> Rondeau
> Sent: March-18-15 07:11
> To: Vijay Galbaransingh
> Cc: GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] GNU Radio on Android
>
> On Wed, Mar 18, 2015 at 1:46 AM, Vijay Galbaransingh 
> wrote:
> Tom,
>
> What kind of sample rate / setup are you using for your opensl_source? I've
> set up a flowgraph that is just an opensl_source (sampling at 48kHz)
> connected to a file sink, and when I play back the file through GRC on my
> desktop my audio is coming out pretty garbled, as if samples are being
> dropped. I've also tried a couple other sampling rates (44.1kHz, 32kHz,
> 16kHz to name a few.) I'm using a Nexus 4 running Android 5.0.1. Pasted
> below is some of my code.
>
> Vijay
>
> Flowgraph code:
> JNIEXPORT void JNICALL
> Java_com_example_grrecordmic_GrRecordMic_InitFlowgraph(JNIEnv* env, jobject
> thiz, jstring jsinkfilename)
> {
> int rate = 48000;
> const char *sinkfilename = env->GetStringUTFChars(jsinkfilename, 0);
>
> global_tb = gr::make_top_block("Record_Mic");
>
> gr::grand::opensl_source::sptr micSource =
> gr::grand::opensl_source::make(rate);
> gr::blocks::file_sink::sptr fileSink =
> gr::blocks::file_sink::make(sizeof(float), sinkfilename, false);
>
> global_tb->connect(micSource, 0, fileSink, 0);
>
> env->ReleaseStringUTFChars(jsinkfilename, sinkfilename);
> }
>
> I believe that I used either 32k and/or 44.1k. I was using a Nexus 7,
> though, and the codec might play a significant role with this between the
> two devices.
>
> Perhaps try setting the file sink to unbuffered mode?
>
> fileSink->set_unbuffered(true);
>
> Frankly, I feel like this is unlikely to help, but it'll be interesting to
> know what happens.
>
> Tom
>
>
> From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of
> Tom
> Rondeau
> Sent: March-17-15 07:37
> To: Vijay Galbaransingh
> Cc: GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] GNU Radio on Android
>
> On Tue, Mar 17, 2015 at 12:10 AM, Vijay Galbaransingh 
> wrote:
> Thanks Tom, that sorted it out. My audio output is a bit choppy but no
> matter – time to move on to some more complex flowgraphs in my Android app.
>
> Thanks again,
> Vijay
>
> Yes, the skipping in the audio output is a known bug, and  apparently known
> to be difficult in Android. It's going to take some kind of double
> buffering
> to fix it at this level. I did not experience any problems with the audio
> source, though; I just saved it to a file, brought it back to my computer,
> and played it there and it sounded fine.
>
> Tom
>
>
>
> From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of
> Tom
> Rondeau
> Sent: March-16-15 06:37
> To: Vijay Galbaransingh
> Cc: GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] GNU Radio on Android
>
> On Mon, Mar 16, 2015 at 3:28 AM, Vijay Galbaransingh 
> wrote:
> Hi Tom,
>
> I have been following your notes on the wiki in an attempt to build a test
> app (a dial tone flowgraph.) I'm hitting a snag on the ndk-build step
> though -- when I use your example Android.mk listing, the linker isn't
> finding any of the static libraries we built (gnuradio, grand, boost,
> fftw.)
> Instead I'm getting a pile of undefined reference errors.
>
> I tried editing the example Android.mk file by adding the following before
> the shared library build:
>
> include $(CLEAR_VARS)
> LOCAL_MODULE := grand_static_lib #for example
> LOCAL_SRC_FILES := /opt/grandroid/lib/libgnuradio-grand.a
> include $(PREBUILT_STATIC_LIBRARY)
>
> However I quickly realised that while there are only a few gnuradio
> libraries to add this way, there are a ton of boost libraries... Is there a
> smarter way to add all the prebuilt .a libraries at once? Or am I headed in
> the wrong direction entirely?
>
> Any tips appreciated,
> Vijay
>
>
> Yep, you have to add all of the libraries into the Android.mk file. I've
> updated the wiki:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GRAndApps
>
> You can go there and simply download GrAndroid.mk that does all of this for
> you and include it in your Android.mk file. Just follow the instructions.
>
> Hope that he

Re: [Discuss-gnuradio] Changing GUI Sink block params on the fly from a custom C++ block?

[Murphy, John]

Thanks, got it.
John Murphy
jmur...@comsonics.com


On Thu, Mar 19, 2015 at 10:30 AM, Tom Rondeau  wrote:
> On Thu, Mar 19, 2015 at 9:26 AM, Murphy, John  wrote:
>>
>> Hello GNU Radio'ers,
>>
>> I have a GRC flowgraph with a custom C++ block that feeds a stream of
>> vectors of floats to the QT GUI Vector Sink. Which particular internal
>> vector of floats gets streamed out of the custom C++ block is set on
>> the fly from a QT GUI Chooser. I am using the autoscale on the QT GUI
>> Vector Sink.
>>
>> The autoscale is okay but I do come up against shortcomings with it
>> and I could do better if I could somehow have the C++ code for the
>> custom C++ block (or the stuff in the GRC flowgraph, but that seems
>> more difficult to me) call some function to change the QT GUI Vector
>> Sink Y Axis Min and Max on the fly when the param choosing the vector
>> is changed.
>>
>> Would someone please indicate how to do this, if it can be done? And
>> perhaps provide a link to a similar example on the web to work from,
>> if such exists?
>>
>> Thanks,
>> John
>
>
> In the Vector Sink's properties, you can set a variable for the y-min and
> y-max. When you change the variable (via a slider or in any other way), it
> will change the y axis settings.
>
> Tom
>

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

Re: [Discuss-gnuradio] GRC taps as parameter in hierarchical block?

[Tom Rondeau]

On Wed, Mar 4, 2015 at 2:54 PM, Christopher Friedt 
wrote:

> Hi list,
>
> I'm looking for a pointer in using GRC when creating a hierarchical block.
>
> The hierarchical block has an parameter block of type None with ID
> 'taps'. The Value of the block is 'filter.firdes.root_raised_cosine(
> nfilts, nfilts, 1.0, 0.35, 11 * samples_per_symbol * nfilts )'. nfilts
> and samples_per_symbol are both also parameters. The 'taps' parameter
> block evaluates properly.
>
> The problem is, when I try to use the value of the 'taps' parameter
> within a Polyphase Arbitrary Resampler block configured as type ccf
> (Complex -> Complex ( Real Taps ) ), it does not evaluate the 'taps'
> parameter. The 'taps' field is brown, which obviously means it does
> not interpret the field.
>
> Value "taps" cannot be evaluated:
> name 'taps' is not defined
>
> However, when I use a Variable block for the exact same 'taps' value,
> the resampler works properly.
>
> Clearly the difference is that, with the variable block, the value is
> evaluated at compile time, versus when using a parameter, it must be
> compiled ... well... later at compile time... or at 'run time', if one
> could call it that.
>
> My question is, do any of the gurus on the list have a suggestion on
> how to 'cast' the parameter as a real_vector or something equivalent
> to make it usable as a block?
>
> If it matters why I'm doing this, I'd like to make the
> generic_mod_demod more generic by allowing the pulse shape filter to
> be specified as a parameter... and yes, I'm doing it in GRC rather
> than python for a few reasons.
>
> Cheers,
>
> C
>

This is an interesting problem, and I don't think that it has anything to
do with the taps, data types, or the resampler block. I think it's an order
of operations issue.

First, the brown color of the field does not indicate that anything is
wrong. It's just the color used when indicating a list of floats is
expected.

To resolve the issue -- not as a real solution just to prove this to
yourself -- is to plug in real numbers to the taps line instead of using
nfilts:

 'filter.firdes.root_raised_cosine(32, 32, 1.0, 0.35, 11 * 2 * 32)'

That should work. I just used 32 for nfilts and 2 for samples_per_symbol.

I think the problem is how and when the parameters are evaluated when used
in the block. We might have to consult Sebastian on this one.

In the meantime, perhaps using parameters to define other parameters isn't
really the right thing to do, anyways. You are setting the default value
based on the default value of another parameter. When actually using the
hier_block in another flowgraph, that nfilts doesn't propagate through to
reset the default value of the taps parameter. So I don't think that this
would even have the desired behavior you're looking for.

Maybe just hard-code those numbers in for the defaults and then the setup
in the flowgraph could change to using the variables set in the flowgraph,
not the hier_block.

Does this make sense?

Tom

P.S. I don't know where we came up with the constant 11 for our RRC
filters, but it's probably overkill. I'd think you can reduce that down to
5 or so to improve speed and not lose much in performance.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[ben Gee]

Sylvain,
Firstly, there is only one install of pybombs on this machine, so
definitely no separate install conflicts

Second, unfortunately, in an effort to start over, i uninstalled gr-fosphor
and attemted to reinstall it. I'm now getting this opencl error now. not
sure if this was something i overlooked last time, but i thought the build
was ok.
the resources on the internet regarding opencl are somewhat hazy (or at
least they are to me) and it seems that there are many different options
for drivers. Can you shed some light on building these with pybombs as a
dependency for gr-fosphor? Should they be installed system-wide or do they
have to be installed in the pybombs environment?

thanks,
-b

On Thu, Mar 19, 2015 at 3:22 AM, Sylvain Munaut <246...@gmail.com> wrote:

> On Wed, Mar 18, 2015 at 11:47 PM, ben Gee  wrote:
> > i should also add that the output of "./pyboms" list shows that
> gr-fosphor
> > IS installed, output below:
>
> Interesting ...
>
> Are you sure you haven't two install of pybombs with different
> prefixes that would mix things up ?
>
> If not, I think pybombs keeps a build log somewhere for the various
> installed package, try to find it and pastebin it somewhere.
>
> Cheers,
>
>Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[Sylvain Munaut]

> Can you shed some light on building these with pybombs as a
> dependency for gr-fosphor? Should they be installed system-wide or do they
> have to be installed in the pybombs environment?

The whole OpenCL SDK (headers / libs / drivers) must be installed
outside of pybombs, at the system level and before you try to build
gr-fosphor.

See the OpenCL notes on https://sdr.osmocom.org/trac/wiki/fosphor


Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] GNU Radio on Zedboard

[Alireza Khodamoradi]

Here are the files I have in the FAT partition (boot):

1- boot.bin
2- u-boot.img
3- uEnv.txt
4- uImage
5- zc702-zynq7.dtb

* I used this image: *sdimage-8G-zc702.direct*

On Thu, Mar 19, 2015 at 6:41 AM, Philip Balister 
wrote:

> On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote:
> > Philip,
> >
> > Thank you for letting me using your images. I tried both of them with
> the *dd
> > *command, it took me around 2000 seconds (30 mins) each and after using
> > them on the board I get the following message via the UART:
> >
> > *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)*
> > *mmc boot*
> > *reading fpga.bin*
> > *spl: error reding image fpga.bin, err - -1*
> > *reading system.dtb*
> > *spl: error reading image system.dtb, err - -1*
> > *reading u-boot.img*
> > *spl: error reading image u-boot.img, err - -1*
> > *### ERROR ### Please RESET the board ###*
>
> So the first stage boot loader is running, which is good.
>
> It looks for a couple of files which should be there, which is OK.
> (fpga.bin and system.dtb)
>
> Then it tries to load u-boot.img which it doesn't find. This is bad.
>
> Can you put the card in a PC and send the list of file in the FAT
> partition?
>
> Philip
>
>
> >
> > I got the above message for sdimage-8G-zc702.direct. I get no message for
> > the other image.
> >
> > What am I doing wrong?
> >
> > On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister 
> > wrote:
> >
> >> On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote:
> >>> Hello everyone,
> >>>
> >>> I'm going through the instructions from here:
> >>>
> >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
> >>
> >> I should go over those carefully, but in the mentime I have some images
> >> built for the zedbaord here:
> >>
> >>
> https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?dl=0
> >>
> >> Take the zedboard one, uncompress it and write it to an sd card. Be sure
> >> to unmount (not eject) the sd card and run:
> >>
> >> sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX
> >>
> >> where sdx is the device the sd card is on.
> >>
> >> Philip
> >>
> >>>
> >>> to get a working image with gnu radio for my zedboard.
> >>>
> >>> Unfortunately I can't get the board to boot with this image. I was
> >>> wondering if someone can help me.
> >>>
> >>> what I tried so far ( all failed - can't boot from the SDCard):
> >>>
> >>> - default settings in the instructions
> >>> - renaming u-boot.bin to boot.bin
> >>> - renaming u-boot.bin to BOOT.BIN
> >>> - renaming uImage--zedboard-zynq7.dtb to devicetree.dtb
> >>> - I tried command line as well as gparted gui.
> >>>
> >>> what I checked:
> >>>
> >>> - download a linux from XillyBus and boot the board with SDCard ->
> works
> >>>
> >>> v/r
> >>> Alireza
> >>>
> >>>
> >>>
> >>> ___
> >>> 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] OFDM test with USRP

[Henry Jin]

Hi Marcus,

Thanks for your very detailed comments.

My purpose of testing the PER is to facilitate evaluations on further
modifications of the codes. I'd like to set up a benchmark like the ones I
have shown and then draw a PER vs SNR curve to show the performance just
like how we do evaluations theoretically. So I prefer to find the root
cause of this phenomenon rather than using error correction
or re-transmission.

> I'm a bit surprised, though -- you just feed in random information, and
> that should be white, which means that packets with unhealthily high
> PAPR are seldom.

Originally, I feed in some fixed sequences. The working range of the const
value is even smaller, around (0.035, 0.025). So later I replaced it with
the random source. Indeed, I saw some improvement but yet not good enough.

> You should save the samples that come out of the OFDM mod block using a
> file sink, and analyze them later; look for samples with magnitude >1.0
> (they shouldn't be there, because the output of the internal IFFT is
> scaled with 1/sqrt(fftlen)).
> > However, when the const value increases, for example, to 0.06. the PER
> > is around 0.0044
> That doesn't sound half bad, considering you don't do any equalizing. I
> think (I'm not totally sure, was too lazy to look into the source code
> just now) that the OFDM implementation (you're using the older one, the
> newer one is cooler) doesn't do much on the receiving side to recover
> the signal.
> Have a look at the rx_ofdm example (in
> /usr/[local/]share/gnuradio/examples/digital/, or so). That's a bit more
> advanced than your RX.
According to my knowledge, the OFDM transceiver blocks I used is the latest
one. I've read all the related codes so I know that there is actually
equalization done on the receiver end. Besides, the more advanced example
you referred to is actually a breaking down of the receiver block that I
used. In other words, that is the internal implementation of the receiver
block I used.

I will try checking the sample values as you suggested. Also, maybe I'll
also use another USRP to test but I doubt it matters.

Best,
Henry



Message: 20
Date: Thu, 19 Mar 2015 13:37:53 +0100
From: Marcus M?ller 
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] OFDM test with USRP
Message-ID: <550ac321.10...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

Hi Henry,
> I have built a tx and a rx grc flowchart for OFDM using USRP. I found
> the range of the amplitude of the input is fairly small in order to
> get it working (i.e., the USRP at the rx end can successfully decode
> the packets.)  I wound if anyone can share some thoughts about this?
> I've been stuck here for several days.
there's very many factors limiting the decodability of a transmission --
the main being SNR, especially since you get problems the further you
move away, but also aspects like the increased multipath effects, that
the equalizer might or might not be up to compensate.

What you're seeing might be something else, though:
> Through my test, I found the const in multiply_const in the tx part
> (which corresponds to amplitude adjustment) needs to be (0.05, 0.025).
that value definitely has the effect of limiting the sample amplitude
that goes into your USRP. The USRP driver framework maps values from
-1;1 to (DAC_min; DAC_max), basically. Driving the USRP with values
close to (or even over) 1.0 will lead to clipping/gain compression
problems. However, small values of course lead to "weak signal" on
average, leading to low SNR. The OFDM Tx that you use internally uses
apropriate scaling to limit the values to magnitudes <= 1.0, so I'm a
bit surprised your constant is so small.

That is a problem so common in transmitters, especially in OFDM, that
there's an abbreviation for that PAPR - Peak-to-Average Power ratio.
You often combat that by doing appropriate coding, with the aim of
guaranteing that no info symbols that map to time signals with strong
peaks exist. However, that means that you can't use all the information
"capacity" of the OFDM words -- and will be slower in the end. You can
solve that by ignoring the clipped/compressed peaks and fix the
resulting packets by doing error correction -- but that also comes at
the price of less bits per second, since you have to add sufficient
redundancy in the transmitter. Your third option is to just don't care
so much and retransmit broken packets -- for low packet error rates,
that might be sufficient.

I'm a bit surprised, though -- you just feed in random information, and
that should be white, which means that packets with unhealthily high
PAPR are seldom.

You should save the samples that come out of the OFDM mod block using a
file sink, and analyze them later; look for samples with magnitude >1.0
(they shouldn't be there, because the output of the internal IFFT is
scaled with 1/sqrt(fftlen)).
> However, when the const value increas

[Discuss-gnuradio] GR Dev Call March on Now

[Martin Braun]

Follow us live at http://youtu.be/lBA-2d4yT08, or on #gnuradio.

See ya!

M

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

Re: [Discuss-gnuradio] Audio Source configuration

[Larry Van Der Jagt]

Hello:

Thanks to everyone who has replied.  It seems that audio processing has
some sort of timing issues.

When I experiment with the channelizers detailed in;

http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html

https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633d9/543aee20e4b09162d086354d/1395272342027/fm_channelizer.grc

With the only change being setting the Mb0 clock source to default rather
than as in the demo in order to get the flowgraph to run on my E310 as well
as my B210,  The B210 is running on an Ubuntu 12.04 kernel
3.8.0-44-generic,  the E310 is running 3.14.2-xilinx.

I find that the code runs with minimal aU and O on the B210 connected using
USB3 to an I7 machine.

However, when I I try the exact same code Xed in to my E310 running the
Dizzy Demo image with updates to allow for QTGUI and QWT to operate,

There are very many string of approximately 30 Os  interspered with single
aUs and these overflow result in completely broken unusable audio.

I am now researching what levers may be available for audio system tuning
and into the possibility of switching to Jack for audio ...

As always any links or pointers are welcomed.

LVDJ



On Tue, Mar 17, 2015 at 10:30 AM, Larry Van Der Jagt 
wrote:

> Hello:
>
> Can anyone point me to some "color" on how to work with the Audio Source.
> I am working examples to transmit FM Audio and have problems with Underruns
> on the UHD:USRP Sink.
>
> The examples (from files.ettus.com/tutorials/Lab_5.grc and others) I am
> running select Audio Source Arch:alsa and this seems to be a problem.
>
> I have tried to replace the Device name with plughw:0,0 as suggested in
> the documetnation, but this does not seem to have an impact on the choice
> of Audio arch: alsa
>
> If I replace the audio source with a signal source at the same sample rate
> all is well, but the Audio Source implements .
>
> Using the suggestion of having the USRP expect a bit lower rate than the
> audio can deliver seems to implement nearly limitless delay  the voice
> is received but only after a very long ... many seconds delay ... 
>
> At this time I am using a B210 connected via USB3 to an I7 with plenty of
> memory running Ubuntu 12.04   I have similar issues trying to use an
> E310 as the transmitter ...
>
> Any direction would be appreciated.
>
> LVDJ
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[Tom McDermott]

My particular video card OpenCL drivers moved where they were installed
between different
versions of Ubuntu. I tracked it down with:

~$ locate libOpenCL.so

  producing...
/usr/lib/i386-linux-gnu/libOpenCL.so.1
/usr/lib/i386-linux-gnu/libOpenCL.so.1.0
/usr/lib/i386-linux-gnu/libOpenCL.so.1.0.0
/usr/lib/x86_64-linux-gnu/libOpenCL.so
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0

So when building gr-fosphor:

cmake ../ -DOPENCL_LIBRARY=/usr/lib/x86_64-linux-gnu/libOpenCL.so


-- Tom, N5EG



On Thu, Mar 19, 2015 at 8:51 AM, ben Gee  wrote:

> Sylvain,
> Firstly, there is only one install of pybombs on this machine, so
> definitely no separate install conflicts
>
> Second, unfortunately, in an effort to start over, i uninstalled
> gr-fosphor and attemted to reinstall it. I'm now getting this opencl error
> now. not sure if this was something i overlooked last time, but i thought
> the build was ok.
> the resources on the internet regarding opencl are somewhat hazy (or at
> least they are to me) and it seems that there are many different options
> for drivers. Can you shed some light on building these with pybombs as a
> dependency for gr-fosphor? Should they be installed system-wide or do they
> have to be installed in the pybombs environment?
>
> thanks,
> -b
>
> On Thu, Mar 19, 2015 at 3:22 AM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> On Wed, Mar 18, 2015 at 11:47 PM, ben Gee  wrote:
>> > i should also add that the output of "./pyboms" list shows that
>> gr-fosphor
>> > IS installed, output below:
>>
>> Interesting ...
>>
>> Are you sure you haven't two install of pybombs with different
>> prefixes that would mix things up ?
>>
>> If not, I think pybombs keeps a build log somewhere for the various
>> installed package, try to find it and pastebin it somewhere.
>>
>> Cheers,
>>
>>Sylvain
>>
>
>
> ___
> 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] cmake can't find 'gnuradio-runtime'

[rohin]

hello

i got the exact same error

i am following the guidlines given for OOT module given here-
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules


/rohin@rohin-Inspiron-5520:~/gr-howto/build$ cmake ../
-- Build type not specified: defaulting to release.
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:492 ] _boost_TEST_VERSIONS
=
1.35.0;1.35;1.36.0;1.36;1.37.0;1.37;1.38.0;1.38;1.39.0;1.39;1.40.0;1.40;1.41.0;1.41;1.42.0;1.42;1.43.0;1.43;1.44.0;1.44;1.45.0;1.45;1.46.0;1.46;1.47.0;1.47;1.48.0;1.48;1.49.0;1.49;1.50.0;1.50;1.51.0;1.51;1.52.0;1.52;1.53.0;1.53;1.54.0;1.54;1.55.0;1.55;1.56.0;1.56;1.57.0;1.57;1.58.0;1.58;1.59.0;1.59;1.60.0;1.60;1.61.0;1.61;1.62.0;1.62;1.63.0;1.63;1.64.0;1.64;1.65.0;1.65;1.66.0;1.66;1.67.0;1.67;1.68.0;1.68;1.69.0;1.69;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:494 ]
Boost_USE_MULTITHREADED = TRUE
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:496 ]
Boost_USE_STATIC_LIBS = 
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:498 ]
Boost_USE_STATIC_RUNTIME = 
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:500 ]
Boost_ADDITIONAL_VERSIONS =
1.35.0;1.35;1.36.0;1.36;1.37.0;1.37;1.38.0;1.38;1.39.0;1.39;1.40.0;1.40;1.41.0;1.41;1.42.0;1.42;1.43.0;1.43;1.44.0;1.44;1.45.0;1.45;1.46.0;1.46;1.47.0;1.47;1.48.0;1.48;1.49.0;1.49;1.50.0;1.50;1.51.0;1.51;1.52.0;1.52;1.53.0;1.53;1.54.0;1.54;1.55.0;1.55;1.56.0;1.56;1.57.0;1.57;1.58.0;1.58;1.59.0;1.59;1.60.0;1.60;1.61.0;1.61;1.62.0;1.62;1.63.0;1.63;1.64.0;1.64;1.65.0;1.65;1.66.0;1.66;1.67.0;1.67;1.68.0;1.68;1.69.0;1.69
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:502 ]
Boost_NO_SYSTEM_PATHS = 
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:554 ] Declared as CMake or
Environmental Variables:
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:556 ]   BOOST_ROOT = 
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:558 ]   BOOST_INCLUDEDIR = 
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:560 ]   BOOST_LIBRARYDIR = 
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:562 ] _boost_TEST_VERSIONS
=
1.35.0;1.35;1.36.0;1.36;1.37.0;1.37;1.38.0;1.38;1.39.0;1.39;1.40.0;1.40;1.41.0;1.41;1.42.0;1.42;1.43.0;1.43;1.44.0;1.44;1.45.0;1.45;1.46.0;1.46;1.47.0;1.47;1.48.0;1.48;1.49.0;1.49;1.50.0;1.50;1.51.0;1.51;1.52.0;1.52;1.53.0;1.53;1.54.0;1.54;1.55.0;1.55;1.56.0;1.56;1.57.0;1.57;1.58.0;1.58;1.59.0;1.59;1.60.0;1.60;1.61.0;1.61;1.62.0;1.62;1.63.0;1.63;1.64.0;1.64;1.65.0;1.65;1.66.0;1.66;1.67.0;1.67;1.68.0;1.68;1.69.0;1.69;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:655 ] location of
version.hpp: /usr/include/boost/version.hpp
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:679 ] version.hpp reveals
boost 1.54.0
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:755 ] guessed
_boost_COMPILER = -gcc48
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:765 ] _boost_MULTITHREADED
= -mt
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:808 ]
_boost_RELEASE_ABI_TAG = -
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:810 ] _boost_DEBUG_ABI_TAG
= -d
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:859 ]
_boost_LIBRARY_SEARCH_DIRS = /usr/lib/i386-linux-gnu;NO_DEFAULT_PATH
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:947 ] Searching for
FILESYSTEM_LIBRARY_RELEASE:
boost_filesystem-gcc48-mt-1_54;boost_filesystem-gcc48-mt;boost_filesystem-mt-1_54;boost_filesystem-mt;boost_filesystem
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:983 ] Searching for
FILESYSTEM_LIBRARY_DEBUG:
boost_filesystem-gcc48-mt-d-1_54;boost_filesystem-gcc48-mt-d;boost_filesystem-mt-d-1_54;boost_filesystem-mt-d;boost_filesystem-mt;boost_filesystem
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:947 ] Searching for
SYSTEM_LIBRARY_RELEASE:
boost_system-gcc48-mt-1_54;boost_system-gcc48-mt;boost_system-mt-1_54;boost_system-mt;boost_system
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:983 ] Searching for
SYSTEM_LIBRARY_DEBUG:
boost_system-gcc48-mt-d-1_54;boost_system-gcc48-mt-d;boost_system-mt-d-1_54;boost_system-mt-d;boost_system-mt;boost_system
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:1034 ] Boost_FOUND = 1
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- checking for module 'gnuradio-runtime'
--   package 'gnuradio-runtime' not found
-- Could NOT find GNURADIO_RUNTIME (missing:  GNURADIO_RUNTIME_LIBRARIES) 
-- checking for module 'cppunit'
--   package 'cppunit' not found
-- Could NOT find CPPUNIT (missing:  CPPUNIT_INCLUDE_DIRS) 
CMake Er

Re: [Discuss-gnuradio] cmake can't find 'gnuradio-runtime'

[Tom Rondeau]

On Thu, Mar 19, 2015 at 3:31 PM, rohin  wrote:

> hello
>
> i got the exact same error
>
> i am following the guidlines given for OOT module given here-
> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
>
>
> /rohin@rohin-Inspiron-5520:~/gr-howto/build$ cmake ../
> -- Build type not specified: defaulting to release.
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:492 ]
> _boost_TEST_VERSIONS
> =
>
> 1.35.0;1.35;1.36.0;1.36;1.37.0;1.37;1.38.0;1.38;1.39.0;1.39;1.40.0;1.40;1.41.0;1.41;1.42.0;1.42;1.43.0;1.43;1.44.0;1.44;1.45.0;1.45;1.46.0;1.46;1.47.0;1.47;1.48.0;1.48;1.49.0;1.49;1.50.0;1.50;1.51.0;1.51;1.52.0;1.52;1.53.0;1.53;1.54.0;1.54;1.55.0;1.55;1.56.0;1.56;1.57.0;1.57;1.58.0;1.58;1.59.0;1.59;1.60.0;1.60;1.61.0;1.61;1.62.0;1.62;1.63.0;1.63;1.64.0;1.64;1.65.0;1.65;1.66.0;1.66;1.67.0;1.67;1.68.0;1.68;1.69.0;1.69;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:494 ]
> Boost_USE_MULTITHREADED = TRUE
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:496 ]
> Boost_USE_STATIC_LIBS =
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:498 ]
> Boost_USE_STATIC_RUNTIME =
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:500 ]
> Boost_ADDITIONAL_VERSIONS =
>
> 1.35.0;1.35;1.36.0;1.36;1.37.0;1.37;1.38.0;1.38;1.39.0;1.39;1.40.0;1.40;1.41.0;1.41;1.42.0;1.42;1.43.0;1.43;1.44.0;1.44;1.45.0;1.45;1.46.0;1.46;1.47.0;1.47;1.48.0;1.48;1.49.0;1.49;1.50.0;1.50;1.51.0;1.51;1.52.0;1.52;1.53.0;1.53;1.54.0;1.54;1.55.0;1.55;1.56.0;1.56;1.57.0;1.57;1.58.0;1.58;1.59.0;1.59;1.60.0;1.60;1.61.0;1.61;1.62.0;1.62;1.63.0;1.63;1.64.0;1.64;1.65.0;1.65;1.66.0;1.66;1.67.0;1.67;1.68.0;1.68;1.69.0;1.69
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:502 ]
> Boost_NO_SYSTEM_PATHS =
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:554 ] Declared as CMake
> or
> Environmental Variables:
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:556 ]   BOOST_ROOT =
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:558 ]   BOOST_INCLUDEDIR
> =
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:560 ]   BOOST_LIBRARYDIR
> =
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:562 ]
> _boost_TEST_VERSIONS
> =
>
> 1.35.0;1.35;1.36.0;1.36;1.37.0;1.37;1.38.0;1.38;1.39.0;1.39;1.40.0;1.40;1.41.0;1.41;1.42.0;1.42;1.43.0;1.43;1.44.0;1.44;1.45.0;1.45;1.46.0;1.46;1.47.0;1.47;1.48.0;1.48;1.49.0;1.49;1.50.0;1.50;1.51.0;1.51;1.52.0;1.52;1.53.0;1.53;1.54.0;1.54;1.55.0;1.55;1.56.0;1.56;1.57.0;1.57;1.58.0;1.58;1.59.0;1.59;1.60.0;1.60;1.61.0;1.61;1.62.0;1.62;1.63.0;1.63;1.64.0;1.64;1.65.0;1.65;1.66.0;1.66;1.67.0;1.67;1.68.0;1.68;1.69.0;1.69;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:655 ] location of
> version.hpp: /usr/include/boost/version.hpp
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:679 ] version.hpp reveals
> boost 1.54.0
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:755 ] guessed
> _boost_COMPILER = -gcc48
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:765 ]
> _boost_MULTITHREADED
> = -mt
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:808 ]
> _boost_RELEASE_ABI_TAG = -
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:810 ]
> _boost_DEBUG_ABI_TAG
> = -d
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:859 ]
> _boost_LIBRARY_SEARCH_DIRS = /usr/lib/i386-linux-gnu;NO_DEFAULT_PATH
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:947 ] Searching for
> FILESYSTEM_LIBRARY_RELEASE:
>
> boost_filesystem-gcc48-mt-1_54;boost_filesystem-gcc48-mt;boost_filesystem-mt-1_54;boost_filesystem-mt;boost_filesystem
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:983 ] Searching for
> FILESYSTEM_LIBRARY_DEBUG:
>
> boost_filesystem-gcc48-mt-d-1_54;boost_filesystem-gcc48-mt-d;boost_filesystem-mt-d-1_54;boost_filesystem-mt-d;boost_filesystem-mt;boost_filesystem
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:947 ] Searching for
> SYSTEM_LIBRARY_RELEASE:
>
> boost_system-gcc48-mt-1_54;boost_system-gcc48-mt;boost_system-mt-1_54;boost_system-mt;boost_system
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:983 ] Searching for
> SYSTEM_LIBRARY_DEBUG:
>
> boost_system-gcc48-mt-d-1_54;boost_system-gcc48-mt-d;boost_system-mt-d-1_54;boost_system-mt-d;boost_system-mt;boost_system
> -- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:1034 ] Boost_FOUND = 1
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- checking for module 'gnuradio-runtime'
> --   package 'gnuradio-runtime' not found
> -- Could NO

[Discuss-gnuradio] USRP B210 "UHD Error: recv packet demuxer unexpected sid 0xff87ffc3"

[Larry Van Der Jagt]

Hello:

Running examples from:


http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html

https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633d9/543aee20e4b09162d086354d/1395272342027/fm_channelizer.grc

With the the following changes:

1) Mb0 Clock sources in UHD:USRP source set to Default

2) Output of Polyphase decimator routed to new UHD:USRP Sink with sample
rate set to 200k to match Polyphase Decimator rate and center frequency set
to 93.9 MHz (source center frequency is 97.9 MHz in intended application,
but problem also occurs when source and sink frequencies match)

System runs successfully for roughly 5 minutes and then errors with a
series of:

UHD Error: recv packet demuxer unexpected sid 0xff87ffc3

Over and over.  Sometimes the sid listed is the same, sometimes it changes.

Running UHD 003.008.001-82-g9e6ff291 over GNURadio 3.7.6.1 utilizing USB3
on I7 running Ubuntu 12.04 LTS.  The firmware loaded is the standard
usrp_b200_fw.hex that came with the build.

I note this was looked at in:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/009516.html

but I do not find a resolution at that time .

Once this occurs it is necessary to unplug and replug the USB cable to get
the system to operate again.

There are occasional   UUU OOO Ua during operation, but these
occur albeit less frequently without the addition of the USRP Sink and I
have not seen the sid error when this Sink is absent.

As always any links or info is welcomed.

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

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[ben Gee]

ok, no progress, but here's what i've done so far. (all as per the
https://sdr.osmocom.org/trac/wiki/fosphor instructions)

sudo apt-get install cmake xorg-dev libglu1-mesa-dev

git clone https://github.com/glfw/glfw
cd glfw
mkdir build
cd build
cmake ../ -DBUILD_SHARED_LIBS=true
make
sudo make install
sudo ldconfig

then, sudo apt-get install opencl-headers

Next, because i have an intel integrated graphics controller in my laptop i
chose the "Intel CPU OpenCL" option from the instructions
i went to the link on the page, but it says that there is no standalone
OpenCL SDK package anymore and that you have to download the "Intel Code
Builder for OpenCL" so i downloaded and installed this:

https://software.intel.com/en-us/articles/intel-code-builder-for-opencl-api

after that, (from my pybombs directory) i ran ./pybombs install gr-fosphor
which returns an 'ok' message at the end of the install.
I now run osmocom get this for my output:

http://pastebin.com/SpWJKwBc



On Thu, Mar 19, 2015 at 2:45 PM, Tom McDermott  wrote:

> My particular video card OpenCL drivers moved where they were installed
> between different
> versions of Ubuntu. I tracked it down with:
>
> ~$ locate libOpenCL.so
>
>   producing...
> /usr/lib/i386-linux-gnu/libOpenCL.so.1
> /usr/lib/i386-linux-gnu/libOpenCL.so.1.0
> /usr/lib/i386-linux-gnu/libOpenCL.so.1.0.0
> /usr/lib/x86_64-linux-gnu/libOpenCL.so
> /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
> /usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0
> /usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0
>
> So when building gr-fosphor:
>
> cmake ../ -DOPENCL_LIBRARY=/usr/lib/x86_64-linux-gnu/libOpenCL.so
>
>
> -- Tom, N5EG
>
>
>
> On Thu, Mar 19, 2015 at 8:51 AM, ben Gee  wrote:
>
>> Sylvain,
>> Firstly, there is only one install of pybombs on this machine, so
>> definitely no separate install conflicts
>>
>> Second, unfortunately, in an effort to start over, i uninstalled
>> gr-fosphor and attemted to reinstall it. I'm now getting this opencl error
>> now. not sure if this was something i overlooked last time, but i thought
>> the build was ok.
>> the resources on the internet regarding opencl are somewhat hazy (or at
>> least they are to me) and it seems that there are many different options
>> for drivers. Can you shed some light on building these with pybombs as a
>> dependency for gr-fosphor? Should they be installed system-wide or do they
>> have to be installed in the pybombs environment?
>>
>> thanks,
>> -b
>>
>> On Thu, Mar 19, 2015 at 3:22 AM, Sylvain Munaut <246...@gmail.com> wrote:
>>
>>> On Wed, Mar 18, 2015 at 11:47 PM, ben Gee  wrote:
>>> > i should also add that the output of "./pyboms" list shows that
>>> gr-fosphor
>>> > IS installed, output below:
>>>
>>> Interesting ...
>>>
>>> Are you sure you haven't two install of pybombs with different
>>> prefixes that would mix things up ?
>>>
>>> If not, I think pybombs keeps a build log somewhere for the various
>>> installed package, try to find it and pastebin it somewhere.
>>>
>>> Cheers,
>>>
>>>Sylvain
>>>
>>
>>
>> ___
>> 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] OFDM test with USRP

[Henry Jin]

Hi Marcus,

I later added a throttle and time scope to the tx end to see how large the
amplitude can be. Indeed, when the multiplier is 60m, the amplitude
increases beyond 1, which will be clipped by the USRP driver. Setting it to
be 0.45 seems like a safe choice.

For small amplitude cases such as when the multiplier is 20m, the SNR is
also low. The reason the OFDM receiver fails to receive many packets is
actually because the threshold used in digital.ofdm_sync_sc_cfb() for the
plateau detector. Currently, the code leaves the threshold value to be
default, which is 0.9. In low SNR cases, in fact, we need to set it smaller
to tolerate noise. Originally, let's say the synchronization rate is only
1% or even lower, after this adjustment, it can be over 90%. I suggest
adding a parameter in ofdm_txrx.py to adjust this parameter.

Back to the high SNR cases, one issue puzzling me now is that when the
multiplier is 60m, although indeed there are samples exceeding the
amplitude limitation of 1, many other samples (in fact most of them) have a
small amplitude less than 0.5. This greatly limits the overall SNR we can
get. I wonder if there can be any improvements over this?

Thanks
Henry

On Thu, Mar 19, 2015 at 10:17 AM, Henry Jin  wrote:

> Hi Marcus,
>
> Thanks for your very detailed comments.
>
> My purpose of testing the PER is to facilitate evaluations on further
> modifications of the codes. I'd like to set up a benchmark like the ones I
> have shown and then draw a PER vs SNR curve to show the performance just
> like how we do evaluations theoretically. So I prefer to find the root
> cause of this phenomenon rather than using error correction
> or re-transmission.
>
> > I'm a bit surprised, though -- you just feed in random information, and
> > that should be white, which means that packets with unhealthily high
> > PAPR are seldom.
>
> Originally, I feed in some fixed sequences. The working range of the const
> value is even smaller, around (0.035, 0.025). So later I replaced it with
> the random source. Indeed, I saw some improvement but yet not good enough.
>
> > You should save the samples that come out of the OFDM mod block using a
> > file sink, and analyze them later; look for samples with magnitude >1.0
> > (they shouldn't be there, because the output of the internal IFFT is
> > scaled with 1/sqrt(fftlen)).
> > > However, when the const value increases, for example, to 0.06. the PER
> > > is around 0.0044
> > That doesn't sound half bad, considering you don't do any equalizing. I
> > think (I'm not totally sure, was too lazy to look into the source code
> > just now) that the OFDM implementation (you're using the older one, the
> > newer one is cooler) doesn't do much on the receiving side to recover
> > the signal.
> > Have a look at the rx_ofdm example (in
> > /usr/[local/]share/gnuradio/examples/digital/, or so). That's a bit more
> > advanced than your RX.
> According to my knowledge, the OFDM transceiver blocks I used is the
> latest one. I've read all the related codes so I know that there is
> actually equalization done on the receiver end. Besides, the more advanced
> example you referred to is actually a breaking down of the receiver block
> that I used. In other words, that is the internal implementation of the
> receiver block I used.
>
> I will try checking the sample values as you suggested. Also, maybe I'll
> also use another USRP to test but I doubt it matters.
>
> Best,
> Henry
>
>
> 
>
> Message: 20
> Date: Thu, 19 Mar 2015 13:37:53 +0100
> From: Marcus M?ller 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] OFDM test with USRP
> Message-ID: <550ac321.10...@ettus.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Henry,
> > I have built a tx and a rx grc flowchart for OFDM using USRP. I found
> > the range of the amplitude of the input is fairly small in order to
> > get it working (i.e., the USRP at the rx end can successfully decode
> > the packets.)  I wound if anyone can share some thoughts about this?
> > I've been stuck here for several days.
> there's very many factors limiting the decodability of a transmission --
> the main being SNR, especially since you get problems the further you
> move away, but also aspects like the increased multipath effects, that
> the equalizer might or might not be up to compensate.
>
> What you're seeing might be something else, though:
> > Through my test, I found the const in multiply_const in the tx part
> > (which corresponds to amplitude adjustment) needs to be (0.05, 0.025).
> that value definitely has the effect of limiting the sample amplitude
> that goes into your USRP. The USRP driver framework maps values from
> -1;1 to (DAC_min; DAC_max), basically. Driving the USRP with values
> close to (or even over) 1.0 will lead to clipping/gain compression
> problems. However, small values of course lead to "weak signal" on
> average, leadi

Re: [Discuss-gnuradio] Splitting a vector at the output of the FFT

[Alejandro Pascual Laguna]

Thanks for the quick reply!

When I said splitting in the GUI I meant using the flowgraph (instead of 
digging into the code) not using the sink FFT. As you say, I am using 
the standalone block for the FFT and I want to split its output. Is 
there any block to do so or any kind of snippet of code to add in the 
fields of the parameters of the subsequent blocks?


Regarding the FFT output now it is much more clear having the actual 
implementation info. However, prior to this conversation I remember I 
used at the output of the FFT block a vector sink and, interestingly 
enough, I saw for a constant source a bin in the middle of the plot (at 
index fftSize/2) and when using a cosine with a certain frequency, the 
spectrum shifted right but nothing showed up in the "negative" 
frequencies. I'll take a look at it again.


Again, thank you for your time.

Regards,
Alejandro

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

Re: [Discuss-gnuradio] USRP B210 "UHD Error: recv packet demuxer unexpected sid 0xff87ffc3"

[Marcus D. Leech]

On 03/19/2015 04:39 PM, Larry Van Der Jagt wrote:

Hello:

Running examples from:


http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html

https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633d9/543aee20e4b09162d086354d/1395272342027/fm_channelizer.grc

With the the following changes:

1) Mb0 Clock sources in UHD:USRP source set to Default

2) Output of Polyphase decimator routed to new UHD:USRP Sink with 
sample rate set to 200k to match Polyphase Decimator rate and center 
frequency set to 93.9 MHz (source center frequency is 97.9 MHz in 
intended application, but problem also occurs when source and sink 
frequencies match)


System runs successfully for roughly 5 minutes and then errors with a 
series of:


UHD Error: recv packet demuxer unexpected sid 0xff87ffc3

Over and over.  Sometimes the sid listed is the same, sometimes it 
changes.


Running UHD 003.008.001-82-g9e6ff291 over GNURadio 3.7.6.1 utilizing 
USB3 on I7 running Ubuntu 12.04 LTS.  The firmware loaded is the 
standard usrp_b200_fw.hex that came with the build.


I note this was looked at in:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/009516.html

but I do not find a resolution at that time .

Once this occurs it is necessary to unplug and replug the USB cable to 
get the system to operate again.


There are occasional   UUU OOO Ua during operation, but these 
occur albeit less frequently without the addition of the USRP Sink and 
I have not seen the sid error when this Sink is absent.


As always any links or info is welcomed.

LVDJ


Basically, what seems to happen with B200, is that overruns tend to turn 
into cascades that yield dropped USB frames, which provokes "syntax 
errors" in the underlying (or overlying, depending on your view of the 
VITA-49 stack) protocol layer.


What type of USB subsystem do you have?  What CPU utilization is 
happening when you're running the flow-graph.  I don't have a good feel for
  how "crunchy" a PFB decimator is compared to, for example, a 
hierarchical filtering scheme to get you from 20Msps to a single WBFM 
channel.


If you really are interested in just a single WBFM channel, then 
bringing the samples in at a lower rate is preferable.  I usually run 
the radio interface at
  1Msps, and filter-and-decimate down to 250kHz.  I get good results 
that way.


I realize this may just be an "exploratory" thing for you, on the way to 
something else.


Also, I just noticed that you're running an older (very) Ubuntu. The 
older kernels had poorer USB-3.0 support, so something to consider would be

  to upgrade your OS to 14.04 LTS.



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

Re: [Discuss-gnuradio] OFDM test with USRP

[Martin Braun]

On 19.03.2015 14:11, Henry Jin wrote:

Hi Marcus,

I later added a throttle and time scope to the tx end to see how large
the amplitude can be. Indeed, when the multiplier is 60m, the amplitude
increases beyond 1, which will be clipped by the USRP driver. Setting it
to be 0.45 seems like a safe choice.


You might be able to push it a bit more. But definitely stay clear from 1.


For small amplitude cases such as when the multiplier is 20m, the SNR is
also low. The reason the OFDM receiver fails to receive many packets is
actually because the threshold used in digital.ofdm_sync_sc_cfb() for
the plateau detector. Currently, the code leaves the threshold value to
be default, which is 0.9. In low SNR cases, in fact, we need to set it
smaller to tolerate noise. Originally, let's say the synchronization
rate is only 1% or even lower, after this adjustment, it can be over
90%. I suggest adding a parameter in ofdm_txrx.py to adjust this parameter.


Hm. S&C works fine for low SNRs, and changing the threshold is usually 
not required, due to normalization. I'd be hesitant to add that 
parameter, there might be another issue here. When you say low SNR, 
which regime are you talking about? Because the slicers (QPSK demapping) 
will usually fail before the detection.



Back to the high SNR cases, one issue puzzling me now is that when the
multiplier is 60m, although indeed there are samples exceeding the
amplitude limitation of 1, many other samples (in fact most of them)
have a small amplitude less than 0.5. This greatly limits the overall
SNR we can get. I wonder if there can be any improvements over this?


This is a well-known OFDM issue. You can choose an encoding that will 
limit PAPR, use pilot tones that decrease PAPR... and many other 
PAPR-reducing techniques.
This also depends on how many subcarriers you use. For random data, your 
PAPR usually stays within 2*ln(N), which is usually not that bad.


Cheers,
M

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

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[Sylvain Munaut]

> I now run osmocom get this for my output:
>
> http://pastebin.com/SpWJKwBc

Pastebin :
 - A full listing of all the files in your pybomb install (using find)
 - The complete build logs of gr-fosphor (and no, I have no idea where
to find those, I never used pybombs, but it must put them somewhere)

Cheers,

 Sylvain

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

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[Sylvain Munaut]

Also :

> Next, because i have an intel integrated graphics controller in my laptop i
> chose the "Intel CPU OpenCL" option from the instructions
> i went to the link on the page, but it says that there is no standalone
> OpenCL SDK package anymore and that you have to download the "Intel Code
> Builder for OpenCL" so i downloaded and installed this:
>
> https://software.intel.com/en-us/articles/intel-code-builder-for-opencl-api

Actually if you read everything they say it's still available for linux :

https://software.intel.com/en-us/articles/opencl-drivers#ubuntu64

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

Re: [Discuss-gnuradio] OFDM test with USRP

[Henry Jin]

Hi Martin,

Thanks for the FOSDEM 14 video on youtube (although maybe not posted by
you). Your talk is very informative and helpful.

On Thursday, March 19, 2015, Martin Braun  wrote:

> On 19.03.2015 14:11, Henry Jin wrote:
>
>> Hi Marcus,
>>
>> I later added a throttle and time scope to the tx end to see how large
>> the amplitude can be. Indeed, when the multiplier is 60m, the amplitude
>> increases beyond 1, which will be clipped by the USRP driver. Setting it
>> to be 0.45 seems like a safe choice.
>>
>
> You might be able to push it a bit more. But definitely stay clear from 1.
>

There is a typo here. The max multiplier I can set is 0.045. This value is
based on the display on the time scope. The value ensures that every sample
stays below the limit of 1.


>
>  For small amplitude cases such as when the multiplier is 20m, the SNR is
>> also low. The reason the OFDM receiver fails to receive many packets is
>> actually because the threshold used in digital.ofdm_sync_sc_cfb() for
>> the plateau detector. Currently, the code leaves the threshold value to
>> be default, which is 0.9. In low SNR cases, in fact, we need to set it
>> smaller to tolerate noise. Originally, let's say the synchronization
>> rate is only 1% or even lower, after this adjustment, it can be over
>> 90%. I suggest adding a parameter in ofdm_txrx.py to adjust this
>> parameter.
>>
>
> Hm. S&C works fine for low SNRs, and changing the threshold is usually not
> required, due to normalization. I'd be hesitant to add that parameter,
> there might be another issue here. When you say low SNR, which regime are
> you talking about? Because the slicers (QPSK demapping) will usually fail
> before the detection.
>

Since there seems no available SNR estimators for OFDM yet in GNURadio, I
implemented one myself. Although it seems to be not quite accurate, but it
can serve as a reference. The low SNR I was talking about is around 13 dB.
The observation that motivates me to modify the threshold is that the
receiver can almost fully decode every packet it received (i.e., the PER is
quite low, around 2%). However, I noted that in fact many packets are
missing by observing the inconsistent packet_number in the tag debug at the
receiver end. Conservatively speaking, more than 80% missed. So I figure
that maybe it is because the sync module fails to detect a peak. By adding
some debug code, I am able to find the peak gap between each other is
random and large, not constant and small (It should be the exact or nearly
exact number of samples in the whole frame). So by lowering the threshold,
now it seems to be working as expected as now many packets can indeed be
received and decoded. To play safe, I only lower the threshold when needed.
If the SNR is high, default value can still be used.


>
>  Back to the high SNR cases, one issue puzzling me now is that when the
>> multiplier is 60m, although indeed there are samples exceeding the
>> amplitude limitation of 1, many other samples (in fact most of them)
>> have a small amplitude less than 0.5. This greatly limits the overall
>> SNR we can get. I wonder if there can be any improvements over this?
>>
>
> This is a well-known OFDM issue. You can choose an encoding that will
> limit PAPR, use pilot tones that decrease PAPR... and many other
> PAPR-reducing techniques.
> This also depends on how many subcarriers you use. For random data, your
> PAPR usually stays within 2*ln(N), which is usually not that bad.
>

I see. Currently, I'm using 48 data subcarriers out of 64 in total.


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


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

[Discuss-gnuradio] Fwd: AttributeError: 'module' object has no attribute 'block_name'

[Mike Heese]

Tom,

I sincerely apologize if I have posted this email to the wrong location but
this is where the web page sent me.

I have forwarded my original email below and hope it shows up as you
expected.

Any info you can provide on this problem would be greatly appreciated.

Thanks!
Mike Heese





Forwarded conversation
Subject: Re: [Discuss-gnuradio] AttributeError: 'module' object has no
attribute 'block_name'


From: *Mike Heese* 
Date: Wed, Mar 18, 2015 at 10:07 PM
To: t...@trondeau.com


Sir,

I am having the exact same issues as those discussed in this thread and
have not found any solutions that work.  I apologize for the strange-ness
of the email but we've been struggling with this problem for several days.

First, I have GNU Radio 3.7.5.1 installed on three different Laptops each
running 64-bit Ubuntu.  GNURadio was installed using the 'apt-get' install
call for gnuradio with no other modifications.  The steps below will
produce this exact problem on every machine we have tried it on.

Step 1.
Pick any GNU Radio Tutorial such as the 'square2_ff' Tutorial.  Follow all
the steps exactly as indicated to create the basic block.  Compile and
install the block into GNURadio following the steps in the Tutorial.  Run
the Block in GNURadio.  The Block should work in GNURadio exactly as
indicated in the Tutorial.  Great Tutorial by the way!

Step 2.
Now, completely exit GNURadio.  Open the 'square2_ff_impl.cc' file (or
whatever your implementation file is) and add (any) one of the C++ API
Class Headers such as:
#include <*gnuradio/filter/fir_filter_fff.h*
>

Next, in the constructor for square2_ff_impl add a single line to
instantiate a filter object such as:
gr::filter::fir_filter_fff::sptr
filter(gr::filter::fir_filter_fff::make(1,m_taps));

Make sure the 'm_taps' vector does in fact hold values but don't do
anything else here.  Just declare a variable of the C++ API Class you
picked. Do not modify any other files than the .cc file.

Step 3.
Following this, compile the Block code and install the Block into GNURadio
again following the exact same steps from the Tutorial as before.  The Test
Steps on my machine do not indicate any errors here, which is adding to my
confusions.

Step 4.
Open GNURadio and try running the 'square2_ff' (or whatever yours is
called) Block again.
Now, with every machine I've tried this on, you will get the error:
AttributeError:'module' object has no attribute 'square2_ff'

Following this, exit GNURadio completely.

Step 5.
Open the source module 'square2_ff_impl.cc' file again and comment out only
the line where you instantiated the 'filter' object.  Leave the #include
for 'fir_filter_fff.h' alone.  Recompile and reinstall the Block back into
GNURadio following the Tutorial steps as before.  Don't modify anything
else other than the .cc file.

Step 6.
Open GNURadio again and try the square2_ff block again.  This time it works
exactly as it should with no errors.

For some reason, the C++ OOT Blocks will not run inside GNU Radio if I try
to use any of the C++ API Classes in the implementation code.  I've tried
everything I can think to move the declarations/headers around but nothing
works. Granted, I have not tried every single API Class but I've tried
enough to know it doesn't work.  I do not touch any of the swig or python
files or XML files.  The only file I touch is the implementation file and
this is enough to cause this error.

What am I doing wrong here?  This problem is all over the internet but none
of the solutions offered seem to work on any machine I try them on??

Any help on this would be greatly appreciated.

Thanks,
Mike H


--
From: *Tom Rondeau* 
Date: Thu, Mar 19, 2015 at 9:54 AM
To: Mike Heese 


Hi Mike,

I have the answer for you, but it's our policy not to answer these
questions off the mailing list. Could you please post this to the ML,
instead, and I can answer it there?

And I really appreciate the detail you went through to help me recreate and
understand the issue.

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

Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'block_name'

[Mike Heese]

Tom,

I hope I put this question into the correct location on the Mailing List.

Thanks again for your rapid response!!

Mike H.


On Thu, Mar 19, 2015 at 7:24 PM, Mike Heese  wrote:

> Tom,
>
> I sincerely apologize if I have posted this email to the wrong location
> but this is where the web page sent me.
>
> I have forwarded my original email below and hope it shows up as you
> expected.
>
> Any info you can provide on this problem would be greatly appreciated.
>
> Thanks!
> Mike Heese
>
>
>
>
>
> Forwarded conversation
> Subject: Re: [Discuss-gnuradio] AttributeError: 'module' object has no
> attribute 'block_name'
> 
>
> From: *Mike Heese* 
> Date: Wed, Mar 18, 2015 at 10:07 PM
> To: t...@trondeau.com
>
>
> Sir,
>
> I am having the exact same issues as those discussed in this thread and
> have not found any solutions that work.  I apologize for the strange-ness
> of the email but we've been struggling with this problem for several days.
>
> First, I have GNU Radio 3.7.5.1 installed on three different Laptops each
> running 64-bit Ubuntu.  GNURadio was installed using the 'apt-get' install
> call for gnuradio with no other modifications.  The steps below will
> produce this exact problem on every machine we have tried it on.
>
> Step 1.
> Pick any GNU Radio Tutorial such as the 'square2_ff' Tutorial.  Follow all
> the steps exactly as indicated to create the basic block.  Compile and
> install the block into GNURadio following the steps in the Tutorial.  Run
> the Block in GNURadio.  The Block should work in GNURadio exactly as
> indicated in the Tutorial.  Great Tutorial by the way!
>
> Step 2.
> Now, completely exit GNURadio.  Open the 'square2_ff_impl.cc' file (or
> whatever your implementation file is) and add (any) one of the C++ API
> Class Headers such as:
> #include <*gnuradio/filter/fir_filter_fff.h*
> >
>
> Next, in the constructor for square2_ff_impl add a single line to
> instantiate a filter object such as:
> gr::filter::fir_filter_fff::sptr
> filter(gr::filter::fir_filter_fff::make(1,m_taps));
>
> Make sure the 'm_taps' vector does in fact hold values but don't do
> anything else here.  Just declare a variable of the C++ API Class you
> picked. Do not modify any other files than the .cc file.
>
> Step 3.
> Following this, compile the Block code and install the Block into GNURadio
> again following the exact same steps from the Tutorial as before.  The Test
> Steps on my machine do not indicate any errors here, which is adding to my
> confusions.
>
> Step 4.
> Open GNURadio and try running the 'square2_ff' (or whatever yours is
> called) Block again.
> Now, with every machine I've tried this on, you will get the error:
> AttributeError:'module' object has no attribute 'square2_ff'
>
> Following this, exit GNURadio completely.
>
> Step 5.
> Open the source module 'square2_ff_impl.cc' file again and comment out
> only the line where you instantiated the 'filter' object.  Leave the
> #include for 'fir_filter_fff.h' alone.  Recompile and reinstall the Block
> back into GNURadio following the Tutorial steps as before.  Don't modify
> anything else other than the .cc file.
>
> Step 6.
> Open GNURadio again and try the square2_ff block again.  This time it
> works exactly as it should with no errors.
>
> For some reason, the C++ OOT Blocks will not run inside GNU Radio if I try
> to use any of the C++ API Classes in the implementation code.  I've tried
> everything I can think to move the declarations/headers around but nothing
> works. Granted, I have not tried every single API Class but I've tried
> enough to know it doesn't work.  I do not touch any of the swig or python
> files or XML files.  The only file I touch is the implementation file and
> this is enough to cause this error.
>
> What am I doing wrong here?  This problem is all over the internet but
> none of the solutions offered seem to work on any machine I try them on??
>
> Any help on this would be greatly appreciated.
>
> Thanks,
> Mike H
>
>
> --
> From: *Tom Rondeau* 
> Date: Thu, Mar 19, 2015 at 9:54 AM
> To: Mike Heese 
>
>
> Hi Mike,
>
> I have the answer for you, but it's our policy not to answer these
> questions off the mailing list. Could you please post this to the ML,
> instead, and I can answer it there?
>
> And I really appreciate the detail you went through to help me recreate
> and understand the issue.
>
> Tom
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio