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 filteri
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 virtu
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:
> Hi all,
>
> I'm using
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 u
El 21/01/18 a las 11:39, Daniel Estévez escribió:
>
> out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[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
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(&in[count+d_out_idx]);
>>
>
> Hi all,
>
> I've been looking at this again and the problem is that in this line,
>
> count = -134217704
>
>
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,
gr_v
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 try adding the "+1" to
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 wrote:
>
>> The forecast function is supposed
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 tuning
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 this application, I am tryi
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 (
https://github.com/gnuradio/gnuradio/b
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
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 everyth
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
> handled inside "general_work(
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 (or, gr-ieee-802.11 in this
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 must be "virtual"
> for the
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
> round-robin on the inpu
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, Jeff Long wrote:
>
>> I
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 "{}"
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
> "decision_maker" method is. And y
21 matches
Mail list logo