Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

[Kartik Patel]

Hello all,
Gentle reminder regarding previous email.
Also, I have implemented a Plotly based frontend and Bokeh server as backend.
Please see [1].
For demo: Go to [2] for Bokeh based output and [3] for Plotly based output. In
both cases, backend is handled by Bokeh.
Procedure to setup on your system: 1. Turn on Bokeh server
 2. Run the top_block.py.
 3. You can review Bokeh based output at localhost:5006
 4. Also, opening plotly.html will display the plot using plotly.js frontend.
You may have to change the socket URL in plotly.html. It can be
automatically configured but I wanted to have a minimalistic prototype.

Now, I think this example solves the query of independent frontend and backend.
As shown in the example, using the socket provided by Bokeh server, one can use
any frontend library for plotting.
Also, any change in connected client will be pushed by Bokeh server. So, the
person changing the frontend library (in future) will have to handle such
changes using Javascript.
So, I think, now we can easily use Bokeh backend for the task. Instead of
writing server application on our own, Bokeh will be more structured and
efficient. What is your suggestion on this?
Regards,Kartik Patel
[1]: https://github.com/kartikp1995/gr-htmlgui/[2]: 
http://terminal.kartikpatel.in/?bokeh-session-id=h4NyPINXVEniemWudNItOhpEwM1U9NvoC3WaHu1Dmfyr
[3]: http://terminal.kartikpatel.in/plotly/  





On Wed, Mar 22, 2017 3:02 AM, Kartik Patel kartikpatel1...@gmail.com  wrote:

Hello all,
Thank you very much for the discussions and feedbacks. I will try to answer all
of them one-by-one.
Mail from Marcus: * said server has a REST API, i.e. ispolled from the client 
only? Or can there
   be pushing data from server -> client? What is the model you'd prefer? Your
   proposal says "stream to the clients", but I can't find that in Bokeh (but
   then again: no experience on interactive Web dev on my side at all, so this
   might be really easy for you, if possible).

Although server has a REST API, the bokeh use sockets to transfer the data.
Websockets are like pipelines of data which can be used by both server and
client. This is not based on typical request-response model of the web. "Stream
to the client" means server will sent data to the client without client asking
it. The data transfer can be continuous until socket is not broken (from either
side). For an example: Video streaming asks for the video once, and then a
simple socket will stream the data in frames (without client asking for more
data at every frame). * I've no idea how to talk GR data -> bokeh-server. Maybe
   you could elaborate on how you do that?

Consider the #L62 in time_sink_f.py in my prototype [1]. The function stream of
the DataSource object will stream data to respective socket. This data source is
initialised at #L50 in same file and connected to the plot in the line #L51. So,
every time after processing the data through GR, it can be streamed through the
function to the server. This streaming can be handled by Bokeh library. * the
   JSON is relatively verbose, and contains basically all imaginable settings
   for a plot. However, I presume a data update from the bokeh-server would only
   consist of the model data, which, for a 5-point line graph would consist of
   (this is pretty-printed, Bokeh omits all the whitespace/line breaks):

Correct. * Hence, if performance of the python server is doubted, or integration
   into GR is complicated, you could also just write a C++ block that takes
   numerical values from GNU Radio and serves them via Websocket (how does one
   do that?), and point BokehJS at that instead? (example from [0], found the
   embed_items declaration in [1])
   

Although we can do that, but I don't think it is necessary. We are not doing
anything in Python except the streaming. All processing is done by C++. But I
have never used Python where its speed is the constraint. So, may be you can
suggest me more on this. I don't think that the Socket will limit the dataflow.
Also, since for now we are limiting the use-case to the local network, the speed
of network will not be the problem. * However, when running and changing the
   data source, I see all the plot JSON being transferred, the ColumnDataSource
   object just being about half of the 12 kB response object (amongst dozens of
   requests made to react to this change of model, but that might be an effect
   of this being a feature-rich plot).
   

Although I did not understand the point you are making, but considering our
use-case, we don't need to change the data source. * Can you please explain the
   user work flow? I would have imagined that the users design their "plot
   layout" either
 * implicitly (by just using
   your sinks in their flow graph), so that gr-bokehgui builds a HTML page
   containing the plots they want on its own, orexplicitly by designing an HTML
   page with  placeholders on their own and tell gr-bokehgui "hey, use
   that; the plot  IDs 

Re: [Discuss-gnuradio] Transceiver gr-ieee802.11

[Cinaed Simson]

On 03/22/2017 10:27 AM, Cristian Rodríguez wrote:
> Hi everybody.
> 
> I'm trying to implement the Transceiver gr-ieee802.11 of Bastian.
> 
> I'm following the instructions in github, and this video in youtube.
> https://www.youtube.com/watch?v=tAVgsJLM-sc
> 
> In the begining of the simulation should be appear "Using volk machine"
> like in the video, because this is important for the simulation. But i
> don't get it, and of course the simulation doesn't work for me.
> 
> I've been finding out more about VOLK but it is not clear for me how to
> know if it is working and install.

Type

   volk_profile -h

> 
> Does someone help me, please?
> 
> Thanks in advance.
> 
> Greatings,
> 
> Cristian
> 
> 
> ___
> 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] installing a python package without elevated privileges

[Naceur]

You are right if they had access to it at first place. Anyhow I fixed it.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183p63258.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Implementing IEEE 802.11 a/g/p Transceiver module

[Cristian Rodríguez]

Hi.

I'm implementing the transceiver of Bastian following the instructions in
github.

When i use nic.sh (as it is indicated in the youtube video
https://www.youtube.com/watch?v=tAVgsJLM-sc) i should receive it.

[image: Imágenes integradas 1]
But instead, i'm receiving:

   Uether type: IP
   read(net): Conexi?n rehusada

And later from the mac:
[image: Imágenes integradas 2]
Why do you think i am doing bad?

Thanks in advance.

Best regards,

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

Re: [Discuss-gnuradio] FEC: Convolutional Encoder Gnuradio and Matlab: different results

[Dan CaJacob]

Hi Emanuel,

Try bit-reversing the polynomials.  By the way, even though the block
definitions can take any python representation of the numbers.  For
instance 91 decimal is 0x5B (hex) and 091 (octal) in python.  I often use
the leading zero octal notation for stuff like this since the weirdos who
came up with conv encoding like to use octal to specify their polynomials.

- Dan

On Wed, Mar 22, 2017 at 10:16 AM Usman Haider 
wrote:

> Hi Emanuel,
>
> Maybe you find following thread useful.
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00404.html
>
> --
> Usman
>
>
>
> On Wed, Mar 22, 2017 at 1:07 PM,  wrote:
>
> Hi together,
>
>
>
> I’m using the FEC Async Encoder with the CC Encoder Definition.
> Input/Output are unpacked and I use the terminated behavior. In Gnuradio
> the polynomials for the CC Encoder Definition are defined on a base of 10,
> and not as octals like in MATLAB, right?
>
>
>
> I tried the following: 1 bit with ‘1’ as input to the FEC Async Encoder
> and the same in MATLAB to check the response of the encoder. The results
> don’t match. No matter if I use different constraint lengths, rates or
> polynomials.
>
> e.g. in Matlab: K = 7, 1/R=2, Polynomials (octal) [171,133] and Gnuradio
> Polynomials (10-base) [121,91] give completely different outputs.
>
>
>
> No matter what I do, e.g., using octal representation in Gnuradio, or
> changing the polynomials’ positions in the specified vector, gives me a
> result which matches.
>
>
>
> Did anyone compare results before? Any clues?
>
> Regards,
>
> Emanuel
>
>
>
> ___
> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Transceiver gr-ieee802.11

[Cristian Rodríguez]

Thanks a lot. Yes i was worried about the message then your answer is ver
useful Ron and again thanks Marcus for your interest in help.



2017-03-22 12:45 GMT-05:00 Ron Economos :

> volk-config-info --machine
>
> BTW, the printout you see in the video has been removed in recent versions
> of GNU Radio.
>
> Ron
> On 03/22/2017 10:42 AM, Cristian Rodríguez wrote:
>
> Thanks for your answer Marcus.
>
> Is there a command so i can know if the gnuradio flow graph is executing
> VOLK?
>
> Regards,
>
> Cristian
>
> 2017-03-22 12:32 GMT-05:00 Marcus Müller :
>
>> Hi Cristian,
>>
>> VOLK is an integral component of GNU Radio. If your GNU Radio has no
>> VOLK, you wouldn't even have most of the GNU Radio blocks you use. So you
>> very, very likely have VOLK. Your problem lies somewhere else.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 03/22/2017 06:27 PM, Cristian Rodríguez wrote:
>>
>> Hi everybody.
>>
>> I'm trying to implement the Transceiver gr-ieee802.11 of Bastian.
>>
>> I'm following the instructions in github, and this video in youtube.
>> https://www.youtube.com/watch?v=tAVgsJLM-sc
>>
>> In the begining of the simulation should be appear "Using volk machine"
>> like in the video, because this is important for the simulation. But i
>> don't get it, and of course the simulation doesn't work for me.
>>
>> I've been finding out more about VOLK but it is not clear for me how to
>> know if it is working and install.
>>
>> Does someone help me, please?
>>
>> Thanks in advance.
>>
>> Greatings,
>>
>> Cristian
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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 
> listDiscuss-gnuradio@gnu.orghttps://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] Measure and record the phase at the receiver

[Marcus Müller]

Hi Fernando!


On 03/22/2017 06:51 PM, Trejo Treviño, Fernando Alberto wrote:
>
> Hi Marcus!
>
>
> I am implementing a transmitter and a receiver model using two USRP
> N210s. Both are using GFSK modulation, and the data is transmitted at
> 2.4 GHz.
>
Cool :)
>
> I would like to add a phase shift at the transmitter side via the use
> of a multiplier block with an exponential.
>
Ah, so a multiply_const with a constant of
$e^{j\frac{2\pi}{f_\text{sample}\varphi}$, yeah.
>
> Then, at the receiver I would like to receive this transmitted signal
> and check if the phase matches the one that was transmitted. This is
> why I need a measuring method.
>
>
Well, you can't see absolute phase without further ado – that would need
your TX and RX to be phase-synchronized (you don't know the electrical
length between your transmitter and receiver, it's absolutely random by
itself).

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

Re: [Discuss-gnuradio] Measure and record the phase at the receiver

[Trejo Treviño , Fernando Alberto]

Hi Marcus!


I am implementing a transmitter and a receiver model using two USRP N210s. Both 
are using GFSK modulation, and the data is transmitted at 2.4 GHz. I would like 
to add a phase shift at the transmitter side via the use of a multiplier block 
with an exponential. Then, at the receiver I would like to receive this 
transmitted signal and check if the phase matches the one that was transmitted. 
This is why I need a measuring method.


Regards,


Fernando

From: Discuss-gnuradio 
 on 
behalf of Marcus Müller 
Sent: Wednesday, March 22, 2017 6:30:44 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Measure and record the phase at the receiver


Hi Fernando,


you'll need to be a little more specific what you mean with "a received signal" 
and its phase – a PLL does keep track of the phase, but its job is, by 
definition, to "correct" the output so that it follows a specific phase 
behaviour, so a PLL is certainly not what you're looking for alone.


can you tell us more about your signal and what you want to do, in the bigger 
picture?

Best regards,

Marcus

On 03/22/2017 05:58 PM, Trejo Treviño, Fernando Alberto wrote:

I am currently experimenting with a USRP N210, and I would like to measure and 
record the phase of a received signal. I have read into the pre-installed PLL 
blocks, but these do not provide the same functionality. Ideally this would be 
done before the first iteration of the PLL, but I am also open to other 
solutions. Any suggestions?


Best,


Fernando



___
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] Transceiver gr-ieee802.11

[Ron Economos]

volk-config-info --machine

BTW, the printout you see in the video has been removed in recent 
versions of GNU Radio.


Ron

On 03/22/2017 10:42 AM, Cristian Rodríguez wrote:

Thanks for your answer Marcus.

Is there a command so i can know if the gnuradio flow graph is 
executing VOLK?


Regards,

Cristian

2017-03-22 12:32 GMT-05:00 Marcus Müller >:


Hi Cristian,

VOLK is an integral component of GNU Radio. If your GNU Radio has
no VOLK, you wouldn't even have most of the GNU Radio blocks you
use. So you very, very likely have VOLK. Your problem lies
somewhere else.

Best regards,

Marcus


On 03/22/2017 06:27 PM, Cristian Rodríguez wrote:

Hi everybody.

I'm trying to implement the Transceiver gr-ieee802.11 of Bastian.

I'm following the instructions in github, and this video in
youtube. https://www.youtube.com/watch?v=tAVgsJLM-sc


In the begining of the simulation should be appear "Using volk
machine" like in the video, because this is important for the
simulation. But i don't get it, and of course the simulation
doesn't work for me.

I've been finding out more about VOLK but it is not clear for me
how to know if it is working and install.

Does someone help me, please?

Thanks in advance.

Greatings,

Cristian


___
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] Transceiver gr-ieee802.11

[Cristian Rodríguez]

Thanks for your answer Marcus.

Is there a command so i can know if the gnuradio flow graph is executing
VOLK?

Regards,

Cristian

2017-03-22 12:32 GMT-05:00 Marcus Müller :

> Hi Cristian,
>
> VOLK is an integral component of GNU Radio. If your GNU Radio has no VOLK,
> you wouldn't even have most of the GNU Radio blocks you use. So you very,
> very likely have VOLK. Your problem lies somewhere else.
>
> Best regards,
>
> Marcus
>
> On 03/22/2017 06:27 PM, Cristian Rodríguez wrote:
>
> Hi everybody.
>
> I'm trying to implement the Transceiver gr-ieee802.11 of Bastian.
>
> I'm following the instructions in github, and this video in youtube.
> https://www.youtube.com/watch?v=tAVgsJLM-sc
>
> In the begining of the simulation should be appear "Using volk machine"
> like in the video, because this is important for the simulation. But i
> don't get it, and of course the simulation doesn't work for me.
>
> I've been finding out more about VOLK but it is not clear for me how to
> know if it is working and install.
>
> Does someone help me, please?
>
> Thanks in advance.
>
> Greatings,
>
> Cristian
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] Transceiver gr-ieee802.11

[Marcus Müller]

Hi Cristian,

VOLK is an integral component of GNU Radio. If your GNU Radio has no
VOLK, you wouldn't even have most of the GNU Radio blocks you use. So
you very, very likely have VOLK. Your problem lies somewhere else.

Best regards,

Marcus


On 03/22/2017 06:27 PM, Cristian Rodríguez wrote:
> Hi everybody.
>
> I'm trying to implement the Transceiver gr-ieee802.11 of Bastian.
>
> I'm following the instructions in github, and this video in youtube.
> https://www.youtube.com/watch?v=tAVgsJLM-sc
>
> In the begining of the simulation should be appear "Using volk
> machine" like in the video, because this is important for the
> simulation. But i don't get it, and of course the simulation doesn't
> work for me.
>
> I've been finding out more about VOLK but it is not clear for me how
> to know if it is working and install.
>
> Does someone help me, please?
>
> Thanks in advance.
>
> Greatings,
>
> Cristian
>
>
> ___
> 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] Measure and record the phase at the receiver

[Marcus Müller]

Hi Fernando,


you'll need to be a little more specific what you mean with "a received
signal" and its phase – a PLL does keep track of the phase, but its job
is, by definition, to "correct" the output so that it follows a specific
phase behaviour, so a PLL is certainly not what you're looking for alone.


can you tell us more about your signal and what you want to do, in the
bigger picture?


Best regards,

Marcus


On 03/22/2017 05:58 PM, Trejo Treviño, Fernando Alberto wrote:
>
> I am currently experimenting with a USRP N210, and I would like to
> measure and record the phase of a received signal. I have read into
> the pre-installed PLL blocks, but these do not provide the same
> functionality. Ideally this would be done before the first iteration
> of the PLL, but I am also open to other solutions. Any suggestions?
>
>
> Best,
>
>
> *Fernando*
>
>
> ___
> 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] Transceiver gr-ieee802.11

[Cristian Rodríguez]

Hi everybody.

I'm trying to implement the Transceiver gr-ieee802.11 of Bastian.

I'm following the instructions in github, and this video in youtube.
https://www.youtube.com/watch?v=tAVgsJLM-sc

In the begining of the simulation should be appear "Using volk machine"
like in the video, because this is important for the simulation. But i
don't get it, and of course the simulation doesn't work for me.

I've been finding out more about VOLK but it is not clear for me how to
know if it is working and install.

Does someone help me, please?

Thanks in advance.

Greatings,

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

[Discuss-gnuradio] Measure and record the phase at the receiver

[Trejo Treviño , Fernando Alberto]

I am currently experimenting with a USRP N210, and I would like to measure and 
record the phase of a received signal. I have read into the pre-installed PLL 
blocks, but these do not provide the same functionality. Ideally this would be 
done before the first iteration of the PLL, but I am also open to other 
solutions. Any suggestions?


Best,


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

Re: [Discuss-gnuradio] FEC: Convolutional Encoder Gnuradio and Matlab: different results

[Usman Haider]

Hi Emanuel,

Maybe you find following thread useful.

http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00404.html

--
Usman


On Wed, Mar 22, 2017 at 1:07 PM,  wrote:

> Hi together,
>
>
>
> I’m using the FEC Async Encoder with the CC Encoder Definition.
> Input/Output are unpacked and I use the terminated behavior. In Gnuradio
> the polynomials for the CC Encoder Definition are defined on a base of 10,
> and not as octals like in MATLAB, right?
>
>
>
> I tried the following: 1 bit with ‘1’ as input to the FEC Async Encoder
> and the same in MATLAB to check the response of the encoder. The results
> don’t match. No matter if I use different constraint lengths, rates or
> polynomials.
>
> e.g. in Matlab: K = 7, 1/R=2, Polynomials (octal) [171,133] and Gnuradio
> Polynomials (10-base) [121,91] give completely different outputs.
>
>
>
> No matter what I do, e.g., using octal representation in Gnuradio, or
> changing the polynomials’ positions in the specified vector, gives me a
> result which matches.
>
>
>
> Did anyone compare results before? Any clues?
>
> Regards,
>
> Emanuel
>
>
>
> ___
> 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] Using multi_usrp in python code

[Marcus Müller]

Hi Nicolas,

> I tried to use the set_auto_dc_offset method of the usrp_source class
> (GRC automatically creates a usrp_source instance) to disable auto
> offset correction and the set_dc_offset to set it to 0, but
> experimentally, it seems that it does not do anything.
We know of this:

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

Basically, to make this work, you'd need to remove the

|#if $dc_offs_enb$(n)() |

line from the USRP_Source's XML file. And to do that you just need to
remove the lines that generate that line and the #endif line from the
python script mentioned in above Bug report.
If you could do that, test it, and do a pull request, I think we all
would be thankful!

Best regards,
Marcus

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

[Discuss-gnuradio] Using multi_usrp in python code

[Nicolas GALLAND]

Hello,

I am using gnuradio with a X310 usrp and a LFRX daughterboard to acquire 
a 10 kHz signal. My problem is due to the DC offset correction.


The flowgraph is generated using GRC and I am working on the python file.

I tried to use the set_auto_dc_offset method of the usrp_source class 
(GRC automatically creates a usrp_source instance) to disable auto 
offset correction and the set_dc_offset to set it to 0, but 
experimentally, it seems that it does not do anything.


I read somewhere that the multi_usrp class has a method called 
set_rx_dc_offset and I would like to try it, but I can't find any 
example about how to crate a multi_usrp object in python to use this method.


Is there a way to do that, or another way to disable dc offset correction ?
Or should I code a new block in C++ to have a multi_usrp object ?

Thanks in advance,

Best regards,

Nicolas


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

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Marcus Müller]

A common way to figure out dependencies is to look into what other
builders used – in your case, you can check very easily:

apt-get build-dep gnuradio

Will list (and if you want to, install) all packages that the package
maintainer deemed necessary to build GNU Radio. Note that this will
include *all* dependencies, including doxygen for documentation, latex
for formulas in documentation, all the graphical libraries and so on.
But: It's easier to look at each package in a list and quickly decide
whether you'll need it or not than to research all packages you need to
install yourself.


Best regards,
Marcus

On 22.03.2017 05:34, Usman Haider wrote:
>
>
> On Wed, Mar 22, 2017 at 2:52 AM, Dennis Glatting  > wrote:
>
> On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote:
> > Hi,
> >
> > I am currently building GNU Radio 3.7.10.1 on Beaglebone black
> > running Debian 8.6.  I have disable some components for testing and
> > to speed up the process. After installing the dependencies when
> I run
> > cmake I am getting following messages. Are these messages okay? Do I
> > have to pass any flags to cmake like -march etc or not?
> >
> > 
> > -- Performing Test have_msse2
> > -- Performing Test have_msse2 - Failed
> > -- Performing Test have_msse3
> > -- Performing Test have_msse3 - Failed
> > -- Performing Test have_mssse3
> > -- Performing Test have_mssse3 - Failed
> > -- Performing Test have_msse4a
> > -- Performing Test have_msse4a - Failed
> > -- Performing Test have_msse4_1
> > -- Performing Test have_msse4_1 - Failed
> > -- Performing Test have_mavx
> > -- Performing Test have_mavx - Failed
> > -- Performing Test have_mavx2
> > -- Performing Test have_mavx2 - Failed
> > -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> > -- Architecture is not x86 or x86_64, Overruled arch mmx
> > -- Architecture is not x86 or x86_64, Overruled arch sse
> > -- Architecture is not x86 or x86_64, Overruled arch sse2
> > -- Architecture is not x86 or x86_64, Overruled arch sse3
> > -- Architecture is not x86 or x86_64, Overruled arch ssse3
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> > -- Architecture is not x86 or x86_64, Overruled arch avx
> > -- Available architectures: generic;hardfp;neon;orc;norc
> > -- Available machines: generic_orc;neon_hardfp_orc
> > -- BUILD TYPE = RELEASE
> > -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
> -Wsign-
> > compare -Wall -Wno-uninitialized -Wall
> > -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> > -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall 
> > -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -
> > std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> > -Wall -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> > -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> > Copyright (C) 2014 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There
> > is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > --  Adding ASM files
> > -- -- Detected neon architecture; enabling ASM
> > -- Adding source file:
> >
> /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_ho
> > rizontal_16i.s
> >
> > ...
> > ...
> > Complete output
> >
> > http://pastebin.com/t3KSu0f5
> >
> >
> >
>
> You can build from source on the Beagle. I have done it. 
>
>
> Great!
>  
>
> However, the
> Beagle has only a single core processor, you will have to mount swap
> space, the 4G of memory isn't roomy - at all, and you will have to
> install a bunch of additional packages. 
>
>
> Can you point me to those packages so that I do not miss something? I
> installed pre-reqs for GNU Radio and cmake seems to run fine with some
> warnings/messages as shown in my first email.
>  
>
> I don't recommend native builds but it can be done. Cross develop if
> you can. I seem to recall it took a few /days/ to build, multiply if
> there is a failure. You should also mount an external USB disk for
> swap, /tmp, etc. 
>  
>
> The compiler on the Beagle is old. I installed a more modern version.
>
> I tried to cross develop but was not able to do so. I am still working
> on that approach. If you have done it or have any pointers please do
> share.  What compiler did you use? Did you do a full install of GNU
> Radio on BBB? 
>
> The Beagle isn't suited for GNURadio unless you have a low data rate
> and low memory requirements, 

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

[Cinaed Simson]

On 03/21/2017 09:34 PM, Usman Haider wrote:
> 
> 
> On Wed, Mar 22, 2017 at 2:52 AM, Dennis Glatting  > wrote:
> 
> On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote:
> > Hi,
> >
> > I am currently building GNU Radio 3.7.10.1 on Beaglebone black
> > running Debian 8.6.  I have disable some components for testing and
> > to speed up the process. After installing the dependencies when I run
> > cmake I am getting following messages. Are these messages okay? Do I
> > have to pass any flags to cmake like -march etc or not?
> >
> > 
> > -- Performing Test have_msse2
> > -- Performing Test have_msse2 - Failed
> > -- Performing Test have_msse3
> > -- Performing Test have_msse3 - Failed
> > -- Performing Test have_mssse3
> > -- Performing Test have_mssse3 - Failed
> > -- Performing Test have_msse4a
> > -- Performing Test have_msse4a - Failed
> > -- Performing Test have_msse4_1
> > -- Performing Test have_msse4_1 - Failed
> > -- Performing Test have_mavx
> > -- Performing Test have_mavx - Failed
> > -- Performing Test have_mavx2
> > -- Performing Test have_mavx2 - Failed
> > -- Architecture is not x86 or x86_64, Overruled arch 3dnow
> > -- Architecture is not x86 or x86_64, Overruled arch mmx
> > -- Architecture is not x86 or x86_64, Overruled arch sse
> > -- Architecture is not x86 or x86_64, Overruled arch sse2
> > -- Architecture is not x86 or x86_64, Overruled arch sse3
> > -- Architecture is not x86 or x86_64, Overruled arch ssse3
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_a
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_1
> > -- Architecture is not x86 or x86_64, Overruled arch sse4_2
> > -- Architecture is not x86 or x86_64, Overruled arch avx
> > -- Available architectures: generic;hardfp;neon;orc;norc
> > -- Available machines: generic_orc;neon_hardfp_orc
> > -- BUILD TYPE = RELEASE
> > -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden -Wsign-
> > compare -Wall -Wno-uninitialized -Wall
> > -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> > -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall 
> > -- BUILD INFO ::: neon_hardfp_orc ::: GNU ::: -O3 -DNDEBUG  -
> > std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
> > -Wall -mfpu=neon -funsafe-math-optimizations -mfloat-abi=hard
> > -- Compiler Version: cc (Debian 4.9.2-10) 4.9.2
> > Copyright (C) 2014 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There
> > is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > --  Adding ASM files
> > -- -- Detected neon architecture; enabling ASM
> > -- Adding source file:
> > /home/debian/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_ho
> > rizontal_16i.s
> >
> > ...
> > ...
> > Complete output
> >
> > http://pastebin.com/t3KSu0f5
> >
> >
> >
> 
> You can build from source on the Beagle. I have done it. 
> 
> 
> Great!
>  
> 
> However, the
> Beagle has only a single core processor, you will have to mount swap
> space, the 4G of memory isn't roomy - at all, and you will have to
> install a bunch of additional packages. 
> 
> 
> Can you point me to those packages so that I do not miss something? I
> installed pre-reqs for GNU Radio and cmake seems to run fine with some
> warnings/messages as shown in my first email.
>  
> 
> I don't recommend native builds but it can be done. Cross develop if
> you can. I seem to recall it took a few /days/ to build, multiply if
> there is a failure. You should also mount an external USB disk for
> swap, /tmp, etc. 
>  
> 
> The compiler on the Beagle is old. I installed a more modern version.
> 
> I tried to cross develop but was not able to do so. I am still working
> on that approach. If you have done it or have any pointers please do
> share.  What compiler did you use? Did you do a full install of GNU
> Radio on BBB? 
> 
> The Beagle isn't suited for GNURadio unless you have a low data rate
> and low memory requirements, but it can work.
> 
> I'll also use low data-rates :)
>  
> 
> Regarding VOLK, you may have to tune the build. You will have to look
> up the processor specifics and tune the build appropriately.
> 
> 
> I'll look how can I do it. Thanks for your time.
> 
> --
> Usman
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

I have scripts which will build install the system software needed to
build gnuradio - and scripts to build gnuradio - on the BBB for both
wheezy and jessie.

I 

[Discuss-gnuradio] FEC: Convolutional Encoder Gnuradio and Matlab: different results

[Emanuel.Staudinger]

Hi together,

I'm using the FEC Async Encoder with the CC Encoder Definition. Input/Output 
are unpacked and I use the terminated behavior. In Gnuradio the polynomials for 
the CC Encoder Definition are defined on a base of 10, and not as octals like 
in MATLAB, right?

I tried the following: 1 bit with '1' as input to the FEC Async Encoder and the 
same in MATLAB to check the response of the encoder. The results don't match. 
No matter if I use different constraint lengths, rates or polynomials.
e.g. in Matlab: K = 7, 1/R=2, Polynomials (octal) [171,133] and Gnuradio 
Polynomials (10-base) [121,91] give completely different outputs.

No matter what I do, e.g., using octal representation in Gnuradio, or changing 
the polynomials' positions in the specified vector, gives me a result which 
matches.

Did anyone compare results before? Any clues?
Regards,
Emanuel

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