[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Discuss-gnuradio] GNU Radio and Mac OS X
|
From: |
[ Cosmin ] |
|
Subject: |
RE: [Discuss-gnuradio] GNU Radio and Mac OS X |
|
Date: |
Thu, 22 Oct 2009 00:24:39 +0000 |
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: address@hidden
> Subject: Discuss-gnuradio Digest, Vol 83, Issue 20
> To: address@hidden
>
> Send Discuss-gnuradio mailing list submissions to
> address@hidden
>
> 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
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> 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 <address@hidden>
> Subject: [Discuss-gnuradio] Re: New external clock board for USRP
> To: Gnuradio-discuss <address@hidden>,
> address@hidden
> Message-ID:
> <address@hidden>
> 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)"
> <address@hidden>
> Subject: [Discuss-gnuradio] clarification on RFX-2400
> To: <address@hidden>
> Message-ID:
> <address@hidden>
>
> 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 <address@hidden>
> Subject: [Discuss-gnuradio] Problem new Signal Processing Block
> To: address@hidden
> Message-ID:
> <address@hidden>
> 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 <address@hidden>
> Subject: [Discuss-gnuradio] Problem new Signal Processing Block
> To: address@hidden
> Message-ID:
> <address@hidden>
> 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 <address@hidden>
> Subject: [Discuss-gnuradio] problem about installing hydra
> To: address@hidden
> Message-ID:
> <address@hidden>
> 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 <address@hidden>
> Subject: [Discuss-gnuradio] GNU Radio and Mac OS X
> To: GNURadio Discussion List <address@hidden>
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Subject: Re: [Discuss-gnuradio] Re: New external clock board for USRP
> To: Alexander Chemeris <address@hidden>
> Cc: Gnuradio-discuss <address@hidden>
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Subject: Re: [Discuss-gnuradio] Re: New external clock board for USRP
> To: Jason <address@hidden>
> Cc: Gnuradio-discuss <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Oct 20, 2009 at 18:29, Jason <address@hidden> 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 <address@hidden>
> Subject: [Discuss-gnuradio] how to use value of a variable_sink in
> program
> To: address@hidden
> Message-ID:
> <address@hidden>
> 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
> address@hidden
> 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