Re: [Discuss-gnuradio] choice of antenna and daughter board
On Mar 3, 2011, at 2:34 AM, ranjini ram wrote: can any body tell which is the antenna and daughter board that has to be used in receiving FM...which is the best TVRX of Basic RX? Any antenna or daughter board can receive FM transmissions. FM is just a modulation type, and it can be used at any frequency, and with other variations such as different amounts of frequency deviation. The point of a software-defined radio is that it can send and/or receive *any* modulation type within its constraints of center frequency, bandwidth, and (in some cases) latency. The question is, what frequency range do you need to be able to receive? For example, FM broadcast band transmissions (i.e., what a car stereo can receive) occur between 88 MHz and 108 MHz in the US. FM amateur radio or commercial radio transmissions might occur anywhere between around 27 MHz and well over 1 GHz. The frequency range(s) you need to cover will determine which daughter board(s) might work for you. Your antenna selection will depend on the frequency range(s) you need to cover, as well as other constraints such as required polarization, directional gain, etc. So, what exactly are you interested in receiving? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] choice of antenna and daughter board
Oops... I meant to send this to the list. Begin forwarded message: From: Mark J. Blair n...@nf6x.net Date: March 3, 2011 6:38:46 PM PST To: ranjini ram ranjinira...@gmail.com Subject: Re: [Discuss-gnuradio] choice of antenna and daughter board On Mar 3, 2011, at 6:15 PM, ranjini ram wrote: Am sorry i forgot to mention the frequency range.am concentrating on FM broadcast transmissions i.e.88-108Mhz.i found like both TVRX operates in 50-860hz.This lead to confusion in choosing the daughter board.please do help me in this. Ok, that helps! The TVRX boards will be able to receive the FM broadcast band, according to the specifications on the Ettus site (I haven't used these boards myself). So can the WBX (I have one, and I've used it to receive FM broadcast transmissions). The WBX is more expensive, but it also covers a wider tuning range and is capable of transmitting, in case you expect a future need for either of those. The BasicRX won't receive FM broadcast band transmissions by itself, because it doesn't include an RF front end. It might be possible to hack up a regular FM broadcast band receiver to use as a front end, since I think that they commonly use a 10.7 MHz intermediate frequency. It'll really depend on what you're trying to accomplish and how much you feel like tinkering. For an antenna, if you're just trying to receive a strong local station, you might get by with a few feet of wire attached to the center pin of the SMA connector and laying on the table. Sure, a properly tuned antenna will work better, but for receive-only and strong signals, a random length of wire might be enough. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IS USRP safe for the human body?
On Feb 8, 2011, at 5:07 AM, Nick Othieno wrote: Do I sense a Marie Curie in the making? Remember, kids: It's not the volts that kill you. It's the amps. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Who actually *does* use GNU Radio?
I've been using GNU Radio + USRP as general RF test equipment, and GNU Radio by itself as a simulation environment for learning about SDR. I'm interested in the ongoing discussion of alternate RF hardware platforms for use with GNU Radio. While I'm quite happy with my USRP hardware, I can see plenty of room in the SDR user base for hardware with different feature sets and price points. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On Jan 12, 2011, at 9:17 PM, Jamie Morken wrote: That sounds like a pretty good system. I should say right off the bat that if I am involved to make this I would want to add a clause in the open source hardware license to not allow the hardware to be used for military applications. I think it is important to state this at the start before I would get involved working on a new gnu radio board. If people can live with that requirement I am happy to do the layout work. How would you define military applications? I collect surplus military gear as a hobby, and I'm presently working on a GNUradio-based implementation of a decoder for high-speed Morse code transmissions from my vintage AN/GRA-71 code-burst keyer (for which key pieces of the original reception hardware is unobtainium). I'm presently working entirely in simulation, but my USRP will get pressed into service for this before long. Would you consider that application to be military? Or how about if I were to use the hardware to intercommunicate with other military radio hardware (such as any of the countless surplus military radios used on the ham radio bands every day)? What if I throw it in my HMMWV and use it on a ham band during a Veteran's Day parade? What if a soldier wishes to use the hardware on-base for MARS activities? If any such things would be considered military, then I'd neither use nor contribute towards any hardware that's shackled by such a silly restriction. Furthermore, I doubt very much that the restriction would be at all enforceable. Personally, I don't think that any prior restraint placed upon end use of the hardware (beyond the requirement to keep derivative works open in most cases) is compatible with the very libertarian principles of the open software movement. I've released code under GPL. I thus place certain limited restrictions on the use of the code to keep it open, but beyond those limited restrictions, it's really none of my business to tell people what they can and can't do with it. If I wanted to control its end use to that degree, then I wouldn't have released it in the first place. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Open-Hardware
On Jan 11, 2011, at 5:15 PM, Patrick Strasser wrote: The only problem is that Microsoft promised in 2005 to implement UAC2, but forgot to do it until now. BTW they have a big mess with USB, as Daniel Mack, Linux UAC2 author wrote: Inevery cruel reincarnation of their OS, it has different issues. I spare you the terrible details an leave out the rest of his summary. I have to give MS credit for backwards-compatibility, though. As of Windows 7, they still support mis-identifying a GPS receiver as a serial port mouse, thus causing all sorts of delightful hijinks with the mouse pointer. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fw: Need Advice for SDR choice
On Jan 2, 2011, at 1:31 PM, Andrew Rich wrote: I have a MacBook PRO I7 it can run OS X or windows I have been successfully using the Ettus Research USRP with LFRX, LFTX and WBX boards on my 17 MacBook Pro under OS X (Snow Leopard). Installing the software portion is pretty easy: Install the MacPorts package, then run sudo port install gnuradio in a terminal window. You can play with the gnuradio software to see if it's right for you before committing to buying any hardware, since it can use the audio device and/or data files as a source/sink, or even run entirely simulated flowgraphs. I haven't used any gnuradio-based canned ham radio USB/LSB/whatever applications (if any exist). I have successfully received 2m FM transmissions with one of the examples that comes with the gnuradio distribution. I've mostly used my hardware to generate fairly simple test signals for other radio hardware (i.e., a number of simultaneous CW tones within a fairly narrow bandwidth) and simple spectrum analysis. At the moment, I'm playing around with writing blocks and flowgraphs for sending and receiving high-speed Morse code, due to my current interest in devices such as the AN/GRA-71 code burst keyer (*). This is all pretty simple stuff that the USRP hardware is overkill for, but I'm just beginning to learn about gnuradio and SDR design in general. Based on what you've stated so far, I think that a USB-based USRP with a WBX board and the gnuradio software should work nicely for you, and you can work with it directly under OS X. You may also want to get an RFX2400 board to hit the 2.4GHz band (I have one, but haven't done much with it yet). This board combination will leave a hole between 2.2GHz and 2.3GHz. If I recall correctly, I've generally set my hardware decimation to limit sampled bandwidth to about 2 MHz in order to avoid USB over-runs and/or under-runs. I've been able to look at a 4 MHz bandwidth with occasional over/under-runs. The occasional over/under-run doesn't seem to cause problems when just visually watching an FFT plot (i.e., to look for activity within a band). I don't know if the Ethernet-based USRP platforms work on Macs yet. (*) More info here if you're curious: http://www.militaryradio.com/spyradio/gra71.html These are available (though rare) on the surplus market, but I'm unaware of any of the original receiving equipment that has made it out to the hands of collectors. A SDR setup seems like a natural way to handle receiving the code burst and then either playing it back at low speed for manual decoding, or automatically decoding the transmission at normal speed. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum antenna input voltage on LFRX
On Dec 24, 2010, at 3:37 PM, Nick Smith wrote: I've looked through the mailing list archive and found a few messages related to this, but they referred to signal generators and power in dBm. In my case, I plan to use it with an antenna and eventually a pre-amp. However, I've found that by measuring the voltage from even a 3ft (90cm) antenna using a multimeter with a probe on the antenna and a probe to ground gives a reading of four volts RMS. With a 25ft (7.6m) antenna, I can slightly light up an LED (I don't remember the voltage), and with a 100ft (30.5m) antenna, I got about 140V. A multimeter has very high input impedance. If you attach a 50 ohm resistor(*) between the antenna and ground to simulate the input impedance of a radio receiver, then you should no longer see a measurable voltage with a multimeter. Also, a multimeter won't properly measure RF voltage. You're probably just seeing 60 Hz power line noise, unless you're very close to a high-powered transmitter. If there's a 100kW broadcast transmitter next door, then all bets are off. :) (*) or any other value you can get your hands on between around 25 and 500 ohms -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help with USRP wire?
On Oct 17, 2010, at 2:07 AM, Thunder87 wrote: Which type is this small wire, which connects USRP daughterboard with antenna? The coaxial cables that came with my USRP set appear to be made of type RG-316 cable. The LFTX and LFRX boards have SMA connectors. I think that the antenna connectors on the WBX board are MMCX connectors. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX and USRP1 on GnuRadio 3.3
On Oct 17, 2010, at 11:27 PM, Ed Criscuolo wrote: Is it possible to use a WBX daughtercard on a USRP1 with the 3.3 stable release of GnuRadio Yes. I am presently using my WBX in my USRP with the 3.3 release of GNU Radio via macports on my Mac. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange side-band when transmitting using WBX on USRP1
On Oct 13, 2010, at 8:45 PM, Drew Read wrote: We're having some problems with transmitting using the WBX board on a USRP1 (not an old one). We have a flow graph with a NULL source going into a NBFM, then through a multiply_const and into the USRP. At low frequencies (100MHz) the signal looks ok, but when we get up passed 500MHz we can see/hear that what should be an unmodulated carrier also has a single side-band (and is audible as a tone when demodulated) . And by increasing the const in the multiply_const, we can see our wanted signal getting stronger while the side-band remains there at a constant level. That sounds (and looks) like an issue that I encountered yesterday with my USRP + WBX. I was using it to generate some test signals in the 1.5-1.7 GHz range, and I found that there was a constant spur about 1-2 kHz above the transmitter's center frequency. I also found that I could reduce its effects by playing with the signal level, transmitter gain and an external attenuator. For now, I think I can work around it by simply generating my test signals at an offset from the transmitter center frequency and adjusting the center frequency to put them back where I want them, thus moving the spur out of the middle of my test signal. We've had a play with manually adjusting the DC offset of the USRP sink, which seems to change the size of the side-band a bit, but we don't really know what to do with that. I also found a bit of the transmitter center frequency bleeding through when I modulated it with no DC component. I haven't tried to mitigate this yet, but my workaround for the spur should also let me ignore this little bit of unwanted carrier for the time being. I presume that it's due to a small DC offset error in the DACs, based on the my observation of what appears to be a small (sub-LSB) DC error in the receiver ADCs. In my receive path, I found there to always be a received component at the tuned receiver frequency, and I found that I could null it out by adding a small (magnitude 1.0) complex constant to the USRP source output before it passed to the rest of my receive chain. Over the course of a few hours and a power-cycle, I found that I had to readjust the constant once or twice. This little error is pretty negligible when receiving larger signals, but it was annoying while I was trying to look at some pretty weak signals. I may be able to swamp it out with some external gain, but I didn't have an LNA handy yesterday to try that. For the time being, I'm going to try to ignore these DC components in both the receiver and transmitter by simply offsetting the LO a bit from the signal that I want to transmit or receive. I have to do some more tests tomorrow using my USRP as a signal generator, so I hope this will work. In the longer term, I'm interested in looking into whether there's a better approach to trimming out any DC offsets in the DACs and ADCs. I'm also interested in learning more about that unwanted spur in the transmit output (particularly since it's quite a bit larger than the component that appears to be caused by a small DC error). We've tried several USRPS and several WBX boards and seen the same problem on all of them. We don't see it on the USRP2. Interesting. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] want to achieve the symbol rate to 270.833kb/s
On Sep 25, 2010, at 10:41 AM, dburg...@kestrelsp.com wrote: We would have used 13 MHz, but the USRP-1 FPGA code fails to transmit for clock rates below about 48 MHz. Does anybody know why this is? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] s/Eric/Tom/g
I'm new here, but I can already tell that GNU Radio is Really Cool Stuff. Thank you for your great contributions, and I welcome our new overlord! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: making a small USRP board
On Aug 30, 2010, at 6:52 AM, William Cox wrote: As of yet, I'm trying to figure out if reducing the size of the USRP1 baord, by removing one of the transceivers, is feasible. I'm a GNURadio/USRP newbie and I'm just going off looking at the pysical board and thinking I didn't need half of it. Are you considering keeping the same form factor and connectors for the RF daughterboards (i.e., mounting regular RF daughterboards on a reduced-size USRP motherboard), or further shrinking the package size by integrating the RF and digital stuff onto a single, smaller board dedicated to a specific RF band? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: making a small USRP board
On Aug 30, 2010, at 8:24 AM, William Cox wrote: Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board. So, yes, same form factor for daughterboard connections. That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Warning in usrp_benchmark_usb.py
On Aug 30, 2010, at 8:15 AM, Federico Battaglia wrote: in testing the USRP I came across several warnings. Can someone tell me what they mean and if they are irrelevant? [...] @ubuntu:/usr/share/gnuradio/examples/usrp$ ./usrp_benchmark_usb.py Testing 2MB/sec... Warning: Treating daughterboard with invalid EEPROM contents as if it were a Basic Tx. Warning: This is almost certainly wrong... Use appropriate burn-*-eeprom utility. Warning: Treating daughterboard with invalid EEPROM contents as if it were a Basic Rx. Warning: This is almost certainly wrong... Use appropriate burn-*-eeprom utility. Those look relevant to me. Each RF daughterboard is supposed to have an EEPROM (memory chip) whose contents tell the gnuradio software what kind of board is installed. Your software is complaining that it couldn't identify the installed daughterboard(s), so their EEPROM(s) may need to be reprogrammed. There's some discussion of the EEPROMs here that might be helpful: http://gnuradio.org/redmine/wiki/gnuradio/UsrpFAQDBoards -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: making a small USRP board
Ah, I see. That sounds like a neat project. On Aug 30, 2010, at 10:44, William Cox wc...@ncsu.edu wrote: Mark, Going from 36 sq-in to 18 sq-in is a big improvement for us. We'll be using it on an underwater vehicle, and space is a premium. Your idea for a smaller WBX board is cool, but would be a lot of work. -William On Mon, Aug 30, 2010 at 11:44 AM, Mark J. Blair n...@nf6x.net wrote: On Aug 30, 2010, at 8:24 AM, William Cox wrote: Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board. So, yes, same form factor for daughterboard connections. That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ 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] USRP/gnuradio Issues in OS X
So far, the only way I've been able to get gnuradio to link against libusb-legacy has been to uninstall libusb-1.0. Even when I overrode pkg-config by setting the USB_* variables, it'd still (apparently) link against libusb-1.0 and then crash at runtime when it couldn't find the _usb_debug symbol. Hopefully I'll be able to find a workaround for this since I'd like to use some other stuff that requires libusb-1.0, but in the mean time this seems to have fixed my usrper problem. I configured this way: ./configure \ CC=/usr/bin/gcc \ CXX=/usr/bin/g++ \ LDFLAGS=-F/opt/local/Library/Frameworks -L/opt/local/lib \ CPPFLAGS=-I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d \ --with-fusb-tech=darwin Now usrper appears to be happy: ~/gnuradio% usrper -v load_standard_bits usrper: found unconfigured usrp; needs firmware. ~/gnuradio% usrper -v get_hash0 hash: ???7???g8!?_Md ~/gnuradio% usrper -v set_hash0 deadbeef ~/gnuradio% usrper -v get_hash0 hash: deadbeef ~/gnuradio% While I don't know what any of those usrper commands are actually doing, at least they seem to be not-crashing! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 24, 2010, at 4:58 PM, Michael Dickens wrote: Hi Mark - I'm glad you got it working; if you installed all of the background dependencies with MacPorts, compiling GNU Radio should be as simple as: [fix bootstrap] ./bootstrap ./configure Should be... but isn't. with no other options. IIRC, the 3 primary environment variables you need to have set are PATH (so that /opt/local/bin comes first), PYTHONPATH (so that /opt/local/lib/python2.6/site-packages comes first), and PKG_CONFIG_PATH (so that /opt/local/lib/pkgconfig comes first). You do not need to set --with-fusb-tech at all; it will auto-detect. You also don't need to set LDFLAGS as you have. Further, I don't think gr-qtgui is working on OSX just yet, so you really don't need to set CPPFLAGS either. And, you can have MacPorts select the CC and CXX for you via gcc_select -- so those aren't necessary. The --with-fusb-tech probably isn't necessary for me since I temporarily uninstalled libusb-1.0, but with that installed I found it to be necessary to specify --with-fusb-tech=libusb1 to get it to work. Anyhting else would cause the USRP code to crash when it failed to find the _usb_debug symbol. I have /opt/local/lib in my path, but I found it necessary to force the compilation to use the native compilers in /usr/bin instead in order to find the Mac frameworks. I chose to do this with the CC and CXX variables instead of gcc_select in this case. I modified my site.py file so it wouldn't be necessary to add that site-packages directory to my PYTHONPATH. The CPPFLAGS and LDFLAGS variable settings were necessary to get gr-qtgui to build, though I don't know if it actually works yet. In particular, some of the code included qwt and qwtplot3d headers without specifying their subdirectories (i.e., foo.h vs. qwt/foo.h), so I had to add the -I flags to get them to be found. I also had to add that -F flag for the linker to find the QtOpenGL framework. I don't know if there's something screwy about my system configuration, but that's what I had to do to get things to build and run. My question now is whether or not the other tests you talked about work (e.g., usrp_benchmark_usb.py). If that works, then you're good to go can play around with all the other pieces of GNU Radio USRP. Ah, good question. I've already been playing with some of the scripts such as usrp_fft.pw, usrp_siggen.py and a few others, and with grc, but there have been a bunch of pieces that didn't work. I'll try the benchmark script now that I've fixed (?) the USB stuff... Success! It consistently gives me one USB under-run (I think; it prints uU) at the beginning, but then runs and declares I can get 32MB/sec throughput. One of the other things that hasn't been working still isn't, but I think it's an unrelated error. When I run usrp_am_mw_rcv.py it complains: RuntimeError: gr_remez: insufficient extremals -- cannot continue But, I'm glad you've gotten this far. - MLD Thanks! I didn't expect it to be entirely painless (particularly since I'm running not-Linux here), and I'll keep plugging along. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 23, 2010, at 11:52 AM, Michael Dickens wrote: Hi Mark - I don't know where to point you exactly, since some tests work for you while others don't. You're using --with-fusb-tech=libusb1, which should work but hasn't been thoroughly tested (at least on OSX). Have you tried configuring without this flag then re-testing to see what happens? The native FUSB/OSX drivers do use the legacy libusb (as found on MacPorts), but they are well tested just as fast as those provided by libusb1. - MLD I have the lib...@1.0.8 port installed rather than the libusb-leg...@0.1.12 port, because (I think) I have other stuff that wants the newer libusb port. I discovered that I needed to use the --with-fusb-tech=libusb1 flag to get the configure script to properly identify my libusb version. Before I used that flag everything would compile, but the usrp executables would fail to find a symbol they needed in libusb and then crash. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 23, 2010, at 12:09 PM, Michael Dickens wrote: Hi Mary - So long as you use MacPorts for background dependencies, libusb1 and libusb-legacy (v0.1.12) can be installed at the same time you can easily choose between them (different PKGCONFIG files). Do note that libusb-compat does NOT work with FUSB/Darwin since GNU Radio's FUSB/LIBUSB code uses internals that are not in the 'compat' version (only the API is compat, not the internal implementation). On my MacBook Pro (10.5.8, i386), GNU Radio compiles and executes just fine using libusb-legacy -- so, if you're having issues using it let me know I'll see what I can do to help out. That said, I've also used libusb1 with some success -- so, you might have some other issue (e.g., a bad USB cable). - MLD I'll give libusb-legacy a try tonight (I don't have my USRP with me at work today). I'm sure I don't have a cable problem since I can transmit and receive signals with my USRP. Thanks for the suggestions! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get dqpsk2 block?
On Aug 21, 2010, at 1:46 AM, Thunder87 wrote: log repeatedly says: failed program was /* confdefs.h */ So I guess it's confdefs.h )) You have any idea what is it? That /* confdefs.h */ is just the first line of a temporary C program generated by the configure script to check whether some header file or function can be found. It's not the thing that configure is complaining that it can't find. For example, here's a snippet of my config.log file where it looks for the header file minix/config.h, and doesn't find it: configure:5554: checking minix/config.h presence configure:5554: /usr/bin/gcc -E -I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d conftest.c conftest.c:21:26: error: minix/config.h: No such file or directory configure:5554: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | #define PACKAGE_URL | #define PACKAGE gnuradio | #define VERSION v3.3.1git-47-gf6337c62 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | /* end confdefs.h. */ | #include minix/config.h configure:5554: result: no See, first it says that it's checking for the presence of minix/config.h. Next, it prints the command it used to check for that file (the /usr/bin/gcc line). Next, it prints the output of that command, where the C compiler said that it couldn't find minix/config.h. After that attempted little compilation fails, the configure script prints out the contents of the temporary little program it created for the failed test compilation (all of the lines beginning with |). Finally, is prints that the result of its test was no. In this case, it's not a problem for me that minix/config.h wasn't found. It's just a system-specific variation that the configure script is testing for. But when a gnuradio component isn't built, there will usually be come output that looks like this: configure:25705: result: no configure:25707: result: gr-audio-alsa requires package alsa, not found. configure:25742: result: Not building component gr-audio-alsa. There was a whole bunch of output right before this from configure's tests to see if it could find the alsa package, but the part that I would care about if I wanted to build gr-audio-alsa is just the line where configure tells me that it's not building gr-audio-alsa because it couldn't find the alsa package... so then I'd go looking for the alsa package and install it on my system to fix the missing dependency. At this point, you're not so much having a gnuradio problem yet... you're still learning how to understand the output of the configure script, which is created by the Gnu Autoconf tools. It's kind of complicated, but once you get over the learning curve this knowledge will apply towards working with lots of other open-source stuff, too. Keep plugging along, and you'll get there! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get dqpsk2 block?
On Aug 20, 2010, at 12:56 AM, Thunder87 wrote: Somehow managed to install git and get gnuradio source. Now I have a problem with source installation. sudo ./configure says: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gruel gcell gnuradio-core [...] These components will not be built. You're probably missing at least one required library, so it's not building any of the important parts of the gnuradio code. Look at the config.log file that was created by running configure, and find the first critical component that it decided not to build (probably gruel, and you'll most likely find it by searching for the word building), then try to figure out why it didn't build it. I think it's ok for gcell to not be built on most systems, but other components like gruel or gnuradio-core are critical. Here's a snippet of my config.log file as an example: [...] configure:21465: checking for byteswap.h configure:21465: result: no configure:21548: result: Component gruel passed configuration checks; building. configure:21590: checking whether host_cpu is powerpc* configure:21599: result: no configure:21606: checking for spu-gcc configure:21634: result: noconfigure:21667: result: Not building component gcell. configure:21937: checking for cblas_sgemm [...] Notice that it decided to build gruel, and not to build gcell, and that it didn't build gcell because it couldn't find the spu-gcc compiler. In your config.log file, it'll say ...result: Not building component gruel., and the lines (lots of them, including dumps of the test programs that failed) are what you'll need to study to determine what's missing. Some of the failures are probably innocuous (like my missing byteswap.h file, I think), and just indicate the sorts of system-specific variances that the configure script is looking for. However, there'll probably be at least one failure to find a critical library or header file, and that'll be your first clue about what else you'll need to look for and install. You will probably need to repeat the process many times before all of the critical components will build. You might also need to pass more arguments to the configure script, if you determine that it's not finding something that you're sure is installed on your system. While you're working your way through finding all of your missing required libraries, it may be helpful to temporarily add flags such as --with-gruel or --with-gnuradio-core to the ./configure invocation to make the script abort immediately after deciding not to build the specified component, rather than continuing on and making a zillion more lines of output for you to sift through. For example, since the critical gruel component isn't building on your system, nothing that comes after it in the configuration script matters until you fix that, and the --with-gruel flag should tell it to give up immediately after deciding not to build gruel. By the way, you should only need to use sudo to run the final make install step. None of the configuration and compilation steps before that should require root privileges. Good luck! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sma adapters?
On Aug 19, 2010, at 5:15 AM, dave k wrote: has anyone done a permanent install of a usrp1 or usrp2 with heavy duty feed line? pictures?? how to secure everything? my coax is just lmmr400 with a N Male, i need either a jumper cable or adapter. which has method works best? suggested vendors? thanks A short jumper cable between the thick LMR400 cable and the USRP might be a good idea for strain relief. You can order all of the required adapters and cables from a distributor like Digi-Key, or a cable/adapter vendor like Pasternack. Pasternack will also make custom cables in single quantity. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sma adapters?
On Aug 19, 2010, at 11:10 AM, Marcus D. Leech wrote: When I've had to do this, I've put an 'N' to SMA on the fat cable, and used a short piece of thin flexible cable with SMAs on it. That's exactly what I did in my semi-permanent GPS-disciplined oscillator installation. I also do the same thing when I connect my outdoor discone antenna to my USRP. Both of them have thick feedlines (similar to RG8, LMR400, etc.) terminated with male N connectors, and that's a lot of mass and leverage to hang off a little SMA connector. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote: It seems that 52MHz /64MHz precision clock references are like hen’s teeth, so I’m working on a design. What I need to know is what sort of level is the USRP1 looking for ? Is it 3.3V CMOS ? Once I get the design working, I’ll make them available at a reasonable price J I think you will get bonus points if your design can accept an external 10MHz reference provided by a GPS-disciplined oscillator. If there was some convenient way to adjust out the crystal aging for use when the external reference isn't available, that would be even better. I've been thinking of designing something along these lines, but I won't complain if you do the hard work and I can just buy one from you. ;) -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
On Aug 17, 2010, at 2:24 PM, Gregory Maxwell wrote: I'd also like to echo the 10MHz comment. GPSDOs Clocks with excellent long term stability show up at fairly low prices on ebay all the time (excess from cell site deployments, I assume). I have a couple of them. What they don't usually have is the very low phase noise that I'd want for a clock which is eventually going to multiplied up to GHz levels. So a USRP1 clock board which was primarily a 10-64MHz up-converter with very low phase noise would be exactly what I would want. For my bench frequency reference, I selected a surplus Trimble Thunderbolt with the newer version of OCXO that's supposed to be nearly as good as the HP double-oven OCXOs. I'll power it from an HP bench supply, since the switchers that are often supplied with the surplus Thunderbolts are said to add a lot of phase noise to the oscillator output. If the statistics from the monitoring program that I used during my first test run of the oscillator are to be trusted, then it should be able to provide a reference accurate to within tens of parts per trillion. I haven't finished installation of my GPSDO yet; I still need to finish repairing the (cheap, broken) HP bench supply that I got from eBay and assemble a power cable. I may get this done tonight, as the parts I needed just arrived today. The outdoor antenna (a surplus Lucent +26dB antenna as used at cell sites) is already installed and cabled into my house. My own idea for a USRP clocking replacement was to use a common and fairly inexpensive VCTCXO rated for temperature stability of around +/-2.5ppm (available at Digi-Key in frequencies commonly used in cell phones, GPS receivers, etc.), drive a PLL+VCO with that to generate 64 MHz (or 52 MHz, or any other frequency that the TCXO+PLL+VCO can generate), with an additional PLL to lock the VCTCXO to an external 10 MHz input. I'd also include a microcontroller which could measure the VCTCXO control voltage while locked to an external reference, and then drive that same voltage with a DAC when the external reference isn't present. Thus, while attached to the GPSDO the internal reference would be slaved to a very good reference, and then when that reference isn't available (such as when operating in the field) the on-board VCTCXO would at least be trimmed to compensate for aging. The memorization of the nominal VCTCXO tuning voltage might be triggered automatically, or by a push button, or by a GPIO controlled by the USRP hardware. The VCTCXO might be replaced with a voltage-controllable OCXO if desired for better holdover stability, but I figured that VCTCXO should be adequate for my needs. Does that architecture sound reasonable? If so, would anybody like to save me the trouble of designing and building it myself? ;) -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OCXO ' s
On Aug 17, 2010, at 5:07 PM, William Pretty Security Inc wrote: More Info on the parts I plan to use: At this point I have two possible fixed frequency parts: Silicon Labs Si590 series: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=590PC-BDG-ND Pletronics OHM4 Series: http://www.pletronics.com/products/select/ocxo1.php I think that the Pletronics part looks like a much better option. If I'm not mistaken, the SiLabs part is a computer-grade oscillator with much lower stability and accuracy than is typically required in radio communications applications. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP/gnuradio Issues in OS X
Hi! I'm new to gnuradio, and I just got my USRP several days ago. I'm trying to use it with my Mac running Snow Leopard, and I'm having some issues with some of the USRP utilities and examples. I've built the gnuradio software from the head revision in the git repository, with the pre-requisite libraries supplied by MacPorts. My USRP hardware appears to be working correctly, since I can run many of the examples such as usrp_fft.py, usrp_wfm_rcv.py, usrp_nbfm_rcv.py and usrp_siggen.py, all with reasonable results. Some of the other examples and utilities aren't working for me though. In this message I'll just focus on two of them: usrper and usrp_benchmark_usb.py. I've tried running the test routine (?), and it fails like this: ~% usrper load_standard_bits Assertion failed: (ctx != NULL), function usrp_find_device, file usrp_prims_libusb1.cc, line 184. Abort ~% I've also tried running the bandwidth benchmark, and it fails like this: ...examples/usrp% ./usrp_benchmark_usb.py Testing 2MB/sec... usrp: libusb_control_transfer failed: Unknown error usrp: failed to get hash usrp: libusb_control_transfer failed: Unknown error write_internal_ram failed usrp: failed to load firmware /usr/local/share/usrp/rev4/std.ihx. Traceback (most recent call last): File ./usrp_benchmark_usb.py, line 106, in module main () File ./usrp_benchmark_usb.py, line 96, in main ok = run_test (rate, verbose) File ./usrp_benchmark_usb.py, line 67, in run_test usrp_rx = usrp.source_s (0, rx_decim, 1, 0x32103210, usrp.FPGA_MODE_LOOPBACK) File /usr/local/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 2067, in source_s return _usrp_swig.source_s(*args, **kwargs) RuntimeError: can't open usrp ...examples/usrp% Some notes on my build environment: I found that I need to use the native gcc instead of the one provided by MacPorts in order for gr-audio-osx to build (it can't find some of the core audio headers otherwise), and that I need to pass some flags into configure so that the required libraries and headers are found. Also, MacPorts installs libtoolize as glibtoolize to avoid a name collision with the native Mac libtool program, so I created a symbolic from /usr/local/bin/libtoolize to /opt/local/bin/glibtoolize in order to get the bootstrap script to run. I configured the gnuradio software this way: ./configure CC=/usr/bin/gcc \ CXX=/usr/bin/g++ \ CPPFLAGS=-I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d \ LDFLAGS=-L/opt/local/lib -F/opt/local/Library/Frameworks \ --with-fusb-tech=libusb1 \ --enable-gr-qtgui \ --enable-gr-audio-osx The two --enable* flags probably aren't strictly necessary, but they are leftover from when I was finding the pre-requisites for those packages by trial and error. Everything seems to build OK, and I can use the USRP with some of the examples. I tried make check, and it passes a whole bunch of tests and then chokes when a test that I haven't identified yet complains about failing to connect to a socket. There are other examples which presently don't work for me, such as hfx2.py and usrp_am_mw_rcv.py... I'll try debugging those some more myself before I ask about them here. Have any of y'all seen these kinds of failures before? Thanks in advance for any hints or suggestions. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
