International Federation of Digital Seismograph Networks
Thread: (no subject)
Reinoud Sleeman
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
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
Attachments
-
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
-
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
-
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
-
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
-
-
-
Tim Ahern
Salvatore Mazza
Pete Davis
Constanza Pardo