is different on your two spectrum analyzer captures, and the GRC view is
probably not set up the same as either of those.
On 04/05/2018 04:59 AM, samuel verdon wrote:
> Hello
>
> I come back with my 2FSK burst emission. I will try to be as clear as I
> can 😊.
>
> 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:
>
> https://oshearesearch.com/index.php/2015/05/31/building-a-burst-fsk-modem-in-gnu-radio-with-message-lambda-blocks-and-eventstream/
>
> 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:
>
> https://ibb.co/nzfFex
>
> The image was the result of a ADF sending random data with the parameter
> listed above.
>
> But the output of my flowgraph(GRC) is the following:
>
> https://ibb.co/iq3e6c
>
> And the result on the Spectum Analyser(SA) is the following:
>
> https://ibb.co/kjEVCH
>
> 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.
>
> Samuel
>
> *De : *Müller, Marcus (CEL) <mailto:mueller@kit.edu>
> *Envoyé le :*Friday, March 30, 2018 18:27
> *À : *discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>;
> willcode4@gmail.com <mailto:willcode4@gmail.com>
> *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.
>
> 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) <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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment