Re: [Discuss-gnuradio] 64Mhz Crystal Oscillator part number
Nirali Patel wrote: > > Hi, > > > > I have a USRP Rev 4.5 and I was trying to find stability information > on the 64 Mhz crystal oscillator. However, I am unable to > cross-reference it to a manufacturer’s part number. The part number on > the BOM says X2 is a digikey CTX286LVCT-ND. However the part populated > on the > > USRP is from Ecliptek and the number stamped on the part itself just > tells about the frequency and the year/week of production. I am also > unsure if this is a TCXO or not. Any help and information appreciated. > Older USRPs used the CTX, and it had 50ppm tolerance. Newer ones have the Ecliptek part with 20ppm tolerance. Neither is a TCXO. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 64Mhz Crystal Oscillator part number
Hi, I have a USRP Rev 4.5 and I was trying to find stability information on the 64 Mhz crystal oscillator. However, I am unable to cross-reference it to a manufacturer's part number. The part number on the BOM says X2 is a digikey CTX286LVCT-ND. However the part populated on the USRP is from Ecliptek and the number stamped on the part itself just tells about the frequency and the year/week of production. I am also unsure if this is a TCXO or not. Any help and information appreciated. Thanks, Nirali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] script suffix deletion - tales of woe
In my experience in porting many systems to many platforms, suffix visibility is an essential aid to clarity and understanding. I would hope that the .py suffix would be retained, as well as all other relevant suffixes. Do what you think is best however. The workaround I will use if suffixes are deleted is to grep out the first line of the script to determine the suffix, reinstantiate the script as suffixed and proceed. It is probably just a Unix hack to build a set of tools that add/del suffixes. The trouble comes when scripts call scripts, and visibility as to the nature of the script is lost. This is second-order, and probably requires human recognition, thus my note. Deleting suffixes may cause an increase in confusion and message traffic by newbies, rather than intuition-building. 73, - Van wdv.com AE5CC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts
Frank Brickle <[EMAIL PROTECTED]> writes: >> 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 curious -- why not create a chroot > environment for gnuradio? Or, where the kernel and the CPU allow, > a fully virtualized stable OS install simply for gnuradio? You could, but a chroot per package would lead to a vast number of chroots, and it wouldn't solve the underlying problem of maintaining dependencies. If one views the computer's sole purpose as providing a way to run Gnu Radio, that might be reasonable. If one views GNU Radio as one of many components in an overall system - for instance providing the low-level network connectivity, then it isn't reasonable. The lack of python binding really is just plain suboptimal (or wrong) - but becaues most people rarely change python bindings, and because GNU Radio hackers constantly rebuild/reinstall GNU Radio, it hardly ever causes trouble. I don't expect other people to fix this if they don't want to spend the effort. pkgsrc currently works around this by having a list of files in which the interpreter is changed as they are installed. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark_ofdm_rx not working
Hello, I am using two USRPs rev 4 and two RFX2400. I am basically trying to make the USRPs communicate with each other using the benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. The commands I am executing are ./benchmark_ofdm_tx.py -f2.4e9 -T A (at one USRP connected to laptop) ./benchmark_ofdm_rx.py -f2.4e9 -R A (at the other USRP connected to another laptop) The benchmark_ofdm_tx.py script is working as I can see the packet number displayed(I wrote a print pktno in the script) However the benchmark_ofdm_rx.py script does not give any output. I don't think the rx_callback function is being executed(as the packets are printed in that function). Can anyone please help me out and give suggestions as to what the problem could be? Thank you. On 10/19/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > 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 > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > >1. Re: Contribution: ofdm system (Johnathan Corgan) > > > -- > > Message: 1 > Date: Fri, 19 Oct 2007 07:22:23 -0700 > From: Johnathan Corgan <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Contribution: ofdm system > To: Dominik Auras <[EMAIL PROTECTED]> > Cc: 'Eric Blossom' <[EMAIL PROTECTED]>, discuss-gnuradio@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Dominik Auras wrote: > > > 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 > techniques > > than in your example. If you like it, I suggest to add it as an > alternative > > ofdm system. > > Dominik- > > You may have already heard privately from Eric, but yes, we'd like to > see your code for review and possible incorporation into the project. > > Is it published anywhere else? > > All of the host code in GNU Radio is copyrighted by FSF, so if we do > incorporate it, there is a copyright assignment process you'll have to > go through. > > Thanks for offering it. While we already have an in-progress OFDM > implementation, having multiple options is good, and it may even be > possible to merge implementations. > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com > > > > > -- > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > End of Discuss-gnuradio Digest, Vol 59, Issue 52 > > -- Archana Ragothaman Master's in Telecommunications Graduate Research Assistant MIND Lab,UMIACS University of Maryland, College Park Email: [EMAIL PROTECTED] Phone: 240-422-7887 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strategy advice
Steven Clark wrote: > 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 that both input streams are unit length, then one way to > do it would be to conjugate one stream, then complex multiply the two > together, then take the real part of the output. But if the input streams > are NOT normalized, then the product will likely not be unit length either, > and this won't work. > > We could try and normalize the complex product, but the universe explodes if > it has length 0 (divide by 0). Also, this would require a slow sqrt (?) If your input streams have a rather stable amplitude you could put a slow AGC in front of them to normalize. You shoudl make sure that the vectors are length 1.0. I remember using this trick and that I had to set the reflevel of the agc to 1/srt(2) (in stead of 1.0) or something like that to get it to output vectors of length 1.0. This will however not be as accurate as actually doing the slow sqrt() for every sample. > Is the best approach to just get the phase of the complex product via > fast_atan2f, then take the cos of that? I am working on an SSE optimized version of atan2. It is not fully checked and so not ready for primetime but maybe this would work for you. How much in a hurry are you? > Do any basic math/trig functions (cos, atan2, sqrt, etc) exist at the python > block level, or do I have to delve into C to use them? > Makefiles are scary :( No they are not ;-) Get them to know better and they will be your friends. > > > > > > ___ > 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] Contribution: ofdm system
Dominik Auras wrote: > 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 techniques > than in your example. If you like it, I suggest to add it as an alternative > ofdm system. Dominik- You may have already heard privately from Eric, but yes, we'd like to see your code for review and possible incorporation into the project. Is it published anywhere else? All of the host code in GNU Radio is copyrighted by FSF, so if we do incorporate it, there is a copyright assignment process you'll have to go through. Thanks for offering it. While we already have an in-progress OFDM implementation, having multiple options is good, and it may even be possible to merge implementations. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 59, Issue 49
Hi Dominik, It would be great if you could port the ofdm transceiver that you have implemented to packet_utils. I am actually using two USRPs rev4 with RFX2400 and trying to make them communicate with each other on air using ofdm. Presently I am thinking of how to synchronize the transmitter and the receiver. The S&C based timing offset estimation that you have implemented will be very helpful to me! Thanks, Archana On 10/18/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > 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 > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > >1. Removing '.py' from system path installed Python scripts > (Johnathan Corgan) >2. Re: looking at a wider spectrum (meggahertz) >3. Contribution: ofdm system (Dominik Auras) >4. Re: Removing '.py' from system path installed Python scripts > (Greg Troxel) >5. (no subject) >6. usrp initialization (Hans Glitsch) >7. Re: Removing '.py' from system path installed Python scripts > (Michael Dickens) >8. Re: Removing '.py' from system path installed Python scripts > (Greg Troxel) >9. Re: Removing '.py' from system path installed Python scripts > (Tim Meehan) > > > -- > > Message: 1 > Date: Thu, 18 Oct 2007 09:15:59 -0700 > From: Johnathan Corgan <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] Removing '.py' from system path installed > Python scripts > To: gnuradio mailing list > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > 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 component, we are now installing these into the > $prefix/bin directory, so they'll end up on the user's PATH and be > callable from anywhere without prefixing them with the examples path. > > 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 scripts we install on the path? > > usrp_fft.py -> usrp_fft > usrp_rx_cfile.py -> usrp_rx_cfile > > etc. > > It's not a critical item, but if we do this, it will need to be before > the 3.1 stable branch is officially released. > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com > > > > > -- > > Message: 2 > Date: Thu, 18 Oct 2007 10:23:21 -0700 (PDT) > From: meggahertz <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] looking at a wider spectrum > To: Discuss-gnuradio@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > 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 > 8MHz > > of spectrum. Also, you can use 8 bit data transfer with decimation rate > of > > 4 to look at 16 MHz wide spectrum. > > > > Firas > > > > > > meggahertz wrote: > >> > >> I am new to the GNU Radio and am running the usrp_wfm_rcv.py but it > only > >> shows the spectrum of width ~ 0.4Mhz. How can I look at a wider > spectrum > >> instead of just 0.4MHz around the carrier frequency? > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/looking-at-a-wider-spectrum-tf4643642.html#a13279350 > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > > > -- > > Message: 3 > Date: Thu, 18 Oct 2007 19:36:12 +0200 > From: Dominik Auras <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] Contribution: ofdm system > To: 'Eric Blossom' <[EMAIL PROTECTED]> > Cc: discuss-gnuradio@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > 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 partia
[Discuss-gnuradio] Has Anyone Used Purify with GNU Radio?
Hi, I am trying debug my Python MAC extension with Purify but find that the binary instrumented with Purify does not seem to transmit any packets through GNU Radio 3.0.3. I trace the transmit packets through to mod_pkts. Beyond that, I think the packets should be handled by the GNU Radio .so files which I believe should be instrumented automatically by Purify. However, no packets seem to get transmitted. Does anyone have experience getting Purify working with GNU Radio, or is anyone able to shed some light? Thanks, Jeremy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: AW: Why is Barker Spreading difficult to usrp?
Tomek schrieb: Hello! I´m really new to gnu-radio. I installed the 3.0.4 version on my Ubuntu system finally and now I need some ideas, here is what I want to do: I want to use the USRP to sniff everything going on between 2 WLAN-PCMCIA Laptops on 2,4GH. How do I do that..? Does GNU Radio give me any tools making it possible to visualize this in any way? This will not be possible at the moment. The USRP can transmit 8MHz of complex bandwith over USB 2.0, and a WLAN-Channel has a bandwith of 22MHz. You can sweep over the WLAN-Area and detect power to see if a range has traffic, but you won't be able to decode a lot. See the archives of this list, it has been discusses a few time in the last year or so. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
AW: [Discuss-gnuradio] Why is Barker Spreading difficult to usrp?
Hello! I´m really new to gnu-radio. I installed the 3.0.4 version on my Ubuntu system finally and now I need some ideas, here is what I want to do: I want to use the USRP to sniff everything going on between 2 WLAN-PCMCIA Laptops on 2,4GH. How do I do that..? Does GNU Radio give me any tools making it possible to visualize this in any way? Thx! Tomek ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Removing '.py' from system path installed Python scripts
Frank Brickle schrieb: I'm curious -- really just curious -- why not create a chroot environment for gnuradio? Or, where the kernel and the CPU allow, a fully virtualized stable OS install simply for gnuradio? If you have the possibility to do so, no problem at all. It's quite expansive in respect to resources and administration time. But there may be reasons not create a special area for gnuradio, and then you have to think about robust integration. You would not want to create a whole new chroot or virtulization for every package you install. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
