NetDAS Crash Recovery

The two main techniques for remote software crash recovery are Watchdog Timers (WDT) and Internet power switches. Every system will eventually crash so crash recovery is mandatory. One low-cost approach is a remote AC power switch controlled via a web page. When the system stops working the operator logs onto the web page and selects the power-cycle button. This cycles power, clears the fault and restores normal operation. The disadvantage is that the system may be down for a period of time before the non-operational status is detected.

A better approach is a WDT circuit. The system under
normal operation produces a periodic pulse which "kicks the dog", keeping the system powered up. If the system crashes, the WD pulse fails, the "dog is not kicked" and the WD circuitry power-cycles the system. In the case of NetDAS, the WD interval is about three minutes, so the longest outage will be about three minutes. No operator intervention is necessary, resulting in practically non-stop operation.

What causes system crashes? In new systems, the cause is often software bugs. In the case of mature systems like NetDAS, the cause is static discharge which corrupts the USB stack. Once the USB stack is corrupted, a software reboot is not sufficient to restore the USB stack and only a full power-cycle can clear this error. (This is a well known USB issue and has nothing to do with NetDAS). So why not just cut USB power? Unfortunately, at this time we are not aware of any Linux utility that can cycle USB power.

Original NetDAS at 60% Discount

NetDAS News: 24-bit NetDAS $1795!

September 2018
Precision instrumentation based on open industry standards

DAQ Systems is pleased to offer the last two of the original NetDAS-1 Data Acquisition System (DAS) at a 60% discount. NetDAS-1 systems offer 4 channels at 24 bits resolution, GPS time-stamped data, CF flash memory storage, embedded Linux and digital I/O and auxiliary 10-bit analog channels.

NetDAS (25cm/10” X 20cm/8”X 18cm/7”)

NetDAS-1 Features

  • 4 channels @ 24-bit resolution

  • NetDAS Tools software bundle: multi-triggering, data concentration, multi-formatting, error logging, graphical viewer
  • Low latency, 30ms at 100 Hz sampling

  • MZ104 CPU
  • Military-Style (MS) connectors

  • NavSynch GPS

  • GPS NavSynch card, marine-grade Panasonic antenna (with base) and 15m coax

  • Ethernet port

  • Wide power input (10 – 16 VDC)

  • Linux 2.2 kernel


  • Internal 65 dB low cost tri-axial accelerometer

  • Pre-made custom analog cable

  • 4 GB Compact Flash memory card

  • Nonstop Watchdog Timer

  • Digital I/O

  • Auxiliary 10-bit analog channels

  • Expandable to 8 channels @ 24-bit resolution

About NetDAS

NetDAS is a multi-platform 24-bit DAS based on open industry standards such as Linux, TCP/IP, USB, Secure Digital (SD) and CF flash memory, client/server software, as well as Microsoft Windows. NetDAS finds application in seismic systems and other sensory applications. Embedded versions of NetDAS run Linux on solid-state low-power ARM CPU cards. NetDAS also runs under Ubuntu Linux or Windows on industrial 19-inch rack-mount servers. Introduced in 2003, NetDAS was the first seismic DAS to run embedded Linux. NetDAS comes bundled with NetDAS Tools software clients including triggering (amplitude, STA/LTA, and external logic level), formatting, real-time display and data concentration. For more information, or to place an order, please contact us at the email address or phone number above.

Java acceleration/tilt/vibration data logger

The DAQ24USB 24-bit analog-digital converter combined with the Accel-70 triaxial accelerometer makes a simple-to-use, low-cost, portable and multi-platform (Linux, Windows) Java data logger. The Accel-70 can log acceleration, tilt or vibration to an ASCII file using the bundled Java data recording software, DAQ-Sys-lab. The logger is supplied with or without an industrial fiberglass enclosure.
Pasted Graphic

How does NetDAS GPS timing work?

NetDAS “timing” refers to how NetDAS time stamps GRF packets. Note that time-stamping data is more involved than just reading the system clock and using that as the time stamp. This simplistic approach would not work for two reasons. Firstly, the system clock would not have the required resolution, down to the microsecond level and secondly, the analog-digital data stream is asynchronous to the ADC sampling.

GRFd does however use the system clock as a reference to the second. The GPS thread maintains the UTC delta relative to the system clock (along with the GPS lock state). The time stamp is the system time + the UTC delta. Note that this time only resolves the time to the UTC second. The PPS signal (to the ADC board) resolves the time to the microsecond level and these are used together to generate the time stamp.

Assuming that the GPS was locked at some point, the delta was known and the quality was 'good'. When the GPS loses lock, or (perhaps) stops outputting NMEA RMC sentences, the system is free running using the last GPS delta. This will cause time drift so the time quality will be 'poor'. When the GPS regains lock, the UTC delta begins to update again and results in a time tear in the data when the quality goes back to 'good'.

Add GPS timing to legacy (pre-GPS) systems!

Eliminate clock drift for systems with free-running clocks by adding a GPS-NS timing card. If your legacy system has serial and digital input ports and a timer, you can upgrade your timing to GPS with a software-only solution. Simply connect the GPS-NS NMEA output to your serial port and the GPS-NS PPS output to the digital input port which controls a counter. The counter's counts is the time offset from the second (X.00000) and NMEA RMC is the time of that second. With these two numbers the time is determined to the resolution of the counter. For example, if the counter is clocked at 1 MHz, then the time is accurate to one microsecond.