I come back with my 2FSK burst emission. I will try to be as clear as I
As you recommended , I have checked the and install the eventstream block.
My modulation is the following :
* Frequency : 145 MHz
* Modulation : 2FSK
* Deviation : plus minus 1200kHz
* Bitrate : 1200 bit/sec
* Hardware : LimeSDR
I have built my flowgraph like the eventstream example here:
But adapted the parameter with mine. As there is no FSK nodulation
block, these “message lambda block” creates the block I need.
I attached the grc file to this e-mail.
The result is not really clear for me. I connect my Lime to a spectrum
analyser. I was hoping for a signal like this one:
The image was the result of a ADF sending random data with the parameter
But the output of my flowgraph(GRC) is the following:
And the result on the Spectum Analyser(SA) is the following:
I don’t understand why my signal looks so peaky and not with a good
shape like the ADF.
* How can I have a signal similar to the ADF?
* How can I confirm that my data are sent at 1200bit/s?
* Do I have change something special in the lambda except my parameter?
Thank you in advance for your help.
*De : *Müller, Marcus (CEL) <mailto:muel...@kit.edu>
*Envoyé le :*Friday, March 30, 2018 18:27
*À : *email@example.com <mailto:firstname.lastname@example.org>;
*Objet :*Re: [Discuss-gnuradio] FSK Burst emission
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.
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
> message-oriented sources/sinks and easier distributed
> 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
> > > > Discussemail@example.com
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > > --
> > > Very Respectfully,
> > >
> > > Dan CaJacob
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > Discussfirstname.lastname@example.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Discuss-gnuradio mailing list