Hi Dennis,
yes, that's probably 83%. From gnuradio-runtime/lib/block_detail.cc:
297 float pfull = 1.0f -
static_cast<float>(d_output[i]->space_available()) /
298 static_cast<float>(d_output[i]->bufsize());
299 d_ins_output_buffers_full[i] = pfull;
and
393 std::vector<float>
394 block_detail::pc_output_buffers_full()
395 {
396 return d_ins_output_buffers_full;
397 }
But block.cc:
863 d_rpc_vars.push_back(
864 rpcbasic_sptr(new rpcbasic_register_get<block,
std::vector<float> >(
865 alias(), "output \% full", &block::pc_output_buffers_full,
...
As it seems, this is a display bug... Would you be interested to fix
these strings in gnuradio-runtime/lib/block.cc , and then to submit a
pull request on github? (maybe also fix
gnuradio-runtime/python/something/gr-perf-monitorx) Fame awaits...
Best regards,
Marcus
On 07/09/2015 08:47 AM, Dennis Glatting wrote:
> I'm tracking down an overrun condition with a HackRF SDR but I'm a
> little confused by what ControlPort is telling me.
>
> Control Port says my hackrf_source is "output % full" of 0.83.
>
> Is that 0.83% or 83%? I suspect 83%.
>
>
> Thanks in advance,
>
>
>
>
> _______________________________________________
> 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
