RA and DEC values must match RA_STR and DEC_STR values

[david-macmahon]

In the 2020-5-21 test session, the values for RA (floating point degrees) and RA_STR (sexagesimal hours in colon delimited string form) were not equivalent. Likewise, the values for DEC (floating point degrees) and DEC_STR (sexagesimal degrees in colon delimited form) were not equivalent.

[david-macmahon]

This also happened during 2020-08-13 test session (at least for "test5"):

$ rawhd /datax2/20200813/test5/Unknown/GUPPI/guppi_59074_54336_004444_J1939-6342_0001.0000.raw '^RA' 
RA      =      295.33258333333333
RA_STR  = '8:26:01.91'

[david-macmahon]

Looking back at historical data, it seems like RA_STR and DEC_STR fell of the wagon somewhere around 20200507. Since then these have been stuck at one of these two coordinates:

RA_STR = '8:26:02.10' DEC_STR = '-47:14:54.9'
RA_STR = '8:26:02.10' DEC_STR = '-50:14:54.9'

Weird!

[danielczech]

I think the reason for this is because the target sensor value was only being published, when it should also have been written to Redis. This is a result of switching from the "antenna consensus" approach to the single "target" approach. Fixed in 1e7c509 (working on the dev system; to be tested during a commensal observation).

[danielczech]

The sexagesimal form RA_STR and DEC_STR were obtained from the target sensor. When the target sensor is not correctly paired with a track message (see explanation in #18), these values are incorrect. RA and DEC in degree form are derived from separate, dedicated sensors that are continuously updated. Since scanning observations are expected in future (in which RA and Dec change smoothly), it would be better not to use the target sensor for RA_STR and DEC_STR and instead calculate them from RA and DEC.

[danielczech]

As of 1ee0a1d, now calculating RA_STR and DEC_STR from RA and DEC as mentioned above.