[hpsdr] Ozy/Mercury Protocol

[Phil Harman]

Hi Alberto,

Thanks for the news regarding support for HPSDR with Winrad and I look
forward to testing it.

Dave is quite correct, given the bursty nature of PC processing we have
implemented large FIFOs in the FPGA code to account for this.

We have considered using other endpoints for control data but for two
reasons have not done so yet:

1. Having the dot/dash data in the same frame as the I & Q data is the
fastest way to detect CW key closures. Since we also don't go into the DSP
code to generate the CW tones when using KK full QSK works really well.

2. If it ain't broke - don't fix it!


Also good to hear that your have used WinUSB - that may be the way we have
to go so we can run KK under Vista and Windows 7.

73's Phil...VK6APH






> ***** High Performance Software Defined Radio Discussion List *****
>
> One factor that allows current systems to work is the use of
> buffering--both FIFO
> and ring buffers are used, so that processing can occur in fits and
> starts, but the
> final output stream is uninterrupted, with uniform time between samples.
>
> Dave
> wa8ywq
>
> Alberto I2PHD wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Thanks for the answers about V1.22
>>
>> While you all are considering changes in the Ozy/Mercury protocol, may
>> I express
>> a doubt I have ?
>>
>> Given the 512 bytes limitations of the FX2 FIFO, samples are sent in
>> blocks of 63
>> each sending. Reassembling them in blocks of 512, 1024, 2048, whatever
>> size
>> the processing code in the PC has decided to use, is trivial.
>>
>> But.... if you look at the timing, it is evident that the time
>> interval between the
>> instants a block of, e.g., 512 samples becomes ready is not a constant
>> value...
>> It has some inherent jitter... Granted, on average that time interval
>> is exactly
>> equal to 512 / sampfreq, but only on average...
>>
>> Doesn't this play havoc with data modes that require phase coherence ?
>> I have here a patched version of Winrad that works beautifully with
>> the HPSDR
>> hardware through the WinUSB interface, and voice and CW are not
>> minimally affected
>> by the jitter explained above, but I am wondering if this is true also
>> for data modes...
>>
>> IMHO the ideal would be to send 64 samples in each block, moving the
>> control bytes
>> elsewhere, maybe using end point 0.
>>
>> Am I completely wrong ?  Comments ?
>>
>> 73  Alberto  I2PHD
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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/
>
>
> _______________________________________________
> 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/
>
>



 1250558102.0