Re: [Discuss-gnuradio] Thread Safety
On Mon, Feb 28, 2005 at 02:09:02AM -0500, Krzysztof Kamieniecki wrote: > > Eric Blossom wrote: > > > I was thinking about something slightly more complicated, with a set of > shadow data members that would be protected by the mutex, and copied to the > normal data members at the top of the work method when the flag is > triggered. That way the mutex would only be used if the flag is set. > Something like this. This all looks good. > > I had noticed the development in CVS. Having a gr_msg_queue in each block > may cause some problems for me down the line unless there is a way to > guarantee that the messages are processed in a specific order, but it's > something that I could work around. > Do or could the messages have a timestamp indicating when they should be > performed? I was thinking along the line of a timer that sends "Timer Fired" messages to whoever you want when you want. If it seems more useful to queue up an arbitrary message for delivery in the future, we could implement that. I thought that the message queue per block would simplify matters when dispatching messages for the block. I figured on processing pending messages for each block just before the scheduler called forecast. This would ensure that for each run through the scheduler loop, all messages pending for a given block were processed just before calling forecast/work. Does this sound like it will take care of your needs? You may have noticed that gr_msg_queue is derived from gr_msg_handler. I figured this would give us the flexibility to write arbitrary message handling code that runs at message send time if we needed it. This would correspond to Click's "push" based processing model. I suspect that for most cases the message queue is the right answer (at least for blocks), since it gives a simple way to hide the concurrency issues from the block. We could certainly do both the per block message queue and the "please send this message at Time X" message queue. I also figured on supporting message send on "select" events too. Comments? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FSK now (really) working at 100kbit/sec
Matt and I spent some time looking at the FSK code over the weekend. I made a couple of changes: reduced the gain in the tx module, fixed the problem in gr_simple_correlator.cc that was having it return after processing only a single sample (ooops!), and added a -N option (no graphs) to fsk_tx.py and fsk_rx.py. Two of these changes reduce CPU consumption. The other avoids causing overflow in the FPGA. Here was my test setup: - updated gnuradio-core and gnuradio-examples from CVS. - 1.4 GHz Pentium M laptop, Mandrake 10.1, 2.6.8 kernel. - USRP with an SMA cable connected between one Basic Tx output and one Basic Rx input (both on the A side; SMA connector closest to the corner). - I ran these commands in different windows: $ ./fsk_rx.py -f /dev/null -c 10M -r 100k -N $ ./fsk_tx.py -f /boot/vmlinuz -R -c 10M -r 100k -N In the rx window I'd get "seqno NNN" with increasing contiguous sequence numbers. If this is still burning too much CPU on your system, try dropping down to "-r 50k" This will drop to 50kbit/sec. Running at 100 kbit/sec used about 70% of the CPU; 50kbit/sec used 35%. The primary bottleneck is in the rx path and is in the generic (C++) implemenation of gr_fir_ccf. We could use a SIMD version of this filter primitive (and/or a smarter demod implementation). I suspect that 1Mbit/sec is doable with some algorithmic changes. We're currently running the receiver with 8x oversampling. In the absence of any kind of channel coding, we should probably add at least a CRC to the packets. Bob, I suspect that your socket puzzle is resolved too. The problem where the correlator was only processing a single sample would have caused the behavior you were seeing. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
Hi, I'm using the latest version of wxpython. I have tried removing python completely and reinstall again. But still i'm having same error: File "/usr/local/lib/python2.3/site-packages/gnuradio/wxgui/fftsink.py", line 89, in ? EVT_DATA_EVENT = wx.PyEventBinder (myDATA_EVENT, 0) AttributeError: 'module' object has no attribute 'PyEventBinder' Any way to get around the problem? Thank you, Raja >hey, i had that error after i installed >wxpython-2.5.3.1 over the other version. >try removing wxpython and wxGTK and then installing >them again. then re-emerge numeric and numarray. >mj --- Rahul Dhar <[EMAIL PROTECTED]> wrote: > On Tue, Feb 15, 2005 at 04:09:44AM -0800, mj wrote: > > > > > Are you using wxPython 2.5.2.7 or later? > > > > yup i am now. i upgraded from wxpython-2.4 to > > wxpython-2.5.3.1 > > I'm using wxPython 2.5.3.1 on top of wxGTK 2.5.3 > (dependency in Gentoo, > apparntly) and Python 2.3.4. When I run "python > fftsink.py" I'm > getting the error below. Is fftsink.py even > something I should be > running by itself? > > Traceback (most recent call last): > File "./fftsink.py", line 24, in ? > from gnuradio.wxgui import stdgui > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/stdgui.py", > line 24, in ? > import wx > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", > line 45, in ? > > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", > line 20, in ? > > ImportError: No module named wxc > > Am I missing something? $PYTHONPATH includes > /opt/gnuradio/lib/python2.3/site-packages/gnuradio > > Unfortunately, I don't know Python, and no one here > does either. The > non-GUI examples work fine, though. > > -Rahul > -- > Rahul Dhar > [EMAIL PROTECTED] > Actually, my goal is to have a sandwich named after > me. > > ATTACHMENT part 2 application/pgp-signature = mj - m0mik hotstudent.com [are you hot enough?!] __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ___ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
On Mon, Feb 28, 2005 at 09:08:01AM -0800, Rajaprabhu T.L. wrote: > Hi, > > I'm using the latest version of wxpython. I have tried > removing python completely and reinstall again. > > But still i'm having same error: > > File > "/usr/local/lib/python2.3/site-packages/gnuradio/wxgui/fftsink.py", > line 89, in ? > EVT_DATA_EVENT = wx.PyEventBinder (myDATA_EVENT, > 0) > AttributeError: 'module' object has no attribute > 'PyEventBinder' > > Any way to get around the problem? > > Thank you, > Raja > > > > >hey, i had that error after i installed > >wxpython-2.5.3.1 over the other version. > > >try removing wxpython and wxGTK and then installing > >them again. then re-emerge numeric and numarray. > > >mj My guess is that you still have a 2.4 wxPython installation interfering with the 2.5 installation. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [opensdr] Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
Hi Eric, I installed wxpython only couple of weeks before. It was 2.5 version. There is no other version of wxpython in the system. Raja --- Eric Blossom <[EMAIL PROTECTED]> wrote: > On Mon, Feb 28, 2005 at 09:08:01AM -0800, Rajaprabhu > T.L. wrote: > > Hi, > > > > I'm using the latest version of wxpython. I have > tried > > removing python completely and reinstall again. > > > > But still i'm having same error: > > > > File > > > "/usr/local/lib/python2.3/site-packages/gnuradio/wxgui/fftsink.py", > > line 89, in ? > > EVT_DATA_EVENT = wx.PyEventBinder > (myDATA_EVENT, > > 0) > > AttributeError: 'module' object has no attribute > > 'PyEventBinder' > > > > Any way to get around the problem? > > > > Thank you, > > Raja > > > > > > > > >hey, i had that error after i installed > > >wxpython-2.5.3.1 over the other version. > > > > >try removing wxpython and wxGTK and then > installing > > >them again. then re-emerge numeric and numarray. > > > > >mj > > My guess is that you still have a 2.4 wxPython > installation > interfering with the 2.5 installation. > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Re: FSK now (really) working at 100kbit/sec
Subject: Re: FSK now (really) working at 100kbit/sec Matt and I spent some time looking at the FSK code over the weekend. Thanks. The gr_simple_correlator fix makes it work a lot better. I made a couple of changes: reduced the gain in the tx module, fixed the problem in gr_simple_correlator.cc that was having it return after processing only a single sample (ooops!), and added a -N option (no graphs) to fsk_tx.py and fsk_rx.py. Two of these changes reduce CPU consumption. The other avoids causing overflow in the FPGA. Here was my test setup: - updated gnuradio-core and gnuradio-examples from CVS. - 1.4 GHz Pentium M laptop, Mandrake 10.1, 2.6.8 kernel. - USRP with an SMA cable connected between one Basic Tx output and one Basic Rx input (both on the A side; SMA connector closest to the corner). - I ran these commands in different windows: $ ./fsk_rx.py -f /dev/null -c 10M -r 100k -N $ ./fsk_tx.py -f /boot/vmlinuz -R -c 10M -r 100k -N In the rx window I'd get "seqno NNN" with increasing contiguous sequence numbers. CPU problem also seems fixed. HOWEVER, there still seems to be a problem with the USRP decimating filter. It is more apparent if the data going in is all zeros or ones, but the same thing happens as before. Takes longer for the sidebands to build up, but it's the same problem. I tried cutting back by another factor of 4 with the same result. I think that perhaps the FIR taps aren't set quite right. The new version with the correlator fix runs for several minutes, but the receiver gives bursts of errors. Impossible to tell if it's single bit drops because once a bit drops the sync is thrown off until the next header comes. The situation improves some drop data rate. Also running small frames (16 bytes per). If this is still burning too much CPU on your system, try dropping down to "-r 50k" This will drop to 50kbit/sec. Running at 100 kbit/sec used about 70% of the CPU; 50kbit/sec used 35%. The primary bottleneck is in the rx path and is in the generic (C++) implemenation of gr_fir_ccf. We could use a SIMD version of this filter primitive (and/or a smarter demod implementation). I suspect that 1Mbit/sec is doable with some algorithmic changes. We're currently running the receiver with 8x oversampling. In the absence of any kind of channel coding, we should probably add at least a CRC to the packets. Bob, I suspect that your socket puzzle is resolved too. The problem where the correlator was only processing a single sample would have caused the behavior you were seeing. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Makefile.in
FYI, I just did a clean CVS checkout. The directories don't have Makefile.in, so I copied from the versions in the tarfiles. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [opensdr] Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
On Mon, Feb 28, 2005 at 11:10:45AM -0800, Rajaprabhu T.L. wrote: > Hi Eric, > > I installed wxpython only couple of weeks before. It > was 2.5 version. There is no other version of wxpython > in the system. > > Raja OK. Can you try this experiment for me? $ python Python 2.3.4 (#2, Aug 19 2004, 15:49:40) [GCC 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import wx >>> print wx.__version__ 2.5.3.1 >>> wx.PyEventBinder >>> 2.5.2.7 is the lowest version that we support. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Re: FSK now (really) working at 100kbit/sec
On Mon, Feb 28, 2005 at 02:28:50PM -0500, Bob Vincent wrote: > > >Subject: Re: FSK now (really) working at 100kbit/sec > >Matt and I spent some time looking at the FSK code over the weekend. > > Thanks. The gr_simple_correlator fix makes it work a lot better. > > CPU problem also seems fixed. Good. > HOWEVER, there still seems to be a problem with the USRP decimating filter. > It is more apparent if the data going in is all zeros or ones, but the same > thing happens as before. > Takes longer for the sidebands to build up, but it's the same problem. I > tried cutting back by another factor of 4 with the same result. OK. I see what you're talking about. Running all ones or zeros into the Tx has the sidebands displayed on the Tx Post Modulation FFT move around quite a bit over time with occaisional discontinous jumps. I'll check it out. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Makefile.in
Quoting Bob Vincent <[EMAIL PROTECTED]>: > FYI, I just did a clean CVS checkout. The directories don't have > Makefile.in, so I copied from the versions in the tarfiles. When using CVS, run ./bootstrap from the top-level directory. That will create the Makefile.in files. Then run ./configure. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Makefile.in
Is this bug driving you crazy yet Eric? ;-) Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bob Vincent Sent: Monday, February 28, 2005 8:08 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Makefile.in FYI, I just did a clean CVS checkout. The directories don't have Makefile.in, so I copied from the versions in the tarfiles. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Makefile.in
On Mon, Feb 28, 2005 at 08:43:02PM -, Robert McGwier wrote: > Is this bug driving you crazy yet Eric? > > ;-) > > Bob Just about ;-) Have you tried Josh Lackey's suggested fix? If so, did it work? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Makefile.in
On Mon, Feb 28, 2005 at 03:07:35PM -0500, Bob Vincent wrote: > FYI, I just did a clean CVS checkout. The directories don't have > Makefile.in, so I copied from the versions in the tarfiles. The Makefile.in's are not kept in CVS. The easiest way is to use gr-build http://comsec.com/wiki?HowtoBuildFromCVS Then you can ./for-all-dirs ../buildit In the meanwhile try this: $ cd gnuradio-core $ ./bootstrap # should generate Makefile.in's $ ./configure $ make Some folks have reported a problem where the Makefile.in's aren't getting built by ./bootstrap. Josh Lackey posted a suggested fix to the list in the last 24 - 48 hrs. If you see the problem where they aren't getting built, can you try his fix and let me know if it works for you. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Makefile.in
On Mon, Feb 28, 2005 at 12:17:15PM -0800, Matt Ettus wrote: > Quoting Bob Vincent <[EMAIL PROTECTED]>: > > > FYI, I just did a clean CVS checkout. The directories don't have > > Makefile.in, so I copied from the versions in the tarfiles. > > > When using CVS, run ./bootstrap from the top-level directory. That will > create > the Makefile.in files. Then run ./configure. The "buildit" script doesn't seem to create Makefile.in. Oddly, if I run each command in buildit individually, everything works out. -- Rahul Dhar [EMAIL PROTECTED] Actually, my goal is to have a sandwich named after me. pgpjRWHF3dtT8.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Re: FSK now (really) working at 100kbit/sec
On Mon, Feb 28, 2005 at 02:28:50PM -0500, Bob Vincent wrote: > > > HOWEVER, there still seems to be a problem with the USRP decimating filter. > It is more apparent if the data going in is all zeros or ones, but the same > thing happens as before. > Takes longer for the sidebands to build up, but it's the same problem. I > tried cutting back by another factor of 4 with the same result. I just checked in a fix for gr_frequency_modulator_fc.cc in gnuradio-core. It fixes a floating point loss-of-precision problem. The sidebands as seen in the Tx Post Modulation display are now 70dB down for the all zero and all one cases. Please let me know if this works better for you. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Missing Makefile.in
Does anyone else have to "./bootstrap" twice in a freshly checked-out tree? I'm wondering if it is just my setup, but I have to "./bootstrap; ./bootstrap" or else the Makefile.in doesn't appear. [EMAIL PROTECTED]:~/src/gnuradio/tmp> cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gnuradio co gnuradio-core cvs checkout: Updating gnuradio-core U gnuradio-core/.buildpri U gnuradio-core/.cvsignore U gnuradio-core/AUTHORS [...] [EMAIL PROTECTED]:~/src/gnuradio/tmp> cd gnuradio-core [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./bootstrap [ delete m4 warnings ] configure.ac: installing `./install-sh' configure.ac: installing `./missing' src/gen_interpolator_taps/Makefile.am: installing `./depcomp' src/lib/swig/Makefile.am:50: installing `./py-compile' configure.ac:24: required file `config.h.in' not found [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./configure checking build system type... x86_64-unknown-linux-gnu [...] config.status: creating Makefile config.status: error: cannot find input file: Makefile.in [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./bootstrap [ delete m4 warnings ] [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./configure checking build system type... x86_64-unknown-linux-gnu [...] config.status: creating Makefile config.status: creating gnuradio-core.pc [...] config.status: executing swig_deps commands [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> If I apply the following patch to "bootstrap", a single pass suffices. *** gnuradio-core-old/bootstrap Mon Feb 28 15:29:38 2005 --- gnuradio-core/bootstrap Sat Apr 10 10:59:35 2004 *** *** 29,37 ( cd $dir aclocal -I config - autoconf - autoheader libtoolize --automake automake --add-missing ) done --- 29,37 ( cd $dir aclocal -I config libtoolize --automake automake --add-missing + autoconf + autoheader ) done -- Joshua Lackey, PhD. -- [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing Makefile.in
Yes, I have to do that with FC3 and the latest patches. It reports the same error you are showing below. On Mon, 28 Feb 2005, Joshua Lackey wrote: > Does anyone else have to "./bootstrap" twice in a freshly checked-out > tree? > > I'm wondering if it is just my setup, but I have to "./bootstrap; > ./bootstrap" or else the Makefile.in doesn't appear. > > [EMAIL PROTECTED]:~/src/gnuradio/tmp> cvs -d :ext:[EMAIL > PROTECTED]:/cvsroot/gnuradio co gnuradio-core > cvs checkout: Updating gnuradio-core > U gnuradio-core/.buildpri > U gnuradio-core/.cvsignore > U gnuradio-core/AUTHORS > [...] > [EMAIL PROTECTED]:~/src/gnuradio/tmp> cd gnuradio-core > [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./bootstrap > [ delete m4 warnings ] > configure.ac: installing `./install-sh' > configure.ac: installing `./missing' > src/gen_interpolator_taps/Makefile.am: installing `./depcomp' > src/lib/swig/Makefile.am:50: installing `./py-compile' > configure.ac:24: required file `config.h.in' not found > [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./configure > checking build system type... x86_64-unknown-linux-gnu > [...] > config.status: creating Makefile > config.status: error: cannot find input file: Makefile.in > [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./bootstrap > [ delete m4 warnings ] > [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./configure > checking build system type... x86_64-unknown-linux-gnu > [...] > config.status: creating Makefile > config.status: creating gnuradio-core.pc > [...] > config.status: executing swig_deps commands > [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> > > > If I apply the following patch to "bootstrap", a single pass suffices. > > *** gnuradio-core-old/bootstrap Mon Feb 28 15:29:38 2005 > --- gnuradio-core/bootstrap Sat Apr 10 10:59:35 2004 > *** > *** 29,37 > ( > cd $dir > aclocal -I config > - autoconf > - autoheader > libtoolize --automake > automake --add-missing > ) > done > --- 29,37 > ( > cd $dir > aclocal -I config > libtoolize --automake > automake --add-missing > + autoconf > + autoheader > ) > done > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing Makefile.in
On Mon, Feb 28, 2005 at 02:32:24PM -0800, Joshua Lackey wrote: > Does anyone else have to "./bootstrap" twice in a freshly checked-out > tree? > > I'm wondering if it is just my setup, but I have to "./bootstrap; > ./bootstrap" or else the Makefile.in doesn't appear. > Yes, others are seeing this problem. I'll apply your patch to all the bootstraps. Thanks, Eric > If I apply the following patch to "bootstrap", a single pass suffices. > > *** gnuradio-core-old/bootstrap Mon Feb 28 15:29:38 2005 > --- gnuradio-core/bootstrap Sat Apr 10 10:59:35 2004 > *** > *** 29,37 > ( > cd $dir > aclocal -I config > - autoconf > - autoheader > libtoolize --automake > automake --add-missing > ) > done > --- 29,37 > ( > cd $dir > aclocal -I config > libtoolize --automake > automake --add-missing > + autoconf > + autoheader > ) > done > > > -- > Joshua Lackey, PhD. -- [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Makefile.in
Same here but I have not tried JL's fix. I missed it somehow but that is what the archive is for! Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rahul Dhar Sent: Monday, February 28, 2005 9:15 PM To: Matt Ettus Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Makefile.in On Mon, Feb 28, 2005 at 12:17:15PM -0800, Matt Ettus wrote: > Quoting Bob Vincent <[EMAIL PROTECTED]>: > > > FYI, I just did a clean CVS checkout. The directories don't have > > Makefile.in, so I copied from the versions in the tarfiles. > > > When using CVS, run ./bootstrap from the top-level directory. That will create > the Makefile.in files. Then run ./configure. The "buildit" script doesn't seem to create Makefile.in. Oddly, if I run each command in buildit individually, everything works out. -- Rahul Dhar [EMAIL PROTECTED] Actually, my goal is to have a sandwich named after me. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Makefile.in
On Mon, Feb 28, 2005 at 11:49:42PM -, Robert McGwier wrote: > Same here but I have not tried JL's fix. I missed it somehow but > that is what the archive is for! > > Bob I've changed all the bootstrap's to use the ordering suggested by JL. Let me know how it goes... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bytes_to_syms
Is "bytes_to_syms" a symbol exported by gr_bytes_to_syms? I'm trying to understand the framing mechanism. Thanks, -Rahul -- Rahul Dhar [EMAIL PROTECTED] Actually, my goal is to have a sandwich named after me. signature.asc Description: Digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Thread Safety
Eric Blossom wrote: > On Mon, Feb 28, 2005 at 02:09:02AM -0500, Krzysztof Kamieniecki wrote: >>Do or could the messages have a timestamp indicating when they should be >>performed? > > > I was thinking along the line of a timer that sends "Timer Fired" > messages to whoever you want when you want. If it seems more useful > to queue up an arbitrary message for delivery in the future, we could > implement that. > I think this will have to take into account timestamped sample buffers you mentioned before. For instance a waveform/protocol may require adjusting gains in the TX/RX path between data packets. > I thought that the message queue per block would simplify matters when > dispatching messages for the block. I figured on processing pending > messages for each block just before the scheduler called forecast. > This would ensure that for each run through the scheduler loop, all > messages pending for a given block were processed just before calling > forecast/work. Does this sound like it will take care of your needs? > > You may have noticed that gr_msg_queue is derived from gr_msg_handler. > I figured this would give us the flexibility to write arbitrary message > handling code that runs at message send time if we needed it. This > would correspond to Click's "push" based processing model. > > I suspect that for most cases the message queue is the right answer > (at least for blocks), since it gives a simple way to hide the > concurrency issues from the block. We could certainly do both the per > block message queue and the "please send this message at Time X" > message queue. I also figured on supporting message send on "select" > events too. > > Comments? > > Eric This sounds good. One additional feature that would be useful is some way to specify that a batch of messages to multiple blocks should be queued in an "atomic" manner, so all of the messages get processed during the same pre-forecast time frame. So for a network analyzer you can send a message to the signal source block and another to the downconverter block to switch frequencies at the same time and maintain their phase relationship. -- Krzysztof Kamieniecki callsign:KB1KLB mailto:[EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
