Re: [Discuss-gnuradio] GNU Radio OOT Modules with Same Name - What To Do?

[Martin Braun]

The way OOTs are set up, having two OOTs with the same name will only
work with hacky solutions.

-- M

On 11/03/2017 01:50 PM, Kyeong Su Shin wrote:
> Hello Nicolas,
> 
> It is a GNU Radio module that I saw from GRCon17:
> https://github.com/samwhiting/gnuradio-doa/tree/master/gr-doa
> 
> Regards,
> Kyeong Su Shin
> 
> On Fri, Nov 3, 2017 at 1:21 PM, Nicolas Cuervo  > wrote:
> 
> Hi Kyeong,
> 
> I see only one gr-doa around [1]. Could you point out which other
> implementation is called gr-doa? I would agree that these conflicts
> would be better addressed properly instead of hacky approaches. 
> 
>  Regards,
> - Nicolas
> 
> [1]https://github.com/EttusResearch/gr-doa
> 
> 
> On Fri, Nov 3, 2017 at 8:30 PM, Kyeong Su Shin  > wrote:
> 
> Hello All:
> 
> I am trying to use some GNU Radio OOT modules, and found that
> there are GNU Radio OOT modules have name conflicts ('gr-doa'). 
> 
> In this case, what would be the proper way to resolve the
> conflict and install both modules? I can only think of hacky
> approaches.
> 
> Regards,
> Kyeong Su Shin
> 
> ___
> 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] Fwd: E310 file transition problem

[Martin Braun]

Can you please provide more details, and also, I recommend not posting
pictures on Google drive (many people simply won't click it then).

Cheers,
Martin

On 11/06/2017 10:45 AM, yuqing lin wrote:
> 
> Hello all:
>   We were trying to transmit data between USRP E310 and N200, I have
> attached our GRC (Please see the attachment below). We were able to get
> some data by using this graph on an E310. However, all we got were some
> random ASCII code, Any suggestion, improvement especially the values and
> parameters we were using?
> 
> Regards​​
> Danny
> 
> 
> 
> 
> ​
>  IMG_1376.JPG
> 
> ​​
>  IMG_1375.JPG
> 
> ​
> 
> 
> 
> ___
> 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] Setting output buffer to contain one packet

[Martin Braun]

Would set_output_multiple() do what you want?
https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4edcec53b3

However, you might want to consider passing your packets as messages,
not as streams.

-- M

On 11/09/2017 07:06 AM, Muhammad Zulqarnain wrote:
> Dear All!
> 
> I am new to GNU-Radio. I have previously used MATLAB for packet
> transmission and detection. Here is the problem, I am facing:
> 
> I have inserted zeros between the packets and transmitting the same
> packet over and over again. In the packet formation, I have appended two
> preambles side-by-side and using auto-correlation approach to detect
> coarse estimate of frequency and start of the packet. This was already
> done in MATLAB, but in GNURadio I am stuck in buffer things. I want the
> output buffer to contain exactly one packet so I can do processing on
> each packet (i.e. doing synchronization, demodulating etc.) 
> 
> My approach of doing auto-correlation is similar to Schmidl & Cox
> synchronization but all I find in GNURadio is for OFDM. Where this is a
> case of simple packetized transmission.
> 
> As I am inserting zeros between the packets so detection of individual
> packets at the receiver won't be a problem. 
> 
> I have already set the max output buffer to packet length
> i.e.  set_max_noutput_items (495);
> 
> Here is what I am doing in work function. but somehow I am not getting
> any output.
> 
> 
>       float curr_sample;
>       int i =0;
>       int y = 0;
>       // Do <+signal processing+>
>       while(i<=noutput_items){
>         curr_sample = abs(in[y]);
>           if (curr_sample >= 0.5 && packet_start == 0){ //0.5 is the
> threshold that signal is coming
>                 packet_start = 1;
>                 packet_length_count = 0;
>           }
>           if (packet_start == 1){
>               out[i] = in[y];
>               packet_length_count++;
>               i++;
>           }
>           if (curr_sample <= 0.2 && packet_start == 1){  //0.2 is the
> threshold that zero is coming
>               packet_start = 0;
>               packet_length_count = 0;
>             //  printf("curr_packet_length: %d \n",packet_length_count);
>               return i;
>           }
>         y++;
>       }
>       consume_each (y);
> 
> 
> 
> Awaiting reply!
> 
> Regards,
> Muhammad Zulqarnain
> 
> 
> ___
> 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] DMR Teir 3 just wondering.

[Martin Braun]

On 11/10/2017 01:09 PM, Adrian Hodgson wrote:
> So to the point of the post, would it be of benefit to any developers with 
> the 
> intention of improving blocks, functionality etc if I offered the odd file 
> sink 
> of the radio systems for testing of software.

Hi Adrian,

we love sharing our codes here, and I would encourage you to do the
same. Typically, people throw stuff up on github for sharing.
We also have a site which lists projects that others have shared at
http://cgran.org.

Cheers,
Martin

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

Re: [Discuss-gnuradio] Problem to handle message port in thread

[André Gomes]

Hi Michael,

Thanks for you support but I'm still getting the same error. :/

1) Yes, I'm already doing that.
2) I did that. See figure bellow. Unfortunately, the error persists as you
can see bellow.

*Figure 1: *start() method.

*​*
*Figure 2:* error

I have not found such examples you mentioned for part two. Only few poor/
not crystal clear references about how to do this. Would you have any other
suggestions?

Kind regards,​


*André Gomes*
Email: andre.go...@dcc.ufmg.br
Homepage: http://homepages.dcc.ufmg.br/~andre.gomes/
Mobile: +55 31 994859285 <+55%2031%2099485-9285>

On 12 November 2017 at 18:17, Michael Dickens 
wrote:

> Hi André - I think you're looking for 2 steps:
>
> 1) In the block constructor, declare the message port, e.g.:
> {{{
> message_port_register_out (pmt::mp ("frame request"));
> }}}
> You're probably already doing this.
>
> 2) Add the thread creation to the ::start method, so that the thread is
> not trying to do something before the output message port is actually
> active. Make sure to use gr::thread::thread and boost::bind such that the
> thread is running in the same class namespace as the rest of the block,
> to get access to its variables and methods.
>
> The GR codebase provides examples of how to do this 2-part thread creation
> approach. Hope this helps! - MLD
>
> On Sun, Nov 12, 2017, at 03:01 PM, André Gomes wrote:
>
> I'm getting an error while trying to use an output message port with a
> thread. The thread is responsible for executing function *check_buff()*.
> It seems to return the error bellow because the message port inside the
> function was not initialized yet. Firstly, the thread was started at the
> constructor. According to this link
> ,
> starting at the constructor is the root of the problem and one should start
> the thread in the start function of the block (bool start()). So I did but
> I'm still getting the same error. The port still does not exist when the
> thread starts.
> How do I guarantee the existence of the port before starting the thread?
>
> *Figure 1: *Error
> [image: Inline images 2]
>
> *Figure 2: *Function used by thread.
> [image: Inline images 1]
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Dan CaJacob]

Why not make the sub-second offset a uint64. That way you can express time
to the atto second (I think). The precision is overkill, but uint32, which
barely breaks a picosecond is underkill.

On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller 
wrote:

> Hi Eugene,
>
> yup, fully agree, the whole concept is slightly broken.
>
> So, first of all, I really think the key problem we're constantly working
> around is that tags have an integer offset – which leads to rounding
> errors, even in relatively benign scenarios.
>
> I'd propose we add a fractional part: that would only extend tag_t by
> another integer field, so existing blocks wouldn't break, and would allow
> non-1:1-sync blocks to properly rewrite tag positions.
>
> As you say, floating point is a bad idea when dealing with times (it
> always has been – see uhd::time_spec_t, where we're constantly paying off
> the technical debt of having floating point as "suggested" default
> representation of time, albeit underneath things should (and to some
> degree, are) counted in ticks). Thus, I'd imagine a tag_t like
>
> struct tag_t {
> uint64_t offset; //integer offset, as had
> uint32_t fractional_offset; //interpret as fractional part, i.e. ·2^{-32}
> pmt::pmt_t key;
> pmt::pmt_t tag;
> pmt::pmt_t srcid; // might as well drop this; maybe someone is using 
> this, but I haven't met them
> std::vector marked_deleted;
> }
>
> Would the fractional offset solve the issues you're seeing, assuming that
> we add proper handling to all the existing resamplers?
> Best regards,
> Marcus
>
>
> On 09.11.2017 20:52, Eugene Grayver wrote:
>
> There is a major problem with the way tags are propagated in blocks with
> non-integer relative rate. If the ratio is not a power of two, the
> numerical accuracy of the floating point will cause the output tags to
> diverge from the input tags.  Consider the fractional resampler. It
> accumulates the timing offset in the range of 0 to 1. However tag
> propagation multiplies the ratio by the sample number. As the sample number
> grows the LSB accuracy of the ratio gets scaled by the ever larger value.
> For a ratio of 1.001 we saw divergence of 1000s of samples over a few
> minutes at 10msps. I rewrote tag propagation for the resampler but did not
> rework the generic logic. I think the key point is to use the delta between
> read and written items to take out the large integer difference and then
> apply the scaling to a local delta within the current window.
>
>
>
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274 <(310)%20336-1274>
> 
>
>
>
>
> ___
> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Marcus Müller]

Hi Eugene,

yup, fully agree, the whole concept is slightly broken.

So, first of all, I really think the key problem we're constantly
working around is that tags have an integer offset – which leads to
rounding errors, even in relatively benign scenarios.

I'd propose we add a fractional part: that would only extend tag_t by
another integer field, so existing blocks wouldn't break, and would
allow non-1:1-sync blocks to properly rewrite tag positions.

As you say, floating point is a bad idea when dealing with times (it
always has been – see uhd::time_spec_t, where we're constantly paying
off the technical debt of having floating point as "suggested" default
representation of time, albeit underneath things should (and to some
degree, are) counted in ticks). Thus, I'd imagine a tag_t like

struct tag_t {
uint64_t offset; //integer offset, as had
uint32_t fractional_offset; //interpret as fractional part, i.e. ·2^{-32}
pmt::pmt_t key;
pmt::pmt_t tag;
pmt::pmt_t srcid; // might as well drop this; maybe someone is using this, 
but I haven't met them
std::vector marked_deleted; 
}

Would the fractional offset solve the issues you're seeing, assuming
that we add proper handling to all the existing resamplers?
Best regards,
Marcus

On 09.11.2017 20:52, Eugene Grayver wrote:
>
> There is a major problem with the way tags are propagated in blocks
> with non-integer relative rate. If the ratio is not a power of two,
> the numerical accuracy of the floating point will cause the output
> tags to diverge from the input tags.  Consider the fractional
> resampler. It accumulates the timing offset in the range of 0 to 1.
> However tag propagation multiplies the ratio by the sample number. As
> the sample number grows the LSB accuracy of the ratio gets scaled by
> the ever larger value. For a ratio of 1.001 we saw divergence of 1000s
> of samples over a few minutes at 10msps. I rewrote tag propagation for
> the resampler but did not rework the generic logic. I think the key
> point is to use the delta between read and written items to take out
> the large integer difference and then apply the scaling to a local
> delta within the current window.
>
>  
>
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>
>  
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] Problem to handle message port in thread

[Michael Dickens]

Hi André - I think you're looking for 2 steps:

1) In the block constructor, declare the message port, e.g.:
{{{
message_port_register_out (pmt::mp ("frame request"));
}}}
You're probably already doing this.

2) Add the thread creation to the ::start method, so that the thread is
   not trying to do something before the output message port is actually
   active. Make sure to use gr::thread::thread and boost::bind such that
   the thread is running in the same class namespace as the rest of the
   block, to get access to its variables and methods.
The GR codebase provides  examples of how to do this 2-part thread
creation approach. Hope this helps! - MLD
On Sun, Nov 12, 2017, at 03:01 PM, André Gomes wrote:
> I'm getting an error while trying to use an output message port with a
> thread. The thread is responsible for executing function
> *check_buff()*. It seems to return the error bellow because the
> message port inside the function was not initialized yet. Firstly, the
> thread was started at the constructor. According to this link[1],
> starting at the constructor is the root of the problem and one should
> start the thread in the start function of the block (bool start()). So
> I did but I'm still getting the same error. The port still does not
> exist when the thread starts.> How do I guarantee the existence of the port 
> before starting
> the thread?> 
> *Figure 1: *Error
> Inline images 2
> 
> *Figure 2: *Function used by thread.
> Inline images 1


Links:

  1. https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00388.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem to handle message port in thread

[André Gomes]

I'm getting an error while trying to use an output message port with a
thread. The thread is responsible for executing function *check_buff()*. It
seems to return the error bellow because the message port inside the
function was not initialized yet. Firstly, the thread was started at the
constructor. According to this link
,
starting at the constructor is the root of the problem and one should start
the thread in the start function of the block (bool start()). So I did but
I'm still getting the same error. The port still does not exist when the
thread starts.

How do I guarantee the existence of the port before starting the thread?

*Figure 1: *Error
[image: Inline images 2]

*Figure 2: *Function used by thread.
[image: Inline images 1]

Regards,

*André Gomes*
Email: andre.go...@dcc.ufmg.br
Homepage: http://homepages.dcc.ufmg.br/~andre.gomes/
Mobile: +55 31 994859285 <+55%2031%2099485-9285>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio