[evla-sw-discuss] EVLA WIDAR: Delay Model - format and content

[Sonja Vrcic]

Bruce Rowen wrote:

> Barry Clark wrote:
>
>> There's a lot of content here, and I suspect I'll have much more to say
>> when I've had time to do some work on these (I'm a bit tied up at the
>> moment in my other hat as scheduling officer).  However, a couple of 
>> remarks that occurred to me on a rather cursory reading.
>>
>> 1.  Number of derivatives.  We are working with two derivatives
>> at the moment.  This seems to work pretty well for VLA antennas tracking
>> translunar objects.  (And the code can be easily changed to handle 
>> NMA antennas.)  The cases that probably require more (VLBI and 
>> satelite tracking) have not had any serious design work done on them, 
>> so it's a little unclear how we want to handle them.  I strongly 
>> suspect that they also will turn out to have a number of derivatives 
>> set by the application, not something decided on the fly.  My 
>> preference would be that the number of derivatives be moved to a 
>> setup message, not sent with every delay model.
>> (Presuming that it's needed at all, that it's inconvenient to just use
>> whatever arrives.)
>>
>> 2.  Double.  Why the preference for a hex encoded double, instead of the
>> native 'double' form?  (Just in case somebody decided to read one of 
>> these
>> godawful things.)
>>  
>>
>>> Each coefficient is 64 bit (8 byte) floating-point number encoded as 
>>> hexBinary.
>>>     
>>
>>
>>   
>
>
> As a partial answer to #1 & #2, the coefficient encoding is nicely 
> compact and XML-able when all coefficients are encoded in
> hexBinary. As part of the XML, an attribute specifying the length 
> (number of coefficients) is handy.

After some discussion here in DRAO we came to conclusion that, at least 
for the testing, it would be useful to have readable format for the 
coefficients (derivatives).  Can we agree to use ASCII encoded double as 
defined by  the XML Schema Recommendations:
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#double

When the full system is deployed we can  switch to optimized format if 
we find that "verbose" models are generating to much traffic.
And,  in the spirit of "readability", I will keep the number of 
derivatives in the model (for now).

>
>> 3.  Timestamps.  We work internaly in a double precision MJD and 
>> fraction
>> system (LSB is about one microsecond).  Converting that to ISO 8601 
>> form is easy of course, but I rather suspect that you also will be 
>> working in some similar system internally, and it might save a few a 
>> little bother at both ends just to send that.
>>   
>
>
> Internally our time is in seconds since the "epoch" with a time 
> resolution of 10ms. These are internally carried in
> two unsigned integers (32 bits) as that works very nicely with the OS.

One of the decision from the face-to-face meeting was that  time in the 
XML messages is always UTC  displayed as defined by ISO 8601.


Sonja

>> 4.  Delays.  Who organizes the delay center?  Do I send numbers which 
>> might
>> be negative, or should I add something to them to make them always 
>> positive?
>> If so, what?
>>   
>
>
> TBD, but my feeling is the correlator is "dumb" in the sense it 
> doesn't care about signs or offsets from its delay buffer
> "center" (If the delay buffer center is somehow tied to the array 
> delay center). My only concern (the correlator speaking here) is that 
> the delay never exceeds the buffer range.
>
> -Bruce
>
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>>   
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/evla-sw-discuss/attachments/20061114/190788e4/attachment.html>