Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
On 05/25/2011 09:56 AM, David Evans wrote: > > This has never been clear to me! > What about the phase ambiguity due to the fractional-N VCO's, as Marcus has > mentioned? > > This has to be calibrated out, yes/no?, but how?, unless after a retune you > then > > TX a calibration sequence that you can correlate against and correct. But > after > this, then, do you really need to accurately wait for a PPS? It's just stuff > in > the buffer, with the computational overhead of alignment. > Basically, how do you compensate for the ambiguity? (maybe it doesn't matter > and > Well you really need to do two things: 1) Synchronize the time registers across all the devices using the PPS. This allows you to time-align samples. Also, the cordics across all devices will be aligned in phase when you tell the devices to stream at the same time. 2) Calibrate the setup. After you tune, the daughterboard LOs will have different constant phase offsets. With boards like WBX, its actually possible to sync the LOs using hardware, but this isnt implemented yet. In any case, *no matter what*, you need to calibrate by passing in a common signal and measuring your channels. If you open/close the device handle or re-tune, you will have to re-cal. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.15.4 performance analysis: pin Oscilloscope on IF
Hi! - To my background there's to say - before you read this - I'm just a software-dev. I have little expertise when it comes to hardware. I support the development of a real-time application that uses 802.15.4 on an AT86230RF Chip. That RF chip is IEEE 802.15.4-2003 compliant. It has got a data-rate of 250 kBit/s. Let's say I want to send 10 Byte. 2 Bytes CRC are added, and 6 Bytes from the Physical Layer (Preambel + Length Field + Delimeter). So I send 144 Bits (12 Byte PSDU are 12 *8 and 48 Bytes Physical Layer due 6 * 8). Theoretically I get 0,576 ms per transmission using 250 Kbit/s: 1/250k*144*10^3. Now... I use my USRP with an XCVR, start the sender, and record some transmissions into cfiles. I plot the Q channel, and calculate the transmission lengh: like how many samples do I see with a high amplitude relative to the sample-rate. That's when the RF chip is active. I get 3,45 ms. So the difference between what I theoretically can assume as TX time, and what I see in reality is abnormally high. My questions: 1.) Can I use an Oscilloscope to find out whether there's signal on IF. The Oscilloscope operates on something like 100 MHz, so I want the down-scaled frequency. I read that the RF frontend down-scales to the ADC. I can pin-point the microcontroller with the chip. Can I also pin-point the USRP2 with the XCVR (or RFX)? I could correlate the state-changes of the RF Chip that way. 2.) I suspect the differences result from state-changes on the RF chip (PLL_ON -> TX). Is anybody aware of a similar performance analysis on Zigbee for real-time applications? As I stated out I'm not a hardware-expert. 3.) I use the Gnuradio Companion, and record from the USRP2 directly into a cfile. Is there any way to apply a filter to be able to automatically detect the start and end point of a high-amplitude that represents sending activity? I tried to use the integrator to lower the amplitude (I'm not interested in demodulation at this point, just tx start and end). But that doesn't work very well. I hope my terminology isn't too crude ;) Best, Marius ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
This has never been clear to me! What about the phase ambiguity due to the fractional-N VCO's, as Marcus has mentioned? This has to be calibrated out, yes/no?, but how?, unless after a retune you then TX a calibration sequence that you can correlate against and correct. But after this, then, do you really need to accurately wait for a PPS? It's just stuff in the buffer, with the computational overhead of alignment. Basically, how do you compensate for the ambiguity? (maybe it doesn't matter and I'm probably talking rubbish :-/ ) Cheers, David - Original Message From: Josh Blum To: Khalid Jamil Cc: discuss-gnuradio@gnu.org Sent: Tue, 26 April, 2011 21:12:08 Subject: Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs On 04/26/2011 11:22 AM, Khalid Jamil wrote: > Please correct me if I am wrong. I think that this random channel-channel > phase offset at each acquisition depends on when each usrp 100MHz LO locks > to 10MHz external frequency reference by PLL. How PPS will help in that > case? Unless PPS is locked somehow to 10MHz clock? > Yes, but I strongly recommend that you get time-aligned samples working before trying to calibrate for the LO phase offsets. In your GRC flowgraph, each USRP source block will provide samples that start at a different random time that could be offset by many milliseconds. I don't think you want that? In order to get time-aligned samples from N devices, you must 1) synchronize the the time registers (seconds/ticks) across all USRP devices. You should use the PPS to do this 2) tell the devices to stream at the same time. > Is there a good example to follow, may to start with 2 or 4 channels? > There is an example that comes w/ uhd called rx_multi_samples. if you want to do this in GRC, follow the instructions in the previous email. -Josh ___ 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] QAM demod Error in GRC
On Tue, May 24, 2011 at 5:29 PM, Colby Boyer wrote: > On Tue, May 24, 2011 at 3:13 AM, Tom Rondeau > wrote: > > On Mon, May 23, 2011 at 10:37 PM, Ben Reynwar wrote: > >> > >> On Mon, May 23, 2011 at 12:09 PM, Josh Blum wrote: > >> > > >> > > >> > On 05/23/2011 03:29 AM, Vlad Stoianovici wrote: > >> >> > >> >> Dear Marcus and Bob, > >> >> I did understand that the block was hollow, but this thread is kindda > >> >> old, > >> >> so I thought that in the mean time maybe someone implemented the code > >> >> and > >> >> functionality you are referring to. > >> >> I'm using GRC, but I don't have time to start learning python with > the > >> >> sole > >> >> purpose of being able to write the QAM block. > >> >> It would probably be easier to use Simulink, which I'd rather not do. > >> >> > >> > > >> > This is a motivating example for a new gr-digital component that can > >> > make use of tags: the QAM deframer block. :-) > >> > > >> > -josh > >> > >> In the psk8 branch of my github repo > >> (www.github.com/benreynwar/gnuradio/) there is QAM modulation and > >> demodulation within the "digital" category of GRC. I haven't tested > >> it recently though. Let me know if you try it and it doesn't work. > >> > >> Cheers, > >> Ben > > > > Ben's branch is based off of my 8psk branch in github, too. I still need > to > > pull in his changes. I have a feeling we might be going back and forth a > bit > > in the development of the gr-digital top-level directory. This will make > it > > into the upcoming 'next' branch for the 3.5 release. > > Currently, it includes a more robust version of the Costas loop (you > specify > > the natural freq and damping factor instead of the gains; it sets the > gains > > properly so that the system is more tolerant and locks better) as well as > a > > reworking of the CMA equalizer. I have yet to use this equalizer on a > real > > signal, only simulated multipath channels, so more experience would be > good. > > Note that if you are using this branch you should --disable-gr-trellis. I > > banged up the API that is used in gr-trellis and haven't got back to fix > it, > > yet. > > Tom > > > > Tom, somewhat related. > > In the next week or so (when I have time), I will be contribute a > Gardner timing sync block to GNURadio. It should be a nice addition > for the DxPSK blocks, as it is carrier phase independent. > > --Colby > Thanks, Colby, it'd be good to have that one in the toolbox. The M&M loop and PFB clock sync blocks are also phase independent, though :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
This has never been clear to me! What about the phase ambiguity due to the fractional-N VCO's, as Marcus has mentioned? This has to be calibrated out, yes/no?, but how?, unless after a retune you then TX a calibration sequence that you can correlate against and correct. But after this, then, do you really need to accurately wait for a PPS? It's just stuff in the buffer, with the computational overhead of alignment. Basically, how do you compensate for the ambiguity? (maybe it doesn't matter and I'm probably talking rubbish :-/ ) Cheers - Original Message From: Josh Blum To: Khalid Jamil Cc: discuss-gnuradio@gnu.org Sent: Tue, 26 April, 2011 21:12:08 Subject: Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs On 04/26/2011 11:22 AM, Khalid Jamil wrote: > Please correct me if I am wrong. I think that this random channel-channel > phase offset at each acquisition depends on when each usrp 100MHz LO locks > to 10MHz external frequency reference by PLL. How PPS will help in that > case? Unless PPS is locked somehow to 10MHz clock? > Yes, but I strongly recommend that you get time-aligned samples working before trying to calibrate for the LO phase offsets. In your GRC flowgraph, each USRP source block will provide samples that start at a different random time that could be offset by many milliseconds. I don't think you want that? In order to get time-aligned samples from N devices, you must 1) synchronize the the time registers (seconds/ticks) across all USRP devices. You should use the PPS to do this 2) tell the devices to stream at the same time. > Is there a good example to follow, may to start with 2 or 4 channels? > There is an example that comes w/ uhd called rx_multi_samples. if you want to do this in GRC, follow the instructions in the previous email. -Josh ___ 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] Synchronization issue with multiple USRPs
On Wed, May 25, 2011 at 10:14 AM, Josh Blum wrote: > > > > 2) Calibrate the setup. After you tune, the daughterboard LOs will have > different constant phase offsets. With boards like WBX, its actually > possible to sync the LOs using hardware, but this isnt implemented yet. > In any case, *no matter what*, you need to calibrate by passing in a > common signal and measuring your channels. > What will it take to implement syncing the LOs on the daughterboards that do support this - is this on the roadmap for UHD currently? > If you open/close the device handle or re-tune, you will have to re-cal. > > -Josh > Thanks Josh! Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tuesday, 24th May sample volcanic ash image
Just FYI, to encourage GNURadio users, Received using GR USRP1 + TVRX (traditional, no uhd). Satellite Feng Yun channel-6 HRPT (1km resolution) gray-scale unprocessed image showing volcanic ash cloud entering Scandinavian airspace on Tuesday 24th May @ 1350Z http://www.poes-weather.com/downloads/Iceland-Ash-Cloud/Tue-May-24-2011/2011-05-24T164949-FENGYUN-1D-CH-6.jpg Patrik___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
On Wed, May 25, 2011 at 10:00 AM, Tom Rondeau wrote: > On Tue, May 24, 2011 at 5:29 PM, Colby Boyer wrote: > >> On Tue, May 24, 2011 at 3:13 AM, Tom Rondeau >> wrote: >> > On Mon, May 23, 2011 at 10:37 PM, Ben Reynwar wrote: >> >> >> >> On Mon, May 23, 2011 at 12:09 PM, Josh Blum >> wrote: >> >> > >> >> > >> >> > On 05/23/2011 03:29 AM, Vlad Stoianovici wrote: >> >> >> >> >> >> Dear Marcus and Bob, >> >> >> I did understand that the block was hollow, but this thread is >> kindda >> >> >> old, >> >> >> so I thought that in the mean time maybe someone implemented the >> code >> >> >> and >> >> >> functionality you are referring to. >> >> >> I'm using GRC, but I don't have time to start learning python with >> the >> >> >> sole >> >> >> purpose of being able to write the QAM block. >> >> >> It would probably be easier to use Simulink, which I'd rather not >> do. >> >> >> >> >> > >> >> > This is a motivating example for a new gr-digital component that can >> >> > make use of tags: the QAM deframer block. :-) >> >> > >> >> > -josh >> >> >> >> In the psk8 branch of my github repo >> >> (www.github.com/benreynwar/gnuradio/) there is QAM modulation and >> >> demodulation within the "digital" category of GRC. I haven't tested >> >> it recently though. Let me know if you try it and it doesn't work. >> >> >> >> Cheers, >> >> Ben >> > >> > Ben's branch is based off of my 8psk branch in github, too. I still need >> to >> > pull in his changes. I have a feeling we might be going back and forth a >> bit >> > in the development of the gr-digital top-level directory. This will make >> it >> > into the upcoming 'next' branch for the 3.5 release. >> > Currently, it includes a more robust version of the Costas loop (you >> specify >> > the natural freq and damping factor instead of the gains; it sets the >> gains >> > properly so that the system is more tolerant and locks better) as well >> as a >> > reworking of the CMA equalizer. I have yet to use this equalizer on a >> real >> > signal, only simulated multipath channels, so more experience would be >> good. >> > Note that if you are using this branch you should --disable-gr-trellis. >> I >> > banged up the API that is used in gr-trellis and haven't got back to fix >> it, >> > yet. >> > Tom >> > >> >> Tom, somewhat related. >> >> In the next week or so (when I have time), I will be contribute a >> Gardner timing sync block to GNURadio. It should be a nice addition >> for the DxPSK blocks, as it is carrier phase independent. >> >> --Colby >> > > > Thanks, Colby, it'd be good to have that one in the toolbox. The M&M loop > and PFB clock sync blocks are also phase independent, though :) > > Tom > Let me amend that. The PFB is absolutely phase independent. Our implementation of the M&M loop is not quite text-book, and it has some phase immunity (based on the way we update mu), but it can get caught in a local minimum if the phase offset is close to +/- 90 deg. It really should be phase-locked beforehand. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unexpected energy peak sensing thermal noise and using usrp_spectrum_sense.py
Hello everyone I’m using an USRP with a XCVR2450 daughter board working at 2.4 - 2.5 GHz. I want to find a threshold between thermal noise and signals energy using the script usrp_spectrum_sense.py and sensing from 2.400 GHz to 2.500 GHz. To do that, I replaced the WiFi antenna with a resistor of 50 Ω to measure the noise. I obtained a very strange peak at the beginning of the bandwidth (around 2.405 GHz) and this result was totally unexpected because I supposed to sense only thermal noise without any particular peak. So, I repeated the experiment from 2.420 GHz to 2.500 GHz and I achieved the same peak always at the beginning of the bandwidth (in this case around 2.425 GHz). Therefore, I'm quite sure this is a problem linked to USRP or to the script usrp_spectrum_sense.py, isn’t it? Can someone give me a hint about that please? Regards -- View this message in context: http://old.nabble.com/Unexpected-energy-peak-sensing-thermal-noise-and-using-usrp_spectrum_sense.py-tp31700266p31700266.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
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
On May 25, 2011, at 9:14 AM, Josh Blum wrote: > 2) Calibrate the setup. After you tune, the daughterboard LOs will have > different constant phase offsets. In my experience (with a WBX in a USRP2 and a DBSRX2 in an N210), the phase offsets can change between bursts, not just when you retune. Is this not supposed to be the case? -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
On 25/05/2011 12:01 PM, Marc Epard wrote: On May 25, 2011, at 9:14 AM, Josh Blum wrote: 2) Calibrate the setup. After you tune, the daughterboard LOs will have different constant phase offsets. In my experience (with a WBX in a USRP2 and a DBSRX2 in an N210), the phase offsets can change between bursts, not just when you retune. Is this not supposed to be the case? -Marc I think Josh had separately observed that the CORDIC phase accumulator gets reset between bursts, so the DDC phase isn't continuous, and thus offsets would be different. An interesting test would be to do continuous streaming, and see that the phase offsets remain constant across a single tuning with a continuous stream. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] log scale on gnuradio wxgui scopesink "Counts"
is it possible to show in the *wxgui_scopesink* the "Counts" values in the form of a log scale, i.e. 10^(-1) 10^(-2), 10^(-3), 10^(-4) and so on ? do i have to modify some source python file ? thx in advance Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulink and USRP
On Tue, May 24, 2011 at 3:57 PM, Camden Mendiola wrote: > Hi, > > Doe the USRP2 require specific FPGA and firmware contents to interface with > simulink? When I turn on the USRP2 with the SD card in, all 6 leds flash and > then D and F stay on. Does this mean my SD card is properly programmed with > the correct content? > > http://www.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds > Thanks! > > -Camden Mendiola > ___ > 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] Tuesday, 24th May sample volcanic ash image
On Wed, May 25, 2011 at 2:21 PM, Patrik Tast wrote: > Just FYI, to encourage GNURadio users, > > Received using GR USRP1 + TVRX (traditional, no uhd). Satellite Feng Yun > channel-6 HRPT (1km resolution) gray-scale unprocessed image > showing volcanic ash cloud entering Scandinavian airspace on Tuesday 24th > May @ 1350Z > > http://www.poes-weather.com/downloads/Iceland-Ash-Cloud/Tue-May-24-2011/2011-05-24T164949-FENGYUN-1D-CH-6.jpg > Amazing! So this is received using gr-noaa package and your GUI? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] log scale on gnuradio wxgui scopesink "Counts"
On 05/25/2011 12:16 PM, Arturo Rinaldi wrote: > is it possible to show in the *wxgui_scopesink* the "Counts" values in > the form of a log scale, i.e. 10^(-1) 10^(-2), 10^(-3), 10^(-4) and so on ? > > do i have to modify some source python file ? > yup. You may want to go after wxgui/plotters/channel_plotter.py > thx in advance > > Regards, Arturo > > > > ___ > 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] Synchronization issue with multiple USRPs
On 05/25/2011 12:01 PM, Marc Epard wrote: > On May 25, 2011, at 9:14 AM, Josh Blum wrote: > >> 2) Calibrate the setup. After you tune, the daughterboard LOs will >> have different constant phase offsets. > > In my experience (with a WBX in a USRP2 and a DBSRX2 in an N210), the > phase offsets can change between bursts, not just when you retune. Is > this not supposed to be the case? > The cordics reset when you start a new burst. So you need to time your bursts. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
On 05/25/2011 10:51 AM, Douglas Geiger wrote: > On Wed, May 25, 2011 at 10:14 AM, Josh Blum wrote: >> >> >> >> 2) Calibrate the setup. After you tune, the daughterboard LOs will have >> different constant phase offsets. With boards like WBX, its actually >> possible to sync the LOs using hardware, but this isnt implemented yet. >> In any case, *no matter what*, you need to calibrate by passing in a >> common signal and measuring your channels. >> > > What will it take to implement syncing the LOs on the daughterboards > that do support this - is this on the roadmap for UHD currently? > Basically a timed spi command can sync the LOs. Its on the roadmap. That wont forgo the need for calibration mind you. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs
On Wed, May 25, 2011 at 12:52 PM, Josh Blum wrote: > > >> >> What will it take to implement syncing the LOs on the daughterboards >> that do support this - is this on the roadmap for UHD currently? >> > > Basically a timed spi command can sync the LOs. Its on the roadmap. That > wont forgo the need for calibration mind you. -josh > > Understood - thanks. Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP complex multiplication question
Dear All, I have a question regarding the first complex multiplication process with the IF sinusoid in the USRP. Which of the scheme mentioned below is actually happening in the USRP? Let's say that two ADCs provide the sampled received signal to the next stage of processing. Let's call the sampled stream of ADC_0 as A and sampled stream of ADC_1 as B. SCHEME-1 The NCO produces two sinusoids that are in quadrature phase with each other. These are sin(2*pi*f*t) and cos(2*pi*f*t). Let's call the sin(2*pi*f*t)stream as C and cos(2*pi*f*t) stream as D. The multiplier after the ADC stage does the following. 1. Multiplies the cos(2*pi*fc*t) stream, C, with the sampled data stream of ADC_0, which is the stream named A and the product is AC. 2. Multiplies the sin(2*pi*fc*t) stream with the sampled data stream of ADC_1, which is the stream named B and the product is BD. Then sends the resultant product from these two steps as a complex sample, ( AC + jBD ) SCHEME-2 The NCO produces two sinusoids that are in quadrature phase with each other. These are sin(2*pi*f*t) and cos(2*pi*f*t). The multiplier after the ADC stage does the following. The multiplier after ADC stage then multiplies the ADC outputs with the NCO outputs as ( A + jB ) * ( C + jD) = (AC - BD) + j(AD + BC) and sends the above output as a complex sample. Which one is true? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexpected energy peak sensing thermal noise and using usrp_spectrum_sense.py
On Wed, 2011-05-25 at 08:51 -0700, Lebowski80 wrote: > Hello everyone > > I’m using an USRP with a XCVR2450 daughter board working at 2.4 - 2.5 GHz. I > want to find a threshold between thermal noise and signals energy using the > script usrp_spectrum_sense.py and sensing from 2.400 GHz to 2.500 GHz. To do > that, I replaced the WiFi antenna with a resistor of 50 Ω to measure the > noise. I obtained a very strange peak at the beginning of the bandwidth > (around 2.405 GHz) and this result was totally unexpected because I supposed > to sense only thermal noise without any particular peak. So, I repeated the > experiment from 2.420 GHz to 2.500 GHz and I achieved the same peak always > at the beginning of the bandwidth (in this case around 2.425 GHz). > Therefore, I'm quite sure this is a problem linked to USRP or to the script > usrp_spectrum_sense.py, isn’t it? Can someone give me a hint about that > please? The USRP is not a measurement receiver, and some small spurs are to be expected. You can plan for this, or work around it by changing the LO offset at a given center frequency using the advanced tuning parameters: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html --n > > Regards > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP complex multiplication question
On Wed, 2011-05-25 at 12:14 -0500, John Andrews wrote: > Dear All, > > I have a question regarding the first complex multiplication process > with the IF sinusoid in the USRP. Which of the scheme mentioned below > is actually happening in the USRP? > > > Let's say that two ADCs provide the sampled received signal to the > next stage of processing. Let's call the sampled stream of ADC_0 as A > and sampled stream of ADC_1 as B. > > > > > SCHEME-1 > > > The NCO produces two sinusoids that are in quadrature phase with each > other. These are sin(2*pi*f*t) and cos(2*pi*f*t). Let's call the > sin(2*pi*f*t)stream as C and > cos(2*pi*f*t) stream as D. The multiplier after the ADC stage does the > following. > > > 1. Multiplies the cos(2*pi*fc*t) stream, C, with the sampled data > stream of ADC_0, which is the stream named A and the product is AC. > 2. Multiplies the sin(2*pi*fc*t) stream with the sampled data stream > of ADC_1, which is the stream named B and the product is BD. > > > Then sends the resultant product from these two steps as a complex > sample, ( AC + jBD ) > > > SCHEME-2 > > > The NCO produces two sinusoids that are in quadrature phase with each > other. These are sin(2*pi*f*t) and cos(2*pi*f*t). The multiplier after > the ADC stage does the following. > > > The multiplier after ADC stage then multiplies the ADC outputs with > the NCO outputs as > ( A + jB ) * ( C + jD) = (AC - BD) + j(AD + BC) > and sends the above output as a complex sample. > > > Which one is true? SCHEME-3 The NCO feeds a (continuously increasing) phase to a CORDIC, which rotates the incoming samples by that phase value. --n > > > 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] USRP complex multiplication question
On Wed, 2011-05-25 at 12:14 -0500, John Andrews wrote: > Dear All, > > I have a question regarding the first complex multiplication process > with the IF sinusoid in the USRP. Which of the scheme mentioned below > is actually happening in the USRP? I should also clarify -- USRPs are zero-IF quadrature receivers (excepting the TVRX daughterboards). The daughterboards (excepting the TVRX series) have quadrature outputs and send complex baseband signals to the two ADCs. --n > > > Let's say that two ADCs provide the sampled received signal to the > next stage of processing. Let's call the sampled stream of ADC_0 as A > and sampled stream of ADC_1 as B. > > > > > SCHEME-1 > > > The NCO produces two sinusoids that are in quadrature phase with each > other. These are sin(2*pi*f*t) and cos(2*pi*f*t). Let's call the > sin(2*pi*f*t)stream as C and > cos(2*pi*f*t) stream as D. The multiplier after the ADC stage does the > following. > > > 1. Multiplies the cos(2*pi*fc*t) stream, C, with the sampled data > stream of ADC_0, which is the stream named A and the product is AC. > 2. Multiplies the sin(2*pi*fc*t) stream with the sampled data stream > of ADC_1, which is the stream named B and the product is BD. > > > Then sends the resultant product from these two steps as a complex > sample, ( AC + jBD ) > > > SCHEME-2 > > > The NCO produces two sinusoids that are in quadrature phase with each > other. These are sin(2*pi*f*t) and cos(2*pi*f*t). The multiplier after > the ADC stage does the following. > > > The multiplier after ADC stage then multiplies the ADC outputs with > the NCO outputs as > ( A + jB ) * ( C + jD) = (AC - BD) + j(AD + BC) > and sends the above output as a complex sample. > > > Which one is true? > > > 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] Tuesday, 24th May sample volcanic ash image
Yep, Patrik - Original Message - From: "Alexandru Csete" To: Sent: Wednesday, May 25, 2011 19:39 Subject: Re: [Discuss-gnuradio] Tuesday, 24th May sample volcanic ash image On Wed, May 25, 2011 at 2:21 PM, Patrik Tast wrote: Just FYI, to encourage GNURadio users, Received using GR USRP1 + TVRX (traditional, no uhd). Satellite Feng Yun channel-6 HRPT (1km resolution) gray-scale unprocessed image showing volcanic ash cloud entering Scandinavian airspace on Tuesday 24th May @ 1350Z http://www.poes-weather.com/downloads/Iceland-Ash-Cloud/Tue-May-24-2011/2011-05-24T164949-FENGYUN-1D-CH-6.jpg Amazing! So this is received using gr-noaa package and your GUI? Alex ___ 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] To implement WiMAX with GnuRadio or not?
Hi Alexander - I think Martin & Tom covered that GNU Radio is quite capable of being programmed for the basic receiver processing. You might need to play around a bit with your DSP blocks, but otherwise I think GNU Radio's data processing is up to the task. On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: > 3) Right now all our code is open-source, but we must leave an option > for proprietary plugins. How can we make this possible? > > 4) Related to (3) - how can we make sure our protocol stack can be > embedded into a closed-source application/system? IANAL and TINAL. I think, as has been said, you'll really want to consult a lawyer to figure out how to best meet your needs. GNU Radio is licensed solely under the GPLv3, which is written with the intent that -anything directly- using source or binary becomes part of a "greater work" and hence would also fall under this or an equivalent license (e.g., if used in a sold product). In the case of GNU Radio, that means any C++ code that links with GNU Radio's libraries, or Python script that makes use of GNU Radio's Python / SWIG files / libraries. To the best of my knowledge, because GNU Radio is not dual-licensed, neither can "greater works" derived from it. Ettus' UHD code is (will be?) an example of a dual license (GPL for the primary source, or some other license allowing you to do closed source for your needs when you pay to license the code from Ettus); Qt tries to do this dual-license as well -- I don't know how well they succeed, but they do try. IMHO, you have 3 primary choices for keeping your code closed source: (0) Do not use GNU Radio; use some other project that has a less restrictive license. (1) Do not distribute a product or service that uses the code: Nobody will care how you license your code so long as you / your company does not sell or distribute your product -- e.g., if you use it just in house for testing and evaluation, then you can license it however you want. However, I doubt that this is what you're looking for: why develop such a product, but not sell or distribute it? That brings us to: (2) Make sure your code does not -directly- rely on GNU Radio's headers, Python scripts, or compiled libraries: Use currently available GNU Radio blocks as much as you can (or, those written and released by others), and then create a pipe or socket connection to your specific code. Because your code does not rely -directly- on GNU Radio's codebase / libraries, it forms an independent work & thus you can license it as you choose. That said, this method is certainly a nuisance and, depending what blocks are available versus what you need, it might also be impractical (never impossible :). I don't know of another way to look at this issue -- maybe someone on this list is more enlightened? That said: Unless you feel strongly that your work truly needs to be proprietary, then why not just create a project on the CGRAN or your preferred area (e.g., github) & make your work public -- it will benefit many others in the SDR / DSP world (and, likely, beyond). Good luck, and please do keep the list informed on your project -- it sounds quite interesting! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Michael- > Hi Alexander - I think Martin & Tom covered that GNU Radio > is quite capable of being programmed for the basic receiver > processing. You might need to play around a bit with your > DSP blocks, but otherwise I think GNU Radio's data > processing is up to the task. > > On May 23, 2011, at 3:50 PM, Alexander Chemeris wrote: >> 3) Right now all our code is open-source, but we must > leave an option >> for proprietary plugins. How can we make this possible? >> >> 4) Related to (3) - how can we make sure our protocol > stack can be >> embedded into a closed-source application/system? > > IANAL and TINAL. I think, as has been said, you'll > really want to consult a lawyer to figure out how to > best meet your needs. > > GNU Radio is licensed solely under the GPLv3, which is > written with the intent that -anything directly- using > source or binary becomes part of a "greater work" and > hence would also fall under this or an equivalent > license (e.g., if used in a sold product). In the > case of GNU Radio, that means any C++ code that links > with GNU Radio's libraries, or Python script that > makes use of GNU Radio's Python / SWIG files / > libraries. To the best of my knowledge, because GNU > Radio is not dual-licensed, neither can "greater > works" derived from it. Ettus' UHD code is (will be?) > an example of a dual license (GPL for the primary > source, or some other license allowing you to do > closed source for your needs when > you pay to license the code from Ettus); Qt tries > to do this dual-license as well -- I don't know how > well they succeed, but they do try. > > IMHO, you have 3 primary choices for keeping your code > closed source: > > (0) Do not use GNU Radio; use some other project that > has a less restrictive license. > > (1) Do not distribute a product or service that uses > the code: Nobody will care how you license your code > so long as you / your company does not sell or > distribute your product -- e.g., if you use it just > in house for testing and evaluation, then you can > license it however you want. However, I doubt that > this is what you're looking for: why develop such > a product, but not sell or distribute it? That > brings us to: > > (2) Make sure your code does not -directly- rely on > GNU Radio's headers, Python scripts, or compiled > libraries: Use currently available GNU Radio blocks > as much as you can (or, those written and released > by others), and then create a pipe or socket > connection to your specific code. Because your > code does not rely -directly- on GNU Radio's > codebase / libraries, it forms an independent work > & thus you can license it as you choose. That said, > this method is certainly a nuisance and, depending > what blocks are available versus what you need, it > might also be impractical (never impossible :). This is where I think licensing discussions tend to go off track. Legal precedents have clearly established requirements for interoperability. In that context, the key point is not what code "links to", but where it resides and what shape it takes. "Linking based" arguments are fuzzy and argued ad infinitum until at least one such case reaches the Supreme Court -- not likely any time soon. If code resides across a network, across a bus (i.e. on a PCIe card inside the GNU radio host server), or some other clearly non-GNU radio location then interoperability becomes the metric. It doesn't matter what header files or libraries (or whether the libraries are static or shared object, etc) were used to create an interface to the code that is physically separate -- in that case, the code is clearly out of the scope of the license. I've mentioned on the forum before the need for ways to insert proprietary code within the GNU radio framework, as have others. For example, is it possible for GNU radio users to insert code blocks into the FPGA data flow, for instance if FPGA Verilog code contained "user defined" stubs or simple reference examples to serve as a starting point? Could an Nvidia accelerator be used? To me, it's a matter of imagination, creativity, and persistence -- if GNU radio developers believe in the need for proprietary IP within their framework, then it can be done. So far, evidently, they don't believe. Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving "how to's", not "INALs". -Jeff > I don't know of another way to look at this issue -- maybe someone on this > list is more enlightened? > > That said: Unless you feel strongly that your work truly needs to be > proprietary, then why not just create a project > on the CGRAN or your preferred area (e.g., github) & make your work public -- > it will benefit many others in the SDR / > DSP world (and, likely, beyond). > > Good luck, and please do keep the list informed on your
[Discuss-gnuradio] [RFC] Add a cyclic extender to gr
Hi all, I have been familiarizing myself with the inner guts of gnuradio and hacked together the attached patch, applied to tag v3.3.0. It is an extended version of gr_ofdm_cyclic_prefixer which can add cyclic suffix and symbol overlapping, which is used in VDSL/2 standards, and it is named gr_dmt_cyclic_extender. I would very much appreciate your comments on the code style and any nitpicks you may have. The commit message also explicits a problem I encountered during coding: I believe I need some kind of "done" signal to send whatever is stored in the block's "memory". How should one solve this in gnuradio? There is also a git repository at git://gitorious.org/~igoralmeida/gnuradio/igoralmeida-gnuradio.git with the code applied directly to master, but I'm probably missing some python dev files as gnuradio does not build. Cheers -- Igor Almeida From 6d12b9859ff0d51578524a62781792a33b174a6c Mon Sep 17 00:00:00 2001 From: Igor Almeida Date: Wed, 25 May 2011 12:08:55 -0300 Subject: [PATCH] Add a cyclic extender to gr This is similar to gr_ofdm_cyclic_prefixer, but adds cyclic suffix and symbol overlapping if instructed to do so. The functionality is based on VDSL standard, ITU-T recommendation G.993.1 section 9.2.2. There is a problem with the approach, though. With overlap>0, the overlapping suffix will only be sent after added to the next symbol's prefix. This means the last symbol will have 'overlap' less samples as it should. I'm missing some kind of signal to notify the block to include the last samples when there are no more vectors in the input. --- gnuradio-core/src/lib/general/Makefile.am |3 + gnuradio-core/src/lib/general/general.i|2 + .../src/lib/general/gr_dmt_cyclic_extender.cc | 113 .../src/lib/general/gr_dmt_cyclic_extender.h | 63 +++ .../src/lib/general/gr_dmt_cyclic_extender.i | 34 ++ gnuradio-core/src/python/gnuradio/gr/Makefile.am |1 + .../python/gnuradio/gr/qa_dmt_cyclic_extender.py | 57 ++ 7 files changed, 273 insertions(+), 0 deletions(-) create mode 100644 gnuradio-core/src/lib/general/gr_dmt_cyclic_extender.cc create mode 100644 gnuradio-core/src/lib/general/gr_dmt_cyclic_extender.h create mode 100644 gnuradio-core/src/lib/general/gr_dmt_cyclic_extender.i create mode 100644 gnuradio-core/src/python/gnuradio/gr/qa_dmt_cyclic_extender.py diff --git a/gnuradio-core/src/lib/general/Makefile.am b/gnuradio-core/src/lib/general/Makefile.am index 3d8a428..37ec8d9 100644 --- a/gnuradio-core/src/lib/general/Makefile.am +++ b/gnuradio-core/src/lib/general/Makefile.am @@ -175,6 +175,7 @@ libgeneral_la_SOURCES = \ gr_descrambler_bb.cc \ gr_scrambler_bb.cc \ gr_probe_mpsk_snr_c.cc \ + gr_dmt_cyclic_extender.cc \ gr_probe_density_b.cc libgeneral_qa_la_SOURCES = \ @@ -344,6 +345,7 @@ grinclude_HEADERS = \ gr_descrambler_bb.h \ gr_scrambler_bb.h \ gr_probe_mpsk_snr_c.h \ + gr_dmt_cyclic_extender.h \ gr_probe_density_b.h noinst_HEADERS = \ @@ -484,5 +486,6 @@ swiginclude_HEADERS = \ gr_descrambler_bb.i \ gr_scrambler_bb.i \ gr_probe_mpsk_snr_c.i \ + gr_dmt_cyclic_extender.i \ gr_probe_density_b.i endif diff --git a/gnuradio-core/src/lib/general/general.i b/gnuradio-core/src/lib/general/general.i index 68cafce..58b1daa 100644 --- a/gnuradio-core/src/lib/general/general.i +++ b/gnuradio-core/src/lib/general/general.i @@ -141,6 +141,7 @@ #include #include #include +#include %} %include "gr_nop.i" @@ -262,3 +263,4 @@ %include "gr_copy.i" %include "gr_fll_band_edge_cc.i" %include "gr_additive_scrambler_bb.i" +%include "gr_dmt_cyclic_extender.i" diff --git a/gnuradio-core/src/lib/general/gr_dmt_cyclic_extender.cc b/gnuradio-core/src/lib/general/gr_dmt_cyclic_extender.cc new file mode 100644 index 000..f9b3ac2 --- /dev/null +++ b/gnuradio-core/src/lib/general/gr_dmt_cyclic_extender.cc @@ -0,0 +1,113 @@ +/* -*- c++ -*- */ +/* + * Copyright 2004,2006 Free Software Foundation, Inc. + * + * This file is part of GNU Radio + * + * GNU Radio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3, or (at your option) + * any later version. + * + * GNU Radio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GNU Radio; see the file COPYING. If not, write to + * the Free Software Foundation, Inc., 51 Franklin Street, + * Boston, MA 02110-1301, USA. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include + +#include +#include + +gr_dmt_cyclic_extender_sptr +gr_make_dmt_cyclic_extender (size_t input_size, unsign
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Alexander is asking excellent questions and I'm surprised at the tepid response -- he's got like 4 replies so far? He's the prototype GNU radio user who needs to maintain his group's IP, he should be receiving "how to's", not "INALs". -Jeff Actually, IANAL is a perfectly-valid response. IP licensing arrangements are complicated and studded with sinkholes and minefields. I've avoided the issue (I hope!) in my proprietary "stuff" that uses Gnu Radio by doing two things: o minimizing the "stuff" that I do inside the flow-graph if I can conveniently do it outside o speaking to the flowgraph via named pipes and moving the proprietary and user-goop into non Gnu Radio compiled code. This is probably the safest thing that somebody who isn't a lawyer can do without consulting an (expensive) IPR lawyer. -- 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
Re: [Discuss-gnuradio] Please give me some advice for purchasing the USRP series!
On 04/21/2011 06:40 PM, 김보미 wrote: > 1) Buy one USRP N200 because of this comment of Ettus “Please > consider the USRP N200 series instead of USPR2.” > > And connect *the USRP2* and USRP N200 with MIMO cable to implement > the relay system > > 2) Buy one USRP. > > Then, use the USRP for 2 TX and *the USRP2* for 1 RX. > > > > Which of the USRP series is appropriate to the relay system? > > I want to implement the system as soon as possible. > Either way will work, and it really depends on what sort of bandwidth you need. If the USRP1 is fast enough for you, then that will be the least expensive option. There are some difficulties with precisely aligning the USRP2 with a USRP N200, but you can calibrate that out. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
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. ___ 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 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 Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
