3.4. Troubleshooting

If for some reason the figures quit updating, check the panels and make sure everything is green and active. If they are, DON’T ADJUST ANYTHING: the raw data are being logged, but the processing software hit a glitch for some reason. The ADCP Operator may start data acquisition again under a new cruise name (eg. adding a letter to the cruise name) in an attempt to re-initialize the processing, but if this still does not revive the figures after several hours, email us and we will try to help.

You might find the UHDAS serial communication tool tk_terminal.py to be helpful.

There is also a different section about ADCP failure modes which may help.

• 3.4.1. Troubleshooting Serial Feeds (beware ZMQ)
  • 3.4.1.1. Overview of UHDAS and ZMQ
  • 3.4.1.2. (1) UHDAS configuration: does it expect ZMQ or not?
  • 3.4.1.3. (2) Troubeshooting when ZMQ is not expected
  • 3.4.1.4. (3) Troubeshooting when zmq_publisher.py is expected
  • 3.4.1.5. (4) Clues in the daily email
  • 3.4.1.6. (5) Clues in the diagnostic directory (daily tarball)
  • 3.4.1.7. Appendix
• 3.4.2. Interpreting Accurate Heading NMEA messages
  • 3.4.2.1. Ashtech NMEA messages
  • 3.4.2.2. Seapath NMEA messages
  • 3.4.2.3. POSMV NMEA messages
  • 3.4.2.4. MAHRS messages
• 3.4.3. Troubleshooting Speedlog
  • 3.4.3.1. Components (what talks to whom)
  • 3.4.3.2. Normal behavior
  • 3.4.3.3. Troubleshooting DAS_speedlog.py
  • 3.4.3.4. Troubleshooting web_speedlog.py
• 3.4.4. NTP diagnostics
  • 3.4.4.1. Documentation on the “ntpq -p” command
  • 3.4.4.2. Example of a failed NTP peer server query
• 3.4.5. Hopelessly Confused message
• 3.4.6. Gui is Hung?
• 3.4.7. Diagnostic tools