Hi Mike
Alex (the gqrx and Gpredict author) suggested using pyephem to me once when I
asked about this. I did have a little play with it, but haven't done anything
interesting or useful.
http://rhodesmill.org/pyephem/
Darren, G0HWW
On 24/11/14 10:15, Mike Willis wrote:
> I know this is going b
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.
This
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-typ
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
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
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
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 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
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
Darren
On 28/10/12 17:55, 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
>> haml
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(p
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
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 P
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
ov
scuss-gnuradio] uhd b100 problems
Date: Fri, 17 Feb 2012 22:14:47 +
From: Darren Long
To: dave k
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 in the last week or so with up
19 matches
Mail list logo