I am encountering an issue with scautopick in a SeisComP setup monitoring an accelerographic network, specifically with RefTek SMHR2 stations.
While scautopick runs without any issues for most of our network, it fails to initialize properly for these specific instruments when registered via the SMP (SeisComP Management Package) inventory catalog.
1. First Issue: Missing Gain / Vertical Component Setup
When starting scautopick, I get the following error message:
Plaintext
No gain for stream NET.STAT.LOC.HNZ
NET.STAT.LOC.HNZ failed to setup vertical component
What I have checked so far:
The station inventory/metadata has been thoroughly inspected. All streams, channels, sensors, and datalogger responses appear correctly configured.
I even cloned the station metadata structure from a working station in the catalog, but the issue persists on the SMHR2 instruments.
Gains and responses are defined in the inventory for all components.
2. Second Issue: Horizontal Component Error (Log Output)
Additionally, in the scautopick logs, I consistently see errors like these:
Plaintext
2026/08/26 07:33:13 [error/Autopick] MF.AAZR.11.HNZ: 1st horizontal component not available
2026/08/26 07:33:41 [error/Autopick] MF.PQSH.11.HNZ: 1st horizontal component not available
These log errors only occur on the RefTek SMHR2 stations.
Interestingly, despite these errors being logged, I have observed that scautopickis still generating picks for these stations.
Has anyone encountered a similar issue with RefTek SMHR2 sensors/dataloggers in SeisComP?
Could this be related to how components/azimuths/orientations or gain multipliers are mapped for strong-motion channels (HN*) in the inventory binding files for scautopick?
What would be the best approach or logging level (--debug) to trace where scautopick is failing to resolve the gain/component setup?
Any help, insights, or suggestions on where to look would be greatly appreciated!
in order to determine whether a component is vertical or horizontal or something else you need to define azimuth and dip in the stream object. Without having a look and your inventory for the faulty stations, I can’t help much. The error message is pretty clear: “No gain for stream”. So stream.gain seems to be unset.
There is more to it like network and stations and their epochs and so on. Those screenshots are nice but not very helpful to help with the issue. If I had to debug it, I would need the complete inventory XML of an affected station. Otherwise it is difficult. You can also check inventory issues with scinv check inv.xml. Maybe it reveals some issues already.
Are there other debug message like gain corrections? Maybe the corrected gain ends up being zero because the response at the sensor gain frequency is 0.
Btw, have you modified the output of “No gain for stream NET.STAT.LOC.HNZ” or is it real?
No, its not real, I use that as an example, the real one is: MF.GLIH.11.HNZ.
And that’s one of some that have the issues.
I ran the scinv check as recomended, but there is no annotation about the station GLIH on the reported file.
I don’t see any other debug messages, I will run the scautopick in a test enviroment to check and come later with the results.
Thanks
would you mind sharing the inventory and some short waveform data with seismic phases to be picked with me in private for taking a closer look? I am maintaining the checks in scinv and if there is a real issue, I would like to add the test as well.
Have you configured the S-phase picker `spicker = S-L2` or similar or do you try to measure ML amplitudes which both require the horizontal components? Your inventory for MF.AAZR.11.* only contains the vertical component but no horizontals which could explain the error message “1st horizontal …“
I downloaded and inspected your inventory from SMP and actually, scinv check finds are range of issues which you should address first. For complete checks you should work with SeisComP in version 6.6 or higher, ideally 7.2 or higher.
One more note on your inventory: You are maintaining epochs for stations event where there is no change on station level. I recommend to close and open epochs on the lowest possible level. Examples: When sensor coordinates have changed slightly you maintain another epoch on sensorLocation level but not for station where you can continue to work with the same epoch. When data loggers or sensor specs have changed, maintain epochs on stream level but not sensorLocation, station or network. This will simplify your inventory and ease maintenance and working with it.
Thank you very much for the feedback and insights.
I went ahead and cleaned up the inventory, fixing the epoch errors as suggested. After reloading the updated file into SeisComP, the affected station is now working properly.
Regarding the second issue, scautopick continues to flag the warning. The behavior appears to stem from how the Reftek SMHR2 units structure their output: by default, they separate streams across different locations (e.g., the HNZ stream is assigned exclusively to location 11, while HNE is assigned to location 12). Because no single location contains all components, scautopick likely struggles to locate the companion streams.
I will continue to monitor scautopick’s behavior and will let you know if I find any further details or solutions.
