International Federation of Digital Seismograph Networks

Thread: (no subject)

None
Started: March 17, 2010, 4:47 p.m.
Last activity: March 31, 2010, 4:35 p.m.
Reinoud Sleeman
March 17, 2010, 4:47 p.m.
From:
Sent: Thu 11-3-2010 17:24
To: fdsn-wg2-data<at>iris.washington.edu
Subject:




Dear WGII members,

After taking over the Chairmanship of this working group from Bernard I got
2 proposals for an extension of the SEED format. The first proposal by Tim Ahern
is the use of instrument codes X and Y:

We have a need to identify derived data in the SEED channel naming conventions.
We propose to have an instrument code of X to do this. It would allow direct
archiving of synthetic data for instance. We also propose to capture the Y
instrument code as a general code that can be used for any other instrument
(all the Instrument codes A-Z will now be used up).

His proposed text to be included in Appendix A of the SEED manual is attached.



The other proposal is made by NORSAR:

It would be very good to have the possibility to add COMMENTS in
free ASCII format to all Blockettes, which describe hardware components
of the receiver function. Extending these Blockettes, one could then
add e.g., hardware component names, serial numbers, providers or any
helpful descriptions like filter types, function of specific
Poles&Zeroes, seismometer sensitivities in clear text (not mixed up
with the normalization constant), nominal or calibrated values, .....

Such an extension of the Blockette definitions will also make it
easier to maintain DATALESS SEED headers.


Please let me know your comments.

Best regards,
Reinoud




  • Tim Ahern
    March 18, 2010, 9:20 a.m.
    Hello Reinoud

    I obviously support the adoption of the proposal related to the X & Y instrument codes in the Channel Naming Convention and vote to
    approve it. We at IRIS need this now as we are beginning to include synthetic data to the IRIS DMC's holdings.

    Regarding the NORSAR proposal. I find that it is something that I can probably be in favor of but it lacks specificity. I think it needs to have
    the description that can ultimately appear in the SEED manual written.

    Some thoughts
    Free form fields can be used to document things but are not helpful when searching for specifics. For that reason I think it would be better to have some fixed fields added to the end of blockette 52, the channel blockette. There are 4 specific things that I think could be added as fixed fields

    1) Digitizer model, something like Quanterra 330HR
    2) the serial number of the above
    3) The sensor type Streckeisen STS-2 or Kinemetrics FBA-23
    4) the serial number for item 3

    Another item that has long been missing in SEED is a field that describes the type of clock used. While many system are now GPS, older systems were
    variable. Perhaps a fifth field could be added to blockette 52 to capture the type of clock used.
    A variable free form field as wanted by NORSAR could be added after the above 4-5 fields.

    In the area of free form comments in the response stages, I really think we need to see a written description and some examples. I think I agree with the utility
    of such fields but it is not clear enough to me as to what is being proposed to say I agree or disagree with them. Could we prompt NORSAR to draft the documentation
    and provide some examples that would include the maximum length of these various fields and specifically which blockettes would support them.

    Cheers
    Tim



    Program Manager, IRIS Data Management System
    IRIS DMC
    1408 NE 45th Street #201
    Seattle, WA 98105

    (206)547-0393 x118
    (206) 547-1093 FAX




    On Mar 17, 2010, at 8:47 AM, Sleeman, Reinoud (KNMI) wrote:

    From:
    Sent: Thu 11-3-2010 17:24
    To: fdsn-wg2-data<at>iris.washington.edu
    Subject:




    Dear WGII members,

    After taking over the Chairmanship of this working group from Bernard I got
    2 proposals for an extension of the SEED format. The first proposal by Tim Ahern
    is the use of instrument codes X and Y:

    We have a need to identify derived data in the SEED channel naming conventions.
    We propose to have an instrument code of X to do this. It would allow direct
    archiving of synthetic data for instance. We also propose to capture the Y
    instrument code as a general code that can be used for any other instrument
    (all the Instrument codes A-Z will now be used up).

    His proposed text to be included in Appendix A of the SEED manual is attached.



    The other proposal is made by NORSAR:

    It would be very good to have the possibility to add COMMENTS in
    free ASCII format to all Blockettes, which describe hardware components
    of the receiver function. Extending these Blockettes, one could then
    add e.g., hardware component names, serial numbers, providers or any
    helpful descriptions like filter types, function of specific
    Poles&Zeroes, seismometer sensitivities in clear text (not mixed up
    with the normalization constant), nominal or calibrated values, .....

    Such an extension of the Blockette definitions will also make it
    easier to maintain DATALESS SEED headers.


    Please let me know your comments.

    Best regards,
    Reinoud



    <XandY Instrument CodesFinal.pdf>_______________________________________________
    fdsn-wg2-data mailing list
    fdsn-wg2-data<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


    • Salvatore Mazza
      March 18, 2010, 5:51 p.m.
      I agree on X and Y codes. Also, I share Tim's views about NORSAR proposal and I would like to go a little (but very little) further suggesting to use instruments names "recommended" by FDSN. I mean, may we think of using e.g. the names used in the Library Nominal Responses http://www.iris.edu/NRL/, when present?
      Ciao. Salvatore

      On Mar 18, 2010, at 5:20 PM, Tim Ahern wrote:

      Hello Reinoud

      I obviously support the adoption of the proposal related to the X & Y instrument codes in the Channel Naming Convention and vote to
      approve it. We at IRIS need this now as we are beginning to include synthetic data to the IRIS DMC's holdings.

      Regarding the NORSAR proposal. I find that it is something that I can probably be in favor of but it lacks specificity. I think it needs to have
      the description that can ultimately appear in the SEED manual written.

      Some thoughts
      Free form fields can be used to document things but are not helpful when searching for specifics. For that reason I think it would be better to have some fixed fields added to the end of blockette 52, the channel blockette. There are 4 specific things that I think could be added as fixed fields

      1) Digitizer model, something like Quanterra 330HR
      2) the serial number of the above
      3) The sensor type Streckeisen STS-2 or Kinemetrics FBA-23
      4) the serial number for item 3

      Another item that has long been missing in SEED is a field that describes the type of clock used. While many system are now GPS, older systems were
      variable. Perhaps a fifth field could be added to blockette 52 to capture the type of clock used.
      A variable free form field as wanted by NORSAR could be added after the above 4-5 fields.

      In the area of free form comments in the response stages, I really think we need to see a written description and some examples. I think I agree with the utility
      of such fields but it is not clear enough to me as to what is being proposed to say I agree or disagree with them. Could we prompt NORSAR to draft the documentation
      and provide some examples that would include the maximum length of these various fields and specifically which blockettes would support them.

      Cheers
      Tim



      Program Manager, IRIS Data Management System
      IRIS DMC
      1408 NE 45th Street #201
      Seattle, WA 98105

      (206)547-0393 x118
      (206) 547-1093 FAX




      On Mar 17, 2010, at 8:47 AM, Sleeman, Reinoud (KNMI) wrote:

      From:
      Sent: Thu 11-3-2010 17:24
      To: fdsn-wg2-data<at>iris.washington.edu
      Subject:




      Dear WGII members,

      After taking over the Chairmanship of this working group from Bernard I got
      2 proposals for an extension of the SEED format. The first proposal by Tim Ahern
      is the use of instrument codes X and Y:

      We have a need to identify derived data in the SEED channel naming conventions.
      We propose to have an instrument code of X to do this. It would allow direct
      archiving of synthetic data for instance. We also propose to capture the Y
      instrument code as a general code that can be used for any other instrument
      (all the Instrument codes A-Z will now be used up).

      His proposed text to be included in Appendix A of the SEED manual is attached.



      The other proposal is made by NORSAR:

      It would be very good to have the possibility to add COMMENTS in
      free ASCII format to all Blockettes, which describe hardware components
      of the receiver function. Extending these Blockettes, one could then
      add e.g., hardware component names, serial numbers, providers or any
      helpful descriptions like filter types, function of specific
      Poles&Zeroes, seismometer sensitivities in clear text (not mixed up
      with the normalization constant), nominal or calibrated values, .....

      Such an extension of the Blockette definitions will also make it
      easier to maintain DATALESS SEED headers.


      Please let me know your comments.

      Best regards,
      Reinoud



      <XandY Instrument CodesFinal.pdf>_______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



      • Pete Davis
        March 18, 2010, 2:44 p.m.
        IRIS/IDA has been in the practice of encoding sensor and DAS serial numbers in the 7th field (optional comment) of blockette 52, but without
        any explanatory material, this information is not very useful to users. So I support NORSAR's suggestion about the need for explanatory material
        that goes beyond what is accommodated by SEED already, but I agree with Tim and Salvatore that there needs to be more structure. Salvatore's
        suggestion of using the NLR is very constructive.

        I support the proposal for the X and Y codes. The IRIS DMS oversight committee is anxious to proceed with handling synthetic time series.
        This will allow the DMC to handle these series in an efficient manner.

        Cheers,
        Pete




        On Mar 18, 2010, at 9:51 AM, Salvatore Mazza wrote:

        I agree on X and Y codes. Also, I share Tim's views about NORSAR proposal and I would like to go a little (but very little) further suggesting to use instruments names "recommended" by FDSN. I mean, may we think of using e.g. the names used in the Library Nominal Responses http://www.iris.edu/NRL/, when present?
        Ciao. Salvatore

        On Mar 18, 2010, at 5:20 PM, Tim Ahern wrote:

        Hello Reinoud

        I obviously support the adoption of the proposal related to the X & Y instrument codes in the Channel Naming Convention and vote to
        approve it. We at IRIS need this now as we are beginning to include synthetic data to the IRIS DMC's holdings.

        Regarding the NORSAR proposal. I find that it is something that I can probably be in favor of but it lacks specificity. I think it needs to have
        the description that can ultimately appear in the SEED manual written.

        Some thoughts
        Free form fields can be used to document things but are not helpful when searching for specifics. For that reason I think it would be better to have some fixed fields added to the end of blockette 52, the channel blockette. There are 4 specific things that I think could be added as fixed fields

        1) Digitizer model, something like Quanterra 330HR
        2) the serial number of the above
        3) The sensor type Streckeisen STS-2 or Kinemetrics FBA-23
        4) the serial number for item 3

        Another item that has long been missing in SEED is a field that describes the type of clock used. While many system are now GPS, older systems were
        variable. Perhaps a fifth field could be added to blockette 52 to capture the type of clock used.
        A variable free form field as wanted by NORSAR could be added after the above 4-5 fields.

        In the area of free form comments in the response stages, I really think we need to see a written description and some examples. I think I agree with the utility
        of such fields but it is not clear enough to me as to what is being proposed to say I agree or disagree with them. Could we prompt NORSAR to draft the documentation
        and provide some examples that would include the maximum length of these various fields and specifically which blockettes would support them.

        Cheers
        Tim



        Program Manager, IRIS Data Management System
        IRIS DMC
        1408 NE 45th Street #201
        Seattle, WA 98105

        (206)547-0393 x118
        (206) 547-1093 FAX




        On Mar 17, 2010, at 8:47 AM, Sleeman, Reinoud (KNMI) wrote:

        From:
        Sent: Thu 11-3-2010 17:24
        To: fdsn-wg2-data<at>iris.washington.edu
        Subject:




        Dear WGII members,

        After taking over the Chairmanship of this working group from Bernard I got
        2 proposals for an extension of the SEED format. The first proposal by Tim Ahern
        is the use of instrument codes X and Y:

        We have a need to identify derived data in the SEED channel naming conventions.
        We propose to have an instrument code of X to do this. It would allow direct
        archiving of synthetic data for instance. We also propose to capture the Y
        instrument code as a general code that can be used for any other instrument
        (all the Instrument codes A-Z will now be used up).

        His proposed text to be included in Appendix A of the SEED manual is attached.



        The other proposal is made by NORSAR:

        It would be very good to have the possibility to add COMMENTS in
        free ASCII format to all Blockettes, which describe hardware components
        of the receiver function. Extending these Blockettes, one could then
        add e.g., hardware component names, serial numbers, providers or any
        helpful descriptions like filter types, function of specific
        Poles&Zeroes, seismometer sensitivities in clear text (not mixed up
        with the normalization constant), nominal or calibrated values, .....

        Such an extension of the Blockette definitions will also make it
        easier to maintain DATALESS SEED headers.


        Please let me know your comments.

        Best regards,
        Reinoud



        <XandY Instrument CodesFinal.pdf>_______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


        • Constanza Pardo
          March 31, 2010, 4:35 p.m.
          Hello all,

          We (GEOSCOPE team) support the proposal for the X and Y codes.

          We had also discussed about the need of putting digitizer information
          in channels (sensor identification is already supported
          by field 6 Instrument Identifier, blockette 52). At the beginning we
          discussed about put digitizer model in the 7th field also (optionnal
          comment)
          but we think that it would be more structured and clear to add fixed
          fields to this purpose as proposed by Tim.
          We agree that there needs more structure and we could use NRL as
          Salvatore suggests.

          Cheers,
          Constanza
          GEOSCOPE Network
          IPGP - France

          Pete Davis wrote:
          IRIS/IDA has been in the practice of encoding sensor and DAS serial
          numbers in the 7th field (optional comment) of blockette 52, but without
          any explanatory material, this information is not very useful to
          users. So I support NORSAR's suggestion about the need for
          explanatory material
          that goes beyond what is accommodated by SEED already, but I agree
          with Tim and Salvatore that there needs to be more structure. Salvatore's
          suggestion of using the NLR is very constructive.

          I support the proposal for the X and Y codes. The IRIS DMS oversight
          committee is anxious to proceed with handling synthetic time series.
          This will allow the DMC to handle these series in an efficient manner.

          Cheers,
          Pete

          /
          /


          On Mar 18, 2010, at 9:51 AM, Salvatore Mazza wrote:

          I agree on X and Y codes. Also, I share Tim's views about NORSAR
          proposal and I would like to go a little (but very little) further
          suggesting to use instruments names "recommended" by FDSN. I mean,
          may we think of using e.g. the names used in the Library Nominal
          Responses http://www.iris.edu/NRL/, when present?
          Ciao. Salvatore

          On Mar 18, 2010, at 5:20 PM, Tim Ahern wrote:

          Hello Reinoud

          I obviously support the adoption of the proposal related to the X &
          Y instrument codes in the Channel Naming Convention and vote to
          approve it. We at IRIS need this now as we are beginning to include
          synthetic data to the IRIS DMC's holdings.

          Regarding the NORSAR proposal. I find that it is something that I
          can probably be in favor of but it lacks specificity. I think it
          needs to have
          the description that can ultimately appear in the SEED manual written.

          Some thoughts
          Free form fields can be used to document things but are not helpful
          when searching for specifics. For that reason I think it would be
          better to have some fixed fields added to the end of blockette 52,
          the channel blockette. There are 4 specific things that I think
          could be added as fixed fields

          1) Digitizer model, something like Quanterra 330HR
          2) the serial number of the above
          3) The sensor type Streckeisen STS-2 or Kinemetrics FBA-23
          4) the serial number for item 3

          Another item that has long been missing in SEED is a field that
          describes the type of clock used. While many system are now GPS,
          older systems were
          variable. Perhaps a fifth field could be added to blockette 52 to
          capture the type of clock used.
          A variable free form field as wanted by NORSAR could be added after
          the above 4-5 fields.

          In the area of free form comments in the response stages, I really
          think we need to see a written description and some examples. I
          think I agree with the utility
          of such fields but it is not clear enough to me as to what is being
          proposed to say I agree or disagree with them. Could we prompt
          NORSAR to draft the documentation
          and provide some examples that would include the maximum length of
          these various fields and specifically which blockettes would support
          them.

          Cheers
          Tim



          Program Manager, IRIS Data Management System
          IRIS DMC
          1408 NE 45th Street #201
          Seattle, WA 98105

          (206)547-0393 x118
          (206) 547-1093 FAX




          On Mar 17, 2010, at 8:47 AM, Sleeman, Reinoud (KNMI) wrote:

          From:
          Sent: Thu 11-3-2010 17:24
          To: fdsn-wg2-data<at>iris.washington.edu
          <fdsn-wg2-data<at>iris.washington.edu>
          Subject:




          Dear WGII members,

          After taking over the Chairmanship of this working group from
          Bernard I got
          2 proposals for an extension of the SEED format. The first proposal
          by Tim Ahern
          is the use of instrument codes X and Y:

          We have a need to identify derived data in the SEED channel naming
          conventions.
          We propose to have an instrument code of X to do this. It would
          allow direct
          archiving of synthetic data for instance. We also propose to
          capture the Y
          instrument code as a general code that can be used for any other
          instrument
          (all the Instrument codes A-Z will now be used up).

          His proposed text to be included in Appendix A of the SEED manual
          is attached.



          The other proposal is made by NORSAR:

          It would be very good to have the possibility to add COMMENTS in
          free ASCII format to all Blockettes, which describe hardware
          components
          of the receiver function. Extending these Blockettes, one could then
          add e.g., hardware component names, serial numbers, providers or any
          helpful descriptions like filter types, function of specific
          Poles&Zeroes, seismometer sensitivities in clear text (not mixed up
          with the normalization constant), nominal or calibrated values, .....

          Such an extension of the Blockette definitions will also make it
          easier to maintain DATALESS SEED headers.


          Please let me know your comments.

          Best regards,
          Reinoud



          <XandY Instrument
          CodesFinal.pdf>_______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu
          <fdsn-wg2-data<at>iris.washington.edu>
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu
          <fdsn-wg2-data<at>iris.washington.edu>
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu
          <fdsn-wg2-data<at>iris.washington.edu>
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

          ------------------------------------------------------------------------

          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data