[Hackrf-dev] what is the story with gr-osmosdr not building?

[Chuck McManis]

Hi Dominic,

> We're not in a position to support LimeSDR on this mailing list,

I know, I much prefer my HackRF :-). Up to now I've "gotten away" with
just using the packages rather than go into the FOSS dungeon to smelt
metal to cast parts for a lathe so that I can create the tools that I
need to get something done. Consider it an expression of my
frustration. So begins my entry into the third level of hell, perhaps
I'll blog about it :-). It does surprise me that HEAD on a 'major'
package like gr-osmosdr would not even be buildable, (because that is
typically the first test prior to merge a commit, does it still build)
but as I've been digging into it, some of the inter-relationships
between gnuradio, what Ettus started with (aka the uhd API) and the
current state of affairs (about a half dozen SDRs bodged into the
framework in one way or another) that the situation is far from
"simple."

Since the HackRF stuff seems to be the most effectively integrated SDR
I just assume all the pros are here who already know all this stuff.

--Chuck

On Mon, Jul 31, 2017 at 10:22 PM, Dominic Spill <dominicgs at gmail.com> wrote:
> On 30 July 2017 at 22:51, Chuck McManis <chuck.mcmanis at gmail.com> wrote:
>>
>> Every day I regret spending money on this LimeSDR unit, and the only way
>> to talk to it is with 'SoapSDR' driving it through gr-osmosdr. Now why
>> gr-osmosdr can't drive it directly? Who knows but still I thought I would
>> rebuild gr-osmosdr from source and it dies horribly trying to build RTL
>> stuff.
>
> Hi Chuck,
>
> We're not in a position to support LimeSDR on this mailing list, there's no
> link between the projects and I don't have access to the hardware.  I don't
> know if LimeSDR has a support channel, but I would recommend contacting them
> or other LimeSDR users as they will likely have experience with building
> LimeSDR support for GNU Radio.
>
> Thanks,
>   Dominic