Re: [Discuss-gnuradio] Fwd: Problem with getting clear FM signals using the usrp e110
First 100k is insufficient sample rate from the E110. An FM station has
150 kHz total swing (+/- 75 kHz) so the frequency range of your E110
complex output is 100 kHz and is therefore insufficient for the entire
modulation. You then feed the 100k sample per second signal into the FM
block where you have informed it you will be sending 500 kHz (quadrature
rate) and then with no decimation at all, you send the 500 kHz sample rate
detected audio to a sound block where you've told it to expect 96 kHz audio.
[image: \left [ 0.9 \left [ \frac{A+B}{2} + \frac{A-B}{2}\sin4\pi f_pt
\right ] + 0.1\sin2\pi f_pt \right ] \times 75~\mathrm{kHz}]
is the instantaneous frequency of an FM stereo broadcast signal where A is
the left channel, B is the right channel and fp is the pilot tone frequency
(19 kHz).
Consider matching sample rates between these blocks as the software defined
radio equivalent of impedance matching between analog circuits in one
view of it.
Bob
On Wed, Apr 9, 2014 at 7:40 AM, Mike Jameson m...@scanoo.com wrote:
Here are some pointers for you:
- Firstly, your screenshot shows the error message saying that the RX
frequency is not valid. I'd recommend using a WBX daughterboard, however
the BasicRX should still work with strong FM signals with aliasing if that
is what you are using.
- The samp_rate is set to 100e3. It should be the master clock rate of
the e110 divided by an even number such as 64e6/256 (250e3).
- The quadrature rate in the WBFM receive block should be set to samp_rate
(250e3) and the Audio decimation should be set to 5.
- The audio sink sample rate should be set to samp_rate/audio_decim
(250e3/5=50e3). 50e3 is as close to the wanted audio sample rate of 48e3
that you are going to get without using one of the resampler blocks.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com
-- Forwarded message --
From: Abouda Yassine abouda21yass...@gmail.com
Date: Wed, Apr 9, 2014 at 12:09 PM
Subject: Re: [Discuss-gnuradio] Problem with getting clear FM signals
using the usrp e110
To: Mike Jameson m...@scanoo.com
hi Mike,
thx for offering help.I enclosed both a picture of the fm receiver and the
grc file(because i'm using the embedded gnuradio version on the usrpe
110),so it might not open correctly to you.I will be waiting for your
answer.
2014-04-09 11:47 GMT+02:00 Mike Jameson m...@scanoo.com:
Abouda,
If you attach your GRC file to your reply I'll take a look at it for
you. It sounds like a sample rate mis-match going on somewhere.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com
On Tue, Apr 8, 2014 at 12:18 PM, Abouda Yassine
abouda21yass...@gmail.com wrote:
Hello,
I followed this tutorial to build a simple FM receiver:
https://www.youtube.com/watch?v=KWeY2yqwVA0.I am using the USRP e110,my
problem is I am only getting noise.I tried to change blocks and parameters
and it worked for me when I deleted the rational resampler and made a 100k
as a sample_rate parameter.I get to hear FM radio stations but the quality
of the sound is very bad it's like on the SAW movie.Any one has a solution
on how to improve the sound qualitythx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] X300 PCIe issues
I have my new x300's. The NI ExpressCard-8360B is recognized by my Intel 5, Lenovo, 64 bit machine running U 14.04 LTS. I naively assumed that given the way things had gone before, that this would be a low impact out of the box experience. uhd_find_devices finds nothing. So I go and dig and find I need to do some things first. http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux The installer: sudo niusrprio-installer/INSTALL appears to work, but something is missing still. Unfortunately, the enabling and disabling usage lines don't work because some module the device is looking for has NOT been added to the kernel, much less done with automated update for the next kernel. Anyone who has faced and solved this issue, and gotten their PCIe interface to the x300 to work, please email, because I cannot afford to waste the weekend looking at TV. Bob -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] X300 PCIe issues
Okay, I thought that was it. I will back off to 13.XX LTS for now. Bob On Fri, Apr 25, 2014 at 6:28 PM, Matt Ettus m...@ettus.com wrote: You are using ubuntu 14.4 which has a new kernel. It will take us a little while to get our kernel module working with it. In the mean time, going to an older kernel or distribution will fix it. This does not affect ethernet connections. Matt On Apr 25, 2014 11:38 PM, Robert McGwier rwmcgw...@gmail.com wrote: I have my new x300's. The NI ExpressCard-8360B is recognized by my Intel 5, Lenovo, 64 bit machine running U 14.04 LTS. I naively assumed that given the way things had gone before, that this would be a low impact out of the box experience. uhd_find_devices finds nothing. So I go and dig and find I need to do some things first. http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux The installer: sudo niusrprio-installer/INSTALL appears to work, but something is missing still. Unfortunately, the enabling and disabling usage lines don't work because some module the device is looking for has NOT been added to the kernel, much less done with automated update for the next kernel. Anyone who has faced and solved this issue, and gotten their PCIe interface to the x300 to work, please email, because I cannot afford to waste the weekend looking at TV. Bob -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] X300 PCIe issues
Tim and I are going to swap back to 12.04.4 LTS. I suggest that some note to the installation for x3x0 say which versions of Ubuntu, kernels, etc. are supported currently. Thanks for your time. Bob On Sat, Apr 26, 2014 at 12:01 PM, Robert McGwier rwmcgw...@gmail.comwrote: Okay, I thought that was it. I will back off to 13.XX LTS for now. Bob On Fri, Apr 25, 2014 at 6:28 PM, Matt Ettus m...@ettus.com wrote: You are using ubuntu 14.4 which has a new kernel. It will take us a little while to get our kernel module working with it. In the mean time, going to an older kernel or distribution will fix it. This does not affect ethernet connections. Matt On Apr 25, 2014 11:38 PM, Robert McGwier rwmcgw...@gmail.com wrote: I have my new x300's. The NI ExpressCard-8360B is recognized by my Intel 5, Lenovo, 64 bit machine running U 14.04 LTS. I naively assumed that given the way things had gone before, that this would be a low impact out of the box experience. uhd_find_devices finds nothing. So I go and dig and find I need to do some things first. http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux The installer: sudo niusrprio-installer/INSTALL appears to work, but something is missing still. Unfortunately, the enabling and disabling usage lines don't work because some module the device is looking for has NOT been added to the kernel, much less done with automated update for the next kernel. Anyone who has faced and solved this issue, and gotten their PCIe interface to the x300 to work, please email, because I cannot afford to waste the weekend looking at TV. Bob -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] X300 PCIe issues
Backing off to Ubuntu 12.04.4 LTS was successful in getting the PCIe Express interface to build, dkms the kernel module, start and uhd_find_device sees the USRP x300. Now for the fun part using it. Finally: To all those entertaining PCIe interfacing, do not install a later version of kernel or distro than is KNOWN to support the interface. PCIe is most decidely NOT USB or GigE. Ettus would not be using a proprietary interface from NI with known working support for various kernels if it were not necessary. Having done multiple projects at work with PCIe, you use it when it is necessary and NEVER when it isn't. My application for the x3x0 series requires it. I find all the pieces of the needed documentation to make it all work NOT in one place. I will give a short summary today after I get my first app going using the device. Thanks, Bob On Sat, Apr 26, 2014 at 1:29 PM, Robert McGwier rwmcgw...@gmail.com wrote: Tim and I are going to swap back to 12.04.4 LTS. I suggest that some note to the installation for x3x0 say which versions of Ubuntu, kernels, etc. are supported currently. Thanks for your time. Bob On Sat, Apr 26, 2014 at 12:01 PM, Robert McGwier rwmcgw...@gmail.comwrote: Okay, I thought that was it. I will back off to 13.XX LTS for now. Bob On Fri, Apr 25, 2014 at 6:28 PM, Matt Ettus m...@ettus.com wrote: You are using ubuntu 14.4 which has a new kernel. It will take us a little while to get our kernel module working with it. In the mean time, going to an older kernel or distribution will fix it. This does not affect ethernet connections. Matt On Apr 25, 2014 11:38 PM, Robert McGwier rwmcgw...@gmail.com wrote: I have my new x300's. The NI ExpressCard-8360B is recognized by my Intel 5, Lenovo, 64 bit machine running U 14.04 LTS. I naively assumed that given the way things had gone before, that this would be a low impact out of the box experience. uhd_find_devices finds nothing. So I go and dig and find I need to do some things first. http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux The installer: sudo niusrprio-installer/INSTALL appears to work, but something is missing still. Unfortunately, the enabling and disabling usage lines don't work because some module the device is looking for has NOT been added to the kernel, much less done with automated update for the next kernel. Anyone who has faced and solved this issue, and gotten their PCIe interface to the x300 to work, please email, because I cannot afford to waste the weekend looking at TV. Bob -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] X300 PCIe issues
It needed to be said, but my only goal is to ACCEPT AND LOVE 10GigE until and unless you demand the low latency afforded by the PCIe interface. The things I am working on demand that we meet the tight timing requirements of open specification waveforms. PCIe was required. The x3x0 series are major accomplishments for Ettus and should they just get past the major changes that 14.04 LTS and then BE EXPLICIT about which kernels they will support, etc. They should be good until the next LTS comes out. Bob On Sun, Apr 27, 2014 at 5:48 PM, Marcus D. Leech mle...@ripnet.com wrote: On 04/27/2014 05:32 PM, Sylvain Munaut wrote: While the top side API is very stable so that applications hardly *ever* experience API changes that require on-going tedious maintenance, the same cannot be said of code that runs in the kernel. Quite the contrary. Linus and friends *routinely and regularly* change critical APIs within the kernel, sometimes even across minor version revs of the same codebase. Come on, it's not _that_ bad ... Kernel API are stable inside the maintenance release, so they can only change like every 2 month at most. And when they change, finding the relevant commit is pretty easy with git and it will show exactly what need to be changed in your driver (because that commit fixed every other driver in-tree for the same change). And searching LKML will also give all the gory details. It's like half a day or one day of work at the most. So 1 day of code maintenance every 2 month to keep your codebase current is not what I'd call a nightmare. And if you want to avoid even that, just get your module merged upstream, it will be adapted for you free of charge when APIs change. And wrt to maintaining the same code building for several kernel, that's just the wrong approach. Just maintain different version in different branches. When the code is well written, the driver specific part will be decoupled enough from the kernel api part that there will hardly be any conflicts. And when your driver core function doesn't change (and for the NI driver, it seems it hasn't changed it's functionality for a while AFAICT, just added new kernel support, but I could be wrong on that), then it's even easier to just release a new code for each new kernel. For only a few revisions appart, you might be ok with #ifdef, but if you're trying to go back to ancient times, like the NI module which seems to support 2.6.0 (that's 11 years ago ), yeah there is going to be some serious changes ... Cheers, Sylvain PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver for a FPGA board, so I did experience that. So, would we accept an applications-layer API that changed roughly every two months? I would argue, no, we wouldn't. But people developing in kernel land seem to accept it as some kind of necessary gospel. I reject that notion. Just because kernel-land is where all the kewl kids play is not a good reason to break things on a regular basis. Anyway, this thread is now going fairly far afield -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] X300 PCIe issues
I suspect that 10GigE works just fine. It is PCIe and PCIe express that will have the unique to a kernel release issues. Again, as I said before, if you have no idea why you would need PCIe, DON'T DO IT. Use 10 GigE. On Mon, Apr 28, 2014 at 10:39 AM, Lapointe, Benjamin - 1008 - MITLL blapoi...@ll.mit.edu wrote: Does the 10 Gigabit Ethernet PCI-express adapter card sold by Ettus work with Ubuntu 14.04 LTS? From the previous discussion, it sounds like the PCIe interface does not work with the new kernel, but that 10GigE might work. -Ben *From:* discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org [mailto: discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org] *On Behalf Of *Robert McGwier *Sent:* Monday, April 28, 2014 7:26 AM *To:* Marcus D. Leech *Cc:* Discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] X300 PCIe issues It needed to be said, but my only goal is to ACCEPT AND LOVE 10GigE until and unless you demand the low latency afforded by the PCIe interface. The things I am working on demand that we meet the tight timing requirements of open specification waveforms. PCIe was required. The x3x0 series are major accomplishments for Ettus and should they just get past the major changes that 14.04 LTS and then BE EXPLICIT about which kernels they will support, etc. They should be good until the next LTS comes out. Bob On Sun, Apr 27, 2014 at 5:48 PM, Marcus D. Leech mle...@ripnet.com wrote: On 04/27/2014 05:32 PM, Sylvain Munaut wrote: While the top side API is very stable so that applications hardly *ever* experience API changes that require on-going tedious maintenance, the same cannot be said of code that runs in the kernel. Quite the contrary. Linus and friends *routinely and regularly* change critical APIs within the kernel, sometimes even across minor version revs of the same codebase. Come on, it's not _that_ bad ... Kernel API are stable inside the maintenance release, so they can only change like every 2 month at most. And when they change, finding the relevant commit is pretty easy with git and it will show exactly what need to be changed in your driver (because that commit fixed every other driver in-tree for the same change). And searching LKML will also give all the gory details. It's like half a day or one day of work at the most. So 1 day of code maintenance every 2 month to keep your codebase current is not what I'd call a nightmare. And if you want to avoid even that, just get your module merged upstream, it will be adapted for you free of charge when APIs change. And wrt to maintaining the same code building for several kernel, that's just the wrong approach. Just maintain different version in different branches. When the code is well written, the driver specific part will be decoupled enough from the kernel api part that there will hardly be any conflicts. And when your driver core function doesn't change (and for the NI driver, it seems it hasn't changed it's functionality for a while AFAICT, just added new kernel support, but I could be wrong on that), then it's even easier to just release a new code for each new kernel. For only a few revisions appart, you might be ok with #ifdef, but if you're trying to go back to ancient times, like the NI module which seems to support 2.6.0 (that's 11 years ago ), yeah there is going to be some serious changes ... Cheers, Sylvain PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver for a FPGA board, so I did experience that. So, would we accept an applications-layer API that changed roughly every two months? I would argue, no, we wouldn't. But people developing in kernel land seem to accept it as some kind of necessary gospel. I reject that notion. Just because kernel-land is where all the kewl kids play is not a good reason to break things on a regular basis. Anyway, this thread is now going fairly far afield -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman
Re: [Discuss-gnuradio] GSoC14 Gr-trellis
Congrats! On Tue, Apr 29, 2014 at 4:28 AM, Jan Krämer kraemer...@googlemail.comwrote: Hey, another Google Summer of Code announcement! I'll be doing a project on speeding up gr-trellis! Whoever wants more info on my project can get it on Github https://github.com/spectrejan and I will post most of my updates on my GSoC14 Blog So if you're interested in my project then head to: http://spectrejan.blogspot.de/ Best Regards and thanks for having me on board! Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-specest dependencies
There are several dependencies for gr-specest not included in the recipe for pybombs and some not listed in the gr-specest list of dependencies but implied by the text. The recipe for gr-specest in pybombs doesn't include liblapack-dev, libblas-dev, and libarmadillo-dev. These include the list form the readme Howto build: In order to sucessfully build the gr-specest modules you will need: * cmake 2.8 * swig * libgnuradio-core * libuhd * gfortran (others might work as well, not tested) * liblapack-dev * libblas-dev but it will not compile, giving you an error about not finding BLAS and then you fix it by including armadillo which the readme wishes was deprecated, but most certainly is not. include: libarmadillo-dev on Ubuntu. Now, to construct some use cases that others can use like a guide post to what should be one of the most important gnuradio add-ons and wish I hope will help others use it. I will post stuff to my blog when it is ready. Bob -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build on ubuntu 14.04
And what is the size of the VM disk limited to and how much RAM have you allowed it? The step you are showing as exiting in (SWIG) requires lots of resources in building gnuradio. I hate SWIG, but have no idea what in the world we would do without it. On Sun, May 25, 2014 at 6:16 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi Michael, build-grc.sh is not known to me; I think you're referring to build-gnuradio? (grc is short for GNU Radio Companion, the graphical Flowgraph Designer included in GNU Radio). There have been problems with builds on Ubuntu 14.04. However, your output indicates no error; so I'm not quite sure how to help you. Maybe put the complete log somewhere on pastebin or gist.github.com? By the way, pybombs is the recommended way to go for modern systems. If you really just want a running Linux VM with GNU Radio installed, try the LiveDVD images: http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD Greetings, Marcus On 25.05.2014 11:29, Michael Hartje wrote: Dear list, I try to compile the new GR 3.7.4-git. But it breaks with pybombs as well as with the script build-grc.sh The job is done inside of a virtualbox-environment. host: win8.1, guest ubuntu 14.04 + updates Mem 1600 MB cut of the script build-grc.sh log -8 -- CPU missing cvtpi32_ps, Overruled arch avx -- Check size of void*[8] -- Check size of void*[8] - done -- CPU width is 64 bits, Overruled arch 32 -- Available architectures: generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2 -- Available machines: generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc -- BUILTTYPERELWITHDEBINFO -- Base cflags = -O2 -g -DNDEBUG -- BUILD INFO ::: generic_orc ::: GNU ::: -O2 -g -DNDEBUG -- BUILD INFO ::: sse2_64_mmx_orc ::: GNU ::: -O2 -g -DNDEBUG -m64 -mmmx -msse -msse2 -- BUILD INFO ::: sse3_64_orc ::: GNU ::: -O2 -g -DNDEBUG -m64 -mmmx -msse -msse2 -msse3 -- BUILD INFO ::: ssse3_64_orc ::: GNU ::: -O2 -g -DNDEBUG -m64 -mmmx -msse -msse2 -msse3 -mssse3 -- BUILD INFO ::: sse4_a_64_orc ::: GNU ::: -O2 -g -DNDEBUG -m64 -mmmx -msse -msse2 -msse3 -msse4a -mpopcnt -- BUILD INFO ::: sse4_1_64_orc ::: GNU ::: -O2 -g -DNDEBUG -m64 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -- BUILD INFO ::: sse4_2_64_orc ::: GNU ::: -O2 -g -DNDEBUG -m64 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt -- Compiler Version: cc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Loading build date Thu, 22 May 2014 18:56:46 into constants... -- Loading version 0.1 into constants... -- Using install prefix: /usr/local -- ENABLE_GR_LOG set to ON. -- HAVE_LOG4CPP set to False. -- LOG4CPP_LIBRARIES set to . -8 and some lines down during config of gnuradio -8 -- Boost version: 1.54.0 -- Found the following Boost libraries: -- date_time -- program_options -- filesystem -- system -- thread -- Enabling use of known bad versions of Boost. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] missing internal callbacks
It is a very difficult thing to implement practically and is so close to necessary limitation that you should just consider it necessary and move on. Bob On Thu, Jul 3, 2014 at 5:40 PM, emat...@yahoo.com wrote: Hello- when creating a flowgraph in GRC there are times I would like to change the decimation on-the-fly with a gui slider. However, this does not work because the decimation factor in blocks such as the AM Demod or Decimating Fir Filter does not have an internal callback (as I understand it). My main purpose is to be able to dynamically change the sampling rate to re-scale the x-axis in a gui fft sink while the flowgraph is operating. Is there a way around this? Is this a necessary limitation, or just something nobody has gotten around to implementing? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM
Ooops. Good catch Bastian.
On Fri, Sep 26, 2014 at 2:29 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
On 09 Sep 2014, at 15:42, Tom Rondeau t...@trondeau.com wrote:
On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
Hi all,
looking at the clock recovery MM code, I wonder if
d_omega_relative_limit is a relative or absolute deviation from d_omega.
Here it looks like absolute
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107
Here it is relative
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57
(even though this code has no impact since d_{min,max}_omega is not
used.)
I don’t have access to the book linked in the docs atm.
Best,
Bastian
It is supposed to be relative. I'd have to verify the math on that line
107 in the .cc file, but it's supposed to adjust the center position of the
current omega estimate and then apply the clipping. Then it adds the mid
point back to get it back to where it's centered. Try walking through that
line one more time to verify that it's doing that properly. But yes, it's
supposed to be relative to the original setting of omega.
So this line asserts that the current (absolute) deviation (d_mega -
d_omega_mid) is smaller than the maximum allowed absolute deviation
(d_omega_mid * d_omega_relative_limit). AFAIS, the second argument is
missing “* d_omega_mid”.
I will create a patch, then you can check if I got you right.
Bastian
Just to follow up, Bastian was correct and we merged his patch in this
week.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on how to derive a class in an out-of-tree module based on a gnuradio class
Zhe, every single developer who has ever written for GnuRadio runs into this particular swig necessity and searches like mad, certain it is done... Congrats. On Tue, Oct 7, 2014 at 8:18 AM, Zhe Feng feng...@umich.edu wrote: Hi Marcus, Martin and Bastian, Thanks for your help! You are right, it's a linker error, the reason is absolutely what Martin mentioned that I didn't refer the header files I used i.e packet_header_default.h in my swig file. I checked Bastian's swig file and made this class working as expected! Thanks again! Best, Zhe On Tue, Oct 7, 2014 at 6:39 AM, Bastian Bloessl bloe...@ccs-labs.org wrote: On 07 Oct 2014, at 12:02, Bastian Bloessl bloe...@ccs-labs.org wrote: I did that in gr-ieee802-11 and IIRC I had to define GR_API in the swig config arg, sorry! I had to #define DIGITAL_API and include packet_header_default.h https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i#L18 I think that I also had some problems with the swig bindings without those includes and defines. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Zhe Feng Electrical Engineering: System University of Michigan Ann Arbor Tel: 734-834-3188 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why is fft output complex?
Brad: You are treating an FFT as if it were a spectrum analyzer which produces a magnitude or energy profile of how much signal is at a particular frequency. The FFT does much more than that. It tells not only what magnitude is at a frequency but what phase angle the signal has there. Let's take an example: You would not want the fft of sin(t)+cos(2t) to be the same as sin(t)+sin(2t). You would want the result to show that the stuff at 2t is 90 degrees out of phase depending on what signal you input. Bob On Sat, Oct 11, 2014 at 5:38 PM, k1...@comcast.net wrote: I can't wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no? I'm trying to write a python script to analyze the energy across frequency bins but I don't know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. Thanks Brad. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_pll_carriertracking.cc
The last time I did this I had written the routine ;-) Bob On Nov 23, 2011 11:18 AM, Ben Hilburn b...@ettus.com wrote: Heh, sometimes you have to e-mail a public list before any of it makes sense. Happens to me all the time =) Cheers, Ben On Wed, Nov 23, 2011 at 8:53 AM, Marcus M gnu.f...@gmail.com wrote: On Wed, Nov 23, 2011 at 10:12 AM, Marcus M gnu.f...@gmail.com wrote: Hi, I have the latest gnuradio release and I think the phase error calculation in gr_pll_carriertracking.cc might be wrong. In Line 107 the phase error is calculated as, error = phase_detector(iptr[i],d_phase); whereas, I think it should be as shown below as the phase error is calculated from the signal that has been corrected in phase. error = phase_detector(optr[i],d_phase); Am I right? My bad. The phase_detector() function returns the difference. Ignore this message. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas loop and MM algorithm on FPGA
At high SNR, a single bit is probably enough in the detector and 15 bits in the phase accumulator is also likely more than enough. The error, in my opinion, is elsewhere. Tell us about your work here please: https://www.cgran.org/ after you have set up your git repository here: https://github.com/ and here are some useful instructions http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopingWithGit Thanks, in advance, for sharing Bob On Thu, Dec 15, 2011 at 1:52 AM, Phone Naing MYINT phonenaing.my...@sg.panasonic.com wrote: Hi, ** ** Anyone here implemented freq/phase correction and symbol timing correction in USRP’s FPGA? ** ** Recently I implemented Costas loop and Muller Mueller algorithm in RTL by referring the gnuradio code. Now I’m testing it on FPGA. I can get correct demodulated data(DQPSK) at initial few thousand symbols. After that I’m getting all rubbish data. ** ** I think the problem with my RTL implementation is not good enough bit-resolution (unlike implementation on PC). Currently I’m using 15-bits resolution for decimal part. Anyone has any suggestion ? ** ** PN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas loop and MM algorithm on FPGA
Congratulations. I knew you would find it since you were that close. Please share if you are allowed. I am certain we have wide spread interest in this particular piece of work. Bob On Fri, Dec 16, 2011 at 3:09 AM, Phone Naing MYINT phonenaing.my...@sg.panasonic.com wrote: Hi Bob, ** ** Your guess is correct, I found the error from Transmitter side. Now the synchronization is working fine. ** ** PN ** ** *From:* Robert McGwier [mailto:rwmcgw...@gmail.com] *Sent:* Thursday, December 15, 2011 8:53 PM *To:* Phone Naing MYINT *Cc:* discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com *Subject:* Re: [Discuss-gnuradio] Costas loop and MM algorithm on FPGA*** * ** ** At high SNR, a single bit is probably enough in the detector and 15 bits in the phase accumulator is also likely more than enough. The error, in my opinion, is elsewhere. ** ** Tell us about your work here please: ** ** https://www.cgran.org/ ** ** after you have set up your git repository here: ** ** https://github.com/ ** ** and here are some useful instructions ** ** http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopingWithGit ** ** Thanks, in advance, for sharing ** ** Bob ** ** On Thu, Dec 15, 2011 at 1:52 AM, Phone Naing MYINT phonenaing.my...@sg.panasonic.com wrote: Hi, Anyone here implemented freq/phase correction and symbol timing correction in USRP’s FPGA? Recently I implemented Costas loop and Muller Mueller algorithm in RTL by referring the gnuradio code. Now I’m testing it on FPGA. I can get correct demodulated data(DQPSK) at initial few thousand symbols. After that I’m getting all rubbish data. I think the problem with my RTL implementation is not good enough bit-resolution (unlike implementation on PC). Currently I’m using 15-bits resolution for decimal part. Anyone has any suggestion ? PN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ** ** -- Bob McGwier Facebook: N4HYBob ARS: N4HY ** ** ** ** -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD default subdevice.
Capture your complex command line in a shell script seems an easy way to do this yesterday, today, and tomorrow. Bob On Friday, December 23, 2011, Andrew Davis glneolistm...@gmail.com wrote: That might work, but why worry about people who reconfigure just yet, us who use the device consistently still have to type several args every-time we run a program, the first step is a simple default device config file. On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis glneolistm...@gmail.com wrote: -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Working at 20 MS/s
Able to use sample rates of 20 MHz doesn't necessarily include doing something as slow and killing of performance as display of an FFT. Bob On Tuesday, May 1, 2012, frankist wrote: Hi, I was interested in working with detectors for OFDM 802.11b in my USRP2. I've read on the internet about this and it seems that there are people able to use sampling rates of 20 MS/s. However, when I try to send an OFDM signal with 20 MHz of bandwidth, at the USRP2 receiver board the FFT plot shows the signal blinking. This effect only disappears for sampling rates as low as ~2 MHz. This will affect my detectors performance What is the main cause for this? Can it be solved? Regards, Francisco -- View this message in context: http://old.nabble.com/Working-at-20-MS-s-tp33763341p33763341.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org javascript:; https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC: Filter Design tool update
Adaptive filtering, whether FIR or IIR, will change the taps dynamically. I love the design tool idea. Bob On Wednesday, July 25, 2012, sreeraj r wrote: I didnt mean to imply that there was some kind of formal discussion tool like a forum thread. I was just referring to these emails: https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00142.htmlhttps://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00142.html https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00146.htmlhttps://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00146.html I think that a new parameter tag would include an import statement and a function to call. Example: param nameTaps/name keytaps/key value[0]/value typefloat_vector/type launcher importfrom gnuradio.filter import awesome/import functionawesome.function_to_call/function /launcher /param * I guess the idea would be that GRC adds a gui button the parameter that will invoke this launcher. It then calls awesome.function_to_call(current_param_setting) and when the function returns, the new value is set for the parameter. * Its not the only way to do this but that is one way to solve the problem in a generic fashion. I think the important part vs the idea you first purposed is that GRC does not have to know how to execute a program, it just calls a python function, which is something that it can easily do. Ok. I will proceed as you mentioned. * Once such a launcher is possible, it would not only be nice to add this to blocks with parameters that take taps. But it would also be nice to add a new variable block to GRC that simultaneously allows the user to use this tool, but set its output to a GRC variable. Because I think that it will be more desirable in certain cases to set the result to a variable. * Another block idea, how-about a GRC block that instantiates a GUI element that also calls the filter generation tool and sets the taps in a callback like fashion. This would give you access to using this tool in a live/running flowgraph! Let me know what you think, -josh Some users may just need fixed taps and some would like change those during runtime. I haven't looked into the code for flowgraph creation and execution of GRC yet, still it seems to be reasonable to give access to the filter design tool while the flowgraph is running. I will discuss this with Martin during the next call (I am sure he will see this mail ) and will start GRC integration ASAP. Integrating the tool to GRC will help me to find more bugs in my code, as many users will actually try filter design tool. I will try to accomodate all the features that you suggested. Thanks a lot for your comments and suggestions. -Sreeraj -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to test sse2 support using cmake
How about looking at the libvolk components and see how SSE is done and mimic? On Sep 17, 2012 12:51 AM, Kyle Zhou kyle...@gmail.com wrote: I have a block which depends on sse2. I need to tell cmake to check if the cpu support sse2 in order to determine if the sse2 acceleated version or a generic version should be used. This should be straight forward. However, I just cannot find an example CMakeLists.txt to get me a quick start. Any suggested readings? thanks K Z ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Job opening working for me
http://listings.jobs.vt.edu/applicants/Central?quickFind=196236 -- Bob McGwier Owner and Technical Director, Allied Communication, LLC Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File Sink open/close question
Hans: Where are you resetting X? On Tuesday, January 22, 2013, Hanz wrote: Hi! Im using a message queue to count data, while the data is sinked to a file. Then if the counter reaches X i want the old file to be closed and continue sinking in a new file. Then again if reaches X to switch to the old file. So my bottom part code looks like that: tb = top_block() tb.start() a=0 while 1: if tb.sink_queue.count()X: tb.gr_file_sink_0.close() tb.sink_queue.flush() if a==0: tb.gr_file_sink_0.open(PLACE_TO_SAVE\two) a=1 else: tb.gr_file_sink_0.open(PLACE_TO_SAVE\one) a=0 Right now, it simply closes the first file, but does not begin with the second one. Can anyone help me with that? Thanks in advance -- View this message in context: http://gnuradio.4.n7.nabble.com/File-Sink-open-close-question-tp39098.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org javascript:; https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Owner and Technical Director, Allied Communication, LLC Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-pager compile problem
I have seen several report gr-pager compilation problems. I ran into this on a computer. The solution was straightforward. I did not have ALL of the packages from http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall installed because given the apt-get command indicated on that page resulted in some installed packages. Once done, I did a make distclean ./bootstrap ./configure make and all went well. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Burg spectral estimation
Jens: Have you considered and rejected Pisarenko estimtion techniques or just not tried them yet? Thank you for your efforts Bob On Fri, Mar 26, 2010 at 6:58 PM, Jens Elsner jpels...@1c3.de wrote: Hi Brian, we've done some work to our 'Spectral Estimation Toolbox' and added Burg's algorithm for spectral estimation. It's all on CGRAN, see https://www.cgran.org/wiki/SpecEst This is good stuff; thanks for sharing! If you don't mind, I am curious of your experience of the Burg versus Welch implementation and results - which do you prefer? It looks like Burg translates to frequency domain first, and Welch stays in the time domain? Any idea how much of the bandwidth can be occupied before the algorithms are not relatively accurate anymore? In the presence high-noise, are the algorithms still able to detect the tones in your current setup? Welch's and Burg's method are very different approaches to spectrum estimation and both have their pros and cons. Burg can be better if fewer samples are available, but one has to be careful when choosing the filter order (model complexity). These questions are best answered in detail in the very good book by Stoica/Moses Spectral Analysis of Signals, Prentice Hall, 2005. Best regards, Jens ___ 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
[Discuss-gnuradio] Dayton SDR forum speakers sought
On Friday, May 14, I am the moderator (and speaker) at the SDR forum at the 2:30 PM - 5 PM session. I have two speakers (Scotty on openhpsdr, and I speak on general SDR topics). I need to fill out this time and this leaves at least 1.5 hours to fill. I would like to get this settled as soon as possible. Let me know if you are interested in making a presentation. Also, FYI, I will be the AMSAT/TAPR banquet speaker on Friday night. In addition to my forum, SDR, paper delivery with Joel Harrison, work in Flex booth, etc. this will be one of the busiest Dayton's for me in years. I look forward to seeing many of you. Bob McGwier N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dayton SDR Forum speaker list, times
Dayton SDR Forum is exciting this year. 4/5 of the talks are about HPSDR-related and that is good with a great list of speakers. Friday, 2:30-5 PM Gerald Youngblood, Flex updates 2:30 Lyle Johnson, Embedded Processors for SDR 3:00 John Melton, SDR GUI 3:30 Scott Cowling, HPSDR update 4:00 Jeremy McDermond, MacHPSDR 4:30 Bob McGwier N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Invitation to connect on LinkedIn
LinkedIn Robert McGwier requested to add you as a connection on LinkedIn: -- Abdul, I'd like to add you to my professional network on LinkedIn. - Robert Accept invitation from Robert McGwier http://www.linkedin.com/e/kcqq4e-gdaj09g6-6s/vd6zfNxBgx85xjU-yrUbg0DbdNCYdgCBPTBioq/blk/I822434776_3/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cRYSdPsQcPgOczx9bRtViTxIulBEbPwPdjsMe34Mdz4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Robert McGwier http://www.linkedin.com/e/kcqq4e-gdaj09g6-6s/vd6zfNxBgx85xjU-yrUbg0DbdNCYdgCBPTBioq/blk/I822434776_3/0PnPoTdPgPd38Oe4ALqnpPbOYWrSlI/svi/ -- DID YOU KNOW that LinkedIn can find the answers to your most difficult questions? Post those vexing questions on LinkedIn Answers to tap into the knowledge of the world's foremost business experts: http://www.linkedin.com/e/kcqq4e-gdaj09g6-6s/ask/inv-23/ -- (c) 2010, LinkedIn Corporation___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New audio registry names in v3.4.0git
Thanks to all, that is helpful. On Tue, Mar 22, 2011 at 12:08 PM, Johnathan Corgan jcor...@corganenterprises.com wrote: On Tue, Mar 22, 2011 at 09:38, Josh Blum j...@joshknows.com wrote: Potential fix: http://gnuradio.org/cgit/jblum.git/commit/?id=34313eace681a82e230c38a8cd26c0001ee823ea I pushed this into master. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus2 and RFX2400 For Sale
Is that something like mini-matt? On Fri, Apr 8, 2011 at 3:08 PM, Josh Blum j...@ettus.com wrote: On 04/08/2011 02:44 PM, jeremy ward wrote: I have an Ettus 2 and an RFX2400 that I don't need anymore. I used them a couple times and they work great. If you're interested just drop me a line. So you have one of Matt's helper clones. Ettus 2 escaped a few months ago and we could really use him back. Thanks! -Josh ___ 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] GRC questions
Is Josh Blum like Nicolas Bourbaki? If so we need to start a Wikipedia page for that committee as well. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
Is Josh Blum like Nicolas Bourbaki? If so we need to start a Wikipedia page for that committee as well. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sdcc and usrp in latest master copy
in attempting to force usrp to compile I did --enable-usrp. USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. configure: error: Component usrp has errors; stopping. n4hy@home gnuradio (master) $ which sdcc /usr/libexec/sdcc/sdcc n4hy@home gnuradio (master) $ sdcc -v SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Mar 20 2011) (Linux) r Houston, we have a problem ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sdcc and usrp in latest master copy
FC14, x86-64 Bob On Tue, May 3, 2011 at 12:05 PM, Robert McGwier rwmcgw...@gmail.com wrote: in attempting to force usrp to compile I did --enable-usrp. USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. configure: error: Component usrp has errors; stopping. n4hy@home gnuradio (master) $ which sdcc /usr/libexec/sdcc/sdcc n4hy@home gnuradio (master) $ sdcc -v SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Mar 20 2011) (Linux) r Houston, we have a problem ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] JTRS SCA
http://ossie.wireless.vt.edu/trac/ On Thu, May 5, 2011 at 4:24 AM, Jaco Meintjes jmeint...@csir.co.za wrote: Hi, Has anyone worked on JTRS (Joint Tactical Radios Sytems) SCA (Software Communication Architecture) with GNURadio and UHD? Regards, Jaco -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by * MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier rwmcgw...@gmail.com Amateur Radio Station: N4HY Engineer, Mathematician (Ph.D Brown University) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
Vlad It is apparent to me that you did not understand Josh's explanation. Possibly he was not forceful enough. ;-). This is not an error. It is the mathematical consequence of doing QAM with rotational symmetries. YOU MUST provide your OWN synchronization to remove the phase ambiguity. It is not a bug or an error. It is a feature. It is the mathematical nature of the beast. Bob On Thu, May 19, 2011 at 7:55 AM, Vlad Stoianovici stoianovici_v...@yahoo.com wrote: Dear list and Josh, I'm still getting this error when using the QAM Demod block (qamX_demod is not connected internally). Are there any new developments concerning these blocks? Vlad. Josh Blum-2 wrote: Well, when you receive a qam signal, and lock to it, you still have some unknown phase offset. Lets suppose qam8 has two possible phases: 0 and 180 degrees. Since you don't know which phase is correct, you can look for the packet header in the received signal at 0 degrees and simultaneously at 180 degrees. Whichever phase offset yields a valid packet is the winner. Of course, this all assumes that you are framing your data with some kind of packet headers. Anyone else have some qam demodulation ideas to share? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31655276.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier rwmcgw...@gmail.com Amateur Radio Station: N4HY Engineer, Mathematician (Ph.D Brown University) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and all is well. I get it from sdcc sourceforge site and was done in a few minutes. Bob On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com wrote: On 05/25/2011 09:01 PM, Arturo Rinaldi wrote: i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : *export PATH=/usr/libexec/sdcc:$PATH *as written in the build guide but I still get the error in the configure process : *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp.* Where am i wrong ? If I launch from terminal *$ sdcc -v * it returns : *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)* thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. A few points: If you're using UHD, you don't need component USRP. Since Fedora 14, they have shipped SDCC version 3.0 which has different command names, and also some difference syntax for built-in variable-type intrinsics, so the USRP1 firmware won't build under SDCC-3.0 anyway. The configure script for Gnu Radio looks for SDCC using the SDCC version 2.X command names, and so for a system with SDCC 3.0, this will fail. But, once again, if you're using UHD (which I *strongly* recommend), you don't need the component usrp and gr-usrp to be built anyway. I haven't upgraded any of my systems to F15 yet, but when I do, expect the famous (almost!) build-gnuradio script to get updated to deal with F15. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org And if you do really want to get the usrp and gr-usrp components to build, you should be able to easily install a 2.9 version of SDCC. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Raised Cosine Filter design
That is the best source currently in my opinion especially his discussion of HOW BAD RAISED COSINE FILTERS ARE AS NYQUIST FILTERS FOR DATA TRANSMISSION. Bob On Jun 29, 2011 4:11 AM, John Andrews gnu.f...@gmail.com wrote: Yep! Done. fred harris' book helped the most. Thanks On Tue, Jun 28, 2011 at 12:25 PM, Colby Boyer colby.bo...@gmail.com wrote: Look at the source code used to generate the raised cosine, gr_firdes.h should point to it. Making your own should follow directly from that; also the wikipedia page on the raised cosine is also nice. Its not black magic, so do not fear the source. :P --Colby On Tue, Jun 28, 2011 at 9:12 AM, John Andrews gnu.f...@gmail.com wrote: Hi, I want a raised cosine filter for the transmitter and can someone lead me to a place where I can develop one similar to what we have in gr_firdes.h Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Introducing noise/ considerable BER
I think that many RF and wireless designers make a lot of assumptions as well and never admit to the horror of the mobile channel. LTE is not really realizing the needed increase in capacity to justify the rollout cost of all of the needed infrastructure in my opinion but now everyone is all in. I am sure Sprint and others are happy LTE and WiMax are both having lots of problems. It is truly exceedingly difficult to enable MIMO big gains when lots of mobile channels, each a horror, need to be managed to achieve any real advantages. Welcome to reality! Verizon can't put a cloud computer at every cell site to enable the rapid channel inverse caclulations and MIMO solution per user to optimize the system. ;-) Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] APCO 25 crack using GnuRadio
http://tech.slashdot.org/story/11/09/10/1539217/Security-Researchers-Crack-APCO-P25-Encryption ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio on Mac OS X
Awesome On Sep 23, 2011 5:31 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Fri, Sep 23, 2011 at 2:57 PM, Michael Dickens m...@alum.mit.edu wrote: If you use MacPorts under Mac OS X 10.5, .6, or .7, sudo port install gnuradio should work as of this morning for installing all of the background dependencies (and, version GR 3.3.0 from the tarball if that's good enough). I had to fix SDCC 2.9 to work under 10.7, as well as tweak GNU Radio 3.3.0 tarball's configure script to correctly set the MD_CPU types under 10.7 (just like when 10.6 came out). It looks like the MD_CPU issue has been fixed since the 3.3.0 release, as the current GIT master seems to build cleanly and make check (as correctly as possible) on 10.7 (64 bit) with no changes (and with Volk disabled). The UDP QA code doesn't work any better on 10.7 than on 10.6. I think the primary OSX issue right now is setting the audio input device sample rate using using it as an audio source. There are a few of us looking into this issue as time allows; hopefully nobody is truly dependent on this feature when using OSX. - MLD Thanks Michael! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wiki Access
I don't know you seem pretty malicious to me ;-) On Mon, Sep 26, 2011 at 9:37 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Sep 26, 2011 at 9:08 AM, Martin Braun martin.br...@kit.eduwrote: Hi, I just created an account (mbraun) on the wiki website, and found out I can't edit pages with that. I guess the Wiki's configured to not allow new accounts, but isn't that a bit pointless given that everyone can use the 'guest' account anyway? MB Never attribute to *malice* that which is adequately explained by * stupidity.* I need to see if I can set up the redmine access to automatically assign a default permission to a project. Yes, you should be signed up as a reporter to the GNU Radio project page when you get an account. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Remote Access to USRP testbed with GNU Radio
I believe people are answering the question but are slightly off target. Create a group on your Linux distribution call USRP, make sure those users you want control the USRP as users (AND NOT ROOT) are in this group. The go read the gnuradio wiki about the other changes granting device permissions etc. This is how remote users gain control of the USRP locally without sudo as well as over SSH whether the machine is accessible over a LAN only or the full internet. Bob On Oct 6, 2011 7:15 PM, Ian Buckley ian.buck...@gmail.com wrote: Remember that you in fact are not required to Login to the USRP at all, it isn't an interactive device, more like a peripheral device to a host computer. Thus your remote access limitation is purely dependent on the remote host you utilize to run GNURadio to interface to the USRP. The main issue you are like to run into is using update intensive GRC graphical tools such as FFT via X or VNC which can be very problematic over WANs. In terms of the USRP itself, if the location is truly remote with no local support then it would be wise to utilize A USRP other than the USRP2 since this model requires the SDCard to be physically replaced to upgrade firmware+FPGA. It would also be wise to have a remote accessible PDU so you can power cycle the USRP if necessary. I've built austere lights out remote satellite ground stations that use USRP's with great success. -Ian On Oct 6, 2011, at 3:31 PM, Kunal Kandekar wrote: I have accessed and used a USRP over SSH before. In fact, I accessed it over the Internet, not just a LAN. Although I was not the one who set it up, as far as I know, nothing additional had to be done to enable this. I simply logged in as the user account under which GNU Radio had been installed. The machine was running Ubuntu, in case it matters. Kunal On Thu, Oct 6, 2011 at 6:04 PM, Guanbo Zheng gbzh...@gmail.com wrote: Hi, all We are interesting to build up a USRP testbed which allowed the guest remote access to do some experiments. I have seen someone's youtube video that they control the USRPs to transmit different signals through SSH access. But I want to double check if it allowed guest control of USRP devices ? Are there any other settings I need to take care of, in order to implement this? Thanks a lot for any suggestions! -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Remote Access to USRP testbed with GNU Radio
http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall has configuring USRP support. Following these instructions will allow users in the USRP group to run the hardware without root access. Bob On Fri, Oct 7, 2011 at 7:01 AM, Robert McGwier rwmcgw...@gmail.com wrote: I believe people are answering the question but are slightly off target. Create a group on your Linux distribution call USRP, make sure those users you want control the USRP as users (AND NOT ROOT) are in this group. The go read the gnuradio wiki about the other changes granting device permissions etc. This is how remote users gain control of the USRP locally without sudo as well as over SSH whether the machine is accessible over a LAN only or the full internet. Bob On Oct 6, 2011 7:15 PM, Ian Buckley ian.buck...@gmail.com wrote: Remember that you in fact are not required to Login to the USRP at all, it isn't an interactive device, more like a peripheral device to a host computer. Thus your remote access limitation is purely dependent on the remote host you utilize to run GNURadio to interface to the USRP. The main issue you are like to run into is using update intensive GRC graphical tools such as FFT via X or VNC which can be very problematic over WANs. In terms of the USRP itself, if the location is truly remote with no local support then it would be wise to utilize A USRP other than the USRP2 since this model requires the SDCard to be physically replaced to upgrade firmware+FPGA. It would also be wise to have a remote accessible PDU so you can power cycle the USRP if necessary. I've built austere lights out remote satellite ground stations that use USRP's with great success. -Ian On Oct 6, 2011, at 3:31 PM, Kunal Kandekar wrote: I have accessed and used a USRP over SSH before. In fact, I accessed it over the Internet, not just a LAN. Although I was not the one who set it up, as far as I know, nothing additional had to be done to enable this. I simply logged in as the user account under which GNU Radio had been installed. The machine was running Ubuntu, in case it matters. Kunal On Thu, Oct 6, 2011 at 6:04 PM, Guanbo Zheng gbzh...@gmail.com wrote: Hi, all We are interesting to build up a USRP testbed which allowed the guest remote access to do some experiments. I have seen someone's youtube video that they control the USRPs to transmit different signals through SSH access. But I want to double check if it allowed guest control of USRP devices ? Are there any other settings I need to take care of, in order to implement this? Thanks a lot for any suggestions! -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] I hate Unity
http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I hate Unity
Install gnome-tweak-tools to get advanced settings for gnome to be able to get your favorite settings after you install gnome-shell. On Mon, Oct 17, 2011 at 10:04 AM, Robert McGwier rwmcgw...@gmail.comwrote: http://tombuntu.com/index.php/2011/10/03/install-gnome-shell-in-ubuntu-11-10/ -- Bob McGwier Facebook: N4HYBob ARS: N4HY -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
Yes I have. I disconnected it. In my opinion, it is overkill for anything going on in a USRP1. YMMV, Bob On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia m...@cetilia.org wrote: wondering if anybody out there has replaced their usrp1 fan with something a bit quieter? i find myself listening to its incessant whine many hours a day, and it's starting to make me a little crazy— especially when i am trying to listen to subtle details… anybody have a suggestion for a decent replacement? cheers, mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
Top on. Fire up the fastest card you have (widest band signal you can process) and put your finger on the FPGA. It is cool. If the oscillator in the USRP1 were most stable and accurate, it might make some sense but it just doesn't in my opinion make sense so I disconnected them all in my USRP 1's. Bob On Tue, Oct 18, 2011 at 11:39 PM, Mark Cetilia m...@cetilia.org wrote: Ah good, glad to hear it's not just me… Do you run it with the top on or leave it open? Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 18, 2011, at 11:02 PM, Robert McGwier wrote: Yes I have. I disconnected it. In my opinion, it is overkill for anything going on in a USRP1. YMMV, Bob On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia m...@cetilia.org wrote: wondering if anybody out there has replaced their usrp1 fan with something a bit quieter? i find myself listening to its incessant whine many hours a day, and it's starting to make me a little crazy— especially when i am trying to listen to subtle details… anybody have a suggestion for a decent replacement? cheers, mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Facebook: N4HYBob ARS: N4HY -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wireless @ VT conference, GnuRadio Hackfest, and Vacancy Announcements
Hello friends. One of the centers I belong to at Virginia Tech is Wireless@VT. We run a conference every summer and we are holding it again this summer. http://www.wireless.vt.edu/symposium/2013/ And I know several of you are attending and we are looking forward to hosting you. At one time, before I came to Virginia Tech, I was a regular contributor to GnuRadio but tapered off to zero around 2010. You know how Poltergeists are, WEEE ARE BACKK. We will be hosting GnuRadio Hackfest immediately after the Wireless Symposium and please expect an announcement from GnuRadio folks about that soon. SPAM FOLLOWS: Finally, let me announce that my Center is doing a lot of GnuRadio development both blocks and applications. We are in a serious hiring phase for members of technical staff, program managers, etc. Please visit this web site to see these announcements: http://www.hume.ictas.vt.edu/vacancies Bob -- Bob McGwier Owner and Technical Director, Allied Communication, LLC Senior Member IEEE Facebook: N4HYBob ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DARPA Spectrum Challenge Finalists
Thanks to GnuRadio, USRP, and Joe Gaeddart's liquid DSP. http://www.hpcwire.com/hpcwire/2013-05-09/two_virginia_tech_teams_named_finalists_in_darpa_spectrum_challenge.html Forgive if this is a repost. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC
Well that is 80 dB of dynamic range inside the Nyquist zone (at best and let's call it N). I can add a bit of increase in dynamic range by downsampling (filter and decimation) and growing the accumulator size by a bit for each decimation by 4. This will increase dynamic range. I don't believe this is happening to a large extent in the N210 unless it is included in you 80 dB number which I believe is you just doing 14 bits of ADC is 80 dB. Bob On Mon, Sep 23, 2013 at 11:54 PM, Marcus D. Leech mle...@ripnet.com wrote: ** On 09/23/2013 11:07 PM, bob wole wrote: Can somebody please guide me on this ? Bob On Fri, Sep 20, 2013 at 4:44 PM, bob wole bnw...@gmail.com wrote: I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC ? if yes, which one? If not, then won't the varying input signal (for example signal from moving object) to ADC affect the performance of ADC ? Bob The ADC on an N210 has over 80dB of dynamic range. If that isn't enough, then your application can adjust the RF gain to taste. Only a subset of applications actually benefit from the usual hardware AGC schemes, and such schemes are invariably application-specific, so there's no *automatic* gain control. But your application can dynamically make gain adjustments as it goes. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Owner and Technical Director, Allied Communication, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Pybombs issue
I did an update to pybombs two days ago, and immediately gnuradio got to around 57% completion and just hung my Ubuntu 13.10 computer so hard, I couldn't get it to respond to ctrl-alt-del for over half and hour. I tried again after doing a force rebuild on gnuradio and it was worse. I long-hit the power button to do a reset. I checked the pybombs defaults and it is makewidth = 4, but it certainly acts like it is ignoring this and doing make -j . Further symptoms include a nonstop, hard green LED on disk writes on a 8 GB system. I have never seen it actually go to a major use of virtual memory (if that is what is happening) until now. I went into src/gnuradio/build and did a manual make -j4 and it worked perfectly, thus my diagnosis. Bob -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PYBOMBs Testing
All it DOES see if ice3.4. On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Thanks. I didn't know how or what to search for, so that was useful. Here's the result: p kde-zeroconf - zeroconf plugins and kio slaves for KDE p kde-zeroconf:i386 - zeroconf plugins and kio slaves for KDE p kde-zeroconf-dbg - debug symbols for kde-zeroconf p kde-zeroconf-dbg:i386 - debug symbols for kde-zeroconf p libmono-zeroconf-cil-dev - CLI library for multicast DNS service discovery p libmono-zeroconf1.0-cil- CLI library for multicast DNS service discovery p libqxt-zeroconf0 - library to use multicast DNS service discovery in Qt p libqxt-zeroconf0:i386 - library to use multicast DNS service discovery in Qt v libzeroc-ice-dev - v libzeroc-ice-dev:i386 - p libzeroc-ice-ruby1.8 - Ice for Ruby modules p libzeroc-ice-ruby1.8:i386 - Ice for Ruby modules p libzeroc-ice3.4-cil- Ice for C# libraries p libzeroc-ice3.4-java - Ice for Java libraries i libzeroc-ice34 - Ice for C++ runtime library p libzeroc-ice34:i386- Ice for C++ runtime library i A libzeroc-ice34-dbg - Ice for C++ debugging symbols p libzeroc-ice34-dbg:i386- Ice for C++ debugging symbols i libzeroc-ice34-dev - Ice for C++ development libraries p libzeroc-ice34-dev:i386- Ice for C++ development libraries p monodoc-mono-zeroconf-manual - compiled XML documentation for mono-zeroconf p php-zeroc-ice - Ice for PHP extension p php-zeroc-ice:i386 - Ice for PHP extension p pulseaudio-module-zeroconf - Zeroconf module for PulseAudio sound server p pulseaudio-module-zeroconf:i386- Zeroconf module for PulseAudio sound server p pulseaudio-module-zeroconf-dbg - Zeroconf module for PulseAudio sound server (debuggin p pulseaudio-module-zeroconf-dbg:i386- Zeroconf module for PulseAudio sound server (debuggin i python-zeroc-ice - Ice for Python libraries p python-zeroc-ice:i386 - Ice for Python libraries v python2.7-zeroc-ice- v python2.7-zeroc-ice:i386 - v zeroc-ice - p zeroc-ice-manual - Ice documentation in pdf p zeroc-ice34- Internet Communications Engine p zeroc-icee - Embedded edition of the ZeroC Ice Here's what I found in the gnuradio CMakeCache.txt file: ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so //Path to a library. ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library. ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so //Path to a program. ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details about finding ICE FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()] //ADVANCED property for variable: ICE_INCLUDE_DIR ICE_INCLUDE_DIR-ADVANCED:INTERNAL=1 PC_ICE_CFLAGS:INTERNAL= PC_ICE_CFLAGS_I:INTERNAL= PC_ICE_CFLAGS_OTHER:INTERNAL= PC_ICE_FOUND:INTERNAL= PC_ICE_INCLUDEDIR:INTERNAL= PC_ICE_Ice-3.5_INCLUDEDIR:INTERNAL= PC_ICE_Ice-3.5_LIBDIR:INTERNAL= PC_ICE_Ice-3.5_PREFIX:INTERNAL= PC_ICE_Ice-3.5_VERSION:INTERNAL= PC_ICE_LIBDIR:INTERNAL= PC_ICE_LIBS:INTERNAL= PC_ICE_LIBS_L:INTERNAL= PC_ICE_LIBS_OTHER:INTERNAL= PC_ICE_LIBS_PATHS:INTERNAL= PC_ICE_PREFIX:INTERNAL= PC_ICE_STATIC_CFLAGS:INTERNAL= PC_ICE_STATIC_CFLAGS_I:INTERNAL= PC_ICE_STATIC_CFLAGS_OTHER:INTERNAL= PC_ICE_STATIC_LIBDIR:INTERNAL= PC_ICE_STATIC_LIBS:INTERNAL= PC_ICE_STATIC_LIBS_L:INTERNAL= PC_ICE_STATIC_LIBS_OTHER:INTERNAL= PC_ICE_STATIC_LIBS_PATHS:INTERNAL= PC_ICE_VERSION:INTERNAL= __pkg_config_checked_PC_ICE:INTERNAL=1 Very Respectfully, Dan CaJacob On Thu, Jan 9, 2014 at 11:22 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jan 9, 2014 at 10:44 AM, Dan CaJacob dan.caja...@gmail.com wrote: Hey guys, thanks for the responses! I'm running Ubuntu 13.10 x64 and ICE version
[Discuss-gnuradio] Re: MP scheduler performance scaling
On Sun, Jul 20, 2008 at 12:08 AM, Eric Blossom [EMAIL PROTECTED] wrote: I've collected scaling data on several machines and it looks good! Executive summary: All your core are belong to us! I are more than pleased. ;-) Eric Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU-Radio GUI applications freeze
As Matt is so fond of pointing, I LOVE to install new toys. I have F 8,9, Ubuntu 8.04 with F8 and F9 on x86, x86_64, PPC, and Cell. I have Ubuntu 8.04 on x86, x86_64. They all do gnuradio. Bob On Mon, Sep 8, 2008 at 7:56 PM, Eric Blossom [EMAIL PROTECTED] wrote: Fedora 7, 8, and 9 are known to work fine. I us them. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Price
Matt has been really pushing to get the USRP2 perfect and out. He has ordered lots of them now and while I have no first hand knowledge, I would suspect that the WBX0510 has slid linearly in time with the slide of the USRP2. Matt would have to comment on this directly as I have no first hand knowledge (other than keen to get my hands on one). Bob On Tue, Sep 9, 2008 at 4:53 PM, Gregory Maxwell [EMAIL PROTECTED] wrote: On Tue, Sep 9, 2008 at 4:41 PM, Bob McGwier [EMAIL PROTECTED] wrote: The same daughter boards that work for USRP, work for USRP2. Any news on the WBX0510? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Important: New trunk dependency: GSL
In gnuradio-core, there will be new filter bank technology introduced that will use gsl to accomplish the debauchery of the indices in compact readable form. We are about to use gsl to compute discrete wavelet transforms. There are others but these suffice. One could always replace the underlying routines with local ones that are not bound to gsl. The simple facts are that gnuradio cannot be all things to all people. It might come closer than almost anything else but it cannot run without modification on all computing equipment from dspPic's to Vertex 5's to Cell to x86_64 to OMAP3XXX ! I really like the OMAP with its ARM9, TI DSP chip and Neon SIMD math chip and OpenGL acceleration hardware. It is a worthy target of effort. Bob On Wed, Sep 10, 2008 at 3:40 PM, Philip Balister [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 1:59 PM, Eric Blossom [EMAIL PROTECTED] wrote: I'll be adding the GNU Scientific Library (GSL) as a new dependency on the trunk. GSL is a huge numerical library that's been under active development for more than 10 years: http://www.gnu.org/software/gsl I've been making progress getting GNU Radio trunk running on the OMAP3 and now you toss this my way. Fortunately, OpenEmbedded already knows about gsl and it builds for the beagle. But, I am still curious, what parts of GNU Radio use gsl? Will it be possible to deply GNU Radio apps that do not need it? Or will gsl creep into the very core of GNU Radio? Philip Fedora, Debian and Ubuntu all package it. Under Fedora the relevant packages are: gsl-devel gsl pygsl: $ sudo yum install gsl-devel gsl pygsl I'm not exactly sure of the package names under Debian or Ubuntu. Could someone who knows please let us know and update the Debian and Ubuntu build pages on the wiki? I'll update the Fedora page. gsl-1.11 is the latest, but it looks like gsl-1.10 is what's widely distributed. 1.10 should be fine. Thanks! Eric ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Where's Waldo Ettus? At IEEE DySpan in Chicago of course!
http://www.youtube.com/watch?v=KOgjkSzFzOI ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu 8.10
I am too lazy to check to see if this has been commented on before. The boost, qwt,qt, qwtplot3d, swig, etc. in the Ubuntu 8.10 (Illness Incarnate), support the new requirements of the current svn level through configure, make, and make check. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 SD Card rewrite
On October 25 Matt wrote: Build the firmware by running make in the gnuradio/usrp2 directory Insert the SD card into the card reader, and the card reader into a USB port on your computer Run sudo u2_flash_tool --dev=/dev/ -t s/w usrp2/firmware/txrx.bin -w /dev/ has to be replaced with the device for the SD card This needs some small corrections I think. The correct instructions seem to be cd usrp2/firmware Run sudo ./u2_flash_tool --dev=/dev/ -t s/w ./apps/txrx.bin -w with the rest which I emphasize again. If you get the wrong for the device, you can wipe out your hard drive. Most people will have their hard drive as /dev/sda and on my computer it seems the device is, like Matt's computer, to be /dev/sdb. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Having difficulty with compiling in Ubuntu 8.04... due to QT3/QT4
Agreed, Tom and I don't have Qt3 on our systems as we have moved on. I think we need to change the tests to look SPECIFICALLY for qt4 since that is what we support. Bob On Fri, Dec 12, 2008 at 1:27 PM, Rob Frohne rob.fro...@wallawalla.edu wrote: Hi Everyone, After removing qt3-mt-dev, gnuradio builds just fine on Ubuntu 8.04. I don't think this is the real solution, but a work around because I at least still have some qt3 legacy code I haven't rewritten in QT4. 73, Rob, KL7NA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [hpsdr] [Discuss-gnuradio] Intel Atom is NICE.
The new I7 intel processors have a really amazing amount of horsepower but a tremendous amount of onboard stuff is designed to work intimately with the peripherals to bring on high speed graphics. Now if your argument is that all of this is going to be moved into the GPP, I might agree that we will see some of this. If you are arguing that the demand for an almost exponential increase in capabilities in graphics hardware for the purposes of virtual reality and rendering live and without memorex is not going to be happening, we are in profound disagreement. John, can you give me (and the others here) a pointer to the list of GPIB, etc. devices your fantastic stuff currently supports? I went from seeing it in the early days with a handful of things supported to seeing friends of mine (like W2GPS) running their labs with your code. Bob On Mon, Dec 29, 2008 at 8:31 PM, John Miles jmi...@pop.net wrote: Larrabee, I'm thinking, will be the real SDR platform of choice. A Larrabee box with USB 3.0 is going to put a staggering amount of DSP power into peoples' hands. It won't even make sense to mess with FPGAs at that point, I hope. GPUs are unquestionably an interim hack; I don't think they'll live to see the next decade. They'll go the way of the Weitek. -- john, KE5FX -Original Message- From: hpsdr-boun...@lists.hpsdr.org [mailto:hpsdr-boun...@lists.hpsdr.org]on Behalf Of Bob McGwier Sent: Monday, December 29, 2008 4:40 PM To: 'Newman, Timothy'; 'Marcus D. Leech' Cc: hp...@lists.hpsdr.org; flexra...@flex-radio.biz; q...@yahoogroups.com; tim.newman...@gmail.com; discuss-gnuradio@gnu.org Subject: Re: [hpsdr] [Discuss-gnuradio] Intel Atom is NICE. * High Performance Software Defined Radio Discussion List * And GPU's are going to become commodity priced quickly and possibly even move into the GPP and replace older ways of doing floating point. With Nvidia CUDA, you can write code for your GPP, call GPU with intrinsics to get pretty quick payback while a better longer term strategy is worked on. The future of really hard to program heterogeneous/not symmetric multiple core processors, irrespective of how great the bandwidth is, I don't think is looking all that rosy. It simply cannot take months and months to get speed to make the processor pay or the cost per flop, when ALL COSTS are amortized (expensive people, etc.) begins to look bad. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
I guess all's well that ends well. I have 64 bit Linux and Windows XP running on it. No hitches. I see what you are talking about. Bob On Sun, Jan 11, 2009 at 6:14 PM, Frank Brickle bric...@pobox.com wrote: On Sun, Jan 11, 2009 at 3:00 PM, Bob McGwier rwmcgw...@gmail.com wrote: IF ANYONE CAN SHOW ME WHERE IN THE INSTRUCTIONS IT SAYS THIS IS A TWO PASS PROCESS OR WHERE DURING THE COURSE OF DOING THE FLASH IT SAYS THIS IS A TWO STEP PROCESS, I WOULD BE PLEASED TO BE TOLD I AM BLIND. Well, sort of. I'd posted a note about this somewhat in advance of yours, with a link to the PDF directions. It's mentioned there that the update takes a fair amount of time, at least 5 minutes, and the process isn't complete if it hasn't taken that long. Nothing explicit about a two-step process, though. Quite misleading. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Congratulations Tom
http://www.vtnews.vt.edu/story.php?relyear=2009itemno=83 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Flexradio] [dttsp-linux] Intel ATOM WHOOAAAAA Nellie
http://www.nvidia.com/object/sff_ion.html I think it is pretty clear that almost anyone with any real experience would take Nvidia's restricted distribution graphics drivers about 100 to 1 over the open source CRAP that comes from ATI, and forget completely any of their competitors. I have removed from service every single ATI device which I am able to remove in the last few months because of the utter horror of their driver support. I have yet to have a single Nvidia restricted driver download fail once. BEWARE: YMMV. I attempted to make the point and Frank made it much more clearly. If you need Firewire, the ATOM D945GCLFx family (intel motherboard) is required to get the PCI slot. I am very happy with mine. I use it all the time. There is nothing wrong with it. Like all things, better things come along rapidly these days. What I am personally happy about is how cheap these offerings have been. I have NO IDEA what the price point will be on the Nvidia ION. I think the marketing hype video on the nvidia web page, showing the joint impact of the 2 GB of DDR3 and the Nvidia GeoForce 9300, is about right on target. In addition, the specs show that GigE is supported. I am expecting excellent performance because of the clear concentration of IO support in this box. The small footprint desktops have nearly 100% of the usable back covered with IO connectors. That bare space is not really bare. You need it to get your fingers in on the connectors! Bob On Fri, Feb 20, 2009 at 12:36 AM, Frank Brickle bric...@pobox.com wrote: On Thu, Feb 19, 2009 at 11:17 PM, Bob McGwier rwmcgw...@gmail.com wrote: ...HOWEVER, for those folks who want to build an small board computer for supporting the Flex family of firewire devices, the Intel motherboards are your only choice. You need the PCI slot to get the firewire support... For DttSP apps it's not a real choice. You will need a PCI slot, either for FireWire audio like the Edirol FA-66 or the PreSonus FireBox, or merely for some other halfway decent soundcard like the M-Audio Delta 44. This is a required configuration for effectively using sdr-shell, sdr-core, and the sdrTEC board, for example. A reference Linux implementation for this combination, with a cost of around $800US total for the RF front end + computer, is about ready to go up on CGRAN. The FireWire+Flex option is moot for dttsp-linux and vrk, but the other FireWire/PCI addons are critical. DttSP apps using the USRP1+GNU Radio are fine. USRP2 is an open question, for now. Short form: for dttsp-linux and general RF hardware, the Atom 330 is unquestionably the more utilitarian alternative. This is especially so when, given Nvidia's history regarding Open drivers, Linux support for ION is very uncertain in the near term (6-9 months). 73 Frank AB2KT -- Some people are like slinkies...not really good for anything, but they still bring a smile to your face when you push them down a flight of stairs. -- Anon. ___ FlexRadio Systems Mailing List flexra...@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Behrouz Farhang-Bourjeny and his book
Behrouz has improved his booked with editing and errata repair and having the material tried out on students. I used the book in a class in an early form, at work, and I am very happy to report that Behrouz continues to improve on the work. It does not yet have the OFDM chapter in it. I need to send Behrouz my comments on it but at this time as do others who have received the chapter, but at $16 for the pdf, it is a must have in its current form. I am honored he recognized the feedback I gave him from the classes Frank Brickle and I taught together and the use I have been making of it at the University of Maryland. Again, I am very happy to recommend this book in its updated form: http://www.lulu.com/content/1620824 Bob McGwier ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Software Defined Radio software authors are hard at work
http://www.youtube.com/watch?v=v4Wy7gRGgeA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SDR Forum at Dayton Hamvention
The SDR Forum at the Dayton Hamvention is Saturday 11:15 AM to 1:30 PM May 16. This is the ARRL National convention as well so it should be well attended. Because of missed emails, etc. (I was left off the email addressees so I got none of the emails) we are now in a rush. The initial list, etc. is supposed to be in DARA hands by April 1. This needs to be dealt with ASAP. I will contact some you should directly but I am soliciting 15-20 minute talks. I need at least an indiciation of willingness to speak, a few sentence abstract, and your willingness to be flexible in the timing as Irush this together. Thanks Bob McGwier ARS N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dayton SDR Forum so far
On May 16 2008 at the ARRL National Convention and the Dayton Hamvention we will have a software defined radio forum aimed at amateur radio operators. SO FAR: Bob McGwier, N4HY SDR update ( 15 minutes) Scott Cowling WA2DFI on HPSDR Project update (20 minutes) Frank Brickle, AB2KT, on VR and DttSP (20 minutes) Michelle Thompson, W5NYV on Microwave Engineering Project (http://bit.ly/G3nW) (20 minutes) Gerald Youngblood on the new Flex offerings (http://www.flex-radio.com/) (20 minutes) We have room FOR TWO MORE TALKS AND THAT IS IT. That will not count the fun we will have harassing Dave Toth relentlessly in the halls before and after! COME ONE COME ALL. The AMSAT and TAPR dinner will be that night. Richard Garriott, an amateur radio operator, computer game author, son of astronaut Owen Garriott and recent returnee from the space station where he was a space tourist will be the banquet speaker at the TAPR and AMSAT dinner! TAPR and AMSAT officially sponsor HPSDR. http://www.amsat.org/amsat-new/index.php Bob McGwier ARS N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SDR Forum at Dayton
Room 5, Friday PM http://www.hamvention.org/files/2009Forums-Friday.pdf See you there. Bob N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu 9.04 and GNU Radio
I am not able to configure and compile GR on Ubuntu 9.04 using the directions from the gnuradio.org/trac on any of three different machines on which I attempted to do the upgrade. I then tried on one of them doing a raw install (the one with the least stuff on it). The same failure occurs, so updates do not appear to be broken. Since several of us are making a big deal of gr-qtgui right now and about to roll out several things which we think will be of interest to people, it was disappointing to find that pyqt-qt4-qwt5 would not install, complaining about python-2.6 being too new a version. I think this is a temporary problem, caused by recent updates to Ubuntu 9.04 repositories, but thankfully, there is an easy remedy that just works. If you go the PyQwt home page, and download PyQwt 5.1.0 source, pay attention to the requisites and make sure you have apt-get them (sip4, pyqt-qt4-dev, ) , GR makes and runs with gr-qtgui enabled. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 9.04 and GNU Radio
I have removed the offending package from the build instructions on trac wiki This explains why Tom could get it to build and I could not get started! Thanks, Bob On Sat, Apr 25, 2009 at 7:23 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Sat, Apr 25, 2009 at 4:40 PM, Johnathan Corgan jcor...@corganenterprises.com wrote: On Sat, 2009-04-25 at 16:34 -0400, Robert McGwier wrote: snip And to clarify farther, we do not require PyQwt. We require the QWT library, but not the Python version of it. When I upgraded from Ubuntu 8.10 to 9.04 last night, I have been able to build and run GNU Radio just fine out of the box. However, I have heard that both Bob and at least one other person has had trouble with this. I would be interested to hear how other people are getting along with this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PlayStation 3
My initial readings of the playstation three blurbs/datasheets reveals they were incomplete. In addition to gigabit ethernet, it does have USB support. Phil Covington pointed out this page: http://felter.org/wesley/files/ps3/linux-20061110-docs/LinuxKernelOverview.html and Sony is supporting the kernel development. I spoke with knowledgeable people with Yellow Dog and have been having participating in ongoing talks with IBM and Mercury and this has all produced some good results. Now if we can only get our hands on one or more of these PS3's. If you want to get a real laugh, search for PS3 using froogle and look at all of the listings in the thousands of dollars. MADNESS. Anyway, now that we have very good information, I have placed my pre-order with Yellow Dog Linux FROM Yellow Dog Linux for $100. This is a nonrefundable deposit. If you do this, it comes preloaded with YDL, running when it shows up, and the delta price between PS3 and PS3+YDL is less than them individually. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair If you board the wrong train, it is no use running along the corridor in the other direction. - Dietrich Bonhoffer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [hpsdr] PlayStation 3
Sattler, Jay wrote: What Bob? You didn't order the Y-Bio 56 core Bioinformatics Cluster?? Maybe next time : ) How do I sign up? ;-). Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair If you board the wrong train, it is no use running along the corridor in the other direction. - Dietrich Bonhoffer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
make distclean; ./bootstrap;./configure;make;sudo make install definitely seems in order. Bob Johnathan Corgan wrote: On Tue, 2006-12-19 at 08:12 -0500, Greg Troxel wrote: Undefined PLT symbol _ZN14gr_basic_block11basic_blockEv (symnum = 81) This symbol is defined in a new file that was recently checked in, gr_basic_block.cc, in gnuradio-core/src/lib/runtime. For some reason it looks like this isn't getting linked in during the compile on your system, though it's definitely in the Makefile.am list of source files. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair If you board the wrong train, it is no use running along the corridor in the other direction. - Dietrich Bonhoffer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build errors
I am getting build errors on 3 different machines which heretofore have worked perfectly. It involves the pmt/mblock code. The failure to build comes in the last step of building the libmblock.so and libmblock-qa.so. pmt_nth, pmt_intern, pmt_wrong_type::pmt_wrong_type, are all listed as undefined references in the mblock library link statements and the build fails. Is anyone else experiencing this and have you fixed it? Eric and others are NOT experiencing this so I am trying to figure out what is going wrong on my 3 Ubuntu 6.1 machines with the problem. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair If you board the wrong train, it is no use running along the corridor in the other direction. - Dietrich Bonhoeffer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build errors
Agreed Eric Blossom wrote: On Wed, Jan 17, 2007 at 05:45:33PM -0500, Illix wrote: I'm getting the same problem (as far as I can tell) on an Ubuntu 6.10machine. The build fails with undefined references in libmblock.so and libmblock-qa.so. OK, I've looked at the log file that Bob sent me and compared it to what I see on my machines. The difference appears to be something in libtool. ---snip Although they both make the same call to libtool, libtool spits out a different command line on the two systems. On Bob's (and I assume Illix's) machine, the output of libtool contains --rpath (pointing to the install, not build directory!), whereas my machine lists the actual paths needed to find the pieces. I did a test before I read this note. I ran make install in the pmt directory after the mblock make fails. After this bandaid step, if I run make in the trunk directory, the make succeeds. I concur with your analysis. Don't you hate these kinds of issues? Bob's machine is using ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) I'm using (SuSE 10.1) ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) It looks like the Debian folks may have applied some kind of a patch to libtool 1.5.22 that could be causing the problem. Can any debian/ubuntu users figure out the difference? That is, what's the debian/ubuntu patch, and when and why was it applied? Thanks, Eric Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Linux PS3
This seems to be a useful site. It is referenced several places including the IBM web site. http://ps3.qj.net/category/Linux/cid/3003 and general: http://ps3.qj.net/index.php 73's Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PS3 shortage over?
My local Target, Walmart, and others have PS3's on the shelf. They have controllers, and accessories galore. That said, even with shipping, I saved money (taxes, etc.) by buying from Fry's. My early purchase from Terra (Yellow Dog) will be consumed by others when that comes to fruition so I didn't even lose my $100. I hope to have Fedora Core 5 on it next Thursday after I return from two days of working on HPSDR things in Maryland and will report my PS3/Linux results here. I assume you will not be interested in my wife's Tiger Woods golf score so I won't be reporting that. ;-) Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM in n4hy's tree
I am doubting the libtool error in this one. If you have the libtool error, it shows up well before this. You cannot complete the make. IF you cannot complete the make, and it dies in making the mblock message block code, then you can go back to the pmt directory and in that directory do install cd pmt make install cd .. make the make will now complete mblock in a few seconds and the rest of the tree will build. From there, I have no problems at all with the main branch. I have been UNBELIEVABLY tied up since the first of the year and I have no revisited the Rondeau, Ettus, and McGwier (n4hy) OFDM code since that time. I will make it tonight and see what happens. Tom will be here through the weekend and possible we can check into it if I discover a problem. Bob (n4hy) Eric Blossom wrote: On Fri, Jan 26, 2007 at 02:55:29PM -0800, Brett Trotter wrote: Brett Trotter wrote: I did a bootstrap, configure, make, make install on n4hy's tree and when I try to run ofdm_benchmark_tx, I get [EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 23, in ? from gnuradio import gr, gru, modulation_utils File /usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py, line 27, in ? from gnuradio_swig_python import * File /usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py, line 6, in ? import _gnuradio_swig_python ImportError: /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so: undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume there's a problem with my swig-python or swig- what versions of everything should I be using? Replying to myself here, I heard from someone that I should do make uninstall on the standard tree before doing make install on n4hy's tree. I make uninstalled both just to make sure it was cleaned out, and toasted /usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did make install of n4hy's - only to discover that _gnuradio_swig_python is now missing. Another make uninstall, another rm, and reinstalled the stable tree- which yields the same error. Why is make install not putting _gnuradio_swig_python in place do you suppose? Have I missed something? Which distribution are you guys using? I believe that the Ubuntu libtool problem is still unresolved. I'd really appreciate it if somebody who uses ubuntu would test and document a fix. I suspect that it could be as easy as rolling libtool back to libtool-1.5.22-3 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm2 branch
In branches/developers/n4hy Tom and I have added ofdm2. It contains a merge of the latest trunk with my ofdm directory. svn merge was unusable for this and it had to be built by hand. This branch will be the branch where ofdm work will be attempted by Tom, I, and others. Caveat, I need the c++ hierarchy and wanted the dial_tone example to work so this directory has been enabled in my branch. This enables me to bring ONE development branch into work for all my needs. I will attempt to keep this branch current with the trunk. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm2 branch
Johnathan Corgan wrote: Robert McGwier wrote: Caveat, I need the c++ hierarchy and wanted the dial_tone example to work so this directory has been enabled in my branch. The build system for C++ only applications has not been done yet. The dial_tone example assumes the existence of gr-audio-alsa, so anyone compiling off this developer branch will have problems if they don't enable gr-audio-alsa. This obviously means that non-ALSA systems like Win32 or Mac OSX will fail make/make check on this developer branch. Understood. That is why I was giving out a warning. If you are impacted by this, you can remove the references to c++ and c++/dial_tone in config/grc_gnuradio_examples.m4 and life will be peachy keen. I have to have both ofdm and c++ working by March 15. I would prefer not doing this with hacks but with the new hierarchy but this code needs to be running in some form for my applications. The ever silent Jason and I have to move forward smartly to meet this deadline. Thanks, Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Playstation 3
They are $599 at my local Target. So much for bargains at Costco. Bob Eric A. Cottrell wrote: Hello, I was at my local Costco tonight and noticed they have the 60GB PS3 for $699. I almost bought one but decided to check a Costco in NH first. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [dttsp-linux] dttsp-ps3
Both dttsp and gnuradio build on the PS3. I managed to get everything to install. As I have always found with redhat/fedora installations, what is absolutely seamless and without peer in Ubuntu is a royal pain in the derriere with Fedora. I had to add all of the PYTHONPATH, etc. as usual and I had to roust about on the internet for ppc rpm's to install wxGTK and wxPython since I was absolutely determined not to have to build them. The audio system on the PS3 with Fedora and Alsa is a little odd. I am unable to address /dev/dsp in any meaningful way. Portaudio correctly calls the devices (running pa_devs) but all of the examples fail in gnuradio-example/python/audio. I modified several to attempt portaudio and that failed. Make check failed in many places with a segmentation fault in run_tests.sh The build is slow because of the small memory so it would be nice to be able to push off the component build to a remoted machine. I will attempt to hook up my Extigy (USB) to see if that gives any joy tomorrow. I went from new toy to Fedora core 5 compiling jack, dttsp, and gnuradio in a week. We can do business with this. They are available in numbers (at $599) at my local target and walmart. Bob Frank Brickle wrote: You're building gnuradio right now? -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PS3 one more time
http://n4hy.org/ps3_fedora.jpg http://n4hy.org/ps3_dttsp.jpg http://n4hy.org/ps3_gnuradio.jpg Now to accomplish something useful. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Playstation 3
Eric Blossom wrote: On Sat, Feb 03, 2007 at 09:04:36AM -0500, Eric A. Cottrell wrote: Is the 20 GB version missing something important for linux/GNURadio use? Is it possible to put a bigger hard drive in? 20 and 60 GB hard drives are so last century. :) Besides the larger disk, the 60GB model adds: 802.11 b/g This does not work under PPC Linux on PS3 so far as I can find. I searched for hours on Sony, YDL, and qj.net (the worlds slowest site) before giving up and buying a 50 foot gigE capable cable. Memory Stick/SD/CompactFlash slots http://www.us.playstation.com/PS3/About/TechnicalSpecifications Eric -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] dttsp-ps3
Tom Rondeau wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:discuss- [EMAIL PROTECTED] On Behalf Of Robert McGwier Sent: Saturday, February 03, 2007 1:50 AM To: [EMAIL PROTECTED] Cc: gnuradio mailing list Subject: [Discuss-gnuradio] Re: [dttsp-linux] dttsp-ps3 Both dttsp and gnuradio build on the PS3. I managed to get everything to install. As I have always found with redhat/fedora installations, what is absolutely seamless and without peer in Ubuntu is a royal pain in the derriere with Fedora. I had to add all of the PYTHONPATH, etc. as usual and I had to roust about on the internet for ppc rpm's to install wxGTK and wxPython since I was absolutely determined not to have to build them. The audio system on the PS3 with Fedora and Alsa is a little odd. I am unable to address /dev/dsp in any meaningful way. Portaudio correctly calls the devices (running pa_devs) but all of the examples fail in gnuradio-example/python/audio. I modified several to attempt portaudio and that failed. Make check failed in many places with a segmentation fault in run_tests.sh The build is slow because of the small memory so it would be nice to be able to push off the component build to a remoted machine. Great stuff, Bob. When you say it's slow, about how long are you talking? Tom It took about 1/2 hour to build. A huge amount of time was spent swapping like mad to do the swig wrap. Everything else was speedy. fftw enables altivec for fftwf and that does have an impact. The Extigy is no real solution because it is USB 1.0. If they had a firewire on the thing I would be doing freebob already. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Playstation 3
It can and it does and I did it to component cables before I hooked up hdmi. I use my Sony LCD HDTV as the monitor (when it is needed) because the PS3 is used to play games. For compiles, etc., I do not turn on X and ssh in to a bash shell and work remotely. When we get the sound system sorted out, I will use the monitor to display some of the python gui examples locally. So far, it is a usable PowerPC. Until we get specific dsp and graphics accelerations using the SPE's, it is even an inexpensive PPC at the price in a nice compact package, but nothing more. I am pretty appalled at the status of Linux USB sound. We ran in to this problem two years ago when dealing with all sorts of issues (such as people wanting to use laptops) and I see that not much has really improved. There is a device snd_ps3 which I can find no instructions on how to enable and this discussion seems to indicate from the Ubuntu bigots that it does not work yet: http://ubuntuforums.org/showthread.php?t=343113page=2 So I tried to modify the examples to use oss. They fail. Portaudio (pa_devs) does identify the correct devices but fails to produce useful results so far in their "sound making" exemplars. Bob Dave Dodge wrote: On Sat, Feb 03, 2007 at 03:34:17PM -0500, Eric A. Cottrell wrote: What are PS3 owners on the list using for video displays? Do I need a HDMI monitor with HDCP? For DVI or HDMI, everything I've read says the signal will end up using HDCP, even when running Linux. Supposedly the "ps3videomode" command can configure high-resolution output on the analog component cables. It apparently even has RGB (instead of YPrPb) settings but I don't know how you'd wire that up. I have used a PS3 for games and movies with analog YPrPb at 720p and 1080i, attached to a Dell 2405 flat panel (which does not have HDCP on its DVI port). I haven't tried running Linux on it yet. -Dave Dodge ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest." - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM
The OFDM work has begun under my (n4hy) branch. Next week it will continue as I travel to Virginia Tech to work with Tom, Matt, and others on this and other work. When we have an OFDM transceiver and can drive one of the Flexible boards from Matt on the air, we will move it into the trunk so we can add FEC, interleaving, etc. easily and learn how Achilleas work needs to be optimized (if at all) to be used with this code. Bob (ARS N4HY) [EMAIL PROTECTED] wrote: I'm pretty new to gnu radio and I want to transmit an OFDM signal using different modulation types (BPSK, QPSK, and 64-QAM). The concept is pretty simple: read data, map it to a specified constellation map, and then send it through an IFFT. I don't know if this code already exists but I could use some help. Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM
In the n4hy developers branch, we spent today adding some new code and cleaning up a huge mess. The old temporary mess (ofdm2) is gone and ofdm has replaced it. This was current with the trunk this after and has the ofdm code. We transmitted with this in the lab today. My apologies for the svn confusion. We have achieved svn stability and are working on code. This will not be kept current with the trunk now until we are done with round one and ready to send and receive data and to give a compact description of the signaling to be used on the channel. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU make extension?
Thanks for the note. Please keep them coming so we can learn how to stabilize this across platforms. I made a modification to the grc_gt_qtgui.m4 file in config that fixes the disparity between Redhat/Fedora and Debian/Ubuntu qt.pc problems (thanks Jonathan for aiming me in the right direction). We will fix the qwt piece by adding all of the necessary AC_CHECK library and consequences so we do not have to use the rpm (similar to what is done for oss). Qt/Qwt is VERY impressive. On one 1.8 GHz laptop abacus, without the use of OpenGL, we got 340 frames of fftscope per second and it was resizing the screen EVERY frame. If we do not run into major difficulties in bringing qtgui into being as a usable replacement for wxgui, I am sure people will want to use it as it is so much more capable and faster and the scientific/engineering/signals widget in Qwt seem particularly suited to our needs. So after consulting Eric we decided that the best way to get this kind of feedback was to get it early and often since it seems to have so much potential. Matt, Tom, and I are concentrating on the ofdm branch for a bit as we try to perfect the synchronization but we'll return to the qt stuff shortly. Bob Johnathan Corgan wrote: Michael Dickens wrote: When bootstrap'ing the current trunk, I get the following. I doubt they're show stoppers, but I thought I'd let folks know ... - MLD gr-qtgui/src/lib/Makefile.am:29: `%'-style pattern rules are a GNU make extension gr-qtgui/src/lib/Makefile.am:33: `%'-style pattern rules are a GNU make extension gr-qtgui/src/lib/Makefile.am:36: `%'-style pattern rules are a GNU make extension gr-qtgui/src/lib/Makefile.am:60: filter moc_%.cc, $(qt_examples_SOURCES: non-POSIX variable name gr-qtgui/src/lib/Makefile.am:60: (probably a GNU make extension) gr-trellis/doc/Makefile.am:51: `%'-style pattern rules are a GNU make extension Okay, these are from the new gr-qtgui component that was just added to the trunk today. We'll (well, Bob Jason) will need to figure out how to set up the autotools to compile QT apps that is portable to gmake. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
This problem is understood. There is a change in libtool in the Debian/Ubuntu community. I believed this was fixed here by finding out some shell changes but it is not. If you cannot build mblock, you need to install pmt, which alway builds first. Go into the pmt directory and make install or sudo make install depending on your situation. Then when you go back to the base directory and do make, the mblock (and the rest of the) make will complete quickly. There are a couple of really aggravating things in Ubuntu 6.1 (maybe earlier) and libtool and link of sh to dash are at the top of my list. I could not understand what in the world was going on with these shells which had #!/bin/sh at the top from IBM for the Cell SDK (for example), and others, not working and really bombing badly. Ubuntu has placed /bin/dash, their step towards a posix compliant sh, in the symbolic link. Shell script authors have used sh in their scripts when they probably wanted the bash extensions and should have used bash. It is still a bit ugly to drop this on us without warning and to break so many shell scripts in the process. Bob Johnathan Corgan wrote: Josh Blum wrote: The same problem occurs on cygwin. I know cygwin is a lower priority, but the issue may not be ubuntu specific. -josh Roshan Baliga wrote: I've run into the same problem on Ubuntu 6.06 (Dapper Drake) at trunk rev 4662 (current). The trunk tree built fine for me on the same box a month ago. (I already tried make distclean and bootstrap.) Could you gentlemen please update and retry? -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS with DBSRX, Almost There
You have not read or internalized the specifications for the oscillator on the USRP which is intimately involved in this system. It is 50 ppm accuracy which is bad enough, but look at the can. It is begging to have thermal variances. Start up the usrp and your process and investigate Newton's Law of Cooling (blow on the oscillator) and watch everything dance! I stopped working on GPS until I could come up with a replacement. In my professional applications for the USRP, I am replacing the oscillator with an external stabilized injection. Bob Peter Monta wrote: Gregory W Heckler wrote: The real problem lies in the fact that the carrier tracking loop (a 3rd order PLL) of my software receiver cannot achieve phase lock. The phase jitter looks high, and the LO frequency drifts so much it dominates over the Doppler derived from satellite motion. Yes, it looks like my dbs_rx is wandering 10 Hz or so over timescales of a few seconds. A second-order loop with bandwidth of about 20 Hz seems to track all this out, but at the expense of noise---it would be nice to use a smaller bandwidth for a stationary receiver. Below are plots of 4 seconds of an actual dbs_rx recording (one point per millisecond). The first plot is unwrapped phase (y-axis in radians) and the second is the demodulated data after the PLL (also attached as an octave/matlab file). So things look reasonably okay for strong L1 signals, but there may be limits to how far the dbs_rx can be pushed for weak signals, if cycle slips are at all important. Maybe the strong PRNs can aid the weak ones, since the LO jitter is common to all. If anyone would like any GPS IF data I would be happy to email it to your personal email address (indicate how many seconds of data you would like). Thanks! I could take a look if you like---two seconds perhaps? Cheers, Peter Monta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM status
http://www.gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy is the trac and svn co http://gnuradio.org/svn/gnuradio/branches/developers/n4hy/ofdm gets you the source. I am merging the trunk into this about every 50 revisions unless I see major progress on mblock, usrp, etc that is of immediate relevance. Once we get a single instance running on hardware and over the air with some speed and reliability, I will suggest that we be allowed to merge this into the trunk and we can all play. I kicked the can down the road with Matt Ettus and Tom Rondeau. We have spent two weeks on this total and others are welcome to contribute. We need to have the argument: How do we specify the constellations? How do we map carrier usage (which are pilots, clocks, etc.)? In order to be really credible, we need mblock and we need the part that is running on the usrp because we need RSSI, it needs to be inband so we can do the gain management that is imperative for OFDM to work with its crest factor issues. Bob Kuntal Majumdar wrote: Hello, Who is doing the OFDM project? May I get some info on that, because my thesis project is on the same and I would love help in this regard. Thanks a lot. Regards, Kuntal No need to miss a message. Get email on-the-go http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail with Yahoo! Mail for Mobile. Get started. http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS with DBSRX, Almost There
There is a multiplier circuit/ PLL in the DBS-RX. Whatever phase noise is coming from the oscillator is being multiplied considerably by this upconversion to be used at LO in the DBS-RX. You cannot get low phase noise oscillators and high performance mixers in that small a package. Together these considerations imply more power and territory and thermal control than is available with the DBS-RX. Bob Marcus Leech wrote: Gregory W Heckler wrote: I measured the phase noise of the 64 MHz board clock. Looking at the result, I doubt the board clock is producing the phase noise I am seeing in my receiver. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PS3 success with audio
We definitely have work to do. Portaudio is the ONLY thing I can get to work the PS3 sound system but not in gnuradio. The pieces in the bin directory for testing portaudio that open the sink only work. I can produce tones, hundreds of tones, do latency tests, etc. gr-audio-XXX fails in all cases, including gr-audio-portaudio. I do not believe this is a python issue but I am unsure. The error message is a bit strange. If you download the svn for portaudio, and do configure; make; sudo make install, it puts the portaudio-2.0.pc in /usr/local/lib/pkgconfig unless you specify another prefix. Portaudio is working on the ps3 and the files in bin that begin patest_(produce a sinusoid of some type) make tones and work. Bob Eric Blossom wrote: On Thu, Mar 08, 2007 at 11:55:05AM -0500, Tom Rondeau wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:discuss- I literally have absolutely no idea what I have done, BUT, snd_ps3 is now found by PS3 running Yellow Dog Linux. At some time in the past two weeks while I was running around, I did an update (after Terra finally got my password fixed) and the sound system is found. I compiled and installed PortAudio and pa_devs finds the device and all of the test programs that are using only output work perfectly. Bob, are you using gr-audio-portaudio? I've installed portaudio from yum on FC6, but it's only on version 18 while the GR configure script is trying to find version 19. On top of that, when I installed version 19, there is no portaudio.pc file for pkg-config to look at. I'm sure this is all due to ignorance on my part with using portaudio devices. Thanks, Tom Tom, I'm not sure, but I'm pretty sure he's using ALSA. Eric ___ -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PS3 success with audio
Eric Blossom wrote: On Thu, Mar 08, 2007 at 08:15:47PM -0500, Robert McGwier wrote: We definitely have work to do. Portaudio is the ONLY thing I can get to work the PS3 sound system but not in gnuradio. The pieces in the bin directory for testing portaudio that open the sink only work. I can produce tones, hundreds of tones, do latency tests, etc. gr-audio-XXX fails in all cases, including gr-audio-portaudio. I do not believe this is a python issue but I am unsure. The error message is a bit strange. If you download the svn for portaudio, and do configure; make; sudo make install, it puts the portaudio-2.0.pc in /usr/local/lib/pkgconfig unless you specify another prefix. Portaudio is working on the ps3 and the files in bin that begin patest_(produce a sinusoid of some type) make tones and work. Bob Given that the Python stuff is still broken on PS3, I'm not surprised than gr-audio-* doesn't work. Just let me say that I am not certain this is a python error but until make check works, I cannot easily rule it out. Portaudio definitely works on the PS3 so we will have audio when we get stuff rolling. Eric Thanks, Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: pthreads / NT Threads under win32
BUT, pthreads/win32 is available from cygwin. It compiles with mingw or msvc. To my mind, they have done a good job. Threading code that Brickle wrote ran immediately under pthreads/win32. There is some chance omnithreads would work using this. Bob Don Ward wrote: Can any of you who build GNU Radio under MinGW or Cygwin please let me know whether our omnithread implementation ends up using pthreads or NT threads? You should be able to tell by looking at the output from running configure. If you see a message checking for NT threads it means we didn't find pthreads. GNU Radio uses pthreads on Cygwin, but uses NT threads on MSYS/MinGW. Why I ask, is that I'm considering removing the support for NT Threads in gr_omnithread. If we did this, we could then take advantage of the posix thread cancellation features, which aren't currently available in the omnithread interface. Could you elaborate on what you want to do? Would we use pthreads directly or would we still be using omnithread? Should we find out if Pthreads-win32 http://sourceware.org/pthreads-win32 can be used in GNU Radio? I would be happy to help if that is what is needed. I prefer to use GNU Radio on MSYS/Mingw and am willing to put in some effort to keep it running there. -- Don Ward ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Memory leak in wxgtk
I have been running the usrp wfm stereo receiver for a few hours under Feisty Field Rat from Ubuntu. The memory percentage for the python is absolutely steady at 4.0%. The same with the Xorg process (at 1.9%). It appears the memory leak has been repaired. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FeistyFawn problems again :(
I still get this as well. So far, the following technique (abhorent as it is) works 100%. power off the USRP and power it back on causing it to enumerate and come up raw. After that, the load works every time. Bob Eric Blossom wrote: On Wed, Apr 25, 2007 at 02:32:44PM +0200, konvak wrote: hi all, I read the previous posts about FF + gnuradio, but I still have some trouble I have fresh install of FeistyFawn, fresh install of gnuradio 3.0.2(ubuntu package), I have group usrp with me in it, I have 10-usrp.rules in place but strange thing happens. I can only find usrp the very first time when I plug it in and usbview says Unknown device, after that it always says RuntimeError: Unable to find USRP #0, even though I can see it in usbview as USRP rev 4. thanks for any help, tomas Thanks for the report. I'll take a look at it. It may take me a couple of days to get to it. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest. - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
