International Federation of Digital Seismograph Networks

Thread: Next generation miniSEED - 2016-3-30 straw man change proposal 6 - Change CRC to represent encoded rather than decoded data

None
Started: Aug. 11, 2016, 12:46 p.m.
Last activity: Aug. 23, 2016, 1:09 p.m.

Hi all,

Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached: Change CRC to represent encoded rather than decoded data.

Please use this thread to provide your feedback on this proposal by Wednesday August 24th.

thanks,
Chad




  • Hi

    I am inclined to agree with this. Back in the old days, the first
    sample/last sample were part of the record, with I guess the idea that
    if there was a transmission error you could both check that the
    decompression was done correctly, as well as potentially decompress
    backwards in time to the point of error. In practice I think that
    errors in the compression are near zero and so this amounts to just a
    check on bit errors in transmission. In this case, there is no benefit
    to having the CRC on the decompressed data, and quite a lot of speed
    improvement to having it on the encoded.

    However, I question whether this is even needed as part of the file
    format. It adds complexity to data loggers, perhaps small, but not
    zero. It makes sense as part of a transmission protocol or a file
    system, but that is a separate issue. Perhaps it is cheap insurance,
    but unless it is actively used by receiving software, it doesn't
    really help. Perhaps a question to be asked is does anyone use the
    existing last sample check and has anyone actually encountered real
    miniseed packets with errors? If this type of error doesn't actually
    happen, then perhaps we should not add in a fix for it.

    I am not totally opposed to having a CRC in the format, but feel that
    its benefits vs. costs should be considered. There is value in
    simplicity.

    thanks
    Philip

    On Thu, Aug 11, 2016 at 3:48 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

    Hi all,

    Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached:
    Change CRC to represent encoded rather than decoded data.

    Please use this thread to provide your feedback on this proposal by
    Wednesday August 24th.

    thanks,
    Chad





    ----------------------
    Posted to multiple topics:
    FDSN Working Group II
    (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
    FDSN Working Group III
    (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

    Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/




    • On 08/11/2016 02:29 PM, Philip Crotwell wrote:
      Hi

      I am inclined to agree with this. Back in the old days, the first
      sample/last sample were part of the record, with I guess the idea that
      if there was a transmission error you could both check that the
      decompression was done correctly, as well as potentially decompress
      backwards in time to the point of error. In practice I think that
      errors in the compression are near zero and so this amounts to just a
      check on bit errors in transmission. In this case, there is no benefit
      to having the CRC on the decompressed data, and quite a lot of speed
      improvement to having it on the encoded.

      However, I question whether this is even needed as part of the file
      format. It adds complexity to data loggers, perhaps small, but not
      zero. It makes sense as part of a transmission protocol or a file
      system, but that is a separate issue. Perhaps it is cheap insurance,
      but unless it is actively used by receiving software, it doesn't
      really help. Perhaps a question to be asked is does anyone use the
      existing last sample check and has anyone actually encountered real
      miniseed packets with errors? If this type of error doesn't actually
      happen, then perhaps we should not add in a fix for it.

      Yes, I have software that uses the last sample check,
      Yes, I often use it,
      Yes, I have found errors.

      I use the "last sample vs last decompressed sample" check
      often, and I do find that it oaccasionally detects bad packets.
      Most of the time it is due to a datalogger crash creating a bad packet
      on disk. However, with other data loggers using SeedLink across
      TCP radios, I have seen MiniSEED packet corruption, both in
      the data AND in the headers. So TCP does not flag all multi-bit errors.

      - Doug N

      I am not totally opposed to having a CRC in the format, but feel that
      its benefits vs. costs should be considered. There is value in
      simplicity.

      thanks
      Philip

      On Thu, Aug 11, 2016 at 3:48 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

      Hi all,

      Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached:
      Change CRC to represent encoded rather than decoded data.

      Please use this thread to provide your feedback on this proposal by
      Wednesday August 24th.

      thanks,
      Chad





      ----------------------
      Posted to multiple topics:
      FDSN Working Group II
      (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
      FDSN Working Group III
      (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

      Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
      Update subscription preferences at http://www.fdsn.org/account/profile/


      ----------------------
      Posted to multiple topics:
      FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
      FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

      Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
      Update subscription preferences at http://www.fdsn.org/account/profile/


      --
      ------------------------------------------------------------------------
      Doug Neuhauser University of California, Berkeley
      doug<at>seismo.berkeley.edu Berkeley Seismological Laboratory
      Office: 510-642-0931 221 McCone Hall # 4760
      Fax: 510-643-5811 Berkeley, CA 94720-4760
      Remote: 530-752-5615 (Wed,Fri)

      • OK, then I am in favor of including the CRC.

        However, in thinking more about this, I do not think it makes any
        sense to protect only the data with the CRC. After all an error in the
        headers could be more damaging than one in the data. So, perhaps it is
        better to have the CRC field be over the entire record, with the CRC
        bytes assumed to be zero for purposes of the calculation.

        Philip

        On Thu, Aug 11, 2016 at 7:19 PM, Doug Neuhauser
        <doug<at>seismo.berkeley.edu> wrote:


        On 08/11/2016 02:29 PM, Philip Crotwell wrote:
        Hi

        I am inclined to agree with this. Back in the old days, the first
        sample/last sample were part of the record, with I guess the idea that
        if there was a transmission error you could both check that the
        decompression was done correctly, as well as potentially decompress
        backwards in time to the point of error. In practice I think that
        errors in the compression are near zero and so this amounts to just a
        check on bit errors in transmission. In this case, there is no benefit
        to having the CRC on the decompressed data, and quite a lot of speed
        improvement to having it on the encoded.

        However, I question whether this is even needed as part of the file
        format. It adds complexity to data loggers, perhaps small, but not
        zero. It makes sense as part of a transmission protocol or a file
        system, but that is a separate issue. Perhaps it is cheap insurance,
        but unless it is actively used by receiving software, it doesn't
        really help. Perhaps a question to be asked is does anyone use the
        existing last sample check and has anyone actually encountered real
        miniseed packets with errors? If this type of error doesn't actually
        happen, then perhaps we should not add in a fix for it.

        Yes, I have software that uses the last sample check,
        Yes, I often use it,
        Yes, I have found errors.

        I use the "last sample vs last decompressed sample" check
        often, and I do find that it oaccasionally detects bad packets.
        Most of the time it is due to a datalogger crash creating a bad packet
        on disk. However, with other data loggers using SeedLink across
        TCP radios, I have seen MiniSEED packet corruption, both in
        the data AND in the headers. So TCP does not flag all multi-bit errors.

        - Doug N

        I am not totally opposed to having a CRC in the format, but feel that
        its benefits vs. costs should be considered. There is value in
        simplicity.

        thanks
        Philip

        On Thu, Aug 11, 2016 at 3:48 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

        Hi all,

        Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached:
        Change CRC to represent encoded rather than decoded data.

        Please use this thread to provide your feedback on this proposal by
        Wednesday August 24th.

        thanks,
        Chad





        ----------------------
        Posted to multiple topics:
        FDSN Working Group II
        (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
        FDSN Working Group III
        (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

        Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
        Update subscription preferences at http://www.fdsn.org/account/profile/


        ----------------------
        Posted to multiple topics:
        FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
        FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

        Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
        Update subscription preferences at http://www.fdsn.org/account/profile/


        --
        ------------------------------------------------------------------------
        Doug Neuhauser University of California, Berkeley
        doug<at>seismo.berkeley.edu Berkeley Seismological Laboratory
        Office: 510-642-0931 221 McCone Hall # 4760
        Fax: 510-643-5811 Berkeley, CA 94720-4760
        Remote: 530-752-5615 (Wed,Fri)

        ----------------------
        Posted to multiple topics:
        FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
        FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

        Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
        Update subscription preferences at http://www.fdsn.org/account/profile/

        • Hi,

          I agree with the rationale for this proposal. Even though we lose the capability to validate that the data was properly decoded, that process is not well defined given byte order differences.

          A further consideration is whether we should move the CRC near the top of the header and include as much of the header as possible along with the data.

          Chad


          On Aug 12, 2016, at 9:54 AM, Philip Crotwell <crotwell<at>seis.sc.edu> wrote:

          OK, then I am in favor of including the CRC.

          However, in thinking more about this, I do not think it makes any
          sense to protect only the data with the CRC. After all an error in the
          headers could be more damaging than one in the data. So, perhaps it is
          better to have the CRC field be over the entire record, with the CRC
          bytes assumed to be zero for purposes of the calculation.

          Philip

          On Thu, Aug 11, 2016 at 7:19 PM, Doug Neuhauser
          <doug<at>seismo.berkeley.edu> wrote:


          On 08/11/2016 02:29 PM, Philip Crotwell wrote:
          Hi

          I am inclined to agree with this. Back in the old days, the first
          sample/last sample were part of the record, with I guess the idea that
          if there was a transmission error you could both check that the
          decompression was done correctly, as well as potentially decompress
          backwards in time to the point of error. In practice I think that
          errors in the compression are near zero and so this amounts to just a
          check on bit errors in transmission. In this case, there is no benefit
          to having the CRC on the decompressed data, and quite a lot of speed
          improvement to having it on the encoded.

          However, I question whether this is even needed as part of the file
          format. It adds complexity to data loggers, perhaps small, but not
          zero. It makes sense as part of a transmission protocol or a file
          system, but that is a separate issue. Perhaps it is cheap insurance,
          but unless it is actively used by receiving software, it doesn't
          really help. Perhaps a question to be asked is does anyone use the
          existing last sample check and has anyone actually encountered real
          miniseed packets with errors? If this type of error doesn't actually
          happen, then perhaps we should not add in a fix for it.

          Yes, I have software that uses the last sample check,
          Yes, I often use it,
          Yes, I have found errors.

          I use the "last sample vs last decompressed sample" check
          often, and I do find that it oaccasionally detects bad packets.
          Most of the time it is due to a datalogger crash creating a bad packet
          on disk. However, with other data loggers using SeedLink across
          TCP radios, I have seen MiniSEED packet corruption, both in
          the data AND in the headers. So TCP does not flag all multi-bit errors.

          - Doug N

          I am not totally opposed to having a CRC in the format, but feel that
          its benefits vs. costs should be considered. There is value in
          simplicity.

          thanks
          Philip

          On Thu, Aug 11, 2016 at 3:48 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

          Hi all,

          Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached:
          Change CRC to represent encoded rather than decoded data.

          Please use this thread to provide your feedback on this proposal by
          Wednesday August 24th.

          thanks,
          Chad





          ----------------------
          Posted to multiple topics:
          FDSN Working Group II
          (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
          FDSN Working Group III
          (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/


          ----------------------
          Posted to multiple topics:
          FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/


          --
          ------------------------------------------------------------------------
          Doug Neuhauser University of California, Berkeley
          doug<at>seismo.berkeley.edu Berkeley Seismological Laboratory
          Office: 510-642-0931 221 McCone Hall # 4760
          Fax: 510-643-5811 Berkeley, CA 94720-4760
          Remote: 530-752-5615 (Wed,Fri)

          ----------------------
          Posted to multiple topics:
          FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/

          ----------------------
          Posted to multiple topics:
          FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/


          • The way the checksum is done in TCP packets is to initially set the
            checksum bytes to zero, then calculate the checksum over the entire
            packet, then afterwards set the checksum bytes to the calculated
            value. This procedure has the advantage that you can checksum the
            entire record, not just the parts after the checksum location in the
            header. The TCP checksum is simpler than the CRC in gzip, and has the
            property that the checksum over the packet, including the checksum
            bytes, always gives zero. The equivalent in the CRC case would be to
            skip the CRC bytes in the header (ie assume zero) and then compare the
            value computed with the one in the header.

            But the main point is that because the location of the checksum in the
            header does not determine what can be part of the checksum, I would
            argue that everything should be included (why not?), and we do not
            need to be overly concerned about the location of the CRC in the
            header. For efficiency reasons you might actually prefer it to be
            after the data to allow it to be computed/stored in a streaming mode.
            Not sure if that complication is worth it, but moving the CRC to the
            final 4 bytes of the record might be worth thinking about.

            It may also be wise to allow the CRC not to be set for cases where
            computational speed is more important and errors are not likely, like
            reading, modify, write from a disk. Setting the CRC to zero probably
            is sufficient, but I think there is the possibility that a real CRC
            could actually end up being zero, one chance in 2^32, so likely that
            is small enough not to worry about.

            Philip

            On Thu, Aug 18, 2016 at 10:26 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:
            Hi,

            I agree with the rationale for this proposal. Even though we lose the capability to validate that the data was properly decoded, that process is not well defined given byte order differences.

            A further consideration is whether we should move the CRC near the top of the header and include as much of the header as possible along with the data.

            Chad


            On Aug 12, 2016, at 9:54 AM, Philip Crotwell <crotwell<at>seis.sc.edu> wrote:

            OK, then I am in favor of including the CRC.

            However, in thinking more about this, I do not think it makes any
            sense to protect only the data with the CRC. After all an error in the
            headers could be more damaging than one in the data. So, perhaps it is
            better to have the CRC field be over the entire record, with the CRC
            bytes assumed to be zero for purposes of the calculation.

            Philip

            On Thu, Aug 11, 2016 at 7:19 PM, Doug Neuhauser
            <doug<at>seismo.berkeley.edu> wrote:


            On 08/11/2016 02:29 PM, Philip Crotwell wrote:
            Hi

            I am inclined to agree with this. Back in the old days, the first
            sample/last sample were part of the record, with I guess the idea that
            if there was a transmission error you could both check that the
            decompression was done correctly, as well as potentially decompress
            backwards in time to the point of error. In practice I think that
            errors in the compression are near zero and so this amounts to just a
            check on bit errors in transmission. In this case, there is no benefit
            to having the CRC on the decompressed data, and quite a lot of speed
            improvement to having it on the encoded.

            However, I question whether this is even needed as part of the file
            format. It adds complexity to data loggers, perhaps small, but not
            zero. It makes sense as part of a transmission protocol or a file
            system, but that is a separate issue. Perhaps it is cheap insurance,
            but unless it is actively used by receiving software, it doesn't
            really help. Perhaps a question to be asked is does anyone use the
            existing last sample check and has anyone actually encountered real
            miniseed packets with errors? If this type of error doesn't actually
            happen, then perhaps we should not add in a fix for it.

            Yes, I have software that uses the last sample check,
            Yes, I often use it,
            Yes, I have found errors.

            I use the "last sample vs last decompressed sample" check
            often, and I do find that it oaccasionally detects bad packets.
            Most of the time it is due to a datalogger crash creating a bad packet
            on disk. However, with other data loggers using SeedLink across
            TCP radios, I have seen MiniSEED packet corruption, both in
            the data AND in the headers. So TCP does not flag all multi-bit errors.

            - Doug N

            I am not totally opposed to having a CRC in the format, but feel that
            its benefits vs. costs should be considered. There is value in
            simplicity.

            thanks
            Philip

            On Thu, Aug 11, 2016 at 3:48 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

            Hi all,

            Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached:
            Change CRC to represent encoded rather than decoded data.

            Please use this thread to provide your feedback on this proposal by
            Wednesday August 24th.

            thanks,
            Chad





            ----------------------
            Posted to multiple topics:
            FDSN Working Group II
            (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III
            (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/


            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/


            --
            ------------------------------------------------------------------------
            Doug Neuhauser University of California, Berkeley
            doug<at>seismo.berkeley.edu Berkeley Seismological Laboratory
            Office: 510-642-0931 221 McCone Hall # 4760
            Fax: 510-643-5811 Berkeley, CA 94720-4760
            Remote: 530-752-5615 (Wed,Fri)

            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/

            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/


            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/



            • On 19.08.2016 16:23, Philip Crotwell wrote:

              But the main point is that because the location of the checksum in the
              header does not determine what can be part of the checksum, I would
              argue that everything should be included (why not?), and we do not
              need to be overly concerned about the location of the CRC in the
              header. For efficiency reasons you might actually prefer it to be
              after the data to allow it to be computed/stored in a streaming mode.
              Not sure if that complication is worth it, but moving the CRC to the
              final 4 bytes of the record might be worth thinking about.

              I have one thought about why CRC might usefully only be over data:
              it is not unknown for network/station/location/channel
              codes to be be changed. Changing archived miniSEED would require
              recomputed CRCs if they extend over the stream identifier
              parts. I'm undecided if that's a strength or weakness.


              It may also be wise to allow the CRC not to be set for cases where
              computational speed is more important and errors are not likely, like
              reading, modify, write from a disk. Setting the CRC to zero probably
              is sufficient, but I think there is the possibility that a real CRC
              could actually end up being zero, one chance in 2^32, so likely that
              is small enough not to worry about.

              We already have ~100TB of archived data: ~2^46 bytes. If they were
              all 512 = 2^9 bytes, that's 2^37 records, and 2^37 check sums. I
              suspect there are quite a few with CRC = 0.

              Best wishes,
              P.


              --
              Dr Peter L Evans, GEOFON Data Centre
              GFZ German Research Centre for Geosciences
              pevans<at>gfz-potsdam.de Tel. +49 (0)331 288-1261
              http://geofon.gfz-potsdam.de/ Fax: +49 (0)331 288-1277

  • Agree. A CRC should confirm the integrity of the verbatim bytes representing
    the data record



    From: Chad Trabant [chad<at>iris.washington.edu]
    Sent: Thursday, August 11, 2016 3:47 PM
    To: Tim Ahern <tim<at>iris.washington.edu>; Bob Hutt <Hutt<at>asl.cr.usgs.gov>;
    Bruce Beaudoin <bruce<at>passcal.nmt.edu>; Pete Davis
    <pdavis<at>epicenter.ucsd.edu>; Kent Anderson <kent<at>iris.edu>; Bob Woodward
    <woodward<at>iris.edu>; Katrin Hafner <hafner<at>iris.edu>; Justin Sweet
    <jrsweet<at>uw.edu>; Brent.Evers<at>iris.edu; David Wilson <dwilson<at>usgs.gov>;
    Mathias Franke <mathias.franke<at>kmi.com>; Ogie Kuraica <ogie<at>kmi.com>; Neil
    Spriggs <NeilSpriggs<at>nanometrics.ca>; Angel Rodriguez
    <angel<at>volcanbaru.com>; Leonid Zimakov <L.Zimakov<at>reftek.com>; Edelvays
    Spassov <ens<at>kmi.com>; Branden Christensen
    <branden.christensen<at>osop.com.pa>; Dieter Stoll
    <dstoll<at>lennartz-electronic.de>; Seiji Tsuboi <tsuboi<at>jamstec.go.jp>; Jara
    Salvador, Jose Antonio <JoseAntonio.Jara<at>icgc.cat>; David Easton
    <davideaston<at>nanometrics.ca>; timparker<at>nanometrics.ca; John Clinton
    <jclinton<at>sed.ethz.ch>; Vallee Martin <vallee<at>ipgp.fr>; Constantin Ionescu
    <viorel<at>info.ro>; Marmureanu.Alexandru<at>dst.units.it; Bogdan Grecu
    <bgrecu<at>infp.ro>; Cristian Neagoe <cristian.neagoe<at>infp.ro>; Helle Pedersen
    <Helle.Pedersen<at>ujf-grenoble.fr>; Catherine Pequegnat
    <catherine.pequegnat<at>obs.ujf-grenoble.fr>; Pierre Volcke
    <pierre.volcke<at>obs.ujf-grenoble.fr>; Angelo Strollo
    <strollo<at>gfz-potsdam.de>; S├ębastien Judenherc
    <Sebastien.Judenherc<at>fedd-scientific.com>; Tony Russell
    <tony.russell<at>kenda.co.uk>; Robert Leugoud <rleugoud<at>eentec.com>; Jiang Li
    <lijiang01<at>geodevice.cn>; Lani Oncescu <lani<at>kmi.com>; Shawn Goessen
    <support<at>guralp.com>; Dennis Pumphrey <dp<at>kmi.com>; Suzan Kowalski
    <suzankowalski<at>nanometrics.ca>; Bruce Townsend
    <brucetownsend<at>nanometrics.ca>; Joseph Steim <steim<at>quanterra.com>; Ian
    Billings <reftek_support<at>trimble.com>; Claudio Parma <c.parma<at>solgeo.it>
    Cc: fdsn Group II <fdsn-wg2-data<at>lists.fdsn.org>; FDSN Working Group III
    <fdsn-wg3-products<at>lists.fdsn.org>
    Subject: Next generation miniSEED - 2016-3-30 straw man change proposal 6 -
    Change CRC to represent encoded rather than decoded data





    Hi all,



    Change proposal #6 to the 2016-3-30 straw man (iteration 1) is attached:
    Change CRC to represent encoded rather than decoded data.



    Please use this thread to provide your feedback on this proposal by
    Wednesday August 24th.



    thanks,

    Chad