[Discuss-gnuradio] Writing own blocks
Hi everyone I need to write a custom block or two. I went through the tutorial on the gnuradio website. This only outlines the basics. What I want to do is to implement a polyphase filterbank channeliser that takes in an input stream an breaks it up into a number of channels. I should then be able to select the channel that I want by passing it as a parameter to the new block in a gnuradio application. Does anyone have any recommendations on code that I can look at to help me? How does history in filters work in gnuradio blocks? Thanks a lot. Sebastiaan -- Sebastiaan Heunis Radar and Remote Sensing Group, University of Cape Town Tel: +27 83 305 5667 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
- Start Original Message - Sent: Mon, 29 Dec 2008 22:53:06 -0500 From: "Eric A. Cottrell" To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Intel Atom is NICE. > Hello, > > I bought the earlier version of the motherboard with just the 10/100 > ethernet. I put it in a MI-100 case and it is a nice little system. I > have not gotten a chance to use it with GNURadio much so I have not > commented about it on the list. I am thinking of using it as a car > computer. - End Original Message - Hello, I did not realize that the D945GCLF2 has the new Atom 330 dual core processor. It should work even better than the earlier D945GCLF board or netbook that I used. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP repair - lifted pad - looking for signal
Bob Cameron wrote: I have just replaced the DX2 chip and in the process lifted two pads. They are pins 25 (T2) and 86 (PE0). Looking at the cct diags that one can get from the cvs it appears that pin 25 is not connected to anything else but 86 should be. (By the square blob on the end of the signal wire) I cant however find any reference to that signal on any of the usr cct diagrams.. The netlist shows it has no connection elsewhere .. I dont quite know what to believe... Can anyone tell me if indeed PE0 goes anywhere? PE0 through PE2 are unused. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP repair - lifted pad - looking for signal
I have just replaced the DX2 chip and in the process lifted two pads. They are pins 25 (T2) and 86 (PE0). Looking at the cct diags that one can get from the cvs it appears that pin 25 is not connected to anything else but 86 should be. (By the square blob on the end of the signal wire) I cant however find any reference to that signal on any of the usr cct diagrams.. The netlist shows it has no connection elsewhere .. I dont quite know what to believe... Can anyone tell me if indeed PE0 goes anywhere? Tnxs Bob VK2YQA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] preferences in conf.d issues
Hi All, I have been struggling with the strange behaviour of the configuration files in /usr/local/etc/gnuradio/conf.d This is the place where the following files with gnuradio user preferences live: gnuradio-core.conf gr-audio-jack.conf gr-wxgui.conf gr-audio-alsa.conf gr-audio-oss.conf WHen trying some settings out, I backuped the original file gr-wxgui.conf to gr-wxgui.conf.orig and changed settings in gr-wxgui.conf Whatever I filled in, the old values where still used. It took me a while to find out that the filenames aren't even looked at. They are all read in by gnuradio/gr/prefs.py with the following code: def _sys_prefs_filenames(self): dir = _sys_prefs_dirname() try: fnames = os.listdir(dir) except (IOError, OSError): return [] fnames.sort() return [os.path.join(dir, f) for f in fnames] def _read_files(self): filenames = self._sys_prefs_filenames() filenames.append(_user_prefs_filename()) #print "filenames: ", filenames self.cp.read(filenames) What this comes down to that ALL files in conf.d are read in in alphabetical order. The last file read in overrides all values from the previous files. I don't know if this is documented somewhere, but it is something to be aware about. Don't make backup copies in conf.d But that is not all. I had already found out previously that the inline comments in the pref files prevent the settings from being read. For example in gr-wxgui.conf is: [wxgui] style = auto # 'gl', 'nongl', or 'auto' fft_rate = 10 # fftsink and waterfallsink frame_decim = 1 # scopesink The value the code gets for fft_rate is then: "10 # fftsink and waterfallsink" This gives an error because the code expects only a number. 10 Because of the error the build-in default of 15 will still be used. What would work is the following: #style = auto #'gl', 'nongl', or 'auto' #fft_rate = 15#fftsink and waterfallsink #frame_decim = 1 # scopesink [wxgui] style = auto fft_rate = 10 frame_decim = 1 The uncommented lines before [wxgui] function only as documentation The lines after [wxgui] are the actual settings, no #comments allowed. The same problems are in gr-audio-alsa.conf and maybe others Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduler Help/Question
On Wed, Dec 31, 2008 at 12:32:45PM -0800, Earle Frank wrote: > > Okay I am using the default scheduler. So now I have enabled the logging for > the appropriate thread-per-block scheduler files. > > Here's the heart of my problem. My flow graph has five blocks, A, B, C, D, > E. > Output of A is input to B and C. > Output of C is input to D. > Output of B and D are input to E. > > Block A is a file source. > > Block B has a 1-to-1 input to output function. > > Block C breaks the samples from A into partitions of N samples. The block > does its function over the N samples. Then it outputs the resulting N > values. > > Block D looks at the input and produces an enable signal. The curious > feature, due to implementation, is that this block will only output the > enable signal high once it detects the enable going back low. > > Block E takes the inputs from B and D and only outputs the values of B when > D (the enable) is high. The bug is that D should always produce an enable output, 1:1 with the input. If you're not sure of the state at start up time, output a reasonable default value. > Running this flow graph hangs. Looking at the log files produced for each > block I see that blocks A & B are BLKD_OUT and blocks C, D & E are BLKD_IN. What's happening is that the buffer between B & E is filling, then between A & B fills, then A blocks and the everything hangs because D isn't outputting the enable/not-enable signal. > In this scenario, an enable signal will exist over a partition boundary, say > starts at N-10 and ends at N+10. > > At the point of hanging: > Block A has produced N values. > Block B has consumed N values and produced N values. > Block C has consumed N values and produced N values. > Block D has consumed N values and produced N-10 values. > Block E has consumed N-10 values. > > If only block A would produce the next N values the system would chug along. > To those smarter than I, is there anything obvious as to why this is > stalling the flow graph? > How does the buffers work in this case? > Block C's input buffer is empty and ready. > Block B has 10 values left in it's output buffer, but shouldn't it be able > to produce more outputs? > > > Thanks again in advance, > EF Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
