Following are the descriptions of the TRAM sensors. In most cases, I have not been careful with calibrations and simply have used the manufacturer's original calibration. At some point, I need to develop a Cal/Val procedure for these sensors.
I note that TRAM still does not have a fast-response humidity sensor. This is due to the lack of a suitable sensor (also a problem for UAVs).
3D sonic anemometer-thermometer: This is an ATI sonic embedded in an array that I designed. The electronics board is stuffed in a piece of squashed tubing along the top of the trolley. Originally, I used a full-sized UW array, but the torque as the trolley went around corners bent the array. I now use a 15:1 sized array, but wind tunnel testing on 6/22/2007 showed that this size still was acceptable. I have had a lot of problems over the years with bad connections of the transducer cables to the circuit board. I now use gold-plated connectors (MMCX) mechanically fastened to the board and filled the array with all-new transducers. Now, even these(?) are having some failures. (Along the way, I found that Gorilla glue creeps along the pins and coats them with insulating glue.)
To build this sonic, I cannibalized one of the "NUW" sonics (NUW6). The old pieces are still in the NUW6 case that would allow this sonic to be deployed on a tower if ever needed again (unlikely, at this point). The other 4 NUW sonics could similarly be repurposed to other TRAM trolleys, if more were ever built.
CO2 IRGA: Because of its small size, I've been using the RMT DX-6100 CO2 sensor, originally considered by Britt Stephens as a candidate for his RACCOON system. I bring air into this sensor using a KNF NMP05 pump. I used the RMT for many years and also have inherited Britt's old sensors, so that I now have 4? (though one is just for parts at this stage). Even when new, I found that I had to recalibrate the data frequently. For NIWOT07, this was straightforward since the trolley passed 6 Hydra inlets on every circuit. However, for CentNet testing in 2012 (at Marshall) my best sensor drifted offscale within a few days and never recovered. I tried a total overhaul of the optics and convinced myself that it could be improved with a bit of work, however a test of sensor drift seemed to indicate that the calibration of its "OptoPair" also wasn't too stable. Thus, I have mostly retired this sensor. At this point, I do not have a replacement. The Li-840 is tempting, but it is a bit large. Smaller sensors do exist, many with some sort of gas tube that I have no experience with. EOL/TDF built a prototype sensor for tower use, though its multipath optics might not have worked on the trolley (with lots of bumps).
Slow-response temperature-relative humidity sensor: Originally, this sensor was a Vaisala radiosonde PTU module (copying the old TAOS sonde), but the calibration was found to drift when used for long periods. (I only ever had one PTU module and never "reconditioned" it.) Now, we're using an old version of ISF's SHT75-based sensor.
PAR: For NIWOT09, I attached one of the "bullet" sensors and its PIC processor board from the PAR wands to give incoming PAR. This seems to work fine.
Motion sensing: I have gone through several sets of sensors for TRAM. I started using a TCM2-20 combination magnetometer, fluidic level, and accelerometer, but was worried about fluid sloshing. I then briefly used an HMR3300 magnetometer/accelerometer, but found that it appeared to be affected by metal in the Rohn towers. I also have looked at data from the accelerometer boards in the PAR wand, but found [?] and am not using it. I've gone back to using the TCM2, but now get primary attitude sensing from a Crista IMU. Also, I added a simple rotary counter (from a discarded propellor anemometer) attached to the front trolley idler wheel to measure the speed of the trolley along the cable (assuming no slippage of the wheel). The chopper velocities are a bit high compared to the average sonic winds, but I've double-checked the wheel diameter size and that the chopper outputs 15 pulses per revolution (simply by turning the wheel through 360 degrees and watching a DVM). My latest attempt uses a Vector Nav VN100 AVHRR device, being used by the Naval Postgraduate School, though I haven't yet "flown" with it.
Position sensing: Early on, I tried using both optical sensors (Optek OPB716 and Omron EE-SPY412) and RFID tags (Intersoft) to identify when the trolley was passing a turn. I found that both technologies were very sensitive to the position of the trolley relative to the turn and variations in the trolley motion caused both to fail a large percentage of the time. Even if one of these had worked, positions only at the turns is not enough to derive winds.
For GPS measurements, I started using an extra Garmin GPS35 from ASTER, then went to a Lassen SQ GPS module. However, at least the SQ did not perform well in the trees. I now have a Novatel OEMV2 L1/L2 GPS receiver which is quite accurate, samples faster than 1 sps (I'm using 5 sps now), and powers up quickly. I haven't yet tested it in trees. It's antenna is rather heavy (with a cast aluminum base), so I've had to rebalance the trolley.
To reconfigure the Novatel (apparently needed after a many-month period of non-use):
- connect to the "extra" connector in the trolley box (GPS COM1); RS-232, 9600 N81 (I have a special cable for this), then type the commands:
- freset standard
- freset clkcalibration
- log com2 gpgga ontime 0.2 [5 samples/s]
- log com2 gprmc ontime 0.2
- com com2 9600 n 8 1 n on off
- log com1 bestposa ontime 10 [every 10s, just for fun]
- log com1 gpgsv ontime 10
- saveconfig
I also have the trolley PIC processor measuring the power voltage and current. Before implementing speed control, I found that the current especially was useful in identifying when the trolley was in a turn, since its power consumption increased. I also find that looking at low variance of the TCM roll is a good indicator of turns. My code ORs several conditions to determine if the trolley is in a turn.
Surface Moisture: We quickly found that TRAM's wheels don't work well when the track is wet. This is one of the reasons why a human now monitors TRAM operations. I've had in mind to automate this check by using a Decagon leaf wetness sensor, and even bought with TRAM funds 2 of the ones that ISFS is now using. These data would be acquired by the TRAM DSM. I'd have to write a script to read these data and send a command to turn off the power supply if moisture was detected, which shouldn't be too hard. I even have the idea to build a "car port" over part of the track and run the trolley under it when precip was present. All of this has yet to be done.
