[uplink]VHF-burst_test_lambda.grcDescription: Binary data
|
| From: | samuel verdon |
| Subject: | Re: [Discuss-gnuradio] FSK Burst emission |
| Date: | Thu, 5 Apr 2018 10:59:07 +0200 |
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 :
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 listed above. 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.
Thank you in advance for your help. Samuel De : Müller, Marcus (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 |
[uplink]VHF-burst_test_lambda.grc
Description: Binary data
| [Prev in Thread] | Current Thread | [Next in Thread] |