Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

On 21 January 2018 at 20:15, Michael Dickens wrote: > So we mean adding "virtual" in the GR header here < https://github.com/ > sumitstop/MTSDR-gnuradio/commit/778b6d095517b87c338169e3efc84b > ac9fcf37ea#diff-96726df785ba7d3bf9493c8830d5a1d0R79 >, just like the >

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

So we mean adding "virtual" in the GR header here <  https://github.com/sumitstop/MTSDR-gnuradio/commit/778b6d095517b87c338169e3efc84bac9fcf37ea#diff-96726df785ba7d3bf9493c8830d5a1d0R79  >, just like the "decision_maker" method is. And you'll probably want to declare its function there too as

Re: [Discuss-gnuradio] return value of gr::block::general_work

Well, that settles the question :) On Sun, Jan 21, 2018 at 1:55 PM, Jeff Long wrote: > I sent a PR with a doc fix for this. Interleaver uses this (since it does > round-robin on the input). Also ofdm_chanest and header_payload_demux. > > On Sun, Jan 21, 2018 at 1:54 PM,

Re: [Discuss-gnuradio] return value of gr::block::general_work

I sent a PR with a doc fix for this. Interleaver uses this (since it does round-robin on the input). Also ofdm_chanest and header_payload_demux. On Sun, Jan 21, 2018 at 1:54 PM, Jeff Long wrote: > I sent a PR with a doc fix for this. Interleaver uses this (since it does >

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

Believe me I tried that declaring decision_maker_soft as a virtual function(only virtual not pure virtual), but that din't work. I am trying that now again. On 21 January 2018 at 19:23, Michael Dickens wrote: > Yes that's correct: the base class's method declaration

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

On 20 January 2018 at 18:06, Michael Dickens wrote: > Hi Sumit - OK good I'll take a look when I get a chance. In the meantime, > 3 thoughts come to mind: > > 1) If done correctly, you don't need to modify GR at all. Your new > constellation class is purely in your OOT

Re: [Discuss-gnuradio] return value of gr::block::general_work

Thanks! On Sun, Jan 21, 2018 at 1:34 PM, Michael Dickens wrote: > In theory, yes, you can call "produce()" for each output stream with a > different number of items (or, the same), then return > gr::block::WORK_CALLED_PRODUCE to tell the scheduler that produce was >

Re: [Discuss-gnuradio] return value of gr::block::general_work

In theory, yes, you can call "produce()" for each output stream with a different number of items (or, the same), then return gr::block::WORK_CALLED_PRODUCE to tell the scheduler that produce was handled inside "general_work()". I know of no blocks that actually do this, but I don't know

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

Yes that's correct: the base class's method declaration must be "virtual" for the inheriting class' overloaded method to be usable correctly within SWIG. Good catch! - MLD On Sun, Jan 21, 2018, at 5:42 AM, Bastian Bloessl wrote: > On 01/19/2018 10:30 PM, sumit kumar wrote: > > Hi Michael, Yes I

Re: [Discuss-gnuradio] return value of gr::block::general_work

I found in the docs that general_work only supports outputting the same number of samples to each output port ( https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L47-L49) but the produce method seems to tell otherwise (

Re: [Discuss-gnuradio] sending sine wave, but created another unwanted frequency component

Try reducing the RX filter bandwidth, the gain of the receiver and/or transmitter, or moving the TX and RX apart, and see what happens. This is aliasing, and probably has nothing to do with software. On Sun, Jan 21, 2018 at 12:56 PM, Yang Liu wrote: > Dear all, > > In

[Discuss-gnuradio] sending sine wave, but created another unwanted frequency component

Dear all, In this application, I am trying to send a sine wave at a specific frequency to usrp x310: sine wave generator ---> usrpx310 For the sine wave generator, I use blocks.sig_source_c from gnuradio. The parameters at the transmitter are in the following: center frequency: 1e9 (usrp

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Added issue https://github.com/gnuradio/gnuradio/issues/1554 On Sun, Jan 21, 2018 at 7:38 AM, Jeff Long wrote: > Ah, good. I didn't think it needed another +1 but couldn't think of any > other overflow. > > On Sun, Jan 21, 2018 at 7:33 AM, Jeff Long

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Ah, good. I didn't think it needed another +1 but couldn't think of any other overflow. On Sun, Jan 21, 2018 at 7:33 AM, Jeff Long wrote: > The forecast function is supposed to guarantee that there is enough input, > but it might be rounding down in some cases. Could you

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

The forecast function is supposed to guarantee that there is enough input, but it might be rounding down in some cases. Could you try adding the "+1" to the last line and see if that changes anything? void pfb_clock_sync_ccf_impl::forecast(int noutput_items,

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

El 21/01/18 a las 12:35, Daniel Estévez escribió: > El 21/01/18 a las 11:39, Daniel Estévez escribió: >> >> out[i+d_out_idx] = d_filters[d_filtnum]->filter([count+d_out_idx]); >> > > Hi all, > > I've been looking at this again and the problem is that in this line, > > count = -134217704 > >

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

El 21/01/18 a las 11:39, Daniel Estévez escribió: > > out[i+d_out_idx] = d_filters[d_filtnum]->filter([count+d_out_idx]); > Hi all, I've been looking at this again and the problem is that in this line, count = -134217704 for some weird reason. Obviously, this causes the SIGSEGV. I'll try to

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

El 21/01/18 a las 12:01, Sakthivel Velumani escribió: > Hi Daniel, > > The pfb block sets history() to ensure sufficient amount of input items > are available. Can you provide information on arguments passed to the > pfb block like sps, taps and no. of filters? Hi Sakthivel, The parameters I'm

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Hi Daniel, The pfb block sets history() to ensure sufficient amount of input items are available. Can you provide information on arguments passed to the pfb block like sps, taps and no. of filters? Best, Sakthivel On Sun, Jan 21, 2018 at 11:39 AM, Daniel Estévez wrote: >

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

Hi, On 01/19/2018 10:30 PM, sumit kumar wrote: Hi Michael, Yes I just made one and pushed everything. https://github.com/sumitstop/MTSDR-gnuradio/commits/master https://github.com/sumitstop/MTSDR-gr-ieee-80211/commits/master I didn't test it, but I think you should declare the function

[Discuss-gnuradio] Segfault in Polyphase clock sync block

Hi all, I'm using a Polyphase clock sync block in one of my flowgraphs (https://github.com/daniestevez/gr-satellites/blob/master/apps/picsat.grc) and I'm getting a segmentation fault when running the flowgraph. Using GDB, the problem seems to be in the Polyphase clock implementation, when