[hpsdr] coherent dual mercury receivers

[Phil Harman]

Hi Joe,

That will work just fine since it will give a radar resolution of about
60m which is much higher than I need.

I've stress tested Metis and it will send at 996Mb/s so we have plenty of
bandwidth to play with in the future.

73 Phil...VK6APH




> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi Phil,
>
> I wrestled with this same situation earlier with HPSDR for the timing
> for pulsar data acquisition, as you may recall from some of our
> private communications a while back regarding my use of Atlas bus line
> A19 for "external sync".   Of course, A19 is now designated for use
> by Cyclops but the use of a different bus line could be implemented
> for a1 pps GPS sync signal very easily.
>
> The timing situation can be made better than your 1 in 62 sample
> uncertainty that arises from use of the C&C data by using, say, one of
> the bits in the 16-bit MIC data from Ozy/Magister/Metis to the PC
> instead.  Doing this would improve the real time uncertainty by a
> factor of 62 for you for starters.  No time stamping is necessary as
> long as the comm path between HPSDR and the PC doesn't drop data
> packets.
>
> As you know, the timing uncertainty is limited by the minimum time
> step between samples that are passed to the PC and that limitation is
> 1/192,000 sec at the moment if the highest sampling rate is selected;
> a bit more than 5 uSec between samples.  If time resolution better
> than that is required it seems to me that we would need to run at a
> higher final sampling rate than 192,000 samples/sec, i.e., with less
> total decimation.   Metis should allow for that, I believe, right?
>
> In any case, your Griffin project requirements are not quite the same
> as the issue that Georg brings up with regard to coherent operation of
> dual Mercury boards, I think.  Coherent operation is possible without
> time stamping in Georg's case, unless I've missed the mark completely,
> hihi!
>
> 73,  Joe K5SO
>
>
> On Mar 13, 2011, at 7:16 PM, Phil Harman wrote:
>
>> I do have a requirement to time stamp samples from Mercury.
>>
>> This is for the Griffin project:
>>
>> http://openhpsdr.org/wiki/index.php?title=GRIFFIN
>>
>> I'm developing a Chirp beacon that can be used as a beacon (with an
>> ERP
>> much higher than its actual power output) and a radar for measuring
>> real
>> time propagation on the HF bands and in particular 6m.
>>
>> The Chirp beacon linearly sweeps a carrier over 1kHz in one second
>> (as an
>> example). The start of the sweep is triggered by the 1PPS signal
>> from a
>> GPS receiver.
>>
>> On receive we can feed 1PPS from a GPS receiver to the Atlas bus and
>> use
>> this to time stamp the sample that coincides with the start of the
>> Chirp.
>>
>> If we time stamp at the output of the ADC then there is a high
>> probability
>> that the sample will be removed during decimation.
>>
>> If we time stamp after decimation and filtering then we can
>> currently only
>> indicate which USB frame contains the sample that coincides with the
>> 1PPS.
>> That assumes that we just set a bit in the C&C data. In which case we
>> could be out by a 62 samples.
>>
>> Anyone see an elegant solution?
>>
>> 73 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/
>
>



 1300151131.0