[hpsdr] Ozy/Mercury Protocol

[Bob Cowdery]

Phil, John

That explanation sounds totally logical. I don't claim to have tested 
very extensively and the machines I tried it on may be 'in-sync' but 
Acorn can output to both/either Mercury/Jack although I keep Jack at 
48KHz usually. In practice I don't hear any disturbance but I think 
thats just luck or I didn't listen long enough.

I may be wrong but I think John was trying to do something different, 
writing a Mercury back-end to Jack which may have a completely different 
set of issues. At the time I though that sounds a good way to go because 
there is only one API to deal with and net-jack would maintain sync when 
output to a different sound card. In principal Jack should get its 
timing from the Mercury input samples and there shouldn't be any timing 
aberration.

Bob

Phil Harman wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> 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
>
>
>
>
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: 
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/


 1251014563.0