[Discuss-gnuradio] git clone hanging
Has the git repository been affected by the server issues experienced at gnuradio.org? $ git clone http://gnuradio.org/git/gnuradio.git The above hung at "Cloning into gnuradio..." for a long time and then gave this error: error: Recv failure: Connection reset by peer while accessing http://gnuradio.org/git/gnuradio.git/info/refs fatal: HTTP request failed Is there a way to download over the git port? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio website downtime
On Fri, Oct 28, 2011 at 17:28, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > Due to disk corruption in the volume that stores the MySQL database > back-end to the GNU Radio website, it has become necessary to restore from a > backup. Fortunately, we have daily backups that go back several weeks, so > our data loss will be limited to any changes in the website since yesterday. > > I will send a note to the list when things are back up and running. > The disk volume has been replaced with the backup from approximately 20 hours ago, and the site is back up. If you have made any wiki edits, bug reports, etc., in that time, please check to see whether they need to be redone. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio website downtime
All, Due to disk corruption in the volume that stores the MySQL database back-end to the GNU Radio website, it has become necessary to restore from a backup. Fortunately, we have daily backups that go back several weeks, so our data loss will be limited to any changes in the website since yesterday. I will send a note to the list when things are back up and running. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Job posting
Hello, The company I work for is currently looking to hire an engineer with experience in signal processing. We are looking for someone that can assume leadership over the complete design and development of our client/server software. We need an experienced engineer with the following abilities: * writing signal processing software - filtering, fft, etc. * complex algorithm design * multi-threaded, C++, TCP/IP server applications on Linux * software optimization It would also be helpful if you have experience with any of the following: * Qt SDK * Intel SSE * Intel® Threading Building Blocks * real-time software * Amazon AWS. This is a full-time job for a funded, start-up company. This is not an SDR job, but it does require expertise in many of the disciplines required for SDR. The successful candidate can work (telecommute) from their own home office, or in our office in Orange, CA. Very little travel is required - maybe once or twice per year. Please send CV, or resume to h...@spot411.com Please feel free to pass this on to anyone that might be a good candidate. Thank you very much, Hans ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SDR question
On 28/10/2011 5:31 PM, Andrew Rich wrote: Thanks Marcus So you can go outside the useable bandwidth, you just need to understand that you will loose something as you move to the next chunk of RF ? Generally, the hardware samples at a fixed rate (USRP1 samples at 64Msps, and USRP2/N2XX sample at 100Msps for example). From the hosts point of view, if the tuned frequency is X, and the requested bandwidth is Y, your baseband extends from X-(Y/2) to X+(Y/2). Not sure what you mean by "loose something as you move to the next chunk of bandwidth". I saw an image of several MHz and a little decode window, but I guess that is a decoding window, smaller than the SDR sampling window. It is often the case that an actual application will bring in more bandwidth than it strictly needs--usually because the application-specific bandwidth is a little bit smaller than one of the integer fractions of the samplers input bandwidth. So you typically bandpass-filter in software to whatever the bandwidth of your application is, and then possibly down-sample, or not, depending on the application. Let's say your sampler front-end runs at 100Msps, and you really only want 75Khz of bandwidth. On a USRP2 or N210, the maximum decimation value is 512, which produces a sample rate of 195312sps, (100e6/512) since this is complex-baseband, that 195312sps is *also* 195312Hz of usable bandwidth (in a sense, complex sampling "cheats" Nyquist). So, you'd place a bandpass filter in the signal path to filter it down to 75Khz, before you did anything else with it in the signal flow. I want to use SDR for satellites and packet radio Does it meet a tnc / analogue radio specs ? An SDR-based platform would have no trouble doing at least the modulation and radio parts of a TNC, although implementing something like AX.25 in Gnu Radio is likely a poor architectural choice. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault
On 10/28/2011 12:20 PM, Vanessa Gardellin wrote: > Please let me know if you solve the problem, I also have a seg fault... > So help me help you... What version of gnuradio? What version of uhd? Do the uhd example apps work? Can you import the gnuradio python module? What about making a quick FFT app in gnuradio companion (uhd usrp source -> fft sink)? Does that work? This could be an ABI mismatch, or maybe a bug. Have you tried updating and rebuilding? -josh > Thanks > Vanessa > > On Fri, Oct 28, 2011 at 4:41 PM, Josh Blum wrote: >> >> >> On 10/28/2011 04:03 AM, doering@googlemail.com wrote: >>> Hello list, >>> >>> I tried to launch the "uhd_fft.py" script with the following command line: >>> >>> "uhd_fft.py -a type=usrp2 -f 935M -s 2M" >>> >>> >>> My problem is that my terminal always returns this output: >>> >>> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae >>> >>> -- Opening a USRP2/N-Series device... >>> -- Current recv frame size: 1472 bytes >>> -- Current send frame size: 1472 bytes >>> -- mboard0 is MIMO master >>> Segmentation fault >>> >>> >> >> Does uhd_usrp_probe work? If so, is there a particular line in >> uhd_fft.py that causes the seg fault? Have you debugged w/ gdb? >> >> In any case, I recommend upgrading to the latest release, then see if >> there is still a problem. >> >> -Josh >> >> >>> I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo CPU P8600 @ >>> 2.40GHz × 2, USRP N210 with WBX. >>> I also use ClockTamer as reference for the internal XO and 2 normal GSM >>> 900 antennas. >>> >>> I would really appreciate if someone has an idea on what I am doing >>> wrong here. >>> >>> Thanks in advance! >>> >>> Sebastian >>> >>> ___ >>> 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] SDR question
Thanks Marcus So you can go outside the useable bandwidth, you just need to understand that you will loose something as you move to the next chunk of RF ? I saw an image of several MHz and a little decode window, but I guess that is a decoding window, smaller than the SDR sampling window. I want to use SDR for satellites and packet radio Does it meet a tnc / analogue radio specs ? - Andrew - - Original Message - From: "Marcus D. Leech" To: Sent: Saturday, October 29, 2011 7:16 AM Subject: Re: [Discuss-gnuradio] SDR question On 28/10/2011 5:08 PM, Andrew Rich wrote: I have a question about software defined radio I saw a pass band the other day on a screen which prompted me to ask The Software defined radio has a specific bandwidth ? Does it "scan" across the band very quickly to form the passband, or is the bandwidth already that large it just appears as a chunk of MHz ? I am trying to make the connection between how a Software Defined Radio would be different from an analogue system. For example decoding packet radio using an SDR, is there any performance degradation due to the way it works ? Would the SDR "sweep" and miss some of the signal ? - Andrew VK4TEC - A typical SDR hardware front-end (just taking the RX view for now) has a tunable direct-conversion down-converter that converts a swath of bandwidth at a desired center frequency into a complex (I,Q) baseband signal that "straddles" from -BW/2 to BW/2, with "DC" in the middle. That swath of (analog) bandwidth is sampled by an ADC and FPGA, and then decimated for delivery of a lesser bandwidth (again, in complex baseband form) into the host computer for further processing. The decimation also acts as a filter, so that there is strong alias suppression in the delivered bandwidth. It is usually the case that the FPGA decimator is configurable with respect to the amount of bandwidth delivered towards the host. Bandwidths of several MHz into the host are achievable these days, with all demodulation, etc, happening on the host. That is not to say that you couldn't implement a sweeper for doing SIGINT and spectral estimation, etc. In fact, there are Gnu Radio applications that do just that. ___ 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] SDR question
On 28/10/2011 5:08 PM, Andrew Rich wrote: I have a question about software defined radio I saw a pass band the other day on a screen which prompted me to ask The Software defined radio has a specific bandwidth ? Does it "scan" across the band very quickly to form the passband, or is the bandwidth already that large it just appears as a chunk of MHz ? I am trying to make the connection between how a Software Defined Radio would be different from an analogue system. For example decoding packet radio using an SDR, is there any performance degradation due to the way it works ? Would the SDR "sweep" and miss some of the signal ? - Andrew VK4TEC - A typical SDR hardware front-end (just taking the RX view for now) has a tunable direct-conversion down-converter that converts a swath of bandwidth at a desired center frequency into a complex (I,Q) baseband signal that "straddles" from -BW/2 to BW/2, with "DC" in the middle. That swath of (analog) bandwidth is sampled by an ADC and FPGA, and then decimated for delivery of a lesser bandwidth (again, in complex baseband form) into the host computer for further processing. The decimation also acts as a filter, so that there is strong alias suppression in the delivered bandwidth. It is usually the case that the FPGA decimator is configurable with respect to the amount of bandwidth delivered towards the host. Bandwidths of several MHz into the host are achievable these days, with all demodulation, etc, happening on the host. That is not to say that you couldn't implement a sweeper for doing SIGINT and spectral estimation, etc. In fact, there are Gnu Radio applications that do just that. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SDR question
I have a question about software defined radio I saw a pass band the other day on a screen which prompted me to ask The Software defined radio has a specific bandwidth ? Does it "scan" across the band very quickly to form the passband, or is the bandwidth already that large it just appears as a chunk of MHz ? I am trying to make the connection between how a Software Defined Radio would be different from an analogue system. For example decoding packet radio using an SDR, is there any performance degradation due to the way it works ? Would the SDR "sweep" and miss some of the signal ? - Andrew VK4TEC - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault
Please let me know if you solve the problem, I also have a seg fault... Thanks Vanessa On Fri, Oct 28, 2011 at 4:41 PM, Josh Blum wrote: > > > On 10/28/2011 04:03 AM, doering@googlemail.com wrote: >> Hello list, >> >> I tried to launch the "uhd_fft.py" script with the following command line: >> >> "uhd_fft.py -a type=usrp2 -f 935M -s 2M" >> >> >> My problem is that my terminal always returns this output: >> >> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae >> >> -- Opening a USRP2/N-Series device... >> -- Current recv frame size: 1472 bytes >> -- Current send frame size: 1472 bytes >> -- mboard0 is MIMO master >> Segmentation fault >> >> > > Does uhd_usrp_probe work? If so, is there a particular line in > uhd_fft.py that causes the seg fault? Have you debugged w/ gdb? > > In any case, I recommend upgrading to the latest release, then see if > there is still a problem. > > -Josh > > >> I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo CPU P8600 @ >> 2.40GHz × 2, USRP N210 with WBX. >> I also use ClockTamer as reference for the internal XO and 2 normal GSM >> 900 antennas. >> >> I would really appreciate if someone has an idea on what I am doing >> wrong here. >> >> Thanks in advance! >> >> Sebastian >> >> ___ >> 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 > -- Vanessa GARDELLIN, Ph.D. Researcher Institute for Informatics and Telematics (IIT), Italian National Research Council (CNR) Via G. Moruzzi 1 56124 Pisa - ITALY Phone: +390503153267 Room: B65/c E-mail: vanessa.gardel...@iit.cnr.it WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/ Skype: gardellin.vanessa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Going on "holiday"
On Fri, Oct 28, 2011 at 11:54, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > On Fri, Oct 28, 2011 at 11:53, Tom Rondeau wrote: > > >> It actually wasn't "down," but I don't know why it was responding the way >> it was. I just rebooted it to fix whatever the problem was. I'm about at the >> airport, so I have to pass these problems off to Johnathan. >> > > There was some issues with Amazon Web Services earlier today. The server > instance is running now. > > Well, partially. The disk volume that holds the mysql back-end to the Redmine website seems borked, causing *very* slow responses to links on the site, but they do seem to work eventually. Other things like the cgit interface to repositories and pushing and pulling from git seem ok. I'm looking into it. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Going on "holiday"
On Fri, Oct 28, 2011 at 11:53, Tom Rondeau wrote: > It actually wasn't "down," but I don't know why it was responding the way > it was. I just rebooted it to fix whatever the problem was. I'm about at the > airport, so I have to pass these problems off to Johnathan. > There was some issues with Amazon Web Services earlier today. The server instance is running now. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Going on "holiday"
It actually wasn't "down," but I don't know why it was responding the way it was. I just rebooted it to fix whatever the problem was. I'm about at the airport, so I have to pass these problems off to Johnathan. Sent from my iPhone On Oct 28, 2011, at 2:48 PM, Ben Hilburn wrote: > Tom - > > gnuradio.org is down =( > > Cheers, > Ben > > > On Fri, Oct 28, 2011 at 11:35 AM, Tom Rondeau wrote: > I just wanted to let everyone know that I'm taking a vacation for the week > (and won't be taking my computer with me ). I'm sure the list will > continue to survive and function as usual with the standard amount of help > and advice given by everyone, so you probably won't even notice that I'm > missing. > > In the mean time, Johnathan Corgan should be putting out a release candidate > of 3.5.0 within the next day. We have already moved our master branch in GNU > Radio to this version, anyway, so if you're keeping up that way, you've > already made the transition. Please continue to report bugs, though, before > we put out the full 3.5.0 release. This represents a number of big changes, > so we need eyes on and hands inside the code to make sure it's working right. > I recommend people submit bugs to the Issue Tracker on our Redmine page > (you'll have to log in to create a new ticket, the guest account is > guest:gnuradio), otherwise it might get lost in email. > > Thanks! > > Tom > > > ___ > 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] Going on "holiday"
Tom - gnuradio.org is down =( Cheers, Ben On Fri, Oct 28, 2011 at 11:35 AM, Tom Rondeau wrote: > I just wanted to let everyone know that I'm taking a vacation for the week > (and won't be taking my computer with me ). I'm sure the list will > continue to survive and function as usual with the standard amount of help > and advice given by everyone, so you probably won't even notice that I'm > missing. > > In the mean time, Johnathan Corgan should be putting out a release > candidate of 3.5.0 within the next day. We have already moved our master > branch in GNU Radio to this version, anyway, so if you're keeping up that > way, you've already made the transition. Please continue to report bugs, > though, before we put out the full 3.5.0 release. This represents a number > of big changes, so we need eyes on and hands inside the code to make sure > it's working right. I recommend people submit bugs to the Issue Tracker on > our Redmine page (you'll have to log in to create a new ticket, the guest > account is guest:gnuradio), otherwise it might get lost in email. > > Thanks! > > Tom > > > ___ > 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] Going on "holiday"
http://www.downforeveryoneorjustme.com/gnuradio.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Going on "holiday"
I just wanted to let everyone know that I'm taking a vacation for the week (and won't be taking my computer with me ). I'm sure the list will continue to survive and function as usual with the standard amount of help and advice given by everyone, so you probably won't even notice that I'm missing. In the mean time, Johnathan Corgan should be putting out a release candidate of 3.5.0 within the next day. We have already moved our master branch in GNU Radio to this version, anyway, so if you're keeping up that way, you've already made the transition. Please continue to report bugs, though, before we put out the full 3.5.0 release. This represents a number of big changes, so we need eyes on and hands inside the code to make sure it's working right. I recommend people submit bugs to the Issue Tracker on our Redmine page (you'll have to log in to create a new ticket, the guest account is guest:gnuradio), otherwise it might get lost in email. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GrBlock Inconsistent IO Size
Just FYI, I am integrating this work into gnuradio-core as we speak :-) On 10/28/2011 10:05 AM, Jason Bonior wrote: > I used grblock and numpy to create a block which would calculate the > variance of an incoming vector then pass on the result: > > class variance(grblock.sync_block): > > def __init__(self): > grblock.sync_block.__init__( > self, > name = "variance", > in_sig = [(numpy.float32, 2048)], > out_sig = [numpy.float32], > ) > > def work(self, input_items, output_items): > output_items[0][:] = numpy.var(input_items[0]) > print output_items[0][:].shape > print input_items[0].shape > return len(output_items[0]) > > I added the print .shape commands to make sure that the block IO was > performing as expected. Most of the time I get (1, 2048) and (1, ) as > I would expect but occasionally I get (2, 2048) (2, ) up to (5, 2048) > (5,). Has anyone else seen anything like this or know how it might > affect the performance of the block? > Each element of the input vector is an array of items. In this case each item is a vector of 2048 (I know... its a vector of vectors of vectors). Its not guaranteed how many items the scheduler will give you. It looks like usually you get 1 item, but sometimes several. This is consistent with my observations when dealing with the output of the FFT block. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GrBlock Inconsistent IO Size
I used grblock and numpy to create a block which would calculate the variance of an incoming vector then pass on the result: class variance(grblock.sync_block): def __init__(self): grblock.sync_block.__init__( self, name = "variance", in_sig = [(numpy.float32, 2048)], out_sig = [numpy.float32], ) def work(self, input_items, output_items): output_items[0][:] = numpy.var(input_items[0]) print output_items[0][:].shape print input_items[0].shape return len(output_items[0]) I added the print .shape commands to make sure that the block IO was performing as expected. Most of the time I get (1, 2048) and (1, ) as I would expect but occasionally I get (2, 2048) (2, ) up to (5, 2048) (5,). Has anyone else seen anything like this or know how it might affect the performance of the block? -- Jason Bonior ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault
On 10/28/2011 04:03 AM, doering@googlemail.com wrote: > Hello list, > > I tried to launch the "uhd_fft.py" script with the following command line: > > "uhd_fft.py -a type=usrp2 -f 935M -s 2M" > > > My problem is that my terminal always returns this output: > > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae > > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > -- mboard0 is MIMO master > Segmentation fault > > Does uhd_usrp_probe work? If so, is there a particular line in uhd_fft.py that causes the seg fault? Have you debugged w/ gdb? In any case, I recommend upgrading to the latest release, then see if there is still a problem. -Josh > I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo CPU P8600 @ > 2.40GHz × 2, USRP N210 with WBX. > I also use ClockTamer as reference for the internal XO and 2 normal GSM > 900 antennas. > > I would really appreciate if someone has an idea on what I am doing > wrong here. > > Thanks in advance! > > Sebastian > > ___ > 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] How to use the read_float_binary.m function
On Fri, Oct 28, 2011 at 08:06:40AM -0600, wallen wrote: > > Well, here is the code I cobbled together to do this. It is nothing > fancy. Though it can't be adapted as easily to more sophisticated processing as your python code, I often use this one-liner to do the same thing: $ od -fvw8 filename ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to use the read_float_binary.m function
On Thu, 2011-10-27 at 19:00 -0600, hasanimam wrote:
> Hello,
>
> I am in deep deep trouble. And it would be really great if somebody come up
> with any sort of help.
Well, here is the code I cobbled together to do this. It is nothing
fancy.
- Wayde
---
#!/usr/bin/env python
import sys, struct
if len(sys.argv) != 2: # Need to have one input data file
# Print out splash banner in case the filename
# isn't entered correctly
print
print ' [gr_raw2num.py, Version 20100308 by J. Wayde Allen]'
print
print ' NAME: gr_raw2num.py '
print
print ' USAGE: gr_raw2num.py filename'
print
print ' DESCRIPTION:'
print
print ' Converts raw complex float data to complex'
else:
myfile = sys.argv[1]
f = open(myfile, 'rb')
eof = False
while not eof:
try:
chunk = f.read(8)
a,b = struct.unpack('ff',chunk)
value = complex(a,b)
print a, b
except:
eof = True
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP N210 Benchmarks.
> > > 2011/10/27 Marcus D. Leech mailto:mle...@ripnet.com>> > >> >> Well, that sounds like the lazy solution, intermodulation >> products are bad, so just throwing the transmitter power away is >> not what I'd prefer. >> > But what it points to is an *analog* issue, entirely independant > of the CORDIC (which, as I observe, isn't likely involved in the > test cases > at hand here). > > Analog gain elements (including DACs) have operating regions over > which they're linear, and operating regions over which they're not > linear. If you drive any amplifier near its maximum operating > point, it will start to become non-linear to one degree or > another. I'll > let Matt or one of the other engineering folks at Ettus comment > further, but I personally am totally unsurprised when things start to > become non-linear near the nominal maximum operating point. > > > >> Is there any way of finding out what the resolution is? We >> haven't been able to track it down for the RFX2400 board, >> but this sounds like a nice way to test if it _is_ the CORDIC. > > Look at the tune_result_t from tuning: > > > http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__result__t.html > > If the actual_dsp_freq is 0, then the CORDIC wasn't involved. > > I tuned to an even number of MHz, which on all of the synthesizers > *should* yield 0 CORDIC frequency. > > But maybe Josh can add a feature to 'uhd_usrp_probe' to display > the PLL resolution (although in some cases, > it may change with target frequency range, I think). > > Thank yo very much for this, It is really usefull, and it furthermore > confirms what we have observed. > At 2.4GHz there is no problems, when we go 300 kHz up, we start > seeing the problems. (see images attached) > > This is further collaborated, with the fact that we can find "good" > frequencies up through the entire band. > Keep in mind also that spur and phase-noise performance of a PLL synthesizer will tend to change with different tunings. Said performance on spot frequencies can be improved by engaging in an optimization exercise involving not only PLL register settings, but changing the analog loop filter on the PLL as well. -- 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
[Discuss-gnuradio] uhd_fft.py returns Segmentation fault
Hello list, I tried to launch the "uhd_fft.py" script with the following command line: "uhd_fft.py -a type=usrp2 -f 935M -s 2M" My problem is that my terminal always returns this output: linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master Segmentation fault I am using Linux Ubuntu 11.10, 32bit, Intel® Core2 Duo CPU P8600 @ 2.40GHz × 2, USRP N210 with WBX. I also use ClockTamer as reference for the internal XO and 2 normal GSM 900 antennas. I would really appreciate if someone has an idea on what I am doing wrong here. Thanks in advance! Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 10.10 gnuradio stop working
Hi I run the script http://www.sbrac.org/files/build-gnuradio And it is work :-) Very nice script. Kenta Berggren SM0LRU 2011-10-28 08:19, Kenta Berggren skrev: Hi I upgraded Ubuntu to 10:10 and then the gnuradio stopped working. What do I need to do now? Have A Nice Day Kenta "Cannot import gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set correctly?" ___ 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] USRP N210 Benchmarks.
2011/10/27 Marcus D. Leech > > Well, that sounds like the lazy solution, intermodulation products are > bad, so just throwing the transmitter power away is not what I'd prefer. > > > But what it points to is an *analog* issue, entirely independant of the > CORDIC (which, as I observe, isn't likely involved in the test cases > at hand here). > > Analog gain elements (including DACs) have operating regions over which > they're linear, and operating regions over which they're not > linear. If you drive any amplifier near its maximum operating point, it > will start to become non-linear to one degree or another. I'll > let Matt or one of the other engineering folks at Ettus comment further, > but I personally am totally unsurprised when things start to > become non-linear near the nominal maximum operating point. > > > > Is there any way of finding out what the resolution is? We haven't been > able to track it down for the RFX2400 board, > but this sounds like a nice way to test if it _is_ the CORDIC. > > > Look at the tune_result_t from tuning: > > > http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__result__t.html > > If the actual_dsp_freq is 0, then the CORDIC wasn't involved. > > I tuned to an even number of MHz, which on all of the synthesizers *should* > yield 0 CORDIC frequency. > > But maybe Josh can add a feature to 'uhd_usrp_probe' to display the PLL > resolution (although in some cases, > it may change with target frequency range, I think). > > Thank yo very much for this, It is really usefull, and it furthermore confirms what we have observed. At 2.4GHz there is no problems, when we go 300 kHz up, we start seeing the problems. (see images attached) This is further collaborated, with the fact that we can find "good" frequencies up through the entire band. > > >> Only problem there is that there is a 55 dB loop back between the in and > output of the RFX2400 board, so two different radios are needed. > > You're talking about the combined isolation of the two RF switches in > the path between the TX and RX? That's adequate attenuation > for the tests I'm suggesting. > > I think I prefer our measurement equipment at the University > > > We have observed this as well, but as described before we do not find > this to be the correct solution. > > I'm keen to hear what your "correct solution" is to the problem of > non-linearity in off-the-shelf analog gain devices. I suspect the solution > won't be in the digital domain, but I'm always willing to be surprised. > > I have implemented the cordic in vhdl now, this should reduce the phase error (which is also mentioned in the pdf you referenced) because of the ability to increase the CORDIC stages. I am now just waiting for a Xilinx license. Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -// ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
