Andy and occasionally I have spent a lot of time over the last week tracking down error flags that show up on the CSAT3A data, as seen by the "sonic" LED staying red. Not all the results are consistent, but they generally seem to point to noise originating from the switching AC to DC power supplies that we are using to power the DSMs. I would expect this noise to be at a similar frequency as the sonic acoustic signal (~100kHz).
The noise appears to be mitigated by grounding (to earth) both the CSAT3A head and the EC100 box. Hanging the EC100 on the new mounting plates on a Rohn tower was adequate. However, the Perdigão towers will be painted and paint is even on the ends where the tower sections connect. Thus, I don't think we can expect to be able to get a good earth ground by attaching to the tower (even if we scraped away to bare metal). The only mitigation strategy that I can think of would be either to run our own ground cable down the tower or to attach to the guy wires. (It doesn't seem to me to be a good idea to ground to a lightning suppression cable, even if it exists.) I don't think we can prepare to do this, other than to pack a fair amount of braid. (I have 2 small spools now packed.)
I took a snippet of data from both the Setra and Nanobarometers today in the lab, sitting on the bench.
I see white noise dominating the spectra down to about 0.1 Hz on the Setra. I estimate the noise level at 0.02 mb RMS. I don't see a spec for noise in the datasheet, but the "resolution" is listed as 0.01 mb – not a lot different. (I don't know how resolution is defined for an analog sensor!) Of course, it is possible that our A/D and/or cabling is injecting noise, but it should be better than this.
I saw no evidence of white noise on the Nano, with a general monotonic 5/3 decrease. There was a hint of a step down in frequency response by about a factor of 2 (in power) at about 2Hz.
From both of these tests, I would say that these barometers are working properly.
So...2 boxes (rsw04 & 05) have Titan power panels, Titan front panels, and Viper CPUs. With testing, I found that the DC-DC control was not being driven by any of vio 0–7 (though vio 3 controlled the Aux power). With the DC-DC control not driven (and thus at 0V), the DC-DC converter wasn't enabled to provide +24V to the Ubiquiti. Thus, I came up with a hack of using wire-wrap wire to insert +5V to the "Titan J3" connection on the power front panel. This successfully turns on the DC-DC converter. However, since J3 is now not connected, we've lost vio control of Aux. Thus, I also changed the Aux FET jumpers to leave Aux always on at +12V. (This probably wasn't necessary, since the Aux FET control has a pull-up and was on anyway, but it seemed the proper thing to do.)
I haven't mapped out the other vio ports to determine which/how ttySx are controlled by vio, but it seems to differ from what vio reports.
Even though rsw02 has an actual Titan CPU, I did the same wiring on that box as well. Perhaps vio would have worked...
rsw03 is completely different – Viper power panel, Viper front panel, and maybe a Viper. However, this tower will have a DTU Moxa system, so it needs to have an ethernet switch. Andy and I placed a switch inside it, which is a tight fit, but it probably still should be secured since it will be placed 30m high. Unfortunately, this is also the box that Gordon had identified (and I confirmed) to have intermittent data when using the front-panel RJ45 jack. Thus, the only way to connect to the Viper ethernet would appear to be using one of the precarious adaptors that slip on to the Viper board itself. (I did find that the outside Bulgin connector worked, but then we would have to route the ethernet signal back into the box to get to the switch!) This entire front panel has obvious corrosion on the connectors, so an issue with the RJ45 jack perhaps is not surprising.
Ran every head through EC100 number 1817 using ECMon. Found the following:
Type | S/N | Testing comments |
CSAT3AW | 2033 | good |
2034 | good | |
2035 | good | |
2036 | good | |
2037 | good | |
2043 | good | |
2044 | good | |
2045 | good | |
2046 | good | |
2047 | good | |
2048 | good | |
2049 | good (despite Gordon's note saying head was bad with "flags 1,4,5 set") | |
2050 | intermittent error flag | |
2051 | Head reports "NOCAL"; Tc high by 4 degrees C | |
CSAT3A/EC150 | 1244 | good |
1311 | good | |
1312 | At VERTEX | |
CSAT3AW/EC150 | 1004 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set |
1007 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1001 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1002 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1010 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1008 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1009 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1005 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1003 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
1006 | continuous "low amplitude", "signal lock" flags set (red LED); intermittent "delta T" flag set | |
2031 | good | |
2032 | good |
I have a call in to Campbell. I'm hoping that going back a rev (from 100.07) on EC100 firmware will fix 1001–1010. Heads 2050/2051 may have to be sent back .