Changes for page SmartSolo Node Seismometers
Last modified by robert on 2026/08/12 13:08
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Attachments (4 modified, 0 added, 4 removed)
-
Objects (0 modified, 0 added, 1 removed)
Details
- Page properties
-
- Content
-
... ... @@ -106,13 +106,7 @@ 106 106 107 107 [[HERE>>http://auspass.edu.au/field/NODES_blank_fieldlog.pdf]] is an example logsheet that works well for nodes, feel free to print and use! 108 108 109 -== 2. Burial == 110 - 111 -ALL nodes should be buried flush with the ground, no exceptions. If the node is sticking up the data data quality will be significantly reduced (especially the horizontal channels, see [[below>>https://auspass.edu.au/xwiki/bin/view/Instrumentation/SmartSolo%20Nodes/#HIGU-16Horizontalnoise26howtoavoid]]). It also catches wind, makes them more visible, etc. But mostly it makes the data bad. Don't be lazy: do it right. 112 - 113 -[[An example of what not to do.>>image:1786503344572-296.jpg]] 114 - 115 -== 3. Node Placement == 109 +== 2. Node Placement == 116 116 ))) 117 117 118 118 **Site Analysis**: ... ... @@ -121,12 +121,12 @@ 121 121 * Take photographs from various angles to document the site setup thoroughly. Have a colleague stand next to it pointing at it. 122 122 * Include a detailed site description in your notes. 123 123 124 -== 4. GPS Considerations ==118 +== 3. GPS Considerations == 125 125 126 126 (% class="wikigeneratedid" %) 127 127 The GPS antenna is at the top and center of the unit, and will (usually) only receive signal with a clear sky view directly above. The signal is able to penetrate plastic and terracotta planters and a thin (2 cm?) layer of soil, but may struggle if the soil layer is too thick. **These nodes will not start recording without attaining a GPS lock** and repeated attempts will excessively drain the battery. 128 128 129 -== 5. Visibility and Location Marking ==123 +== 4. Visibility and Location Marking == 130 130 131 131 **Flag Placement**: Position a flag, preferably in a bright color (avoid green or yellow), near the instrument to aid in its future location. 132 132 ... ... @@ -135,11 +135,12 @@ 135 135 * Use a GPS device to mark the instrument's exact location. Most modern cell phones can get to about a 3m error with their internal GPS also; you can probably also get away with investing a few dollars in a good app that shows error and lets you log markers. 136 136 * Also write the GPS down on paper (ie your [[LOG SHEET>>http://auspass.edu.au/field/NODES_blank_fieldlog.pdf]]). 137 137 138 -== (% style="color:inherit; font-family:inherit; font-size:max(18px, min(20px, 14.4444px + 0.462963vw))" %) 6. Charge Time, Pre-Deployment & Post-Deployment(%%) ==132 +== (% style="color:inherit; font-family:inherit; font-size:max(18px, min(20px, 14.4444px + 0.462963vw))" %)5. Charge Time, Pre-Deployment & Post-Deployment(%%) == 139 139 140 140 * **Charging Duration**: Both types of nodes take approximately 6-8 hours to fully charge from a flat state. 141 141 * **Pre-Deployment Charging**: 142 142 ** Although the nodes hold their charge well, it's beneficial to give them a "top up" charge before deployment. 137 + 143 143 * **Operational Duration**: 144 144 ** When recording at 250 Hz, with GPS on and Bluetooth disabled, the instruments are expected to last about 30 days per charge cycle. If they are set to run only overnight, this can be extended to 60 days. 145 145 ... ... @@ -154,7 +154,7 @@ 154 154 ** Charge levels for transport will be advised by the freighter. The required SoC will depend on volume and transport method (air, land, sea). 155 155 156 156 ((( 157 -== 7. Data Sharing and Metadata Creation ==152 +== 6. Data Sharing and Metadata Creation == 158 158 ))) 159 159 160 160 **GPS Data**: ... ... @@ -169,7 +169,7 @@ 169 169 170 170 * Create and organize metadata according to the [[ANU metadata standard txt file>>attach:example_metadata.txt]]. This is going to be particularly important if you are reusing nodes at different sites... not documenting the serial numbers (of the **top half** of the node) and the times they were deployed can lead to station mix-ups. 171 171 172 -== 8. Additional Best Practices ==167 +== 7. Additional Best Practices == 173 173 174 174 * **Training and Familiarisation**: Make sure all team members are adequately trained in using the GPS devices, compass use, and other equipment to ensure consistent and accurate data collection. 175 175 ... ... @@ -439,6 +439,9 @@ 439 439 440 440 We are aware that there are various different published responses for these instruments and trust very few of them. One has to be careful with how polarity is handled between groups as well, and if one is working in integer counts (the ANSIR default) or mV (unclear why anyone would use this as it makes file sizes enormous). The response information published below is in **counts** and seems to fit well in huddle tests. Note that the response is the same for all channels and all units (e.g. there are no bespoke calibrations!), all appear to be sample rate insensitive, and the IGU data has been inverted (multiplied by -1) as described here: [[5Hz Node Polarity Issues>>https://auspass.edu.au/xwiki/bin/view/Data/AusPass%20Data/#HSmartSoloNodePolarityIssues]] 441 441 437 +(% class="wikigeneratedid" %) 438 +//A small note on the y-axis scale of the following plots: We are aware that raw velocity is typically scaled ~~1e-6. This data has been filtered and selected for especially quiet regions so has lower amplitude. The key point is showing the match with the known CMG-6TD and Centaur data.// 439 + 442 442 == IGU 16HR-3C == 443 443 444 444 '16HR3C': {'poles':[(-22.211059+22.217768j), (-22.211059-22.217768j)], ... ... @@ -446,15 +446,15 @@ 446 446 'gain':1, 447 447 'sensitivity': 257019225.55108312} 448 448 449 -[[X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz filter>>image: 16HR_Z_huddle.png||alt="IGU16_Z_huddle.png"]]447 +[[X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz filter>>image:IGU16_Z_huddle.png]] 450 450 451 -[[X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz bandpass filter>>image: 16HR_N_huddle.png||alt="IGU16_N_huddle.png"]]449 +[[X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz bandpass filter>>image:IGU16_N_huddle.png]] 452 452 453 453 == IGU 16-1C == 454 454 455 455 The 1C nodes seem to have the same response as the 3-channel IGU-16HR-3C (above), however the response posted at IRIS-NRL seems to imply that there is no poles and zeros information (e.g. a flat/linear response). This is 100% not so. 456 456 457 -[[IGU-16 1C, X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz bandpass filter. Seems to be same response as IGU-16HR-3C.>>image: 16HR1C_Z_huddle.png||alt="IGU16_1C_Z_huddle.png"]]455 +[[IGU-16 1C, X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz bandpass filter. Seems to be same response as IGU-16HR-3C.>>image:IGU16_1C_Z_huddle.png]] 458 458 459 459 == BD3C-5 == 460 460 ... ... @@ -470,7 +470,7 @@ 470 470 [[X axis is samples (.01 s), Y axis is velocity (m/s), 0.5-5 Hz bandpass filter>>image:BD3C_N_huddle.0.5.png]] 471 471 472 472 (% class="wikigeneratedid" %) 473 -Below the corner frequency (0.2 Hz) the phase response still fares well, but amplitude response may need to be dialed in a bit (it seems a bit high). We are working to try to calibrate this a bit better.In the next two figures the filter is **0.1** to 5 Hz:471 +Below the corner frequency (0.2 Hz) the phase response still fares well, but amplitude response may need to be dialed in a bit (it seems a bit high). In the next two figures the filter is **0.1** to 5 Hz: 474 474 475 475 476 476 [[BD3C **0.1 **to 5 Hz bandpass filter>>image:BD3C_Z_huddle.0.1.png]]
- 16HR1C_Z_huddle.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.robert - Size
-
... ... @@ -1,1 +1,0 @@ 1 -92.1 KB - Content
- 16HR_N_huddle.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.robert - Size
-
... ... @@ -1,1 +1,0 @@ 1 -88.4 KB - Content
- 16HR_Z_huddle.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.robert - Size
-
... ... @@ -1,1 +1,0 @@ 1 -80.8 KB - Content
- 1786503344572-296.jpg
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.robert - Size
-
... ... @@ -1,1 +1,0 @@ 1 -1.4 MB - Content
- BD3C_N_huddle.0.1.png
-
- Size
-
... ... @@ -1,1 +1,1 @@ 1 - 65.9KB1 +72.1 KB - Content
- BD3C_N_huddle.0.5.png
-
- Size
-
... ... @@ -1,1 +1,1 @@ 1 - 68.4KB1 +73.3 KB - Content
- BD3C_Z_huddle.0.1.png
-
- Size
-
... ... @@ -1,1 +1,1 @@ 1 - 64.3KB1 +52.1 KB - Content
- BD3C_Z_huddle.0.5.png
-
- Size
-
... ... @@ -1,1 +1,1 @@ 1 - 52.5KB1 +64.6 KB - Content
- XWiki.XWikiComments[0]
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -Mark Goldman - Comment
-
... ... @@ -1,1 +1,0 @@ 1 -I can verify that the default orientation for the SmartSolo 3C nodes is positive values for case motion to the South, West, and downwards. We have co-located nodes with permanent stations and noticed this correlation when comparing waveforms. - Date
-
... ... @@ -1,1 +1,0 @@ 1 -2026-07-09 10:45:51.967