[Linrad] Re: more on Mercury

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

Hello Ken,

> The protocol for OZY is here (if you have not seen)
> 
> http://www.hamsdr.com/data/GlobalFileUploads/8__HPSDR_USB_protocol_V1_0.doc 
Thank you for this link. It makes me confused - I do not understand
the over-all structure. Why does the PC have to send received audio
to HPSDR for example.
I am also a bit disappointed to see that the sampling speed is limited to
192 kHz.
 
> this doc includes a link to the SVN where you can find the atual c code that talks to OZY vis LibUSB
> 
> (this driver is available in Linux as well as Windows)
> 
> Just implementing this would be a great first step.
Depends on why HPSDR needs received audio (left and right)
Is it simply containing a soundcard?
The protocol looks simple enough though...
 
> In terms of synchronization for two-receiver diversity reception - no problem.
??????
> The Mercury has several ways to sync the down-conversion clock.  I am using a version of the firmware that sync's the 122.88 sampling clock to an external 10 MHz reference. It uses an Altera "megafunction" PLL and produces a very stable and clean clock. One could feed the same 10 MHz oscillator into both Mercury boards and they would be in lock-step with each other. (There is also a way to connect the 122.88 from one board to the other - this sounds trickier). Anyway both of these avoid sending the signal across the problemmatical backplane bus.

I am sorry, but that would not solve any of the sync problems.

1) The FPGA contains a divider that produces a lower sampling rate
(e.g. 192 kHz) Division is most probably in several steps.
All those dividers must run synchronously and therefore you
need one or more sync lines that make sure the counters
(dividers) run synchronously.

2) One way or another the two data streems on the two USB devices
must run synchronously. I guess it would not be too difficult to
make two OZY boards exchange data and set a flag that the PC can use for
synchronisation, but it would be much easier to use the same OZY.
for both Mercury boards.

The bandwidth restriction to 2*96 kHz (???) makes the value
questionable.

 
> Assuming that the USB communications are significantly faster than the data rate coming from the downconversion/decimation (must be to avoid audio drop outs) then the samples coming into Linrad will always stay in the same relationship to each other (in 512 byte packets). 

Maybe. Under Linux OK, but under Windows some other software may block
the PC for a while now and then...

> The sampling clocks on Mercury force the data in the USB links to also be in lock-step.  All that is needed is a one-time-per-powerup synchronization. Any fast rise-time pulse coming into both boards could probably be used for this. One could try to have a simultaneous reset of the two FPGA's but I suspect that would be hard to do ... a software sync would be better.

Well, that would be possible. The time shift converts to a phase shift
between the channels for a narrowband signal. Evaluating the time shift
properly is difficult since the bandwidth is such a small fraction
of the sampling frequency. One would have to measure the phase shift
at many frequencies to get the time shift.

That means either that a sweep generator will be needed or that one
has to do averaging over many pulses to get a reasonable S/N.
(Linrad calibrates amplitude responses like that - but it is not so easy.)

Just looking at the time shift between two (weak) pulses in a 192 kHz
passband will not give anywhere near the needed time resolution.
 

> N3UC here is looking at implementing a fixed-frequency receiver in Mercury that would dispense with the use of OZY altogether. This would take the digital data and pass it straight through to the on-board audio D/A converters. Two such Mercury boards would yield two pairs of synchronized IQ baseband signals at 96 k/s that would go into a 4 channel sound card in the PC. (The 12.288 MHz clock for the D/A is derived from the 122.88 above). Linrad would probably work with that version pretty much as-is (?) - some calibration would still be required, I imagine.

That should work - but with somewhat degraded dynamic range.

> (Of course, it would be nice to get away from the sound card interface eventually)
> 
> Changing the version of the firmware you are using in Mercury only takes a couple of minutes using the free Quartus programmer and the OZY card with its USB-blaster emulation ...  so you could, in effect, have several different "receivers" on your desk to be used for different purposes.

Well, with appropriate coding the FPGA should deliver "perfect"
data to the PC at a couple of selectable bandwidths. There should
not be any reason at all to program it differently for different
purposes. What may be needed is different analog frontends for
different purposes.....

> I am hopeful that this will work, especially since there seem to be several ways to do it.
What about the QS1R ? I think I have seen somewhere that it can
send 2MHz to the PC - or was it even 4 MHz(?)

Two such boards with appropriate synchronization cables.
One way or the other they could use a common PC interface.
I actually know nothing about the architecture, but it seems to
me that HPSDR is optimized for a previous generation SDRs
with its 192 kHz clock rate.

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