# Display Problem with QT GUI Vector Sink

**URL:** <https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237>\
**Category:** GNU Radio\
**Created:** [September 3, 2015, 11:26am UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237 "2015-09-03T11:26:57Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\
**Post date:** [September 3, 2015, 11:26am UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/1 "2015-09-03T11:26:57Z")

</div>

Dear all,

I built an angle-of-arrival system using four Ettus USRP2. I’m facing a  
problem when trying to display a vector containing the calculated  
MUSIC-Spectrum using a “QT GUI Vector Sink”. The vector sink won’t  
display any data for the first two minutes, and then it is starting to  
show very old values. When I use the block “Vector to Stream” and a  
simple “QT GUI Time Sink” instead, the values are displayed immediately  
without delay.

The block “music\_cf” feeding the vector sink is a sync\_decimator,  
generating one vector of 181 elements for every 1000 input samples. I’ve  
provided a shortened version of my c++ code in the attachment, without  
the actual mathematics.

What could be the reason for this huge delay when using the “QT GUI  
Vector Sink”? Is it a buffering problem?

Best regards,  
Simon

Block Diagram:  
[![](http://fs1.directupload.net/images/150903/7cnqbzup.png) ](http://fs1.directupload.net/images/150903/7cnqbzup.png)

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [September 3, 2015, 6:50pm UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/2 "2015-09-03T18:50:56Z")

</div>

The vector sink has an averaging option, is that on?

M

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [September 4, 2015, 10:58am UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/3 "2015-09-04T10:58:53Z")

</div>

Hi Martin,

averaging is disabled. Any further ideas?

Best regards,  
Simon

Am 2015-09-03 18:49, schrieb Martin B.:

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [September 4, 2015, 9:46pm UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/4 "2015-09-04T21:46:45Z")

</div>

There’s an example for the vector sink, which doesn’t seem to have that  
issue. Can you confirm that? It’s in gr-qtgui/examples.

M

PS: I had to locally fix the example, maybe you need to do that to, the  
actual vector sink block was missing.

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [September 7, 2015, 1:19pm UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/5 "2015-09-07T13:19:46Z")

</div>

Hi Simon,

> Is it possible, that the way my music\_cf function is outputting the  
> data, might cause some trouble?

181 floats isn’t really a “round” itemsize, and since GNU Radio can only  
build buffers that are multiple of 4KB (==4096B), I assume that you get  
a large buffer (probably 4096 items of size 181\*sizeof(float) each).  
That per se is not a problem (maybe a loss of a few MB of RAM, but who  
cares in this day and age?); but things get large, and as you can see,  
latency can be pretty high. I remember seeing this a while back, when I  
was trying large (as in 50dBbin) FFTs with the vector sink; I kind of  
assumed visualizing a vector that is a couple of thousand times larger  
than my screen had pixels in x-direction would have been what introduced  
the latency, so I didn’t look into it.

Attempt of building a test case, which might solve your issue, but is  
vastly bad design (because it just copies twice):

music\_cf-\>vector\_to\_stream-\>stream\_to\_vector-\>qt\_vector\_sink

Could you try that?

Next step, because this might be interesting: If you have both  
performance counters enabled and Thrift/gr-controlport, you could have a  
look at the ctrlport performance monitor, which would tell you things  
like the average buffer fill, average work() run time, and variance of  
these numbers.

Best regards,  
Marcus

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [September 7, 2015, 12:45pm UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/6 "2015-09-07T12:45:53Z")

</div>

The example is running without errors.  
Is it possible, that the way my music\_cf function is outputting the  
data, might cause some trouble?

Simon

Am 2015-09-04 21:45, schrieb Martin B.:

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [September 9, 2015, 2:16pm UTC](https://www.ruby-forum.com/t/display-problem-with-qt-gui-vector-sink/243237/7 "2015-09-09T14:16:00Z")

</div>

Hi Marcus,

thanks for your detailed reply. I built your test case, which shows the  
same huge delays of ~2 minutes.  
Surprisingly, changing the vector size to 1024 elements (=4096 bytes)  
yielded a much better result with delays going down to about 3 seconds.  
Nevertheless I think I’ll stick to to the workaround of using ‘Vector to  
Stream’ combined with a time sink, as this gives me the best  
responsiveness.  
Performance counters and Thrift seem promising methods to further  
analyze this behavior, but as of now the idea of having to recompile and  
reinstall gnuradio isn’t very tempting.

Thanks again for your help,  
best regards,  
Simon

Am 2015-09-07 13:18, schrieb Marcus Müller:
