Greg Troxel wrote:
> ...
> Given that new versions of python can be installed and made default
> (meaning invoked as 'python'), it's necessary to bind the scripts to the
> same version of python used to build .so modules and install .py files
> in site-packages...
I'm curious -- really just curio
Johnathan Corgan <[EMAIL PROTECTED]> writes:
> Greg Troxel wrote:
>
>> But that will only really work if the version of python found as
>> 'python' is the same one as the version gnuradio found when it was
>> compiled, and the packaging system installs an interpreter as python.
>> In a world wit
Tim Meehan wrote:
> Can this be handled with symbolic links rather then renaming the scripts?
It could, if need be, but that's an extra complication that I'd want to
avoid. Symlink behavior is easy to break across all the systems that
run GNU Radio, and would probably invite future grief.
--
J
Greg Troxel wrote:
> But that will only really work if the version of python found as
> 'python' is the same one as the version gnuradio found when it was
> compiled, and the packaging system installs an interpreter as python.
> In a world with multiple python versions and site-libs this leads t
Michael Dickens wrote:
> Removing the '.py' works fine on OSX 10.4.10, so long as the file is
> executable (a+x) and has "#!/usr/bin/env python" as the first line to
> get the runtime environment correct.
Anything we put on the path already conforms to the above. This may
actually cause some gri
Greg Troxel wrote:
> From the NetBSD viewpoint, I think that's perfectly fine.
>
> It would be good if all the scripts started with a small set of prefixes
> like usrp_foo and gr_foo, to avoid collisions with at least most of the
> other 5000 packages. Sounds like you are headed this way.
I agr
**
Can this be handled with symbolic links rather then renaming the scripts?
On 10/18/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
>
> A while back we did some clean up of the USRP examples, removing some
> bit-rotted cruft, and moving the commonly used programs into gr-utils.
>
> These include
Removing the '.py' works fine on OSX 10.4.10, so long as the file is
executable (a+x) and has "#!/usr/bin/env python" as the first line to
get the runtime environment correct. - MLD
Agreed.
But that will only really work if the version of python found as
'python' is the same one as the vers
Removing the '.py' works fine on OSX 10.4.10, so long as the file is
executable (a+x) and has "#!/usr/bin/env python" as the first line to
get the runtime environment correct. - MLD
On Oct 18, 2007, at 12:15 PM, Johnathan Corgan wrote:
usrp_fft.py -> usrp_fft
usrp_rx_cfile.py -> usrp_rx_cfil
Hi,
Please help me figure out the strange problem I'm having.
In my system, the software is receiving four interleaved streams of complex
data from the usrp. I am trying to receive two channels on each input of
the usrp, so I setup the usrp to ddc the center of the two channels down to
zero
However, a common convention on Linux, at least on Debian, Ubuntu, and
derived systems (probably Redhat too), is to strip the language specific
extension off scripts in the path.
Would anyone have any heartache if we did this for the gr-utils scripts
as well as the relatively few other s
Hello,
In the last months, we have developed an ofdm system using your gnuradio
architecture as part of a research on dynamic resource allocation. Now we
like to contribute parts of our code to the gnuradio project. We think that
it will be useful to you since it partially employs more advanced te
Thank you, I tried that last night and was able to make it 8MHz, so looks
like it works. So there is no way to take a look at the fft of the entire
spectrum supported by the RX board at once?
Eng. Firas wrote:
>
> Hi,
>
> Use usrp_fft.py with decimation rate of 8. In this case, you can see 8M
A while back we did some clean up of the USRP examples, removing some
bit-rotted cruft, and moving the commonly used programs into gr-utils.
These included things like usrp_fft.py, usrp_rx_cfile.py, and those
scripts that over time have become more utilities than examples.
In the gr-utils compone
Steven Clark wrote:
> We could try and normalize the complex product, but the universe
> explodes if it has length 0 (divide by 0).
What do you want the answer to be in this case? You will only have a
zero length vector from the conjugate multiplication if one of the
original vectors is also zer
DiX <[EMAIL PROTECTED]> writes:
>With BBN codes and FLEX2400 d'borads, now I can received 802.11b
> packets from standard wireless cards, and communicate between two USRPs with
> barker spreading off. These make me really excited :)
That's good to hear - that matches where we got to.
All-
I was hoping I could get some advice on what is a good block-design strategy
for the following problem.
I have two streams of complex samples coming in. I want a block or sequence
of blocks which outputs the cosine of the phase difference between the two
input streams.
If we could assert th
Hi guys,
With BBN codes and FLEX2400 d'borads, now I can received 802.11b
packets from standard wireless cards, and communicate between two USRPs with
barker spreading off. These make me really excited :)
However, I failed trying to send any packet from USRP to PC. I
believe it
18 matches
Mail list logo
