When I run "sudo apt-get install hackrf-tools" I get the following: "E:
Unable to locate package hackrf-tools".
I then assumed that the command should be "sudo apt-get install
hackrf". That seemed to install something.
I then added the needed line to 52-hackrf.rules and rebooted.
Now when I
Try this page:
https://github.com/mossmann/hackrf/wiki/FAQ
On 9/9/2014 7:24 AM, GeorgeF wrote:
When I run "sudo apt-get install hackrf-tools" I get the following:
"E: Unable to locate package hackrf-tools".
I then assumed that the command should be "sudo apt-get install
hackrf". That seem
As a heads up, I was able to get everything working using only GNURadio
Companion. I tied the USRP Source into a Stream-to-Vector block and
created a 20 MS buffer. From there I sent the 20 MS vector to the File
Meta Sink.
This adds some latency, but for my application this is perfectly OK. I
ha
On Mon, Sep 8, 2014 at 11:13 PM, zealdeal wrote:
> Thanks for the info. Can anybody please confirm whether the step size limit
> of 0.5 dB is valid for USRP N200?
>
Use their tool uhd_usrp_probe to find the specifics of your USRP and
daughterboards.
Tom
_
Hi,
this is very interesting!
As this actually seems to be more of a storage issue, I think
kernel-based solutions might be good, too: (as root)
|echo 90 > /proc/sys/vm/dirty_ratio
echo 75 > /proc/sys/vm/dirty_background_ratio
|
|Should allow your kernel to use up up to 90% of your RAM for writ
On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl
wrote:
> Hi all,
>
> looking at the clock recovery MM code, I wonder if d_omega_relative_limit
> is a relative or absolute deviation from d_omega.
>
> Here it looks like absolute
>
> https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/cloc
On Tue, Sep 9, 2014 at 5:24 AM, GeorgeF wrote:
> When I run "sudo apt-get install hackrf-tools" I get the following: "E:
> Unable to locate package hackrf-tools".
>
> I then assumed that the command should be "sudo apt-get install hackrf".
> That seemed to install something.
>
> I then added the n
Has anyone else noticed that in recent GR, medium-to-large flow-graphs
are now *agonizingly slow* to edit, even on relatively-capable
machines?
Larger graphs were always a tad sluggish, but it has now gotten to the
point that larger ones are nearly uneditable, and medium ones are
agonizing
On 09 Sep 2014, at 15:42, Tom Rondeau wrote:
> On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl wrote:
> Hi all,
>
> looking at the clock recovery MM code, I wonder if d_omega_relative_limit is
> a relative or absolute deviation from d_omega.
>
> Here it looks like absolute
> https://github.c
Yes, even after a fresh reboot there is still a delayed reaction while
dragging about blocks in GRC.
GNU Radio Companion 3.7.5git-194-g76a271ac
Ubuntu 14.04 x64 LTS
Quad Core i7
Mike
--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com
On Tue, Sep 9, 2014 at 7:29 PM, Mar
Yes, I have the same issue with v3.7.5
Thanks
Tiankun
Mike Jameson 编写:
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnur
On 09/09/2014 08:20 PM, Tiankun Hu wrote:
Yes, I have the same issue with v3.7.5
Thanks
Tiankun
Mike Jameson 编写:
Yes, even after a fresh reboot there is still a delayed reaction while
dragging about blocks in GRC.
GNU Radio Companion 3.7.5git-194-g76a271ac
Ubuntu 14.04 x64 LTS
Quad Core i
12 matches
Mail list logo