International Federation of Digital Seismograph Networks

FDSN Working Group II

Data Format, Data Centers and Software

fdsn-wg2-data@lists.fdsn.org

  • Subscribe by email
    Your subscription must be approved by a moderator.
  • You need to subscribe in order to post a message.
December
November
October
September (3)
August
July (3)
June (1)
May (5)
April
March (1)
February
January
December
November
October
September
August
July (10)
June
May
April (1)
March
February
January
December (1)
November (9)
October
September
August
July
June
May (2)
April
March
February
January
December
November
October
September
August
July
June (4)
May
April
March
February
January (6)
December (1)
November
October
September
August
July
June
May (1)
April (5)
March (5)
February
January
December
November
October
September
August
July
June
May
April
March
February
January (6)
December
November
October
September
August
July
June
May
April
March
February
January
December
November (2)
October (2)
September
August
July
June (1)

Active Message Threads for May 2016

Tim Ahern
May 10, 2016, 10:04 a.m. - May 17, 2016, 3:39 p.m.
Comments Must Be Submitted to WG II list (fdsn-wg2-data@lists.fdsn.org) by May 31, 2016 I apologize for the delay in getting this information out to everyone. I am attaching the following items 1) The agenda for our meeting in Vienna 2) The next generation of miniSEED document - this is the straw man and is currently Version 2016­-3­-30 3) The rationale for the recommended changes 4) The process proposed at the EGU meeting and it is the process we will follow 5) the Excel template in... [more]
Philip Crotwell
May 13, 2016, 5:24 p.m.
Hi I have put together a java implementation of the strawman 2016-3-30 here: https://github.com/crotwell/seisFile/tree/miniseed3/src/main/java/edu/sc/seis/seisFile/mseed3 There is nothing like actually trying to implement something in code to help see how a spec really works. For what it is worth, I feel like the strawman is much, much improved over the old miniseed2. It is so much simpler and easier to code. I feel that the reduced complexity will make it much less likely that weird and su... [more]
No replies
Philip Crotwell
May 13, 2016, 1:56 p.m.
If sub 1 second packets are used, start times during/near leap seconds may not be in numerical order. Just add warning to docs. Philip
No replies
Philip Crotwell
May 13, 2016, 1:41 p.m.
Hi Small change in text, start time leap second bit is bit 1 not bit 2. Philip
No replies
Philip Crotwell
May 12, 2016, 3 p.m. - May 13, 2016, 8:54 a.m.
Propose to add U as a legal data quality value, indicating user modification as opposed to data center modification. Existing data quality values mostly pertain to data centers. Adding a value to explicitly say the user has modified the data would allow the user to tell processed data from data center "original" data and also allow the user to use the data version field to track their changes. So Q2 data means the data center did a change in quality control, while a U3 means the user has mo... [more]
Replies
Philip Crotwell
May 12, 2016, 2:15 p.m. - May 13, 2016, 8:53 a.m.
Hi Spreadsheet is attached. But as reading in a spreadsheet is painful, here is the idea: Loc ids give namespace to channel codes, but were separate due to constraints of seed. It would be more logical to combine the two into a single field. Propose that this be 8 chars where it can be of the form: BIO, LLBIO, LLBIIO, LLLLBIO, or LLLLBIIO where L is locid, B is band code, I is instrument code and O is orientation code. This preserves naming for older channels, with and without locids, and p... [more]
Replies
Philip Crotwell
May 12, 2016, 4:29 p.m.
The Flags header byte contains the byte ordering of the header. Since the you need the byte order to extract the rest of the header, it makes sense to move it to the front of the header so reading software does not have to read ahead to get this value. Byte 4 seems the best place, immediately after the header version field, but it should be at least before the first multi-byte binary header field. thanks Philip
No replies