[Discuss-gnuradio] PMT to Float32
Hello all, I am trying to create an OOT take a value from a Blob type in GNU Radio, and put it out on an output as Float Data type, I have tried the following: *x = pmt.dict_ref (pmt.car(msg), y, pmt.from_double(100)) #this is suppose to take "y" and make "x" equals the value of "y"* *z = pmt.to_double(x) #this is suppose to make z the double value of x (which is PMT still)* *self.a = numpy.float32(z) # this makes the double to a float 32* . . . *def work(self, input_items, output_items):* * in0 = input_items[0]* * out0 = output_items[0]* * out[:] =self.a* return len(*output_items[0]*) I have tried this but it does not work, when i connect it to a "number sink" in a flowgraph it shows an error , saying that the output of my "new block" is length 8 and the input of the "number sink" is 4. Can anyone please help me, to find what is the problem? Also, if there are any examples or blocks in GIT created to convert Blobs to float or to INT, I would appreciate it. Once again thanks. Kind regards. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on Samples/Symbols (sps) in "PSK Demodulation" tutorial.
Hi Ashish - the short of it is: (samples/sec)/(symbols/sec) = samples/symbol If the bandwidth is complex, then samples/sec = sampling rate in MHz, and symbols/sec is the baud rate. There are lot of reasons why you would get into trouble by just by changing samples/symbol. You need to post the grc file, or the flowgraph for the problem. -- Cinaed On 12/27/18 9:00 AM, Ashish S wrote: > Hello everyone, > I have some confusion on samples/symbols concept in GNU Radio and it's > driving me crazy when I start to overthink on this. > > *How I did PSK modulation during my studies was : * > Generate random bits, group them according to modulation type > (here considering QPSK) and then pass it through some channel and then > demodulate it. > this whole thing runs in a loop for different values of SNR and I used > to plot BER vs SNR. Here is the quick snapshot > > image.png > > > *Running through the PSK modulation(example provided on GNU radio > tutorials)* > flowgraph : mpsk_stage1.grc > We have a random source which outputs 10k samples in the range of > [0,255] as a byte stream and constellation modulator outputs complex > baseband signal (based on constellation object mapping provided) > This constellation modulator has *samples/symbols *as an input which > needs to be >=2 . > > why is this >=2 and since random source repeats its 10k samples every > period , can't it just group two bits and map as a symbol. ? > When I tend to increase the SPS from 2 to 64 keeping everything the same > , the constellation starts to mess up and the fft plot goes narrower. > Can anyone of you give an insight into this, please ? > > > *When SPS is 4* > image.png > * > * > *When SPS is 2* > > image.png > > *When SPS is 16* > image.png > > *When SPS is 64* > * > * > image.png > > > Ashsih > > ___ > 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] GNU Radio Enhancements: Worth a Look!
Hi all, In case you didn't know: Like many other free software projects, we have a process for communicating major changes to GNU Radio early, using what we call GNU Radio Enhancement Proposals (GREPs). We manage GREPs in a git repository: https://github.com/gnuradio/greps The purpose of GREPs is manifold, but the main reasons for having them are: - They give us the ability to communicate early what we plan to do, so everyone can be involved soon, and is less surprised by what's coming - They 3rd-party developers the option to communicate their intent upstream before submitting the code. Every maintainer dreads the many-thousands-of-lines pull requests they hadn't heard before. - They give us a platform to discuss changes with our users before we start making decisions in private. For us maintainers, the year 2018 was all about getting 3.8 done, with all that it entailed: Removing Cheetah to enable Python 3, fighting SWIG to enable Python 3, replacing Qt4 with Qt5, improving the CI system... lots of stuff that was frankly a pain the rear and not the most entertaining. Now while 3.8 is not quite finished (see our other emails on the release planning), we feel like we're on the home stretch now. Which means, it's time to think about other changes to modernize GNU Radio and keep it relevant, modern, and powerful. In the last 6 months, I've had many conversations with developers within and around the GNU Radio community, and there's a lot of things that people want to happen. Heterogeneous computing, better streaming performance, ... there's so much we could do. To create a solid base for all of this, I've submitted four GREPs that have fallen out of various conversations. They are all in "Draft" stage, which means they're totally open for debate. We could decide to not implement any of those, but then at least we'll have come to that conclusion in a constructive fashion, and it will be documented in the GREPs system. Here they are: GREP 13: Remove log4cpp GREP 14: Create blocktool, a header parsing library for GR blocks GREP 15: Remove SWIG and replace it with ??? GREP 16: Separate the scheduler and the base GNU Radio components into separate in-tree modules to make the scheduler pluggable This thread is not a great place to discuss them, I'll start another thread for each one here. Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GREP] Remove log4cpp
This GREP was recently submitted here: https://github.com/gnuradio/greps/blob/master/grep-0013-remove-log4cpp.md We may or may not go through with this. However, we like to kill dependencies (hey there node.js developers :D ), and log4cpp has some issues of its own that we're currently inheriting. Personally, I use GR logging only for debugging purposes. But I know that others use it for other reasons, and this thread is a good place to discuss: - Alternatives to log4cpp (I've listed Boost.Log and hand-spun as options) - What people need it for - Is the current logging in a good shape as it is - Who wants to own this task? - etc. Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GREP] Create blocktool, a header parsing library
Hi all, here's another GREP: https://github.com/gnuradio/greps/blob/master/grep-0014-blocktool.md This is probably the least controversial. It might even be a good GSoC project! Go check it out, and let us know what you think. Comments, suggestions? -- Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files
Hi all, final GREP of the day: https://github.com/gnuradio/greps/blob/master/grep-0016-separate-scheduler.md This is possible the most fundamental and influential GREPs that were added so far. I would find it hard to find any reasons not to do this -- of course, the question remains, who will do it. Any takers? I'm hoping that by separating scheduler from base, we can open up the avenue for more and better research into scheduling, as well as custom scheduler development. Discuss! -- Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GREP] Replace SWIG
Hi all, https://github.com/gnuradio/greps/blob/master/grep-0015-remove-swig.md this might be the craziest GREP yet: How about we kill SWIG as a dependency? Note: We don't want to remove functionality, and we love our Python bindings. But, could we do better? SWIG slows down our compilers, creates hundreds of kB of source code, and we don't really know what it does. On the other hand, that's because it solves a very complex problem: We point it at headers, and it auto-creates Python libraries for us. And of course, changing this would most likely cause some code to become no longer compatible with GNU Radio. Discuss! -- Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
