Hi,
> However I will follow the issue from time to time, as I think it would be
> great to have beignet available for this (and other) purposes.
Yes, it'd be great and I would love if a beignet dev was also
interested and SDR and tried to make it work and implement the missing
stuff.
Or a SDR gu
Hi Silvain,
great - thanks for your answer. I got it run now on OS X via simple macports
install. However I will follow the issue from time to time, as I think it would
be great to have beignet available for this (and other) purposes.
Also I am keen on looking into how the colored spectrum vie
Hi Markus,
> 1) Can it be compiled without OpenCL?
No. All the data processing is done with OpenCL.
> 2) Do you know beignet? Appearantly they try to implement OpenCL support for
> Haswell.
Yes and this should in time allow to run fosphor.
But I don't think they're sufficiently advanced yet
Hi Sylvain,
I am lucky to have a new Laptop with i7 Haswell CPU, however you have
written on gr-fosphor homepage that intel does not offer OpenCL for Haswell
on Linux. (Appearantly due to some self cannibalization issue of their
products if done so, as suggested somewhere else on the internet). I
Hi Nick,
I've just pushed all the things that were pending in my tree, which
include the sample rate awareness, configurable FFT windows and
various fixes / refactor for more things to come.
> Great! Glad to hear it. You might still take a look at the changes to gl.c,
> as they're orthogonal to y
As of mid-day today, gr-fosphor is available via MacPorts for OSX < 10.9 users.
It looks quite nice! Thanks Sylvain! - MLD
On Oct 26, 2013, at 4:23 PM, Sylvain Munaut <246...@gmail.com> wrote:
> The home page of the project can be found at
> https://sdr.osmocom.org/trac/wiki/fosphor
_
On Wed, Oct 30, 2013 at 1:28 AM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi Nick,
>
> > I've added basic sample rate awareness to gr-fosphor via constructor
> > parameters and a set_rate() call. The GRC blocks now take a sample rate
> > parameter as well. The sink also creates an appropriate le
Hi Nick,
> I've added basic sample rate awareness to gr-fosphor via constructor
> parameters and a set_rate() call. The GRC blocks now take a sample rate
> parameter as well. The sink also creates an appropriate legend (kHz, MHz,
> etc.) and applies it to the plot. I've tested it with WX, Qt, and
Hi,
> ImportError: libgnuradio-fosphor-3.7.0git.so.0.0.0: cannot open shared
> object file: No such file or directory
Did you install it in the same prefix as gnuradio was installed in ?
Not sure where your GR install comes from ...
> I passed the GLFW directories to cmake, and edited line 26
All,
I've added basic sample rate awareness to gr-fosphor via constructor
parameters and a set_rate() call. The GRC blocks now take a sample rate
parameter as well. The sink also creates an appropriate legend (kHz, MHz,
etc.) and applies it to the plot. I've tested it with WX, Qt, and GLFW
version
Thanks, that worked. It complied without GLFW but it errs at run time
with:
ImportError: libgnuradio-fosphor-3.7.0git.so.0.0.0: cannot open shared
object file: No such file or directory
I passed the GLFW directories to cmake, and edited line 26
of glfw_sink_c_impl.cc to remove the directory nam
On 10/29/2013 07:22 PM, Louis Brown wrote:
> Any ideas as to why cmake is not finding the CL libraries on my
> machine; Fedora 19 x64?
>
> Could NOT find OpenCL (missing: OPENCL_LIBRARIES)
> CMake Error at CMakeLists.txt:104 (message):
> OpenCL required to compile gr-fosphor
>
> I have adde
Any ideas as to why cmake is not finding the CL libraries on my
machine; Fedora 19 x64?
Could NOT find OpenCL (missing: OPENCL_LIBRARIES)
CMake Error at CMakeLists.txt:104 (message):
OpenCL required to compile gr-fosphor
I have added the following environment
variables with no luck:
export O
Hi Mike,
> On my PC gr-fosphor handled the full 28MHz BladeRF BW beautifully.
Happy to hear it works nicely for you :)
> I've used R&S's FSVR and dare I say it, I reckon gr-phosphor is possibly
> better than the FSVR's visualizer, and MUCH more affordable.
Thanks !
I never had the chance to
Hi Sylvain,
I had a chance to try it 'for real' this afternoon displaying live signals
from a BladeRF source.
Let me just say WOW that's seriously impressive !
On my PC gr-fosphor handled the full 28MHz BladeRF BW beautifully.
I've used R&S's FSVR and dare I say it, I reckon gr-phosphor is
Hi Mike,
> I hit the 'clCreateFromGLTexture' issue when compiling the benchmark tool,
> not only did I need to comment out the #define but I also needed to turn off
> -Werror in the makefile.
Yes. I have a potential fix, just need to test it doesn't break OSX ...
> I get 61msps with a GT9800 on
Hi,
> Well, the fosphor waterfall itself isn't of much use at high rates as the
> signals just whizz of the screen before you get a chance to look at them.
> The magic, as you point out, is in the fosphor FFT plot, which is awesome!
It kind of depends what you're looking for.
Personally I use th
Hi Sylvain,
Nice work, I just gave it a spin here are my results;-
I hit the 'clCreateFromGLTexture' issue when compiling the benchmark tool,
not only did I need to comment out the #define but I also needed to turn
off -Werror in the makefile.
I get 61msps with a GT9800 on a i7-950 @ 3.06G
Inter
On 27/10/13 21:02, Alexandru Csete wrote:
On Sun, Oct 27, 2013 at 8:45 PM, Darren Long wrote:
I'd like to be able to use this with my KX-3 perhaps as slowly as 48kHz :)
Daren,
Do what exactly?
The purpose with gr-fosphor is to visualize more data that what is
possible with snapshot-type FFT.
Hi,
> Actually, with the chunk size hack, the waterfall is just about OK at 192kHz
> sample rate, but it is still a little jerky. Could we have a buffering
> option to buffer the waterfall for some time before scrolling?
That wouldn't really change anything.
The issue here is that fosphor proces
On Sun, Oct 27, 2013 at 8:45 PM, Darren Long wrote:
>
> On 27/10/13 17:46, Sylvain Munaut wrote:
>>
>> Since the whole idea being fosphor is to never just "drop" data, to slow
>> down the waterfall, multiple FFT results must be "aggregated" with either
>> min/max/avg functions and that's a bit mor
On 27/10/13 17:46, Sylvain Munaut wrote:
Since the whole idea being fosphor is to never just "drop" data, to
slow down the waterfall, multiple FFT results must be "aggregated"
with either min/max/avg functions and that's a bit more tricky to
implement. Cheers, Sylvain
Actually, with the chu
Hi,
> Can we control any options on the sink? For example frequency scale,
> waterfall rate, etc. A callback would be nice too. I'd like to use the
> fosphor sink in my gr-kx3 script that I use to control my HF transceiver.
For the moment not much. You have some basic key control of the power
Yep, I concur. It is blazingly fast at rendering with the HackRF :)
Can we control any options on the sink? For example frequency scale,
waterfall rate, etc. A callback would be nice too. I'd like to use the
fosphor sink in my gr-kx3 script that I use to control my HF transceiver.
This i
Hi,
> However, it seems to be quite laggy, with 'chunks' of 'water' 'falling' at
> about 1 second intervals and not flowing smoothly.
Yes, the FCD will not quite provide enough data for it ... It's more
aimed at very wideband SDR :p
It currently processes data in chunks of 128 * 1024 which for t
Good call. I applied the 4 patches and now I can run osmocom_fft with
the -F option succesfully.
$ osmocom_fft -F -a "fcd=1"
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.004-0-unknown
gr-osmosdr v0.1.x-xxx-xunknown (0.1.1git) gnuradio 3.7.1
built-in source types: file osmos
Hi,
> Set Frequency to: 7.1e+06 Hz, corrected to: 710 Hz
> [xcb] Unknown request in queue while dequeuing
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not
> been called
> [xcb] Aborting, sorry about that.
> python2: ../../src/xcb_io.c:179: dequeue_pending_request: A
Good thinking. Next hurdle is an error:
darren@betty:~$ osmocom_fft -F -a fcd=1 -f 7.1M
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.004-0-unknown
gr-osmosdr v0.1.x-xxx-xunknown (0.1.1git) gnuradio 3.7.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
ne
Hi Darren,
> I can't get osmocom_fft to run, due to a problem inporting fosphor. It runs
> OK without the -F argument. Not sure what is wrong yet. Everything seemed
> to build and install OK. Please see the output below. Also, should there be
> any new blocks in grc?
You need to install in th
Hi Sylvain,
I can't get osmocom_fft to run, due to a problem inporting fosphor. It
runs OK without the -F argument. Not sure what is wrong yet.
Everything seemed to build and install OK. Please see the output below.
Also, should there be any new blocks in grc?
Cheers,
Darren
darren@be
Hi Alex,
The benchmark utility source is in gr-fosphor/lib/fosphor
I had to run make manually, but in order to get it to build I had to
bodge it. The changes I made are in the diff below.
===
diff --git a/lib/fosphor/Makefile b/lib/fosphor/Makefile
index a1ea187..3500d64
On Sun, Oct 27, 2013 at 1:01 PM, Darren Long wrote:
> Very nice. I've only just changed to using the gqrx repository instead of
> building everything from source, but I couldn't resist having a go at
> getting this working. I've managed to get the demo program running, but
> I've not been able t
Hi Darren,
> I've managed to get the demo program running, but
> I've not been able to do anything else yet.
Mmm, really ? What issue did you have ? Did it build at all ?
> 100 Frames time: 227558 us
> BW estimated: 230.397520 Msps
>
> That's the best figure I saw. I think that puts me at the
Very nice. I've only just changed to using the gqrx repository instead
of building everything from source, but I couldn't resist having a go at
getting this working. I've managed to get the demo program running, but
I've not been able to do anything else yet. Hopefully Alex will be able
to ad
> Thanks for the info - this workaround resolved my issue. Now it works
> and looks great.
Ok, great :)
> Does it mean that the glfw version can be used without gr-qtgui or gr-wxgui?
Yes. There is a standalone block that will just create it's own
separate window for display.
Also, I didn't ment
On Sun, Oct 27, 2013 at 10:49 AM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi,
>
>> ImportError:
>> /home/alc/sdr/pybombs/runtime/lib/libgnuradio-fosphor-3.7.0git.so.0.0.0:
>> undefined symbol: clCreateFromGLTexture
>
> Yes, I've been made aware of the issue but don't really know what to
> do ab
Hi,
> ImportError:
> /home/alc/sdr/pybombs/runtime/lib/libgnuradio-fosphor-3.7.0git.so.0.0.0:
> undefined symbol: clCreateFromGLTexture
Yes, I've been made aware of the issue but don't really know what to
do about it ...
Basically Ubuntu installs the OpenCL ICD from NVidia which is OpenCL
1.1 c
On Sun, Oct 27, 2013 at 10:39 AM, Alexandru Csete wrote:
> On Sat, Oct 26, 2013 at 10:23 PM, Sylvain Munaut <246...@gmail.com> wrote:
>>
>> Hi,
>>
>>
>> As some of you know, beginning of this month I presented a new
>> GNURadio block I wrote that implements a RTSA like spectrum
>> visualization of
On Sat, Oct 26, 2013 at 10:23 PM, Sylvain Munaut <246...@gmail.com> wrote:
>
> Hi,
>
>
> As some of you know, beginning of this month I presented a new
> GNURadio block I wrote that implements a RTSA like spectrum
> visualization of the spectrum similar to those found on R&S / Agilent
> / Tek equip
Hi,
As some of you know, beginning of this month I presented a new
GNURadio block I wrote that implements a RTSA like spectrum
visualization of the spectrum similar to those found on R&S / Agilent
/ Tek equipement.
I've just pushed the latest version of it on git and this includes a
proper integ
40 matches
Mail list logo
