General Comments:  This manuscript provides a thorough description of a failure mode of the remotely operated instruments related to the GPS week rollover that occurred in 2019.  A description of how the instruments failed is given as well as how the operators were able to bring the instruments back online.  At the end of the manuscript, the authors provide some general advice for remote instrument operation that is a direct result of their lessons learned from their whole experience.  In general, the manuscript is well organized and provides clear descriptions of what happened and how they were able to fix their problems.  I feel that this is useful information to be out and available to the scientific community, especially with regards to how to avoid such instrument failures in the future.  I feel that this manuscript is acceptable in its present form.

This manuscript contains a detailed account of the impact of GPS rollover on autonomous instrument platforms in Antarctica.

It provides a useful example of how modern data acquisition and communication systems can be rendered inoperative, and the

difficulties involved in restoring functionality.  Altogether, this is a useful contribution and should be published.  

I would suggest several very minor edits as indicated below.  Following these, I have some general notes and questions which 

might help clarify some aspects of the paper, but would accept the existing manuscript without requiring any substantive 

changes (other than the minor edits).

==== Minor edits ===

>>line 35 "therefore the GPS week number rollovers every 1024 weeks" 

...number rolls over every...

>>line 41 "Although the 2019 GPS rollover was warned of by Department of Homeland Security, the International Civil Aviation Organization and other relevant organizations beforehand,"

Despite advance warnings about the 2019 GPS rollover from the Department of Homeland Security, the International Civil Aviation Organization, and other relevant organizations ..."

>>line 42 "numerous" & "numerous" 

roughly how many?

>>line 58 "one for the equipment cargo and another for the field team to put in." 

...another for the $N$ member field team...

>>line 60 maybe give a table with # of flights per site per year?

>>line 69 "In the polar region, the available sunlight is limited throughout the year"  

...limited during Southern summer as well?

>>line 81 "Thus, we use this fault as an example to describe best practices for designing future systems against similar

faults, or to at least enable graceful fault recovery and restorative action if a fault occurs."

...designing against similar faults...  ==>> ...protection from similar faults...

>>line 85 "the remote instrument platform operated by the authors" 

...the AAL-PIP...

>>line 89 inconsistent past/present tense?

>>line 114 "Up to this point 0 of the 5 RUDICS enabled stations"   

...none of the five...

>>line 152 "land at PG0"  

Station coordinates for PG2 provided in Figure 1, so should probably give PG0 lat/lon here.

>>line 163 

Is PG0 the only one able to use Iridium?  Clarify.

>>line 188 "all but one of the systems have come out of hibernation and each system has undergone a software update. The AAL-PIP array

has thus far been restored to full operational capacity."  

N-1 of N is full capacity?

>>line 267 "John Bowman, and undergraduate student" 

...an undergraduate student...

>> Figure 2 What does the dotted line indicate?  

Couldn't this be reduced to a single figure just by adding 2nd line pointing down from Iridium to System clock.

=== General comments ===

Although there are some general lessons to be learned from this episode, the specific problems arose from a 

particular combination of hardware and software. It might be helpful to include some technical details ie.

>>line 164 "GPS module"  make/model/interface?

and possibly software versions eg. nptd

The complicated sequence of events is presented over several pages, so it might be useful

to provide some summary of what happens when.  Perhaps something simple like this: 

--------------------------------------

Typical state transition

0.0  system power on

0.0  SBC: start boot Linux

0.0  Iridium: boot local antenna, connect to SV

0.0  GPS: start boot local antenna

1.0  Linux: NTPD startup, initialize with SBC hardware clock time

2.0  GPS: acquire SVs, initial location & time estimate

3.0  GPS: RS232 available

4.0  Linux: initialize (software?) watchdog with SBC hardware clock time(?)

5.0  Linux: connect to GPS RS232, receive NMEA time, add source to NTPD

6.0  Linux: update NTPD with GPS time **possibly wrapped**

6.1  Linux: write NTPD time to SBC hardware clock

6.2  Linux: check software watchdog?

7.0  Iridium: read time from satellite

7.1  Iridium: RS232 available

7.2  Linux: connect to Iridium network

...and so on...

------------------------------------------

And centralize just a bit more detail about each of the elements in Figure 2 with their critical interactions eg.

    SBC hardware - read by Linux software; written to on shutdown?

    Linux software - NTPD(?) version

    GPS hardware (make/model/interface=NMEA?) - default read by ntpd

    Iridium satellite network - read?

    Iridium local terminal - no read; no write?

then use these labels (SBC, NTPD, GPS etc.) to refer to different time sources consistently throughout the manuscript.

For example, "system time"  and "system clock time" and "reported time"; are these all NTPD time?

Again- the manuscript is certainly acceptable as is, but could possibly benefit from some relatively minor modifications.