[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linrad] mercury - more info



Hi Leif
 
Sorry - thought you were more familiar
 
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. That is why the PC sends the audio back to the card over the USB. You can get audio out at the PC if you want, using the VAC interface to PowerSDR (or whatever software you are running)
 
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).
 
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
 
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).
 
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
 
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.
 
of course, 196 kS/s is fast enough for the EME polarization diversity application.
 
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.   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. 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.
 
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.
 
73
 
Ken
 

--~--~---------~--~----~------------~-------~--~----~
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