Hello, With the GIT version of Gnuradio, after,./bootstrap./configure (with or without options), I have this error:"config.status: error: cannot find input file: `gruel/Makefile.in'"
Maybe this error take this source in the ".gitignore" files, I don't know, but all the "Makefile.in" in the [gruel] folder seems to be need for ./configure. Any Ideas? Best, Cosmin > Date: Tue, 20 Oct 2009 12:00:36 -0400 > From: discuss-gnuradio-requ...@gnu.org > Subject: Discuss-gnuradio Digest, Vol 83, Issue 20 > To: discuss-gnuradio@gnu.org > > Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > or, via email, send a message with subject or body 'help' to > discuss-gnuradio-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > > 1. Re: New external clock board for USRP (Alexander Chemeris) > 2. clarification on RFX-2400 (Narayanan, Sivaramasubramanian (R&T)) > 3. Problem new Signal Processing Block (Edmar Candeia Gurj?o) > 4. Problem new Signal Processing Block (Edmar Candeia Gurj?o) > 5. problem about installing hydra (chenchen chen) > 6. GNU Radio and Mac OS X (Michael Dickens) > 7. Re: Re: New external clock board for USRP (Jason) > 8. Re: Re: New external clock board for USRP (Alexander Chemeris) > 9. how to use value of a variable_sink in program (nansai hu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 20 Oct 2009 02:31:48 +0400 > From: Alexander Chemeris <alexander.cheme...@gmail.com> > Subject: [Discuss-gnuradio] Re: New external clock board for USRP > To: Gnuradio-discuss <discuss-gnuradio@gnu.org>, > openbts-disc...@lists.sourceforge.net > Message-ID: > <3d032e5d0910191531m4aa98d2r84fa4a053adee...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi all, > > As I wrote in my previous mail, we're working on an universal clock > source for USRP (and not only for USRP). It is based on 0.28ppm TCXO > from Connor Winfield [1], National Semiconductor LMX2531 VCO+PLL [2] > and LMK01000 CD [3] for clock generation and Atmel ATUSB for control. > So far we've finished PCB design and working on production of the first > 25 units. We'll reserve 5 of them for our own use and testing of > different options, 8 others are requested by community people, so there > are more then 10 left for sale. We plan to finish production at > the beginning of Dec and take units to 26C3. If you plan to attend it, > you have a great chance to see them, play with them and take some of > them with you. ;) > > As we promised, units form this experimental batch will be sold out > for only $100 or 66EUR (without shipping). We kindly invite everyone > interested in such unit to get one and try fitting it to your setup. > Also we need your help determining the best feature set for the unit > (read on for the ample list of possible features). We aim at creating > a really flexible and cheap clocking unit, which may used by a broad > GnuRadio community and will best fit its needs. Unit with open source > software and open hardware. > > Now, lets get to facts. Board dimensions are 86x44mm (3.4" x 1.7") - > it is designed to work inside of USRP box with RFX boards installed > with no external connections. > > Default distribution version includes: > 1) Clock board with default options > 2) U.FL to SMA cable to connect to USRP > 3) Power cable to connect to USRP's fan connector > > Default board options: > 1) Control from miniUSB or 16-pin connector on USRP daughter boards. > It will be possible to write a GNURadio block to control clocks right > from GNURadio flowgraph! > 2) Power from 2-pin connector for connecting to USRP fan power > connector and 2-pin pass-throw to connect fan to. That is board is > connected between USRP and fan. > 3) One U.FL clock output with ability to generate frequency in the main > range 2.84-65.83MHz, and additional ranges 65.91-71.82MHz, > 72.5-79MHz, and more ranges higher with <=0.44Hz step. Output > levels are CMOS. This means that you can tune your clock precisely > ti whatever frequency you want. > 4) Initial frequency calibration 1ppm, temperature stability 0.28ppm, > holdover stability over 24h 0.32ppm [1]. Clock jitter will be measured > when first units arrive to us, I'll post measurement results here. > > Pretty simple and flexible isn't it? But what makes this clock unit really > universal is a set of available options. You may solder them by yourself > or request ready-to-use units from us - I will make some notes on price > changes and options compatibility below, mail me for details if you're > interested in particular configuration. We want to be as flexible as > possible to fulfill community need in flexible clock source. > > So, basic additional options include: > 1) Power may be taken from 2-pin connector, 6V jack input or from USB. > All power options are mutually exclusive. > 2) COM-port with RS-232 levels for clock control. This will add about 3.5$ > to the price. > 3) Up to 5 more additional U.FL outputs (6 outputs altogether), which > share VCO frequency, but may be independently divided in clock > distributor. 5 additional connectors will add 8-9$ to the price. > 4*) Output levels may be (a) 4 LVPECL (or CMOS) outputs and 2 LVDS > outputs, (b) 6 LVPECL (or CMOS) outputs, (c) 6 LVDS outputs. > 5) SMA connector may be soldered instead of one of U.FL with CMOS > levels. It will add 4.5$ to the price. > 6) SMA connector with direct VCO output bypassing clock distributor. > It will add 4.5$ to the price. > 7) SMA connector for external clock source. This way onboard > oscillator should be disabled by resistors soldering or should not be > present. It will add 4.5$ to the price. > 8*) Oscillator could be changed to 0.5ppm. This will save you 7.5$. > 9*) VCO+PLL with clock divider could be changed to clock divider > and multiplier. In this case you won't be able to tune your clock > precisely, but you'll be able to generate, e.g. 13MHz, 26MHz and 62MHz > from a single oscillator. > 10*) Frequency range could be extended to 1.87-94.75MHz (and more > ranges higher) at the price of more phase noise. > 11*) For nerds only - unit may be used without onboard controller by > direct access to VCO+PLL pins. But this is roughly equivalent to > a VCO starter kit and obviously is not compatible with features like > SPI/USB/RS232 control, and can't be used with power from USRP. > 12) 1pps external signal may be used to tame the clock to external > GPS unit. It will be passed to ATMega's interrupt input, so you > should keep in mind that this will need a lot of software work for filtering > out jitter, generated by it. We don't plan to develop this software at > least now, but anyone who need this is welcome to take it. > > * These options is not immediately available because of changes in > components list. Some options need testing before we can offer units > with them. Some options available for small orders, some available > only for volume orders. And sure, you can solder them by yourself. > Mail me for details, if you're interested. > > There are two big options, which touches a big part of the unit and are > very much experimental. We can't guarantee that they will work, > but we think they will. :) > * TCXO with VCO+PLL could be replaced with VCTCXO with DAC. > DAC can be 12-bit linear or 16-bit delta-sigma. This will make it > about 20$ cheaper then default bundle if we produce it in volume. > The downside of this is that frequency range is much smaller and > more calibration is needed. > * GPS chip could be actually installed right on board to provide > 1pps signal. PCB is designed to be used with cheap EB230 GPS > Module and will add about 40$ to the price. But there are some small > limitations - you can't use RS232 output with it, only 5 output channels > are possible. Same notes on software as for 1pps input applies. > > We're working on detailed documentation and will make it available > as soon as possible. > > 1. http://www.conwin.com/datasheets/tx/tx236.pdf > 2. http://www.national.com/ds/LM/LMX2531LQ1515E.pdf > 3. http://www.national.com/ds/LM/LMK01000.pdf > > -- > Regards, > Alexander Chemeris. > > > > > ------------------------------ > > Message: 2 > Date: Tue, 20 Oct 2009 12:01:20 +0530 > From: "Narayanan, Sivaramasubramanian (R&T)" > <sivaramasubramanian.naraya...@honeywell.com> > Subject: [Discuss-gnuradio] clarification on RFX-2400 > To: <Discuss-gnuradio@gnu.org> > Message-ID: > > <8797c1399d4fe54dbed30e819faae0290292f...@ie10ev812.global.ds.honeywell.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, > > > > I am using RFX2400 daughter board as a receiver in USRP. In the run > time, will I be able to use it as a transmitter? For ex, say the board > will act as a receiver for 30 seconds and switch to transmit mode after > 30 secs automatically? Please help me, how would I do that in software. > I am using the antenna in the TX/RX SMA port. > > > > Regards, > > Sivaram > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20091020/9e43ffed/attachment.html > > ------------------------------ > > Message: 3 > Date: Tue, 20 Oct 2009 07:42:45 -0300 > From: Edmar Candeia Gurj?o <ecand...@dee.ufcg.edu.br> > Subject: [Discuss-gnuradio] Problem new Signal Processing Block > To: discuss-gnuradio@gnu.org > Message-ID: > <2fb0bdaa0910200342w32d05221l702695250853c...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear > > -- > --------------------------------- > Edmar Candeia Gurjão > Universidade Federal de Campina Grande > Unidade Acadêmica de Engenharia Elétrica > http://www.dee.ufcg.edu.br/~ecandeia > http://www.dee.ufcg.edu.br/~pet > Tel.: 83 - 3310 1403 > > > > > ------------------------------ > > Message: 4 > Date: Tue, 20 Oct 2009 07:54:37 -0300 > From: Edmar Candeia Gurj?o <ecand...@dee.ufcg.edu.br> > Subject: [Discuss-gnuradio] Problem new Signal Processing Block > To: discuss-gnuradio@gnu.org > Message-ID: > <2fb0bdaa0910200354r1814039en53e7fa51bc2f...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear all, > > yesterday I posted a message about problems to install a new signal > processing block, after that I search in previous messages in the > gnuradio discussion list and I found some different solutions to my > problem, I put them together my problem was solved. > At fist I note that in configure file the $prefix=/usr/local and the > rest of the construction process use this information, so I ran > ./configure --prefix=/usr since my /lib folder in under /usr only not > in /usr/local. > After that I modify the qa_howto.py file by changing the import > howto by from gunradio import howto. When I made this changes it > finally works, > > > -- > --------------------------------- > Edmar Candeia Gurjão > Universidade Federal de Campina Grande > Unidade Acadêmica de Engenharia Elétrica > http://www.dee.ufcg.edu.br/~ecandeia > http://www.dee.ufcg.edu.br/~pet > Tel.: 83 - 3310 1403 > > > > > ------------------------------ > > Message: 5 > Date: Tue, 20 Oct 2009 09:13:39 -0400 > From: chenchen chen <cc19...@gmail.com> > Subject: [Discuss-gnuradio] problem about installing hydra > To: Discuss-gnuradio@gnu.org > Message-ID: > <3b07a9230910200613x609736b2qe5b5605d02427...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > hello, > > i am trying to install hydra. > i input commands step by step as INSTALL file. > when installing gr-hydra, however, there is something wrong that defeated me. > configure can be done successfully. > when i enter make, ouput is as followed. > by the way, i am using fedora 10. > ............ > lc -lgcc_s /usr/lib/gcc/i386-redhat-linux/4.3.2/crtendS.o > /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crtn.o -pthread > -Wl,-soname -Wl,_gui.so -o .libs/_gui.so > creating _gui.la > (cd .libs && rm -f _gui.la && ln -s ../_gui.la _gui.la) > make[5]: Leaving directory `/home/datalink/hydra/gr-hydra/src/swig/gui' > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/swig/gui' > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/swig' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/swig' > make[3]: Leaving directory `/home/datalink/hydra/gr-hydra/src/swig' > Making all in python > make[3]: Entering directory `/home/datalink/hydra/gr-hydra/src/python' > Making all in core > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python/core' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python/core' > Making all in rf > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python/rf' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python/rf' > Making all in phy > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python/phy' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python/phy' > Making all in mpif > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python/mpif' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python/mpif' > Making all in gui > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python/gui' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python/gui' > Making all in mac > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python/mac' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python/mac' > make[4]: Entering directory `/home/datalink/hydra/gr-hydra/src/python' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python' > make[3]: Leaving directory `/home/datalink/hydra/gr-hydra/src/python' > Making all in util > make[3]: Entering directory `/home/datalink/hydra/gr-hydra/src/util' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory `/home/datalink/hydra/gr-hydra/src/util' > make[3]: Entering directory `/home/datalink/hydra/gr-hydra/src' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory `/home/datalink/hydra/gr-hydra/src' > make[2]: Leaving directory `/home/datalink/hydra/gr-hydra/src' > make[2]: Entering directory `/home/datalink/hydra/gr-hydra' > make[2]: Leaving directory `/home/datalink/hydra/gr-hydra' > make[1]: Leaving directory `/home/datalink/hydra/gr-hydra' > > can anyone help me? > thanks in advanced. > > > > > ------------------------------ > > Message: 6 > Date: Tue, 20 Oct 2009 10:10:49 -0400 > From: Michael Dickens <m...@alum.mit.edu> > Subject: [Discuss-gnuradio] GNU Radio and Mac OS X > To: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Message-ID: <1c4711c5-075d-4f37-a7c5-bfa052f3f...@alum.mit.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > As of Oct 19, the latest GIT master of GNU Radio should be compatible > with Mac OS X 10.4, 10.5, and 10.6, 32- or 64-bit compiling & > execution (as allowed by the platform and XCode version), PPC or Intel > -- with the sole exception that the GUIs may not work under 64-bit > mode (on any version of OS X, not just 10.6). Might be tricky getting > the various background libraries and such installed on 10.4, but it > should be doable. > > If you're using MacPorts to install GNU Radio (e.g., "sudo port > install gnuradio"), it currently installs version 3.2.0, and the USRP > component won't work because libusb 0.1.12 was renamed to 'libusb- > legacy' -- the GIT master checks for this now & works correctly. > Other than that I think at least on 32-bit 10.4, 10.5, and 10.6 this > way of installing GNU Radio (except QtGUI, but that's for another day) > should work "out of the box" with the latest MacPorts. > > If you're an OSX user of GNU Radio, please do test out the latest GIT > master for yourself to verify that it (still) works; and if not, we'll > work on fixing whatever issues come up if you let the list know. - MLD > > > > > ------------------------------ > > Message: 7 > Date: Tue, 20 Oct 2009 10:29:44 -0400 > From: Jason <gnura...@lakedaemon.net> > Subject: Re: [Discuss-gnuradio] Re: New external clock board for USRP > To: Alexander Chemeris <alexander.cheme...@gmail.com> > Cc: Gnuradio-discuss <discuss-gnuradio@gnu.org> > Message-ID: <4addc958.5070...@lakedaemon.net> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Alexander Chemeris wrote: >> Hi all, >> >> As I wrote in my previous mail, we're working on an universal clock >> source for USRP (and not only for USRP). It is based on 0.28ppm TCXO >> from Connor Winfield [1], National Semiconductor LMX2531 VCO+PLL [2] >> and LMK01000 CD [3] for clock generation and Atmel ATUSB for control. >> So far we've finished PCB design and working on production of the first >> 25 units. We'll reserve 5 of them for our own use and testing of >> different options, 8 others are requested by community people, so there >> are more then 10 left for sale. We plan to finish production at >> the beginning of Dec and take units to 26C3. If you plan to attend it, >> you have a great chance to see them, play with them and take some of >> them with you. ;) >> > > Awesome! I don't think I'll be able to swing 26C3, though. > >> As we promised, units form this experimental batch will be sold out >> for only $100 or 66EUR (without shipping). We kindly invite everyone >> interested in such unit to get one and try fitting it to your setup. >> Also we need your help determining the best feature set for the unit >> (read on for the ample list of possible features). We aim at creating >> a really flexible and cheap clocking unit, which may used by a broad >> GnuRadio community and will best fit its needs. Unit with open source >> software and open hardware. >> > > Can you post the preliminary pcb/gerber/asm files? Are you using > geda/pcb, by chance? > >> Now, lets get to facts. Board dimensions are 86x44mm (3.4" x 1.7") - >> it is designed to work inside of USRP box with RFX boards installed >> with no external connections. >> >> Default distribution version includes: >> 1) Clock board with default options >> 2) U.FL to SMA cable to connect to USRP >> 3) Power cable to connect to USRP's fan connector >> >> Default board options: > [snip] >> 12) 1pps external signal may be used to tame the clock to external >> GPS unit. It will be passed to ATMega's interrupt input, so you >> should keep in mind that this will need a lot of software work for filtering >> out jitter, generated by it. We don't plan to develop this software at >> least now, but anyone who need this is welcome to take it. >> > > This would be interesting. > > thx, > > Jason. > > > > > ------------------------------ > > Message: 8 > Date: Tue, 20 Oct 2009 18:51:27 +0400 > From: Alexander Chemeris <alexander.cheme...@gmail.com> > Subject: Re: [Discuss-gnuradio] Re: New external clock board for USRP > To: Jason <gnura...@lakedaemon.net> > Cc: Gnuradio-discuss <discuss-gnuradio@gnu.org> > Message-ID: > <3d032e5d0910200751i50bdf7eah500f55ef0e906...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Oct 20, 2009 at 18:29, Jason <gnura...@lakedaemon.net> wrote: >> Alexander Chemeris wrote: >>> As I wrote in my previous mail, we're working on an universal clock >>> source for USRP (and not only for USRP). It is based on 0.28ppm TCXO >>> from Connor Winfield [1], National Semiconductor LMX2531 VCO+PLL [2] >>> and LMK01000 CD [3] for clock generation and Atmel ATUSB for control. >>> So far we've finished PCB design and working on production of the first >>> 25 units. We'll reserve 5 of them for our own use and testing of >>> different options, 8 others are requested by community people, so there >>> are more then 10 left for sale. We plan to finish production at >>> the beginning of Dec and take units to 26C3. If you plan to attend it, >>> you have a great chance to see them, play with them and take some of >>> them with you. ;) >>> >> >> Awesome! Â I don't think I'll be able to swing 26C3, though. >> >>> As we promised, units form this experimental batch will be sold out >>> for only $100 or 66EUR (without shipping). We kindly invite everyone >>> interested in such unit to get one and try fitting it to your setup. >>> Also we need your help determining the best feature set for the unit >>> (read on for the ample list of possible features). We aim at creating >>> a really flexible and cheap clocking unit, which may used by a broad >>> GnuRadio community and will best fit its needs. Unit with open source >>> software and open hardware. >>> >> >> Can you post the preliminary pcb/gerber/asm files? Â Are you using geda/pcb, >> by chance? > > We will setup a website for the project and will put sources and schematics > there. To date software is in embryo stage - we were busy placing unit > into production to get it before 26C3. We plan to get back to it soon and > will publish it then. > >>> Now, lets get to facts. Board dimensions are 86x44mm (3.4" x 1.7") - >>> it is designed to work inside of USRP box with RFX boards installed >>> with no external connections. >>> >>> Default distribution version includes: >>> 1) Clock board with default options >>> 2) U.FL to SMA cable to connect to USRP >>> 3) Power cable to connect to USRP's fan connector >>> >>> Default board options: >> >> [snip] >>> >>> 12) 1pps external signal may be used to tame the clock to external >>> GPS unit. It will be passed to ATMega's interrupt input, so you >>> should keep in mind that this will need a lot of software work for >>> filtering >>> out jitter, generated by it. We don't plan to develop this software at >>> least now, but anyone who need this is welcome to take it. >>> >> >> This would be interesting. > > You're welcome to get the unit and hack this ;) > > > -- > Regards, > Alexander Chemeris. > > > > > ------------------------------ > > Message: 9 > Date: Tue, 20 Oct 2009 11:43:19 -0400 > From: nansai hu <hunan...@gmail.com> > Subject: [Discuss-gnuradio] how to use value of a variable_sink in > program > To: discuss-gnuradio@gnu.org > Message-ID: > <993321de0910200843sf71be7dm4264d3bdadf7d...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > how to use value of a variable_sink in program? > > I use a variable_sink to receive a value that clac in GRC program > Now I want to use this value in another place in program(name as val_freq), > > So how to do that? I announced val_freq in front of whole program and add > two yellow lines in variable_sink, > but it doesn't work. > > self.blks2_variable_sink_x_0 = grc_blks2.variable_sink_f( > vlen=1, > decim=1, > callback=self.set_mod_freq_sg, > global val_freq > val_freq=self.set_mod_freq_sg, > ) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20091020/81193ec6/attachment.html > > ------------------------------ > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > End of Discuss-gnuradio Digest, Vol 83, Issue 20 > ************************************************ _________________________________________________________________ A la recherche de bons plans pour une rentrée pas chère ? Bing ! Trouvez ! http://www.bing.com/search?q=bons+plans+rentr%C3%A9e&form=MVDE6 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio