With a working OpenCL platform -- that can be an OpenCL-cabable GPU
driver, or something like the intel OpenCL implementation.
Depending on what devices or how you pass through the CPU to the VM,
that might even work -- however, gr-fosphor is just "one" awesome
visualization making most of OpenCL to reduce CPU load necessary to
display an FFT for every single input vector.
If you can live with lesser update rates (and hence, a reduced
probability of interception), simply go for the QT frequency or
waterfall sinks.
It's probably even worth it thinking about moving your signal processing
out of your VM; high rate visualizations aren't exactly what virtual
display adapters were made for...
Best regards,
Marcus
On 27.07.2015 16:02, Jason Matusiak wrote:
That's it -- the detection is working, but the demod is not.
OK, thank you Martin, that at least helps me narrow down where the issue
was (with the comms itself, or my setup).
On your receive end, make sure you have a clean spectrum using e.g.
fosphor. You'll notice distortions, clipping etc. by a surge of
out-of-band emissions.
Sadly I think fosphor is going to be a no-go as I am running in a VM.
My understanding was the fosphor needed to be run on a PC with a GPU, is
that right?
~Jason
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
