On 11/04/2011 01:55 PM, Jordan Otomo wrote:
> I think the problematic block might be the FLL used in the PSK
> demodulator. I haven't looked into the issue very deeply, but I have
> confirmed that given the same input parameters, the FLL from 3.4.2
> works fine, while the 3.5.0 version causes a
On 11/04/2011 01:55 PM, Jordan Otomo wrote:
> I think the problematic block might be the FLL used in the PSK
> demodulator. I haven't looked into the issue very deeply, but I have
> confirmed that given the same input parameters, the FLL from 3.4.2
> works fine, while the 3.5.0 version causes a
I think the problematic block might be the FLL used in the PSK demodulator. I
haven't looked into the issue very deeply, but I have confirmed that given the
same input parameters, the FLL from 3.4.2 works fine, while the 3.5.0 version
causes a lot of overruns.
Jordan
On Nov 4, 2011, at 12:18
I am not seeing the same buffering issues with GMSK. I' am guessing that
the recent work on gr-digital may have accidentally messed up our d*psk
blocks. Maybe massive filter coefficients are being calculated?
When Tom gets back I think he can offer some insight.
Can you try/compare the GMSK mod/d
On 11/03/2011 08:52 PM, Tuan (Johnny) Ta wrote:
> Just a thought. Could this be the overhead of the new stream tags? Since I
> didn't see it before.
>
The tags overhead should be next to nothing. The source block only
produces a tag once on init, and after overflows. The overflows that you
see
Just a thought. Could this be the overhead of the new stream tags? Since I
didn't see it before.
On Thu, Nov 3, 2011 at 10:23 PM, Tuan (Johnny) Ta wrote:
> Josh,
>
> I've upgraded to 3.5rc0. The same thing happened. I got some more details:
>
> When I ran benchmark_tx on 1 machine, at low bitrate
Josh,
I've upgraded to 3.5rc0. The same thing happened. I got some more details:
When I ran benchmark_tx on 1 machine, at low bitrate (0.1Mbps or 0.2MSps -
I'm using bpsk) the CPU utilization is roughly 9%.
But the receiver, running benchmark_rx showed 110% CPU utilization.
If I up the bitrate t
On 11/03/2011 01:28 PM, Tuan (Johnny) Ta wrote:
> Hello all,
>
> I just came across a strange behavior in the digital benchmark examples
> that I haven't seen before. The transmitter wouldn't stop itself after it
> finishes sending the requested data size (specified by -M argument).
> Keyboard i
