Re: [Discuss-gnuradio] FSK Burst emission

[CEL]

So, to give a bit of insight where I think this will, medium-to-long
term end up:

We'll do message passing much more than before. We certainly need a way
of doing so with backpressure – tagged stream blocks does implement
that, but I frankly think that it's been an architectural experiment
that turned up a lot of problems, and we'll need to find a way to work
around these; I don't think TSB will be the go-to solution for this in
the long run.

Remote things will require two things:

· Ctrlport that actually works for most. And with that I mean we need
to replace Thrift.
· We'll need a common command format. I've had some code a while back
that basically made it easy for blocks to register a message handler
for every method; we need to standardize the way we're going to do
that. Essentially, the preferred way of mucking around with blocks'
states should be through messages, not direct method calls (that solves
a lot of threading issues for free, too)
· We'll need a sane format to transport these commands. ZeroMQ does
work well for a transport, but PMT is really holding us back at this
point. What use is a serialization library that's not fully machine-
independent, can't be used with static class members, makes it hard to
construct even the most basic structures, doesn't come with any
language bindings than those that  just as well could directly
interface directly with GR, and isn't installable without a full GR
runtime? (don't get me started about the object ownership/refcounting
issues that its Python wrapper introduces.) I'm partial to messagepack
at this point, but I've not done enough research to say it's 100% what
we should be using.

Best regards,
Marcus

On Thu, 2018-03-29 at 11:17 -0400, Jeff Long wrote:
> 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) <address@hidden
> > > .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
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > 
> > > -- 
> > > Very Respectfully,
> > > 
> > > Dan CaJacob
> > > 
> > > 
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature