Hi,
I've been pottering around in GRC trying to get a pair of function
probe's to update the QT fosphor GUI sink's centre frequency by calling
self.set_freq(float(subprocess.check_output(['/usr/bin/rigctl', '-m',
'2', 'f']).strip()))
at 5Hz and
self.set_samp_rate(self.samp_rate)
at 20Hz.
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
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
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
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
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
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
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 chunk
On 27/10/13 21:02, Alexandru Csete wrote:
On Sun, Oct 27, 2013 at 8:45 PM, Darren Long darren.l...@mac.com 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
Hi,
In gnuradio-companion, I'm tring to control my KX3 transceiver using
hamlib's rigctl utility.
I've bodged a call to:
float(pexpect.run(rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f))
in a variable block's value, and then used that to set the wxgui
waterfall sink's baseband frequency, which
Hi,
In gnuradio-companion, I'm tring to control my KX3 transceiver using
hamlib's rigctl utility.
I've bodged a call to:
float(pexpect.run(rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f))
in a variable block's value, and then used that to set the wxgui
waterfall sink's baseband frequency, which
Never mind. I've bodged it directly in the generated python.
Darren
On 28/10/12 14:35, Darren Long wrote:
Hi,
In gnuradio-companion, I'm tring to control my KX3 transceiver using
hamlib's rigctl utility.
I've bodged a call to:
float(pexpect.run(rigctl -m 229 -r /dev/ttyUSB0 -s 38400
, Darren Long wrote:
Never mind. I've bodged it directly in the generated python.
Darren
On 28/10/12 14:35, Darren Long wrote:
Hi,
In gnuradio-companion, I'm tring to control my KX3 transceiver using
hamlib's rigctl utility.
I've bodged a call to:
float(pexpect.run(rigctl -m 229 -r /dev
Hi Chris,
Might I be so bold to suggest that in your efforts, you consider using
the gr-osmosdr abstraction (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR)
so that the RTL-SDR could be used too. In fact it supports UHD, FCD and
RTL-SDR, and works well in gqrx for example.
Sorry for being cheeky :P
Me too, please.
Darren
On 07/06/12 00:20, John Malsbury wrote:
PS - The decoder I built was tested with live recordings of a stensat
beacon from the phonesat group, so I think it will certainly work in
your case - if only with minor modifications.
-John
On Wed, Jun 6, 2012 at 4:18 PM,
I've noticed that when stopping a GRC sketch and starting another, I get
unknown stream ID reports from my B100, requiring a restart of the USRP to
recover. This used to happen a while back, but was fixed. Perhaps the fix has
been broken or the issue is similar.
Darren
Sent from my iPhone
On
In the amateur radio world, AX.25 packet radio terminal node
controllers supported KISS mode, which left the CSMA and HDLC framing
in the TNC but offloaded the state-machine for connection management to
the host CPU stack.
KISS merely provided a way to forward the frame metadata and payload
-gnuradio] uhd b100 problems
Date: Fri, 17 Feb 2012 22:14:47 +
From: Darren Long darren.l...@mac.com
To: dave k dave_k_...@yahoo.com
I have been having similar issues intermittently, although just
reloading the firmware works for me without the need to cycle power.
It seems to have improved
18 matches
Mail list logo
