Re: [Discuss-gnuradio] fftsink and scopesink refactored

[Martin Dvh]

Eric Blossom wrote:
> FYI,
>
> fftsink and scopesink were just refactored to use messages and message
> queues to communicate between the C++ and Python side.  This removes
> our dependency on pipes, but more importantly, the C++ side will now
> never block trying to send data to the GUI.
Thank you very much.
Not depending on pipes is very important for the windows port.
I tested rightaway and fftsink and scopesink now work right out-of-the-box on 
windows.
(No more windows-special hacks in scopesink and fftsink needed)

All options work, only the gui doesn't respond when the datarate is too great.

The C++ side will never block, but the gui does block when the data is coming 
in too fast.
In fft_sink you can solve this by adding the fft_rate=5 parameter when 
initiating the fft_sink.
(5 frames/sec in stead of default 20 frames/sec)
I also do this most of the time in linux because otherwise the gui-response is 
very slow on my 1Ghz machine.
On windowas it just doesn't respond at all without this. This could be 
different on faster machines.

With the scopsink I have to imidiately click on the timebase decrease button a 
couple of times.
When the timebase is short enought (below 5 microsec) the gui starts responding 
normally.
With a longer timebase, the gui gets no time at all, so does not respond.

I also tried adding the gr_throttle block, but this didn't help.
(as is in the example in scopsink.py itsself)

With gnuradio-core, gr-wxgui gr-audio-windows and the usrp working on windows I 
think it is time to get the windows-port out of the experimental stadium.

I have been working on making some cross-build scripts to cross-build and 
generate the windows installers from linux.
But this needs again a few gr_python.m4 changes.
(Not all variables are overidable on the commandline now)

I even could build the usrp installer using innosetup under wine.

Does anybody know if you can start innosetup from a script and tell it to build 
something without user/gui interaction?

The thing I couldn't built under linux was the fpga firmware because I couldn't 
get quartus to work under wine.

Greetings,
Martin


> There are also a couple generally useful new blocks:
>
>   gr.message_source
>   gr.message_sink
>
> The message source receives data from messages sent to it and writes
> it to an output stream.
>
> The message sink reads data from its input stream, generates messages
> and inserts them into the provided message queue.
>
> These are currently useful for getting variable length data in and out
> of the C++ world.  They currently work within the same address space,
> but with a bit of work, could be made to work across address spaces.
>
> Eric
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio