[Hackrf-dev] ubuntu 14.04lts

Sat Jul 18 08:44:55 EDT 2015

On 18 July 2015 at 12:57, Rainer Matla <rainer at matla.me> wrote:
>
> But: your tipps lead me to the tlp service. And there is an auto suspension
> for usb activated. So i deactivated it in /etc/default/tlp , or better added
> the device identifier to the blacklist and it now works like a charm!

The TLP problem is something that another user has reported in the
past few days and is being tracked here:
https://github.com/mossmann/hackrf/issues/181

We believe that this is a firmware issue, but I don't have a fix for
this yet, other than disabling auto suspend for HackRF.

> Am 17.07.2015 um 23:57 schrieb Paul Connolly <eeipcy at gmail.com>:
>
> I'm curious does 'uname -r' return a kernel version older than 3.18 in
> Ubuntu 14.04, (before the hackrf module was added by LinuxTV kernel
> developers) ?
>
> http://palosaari.fi/linux/
> ... snip ...
> HackRF SDR driver (hackrf)
> * Kernel 3.18
> * only RX
> ... snip ...
>
> You could try the following:
> https://github.com/mossmann/hackrf/issues/165#issuecomment-106059555
> $ echo "blacklist hackrf" | sudo tee /etc/modprobe.d/blacklist-hackrf.conf
> $ sudo rmmod hackrf
>
> Which was fixed with this update.
> https://github.com/mossmann/hackrf/issues/163
>
> Or maybe it is USB ports being automatically powered down by Ubuntu, if
> powernap is installed ?
> $ sudo powernap-action --disable usb_autosuspend
>
> Or if it is Ubuntu with "Laptop-Mode-Tools" installed to extend battery life
> you could disable the powerdown of this specific USB device:
> Find the ID with 'lsusb', for a HackRF One this will be "1d50:6089"
> Edit the AUTOSUSPEND_USBID_BLACKLIST parameter in
> /etc/laptop-mode/conf.d/usb-autosuspend.conf to be
> AUTOSUSPEND_USBID_BLACKLIST="1d50:6089"
> sudo service laptop-mode restart
>
>
>
> On 17/07/2015 17:56, kd5wdq . wrote:
>
> I get this on my Nvidia Jetson bd.  Google this and it turns out it was just
> introduced in (I forget which) libusb or ubuntu 14.0x.   So it's known,
> and it acts like you describe.
>
> So I'm waiting for a fix.
>
> eddie af5sa
>
> On Fri, Jul 17, 2015 at 11:19 AM, Rainer Matla <rainer at matla.me> wrote:
>
> Hi everybody,
>
> i tried to use the installation script from Donald. Everything seems to
> work, so i don’t get any errors during the installation or so.
>
> But when i try to run the hackrf_info command i get the following error:
>
> Found HackRF board 0:
> hackrf_open() failed HACKRF_ERROR_LIBUSB (-1000)
>
> Okay, i know this error could be from the missing dev rules. But they are
> all there.
>
> The real crazy part is: When i’m trying the command a second time, i get a
> correct output.
>
> Firmware Version: 2014.08.1
> Part ID XXX
> Serial XXX
>
> When i retry it: every next try works. But when i’m waiting 2 minutes, i
> get the same libusb error from above.
>
> Can anyone help me with that? (i tried the hacker on my MacBook and it
> works fine so it should not be a Hardware Issue… )
>
> Thank you!
>
> Am 13.07.2015 um 00:38 schrieb Donald Pupecki <pupeckd at sunyit.edu>:
>
> No problem. I'll add that if you switch between the hackrf and the ettus
> board in gqrx it may eventually tell you an error about gain settings not
> being correct and refuse to start. Not sure if it's been fixed yet. But if
> you get it, its due to gqrx saving the gain settings and trying to apply
> the wrong ones when you load up the ettus board. The fix is to remove the
> gains=<blah> line from ~/.config/gqrx/default.conf
>
> Or just rm the whole file. (Tho that will clear some settings.)
> On Jul 12, 2015 3:20 PM, <tokens at myranch.com> wrote:
>
>   Donald,
>
> Thank you for your script!!!! After spending the last four days (on and
> off) trying Pybombs and other methods, reinstalling Ubuntu each time, your
> script was the thing that worked for me.
>
> Al
>
>  *From:* Donald Pupecki <pupeckd at sunyit.edu>
> *Sent:* Wednesday, July 08, 2015 3:56 AM
> *To:* Paul Connolly <eeipcy at gmail.com>
> *Cc:* hackrf-dev at greatscottgadgets.com
> *Subject:* Re: [Hackrf-dev] ubuntu 14.04lts
>
>
> Well,
>
> Heres an argument for just doing it from source. I made a little script
> that builds gqrx and gnuradio with support for hackrf, uhd, and rtlsdr on
> 14.04lts.
>
> I highly encourage anyone who wants to use it to not just run it but open
> it up and copy/paste the lines into a terminal so you see the process. It's
> written such that it avoids any real need to know bash to use. All the
> commands are just as if you would have typed them into a terminal yourself.
>
> I included some commented out lines on the bottom that should show you
> how to uninstall or update.
>
> And lastly... it's not very robust, in favor of simplicity, so I wouldn't
> try to rerun it without uninstalling and then deleting the SDR directory it
> created. It should be considered more like a how to that happens to be
> executable.
>
> Hope someone finds it useful.
>
> https://github.com/Flamewires/u14lts-gr-build/blob/master/build.sh
> On Jul 7, 2015 5:59 PM, "Paul Connolly" <eeipcy at gmail.com> wrote:
>
> Either way is fine, just choose one and stick to it. Me personalty I use
> packages, but I re-pointed my Debian machine from wheezy to jessie, so
> I at the cost of being behind on security updates (machine is not
> networked) I'm slightly closer to the cutting edge, but still behind
> using  ppa:gqrx/(releases and snapshots), mostly because I did not know
> that it existed when I set the machine.
>
> packages
> -------------
> pros:
> Easy to install (
> https://github.com/mossmann/hackrf/wiki/Installing-gnuradio-on-Ubuntu-14.04-with-the-packaging-manager
> )
> Fast to install
> Easy to update (sudo apt-get update)
> Fast to update
> cons:
> Can lag behind the cutting edge of changes to the source code ( releases,
> but maybe not snapshots )
> In theory a malicious person could own your machine, but the same is
> true from an OS distributor.
>
> pybombs
> pros:
> Works on more Linux distributions
> At the cutting edge of changes to the source code
> Easy to install ( http://gnuradio.org/redmine/projects/pybombs/wiki )
> Easy to update (./pybombs update)
> More secure since you have built the binaries, no  need to trust that
> the package binaries are not malicious (99.999999999% of the time, not an
> issue).
> cons:
> Always at the cutting edge of changes to the source code
> Slower to install and update - compiling all the source code into
> binaries takes time
>
>
> On 07/07/2015 22:06, tokens at myranch.com wrote:
>
> There have been several suggestions as to how to install. What are the pros
> and cons of the methods. I am Linux illiterate so please be explicit.
>
> Thank you all for your help.
>
> Regards,
> Al
>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
> ------------------------------
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>  _______________________________________________
>
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>