Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Dear Marcus, Please avoid adding more confusions rather than clarities. The term upconversion and downconversion are common terms used in the radio engineering industry, but may not be common among other technical folks. In radio engineering industry, there are more than 1 type of upconversion or downconversion. The common types include: a). analog up-conversion: The baseband real signal x(t) will be mixed with a carrier frequency, that its output is a real signal of y(t) = x(t).cos(wt) where w = central frequency b). complex up-conversion: The baseband complex-based signal x(t) = I(t) + j.Q(t) will be quadrature upconverted so that its output is a real signal of y(t) = I(t).cos(wt) - Q(t).sin(wt) For clarity sometimes we need to clarify which one you were referring to. These two (analog vs complex upconverter) are significantly very different from each other. The complex upconverter simply sums the two components after mixing, to produce a valid real-valued analog signal. Are you saying SBX performs this complex upconversion? But earlier you said SBX just performed analog upconversion and nothing more. But, again, none of the daughtercards that Ettus produces are designed to extract *information* from the signal--they merely manipulate it so that it is represented in a complex baseband form that can easily be digitized by the ADCs. You are saying the output of SBX is in complex baseband. This means SBX perform complex down-conversion. But earlier you said SBX performed just analog down-conversion and nothing more. One impresses *information* on an RF carrier by modulating it--doing stuff to that carrier so that the information can be recognized by a suitable receiver. There are hundreds of different ways of doing this, depending on the required attributes of the resulting signal, etc. Are you saying SBX daughtercard will automatically select the correct way depending on the received signal? In my flow graph there is no configuration to tell the SBX which way to use. You square-wave example is roughly similar to so-called OOK--on/off keying. Such techniques are generally only used for very-low-speed data transmission, owing to the unpleasant spectral properties of signals with sharp edges. There are no documentation of what SBX performs on incoming or outgoing signals. https://www.ettus.com/product/details/SBX If Ettus support personnel doesn't clear things up, the Ettus products continue to remain mystery to many newcomers. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech mle...@ripnet.com wrote: The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way. That is what SDR is all about--the signals are represented as complex-baseband (i/Q) format for processing by computer algorithms. The SBX (or any other daughtercard) is simply doing downconversion (or, upconversion for TX). Even the simplest quadrature downconversion also needs to avoid clock drift. http://en.wikipedia.org/wiki/Quadrature_modulation#Clocking If your analog downconversion above refers to quadrature downconversion, then it is very important to have a phase lock loop (PLL) on the SBX to avoid clock drift. How could this PLL only present at the host (gnuradio flow graph), but not Ettus SBX daughtercard ? Does the flow-graph PLL able to correct all effects due to clock drift of SBX? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Hi, There are no documentation of what SBX performs on incoming or outgoing signals. https://www.ettus.com/product/details/SBX IMHO Ettus is among the brands where there is the _least_ surprises just because the exact schematic is published, you can see _exactly_ what the SBX does to your signal ... If Ettus support personnel doesn't clear things up, the Ettus products continue to remain mystery to many newcomers. Just a thought, but have you considered that newcomers aren't the target audience ? SDR has radio in it, and to use them properly you kind of need an understanding of how radio works. Ettus isn't here to teach you the fundamentals of RF, Radios, DSP, SDR, ... you're supposed to learn those by yourself beforehand. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On Sat, Mar 15, 2014 at 4:05 PM, Sylvain Munaut 246...@gmail.com wrote: There are no documentation of what SBX performs on incoming or outgoing signals. https://www.ettus.com/product/details/SBX IMHO Ettus is among the brands where there is the _least_ surprises just because the exact schematic is published, you can see _exactly_ what the SBX does to your signal ... Let's see yourself at http://code.ettus.com/redmine/ettus/projects/public/documents This is the link referred by http://www.ettus.com/kb/detail/frequently-asked-questions This link leads to The page you were trying to access doesn't exist or has been removed ! If Ettus support personnel doesn't clear things up, the Ettus products continue to remain mystery to many newcomers. Just a thought, but have you considered that newcomers aren't the target audience ? Newcomers refer to those who purchase Ettus products for the first time. Sadly they are not given appropriate attention even through they are consumers of Ettus. SDR has radio in it, and to use them properly you kind of need an understanding of how radio works. Ettus isn't here to teach you the fundamentals of RF, Radios, DSP, SDR, ... you're supposed to learn those by yourself beforehand. I do not expect Ettus to teach me the fundamentals, but to clarify fundamental details with Ettus support personnel who seem to confuse with RF fundamentals. You may refer to previous conversations. Do you agree with him that a simple quadrature downconverter doesn't need to care about clock drift because it just simply downconverter and nothing more? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Hi, Let's see yourself at http://code.ettus.com/redmine/ettus/projects/public/documents This is the link referred by http://www.ettus.com/kb/detail/frequently-asked-questions This link leads to The page you were trying to access doesn't exist or has been removed ! Wow, they have a broken link because there was a reorganization recently, big deal. Use the power of google ... 4th link when searching for Ettus SBX schematic And it's also in their file repo http://files.ettus.com/schematics/sbx/sbx.pdf if you want it from official source. You may refer to previous conversations. Do you agree with him that a simple quadrature downconverter doesn't need to care about clock drift because it just simply downconverter and nothing more? Yes ... Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On Sat, Mar 15, 2014 at 5:14 PM, Sylvain Munaut 246...@gmail.com wrote: You may refer to previous conversations. Do you agree with him that a simple quadrature downconverter doesn't need to care about clock drift because it just simply downconverter and nothing more? Yes ... Cheers, Sylvain In this case I shall rephrase my question to: How to compensate the error due to clock drift which is not handled by a simple quadrature upconverter ? Could anyone of gnuradio forum gives me some idea ? I hope this is no longer categorized as expecting Ettus to teach me the fundamentals of RF. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On Sat, 15 Mar 2014 17:46:58 +0800 Activecat active...@gmail.com wrote: In this case I shall rephrase my question to: How to compensate the error due to clock drift which is not handled by a simple quadrature upconverter ? I do not want to sound rude or anything, but you are asking very basic questions on radio communications. You should read a textbook or go to an introductory class on that topic. You can find recommended documents on the suggested reading page[1]. Especially the Digital Comms section. Also a good idea would be to do an Ham Radio licensing course. These usually cover the most basic modulations and how it relates to real devices too. Attila Kinali [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading/ -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On Sat, Mar 15, 2014 at 10:46 AM, Activecat active...@gmail.com wrote: On Sat, Mar 15, 2014 at 5:14 PM, Sylvain Munaut 246...@gmail.com wrote: You may refer to previous conversations. Do you agree with him that a simple quadrature downconverter doesn't need to care about clock drift because it just simply downconverter and nothing more? Yes ... Cheers, Sylvain In this case I shall rephrase my question to: How to compensate the error due to clock drift which is not handled by a simple quadrature upconverter ? Could anyone of gnuradio forum gives me some idea ? I hope this is no longer categorized as expecting Ettus to teach me the fundamentals of RF. Activecat, It was mentioned earlier in this thread, you can use a PLL to lock to a carrier. Basically, you need an algorithm that performs carrier recovery. This thread is starting to get a little too confrontational, so we all need to take a bit of a break. Please take a look at the PLL blocks in GNU Radio; you can find them under the Synchronizers category in the block tree of GRC. Spend some time understanding these blocks and how to use them. If you still have questions, please open another email thread. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On Sat, Mar 15, 2014 at 5:56 PM, Tom Rondeau t...@trondeau.com wrote: It was mentioned earlier in this thread, you can use a PLL to lock to a carrier. Basically, you need an algorithm that performs carrier recovery. This thread is starting to get a little too confrontational, so we all need to take a bit of a break. Please take a look at the PLL blocks in GNU Radio; you can find them under the Synchronizers category in the block tree of GRC. Spend some time understanding these blocks and how to use them. If you still have questions, please open another email thread. Thanks, Tom I saw those PLL blocks but basically these blocks extract clocking at the host (PC), while clock locking is needed at the SBX. I feel you guys doesn't understand my concern. Nevertheless I understand this starts to get confrontational, so I have to stop here. Sorry for any misunderstanding and offense arisen. Thank you very much. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/15/2014 02:57 AM, Activecat wrote: Dear Marcus, Please avoid adding more confusions rather than clarities. The term upconversion and downconversion are common terms used in the radio engineering industry, but may not be common among other technical folks. In radio engineering industry, there are more than 1 type of upconversion or downconversion. The common types include: a). analog up-conversion: The baseband real signal x(t) will be mixed with a carrier frequency, that its output is a real signal of y(t) = x(t).cos(wt) where w = central frequency b). complex up-conversion: The baseband complex-based signal x(t) = I(t) + j.Q(t) will be quadrature upconverted so that its output is a real signal of y(t) = I(t).cos(wt) - Q(t).sin(wt) For clarity sometimes we need to clarify which one you were referring to. These two (analog vs complex upconverter) are significantly very different from each other. I was using the term analog to distinguish from digital. The FPGA *also* has up/downconverters for doing offsetting and mop up operations on the signal stream, and those operations are, necessarily, performed on a digital sample stream, rather than on an analog electron stream. A quadrature up (or down) converter is structurally very similar to a real-valued converter, and most folks in the industry refer to both as upconversion and downconversion. While the mathematical expressions that describe them are, as you note, different, they're performing a very similar function, and use nearly-identical hardware, except that in the complex (quadrature) case, you have two mixers, and a phase-split local oscillator. You can see the schematics of SBX (and other cards) here: http://www.ettus.com/files/schematics ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
This thread is starting to get a little too confrontational, so we all need to take a bit of a break. Please take a look at the PLL blocks in GNU Radio; you can find them under the Synchronizers category in the block tree of GRC. Spend some time understanding these blocks and how to use them. If you still have questions, please open another email thread. Thanks, Tom ___ Sorry, Tom. I posted another in the thread before looking at you drop this thread message. My bad. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
I have found the answers. http://nutaq.com/en/blog/multi-channel-synchronization-fpga-based-daq-systems http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm On the Nutaq platforms (ZeptoSDR, PicoSDR) you can control VCXO voltage DAC from GNU Radio (and from FPGA user logic) to implement carrier frequency offset correction. Thanks everyone for your help. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Hi, I try to send square wave from one USRP to another. The received signal at the receiver USRP is very different from what was being sent. This is just a very simple setup. What could be wrong ..? Apparently your understanding of how things work :) First thing, square waves have infinite bandwidth, the DAC can't generate them properly, the ADC can't capture them properly and they'll be modified by the IF filters. The effect of that is to round off the edges. And since you sample at 32k, that's probably going to be fairly visible. Then the second and major thing is that I Q aren't magically transmitted and received perfectly aligned. Unless you use the _exact_ same totally phase aligned LO and ensure the propagation delay to have the ADC sample exactly on your DAC transmitted symbols, the I Q you receive won't be the I Q you transmit, you'll have random time and phase alignement. That's kind of why people use modulation rather than TX raw binary waveforms. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/13/2014 09:32 PM, Activecat wrote: I try to send square wave from one USRP to another. The received signal at the receiver USRP is very different from what was being sent. This is just a very simple setup. What could be wrong ..? What you are seeing is a classic case of frequency/phase offset between the transmitter and receiver, introducing a rotation in the I/Q domain at baseband equal to the difference frequency. In spite of calibrating things, you have only made the transmitter and receiver local oscillator frequencies close. All real-world receivers must implement a correction loop to estimate this frequency and compensate for it, which eliminates the rotation. This correction loop often takes the form of a phase-locked loop, of which there are several in GNU Radio. For the type of waveform you are transmitting, the PLL Carrier Tracking loop should work, as your baseband waveform results in significant carrier energy when upconverted to passband. Also, the amplitude of the data you are transmitting at baseband is likely too high; you can see evidence of numerical overflow in the received signal. I suggest you limit the amplitude of the square wave baseband waveform to +-0.7; this prevents the magnitude of the signal exceeding 1.0 in the CORDIC stage of the DUC in the USRP. If any of the above concepts are unfamiliar to you, there are excellent references in the Suggested Reading page on the GNU Radio wiki. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com attachment: johnathan.vcf signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Dear Sylvain, On Fri, Mar 14, 2014 at 2:17 PM, Sylvain Munaut 246...@gmail.com wrote: First thing, square waves have infinite bandwidth, the DAC can't generate them properly, the ADC can't capture them properly and they'll be modified by the IF filters. The effect of that is to round off the edges. I am using Ettus SBX daughtercard at the transmitter USRP to transmit complex square wave (means the signal is in IQ form). https://www.ettus.com/product/details/SBX I understand that SBX performs quadrature up-conversion automatically, and this feature cannot be disabled. Hence, the signal sent to the transmitter antenna is no longer square waves, but IQ up-converted signal. That's why I guess the round off the edges effect is no longer applicable here. At the receiver side, another SBX daughtercard should have automatically down-converted the signal back into IQ form. Here I expect the signal output from SBX become (nearly) square wave. And since you sample at 32k, that's probably going to be fairly visible. I repeat the test with sampling rate changed to 1MHz at both sides, this gain similar undesirable result. Then the second and major thing is that I Q aren't magically transmitted and received perfectly aligned. Now I am focusing on the frequency and phase alignment issue. Thank you very much. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Dear Johnathan, On Fri, Mar 14, 2014 at 2:21 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 03/13/2014 09:32 PM, Activecat wrote: I try to send square wave from one USRP to another. The received signal at the receiver USRP is very different from what was being sent. This is just a very simple setup. What could be wrong ..? What you are seeing is a classic case of frequency/phase offset between the transmitter and receiver, introducing a rotation in the I/Q domain at baseband equal to the difference frequency. In spite of calibrating things, you have only made the transmitter and receiver local oscillator frequencies close. All real-world receivers must implement a correction loop to estimate this frequency and compensate for it, which eliminates the rotation. This correction loop often takes the form of a phase-locked loop, of which there are several in GNU Radio. For the type of waveform you are transmitting, the PLL Carrier Tracking loop should work, as your baseband waveform results in significant carrier energy when upconverted to passband. I was told that the Ettus SBX daughtercard has built-in PLL capability. In this case is the flowgraph-based PLL still necessary ..? Refer below message from Ettus support engineer. -- Forwarded message -- From: Marcus D. Leech mle...@ripnet.com Date: Sun, Feb 2, 2014 at 8:50 PM Subject: Re: [Discuss-gnuradio] undocumented SBX behavior To: Activecat active...@gmail.com On 02/02/2014 07:03 AM, Activecat wrote: Dear Marcus, At the receiver USRP, does the SBX daughtercard have any mechanism of phase-lock-loop (PLL) ? I guess the daughtercard should have it because PLL is essential for quadrature downconversion. Please advise, thanks. Regards, activecat Yes, the synthesizers are PLL based. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 14.03.2014 09:50, Activecat wrote: In spite of calibrating things, you have only made the transmitter and receiver local oscillator frequencies close. All real-world receivers must implement a correction loop to estimate this frequency and compensate for it, which eliminates the rotation. This correction loop often takes the form of a phase-locked loop, of which there are several in GNU Radio. For the type of waveform you are transmitting, the PLL Carrier Tracking loop should work, as your baseband waveform results in significant carrier energy when upconverted to passband. I was told that the Ettus SBX daughtercard has built-in PLL capability. In this case is the flowgraph-based PLL still necessary ..? Refer below message from Ettus support engineer. Hi Activecat, our synthesizers use PLLs, but this won't solve frequency offset issues with your transceiver. This is not a limitation of USRPs, but fundamentally necessary in every receiver. Here's a very brief explanation: The PLL for the synthesizer makes sure the locally generated frequency is stable (per-device). It's physically impossible to make perfectly aligned oscillators. By throwing money at the problem, you can reduce the potential offset. But since you can never get rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the incoming signal. Phase is another story. Even in a world with perfect oscillators, your phase can be rotated. That's something else you have to account for. Have a look at the examples in gr-digital/examples/demod. You'll see many mechanisms to correct offsets between tx and rx (time, phase and frequency). These are all standard components for digital transceivers. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/14/2014 01:50 AM, Activecat wrote: In spite of calibrating things, you have only made the transmitter and receiver local oscillator frequencies close. All real-world receivers must implement a correction loop to estimate this frequency and compensate for it, which eliminates the rotation. This correction loop often takes the form of a phase-locked loop, of which there are several in GNU Radio. For the type of waveform you are transmitting, the PLL Carrier Tracking loop should work, as your baseband waveform results in significant carrier energy when upconverted to passband. I was told that the Ettus SBX daughtercard has built-in PLL capability. In this case is the flowgraph-based PLL still necessary ..? Refer below message from Ettus support engineer. The hardware PLL in the receive section of the daughterboard serves an entirely different purpose; it is there to create the local oscillator signal at the frequency requested when tuning. However, that frequency is ultimately derived from a hardware oscillator that is subject to manufacturing tolerances, drift, thermal effects, phase noise, etc. So even when both transmitter and receiver are physically tuned to what you set as the same frequency, in reality there is an offset between them, and even the amount of that offset changes on a moment-by-moment basis. It is an unavoidable reality of designing radio receivers that one must compensate for this offset in transmitter and receiver local oscillator frequencies. In software radio systems, this is most often done by estimating the frequency/phase error and performing de-rotation on the resulting waveform. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com attachment: johnathan.vcf signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/14/2014 01:05 PM, Johnathan Corgan wrote: The hardware PLL in the receive section of the daughterboard serves an entirely different purpose; it is there to create the local oscillator signal at the frequency requested when tuning. However, that frequency is ultimately derived from a hardware oscillator that is subject to manufacturing tolerances, drift, thermal effects, phase noise, etc. So even when both transmitter and receiver are physically tuned to what you set as the same frequency, in reality there is an offset between them, and even the amount of that offset changes on a moment-by-moment basis. It is an unavoidable reality of designing radio receivers that one must compensate for this offset in transmitter and receiver local oscillator frequencies. In software radio systems, this is most often done by estimating the frequency/phase error and performing de-rotation on the resulting waveform. I would emphasize that this requirement isn't a quirk of SDR hardware--every digital radio system ever has needed some kind of offset error estimator to track differences between TX and RX phase/frequency. In analog systems (like NBFM voice, or FM radio, or AM audio), it's generally not as necessary, because it's hard for humans to hear minor frequency offsets. But for data systems, an error estimator is vital.Even in WBFM, I've implemented an AFC block to compensate for the crappy (RTLSDR) master clock on the receiver. But each modulation type and coding system will have its own way of estimating phase/frequency error which you'll have to implement, or just live with bad BER. -- 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] Failure of sending square wave over USRPs (back-to-back)
Dear Martin, On Fri, Mar 14, 2014 at 5:13 PM, Martin Braun martin.br...@ettus.com wrote: Here's a very brief explanation: The PLL for the synthesizer makes sure the locally generated frequency is stable (per-device). It's physically impossible to make perfectly aligned oscillators. By throwing money at the problem, you can reduce the potential offset. But since you can never get rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the incoming signal. At the receiver side, the received signal is first processed by SBX daughtercard before being sent it to the host (which is the PC). The IQ demodulation is performed at the receiving SBX, not at the host. In this case the clocking of SBX must be synchronized to the received IQ-modulated signal. Hence the PLL must be done precisely in the SBX, not in the host, correct? If the PLL is done at the gnuradio flow graph, then this flow graph must be able to adjust the local oscillator of the SBX daughtercard, via softare. Does gnuradio flow graph have this capability? Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/14/2014 10:51 PM, Activecat wrote: Dear Martin, On Fri, Mar 14, 2014 at 5:13 PM, Martin Braun martin.br...@ettus.com wrote: Here's a very brief explanation: The PLL for the synthesizer makes sure the locally generated frequency is stable (per-device). It's physically impossible to make perfectly aligned oscillators. By throwing money at the problem, you can reduce the potential offset. But since you can never get rid of it entirely, you also need a mechanism (e.g. a PLL) to lock on the incoming signal. At the receiver side, the received signal is first processed by SBX daughtercard before being sent it to the host (which is the PC). The IQ demodulation is performed at the receiving SBX, not at the host. In this case the clocking of SBX must be synchronized to the received IQ-modulated signal. Hence the PLL must be done precisely in the SBX, not in the host, correct? If the PLL is done at the gnuradio flow graph, then this flow graph must be able to adjust the local oscillator of the SBX daughtercard, via softare. Does gnuradio flow graph have this capability? Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way. That is what SDR is all about--the signals are represented as complex-baseband (i/Q) format for processing by computer algorithms. The SBX (or any other daughtercard) is simply doing downconversion (or, upconversion for TX). Frequency offset in a digital demodulator implemented in software generally drives a local correction--not the hardware. You achieve this by bringing in a bit more bandwidth than you actually need, and then applying frequency corrections in software. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
Dear Marcus, On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech mle...@ripnet.com wrote: The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way. Please be clarified what do you mean by analog downconversion. At the transmitter side, complex-based (I/Q) signal is fed into USRP. Says, the signal is x(t) = I(t) + j.Q(t) I think this is performed at transmitter SBX: y(t) = I(t).cos(wt) - Q(t).sin(wt) where w = central frequency, t = time here the y(t) is the output of SBX to the antenna. Is this what you meant by analog upconversion ? Whereas at the receiver side, the received signal from antenna is real signal, says, z(t) = c.y(t) = c.I(t).cos(wt) - c.Q(t).sin(wt)where c = channel attenuation The receiver SBX performs this: Retrieved I(t) = LPS( z(t).cos(wt) )where LPS = low pass filter Retrieved Q(t) = LPS( z(t). sin(wt) ) With this process the receiver SBX is able to produce complex-based (I/Q) signal from the real signal from antenna. Is this what you meant by analog downconversion? If not, please describe what you mean by analog upconversion and analog downconversion, because I have no idea of what you are trying to explain. It is impossible that SBX only mix the incoming complex-based signal with a central frequency and then send directly to antenna for transmission, because the simple mixing (analog upconversion) produces another complex-based signal which cannot be transmitted through antenna. A physical antenna can only transmit real signal, not complex-based signal. Please clarify, thanks. Regards, Activecat That is what SDR is all about--the signals are represented as complex-baseband (i/Q) format for processing by computer algorithms. The SBX (or any other daughtercard) is simply doing downconversion (or, upconversion for TX). Frequency offset in a digital demodulator implemented in software generally drives a local correction--not the hardware. You achieve this by bringing in a bit more bandwidth than you actually need, and then applying frequency corrections in software. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)
On 03/15/2014 12:10 AM, Activecat wrote: Dear Marcus, On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech mle...@ripnet.com wrote: The SBX does analog downconversion, nothing more. It knows nothing about the incoming signal, and doesn't demodulate it in any way. Please be clarified what do you mean by analog downconversion. At the transmitter side, complex-based (I/Q) signal is fed into USRP. Says, the signal is x(t) = I(t) + j.Q(t) I think this is performed at transmitter SBX: y(t) = I(t).cos(wt) - Q(t).sin(wt) where w = central frequency, t = time here the y(t) is the output of SBX to the antenna. Is this what you meant by analog upconversion ? Whereas at the receiver side, the received signal from antenna is real signal, says, z(t) = c.y(t) = c.I(t).cos(wt) - c.Q(t).sin(wt)where c = channel attenuation The receiver SBX performs this: Retrieved I(t) = LPS( z(t).cos(wt) )where LPS = low pass filter Retrieved Q(t) = LPS( z(t). sin(wt) ) With this process the receiver SBX is able to produce complex-based (I/Q) signal from the real signal from antenna. Is this what you meant by analog downconversion? If not, please describe what you mean by analog upconversion and analog downconversion, because I have no idea of what you are trying to explain. It is impossible that SBX only mix the incoming complex-based signal with a central frequency and then send directly to antenna for transmission, because the simple mixing (analog upconversion) produces another complex-based signal which cannot be transmitted through antenna. A physical antenna can only transmit real signal, not complex-based signal. Please clarify, thanks. Regards, Activecat The term upconversion and downconversion are common terms used in the radio engineering industry, but may not be common among other technical folks. The complex upconverter simply sums the two components after mixing, to produce a valid real-valued analog signal. But, again, none of the daughtercards that Ettus produces are designed to extract *information* from the signal--they merely manipulate it so that it is represented in a complex baseband form that can easily be digitized by the ADCs. One impresses *information* on an RF carrier by modulating it--doing stuff to that carrier so that the information can be recognized by a suitable receiver. There are hundreds of different ways of doing this, depending on the required attributes of the resulting signal, etc. You square-wave example is roughly similar to so-called OOK--on/off keying. Such techniques are generally only used for very-low-speed data transmission, owing to the unpleasant spectral properties of signals with sharp edges. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
