Re: [Discuss-gnuradio] Sharing variable
Hello Marcus, In your original reply you said that variable sharing was a python concept, So I wrote my block in python. I would like to do something like the block "variable" or the "probe signal" block that shares a variable will all blocks in GNUradio I want to do a block that changes the samp_rate or the center frequency automatically if a condition is true inside my block. Thanks Luis 2015-05-26 8:37 GMT+02:00 : > Hi Marcus, > > An example I can think of is let's say there's a channel estimation block > followed by an equalizer block. > > Let's say the channel estimator estimates the channel by looking for a > training sequence in the incoming data. Once it finds the training sequence > it needs to transfer the data into the equalizer which it will through its > output port. > > But how is the channel vector sent to the equalizer? Its not going to be a > constant stream, it may just be a fixed vector of so and so number of taps. > Is there a way to make the equalizer see this channel vector? > > Thanks > Anil > > ___ > 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
Re: [Discuss-gnuradio] Sharing variable
Hi Marcus, An example I can think of is let's say there's a channel estimation block followed by an equalizer block. Let's say the channel estimator estimates the channel by looking for a training sequence in the incoming data. Once it finds the training sequence it needs to transfer the data into the equalizer which it will through its output port. But how is the channel vector sent to the equalizer? Its not going to be a constant stream, it may just be a fixed vector of so and so number of taps. Is there a way to make the equalizer see this channel vector?ThanksAnil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sharing variable
Hi Luis, as I said in my original reply, there's no direct way to "share" variables. Maybe you'd want to specify or give an example of what exactly you want to do. Best regards, Marcus On 05/25/2015 10:47 PM, Luis urday wrote: > Hello > > I would like to share a variable "X" from my python block to any > other block in GNU radio. > > How could i do that ? > > Thanks > > Luis > > > ___ > 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
Re: [Discuss-gnuradio] BPSK output abnormal
Oh sorry I forgot to reply to all. Now there's a new problem. I use Packet Encoder to add preamble, the setting is: Encoder - sps = 2 - bps = 1 (bpsk) - preamble = 101001000010 - access code = 101011001101110110100100111000100010100011101100 - pad for USRP = no - payload strength = 16 Decoder - access code = 101011001101110110100100111000100010100011101100 - threshold = -1 both access code and preamble are from http://gnuradio.org/doc/sphinx-3.7.2/digital/pkt_utils.html The output now become 0kB On Mon, May 25, 2015 at 10:09 PM, Tom Rondeau wrote: > On Sun, May 24, 2015 at 4:25 PM, Surya Agam > wrote: > >> Oh thank you Tom, I can recover the file size. About frame synchronization, >> am I need Polyphase Clock Sync Block? And also I have no idea about "You >> can zero-pad the input to "push" the samples through."? >> > > (please keep emails on the mailing list) > > The PFB clock sync handles symbol synchronization -- it finds where the > bits are. You'll need another level of synchronization to find the start of > the frame, usually by looking for a known start pattern, preamble, etc. > > And there are many ways to accomplish the zero-padding. I'll leave that up > to you to figure out :) > > Tom > > > > >> On Mon, May 25, 2015 at 12:34 AM, Tom Rondeau wrote: >> >>> On Sun, May 24, 2015 at 4:54 AM, Surya Agam >>> wrote: >>> Hi everyone, I try to simulate file transfer using BPSK with block diagram File Source --> PSK Mod --> PSK Demod --> File Sink The block setting is File Source : -file type = .jpg (282,8 kB (282.765 bytes)) -repeat = no -vec length = 1 PSK Mod : -num of constellation = 2 -gray code = yes -diff. encoding = yes -sample/symbol = 2 -excess BW = 0.35 -verbose = off =log = off PSK Demod : -num of constellation = 2 -diff. encoding = yes -sample/symbol = 2 -excess BW = 0.35 -frequency BW = 6.28/100.0 -timing BW = 6.28/100.0 -phase BW = 6.28/100.0 -gray code = yes -verbose = off -log = off File Sink -vec length = 1 -unbuffered = on -append file = overwrite The size of input file = 282,8 kB (282.765 bytes) but the size of output file = 2,3 MB (2.262.066 bytes) What's wrong with my fg? Thank you, Surya Agam >>> >>> >>> The output is unpacked. So each sample only represents a single bit. You >>> have to repack them into 8 bits per byte, but you'll also need to know >>> where to start through some kind of frame synchronization. >>> >>> 282765*8 = 2262120 >>> >>> The rest of the difference is due to delays in the filters. You can >>> zero-pad the input to "push" the samples through. >>> >>> Tom >>> >>> >>> >>> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Notion of buffering up input data in GNURadio
Hi Marcus, Thanks for your reply. > So, you're writing that application and ask us how your buffering works? > that doesn't sound right, so maybe I'm misunderstanding you? My bad. What I meant to say was the block that I NEED to implement involves a fixed number of samples that I need to collect (as long as they are available) and then start processing those (in my case it is a sliding window). > I think you should really read the guided tutorials I've linked to in my > last email; you're trying to replicated functionality that is central to > GNU Radio. > GNU Radio cares for your block's in- and output buffers. Unless your > work explicitly consumes input items (e.g. by returning a positive > number), GNU Radio accumulates the samples in your input buffer. I have been through most of the tutorials. I merely want to make sure I understand them right. I do understand you may have answered the same questions lots of times before. Apologies for that :-) > Don't you care, GNU Radio does that for you! > When your work() is called, GNU Radio knows how many items you can > consume (from the input) and how many you can produce (on the output) -- It knows because that is what I specify in the forecast function (for a general block) am I correct? > your job as a developer is just writing an algorithm that can work on an > array of samples that lies sequentially in memory. So in my case, if I have a sliding window based avg power calculation where I first buffer up some samples, then calculate power in each window and compare it to threshold. If in a particular window power < threshold, is there a way to get GNURadio to immediately replace that window with new data while I slide through the rest of the input items? > If you know how much items you need at once (e.g. you always need 127) > you can use set_output_multiple (which will inherently set the input > multiple on a sync block, i.e. any block with a work(), not a > general_work()), and GNU Radio will only call you if there's at least > 127 items of input. I understand what you're saying here. > Whilst your block is working on its input, new input might already occur > from the block upstream -- that's no problem at all (in fact, it's > what's pretty awesome about the current GNU Radio scheduler). Right > after your current work() call is finished (i.e. has "return"ed), work() > will be called again, with whatever you left untouched of the input from > last time plus the new items. I also understand this. Only question is like I asked above, is there a way to update new samples in a dynamic way instead of waiting for work to return something? A case where this might be needed is, if my power never exceeds the threshold, then nothing will (should) be returned at all. I am happy to explain further, what i'm trying to implement if necessary. Thanks for your time Anil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sharing variable
Hello I would like to share a variable "X" from my python block to any other block in GNU radio. How could i do that ? Thanks Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Notion of buffering up input data in GNURadio
Hi Anil On 05/25/2015 09:03 AM, yanilkumar2...@gmail.com wrote: > > I have a block that involves collecting samples in a buffer, once > buffer is full, start processing the data (slide a window over it etc > etc). > > My question is how does this whole concept of buffering work? So, you're writing that application and ask us how your buffering works? that doesn't sound right, so maybe I'm misunderstanding you? > Can I say I need len(buffer) number of samples (assuming that buffer > is the name of the array over which I slide my window etc) in the > forecast function and then just copy input_items[0] into buffer in > every work call? What if in some iterations I don't need to copy > len(buffer) elements? For example if I only need to copy one or two > window lengths worth data while other windows are still under process. > Can I still do that? I think you should really read the guided tutorials I've linked to in my last email; you're trying to replicated functionality that is central to GNU Radio. GNU Radio cares for your block's in- and output buffers. Unless your work explicitly consumes input items (e.g. by returning a positive number), GNU Radio accumulates the samples in your input buffer. > > My second question is, how do I account for the data that comes in > while I'm still processing data in buffer? Do I need a second buffer > to accumulate subsequent data while processing buffer is full? Don't you care, GNU Radio does that for you! When your work() is called, GNU Radio knows how many items you can consume (from the input) and how many you can produce (on the output) -- your job as a developer is just writing an algorithm that can work on an array of samples that lies sequentially in memory. If you know how much items you need at once (e.g. you always need 127) you can use set_output_multiple (which will inherently set the input multiple on a sync block, i.e. any block with a work(), not a general_work()), and GNU Radio will only call you if there's at least 127 items of input. Whilst your block is working on its input, new input might already occur from the block upstream -- that's no problem at all (in fact, it's what's pretty awesome about the current GNU Radio scheduler). Right after your current work() call is finished (i.e. has "return"ed), work() will be called again, with whatever you left untouched of the input from last time plus the new items. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Conditional execution of work function
Hi Anil, On 05/25/2015 09:03 AM, yanilkumar2...@gmail.com wrote: > > Or does GNURADIO already do this? exactly that's the core job of GNU Radio :) Whenever there's new samples to be processed, your work gets called. If you haven't seen them, I'd like to point you at the Guided Tutorials [1], these should explain core concepts quite well! Best regards, Marcus [1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] sharing variable
Hi Luis, I think you might be referring to the concept of GNU Radio Companion's variables; since that is a pure python concept, there's no easy way to do this in C++ (you'd simply lack the python glue). Typically, you'd use message passing to asynchronously exchange information between blocks, or you'd directly call appropriate get/set methods on the other blocks. Best regards, Marcus PS: GNU Radio has its own mailing list, which I included in CC:; I'd recommend signing up for it and continuing this discussion there, as it is pretty unrelated to the USRPs. https://lists.gnu.org/mailman/listinfo/discuss-gnuradio On 05/25/2015 05:17 PM, Luis urday via USRP-users wrote: > Dear, > > I would like to share a variable "X" from my block in C++ to others > blocks in GNU radio. > > How could I do that? > > Thanks > > Luis > > > ___ > USRP-users mailing list > usrp-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK output abnormal
On Sun, May 24, 2015 at 4:25 PM, Surya Agam wrote: > Oh thank you Tom, I can recover the file size. About frame synchronization, > am I need Polyphase Clock Sync Block? And also I have no idea about "You > can zero-pad the input to "push" the samples through."? > (please keep emails on the mailing list) The PFB clock sync handles symbol synchronization -- it finds where the bits are. You'll need another level of synchronization to find the start of the frame, usually by looking for a known start pattern, preamble, etc. And there are many ways to accomplish the zero-padding. I'll leave that up to you to figure out :) Tom > On Mon, May 25, 2015 at 12:34 AM, Tom Rondeau wrote: > >> On Sun, May 24, 2015 at 4:54 AM, Surya Agam >> wrote: >> >>> Hi everyone, >>> >>> I try to simulate file transfer using BPSK with block diagram >>> >>> File Source --> PSK Mod --> PSK Demod --> File Sink >>> >>> The block setting is >>> File Source : >>> -file type = .jpg (282,8 kB (282.765 bytes)) >>> -repeat = no >>> -vec length = 1 >>> >>> PSK Mod : >>> -num of constellation = 2 >>> -gray code = yes >>> -diff. encoding = yes >>> -sample/symbol = 2 >>> -excess BW = 0.35 >>> -verbose = off >>> =log = off >>> >>> PSK Demod : >>> -num of constellation = 2 >>> -diff. encoding = yes >>> -sample/symbol = 2 >>> -excess BW = 0.35 >>> -frequency BW = 6.28/100.0 >>> -timing BW = 6.28/100.0 >>> -phase BW = 6.28/100.0 >>> -gray code = yes >>> -verbose = off >>> -log = off >>> >>> File Sink >>> -vec length = 1 >>> -unbuffered = on >>> -append file = overwrite >>> >>> The size of input file = 282,8 kB (282.765 bytes) >>> but the size of output file = 2,3 MB (2.262.066 bytes) >>> >>> What's wrong with my fg? >>> >>> Thank you, >>> Surya Agam >>> >> >> >> The output is unpacked. So each sample only represents a single bit. You >> have to repack them into 8 bits per byte, but you'll also need to know >> where to start through some kind of frame synchronization. >> >> 282765*8 = 2262120 >> >> The rest of the difference is due to delays in the filters. You can >> zero-pad the input to "push" the samples through. >> >> Tom >> >> >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] alsa problem
On Mon, May 25, 2015 at 6:15 AM, Andreas Ladanyi wrote: > Hi together, > > i am using grc 3.7.6.1. The system is odroid with ubuntu 14. I tested the > alsa system with aplay and the sound works. > > When i start my project on odroid i get the following error message. On > my desktop pc with grc 3.7.2.1 / ubuntu 14 the grc alsa works. > > > INFO: Audio sink arch: alsa > ERROR: [default]: snd_pcm_hw_params failed: Invalid argument > Traceback (most recent call last): > File "/home/odroid/gr-rds-master_rds2/apps/rds_rx.py", line 421, in > > tb.Start(True) > File > "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", > line 73, in Start > self.start() > File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", > line 106, in start > top_block_start_unlocked(self._impl, max_noutput_items) > File > "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line > 4742, in top_block_start_unlocked > return _runtime_swig.top_block_start_unlocked(*args, **kwargs) > RuntimeError: check topology failed on audio_alsa_sink(54) using > ninputs=2, noutputs=0 > > > Andy ideas ? Thanks in advance. > > cheers, > Andy > It would be helpful here to see the flowgraph you're working on. The error is related to the blocks and how you connected them up. The audio sink, in this case, is having a problem with the input connections you're giving it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to "declare_sample_delay" in C++?
Hi Martin, Thanks for the answer. My confusion is that when you generate, for example, a multi-stage polyphase decimator in GRC, a 'declare_sample_delay(0)' code will be generated for each decimation block. When I go from Python to C++ I thought I should do the same. Now, since the default is zero, does that mean the 'declare_sample_delay(0)' codes generated by GRC are redundant? Thank you. Best wishes, Khalid > Message: 7 > Date: Fri, 22 May 2015 12:00:39 -0700 > From: Martin Braun > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] How to "declare_sample_delay" in C++? > Message-ID: <555f7cd7.2040...@ettus.com> > Content-Type: text/plain; charset=windows-1252 > > Not sure what you're asking, the command is wrapped from C++ to Python, > and hence the same in both domains (see also > > http://gnuradio.org/doc/doxygen/classgr_1_1block.html#acad5d6e62ea885cb77d19f72451581c2 > ). > > Also, 0 is the default. > > M > > On 22.05.2015 11:26, khalid.el-darymli wrote: > > Hi list, > > > > I am doing some (polyphase) decimation with GNURadio in C++. I > > constructed my filters, I wrote some wrapper, and my script compiles > > perfectly. However, I am a bit unclear about "declare_sample_delay". > > > > Assume that I have the block: pfb_decimator_ccf_0_5. To set the sample > > delay for this block to 0, in python, one uses: > > > > self.pfb_decimator_ccf_0_5.declare_sample_delay(0) > > > > > > What is the proper way to do the same command in C++? > > > > > > Thanks in advance. > > > > Best wishes, > > Khalid > > > > > > > > ___ > > 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
Re: [Discuss-gnuradio] grc - libGL error: failed to load driver: i965
I think i solved the problem with the slow windows a little. The reason was the armsoc driver of the X Server. This driver was configured in the xorg.conf. There was another file named xorg.conf.mali which contains parameter to use the mali driver. I renamed the both xorg files so the file with the mali driver could be load instead of the armsoc driver. The reaction of all windows / textboxes / sliders are better. This problem was not only with the gnuradio guis instead it was a general problem. The libgl error is always present. Am 18.05.2015 um 15:06 schrieb Andreas Ladanyi: Hi, when i want to start a grc project i get the error message: libGL error: failed to load driver: i965 Iam working on odroid (MALI 400 GPU) 3 with Ubuntu 14 and i start the grc via ssh and X-Forwarding on my PC. The grc project i want to start and run on the odroid works great and the cpu load is about 50 % on all 4 cores. But the wx gui graphs and sliders etc. are very slow / not responding. The editing operations in the grc editor GUI are also slow (but thats no problem for me because iam developing on a pc). I read that this could be a problem with the mali graphical driver and the OpenGL/OpenGLES but iam not familar with the details and how to fix them for gnuradio. Could you give me help, please ? cheers, Andy ___ 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] alsa problem
Hi together, i am using grc 3.7.6.1. The system is odroid with ubuntu 14. I tested the alsa system with aplay and the sound works. When i start my project on odroid i get the following error message. On my desktop pc with grc 3.7.2.1 / ubuntu 14 the grc alsa works. INFO: Audio sink arch: alsa ERROR: [default]: snd_pcm_hw_params failed: Invalid argument Traceback (most recent call last): File "/home/odroid/gr-rds-master_rds2/apps/rds_rx.py", line 421, in tb.Start(True) File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 73, in Start self.start() File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 106, in start top_block_start_unlocked(self._impl, max_noutput_items) File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4742, in top_block_start_unlocked return _runtime_swig.top_block_start_unlocked(*args, **kwargs) RuntimeError: check topology failed on audio_alsa_sink(54) using ninputs=2, noutputs=0 Andy ideas ? Thanks in advance. cheers, Andy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Notion of buffering up input data in GNURadio
I have a block that involves collecting samples in a buffer, once buffer is full, start processing the data (slide a window over it etc etc). My question is how does this whole concept of buffering work? Can I say I need len(buffer) number of samples (assuming that buffer is the name of the array over which I slide my window etc) in the forecast function and then just copy input_items[0] into buffer in every work call? What if in some iterations I don't need to copy len(buffer) elements? For example if I only need to copy one or two window lengths worth data while other windows are still under process. Can I still do that?My second question is, how do I account for the data that comes in while I'm still processing data in buffer? Do I need a second buffer to accumulate subsequent data while processing buffer is full? Thanks for your timeAnil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Conditional execution of work function
HelloJust like how we use while 1 for something to execute infinite times, is there something like that for the work function? I may not need to execute it infinite times but let's say I'm receiving data through a USRP, can I have a condition that says, While USRPIsOn or While input data is available (noise or otherwise) Keep executing work. Or does GNURADIO already do this? If it does, could someone provide me with a brief insight on how this works? ThanksAnil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
