Re: [Discuss-gnuradio] Packetloss and Ber simulation using OFDM
Hmm I agree a cleanup is necessary. Will get back. Thank you guys. On Wed, Feb 27, 2019 at 13:47 Michael Dickens wrote: > I'll second what Marcus said: a little tidier GRC flowgraph would help. > > That said, it looks like you're using nice and simple GR OFDM for Tx and > then you've expanded the GR OFDM Rx into its hier block equivalent form ... > then connected the output to PER and BER blocks and output those results to > the Qt GUI. I can't say for certain that all of the parameters are "stock", > but those I can see look like they are. Is this correct? > > What I'm wondering is where you're seeing the "55db drop in the signal" > you specifically note? GR's default OFDM has zeros in the frequency > spectrum in some locations. I don't see anything specifically "wrong" nor > "out of place" with the spectrum you posted, but since this is just a > screenshot it's difficult to tell what's going on beyond that it's an OFDM > waveform. Hence my query to what exactly you're referring. > > Hope this is useful! - MLD > > On Wed, Feb 27, 2019, at 1:32 PM, Müller, Marcus (CEL) wrote: > > Hi Nishant, I'm afraid you'll have to first tidy up your flowgraph. > I've been staring at it for a while, and it's just too confusing. > > Best regards, > Marcus > > On Wed, 2019-02-27 at 11:41 -0500, Sai Parepalli Laxman wrote: > > Hello, > > > > This is Nishant. > > > > I have a pair of N210 USRP modules and two pairs of LFTX/LFRX daughter > boards. I have an unexplained 55db drop in the signal where a signal with > amplitude bounded between -1 to 1, shows a -30db peak rather than a 0 dB > peak on Qt GUI Frequency Sink and I am wondering if the amplifier is wrong > or something that I am not doing right. > > > > I am using Ubuntu 18.04.1 gnuradio version 3.7.11 and UHD_003.010.003.000 > > > > I have attached the flowgraph and the transmitter output below. > > > ___ > 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] Distance Measurement by Correlation
Some pointer that might help you. - No, the samples are not completely real in BPSK until the point in signal processing chain where you decimate the signal down to the symbol rate. >From what I understand your problem, and given that your purpose is to find the correlation peak instead of demodulating the data, you'd be dealing with both I and Q samples. - Be very careful with conjugation as they bring in both conjugation and reversal in the other domain ( https://dsp.stackexchange.com/questions/23733/conjugation-in-fourier-transform). Furthermore, you're correlating it with a clean copy that is stored in your system so there is a usual discrimination between cross-correlation and auto-correlation, the latter being the operation in which conjugations remove the phase/frequency effects and not the former. - Regarding the Costas loop, I usually do not trust the acquisition range/acquisition time numbers from simulation to practice, as simulations are done at a certain SNR with only one imperfection present. Even if everything expected is simulated, the loop starting points cannot be carefully controlled due to the unknown incoming phase! In addition, acquisition is a highly non-linear operation which strongly depends on both the Rx SNR and the loop SNR as well as the shape of the channel frequency response. In this particular ranging application, I would rather tune the frequency of one USRP receiving a test signal (e.g., simple CW and employing a simple PLL) until I get the lock. Then in the next experiment, I would initiate my ranging procedure and track small changes from there. Also keep in mind that there is a finite acquisition time for the loop to settle which might comprise of your entire sequence to be correlated. At least it will certainly eat away some part of it. Finally, Marcus' suggestion of starting with the simplest case and seeing where your signal deviates from what you expect is probably the best way to move forward. Cheers, Qasim On Wed, Feb 27, 2019 at 6:58 PM Jonathan Preheim wrote: > Hi all, > > Thanks for the responses. Ultimately, we won't be able to share a clock > source directly, and I don't have the right cables right now to link them > for troubleshooting. Even when I try to use the RF loopback modes though, I > do not see a correlation peak. Firmware-based loopback works as expected. > I've been trying to model a frequency offset with the Channel Model block, > and compensate with the Costas loop block with a little success. But > actually doing it on the radios does not work. > > The Costas loop handles frequency offsets up to 0.05 in simulations with > an otherwise ideal channel. The chip rate is 1.25Mchip/s, so that's an > offset of about 63kHz. The BladeRF's clock is 38.4MHz accurate to 1 ppm or > 38.4Hz. Multiplied up to our carrier frequency of 910MHz, that's an > expected accuracy of under 1kHz, so it's reasonable to expect that the > Costas loop would take care of any offset right? > > Using the conjugate of the samples doesn't seem to make difference. That > would make sense to me if I was trying to do the correlation as frequency > domain multiplication by the conjugate, but I'm not (the FIR filter method > has produced much more consistent results in simulations for us so far). > Ideally, the samples would be completely real since it's BPSK, and we'd > want to apply compensation in order to achieve roughly that, right? > > T'hanks, > Jonathan > > On Tue, Feb 26, 2019 at 7:00 PM Qasim Chaudhari > wrote: > >> >Make sure both your radios are locked to the same clock source. >> Any fsignificant requency offset between the two is going to ruin your >> correlation peaks very quickly. >> >> When the same clock source is not possible due to the distance between >> them, the carrier frequency offset can also be estimated and corrected at >> the initiating USRP and then the correlation can be applied. In this >> scenario, the quality of the result will depend on how good the CFO >> estimate is. >> >> Cheers, >> Qasim >> >> >> Message: 4 >>> Date: Tue, 26 Feb 2019 10:07:51 +0100 >>> From: Sylvain Munaut <246...@gmail.com> >>> To: Jonathan Preheim >>> Cc: GNURadio Discussion List >>> Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation >>> Message-ID: >>> >> uo2tdw...@mail.gmail.com> >>> Content-Type: text/plain; charset="UTF-8" >>> >>> > Any ideas about how we can troubleshoot this more effectively? Or >>> better model the channel? >>> >>> Make sure both your radios are locked to the same clock source. >>> Any fsignificant requency offset between the two is going to ruin your >>> correlation peaks very quickly. >>> >>> Frequency offset is going to end up as a progressive phase shift along >>> your PN sequence. If that phase shift is a non-negligibe part of the >>> unit circle during the time of your PN sequence, they won't 'add up' >>> to a peak anymore. >>> >>> Cheers, >>> >>>Sylvain >>> >>> >>> >>> -- >>> >>
Re: [Discuss-gnuradio] Distance Measurement by Correlation
To clarify a confusion in my last email, by "until the point in signal processing chain where you decimate the signal down to the symbol rate", I meant the stage just before quantization; otherwise carrier recovery in BPSK still needs to work with complex samples at symbol rate. Cheers, Qasim On Thu, Feb 28, 2019 at 11:06 AM Qasim Chaudhari wrote: > Some pointer that might help you. > > - No, the samples are not completely real in BPSK until the point in > signal processing chain where you decimate the signal down to the symbol > rate. From what I understand your problem, and given that your purpose is > to find the correlation peak instead of demodulating the data, you'd be > dealing with both I and Q samples. > > - Be very careful with conjugation as they bring in both conjugation and > reversal in the other domain ( > https://dsp.stackexchange.com/questions/23733/conjugation-in-fourier-transform). > Furthermore, you're correlating it with a clean copy that is stored in your > system so there is a usual discrimination between cross-correlation and > auto-correlation, the latter being the operation in which conjugations > remove the phase/frequency effects and not the former. > > - Regarding the Costas loop, I usually do not trust the acquisition > range/acquisition time numbers from simulation to practice, as simulations > are done at a certain SNR with only one imperfection present. Even if > everything expected is simulated, the loop starting points cannot be > carefully controlled due to the unknown incoming phase! In addition, > acquisition is a highly non-linear operation which strongly depends on both > the Rx SNR and the loop SNR as well as the shape of the channel frequency > response. In this particular ranging application, I would rather tune the > frequency of one USRP receiving a test signal (e.g., simple CW and > employing a simple PLL) until I get the lock. Then in the next experiment, > I would initiate my ranging procedure and track small changes from there. > Also keep in mind that there is a finite acquisition time for the loop to > settle which might comprise of your entire sequence to be correlated. At > least it will certainly eat away some part of it. > > Finally, Marcus' suggestion of starting with the simplest case and seeing > where your signal deviates from what you expect is probably the best way to > move forward. > > Cheers, > Qasim > > > On Wed, Feb 27, 2019 at 6:58 PM Jonathan Preheim < > jonathan.preh...@gmail.com> wrote: > >> Hi all, >> >> Thanks for the responses. Ultimately, we won't be able to share a clock >> source directly, and I don't have the right cables right now to link them >> for troubleshooting. Even when I try to use the RF loopback modes though, I >> do not see a correlation peak. Firmware-based loopback works as expected. >> I've been trying to model a frequency offset with the Channel Model block, >> and compensate with the Costas loop block with a little success. But >> actually doing it on the radios does not work. >> >> The Costas loop handles frequency offsets up to 0.05 in simulations with >> an otherwise ideal channel. The chip rate is 1.25Mchip/s, so that's an >> offset of about 63kHz. The BladeRF's clock is 38.4MHz accurate to 1 ppm or >> 38.4Hz. Multiplied up to our carrier frequency of 910MHz, that's an >> expected accuracy of under 1kHz, so it's reasonable to expect that the >> Costas loop would take care of any offset right? >> >> Using the conjugate of the samples doesn't seem to make difference. That >> would make sense to me if I was trying to do the correlation as frequency >> domain multiplication by the conjugate, but I'm not (the FIR filter method >> has produced much more consistent results in simulations for us so far). >> Ideally, the samples would be completely real since it's BPSK, and we'd >> want to apply compensation in order to achieve roughly that, right? >> >> T'hanks, >> Jonathan >> >> On Tue, Feb 26, 2019 at 7:00 PM Qasim Chaudhari < >> qasim.chaudh...@gmail.com> wrote: >> >>> >Make sure both your radios are locked to the same clock source. >>> Any fsignificant requency offset between the two is going to ruin your >>> correlation peaks very quickly. >>> >>> When the same clock source is not possible due to the distance between >>> them, the carrier frequency offset can also be estimated and corrected at >>> the initiating USRP and then the correlation can be applied. In this >>> scenario, the quality of the result will depend on how good the CFO >>> estimate is. >>> >>> Cheers, >>> Qasim >>> >>> >>> Message: 4 Date: Tue, 26 Feb 2019 10:07:51 +0100 From: Sylvain Munaut <246...@gmail.com> To: Jonathan Preheim Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation Message-ID: >>> uo2tdw...@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > Any ideas about how we can troubleshoot this more effectively? Or
Re: [Discuss-gnuradio] OFDM Frequency Spacing
Hi ARob, You're right to presume that – because that's how the math behind the DFT works out! So, no, you can't change that. What you can do, of course, make a system with the correct resulting sampling rate (as calculated from desired spacing times number of bins), and just resample that to the rate you need. Alternatively, and that's what you probably want: Calculate the FFT length so that you get your desired channel spacing giving your sampling rate, and use the carrier map to just use the (typically center, aside from DC) ones that you need. Best regards, Marcus On Wed, 2019-02-27 at 13:00 -0600, Alex Roberts wrote: > Hello GNURadio Users, > > Is it possible to specify the frequency spacing of the carriers in the OFDM > Transmitter Block or Carrier Allocator block? My assumption is the carrier > spacing is calculated from the sampling rate and the FFT length (e.g, if > sampling rate is 640k and fft length is 64, is the frequency spacing 10 kHz). > It would be nice to have the capability to manually define the frequency bin > spacing. > > Thanks, > ARob > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM Frequency Spacing
Hello GNURadio Users, Is it possible to specify the frequency spacing of the carriers in the OFDM Transmitter Block or Carrier Allocator block? My assumption is the carrier spacing is calculated from the sampling rate and the FFT length (e.g, if sampling rate is 640k and fft length is 64, is the frequency spacing 10 kHz). It would be nice to have the capability to manually define the frequency bin spacing. Thanks, ARob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packetloss and Ber simulation using OFDM
I'll second what Marcus said: a little tidier GRC flowgraph would help. That said, it looks like you're using nice and simple GR OFDM for Tx and then you've expanded the GR OFDM Rx into its hier block equivalent form ... then connected the output to PER and BER blocks and output those results to the Qt GUI. I can't say for certain that all of the parameters are "stock", but those I can see look like they are. Is this correct? What I'm wondering is where you're seeing the "55db drop in the signal" you specifically note? GR's default OFDM has zeros in the frequency spectrum in some locations. I don't see anything specifically "wrong" nor "out of place" with the spectrum you posted, but since this is just a screenshot it's difficult to tell what's going on beyond that it's an OFDM waveform. Hence my query to what exactly you're referring. Hope this is useful! - MLD On Wed, Feb 27, 2019, at 1:32 PM, Müller, Marcus (CEL) wrote: > Hi Nishant, I'm afraid you'll have to first tidy up your flowgraph. > I've been staring at it for a while, and it's just too confusing. > > Best regards, > Marcus > > On Wed, 2019-02-27 at 11:41 -0500, Sai Parepalli Laxman wrote: > > Hello, > > > > This is Nishant. > > > > I have a pair of N210 USRP modules and two pairs of LFTX/LFRX daughter > > boards. I have an unexplained 55db drop in the signal where a signal with > > amplitude bounded between -1 to 1, shows a -30db peak rather than a 0 dB > > peak on Qt GUI Frequency Sink and I am wondering if the amplifier is wrong > > or something that I am not doing right. > > > > I am using Ubuntu 18.04.1 gnuradio version 3.7.11 and UHD_003.010.003.000 > > > > I have attached the flowgraph and the transmitter output below. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packetloss and Ber simulation using OFDM
Hi Nishant, I'm afraid you'll have to first tidy up your flowgraph. I've been staring at it for a while, and it's just too confusing. Best regards, Marcus On Wed, 2019-02-27 at 11:41 -0500, Sai Parepalli Laxman wrote: > Hello, > > This is Nishant. > > I have a pair of N210 USRP modules and two pairs of LFTX/LFRX daughter > boards. I have an unexplained 55db drop in the signal where a signal with > amplitude bounded between -1 to 1, shows a -30db peak rather than a 0 dB peak > on Qt GUI Frequency Sink and I am wondering if the amplifier is wrong or > something that I am not doing right. > > I am using Ubuntu 18.04.1 gnuradio version 3.7.11 and UHD_003.010.003.000 > > I have attached the flowgraph and the transmitter output below. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] creating a embedded python-block with multiple output types
Cinaed; (inline comments) On 27/02/19 05:37, Cinaed Simson wrote: There's problem with the grc file - it doesn't load into grc. The embedded python code is using "" instead of ">" - at least that was my guess. I don't know. It seams to work as is on my machine (ubuntu 16.04). I do also see the "" in the .grc file, but when I open the python source-code from gnuradio-companion, they are replaced by "<" and ">". As for your question, do you mean select a waveform in the signal source block? No, what I want to do is to allow the user to select the output type. If you look at the signal-source block, it can output complex, float, int or short. I was wondering how to implement that as part of an embedded python block. In my current python code, I have this: gr.sync_block.__init__( self, name='morsecode encoder', in_sig=[], out_sig=[np.complex64] <-- ) (Where the "out_sig = ..." describes the output type) I would like to make this output-type user-selectable. -- Cinaed Cheerio! Kr. Bonne. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distance Measurement by Correlation
So, that means we're deep in the realm of signal debugging. Make sure your time- and frequency-domain signals look like you expect them to look. Get to know where the limits of your system are, and make sure you're far enough from them. For example, slightly increase your gain until you see receiver nonlinearity/clipping. Then, note that gain and make sure you stay away from that; same on the other end of the amplitude scale. Do multi-tone tests superimposed with your signal; does that work as expected? By doing these tests, you'll probably find the specific case of what starts to *not* look like it should, according to your digital comms textbook. That's where you investigate. Best regards, Marcus On Tue, 2019-02-26 at 23:58 -0800, Jonathan Preheim wrote: > Hi all, > > Thanks for the responses. Ultimately, we won't be able to share a clock > source directly, and I don't have the right cables right now to link them for > troubleshooting. Even when I try to use the RF loopback modes though, I do > not see a correlation peak. Firmware-based loopback works as expected. I've > been trying to model a frequency offset with the Channel Model block, and > compensate with the Costas loop block with a little success. But actually > doing it on the radios does not work. > > The Costas loop handles frequency offsets up to 0.05 in simulations with an > otherwise ideal channel. The chip rate is 1.25Mchip/s, so that's an offset of > about 63kHz. The BladeRF's clock is 38.4MHz accurate to 1 ppm or 38.4Hz. > Multiplied up to our carrier frequency of 910MHz, that's an expected accuracy > of under 1kHz, so it's reasonable to expect that the Costas loop would take > care of any offset right? > > Using the conjugate of the samples doesn't seem to make difference. That > would make sense to me if I was trying to do the correlation as frequency > domain multiplication by the conjugate, but I'm not (the FIR filter method > has produced much more consistent results in simulations for us so far). > Ideally, the samples would be completely real since it's BPSK, and we'd want > to apply compensation in order to achieve roughly that, right? > > T'hanks, > Jonathan > > On Tue, Feb 26, 2019 at 7:00 PM Qasim Chaudhari > wrote: > > >Make sure both your radios are locked to the same clock source. > > Any fsignificant requency offset between the two is going to ruin your > > correlation peaks very quickly. > > > > When the same clock source is not possible due to the distance between > > them, the carrier frequency offset can also be estimated and corrected at > > the initiating USRP and then the correlation can be applied. In this > > scenario, the quality of the result will depend on how good the CFO > > estimate is. > > > > Cheers, > > Qasim > > > > > > > Message: 4 > > > Date: Tue, 26 Feb 2019 10:07:51 +0100 > > > From: Sylvain Munaut <246...@gmail.com> > > > To: Jonathan Preheim > > > Cc: GNURadio Discussion List > > > Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation > > > Message-ID: > > > > > > > > > Content-Type: text/plain; charset="UTF-8" > > > > > > > Any ideas about how we can troubleshoot this more effectively? Or > > > > better model the channel? > > > > > > Make sure both your radios are locked to the same clock source. > > > Any fsignificant requency offset between the two is going to ruin your > > > correlation peaks very quickly. > > > > > > Frequency offset is going to end up as a progressive phase shift along > > > your PN sequence. If that phase shift is a non-negligibe part of the > > > unit circle during the time of your PN sequence, they won't 'add up' > > > to a peak anymore. > > > > > > Cheers, > > > > > >Sylvain > > > > > > > > > > > > -- > > > > ___ > > 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 smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GSoC19] GNU Radio accepted as mentoring organization
Hi all, great news! We are once again accepted as mentoring organization for Google Summer of Code. Another great opportunity to bring fresh talent into the community! So, to all students: APPLY! =) We have a great selection of projects waiting, from DSP-heavy filter design, channel coding, and radar projects to GUI improvements with Qt. Please head over to our ideas list [0] and find the project that suits you best! Of course, if you have great ideas GNU Radio could profit from, do not hesitate to discuss them on this mailing list. We have also collected some information in [1,2] to give you an idea how the application process works, what we want to see in a proposal and how to become a successful GSoC student! The general GSoC timeline including the (very important!) deadlines can be found here [3]. The student application period officially begins in 4 weeks, but do not hesitate to introduce yourself before that date, especially if you have a project idea of your own for which you need to find a mentor! GSoC is a great opportunity for you to improve your coding skills, network with experts, learn how open source projects work, and make a real impact for a large user base - don't miss out on that! We usually also invite successful GSoC students to our annual GNU Radio conference, which will take place mid-September in Huntsville, Alabama. We're looking forward to hearing from you! Cheers, Felix (GSoC Org Admin 2019) [0] https://wiki.gnuradio.org/index.php/GSoCIdeas [1] https://wiki.gnuradio.org/index.php/GSoCStudentInfo [2] https://wiki.gnuradio.org/index.php/GSoCManifest [3] https://summerofcode.withgoogle.com/how-it-works/#timeline ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distance Measurement by Correlation
Hi all, Thanks for the responses. Ultimately, we won't be able to share a clock source directly, and I don't have the right cables right now to link them for troubleshooting. Even when I try to use the RF loopback modes though, I do not see a correlation peak. Firmware-based loopback works as expected. I've been trying to model a frequency offset with the Channel Model block, and compensate with the Costas loop block with a little success. But actually doing it on the radios does not work. The Costas loop handles frequency offsets up to 0.05 in simulations with an otherwise ideal channel. The chip rate is 1.25Mchip/s, so that's an offset of about 63kHz. The BladeRF's clock is 38.4MHz accurate to 1 ppm or 38.4Hz. Multiplied up to our carrier frequency of 910MHz, that's an expected accuracy of under 1kHz, so it's reasonable to expect that the Costas loop would take care of any offset right? Using the conjugate of the samples doesn't seem to make difference. That would make sense to me if I was trying to do the correlation as frequency domain multiplication by the conjugate, but I'm not (the FIR filter method has produced much more consistent results in simulations for us so far). Ideally, the samples would be completely real since it's BPSK, and we'd want to apply compensation in order to achieve roughly that, right? T'hanks, Jonathan On Tue, Feb 26, 2019 at 7:00 PM Qasim Chaudhari wrote: > >Make sure both your radios are locked to the same clock source. > Any fsignificant requency offset between the two is going to ruin your > correlation peaks very quickly. > > When the same clock source is not possible due to the distance between > them, the carrier frequency offset can also be estimated and corrected at > the initiating USRP and then the correlation can be applied. In this > scenario, the quality of the result will depend on how good the CFO > estimate is. > > Cheers, > Qasim > > > Message: 4 >> Date: Tue, 26 Feb 2019 10:07:51 +0100 >> From: Sylvain Munaut <246...@gmail.com> >> To: Jonathan Preheim >> Cc: GNURadio Discussion List >> Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation >> Message-ID: >> > uo2tdw...@mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> > Any ideas about how we can troubleshoot this more effectively? Or >> better model the channel? >> >> Make sure both your radios are locked to the same clock source. >> Any fsignificant requency offset between the two is going to ruin your >> correlation peaks very quickly. >> >> Frequency offset is going to end up as a progressive phase shift along >> your PN sequence. If that phase shift is a non-negligibe part of the >> unit circle during the time of your PN sequence, they won't 'add up' >> to a peak anymore. >> >> Cheers, >> >>Sylvain >> >> >> >> -- >> > ___ > 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
