3.3. 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.

• 3.3.1. Troubleshooting Serial Feeds (beware ZMQ)
  • 3.3.1.1. Overview of UHDAS and ZMQ
  • 3.3.1.2. (1) UHDAS configuration: does it expect ZMQ or not?
  • 3.3.1.3. (2) Troubeshooting when ZMQ is not expected
  • 3.3.1.4. (3) Troubeshooting when zmq_publisher.py is expected
  • 3.3.1.5. (4) Clues in the daily email
  • 3.3.1.6. Appendix
• 3.3.2. Interpreting Accurate Heading NMEA messages
  • 3.3.2.1. Ashtech NMEA messages
  • 3.3.2.2. Seapath NMEA messages
  • 3.3.2.3. POSMV NMEA messages
  • 3.3.2.4. MAHRS messages
• 3.3.3. Troubleshooting Speedlog
  • 3.3.3.1. Components (what talks to whom)
  • 3.3.3.2. Normal behavior
  • 3.3.3.3. Troubleshooting DAS_speedlog.py
  • 3.3.3.4. Troubleshooting web_speedlog.py
• 3.3.4. NTP diagnostics
  • 3.3.4.1. Documentation on the “ntpq -p” command
  • 3.3.4.2. Example of a failed NTP peer server query
• 3.3.5. Hopelessly Confused message
• 3.3.6. Gui is Hung?
• 3.3.7. Diagnostic tools