Saturday, August 12. Shane arrived at field site around 9:20 AM, initialized BSU at 9:24 AM, started laser warm-up at 9:25 AM.
Eastern panorama at 9:28 AM PDT:
Western panorama at 9:28 AM PDT:
Photo of LabVIEW real-time display on first scan at 9:46 AM PDT:
At 18:36 UTC today the data system simply stopped saving shots as evidenced by the SHOTS variable in the housekeeping data:
I didn't catch this until 18:42 UTC. In the 6 minutes between 18:36 and 18:42, several of the diagnostic variables exhibit unexplained behavior. For example, more erratic 1064 pulse energies (recall this is normally an average of 170 SHOTS. If SHOTS becomes zero or is erratic, then it seems plausible that the averages would become erratic too.)
And the 1543 nm pulse energy:
This higher variance in laser pulse energy, and beam position, and even in other variables, can lead one to mistakenly conclude there is a problem in the laser transmitter. Indeed, my first check was an examination of the transmitter optics, the seed laser, the Raman cell pressure, and the water level in the Nd:YAG power and cooling unit. They were all fine.
Restarted the system at 19:54 UTC and concluded the transmitter was fine. Problem must be in data acquisition system.
Another important clue was that the backscatter waveforms in LabVIEW had disappeared:
With assistance from Mack, we used the oscilloscope to confirm that we had triggers (yellow line below) and at least channel 2 (purple line) looked fine:
This led us to the conclusion that the NI PCI-5122 card was defective. Photos of the defective card:
Fortunately, we had a spare and replaced it. Was able to get the system working again by about 22:30 UTC after making adjustments to detector voltages.
The conclusion is that because the data acquisition system is very dependent upon receiving triggers from the laser, as soon as the data system fails to recognize trigger all variables that it monitors become corrupted. It's important to remember that the numbers in the housekeeping data files are averages of all pulses from the end of one scan to the next. That is why we expect to always see 170 or 171 in the SHOTS variable for 17 s between scans. During this failure, the SHOTS variable fell to 5 or 6 (not sure why) and all the diagnostic variables became noisy.
Soon after restoring the system, a gust front blew through from the north to the south:
Very strong northerly flow behind the leading edge (the green area) of this outflow boundary. Thunderstorm to the north.
Unfortunately, not many sky photos from today because too busy troubleshooting and repairing system.
Eastern panorama at 5:21 PM PDT:
Western panorama at 5:21 PM PDT:
Here is a snapshot of the LabVIEW panels showing detector voltages, transmit energy, and the shapes of the raw backscatter waveforms:
Shut system down from hotel at 1:38 UTC. (6:38 PM PDT).
1 Comment
Unknown User (shane)
Saturday, August 12. Shane arrived at field site around 9:20 AM, initialized BSU at 9:24 AM, started laser warm-up at 9:25 AM.
Eastern panorama at 9:28 AM PDT:
Western panorama at 9:28 AM PDT:
Photo of LabVIEW real-time display on first scan at 9:46 AM PDT:
At 18:36 UTC today the data system simply stopped saving shots as evidenced by the SHOTS variable in the housekeeping data:
I didn't catch this until 18:42 UTC. In the 6 minutes between 18:36 and 18:42, several of the diagnostic variables exhibit unexplained behavior. For example, more erratic 1064 pulse energies (recall this is normally an average of 170 SHOTS. If SHOTS becomes zero or is erratic, then it seems plausible that the averages would become erratic too.)
And the 1543 nm pulse energy:
This higher variance in laser pulse energy, and beam position, and even in other variables, can lead one to mistakenly conclude there is a problem in the laser transmitter. Indeed, my first check was an examination of the transmitter optics, the seed laser, the Raman cell pressure, and the water level in the Nd:YAG power and cooling unit. They were all fine.
Restarted the system at 19:54 UTC and concluded the transmitter was fine. Problem must be in data acquisition system.
Another important clue was that the backscatter waveforms in LabVIEW had disappeared:
With assistance from Mack, we used the oscilloscope to confirm that we had triggers (yellow line below) and at least channel 2 (purple line) looked fine:
This led us to the conclusion that the NI PCI-5122 card was defective. Photos of the defective card:
Fortunately, we had a spare and replaced it. Was able to get the system working again by about 22:30 UTC after making adjustments to detector voltages.
The conclusion is that because the data acquisition system is very dependent upon receiving triggers from the laser, as soon as the data system fails to recognize trigger all variables that it monitors become corrupted. It's important to remember that the numbers in the housekeeping data files are averages of all pulses from the end of one scan to the next. That is why we expect to always see 170 or 171 in the SHOTS variable for 17 s between scans. During this failure, the SHOTS variable fell to 5 or 6 (not sure why) and all the diagnostic variables became noisy.
Soon after restoring the system, a gust front blew through from the north to the south:
Very strong northerly flow behind the leading edge (the green area) of this outflow boundary. Thunderstorm to the north.
Unfortunately, not many sky photos from today because too busy troubleshooting and repairing system.
Eastern panorama at 5:21 PM PDT:
Western panorama at 5:21 PM PDT:
Here is a snapshot of the LabVIEW panels showing detector voltages, transmit energy, and the shapes of the raw backscatter waveforms:
Shut system down from hotel at 1:38 UTC. (6:38 PM PDT).