Thanks, got it!
-George
On Dec 19, 2013, at 9:21 AM, Tom Rondeau wrote:
> On Wed, Dec 18, 2013 at 7:47 PM, George wrote:
>> Tom,
>>
>> Is there going to be a fix soon or should I go with the 3.6.5 version of
>> gnuradio?
>>
>> Thanks,
>> -George
>
> George,
>
> The patch was pushed last
On Wed, Dec 18, 2013 at 7:47 PM, George wrote:
> Tom,
>
> Is there going to be a fix soon or should I go with the 3.6.5 version of
> gnuradio?
>
> Thanks,
> -George
George,
The patch was pushed last night. I will make it into the next bug
release, which will probably be in a month, plus or minu
Tom,
Is there going to be a fix soon or should I go with the 3.6.5 version of
gnuradio?
Thanks,
-George
On Dec 18, 2013, at 7:01 PM, George wrote:
> Hi Tom,
>
> You are right increasing the number of taps by 100 is not the case, after I
> debugged the results a bit more.
> The problem see
Hi Tom,
You are right increasing the number of taps by 100 is not the case, after I
debugged the results a bit more.
The problem seems to be in the number of samples consumed as you mentioned
above.
The full definition for the filter I am using is
firdes.root_raised_cosine(nfilts, 1.0, 1.0/nf
On Tue, Dec 17, 2013 at 9:06 PM, George wrote:
> Hello all,
>
> Considering a simple gnuradio flowgraph as the following
>
> Random source -> chunks2symbols -> complex2float -> float2complex ->
> pfb_arb_resampler-> USRP sink
>
> which used to work without any problem in the older gnuradio distri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi George,
I can't really see what should have changed in the c2f / f2c behaviour.
My wild guess is: old (like, quite old) versions of GNU Radio UHD used
to have a 2^16 range, while modern USRP interfaces want samples with
im and re parts in [-1;1].
Hello all,
Considering a simple gnuradio flowgraph as the following
Random source -> chunks2symbols -> complex2float -> float2complex ->
pfb_arb_resampler-> USRP sink
which used to work without any problem in the older gnuradio distributions, in
the newer 3.7.2.1 seems that the conversion abo
