<div dir="ltr"><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><b>k2ew Warning:</b></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">NCSN staff have discovered that data values produced by k2ew from uncompressed-format Altus Serial Data Streams ('sds for 0') are bogus. To get valid data from k2ew, one must run the Altus Instrument with compressed Serial Data Stream format ('sds for 1').</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><b>Quick Summary:</b></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">k2ew with 'sds for 1' GOOD : Earthworm tracebuf2 and Altus .evt data values match</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">k2ew with 'sds for 0' BAD! : Earthworm tracebuf2 and Altus .evt data values *do not* match</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><b>Background:</b></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">For Altus SDS streaming data, there are two format choices on the K2:</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">  sds for 0  (uncompressed, 24bit samples)</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">  sds for 1  (compressed data samples)</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">k2ew was written to unpack either format, in different sections of code in k2pm_proc_streamdata() in k2pktman.c.</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">Since the dawn of k2ew acquisition, NCSN has always used compressed SDS ('sds for 1') to telemeter continuous data from our Altus Instruments. In a recent transition of some K2s from triggered .evt dialup telemetry to SDS-continuous-to-Networm, a handful of K2s were configured to use uncompressed SDS ('sds for 0').</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">Then during a M4.0 earthquake, a number of our close-in stations recorded full-scale +/- 2**23 spikes in the data output by k2ew. In addition, the spiky channels had extremely large bias, also near 2**23. The stations recording those spikes were those configured with 'uncompressed' data streams. Toggling the SDS format on the K2 to 'compressed' shifted the bias of continuous k2ew data to near-zero. </div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">Our K2s are also configured to trigger and record an .evt file to disk. We compared data values from .evt files with k2ew-output, and discovered that the data values matched only if the K2 was set to compressed format 'sds for 1'.  With uncompressed streams, both the data values and difference between data values did *not* match (ie, the problem is more than just a DC offset).</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">For a quick visual, I've attached two screenshots showing waveform data from two stations. The first image is .evt data. The second is k2ew-output from the same time interval, top 3 channels from a compressed data stream, bottom 3 from an uncompressed data stream.</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">  1739evt-1877evt-20150721.jpg  (wiggles from .evt files)</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">  1739sds1-1877sds0-20150721.jpg  (wiggles from k2ew)</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">Bottom line: there appears to be a bug in the part of k2ew's k2pm_proc_streamdata() that re-packages the 24bit uncompressed SDS data, or in how the K2 packages that uncompressed data stream.</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">The same behavior observed with data produced by:</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">k2ew from EW v7.7.1 on Windows</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">k2ew from EW v7.7   on Linux (Ubuntu)</div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">Given that there is a functional work-around, and that K2s are no longer supported, we are not highly motivated to track down the bug.<br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px"><b>Recommendation:</b></div><div style="color:rgb(0,0,0);font-size:12.8000001907349px">When using k2ew to acquire data, always set the Altus Instrument to *compressed* Serial Data Streams ('sds for 1')!</div></div>