Confused by light?

I continued to ponder why the Perfectflite PNUT flown in Probe-18 on Saturday had ground level at -65 feet. I am not an electronics type of guy, so I did what any nerd seeking enlightenment would do - I contacted tech support:

Sir,
I experienced my first ever anomaly with a Perfectflite altimeter at this past Saturday’s launch. In brief, it seemed to think ground level was at -65 feet, and underreported the altitude by that amount (as compared to another altimeter in the same payload section). I have a post describing this on my blog: 

http://billsrockets.blogspot.com/2015/09/altimeter-funny-business.html 

and have attached the data file to this email. Any insight/help you can give would be greatly appreciated.
Kind regards,
Bill Cooke

Perfectflite responded in a day with this very informative post, which gives a lot of insight into the workings of the PNUT:

Hi Bill
The Pnut does not start recording at T = 0 & Alt = 0.  After you turn it on and wait for the init procedure, it constantly samples pressure and fills several circular buffers.  One buffer records the last 32 altitude readings (MSL, or above sea level, not ground level) to provide pre-launch data.  The other buffer stores averages of the contents of the first buffer to track the ground elevation which can change due to weather variations if the rocket sits on the pad for an extended time.  The averaging also minimizes the impact of sensor drift and wind gusts.

The altimeter detects launch when the current altitude reading is 100 feet higher than the averaged ground elevation (this launch detect threshold is changeable from the download software, 100' is the default).  The program then copies the last 29 readings into the flight memory and continues sampling and recording data from that point.  So the bottom line is that you get about 1.4 seconds of data preceding the 100 foot altitude point, which will not necessarily mean that T=0 on the graph will be at altitude = 0.  If the rocket takes off quickly, you will have a number of altitude = 0 readings stored before the curve starts upward.  Similarly, if the rocket has a slow ascent, the T=0 altitude will be greater than 0.  With a 100 foot launch detect, as long as the rocket's average speed is above about 70 FPS you will be assured of getting data extending back to the liftoff point.

The above is just an explanation of the fact that T = 0 and altitude = 0 do not coincide (so we can record and display some pre-liftoff data), it has nothing to do with explaining your anomaly.

The second buffer averages the MSL readings from several seconds prior to the current point in time back to about 26 seconds prior to the current time.  The produces the stabilized ground elevation that the altimeter later uses to convert MSL readings to AGL (above ground level) readings.  Because the average is based on a "moving window" that is updated continuously, effects of sensor drift and weather variations are essentially eliminated.  Because it is an averaged value based on a large number of samples, noise due to wind gusts or other anomalies is also reduced.  If you just sampled the ground elevation once when the altimeter was turned on and the rocket sat on the pad for 30 minutes before launch (not uncommon...) then the sensor drift and weather issues could be quite large.  If you just take a single sample every so often to update the ground elevation (without averaging), then a wind gust at that particular point can shift the ground elevation significantly, potentially leading to false launch detect and large errors in the ground elevation.

As soon as the altimeter detects launch (altitude greater than 100 feet and T=1.4 seconds) the ground elevation averaged from the period 3 seconds earlier to 26 seconds earlier is "locked in" and is never subject to change.  The large ejection spike occurs well after that point, so it has nothing to do with the issue.

So something during the period of 3 seconds to 26 seconds prior to launch detect had an enormous impact on the ground elevation.  If it was a brief event, the magnitude would have to be huge to shift the average of nearly 450 samples by 65 feet.

Is it possible that sunlight entered the payload bay's vent holes (i.e. are any lined up in such a way that this could be possible)? If your Pnut is one with the newer stainless steel covered pressure sensor (U3 on the bottom of the unit) then one of the sensor's holes should be covered with a small black piece of tape.  If the tape has been dislodged, then the sensor will have a large degree of light sensitivity and a hit by direct sunlight could easily cause the issue you describe.  If you have the older sensor with a white plastic cover, light sensitivity is not a problem.

Can you email a sharp closeup of the bottom of the altimeter?

Also, the difference in magnitude of the ejection spike is easily explained by the fact that the spike is very brief (less than 1 sample in duration) and the Pnut samples at 20 samples per second vs. the MicroPeak 10 sample per second.  Unless the two devices were in perfect synchronization, they would be sampling different pressures due to the rapid change in pressure during the spike.

The paragraph highlighted in bold is what surprised me - a light-sensitive pressure sensor? I hauled out the PNUT and took a close look:

Bottom of PNUT altimeter (Click to enlarge).

Sure enough, there was no tape covering one of the holes (I have no idea which one is supposed to be covered). So that seems to be it - light entering the payload section and hitting the sensor caused ground level to be reset. Who would have thunk?

Perfectflite, being a class act, offer to repair and clean the altimeter if I return it to them, which I will do next week. Hard to turn down an offer like that. They also gave me a couple more tips, which I am posting below for those who may find them of use. Technical support (except for Apple Genius Bar) is good - a couple of emails yielded a plausible answer to my mystery.

Additional Perfectflite suggestions:

1) A large downward ejection spike is usually caused by ejection charge gas entering the payload bay because of insufficient sealing.  Since the gas is corrosive, this can cause degradation of the electronics.  Are there any holes or other possible leaks in the balsa coupler depicted in your drawing?  Or is the balsa that porous?

Bill's note - nope, there are no holes or leaks in the coupler, which is a nice 1.5" length cylinder of good quality balsa. Has a nick in the bottom after this flight, but still AOK) 

2) Your static ports don't need to be anywhere near as large as described on your drawing (four 1/8" holes).  Four pinholes made with a standard pin would be more than enough, and using a pin is fast & clean.  The smaller holes would also minimize sunlight effects and provide filtering of wind and turbulence for a smoother graph.