[hpsdr] Ozy/Mercury Protocol

[Phil Harman]

Subject: Re: [hpsdr] Ozy/Mercury Protocol


> This sounds familiar ;-)
>
> It is exactly the problem I see with interfacing HPSDR with Jack on Linux.
>
> -- John g0orx/n6lyt
>

Hi John,

I don't know Jack..... but I fear that its doomed not to work - here is my 
reasoning.

With Mercury we send data to the PC at 48/96/192ksps at very high accuracy 
(GPS locked if necessary). Using Windows the PC has not the slightest idea 
what sample rate we send it, neither does it care.  It only needs to be told 
what the sample rate is so the various DSP functions are calculated 
correctly.

All we ask of the PC is to process our samples and send them back to us so 
we can hear the results.  If the PC is not too busy with other tasks, and 
despite only being able to service our request infrequently, it does manage 
to 'keep the bucket' from either filling  up or emptying for most of us.

For a soundcard based SDR (e.g. SDR1000 or Softrock) then the clock in the 
sound card determines the rate that samples are fed to the PC code and also 
how fast they are played back.  Since these use the same clock then it does 
not need to be exactly 48kHz etc and any drift is common to both the ADC and 
DAC paths.   If you are using Jack and Linux then I would hope that Jack 
gets its clock from the sound card.

Now if we use Mercury and Jack under Linux and the Mercury sampling rate 
(48/96/192ksps) and the clock that somehow Jack gets from the PC are 
**exactly** the same then things are going to be sweet.

But, if the Jack clock is slightly faster or slower than the Mercury 
sampling rate then, (depending on the absolute frequency error) in 
seconds/minutes/hours or days we are either going to run out of samples for 
Jack to process or we are going to have to drop some since we have too many. 
This results in regular 'pops' in the data that I know you are familiar 
with.

We could use a large buffer on the input of Jack to delay the inevitable but 
this just adds additional latency which for CW is not going to be 
acceptable.

The only way I can see this working is to resample the data going to Jack to 
a lower rate so it never runs out of data.  This will reduce the bandwidth 
of the signals we can process to the new (lower) sampling rate.

As I said at the beginning...  I don't know Jack.... so it possible I'm 
doing it a huge injustice since it may be much smarter than my simple 
explanation.  If not..... then I can't see how it is ever going to work.

Perhaps we have  someone in the group who has a good understand of Jack and 
how it could be made to work?

73's Phil...VK6APH







 1250941628.0