[Linrad] Re: mercury - more info

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Hi Ken,

> the concept with Mercury is that your PC does not even need a 
> sound card. Having no analog connections between the front end 
> and the PC means that no IQ balancing is required, etc.
Hmmm, IQ balancing is always needed if the hardware has
an analog quadrature mixer. Putting the A/D converters externally
does not change anything. The Mercury has a digital quadrature mixer
so no balancing is needed....

> That is why the PC sends the audio back to the card over the USB. 
So you mean that sending nothing (zeroes) back would be ok to the OZY?
The specification seems to say something else....

> You can get audio out at the PC if you want, using the VAC 
> interface to PowerSDR (or whatever software you are running)
My interest is limited to whether the hardware would be suitable
as hardware supported by Linrad. 

> The block diagram is shown here:
> 
> http://hpsdr.org/wiki/index.php?title=MERCURY
> 
> I am not an expert on this stuff  (perhaps obvious by now?) 
> so in looking for more information I stumbled across this article
> 
> http://www.ifn.et.tu-dresden.de/MNS/veroeffentlichungen/2002/Hentschel_T_Wiley_02.pdf
> 
> which describes the theory behind a system very much like Mercury 
> (CORDIC followed by multi-rate decimating bandpass filters).
This is the same as SDR-14, SDR-IQ, SDR-14 and others. From my point of
view the Mercury is just one more of the kind. The problems I see are
caused by its integration into a system with limited performance.


> I believe QS1R you mentioned shares many features with Mercury (or vice versa) to see the relationship between the two projects look here
> http://pcovington.blogspot.com/2007/10/history-of-hpsdr-mercury-and-quick..html
This page was not available from here.

> With firmware modifications Mercury's bandwidth is limited only 
> by the USB (480 Mb/s divided by the size of each sample plus 
> overhead - certainly it is in the multi-megahertz range if 
> the PC could swallow data that fast).
Linrad runs happily at 2 MHz with the Perseus on a modest computer.
I do not have the skils to do the appropriate firmware for Mercury however.

> For example, here is a spectrum analyzer based on Mercury that 
> (apparently) produces data faster than the PC can swallow it. 
> http://hpsdr.org/wiki/index.php?title=CYCLOPS
That is because of sub-optimal PC programming I would guess....

> It looks to me that if all the CIC filters in Mercury were set 
> to their minimum decimation rate, you would get 1.024 MS/s. 
> I don't know if that is feasible due to other constraints, 
> but in principle any such thing could be programmed up.
Sure, in principle yes, but to invest time in putting yet another
input routine into Linrad I would need a well working and stable
drive routine to interface to......
 
> of course, 196 kS/s is fast enough for the EME polarization 
> diversity application.
Yes. 

> I am still having some trouble understanding the synchronizing 
> issue. Everything in the signal path is being clocked by the 
> same oscillator and the two oscillators will be fed by a common 
> reference source. 
Yes. This is the first necessary condition.

> The software sync that I am proposing would be one of lining-up 
> corresponding samples and basically amount to an integer number 
> ( probably +/- 200 ) that you shift one set of samples by so they 
> match up with the other set. 
But one sample at the output corresponds to 640 samples at the input.
There are 640 different possibillities, each one time shifted by
8 ns. Wideband calibration is difficult. Pulses in the two channels
will be two or three samples at 192 kHz depending on details in
the decimation filters. They will be surrounded by oscillations
that extend in proportion to the Q of the filter skirts, presumably
10 to 30 points. The pulses in the two channels will not look
very similar, translating the difference to a time shift is not
so easy. In all, wideband calibration will not be be easy.


> It could be done in the software that reads the data from 
> the USB - not in the core of Linrad.  This same software should 
> make sure that it alternately reads one USB then the other - never 
> the same one twice - regardless of what the operating system is doing.
> 
> The one problem I can see is that, when you tune the radio 
> to a  new center frequency, the two NCO's would get the new 
> frequency numbers at slightly different times and  change 
> their NCO's at different times. For certain this would require 
> resynchronization.
> 
> But again - for the EME application - this is not a problem.
OK. Narrowband calibration is different. Assume the driver
takes care of selecting the nearest sample and thus makes the
time error less than 5 microseconds and that we use a sinewave
at the center frequency for calibration. That would be trivial.
Signals near the center frequency will then get the correct
polarisation readout. A signal 75 kHz away may get the correct
phase (=time) but it may also be shifted by up to 5 us.
At 75kHz a full period is 13 us so the phase error could become
as large as 140 degrees. We want the phase error to be less than
45 degrees to be sure what tx polarisation to use and therefore
the useful bandwidth would be +/- 25 kHz. The receive sensitivity
will not be affected at all, so all stations within the full
150 kHz or so will be received equally well. In case an interesting
signal is heard outside the calibrated range it would be trivial
to transmit for a fraction of a second with equal signal into
both channels and use the recorded polarisation to recalibrate
the polarisation indicator for the new frequency.


> I guess the question comes down two how close the two contemporaneous samples stay in time (phase)? This translates into: what is the phase difference between the two 122.88 MHz oscillators. One would expect that they would stay within a degree, with some random jitter ... it should be possible to check this in an experiment.  Having identified the pair of samples that are contemporaneous, the point in time when they were taken should correspond to this small phase angle difference.  If this proves to be too large of a difference then connecting the oscillator from one board over to the other would be the preferred. That would really make it a 4-channel down converter.

Phase jitter is another thing. It will only affect "reciprocal mixing"
the noise sidebands that surround very strong signals. If both units
are locked to the same reference oscillator it does not matter if
they drift randomly over a large time span. On the average the
phase will stay constant. The random drift is FM modulation
and translated to phase shift in the baseband it would be extremely
small and totally insignificant if the time shift varies slowly 
with time. The time constant of the two PLLs that keep the Mercurys
locked to 10 MHz determines the details. To affect the signal we
hear, the phase shift has to be more than 10 degrees over a time
of 1/bw, in the order of 0.01 seconds. The PLLs are VERY much
faster than that.

Surely the route you propose would be possible, but I think direct
synchronization of the hardware would be trivial. It could require
a small layout change in order to allow a connector to allow the
FPGAs of the two Mercury boards to synchronize.

Rather than writing dedicated software for a "temporary solution"
to the two channel problem I prefer to wait for the first solution
in hardware. For the SDR-14 it would be trivial, the decimation
chip from Analog devices already contains everything needed.
One just has to connect a couple of pins between tha chips
on two (or more) boards and figure out how to read two different
SDR-14 units from different USB ports. The only software
problem would be to select what sample on USB1 to pair with
sample N on USB2. One or two more wires between the units
should solve that easily if one would make appropriate
changes in the FPGA code.

I am 100% sure that multi-channel receivers will produce far
bigger advantages on HF bands as compared to 144 MHz. Those who
would be interested are not yet aware of it, but I am sure
they will find out some day. Have a look here:
http://www.sm5bsz.com/lir/am640/am640.htm

The page is preliminary and not linked to from anywhere.
It has some impractical .wav files that should be changed to
mp3 and there are several other things that I will change.
The conclusion at the bottom of the page should be well 
understood by many of the serious MWDX operators. They really 
care about receiving weak signals under difficult QRM situations. 
In my experience, amateur HF operators typically do not
care. Contesters should benefit greatly by having a stereo
system because their ear-brain system could better
select which station to answer in a pile-up. I have failed
to make anyone interested so far, but I really did not make
much of an effort yet. I did provide the hardware, but
it seems nobody with two beverages tried the WSE converters
on 160 m in a contest yet....

73

Leif / SM5BSZ 
 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL