Re: [Discuss-gnuradio] FSK Burst emission

Two things I think would be a big win for GR are a clean interface with
message-oriented sources/sinks and easier distributed deployment/remote
control. Maybe that's three things.

On 03/29/2018 08:22 AM, Müller, Marcus (CEL) wrote:
> That's actually an extensively great idea (though I admit it hadn't
> crossed my mind so far)!
>
> So, for this to make it upstream, first of all, it'd need an OK from
> Tim, as that probably kinda reassigns copyright to the FSF (Ben would
> be my go-to authority on that).
>
> Then, I'd obviously have to play "grumpy mean old maintainer" a bit:
> I know there's qa_es.py, but I think it's been written before we fixed
> shutdown bugs, so, probably, there's a bit good functionality that's
> not covered by tests. Seeing how much "fun" we've had after extending
> runtime infrastructure (and that's what I'd consider eventstream), to
> avoid regressions in the future, I'd have to insist on a few additional
> tests. Don't know how they'd look like, which might be an indication
> I'd need to invite Tim for a beer and talk about what should be tested.
> Code coverage metrics alone do not make for good testing.
>
> And: As cool as eventstream is, and as much as I like Tim's blog, we'd
> obviously need formal documentation; right now, I can't find a docs/
> folder in my gr-eventstream build directory, so at least the building
> of API docs needs to be fixed. And: if we do gr-eventstream, we'd do it
> properly, which means that someone needs to sit down and write a guide
> that integrates with the tutorials. I'm afraid a simple copypasta from
> Tim's block wouldn't do, but would need to be broken down for beginners
> to understand the problem at hand first (which requires some GNU Radio
> operational theory).
>
> So, as I can't do that today, and probably not in the first two weeks
> of April, either, I'd propose we make a GREP out of that. Want to
> champion that? That way, we'd document a desire to improve GNU Radio at
> its core, and give us a target.
>
> Cheers,
> Marcus
>
> On Thu, 2018-03-29 at 00:44 +0000, Dan CaJacob wrote:
>> Speaking of gr-eventstream, Marcus: is there any intent to pull that or something like it into core in this new Gnuradio world?
>>
>> On Wed, Mar 28, 2018 at 3:22 PM Müller, Marcus (CEL) <mueller@kit.edu> wrote:
>>> Hi Samuel,
>>> On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote:
>>>> I forgot to say that my graph is connected to hardware (bladerf or limesdr) via osmocom block. This one give me the error that there is not enough data.
>>>
>>> Jeff's mail recommending gr-eventstream was on-spot.
>>>
>>> Best regards,
>>> Marcus_______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio