Turn on Sonar
1. Turn on the four Macintosh Mini Computers

2. Turn on Sonar Power Supplies and “OPG Doppler Sonar Interface Unit”
3. Start The SonarTDS command line program:

a. Double click on the “Start TDS” icon on the TDS computer’s desktop.
b. The ”Terminal” application will start and run the “SonarTDS” executable in a terminal shell

c. The TDS will initialize sensors and begin to run. Verify that all sensors are reporting reasonable values and no “Missing string xxx error” message is displayed on the TDS screen.
d. With the TDS running, either sonar can be started up. To do so:

4. Start The SonarAcq command line program and SonarDAS monitor application.
a. Double click on the “Start Sonar” icon on the 140 kHz and 50 kHz computer’s desktop. This activates an applescript that: starts the “SonarACQ” command line program and the “Sonar DAS” application. b. Select the data directory for “Sonar DAS”.

c. The ”Terminal” appliction will start and run the “SonarACQ” executable in a terminal shell.
d. The SonarAcq will initialize the system and begin to run. Verify that the sonar and all sensors are reporting reasonable values. Data are written to primary and secondary disk files with paths specified in the setup file (default.hdss_setup). These paths typically point to 2 external firewire drives mounted in the rear of the 50kHz rack. The filenames are auto-generated from the setup file with a date code appended. (see example below)

Drydock Transducers maintenance How to clean up HDSS transducers



Jan 18, 2011

Take care not to flex any of the cabling or connectors as they may have become brittle.

Also be careful when cleaning around the repaired 140 kHz transducers ( the black urethane sealant that Achintya applied in 2007). If those seals look good on inspection (i.e. none of the sealant has delaminated from the array face) no further sealing is necessary. If the sealant is only slightly lifted try and seal over the existing patch. if the sealant is badly delaminated try to remove the existing patch before the applying the sealant.

Before applying the sealant The area to be sealed should be 1) scraped,
2) cleaned with alcohol,
3) abraded with scotch-bright pads,

4) cleaned again with alcohol,
5) completely dry
6) masked with blue masking tape to avoid the active area of the array

If an existing patch needs sealing, it's ok to expand the sealed area a small amount if sealing over the existing patch. Do this by applying the blue masking tape 1/4" inside the existing patch area.

Are you referring to the HDSS data from the 140kHz, 50kHz, or both. The NB 150
will asynchronously crosstalk into the 140 kHz HDSS and reduce its performance somewhat. The normalized covariance, (selected as default by the HDSS process) should be used to reduce the effect of the crosstalk noise. The navigation signals, (pitch, roll, gyro heading, and gps sog) should be monitored for quality. It would be helpful if you could send some data samples for us to examine.


Jan 25, 2009


Hello, my name is Byron Kilbourne, I'm a UW graduate student currently at sea on board the R/V Revelle.

I have been tasked with interpreting the HDSS data for this cruise.

We will be releasing tracer on this cruise and hope to use the HDSS data in our efforts to track the tracer dispersion for sampling. The computer tech on board, Jon Meyer, has shared the .m files used to process the raw data and generate the plots on the ships website.

The problem we are having is that the data in the "sonaravg.mat" files seems very noisy. I have tried to make some comparison of the HDSS to the RDI nb150 data by using smoothing and averaging routines in matlab.

I have also used the functions from Jon, which filter based on signal to noise ratio and beam intensity. The results so far have been mixed. the filtering routines remove large sections of the data and replace it with NaN values.

I am concerned that I am missing something in the data processing. If needed, I would be happy to provide you with my work so far, and some of the HDSS and ADCP data, or anything else that might help.

Thanks, -Byron

On our current cruise we have had a request for pitch-heave-roll (gyro) measurements for our scientists at 1-second intervals. We are normally not recording this data at that timeframe, and we're wondering if the HDSS system might have this information.

Also just to let you know the HDSS system has been showing a little instability this cruise (TDS server route errors, HDSS 50 error). However restarts and troubleshooting via your manual have cleared up the problems so far.

Thanks Brent


April 9, 2010

Hi Brent,

The Phins VRU data is recorded along with the HDSS raw and processed data files. The 50kHz unit records these data at at 20 Hz. The 140kHz records these at 20Hz in one second bursts every other second. The SonarDas application "Sonar TDS" window refers to these channels as TSS pitch, TSS roll, and TSS Heave. These channels could be retrieved out of the .hdssraw or .hdsscov files using a matlab script. A copy of these files should be available on the HDSS server disk

The matlab compatible mat files that are generated on the hdss server contain averaged VRU pitch roll and heave data but we'll need find out how much smoothing is applied before they are saved in the mat files.


Feb 10, 2011

Variable definitions

'TDS.TSS.pitch' 'TDS.TSS.roll' 'TDS.TSS.heave'


When you use HDSS process (*.m files) to analyze covariance file, you will have a main variable “sonar”, it contents all information as following:

>> sonar

sonar =

filename: {16x1 cell} dasinfo: [1x1 struct]
TDS: [1x1 struct] datenum: [1x360 double] cov0: [92x360x4 double] int0: [92x360x4 double] cov: [92x360x4 double] int: [92x360x4 double] covs0: [92x360x4 double] covs: [92x360x4 double] Navg: 120

sn: [92x360 double]
nbins: 92
ranges: [92x1 double] depths: [92x1 double] beamvel: [92x360x4 double] u: [92x360 double]

w: [92x360 double] u_z: [92x360 double] nav: [1x360 double] U: [92x360 double] U_z: [92x360 double] yday: [1x360 double] lat: [1x360 double] lon: [1x360 double]

* sonar.filename: the list of the data file being processed. Since one ".mat" file was processed one day, so the list would be all the files in that day.

For example:
>> sonar.filename

ans =

'50k_RR0908_09_08_13_134558.hdss_cov' '50k_RR0908_09_08_13_135110.hdss_cov' '50k_RR0908_09_08_13_141014.hdss_cov' '50k_RR0908_09_08_13_145249.hdss_cov' '50k_RR0908_09_08_13_153509.hdss_cov' '50k_RR0908_09_08_13_161729.hdss_cov' '50k_RR0908_09_08_13_165949.hdss_cov' '50k_RR0908_09_08_13_174209.hdss_cov' '50k_RR0908_09_08_13_182429.hdss_cov' '50k_RR0908_09_08_13_190649.hdss_cov' '50k_RR0908_09_08_13_194909.hdss_cov' '50k_RR0908_09_08_13_203129.hdss_cov' '50k_RR0908_09_08_13_211349.hdss_cov' '50k_RR0908_09_08_13_215609.hdss_cov' '50k_RR0908_09_08_13_223829.hdss_cov' '50k_RR0908_09_08_13_232049.hdss_cov'

* sonar.datenum: number of days from the 1/1/0000 to the date of deployment * sonar.cov0: covariance (complex), non filter
* sonar.int0: intensity, non filter
* sonar.cov: covariance (complex), filter

* intensity, filter
* sonar.covs0: covariance (complex) with VRU correction (fin), non filter
* sonar.covs: covariance (complex) with VRU correction (fin), filter
* sonar.Navg: 120 (average 4 mins) - look in "runScripts.m" file
* signal to noise ratio (s/n)
* sonar.nbins: 92 (number bin)
* sonar.ranges: along the beam
* sonar.depths: vertical beam
* sonar.beamvel: inward doppler velocity (along beam)
* sonar.u: velocity with the ship (m/s)
* sonar.w: vertical velocity
* sonar.u_z: derivative of the u, shear, du/dz (z: depth)
* sonar.nav:
* sonar.U: velocity with the earth frame ---> imagesc(sonar.datenum,sonar.depths,real(sonar.U))
* sonar.U_z: derivative of the U, shear, dU/dz (z: depth)
* sonar.yday: year day, note: year day = 1 at Jan 1 of the deployment year, while the time_mark is 0 * latitude
* sonar.lon: longtitude

* >> sonar.dasinfo: hardware setup

data_Type_System: [32x1 char] dasrec_size: 5592
Record: [1x1 struct]
SonarCom: [1x1 struct]

TDS: [1x1 struct]
Tx: [1x1 struct]
Hardware: [1x1 struct] SonarProcessingStruct_size: 1172 samples_to_process: 24387

The Mat file data variables in the sonar structure are named:

time_lag: 24
range_average: 264
n_bins: 92
bin_size_meters: 3.1258e+04 filter_type: 1
cov_proc_type: 1
beam: [1x4 struct] combine_segments: 1 data_format_str: [1024x1 char]

* sonar.dasinfo.data_Type_System:
Type of the acquisition system: little endian or big endian, example, these data is : "LITTLE_ENDIAN"

* sonar.dasinfo.dasrec_size: 5592
The size of the dasrec structure, this structure is the same structure daslayout in "hdssDefineCStruct.m"
(note for me: should change comment: not header size)

* sonar.dasinfo.Record: the structure "Record" in the daslayout structure (see the file "hdssDefineCStruct.m")
For example:
>> sonar.dasinfo.Record

ans =

SonarRecordStruct_size: 1324 run_name: [256x1 char] warnmin: 0
max_FileSize: 0.0047 rec_sens: 0

rec_janus: 0
rec_slant: 0
rec_raw: 0
data1_flag: 1
data2_flag: 1 path_copy1: [256x1 char] path_copy2: [256x1 char] cov1_flag: 1

cov2_flag: 1
cov1_path: [256x1 char] cov2_path: [256x1 char]

* sonar.dasinfo.Record.run_name: the name of the leg/cruise which is input from the user (scientist/engineer) before running the system.

For example:
>> sonar.dasinfo.Record.run_name ans = 50k_RR0908

sonar.dasinfo.Record.max_Filesize: the size of the data file, 47MB size sonar.dasinfo.Record.data1_flag: turn on the flag save raw data in copy1 sonar.dasinfo.Record.data2_flag: turn on the flag save raw data in copy2 sonar.dasinfo.Record. path_copy1: the path of the copy 1 data sonar.dasinfo.Record. path_copy2: the path of the copy 2 data sonar.dasinfo.Record.cov1_flag: turn on the flag save cove data in copy1 sonar.dasinfo.Record.cov2_flag: turn on the flag save cove data in copy2

* >> sonar.dasinfo.SonarCom ans =

sonar_com_size: 1392 das_serialNum: 20080 time: 0
rec_header_size: 128 reclength: 780512
n_seq: 1
sample_period: 80 seq_length: 24900 samples_to_acquire: 24387 n_ensmb: 0

xmitfreq: 48000
mixfreq: 48000
n_modes: 1
n_aux: 0
run_notes: [1024x1 char] n_xducers: 8
n_data_channels: 16 databuffsize: 1024 start_DateTime: 19403157 sodad_version_str: [256x1 char] UserLevel: 0

PowerLevel: 0 SonarType: [32x1 char]

* das_serialNum: serial number of DAS version * n_seq: number of sequences per ensemble
* sample_period: sample periods ( milliseconds) * seq_length: sequence length (samples)

* sample_to_acquire: number of samples to record
* xmitfreq: 48000, transmit fréquence (Hz)
* mixfreq: 48000, mixer frequency (Hz)
* n_xducers: 8, number of transducer, look at the setup file
* n_data_channels: 16, number of 16 bit data channels from analog to digital, usually 2 per receiver * start_DateTime: 19403157, run start time

* SonarType: the type of the Sonar, either 50kHz or 140kHz * >> sonar.dasinfo.TDS

ans =

SonarTDS_SetupStruct_size: 36 TDS_on: 1
UDPportNum: 5252
sync_flag: 0

n_time_marks: 40 TDSrecs: 38 cir_buff_size: 80 hold_off: 4 sync_mode: 0

* TDS_on: turn on TDS (Time Data Server)
* UDPportNum: the UDP port to get TDS data
* n_time_marks: 40, number of time marks per sequence
* TDSrecs: 38, number of 50ms TDS records appended to each data record * hold_off = 4, number of milliseconds to hold off at the end of the sequence

*>> sonar.dasinfo.Tx ans =

sonar_tx_size: 88 relay_delay: 32 autorelay: 0 post_xmt_gate_delay: 32 start_time: 32

bit_width: 6
code: [32x1 char] code_reps: 23 tone_reps: 1 trep_period: 1000 n_bits: 4 bit_smoothing_fact: 993 dac_slct: 0
gate_slct: 255 MaxPower: 285

* start_time: 32, transmit start time
* bit_witdth: 6, transmit bit width
* code: 1141, transmit code string
* code_reps: 23, number of subcode repeats * tone_reps: 1, transmit repeats

* trep_period: 1000, transmit repeat period * n_bits: 4, code length

*>> sonar.dasinfo.Hardware ans =

SonarHardwareStruct_size: 1544 data_link_flag: 1
controller_flag: 1 Data_link_setup_struct_size: 52 Data_link: [1x1 struct] Controller_setup_struct_size: 1480 Controller: [1x1 struct]

* sonar.dasinfo.samples_to_process: 24387, number of AD samples to process * sonar.dasinfo.time_lag: 24, time lag (code bits)
* sonar.dasinfo.range_average: 264, number of AD samples per range bin
* sonar.dasinfo.n_bins: 92, number of range bins

* sonar.dasinfo.bin_size_meters: 3.1258e+04, range in size (meter)
* sonar.dasinfo.filter_type: 1, selector for which filter to use 0 for filter, 1 for Cheby, etc... * sonar.dasinfo.cov_proc_type: 1, selector for covariance process type

*>> sonar.TDS: all sensors of TDS ans =

system_type: [1x360 double] packet_ID: [1x360 double] time_mark: [1x360 double] time_host: [1x360 double] time_mark_year: [1x360 double] Gyro: [1x1 struct]

ADAM: [1x1 struct] TSS: [1x1 struct] pcode: [1x1 struct] ADU2: [1x1 struct]

* system_type, 0: little endian, 1: big endian
* time_mark: TDS time is computed by GPS time in second from the beginning of deployment year * 20 (20 ticks per second)
* time_host: TDS time is the hundred of the second in local time.
* time_mark_year: the deployment year

Note: sonar.datenum // number of days
= datenum(sonar.TDS.time_mark_year(1,:),1,1) + sonar.TDS.time_mark(1,:)/20/86400 // 2010 M D // number of days base on GPSTime
example: 1/5/2010 = 5


Feb 10, 2011




Power supplies are good but sonar controller fails to load after SonarACQ started:

1) Quit sonar application and start the Zterm application.
2) Set baud rate to 19200 by clicking baud button on lower left of control window.
3) Set channel to KaeySerial1. (this corresponds to the #1 port of the Keyspan USB dongle)
4) Type a few returns. Each should be accompanied by ‘:’ prompt.
5) If you get a prompt type lower case L. This should give you a list of setup parameters.
6) If you receive no prompt the controller, the USB/serial dongle, or serial cabling is



Feb 13, 2011

Feb 13, 2011

malfunctioning. Repeat serial and USB connectors. Restart and repeat the test. Time Data Server (TDS) :

1) To stop the TDS type <q> and press <enter> key in the TDS Terminal. (if the computer freezes press and hold the power button on the rear-right side of the mac mini)
2) Re-start the Computer.

3) Start the TDS program by double click the “Start TDS” icon on the desktop. Acquisition should start and a terminal output should indicate sensors being acquired
4) Start the Sonar program by double clicking the “Start Sonar” icon on the desktop 5) From the “SonarDAS” application select the “Choose Directory” button on the lower left “Sonar Playback” window. Navigate to the current data directory and click the “Open” button. The screen should now be updating (realtime mode is selected by default”

Checks before starting 50kHz and 140kHz Revelle Sonar applications:

1) Check that all the cables are firmly connected.
2) Check configuration:
a) Open “default.hdss_setup”
3) Start the sonar by pressing the “Start Sonar” button


Hi Mike,

The replacement Sperry gyro's digital output hasn't been working as expected, so it's been removed from the mix.

Gyro-feed wise, we now have the PHINS (output: Simrad EM3000 [19200] or Gyro [115200]), and the Hydrins (Simrad EM3000 [19200], Gyro [9600], PHINS Standard/PIXSE [19200]).

What sort of adjustments should be made to the HDSS?

Thanks, Mary

Hi Mike,

Here's an example of the Hydrins Gyro feed: $HEHDT,159.726,T*21 $HEHDT,159.651,T*20 $HEHDT,159.582,T*2D $HEHDT,159.520,T*25 $HEHDT,159.464,T*24 $HEHDT,159.412,T*25 $HEHDT,159.367,T*20 $HEHDT,159.326,T*25 $HEHDT,159.292,T*2B $HEHDT,159.261,T*27

The PHINS (Simrad format) is currently connected to the HDSS, but the TDS is complaining about missing gyro data. Is that because of the missing backup?

Thanks, Mary

Hey Mike --
attached is the manufacturer's docs describing all the supported output formats.

We've currently got the simrad em (@ 19200), 'phins standard' (1hz @ 19200), and 'nmea gyro' (10hz @ 9600) outputs published in the computer lab. If you have a need one of the other output formats we _might_ be able to accommodate -- there are currently additional output ports free on the hydrins ... Part5_Library_MU-PHINSIII-007-B-all


Hey guys,

Sorry to bother you with this. We've replaced all the components of the met system over the course of this drydock period -- and have misplaced the destination for a surface sound speed output that was configured on the old system. Does the hdss consume any data feed from the tsg in the bow dome near the seawater intake pump? I don't see any indication that it does on the hdss time-data-server, but just want to make before I chalk this up to a documentation error.

Many thanks, Ben

Hi Mike,
The 140k has been stopping with this error (see attached).

The sonar stops, and restarting SonarAcq and resetting the controller gets it to run again; this has been done twice in the past day or so.

Would you happen to have any troubleshooting advice?

Thanks, Mary

Hi Mary,

The PHINS (Simrad 19200 format) is out main heading signal now. The Sperry NMEA-$HEDT input was used as a backup only so the system will work fine without it. No adjustments are necessary.

Is the Hydrins Gyro [9600] output NMEA-$HEDT format? If so we might be able to use it as a backup feed to replace the Sperry feed.

Can you send us a pdf of the Hydrins datasheet? Thanks.


Feb 13, 2011

Feb 25, 2011

Feb 26, 2011

Hi Ben,

The current version of the HDSS does not take a thermosalinograph feed.
to record the feed it can be used for post processing if the recorded files are included along with the HDSS covariance data.

Thanks -Mike

Hi Mary,

The error indicates a timeout on the ethernet data link from the sonar interface unit. This can occur if the controller or interface unit hangs or if the SonarAcq program gets delayed in handling the ethernet packets coming in from the sonar interface unit. A delay can occur If the data disk drive attached to the system is problematic. Has the 140kHz been working for long periods of time this leg before the errors appeared?

1) When the unit quits is the amp meter on the power supply in the bottom of the 140k rack slightly twitching every 2 seconds (indicating pings are still being transmitted)? The needle only slightly twitches on the 140 so careful inspection is necessary. If it is stopped, the fault might be in the sonar controller or interface.

2) A cron job monitors the external data RAID drive on the 140k system and periodically wipes the earliest raw data when the disk starts to get full. Can you examine the external data RAID drive on the 140k system? How much space is left on the disk?


If you have the ability



Feb 26, 2011

Hi Mike,
Ben is currently also troubleshooting.

The last time the error occurred, the needle in the amp meter for the 140k had apparently stopped twitching.

This is what the hdss-140khz shows:

Filesystem 512-blocks Used Available Capacity Mounted on /dev/disk0s2 116622768 52439480 63671288 46% /
devfs 222 222 0 100% /dev
/dev/disk0s3 116884912 28630728 88254184 25%


Hi Mary,
87% on /Volumes/HDSS_140k_Data_Copy should be fine for operation of the sonar. Oliver

Feb 27, 2011

Does that look too full? Or should I be looking elsewhere? The 140 hadn't worked long before this started happening.

Thanks, Mary

Hi Oliver,

map-hosts 0
map auto_home
/dev/disk1s2 1952753344 1695542528 257210816 87%

0 /Volumes/HDSS_140k_Data_Copy1

0 0 100% /net
0 0 100% /home


Hi Mary, Unfortunately, the problem is persisting. The 140 will run for a few hours before

exiting with this error. Mary

A year ago 27 Jan 2010 we addressed a similar problem.

After the TDS feeds were checked and brought back up you checked the power and data connections in the NEMA box in the sonar void below the exercise room. I sent you a the method we used last year to address this problem:

The problem you described might be caused by an intermittent DC power connection in the electronics box below the exercise room. You can re-seat the connectors in the box as a possible solution. You should bring a large flat blade screwdriver, a flashlight, and a 2 foot length of cord (to secure the cabinet door open).

To reseat the connectors:
1) Switch the 140kHz power supply in the lab off

2) Loosen the 4 latches as shown in the red circles (see attached photo #1A) and swing the door open. secure the door open by tying the door latch to the ship frame.

3) For added safety the power to the box can be switched off system power breaker in the cabinet (yellow circle labeled 'A' in the attached photo #2)as well as the switch in the computer lab .

4) Reseat the green power connectors on the controller (yellow circles labeled 1 and 2 in photo #2) by unplugging and re-plugging the connectors.

5) Reseat the fiber optic connectors by gently wiggling the connector ends on the yellow and brown fiber optic cables (yellow circle labeled 3 in the photo #2)

6) Switch the system power breaker back on and close and latch the door.

#1A,B 140 kHz electronics box exterior

Photo #2 interior of 140kHz electronics box


Hi Bud,
I have a few questions that will help diagnose the problem.

1) When the system stops, is the amp meter on the 140 kHz power supply twitching even minutely?

2) After the spurious halting does the system restart normally?

3) Is the error message displayed on the SonarAcq display always the same as the one Mary sent when the problem first appeared?

If the controller seems to be responding the problem might be with the VRU signals. Spurious data might be choking the processing and delaying the i/o enough to get the -35 resource unavailable error.

We should check the TDS data fed to the sonars to make sure that the VRU and GPS,signals are not somehow getting corrupted.

5) Can you check the values of the PHINS pitch, roll, and heading that are displayed in the 140khz TDS display?

(The PHINS VRU is displayed under the name TSS pitch, TSS roll, and TSS heading on the 140kHz sonar tds display)

Thanks -Mike

Hi Bud,

It's significant that the controller was still pinging when SonarDacq stopped. The problem might have to do with the Sonar Interface. You should power down the Sonar Interface for a minute and



Mar 3, 2011

I've been testing the 140K and it continues to halt after about 12 to 18 hours. I've done the plug re-seating several times now.

Any suggestions other than to just watch it and restart it when it halts? Bud


Mar 3, 2011

Oops, lost my first reply: But:


Mar 6, 2011

Mar 6, 2011

2010 2009 2008 2007

1)Whenitstopstheampmeterisstill.Notwitchingatall.Iknowhowslightthe twitching is an there is none.

2) When it stops I kill all the windows and and SonarDas and it restarts. However I've always been doing a reset
before I try to restart by double clicking the icon.

3) I've not been checking the error message carefully but merely assume it was the same. I will capture it next time.

5) The roll, pitch and heading look pretty normal. Heading displayed is 295.9xx, pitch about 0.15x, roll about 0.45x, heave holding right a 000.

It appears the 140K halted after only a few hours this time. But the controller failed to stop. The amp meter needle continues to flick as it
does when it is operating. So I went to the Zterm method to manually halt it. And I find that Zterm no longer starts but gives a message
that it requires that "Rosetta" be installed. I then tried to start Zterm on the 50K machine and got the same error.

Without Zterm how do you suggest I stop the sonar controller?

I realize it is the middle of the night back there and you probably won't see this until tomorrow. So when we get out of the harbor I will
start the 50K and leave the 140K until I hear back from you.


Just an update on the 140: I did quite a bit of contact cleaning and reseating while docked but the 140K continued to halt from time to time. Then on the way out
it hung with the sonar still pinging. I followed you guidance in getting it cleared and restarting. I restarted it about the time we were allowed to start taking data.
It now has run quite well with no problems since. So don't know if being in the harbor had anything to do with it or not. I'd sure be interested to hear your opinion.


First question: ship was docked most of the time of these tests. This was started by Mary Huey as soon as the ship entered the harbor. So I started trying to continue from what she was telling me. But it did happen on the way out also.

To my knowledge the 140K computer and it's RAID drive did not get powered down and restarted at any time between halts.

Just FYI: it has been going now since late Friday without a problem. Bud



We no longer use zterm on the macs as they need rosetta to be installed. We're using coolterm and goSerial for terminal emulation now. I think coolterm is installed. Attached is my prferred emulator, "goSerial" This info will be included in the new manual.

This is a handy emulator as it can handle several open ports at the same time.

We're also not using the keyspan USB to adapters for the controllers or the TDS anymore. For the controllers We're using a single port adaptor from SerialGear. So the name for the new port for the 140kHz controller serial port is:

with 19200 baud 8 data bits with no handshaking. -Mike

Hi Bud,

Thanks for the update.
clear reason why the unit would behave differently in the harbor. Was the ship docked in the harbor during the entire time it was spuriously halting?

Had the 140kHz computer system or it's RAID drive been powered down and restarted at any time between spurious halts?

Thanks for the debugging effort. -Mike

Hi Bud,

Thanks for the info. That it sometimes is still pinging when it spuriously halts is a sign that the controller is working and the problem may be elsewhere in the data path.
Has the network configuration for the HDSS ethernet subnet been changed in any way?



I'll try and track the error on our similar system in the lab.

I can't think of a


I will put the .html file here ...