[SDRSharp] Re: From a SDR Grapevine...


Alberto I2PHD
 

On 8/14/2013 4:01 AM, alan_r_cam wrote:

Wait... huh? No, no, no.

Yes, put a 20MHz IF on the SDR. BUT - you don't send all that to the PC. You do a FFT, then send a smidgen of data to the PC for your "waterfall" display.

THEN you select the band you want to listen to. That selection goes back to the SDR, and you filter JUST THAT PART and send it back to the PC. Even the I/Q decoding can be moved into the SDR. You shouldn't need more CPU, you should need LESS. Ultimately, you should aim for a standalone SDR with no PC processing at all - just display of status & playback of signal.

Wait... huh? No, no, no.

That is not not how an SDR program works.... have you ever written one ?

The ADC on the SDR samples, let's say, at 122.88 MHz. Those samples are passed to an FPGA which, using a NCO usually implemented
with the Cordic algorithm, does a downconversion that brings the center of the chunk of the spectrum of interest to zero Hz.
In doing this, the formerly real signal from the ADC is transformed to analytic, i.e. I and Q.

Then, with a series of CICs and FIRs the signal is downsampled let's say from 122.88 to 6.144 MHz.
The downsampled signal is then sent to the PC through the USB interface, and the SDR hardware doesn't see it anymore....

The software in the PC takes those 6+ millions of samples per second, does a further downconversion bringing to zero Hz the
specific signal of interest among those contained in the entire chunk received, and for this it uses a NCO this time not implemented
with a Cordic, but with a coupled quadrature oscillator (with level stabilization), then the signal is filtered, usually with the
fast convolution method (but there are those who still prefer FIRs...), then it is demodulated, etc. etc.
In a parallel thread, using a different core of the CPU, the spectrum and the waterfall are computed and displayed.

There is no ping-pong between the PC and the SDR hardware as your message would imply....
The bulk of the processing is done inside the PC, the SDR hardware just downconverts and downsamples the samples acquired by the ADC.
The SDR hardware does not do any FFT.

Or, as the latest product of Elad, the FDM-DUO, shown at the Friedrichshafen Ham Fair, the PC is not anymore needed....
What formerly was performed by the PC, in that product is performed by an ARM Cortex M4F CPU, filtering, demodulation,
waterfall computation and display, etc. etc.�� Also the TX part is implemented as a DUC coded in the ARM processor, which
in turn drives an Analog Devices AD9957 interpolator, quadrature modulator and DAC.

That transceiver is completely stand-alone, no pesky PC is anymore needed... perfect for a field day.....�� :-)

--
73 Alberto I2PHD


clement F59465
 

Hi,

Well explain Alberto !

Thx
73
F59465 Clem


2013/8/14 Alberto I2PHD <i2phd@...>

 

On 8/14/2013 4:01 AM, alan_r_cam wrote:

Wait... huh? No, no, no.

Yes, put a 20MHz IF on the SDR. BUT - you don't send all that to the PC. You do a FFT, then send a smidgen of data to the PC for your "waterfall" display.

THEN you select the band you want to listen to. That selection goes back to the SDR, and you filter JUST THAT PART and send it back to the PC. Even the I/Q decoding can be moved into the SDR. You shouldn't need more CPU, you should need LESS. Ultimately, you should aim for a standalone SDR with no PC processing at all - just display of status & playback of signal.

Wait... huh? No, no, no.

That is not not how an SDR program works.... have you ever written one ?

The ADC on the SDR samples, let's say, at 122.88 MHz. Those samples are passed to an FPGA which, using a NCO usually implemented
with the Cordic algorithm, does a downconversion that brings the center of the chunk of the spectrum of interest to zero Hz.
In doing this, the formerly real signal from the ADC is transformed to analytic, i.e. I and Q.

Then, with a series of CICs and FIRs the signal is downsampled let's say from 122.88 to 6.144 MHz.
The downsampled signal is then sent to the PC through the USB interface, and the SDR hardware doesn't see it anymore....

The software in the PC takes those 6+ millions of samples per second, does a further downconversion bringing to zero Hz the
specific signal of interest among those contained in the entire chunk received, and for this it uses a NCO this time not implemented
with a Cordic, but with a coupled quadrature oscillator (with level stabilization), then the signal is filtered, usually with the
fast convolution method (but there are those who still prefer FIRs...), then it is demodulated, etc. etc.
In a parallel thread, using a different core of the CPU, the spectrum and the waterfall are computed and displayed.

There is no ping-pong between the PC and the SDR hardware as your message would imply....
The bulk of the processing is done inside the PC, the SDR hardware just downconverts and downsamples the samples acquired by the ADC.
The SDR hardware does not do any FFT.

Or, as the latest product of Elad, the FDM-DUO, shown at the Friedrichshafen Ham Fair, the PC is not anymore needed....
What formerly was performed by the PC, in that product is performed by an ARM Cortex M4F CPU, filtering, demodulation,
waterfall computation and display, etc. etc.   Also the TX part is implemented as a DUC coded in the ARM processor, which
in turn drives an Analog Devices AD9957 interpolator, quadrature modulator and DAC.

That transceiver is completely stand-alone, no pesky PC is anymore needed... perfect for a field day.....   :-)

--
73 Alberto I2PHD




--

73'
Cordialement
F59465 Clement

My channel: F59465swl Youtube


jdow <jdow@...>
 

On 2013/08/14 08:42, Alberto I2PHD wrote:


On 8/14/2013 4:01 AM, alan_r_cam wrote:

/Wait... huh? No, no, no.//
/ /
//Yes, put a 20MHz IF on the SDR. BUT - you don't send all that to the PC. You
do a FFT, then send a smidgen of data to the PC for your "waterfall" display.//
/ /
//THEN you select the band you want to listen to. That selection goes back to
the SDR, and you filter JUST THAT PART and send it back to the PC. Even the
I/Q decoding can be moved into the SDR. You shouldn't need more CPU, you
should need LESS. Ultimately, you should aim for a standalone SDR with no PC
processing at all - just display of status & playback of signal./
Wait... huh? No, no, no.
/
/That is not not how an SDR program works.... have you ever written one ?

The ADC on the SDR samples, let's say, at 122.88 MHz. Those samples are passed
to an FPGA which, using a NCO usually implemented
with the Cordic algorithm/,/ does a downconversion that brings the center of the
chunk of the spectrum of interest to zero Hz.
In doing this, the formerly real signal from the ADC is transformed to analytic,
i.e. I and Q.

Then, with a series of CICs and FIRs the signal is downsampled let's say from
122.88 to 6.144 MHz.
The downsampled signal is then sent to the PC through the USB interface, and the
SDR hardware _doesn't see it anymore_....

The software in the PC takes those 6+ millions of samples per second, does a
further downconversion bringing to zero Hz the
specific signal of interest among those contained in the entire chunk received,
and for this it uses a NCO this time not implemented
with a Cordic, but with a coupled quadrature oscillator (with level
stabilization), then the signal is filtered, usually with the
fast convolution method (but there are those who still prefer FIRs...), then it
is demodulated, etc. etc.
In a parallel thread, using a different core of the CPU, the spectrum and the
waterfall are computed and displayed.

There is no ping-pong between the PC and the SDR hardware as your message would
imply....
The bulk of the processing is done inside the PC, the SDR hardware just
downconverts and downsamples the samples acquired by the ADC.
The SDR hardware does not do any FFT.

Or, as the latest product of Elad, the FDM-DUO, shown at the Friedrichshafen Ham
Fair, the PC is not anymore needed....
What formerly was performed by the PC, in that product is performed by an ARM
Cortex M4F CPU, filtering, demodulation,
waterfall computation and display, etc. etc. Also the TX part is implemented
as a DUC coded in the ARM processor, which
in turn drives an Analog Devices AD9957 interpolator, quadrature modulator and DAC.

That transceiver is completely stand-alone, no pesky PC is anymore needed...
perfect for a field day..... :-)

--
/*73 Alberto I2PHD*/
If I am not mistaken he was groping towards describing an SDR that shoves
some of the signal stream calculations into the SDR itself.

Let the SDR "RF block" carry out the initial decimation as happens now.
(In the case of RTL dongles the sample rate is generally 28.8 MHz. This
is decimated or resampled down to something more transportable - say
2.4 Msps.) Then move the FFT calculation process back into the RF block
on data that never left the RF block. Add some plus some additional
steps to select a portion of the FFT data block using a second VFO and
decimation process to get the sample rate down to something easy for the
PC to handle and still plenty wide enough to handle expected modulation
modes. Nothing ever transports backwards from the computer block. But the
computer block now collects two batches of data, the wide band FFT output
and the narrower preselected and pretuned "IF block data."

The computer then behaves like SDRSharp's FFT display on the FFT data
received over the USB link from the RF block. It separately processes
the IF data received from the RF block to demodulate the signal. That
leaves you with a wide spectrum display as well as extreme mode agility
due to the partitioning of the calculations involved in the entire system
design. (It looks like the Apache SDR goodies do or can do this very
neatly.)

I am very much NOT looking for a standalone SDR. If I want a standalone
receiver or transceiver then I purchase a black box that performs the
precise functions I wish without reference to the hardware design inside.
If I am looking for something I can explore, tweak, modify, tune, and
so forth equivalent to the command sets of my (MUCH) younger days or the
old NC109 I had (and modified) then I look for something as hardware dumb
as the RTL dongles to as hardware smart as the Hermes (can be.)

It's a little like OS rwars - pick the job you wish to perform then without
reference to the guts purchase the object/computer plus OS/SDR vs Analog
that performs the job best. The better you define the job, including user
interface, the more pleased you'll be with the results.

{^_^} Joanne/W6MKU