Those could very well be pictures of the same signal. Note that the VBW 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:muel...@kit.edu>
*Envoyé le :*Friday, March 30, 2018 18:27
*À : *discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>; willco...@gmail.com <mailto:willco...@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

Reply via email to