model restarts logged for Fri 10/Aug/2018
2018_08_10 14:54 h1iopsush2a
2018_08_10 14:55 h1susmc1
2018_08_10 14:55 h1susmc3
2018_08_10 14:57 h1suspr3
2018_08_10 14:57 h1susprm
unexpected restart due to IOP crash.
Sheila, Dave:
h1sush2a failed again last night at Aug 10 2018 22:51:28 PDT.
Unlike yesterday afternoon, this time the communication between the CPU and the IO Chassis had stopped. This morning Sheila power cycled the IO Chassis and computer to restore the OneStop communications.
Richard suggests this could be another degrading OneStop fiber transceiver, if it persists we can swap over to using a fiber from the spares pool.
The power cycle procedure was: stop models, take node out of dolphin, power down cpu, power down IO Chassis (front then back switch), power up IO Chassis (back then front switch), power on cpu.
h1iopsush2a went into a very minor negative-IRIGB excursion, which only lasted a few minutes. All is good again now.
Craig, Hang, Georgia, Sheila
We've been having trouble locking, probably because of the wind and a small EQ, and perhaps because the IMC UGF was too high. We decided to use some single bounce time to investigate why we can't engage the OMC ASC. We were able to engage it when we were doing OMC scans just over a week ago. We haven't been able to lock the OMC because we rail the OM3 +OMC suspensions if we try to engage the QPD loops.
Hang and I noticed that the picomotor for AS_A was accidentally moved on August 7th. Even though the settings were set back, we suspect that the pointing onto the QPD may not have been restored because of the hysteresis of the picomotor. On August 7th the AS_C pico was moved for a better SR2 pointing through the OFI.
Craig used his script that restores optics to a given time using the top mass witnesses to restore SR2, OM1,2,3 and the OMC to their alignments from July 31st at 22:53 UTC, which is the time of one of our single bounce scans. We saw that this brought the OMC QPDs closer to their lock point, and pico'd AS_A to center the beam on the diode. AS_B pico has not moved since Thomas Vo adjusted it in June so we didn't touch that. Once AS_A was centered here we closed the AS centering loops, and pico's AS_A while it was in loop to bring the OMC ASC error signals to zero.
After this was done we were able to close the OMC APD loops without a problem, and then walked SR2 back to it's more recent alignment. The OMs are still not railed.
Dear Sheila, what you say about the Picomotors rings true. Calum and I did some investigations into the Picomotor hysteresis. The method by which the Picomotor achieves motion relates to a stick-slip phenomenon. As each Picomotor is preloaded with a certain force, there is an intrinsic tendency for a step in one direction to be unequal in motion to a step in the opposite direction. In addition, this highly friction dependent phenomenon is rife with hysteresis. Simple summary is that if you step N numbers of steps for a Picomotor, you will never know exactly how to reverse this action without a secondary measure of motion.
Past experience shows that a backward motion may be no more than 80% of the forward motion. So the resulting alignment error can be as large as 20% of the full motion.
We have started a 1 hour ring heater test at 04:00:00 UTC. The ring heater on ETMX will run for 1 hour at 3W.
We have shuttered the ALS green beam while we do this test, it can be unshuttered in the morning.
I will schedule another identical ETMX ring heater test tonight at the 04:00:00 UTC, same parameters, from ZOTWS14.
We had a lockloss during the analog CARM transition 2018-08-11_00:47:53Z The IMC didn't loose lock in this case, but the guardian just checks for IMC locklosses to determine if the interferometer has lost lock, so it didn't go to down and continued to blast the suspensions with ASC signals.
I added a new definition for Full_IFO to the is_locked function in isclibrary, which checks TRX NORM. This is checked in every state after RF_DARM
I think I have seen this before this week, the h1omcpi model (64kHz) ran long this afternoon with a cycle time of 50uS (max is 15uS). /proc/h1omcpi/status shows that the max cpu had been as high as 66uS on Aug 02 2018 18:29:39 PDT. A DIAG_RESET of all models cleared the TIM and IPC latched bits. If this becomes a regular occurance, I'll auto-clear the bits to provide a better trend.
Hugh and I made sure that the channel names corresponded to the correct speed sensors. I looked at the realtime data while Hugh stopped each speed sensor with a post. They do, and the channel names are: H1:PEM-X_FENCE_WIND_SPEED_1_MA H1:PEM-X_FENCE_WIND_SPEED_1_MPS H1:PEM-X_FENCE_WIND_SPEED_2_MA H1:PEM-X_FENCE_WIND_SPEED_2_MPS H1:PEM-X_FENCE_WIND_SPEED_3_MA H1:PEM-X_FENCE_WIND_SPEED_3_MPS H1:PEM-X_FENCE_WIND_SPEED_4_MA H1:PEM-X_FENCE_WIND_SPEED_4_MPS H1:PEM-X_FENCE_WIND_DIR_1_MA H1:PEM-X_FENCE_WIND_DIR_1_DEG H1:PEM-X_FENCE_WIND_DIR_2_MA H1:PEM-X_FENCE_WIND_DIR_2_DEG H1:PEM-X_FENCE_WIND_DIR_3_MA H1:PEM-X_FENCE_WIND_DIR_3_DEG H1:PEM-X_FENCE_WIND_DIR_4_MA H1:PEM-X_FENCE_WIND_DIR_4_DEG Only the 1st, 2nd and 4th wind speeds and the 1st wind direction have working sensors. When it arrives, the new speed sensor to replace the broken one will be the 3rd speed channel. We labeled each cable with the sensor name, so we can keep them straight. We also wanted to calibrate the direction sensor with the End X roof direction sensor. We found that our sensor showed where the wind was coming from, while the End X building sensor showed where the wind was blowing towards. Thus, their measurements were off by about 180 degrees, so Hugh rotated the ground direction sensor. This is in a previous aLog entry, but here are the directions for the sensors: Wind travelling in +X direction (from corner station towards X end): 0 (degrees) Wind travelling in the +Y direction (from the corner station toward EY): 270 Wind travelling in the -Y direction, EY to CS (approx. direction of typical storm): 90 Wind travelling in the -X direction, EX to CS (the other most common storm direction): 180 We moved the sensors closer together to try a new huddle test today, as there will be high wind speeds later. They are now about 2 feet apart. I attached a picture of the new huddle test layout, as well as a rough sketch for the speed sensor locations for next week. If whoever moves them could make a new sketch with the sensor numbers, that would be great. Hugh also zip tied sections of the test fence together to more closely resemble the real fence.
Similar to last Friday (alogs here Link and here Link) h1sush2a had a timing glitch which the IOP could not recover from and the DAC drives were subsequently zeroed.
This time the user models detected an ADC timing error (see attached dmesg output) which was not the case last Friday.
After the IMC was put into a safe state, I stopped the models and ran the IOP model by itself for several minutes to verify its timing. I then started the mc1, mc3, prm and pr3 models one at a time, verifying the IOP IRIG-B each time. There is no repeat of the IRIG-B excursion this time. Why this has happed twice in one week with no activity in the CER is still a mystery.
Autocal of the 18bit DACs are correct, once again the 3rd DAC runs slightly long in its cal cycle.
Attached image shows the three separate 18bitDAC autocal blocks since h1sush2a was rebooted last Friday 3rd August 2018.
The first block is soon after the reboot when the models were auto-started The second block is 3.01 hours later when a model restart was required (the IOP IRIG-B excursion had almost completed). The third block is today's restart, 7.20 days after the reboot.
Jenne, Craig We are wondering about our IMC open loop gain, in particular, why do we have to put the servo board In1 gain slider to 31 dB to get a UGF of 100 kHz, when in the past it was much lower (I think around 8 dB for O2) to achieve the same UGF? We checked the power on the REFL PD with 1.6 watts incident and the mode cleaner unlocked. It was 4.2 mW, which was pretty close to what the calibrated ADC output reported of 3.9 mW. The IMC signal chain probably hasn't changed much since O2.
24.1 MHz modulation depth? Right now, with the new EOM, you have a modulation depth of 12.5 mrad (see 41889 ). It looks like there wasn't a measurement of the 24.1 MHz gamma just before swapping the EOM, but I found a measurement by Volker in 2012, entry 4957, that reports m = 0.13 for 24.1 MHz. So that would account for a 20 dB optical gain reduction.
The estimated current modulation at 24.1MHz is 11mrad. The modulation depth before the EOM replacement was estimated to be 14mrad.
- Kiwamu made the modulation depth measurement and got an upper limit of 40mrad [LHO ALOG 9395]
- Evan needed a fudge factor of 0.35 to match the IMC OLTF with the model. I.e. The estimated modulation depth was 14mrad. [LHO ALOG 22188]
- The newly installed EOM was tested at Caltech. It showed the modulation response of 2.1mradpk/Vpk [40m ELOG 13725]
- With the RF combiner amplifier D1800116 installed, the RF driver at the EOM was inferred to be 24.34 dBm (5.21Vpk = 3.68Vrms). [LHO ALOG 41889]
- Therefore the estimated current 24.1MHz modulation is 2.1e-3 * 5.21 = 11mrad
The ITMX, ITMY and ETMX ring heaters will be on for about an hour starting at Aug 10 2018 02:30:00 UTC and set at 3 watts
The H1 BNS inspiral range Figure of Merit (FOM) is visible again showing realtime data in the control room, running from the dmtviewer on nuc0.
I've saved this configuration as H1CAL-range.xml.
It is plotting the range from the SenseMonitor_CAL_H1 DMT monitor. Also, under the Range Tab for the graphics plot on the dmtviewer, the y-axis max is set to 1 Mpc. Someone will need to adjust that when the range goes above 1 Mpc.
(To get back to the static 2016 BNS inspiral range plot that was showing in the control room before, from the dmtviewer, open HL-range2.xml.)
J. Kissel
Using the lock stretch that Sheila called out in LHO aLOG 43263, I gathered data that shows the new violin mode forest after we've replaced ETMX, ETMY, and ITMX (with ITMY been exposed to air for ~9 months, which undoubtedly also changes the violin mode frequencies). Attached are comparisons of the Fundamental (~500 Hz), 1st Harmonic (~1000 Hz), and 2nd Harmonic (~1500 Hz) DARM ASDs from O2 (after the July 2017 EQ) and this most recent lock stretch.
I've begun to update the LHO violin mode table (Violin_Mode_Table_v2) in prep for identification of this new forest. I've used the in-air data from LHO aLOGs 40525, 42180, 38857.
So far, I can identify 29 of the fundamental 32 modes, with a 2 mHz resolution. They're tabulated below (and not yet in the table), since I've not yet associated them with a test mass (though some appear to be "obvious" given the large separation).
In hopes to identify the mode Sheila calls out as the worst, I've pushed a 503.085 Hz filter to all new test masses, on MODE 1. This way when we do get a decent lock stretch, we can identify the mass "passively" by turning on the filter with some small gain, to see on which test mass we get action. As before, we'll started by assuming the mode is controllable by driving in Pitch.
| Frequency | Potential Match w/ in-air |
| 501.553 | IY |
| 501.628 | IY |
| 501.692 | IY |
| 501.755 | IY |
| 502.784 | IX |
| 502.909 | IX |
| 503.085 | EY / IY |
| 503.198 | EY / IY |
| 503.676 | EY / IY |
| 503.733 | EY / IY |
| 504.143 | EY / IY |
| 504.176 | EY / IY |
| 504.606 | EY / IY |
| 504.719 | EY / IY |
| 504.850 | EY |
| 504.889 | EY |
| 504.942 | |
| 505.077 | |
| 505.186 | |
| 507.360 | EX |
| 507.493 | EX |
| 508.844 | EX |
| 508.938 | EX |
| 510.714 | EX |
| 510.723 | EX |
| 511.180 | |
| 513.405 | |
| 516.678 | EX |
| 516.778 | EX |
In order to gather this data, I just used the standard violin mode templates from O2 (see LHO aLOG 37921), which are linked off of the VIOLIN MODE monitor MEDM screen.
Remember, we tried to separate the mode frequencies between test masses, and cluster a given test mass, to make them more easily identifiable (see E1700342, G1701332), but the reality of implementing such a system didn't work out as planned (an already minimal supply of fibers, few sets of fiber breakages, changes in frequency after welding and annealing, etc.). See some details in LHO aLOGs 41216, 40292, and 38965, but most my memory of the failure of the plan is verbal from telecons -- perhaps others can retrace the steps.
I have started adding some violin mode bandpass filters for ETMX, but have not had a change to test them out yet.
I added bandpass, +60, -60 degree phase shifts for 508.36 Hz, 508.844 Hz, 510.714 Hz and 516.678 Hz, in the filter banks under Mode2, Mode 11, Mode 12, and Mode 13 respectively.
The 503.085 Hz mode is on ITMY, and has been damped with the MODE1 filter, with -70 gain, no extra phase ( this can definitely be tuned in the future though), and feedback to pitch.
Note: This comment should have appeared after Georgia's comment below.
The link to the wiki page above isn't working. Here is a link : Violin mode table v2
504.891 Hz is on ITMX, can be damped with a gain of -3 and a phase of -60 degrees. (FM1 in ITMX mode 1 is a 50 mHz wide filter centered at 504.891, this is narrower than our other filters because there is a nearby mode at 504.953 Hz.)
Unfortunately it looks like we have two modes on ITMY that are only separated by 4 mHz. I was able to damp a mode at 501.629 Hz on ITMY with the same MODE4 filter Georgia used to damp the mode at 501.625Hz, but with a negative gain and +60 degrees of phase. I was suspicious that these could be the same mode, so I compared a spectrum with a resolution of 2 mHz from 2:42 UTC today (before Georgia damped ITMY) with the lock at 5:09 UTC, and it looks like they are actually two modes separated by about 4mHz. (Screenshot)
To deal with this, I created a filter called doublet in MODE4 which has 0dB of gain and a phase of -31 degrees at 501.624 and -3dB with -147 degrees at 501.628 Hz. A brave soul might be able to engage this filter with the bandpass that Georgia made earlier and no additional phase shift to damp both modes at once.
Edit: I got to try the doublet filter but it isn't very effective at damping the higher frequency mode which is rung up at the moment.
I also tried to damp 501.755Hz, but I don't think this is on ITMY. I copied my filter to ETMX MODE3, and tried 2 phases of pitch, but we lost lock before I could try yaw or longitudinal for ETMX.
I added a few more violin mode damping filters for ITMY. I promise I'll update the wiki table with this information soon.
The 503.198 Hz mode (MODE5) is on ITMY YAW, and was damped easily with -10 gain (haven't optimised any of the phases yet).
I tried to tackle the ITMY forest around 501.6 Hz but had trouble with cross coupling, accidentally ringing up neighbouring modes. I narrowed the filters and had some success damping
- The 501.625 Hz mode in pitch with a gain of 15 (filter bank MODE4)
- The 501.555 Hz mode in yaw with a gain of 20 (filter bank MODE6)
- The 501.692 Hz mode had some success with a gain of -5, before we dropped lock for other reasons. Will come back to it (filter bank MODE7).
J. Kissel
We don't yet have enough long lock stretches to get more precise than 0.005 mHz resolution, but I attach a few 1 mHz BW ASDs in the recent lock stretches that Sheila mentions (and some that I've found / reported),
- 2018-08-21 07:25 - 07:54 UTC,
- 2018-08-21 02:43 - 03:11 UTC,
- 2018-08-20 21:50 - 22:25 UTC,
- 2018-08-15 19:19 - 20:48 UTC,
where, because the last from several days ago, was 1.5 hrs, I was able to get a 0.5 mHz BW ASDs.
The message -- I can concur with Sheila's assessment that these two modes at 501.625 and 501.629 are 4 mHz apart -- however, only in 1 of the 4 measurements is the lower, 501.625 mode rung up. Thus, I think (thus far, we're not yet on DC readout) this is a weakly coupled mode that was rung up by our damping exploration attempts, so if we can design a filter that only tackles 501.629, then we might be OK. (It may not even be ITMY, but the 4 mHz mode separation does smell very much like a barely-elliptic mode splitting.)
I think Sheila and Georgia are on the right track of refining the band-pass filter to be that much more narrow. Mode frequencies for these violins are stable to temperature and test mass alignment at the ~10 microHertz level, so I think plant inversion -- or at least a very narrow (0.5 mHz) band-pass -- might be OK (see second attachment; figure 2 from G1601163 and/or G1700038).
Updated the table with some gains and phases for modes 504.606 Hz, 504.719 Hz, 504.85 Hz, all on ITMX and requiring low gains (<~5). And 504.953 Hz on ITMY (high gain, -30).
Posting this screenshot as a message to all the other v-modes out there. Blue reference is before damping, red is after.
In response to Sheila's request to compare the two following locks:
Aug 21 2018 02:42:00 UTC > Aug 21 2018 03:11:00 UTC [1218854538 > 1218856278]
Aug 21 2018 05:09:00 UTC > Aug 21 2018 05:29:00 UTC [1218863358 > 1218864558]
I ran 1mHz resolution PSDs. Results are below.
LOCK Aug 21 2018 02:42:00 UTC
Freq. [Hz] SNR
501.3750 77
501.5556 33815
501.6251 10114
501.6913 2815
501.6972 184
501.7553 181884
501.8750 76
502.7849 21376
502.9092 185016
503.0863 111095
503.1984 8470
503.6779 36286
503.7335 82344
504.1442 1609
504.1778 6259
504.6075 19039
504.7205 103589
504.8516 8474
504.8900 26733
504.9529 33514
505.0786 29540
505.1875 230981
507.3609 143884
507.4945 1342
508.8452 783438
508.9403 590
510.7142 915952
510.7255 268
511.1820 147617
513.4059 398372
513.5119 159
516.6806 693925
516.7800 5140
Lock Aug 21 2018 05:09:00 UTC
Freq. [Hz] SNR
501.5540 147
501.6293 478058
501.6925 2127
501.7553 612669
502.7849 17214
502.9091 183754
503.0860 50717
503.1984 88
503.6779 48336
503.7335 45705
504.1442 5292
504.1778 17130
504.6075 45363
504.7205 529860
504.8516 386988
504.8900 1223
504.9529 534100
505.0786 50532
505.1875 238858
507.3609 269516
507.4945 1032
508.8452 459774
508.9404 271
510.7142 492155
510.7254 108
511.1819 184454
513.4059 193424
513.5119 159
516.6806 423031
516.7799 4596
I am sorry I have just noticed these round of violin modes alog entries.
I will investigate further but as a quick comment to add to the comments above:
Jeff suggested that the frequency separation of 4mHz of the two modes may indicate frequency splitting of modes associated to the same fibre. However based on the data we have from all fibres of both LIGO detectors this is very improvable. Frequency splitting observed so far is on the order of tens to hundreds of mHz, there only one case of about 1mHz separation at LLO ITMX and it is not certain to be associated to the same fibre.
Summary: Both injection based noise projections of HAM1 HPI Z to DARM indicate that vertical motion was a limiting noise source for O2 from 10- 17 Hz. These projections also suggest that there is a another coupling of HAM1Z to DARM in addition to the coupling through the refl wfs.
The first attachment is a plot from our noise budget showing a projection of CHARD noise to DARM (based on injections made June 14ths 2017) and HAM1Z motion to DARM (based on injections made in March 2017). The projection of HAM1 Z to DARM roughly matches the projection of CHARD to DARM up to about 13 Hz, so the coupling HAM1Z-> REFL WFS -> DARM can probably explain this noise. However, above 15 Hz, the projection for HAM1Z is larger than the projection for CHARD. I've also attached screenshots of the CHARD injection data, you can see that the CHARD motion was increased by 2 orders of magnitude up to 100 Hz, so the upper limit that we get from the CHARD projection is below the noise that is predicted by the L4C projection above 15 Hz.
I also looked at coherence of CHARD and the HAM1 Z with DARM for 1000 averages on July 3 2017. This also indicates that there is coherence with the HAM1 Z L4Cs above the frequencies where the CHARD loops can explain it. The final attachment is a projection based on these coherence of the noise in DARM. This kind of measurement isn't as convincing as the injection based projection because there could be other explanations for the coherence, and I might be having a problem with numerical precision in DTT with the CHARD drives.
I took the injection of HAM1 referenced above, March 17, and I made estimates for DARM contributions both based on HAM1 L4C witness and CHARD P as witness. Comparing this to LLO (also March 17 injection), we see that the projection at LLO match. I think this means that CHARD at LHO is not dominated by HAM1 Z, while that is kind of true at LLO.
After some discussion with Jeff, Sheila, Hang and Arnaud, we agreed that one of the ways to decrease the HAM1 to DARM coherence is to push up the gain of the Z feedback loop to be more similar to LLO's configuration. I think our installed loops have a ugf of ~10hz, LLO are around 30 hz. I found data to compare the LLO and LHO plants is seismic SVN, they are pretty similar but not identical, see attached plot. Other dofs show similar levels of similarity. I have some higher ugf loops pretty much ready to install, probably do that Tuesday morning.
WP 7749 (Add GS13INF..._OUT to Frames) FRS 11049 (HAM2 & 3 GS13 Gain Switching failure)
I've only looked at the first switch failure closely but I have many more in the can (just ask the operator JeffB) now with the model change adding the GS13INF_.._OUT channels to the frames.
My theory at the moment looking at the first trip is that the corner 2 & corner 3 switching is cross wired. I don't know where yet as that mapping is complex--working on it. Meanwhile...
Look at the attachment and listen to my story...
After getting the GS13INF_OUTs into the frame, I put the platforms into nominal ISOLATED state except the GS13s were in the low gain mode. I manually toggled off every filter for the GS13 gain state and noted the success of the switch. For HAM4, every filter switched with out bothering the platform. On HAMs 2 & 3, corner 1 H & V all switched with out bothering the platform. Conversely, on HAMs 2 & 3, corners 2 & 3 both H & V, every switch of FM 4 or 5 tripped the platform. I did not repeat every switch because the trips took time to recover, and, trips of the verticals on the ISI also tripped the SUSs on board. However, every repeat yielded the same result as noted, there was no inconsistent result. So I zoom into the first trip when I toggled the DW filter on HAM2 H2:
1/2 second of data displayed. Note the H2 (corner 2) SWSTAT change as the FM5 Dewhitening filter changes state. So you can see that the H2 signal (upper left green) gets more high frequency noise even compared to before the switch when the analog whitening is on and its digital DW filter is on; so the digital DW goes away but the analog whitening is still on. Conversely, looking at the H3 GS13 signal (lower right,) the analog & digital whitening and dewhitening filters are on and then the analog whitening is disabled and the digital dewhitening remains on and the signal gets very clean. Note that the H1 GS13 signal is unaffected.
So, bottom line, current theory: corner 2 digital filter is wired to corner 3 analog filter.
Why it could be happening. Maybe best bet is the problem where long long ago, the PSL group asks SEI/ISI to change feedthrus on the chamber because cables they had would not reach the flange. Normally on the ISI, corners 1 & 2 are near each other because the first CPS satellite crate has room for two corners ( there is not a separate crate for each corner on the HAMs.) When SEI changed to a different chamber feedthru, ISI cable length limits necessitated putting corners 1 & 3 into the same CPS satellite crate. We wanted all a corner's channels to go to the same feedthru so GS13 and coil drivers cables were also moved (see SEISMIC REFERENCE note on D1002873.) Since the CPS channels from a crate are on the same cable, corners 1 & 3 go into the same Interface chassis and hence the model must reflect this difference. It is around here that I suspect the problem.
The python command scripts must manage to most of the time switch the corners 2 & 3 quickly enough that it seems to work, usually. The guardian scripts however must do it just enough more slowly that it blows up.
I'll look at the other switches done and see if this story all holds up.
I hope this is the problem.
This can be easily checked by manually switching just one filter at a time.
Switching the Gain or Whitening filters from the GS13_INF filters can be done manually. The engagement of the filter module is the event which switches the digital BIO. I've attached a bit of the GS13INF module from the HAM control diagram to show this.
Thanks Brian--Yes, switching the filters manually is how I tested this: " I manually toggled off every filter for the GS13 gain [& whitening] state and noted the success of the switch."
I'm not sure if the BIO readback is helpful tho as if the model & hardware are cross-wired, the medms will suggest a correct switch. There might be some monitor on the BIO chassis we could pick off otherwise a thorough comb through the model and wiring is in order.
Herein however is the second instance that I again state is very good indication of the miss-wiredness: Attached is ~1/2 second of full data where now the digital gain (FM4) is turned off on the corner 2 horizontal GS13 and we see the H3 output blow up while the H2 signal goes quiet w/o its compensating analog gain. Least one be wary about the signals being fouled by the platform trip, look at the H1 signal where there is a clear gap between H2 & H3 changes and when the platform really starts its throes of death.
Okay--EE, CDS, & LHO SEI believe we know what the problem is and a relatively straight forward and easy way to fix this.
1) LHO GS13 Field wiring does not match the drawing. When we put CPS corners 1 & 3 together for the aforementioned PSL FT need, we thought it made sense to put the GS13s in a similar pairing--this does not match the HAM2 & 3 ISI wiring, D1101576.
2) LHO GS13 BIO switching wiring does match the drawing and this combined with 1) yields the poor results:
The GS13s 1 & 3 (Corners) are wired correctly into the top level model such that Cartesian conversion & Isolation of the platform does work. The Binary switching begins in the Common model and works upward into the top level but given hardware constraints (multiple channel switching on single cable) is unable to swap channels 2 & 3.
So, the binary switching going to Interface chassis one thinks it is switching corners 1 & 2 GS13s but GS13s 1 & 3 are on that chassis hence our digital analog miss-wire and poor behavior on corners 2 & 3.
At one time, it was likely that we had different models for HAMs 2 & 3 addressing this but no longer.
Fortunately the fix is relative simple: a) Switch the field cables at the Interface chassis for GS13s corners 2 & 3--they will then reflect the drawing (and match LLO.) b) Rewire the top level model to reflect this wiring change. Then the binary switching will actually be talking to the correct sensor.
Here is an examination into a couple of the HAM3 GS13 switches showing the same behavior as above.
First, overall plot shows that when switching H1, no evidence of the switch seen on the _OUT signals, how it is supposed to be. Not so much when the H2 filter is switched.
Second plot, shows the switching off of the digital DeWhitening on H2 and the affect on the H2 & H3 signals.
Third plot shows similar when the H2 digital Gain is toggled off and H2 goes quiet and the H3 signal blows up. Same as HAM2.
Lesson learned--check the wiring!
