All,
 
I processed the short orbit 539 SSR dump and it looks like the ISOC recognized the full block range.  There are quite a few missing blocks; we'll do a re-dump.
 
I looked at the orbit 538 dump in more detail:
 
1. The ISOC grabs the timestamp in two ways based on ApID value.   The "scb" values - split into year, doy, hour, minute and second are the ones with the funky values.   The "plfw" timestamps are a single integer MET time and look OK.
 
2.  The bad dates - the ones that get corrected to 2064 - are seen at the beginning of the processing, change to the reasonable 2021 corrected date, then change back to the 2064 date for the remainder of the processing.
 
2. The bad date does increment - there are several day numbers.
 
3. The hour/minute/second values for the bad dates are also changing.  However there may be an offset from the correct values.   Usually adjacent "scb"  and "plfw" dates have timestamps with little difference in time.   Adjacent values are separated by several hours when the scb" value is bad.   However, the bad date may be affecting placement in the telemetry file.
 
Ken
On 08/27/2021 2:18 PM NIgel Angold <nangold@princeton.edu> wrote:
 
 
Attendees:
Nigel Angold, Reese Wynn, Carol Weaver, Jim Conway, Ryan Tyler, Ken Fairchild, Bret Hautamaki, Tim Perry, Sheral Wesley, Eric Chubin, Mark Tapley, Walker Cross

16:00-17:00 UTC HI01 contact activities:

Ryan: looks like there's been a jump in the timestamp that MAESTRO can't process.
Jim: Let's look at raw data.
Tim: we are unable to archive data after DOY 236.

Since the spacecraft is functioning nominally, no need for any immediate action. No need to load orbit 540 ATS just yet.

Science: Lo and Hi teams both report nominal-looking orbit 538 data.

Future planning:






Please restrict discussions on this email list to non-ITAR sensitive topics.
______________________________________________
Isocops mailing list
Isocops@lists.sr.unh.edu
https://lists.sr.unh.edu/mailman/listinfo/isocops