WIP Update docs with photodiode findings

EXAMPLES.md

@@ -7,7 +7,8 @@ patterns that sometimes appear in practical measurements.
 
 All measurements shown here have been made using a cheap homemade instrument,
 specifically a Panasonic AMS3 light sensor feeding an ASUS Xonar U3 used as an
-ADC. You can [build a similar instrument for yourself][] in minutes.
+ADC (unless otherwise noted). You can [build a similar instrument for
+yourself][] in minutes.
 
 ## Perfect result
 
@@ -25,7 +26,8 @@ entire test signal with no outliers - no late nor early frames.
 This example also demonstrates the ability of both the playback and measurement
 system to handle very high FPS - much higher than typical video content - as
 well as their amazing timing accuracy, which as described in the "fine print"
-(the text below the chart) is in the order of 10 µs (yes, _microseconds_).
+(the text below the chart) is in the order of 10 µs (yes, _microseconds_). This
+indicates the recording is virtually noise-free.
 
 If you get this kind of result, your playback system is pretty much flawless as
 far as frame presentation timing is concerned.
@@ -172,6 +174,45 @@ This example demonstrates that, even when the system under test is badly
 misbehaving, videojitter can still make sense of the data and produces reports
 that accurately reflects what went right and what went wrong.
 
+## Recording noise
+
+<img src="videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg">
+
+The above result was obtained by playing a 120/1.001 FPS video on on the
+built-in player of an LG G1 OLED TV. Importantly, the recording was made using
+an instrument with especially bad noise performance: an
+[OSRAM BPW 34](https://ams-osram.com/products/photodetectors/photodiodes/osram-dil-bpw-34)
+connected to the microphone jack of an Asus Xonar U7 with the DC bias voltage
+applied in the forward mode, instead of the more suitable reverse mode.
+
+Recording noise creates random variations in measured frame timestamps with no
+discernible discrete steps nor patterns. On the chart this manifests as points
+forming "fuzzy lines" instead of clean, neat alignments.
+
+The "standard deviation" estimate in the fine print (the text below the chart)
+makes it possible to quantify the noise. In the above example, the standard
+deviation is about 850 µs which is very high. Good recordings made with high
+performance instruments will show a standard deviation of less than 50 µs. Note
+that this metric is only meaningful if the playback system being measured is
+well-behaved (no variations in frame timestamps).
+
+In extreme cases, the noise will be so high as to make the chart unreadable.
+
+This issue can be examined further by looking at the raw waveform, where the
+noise should be visually obvious. Here is an example from the above measurement:
+
+<img src="img/lg_119p_inst_osram_bpw34_u3f-noise.png">
+
+The same noisy signal can also look like this if a lowpass filter was applied:
+
+<img src="img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png">
+
+In theory, it is conceivable that the noise could be caused not by the
+instrument, but by the playback system under test. This would suggest extreme
+levels of random jitter in the playback display clock, which is unlikely, but
+not impossible. In that case the waveform would be expected to look "clean",
+contrary to the above.
+
 ## Artefacts caused by overly slow display/instrument
 
 <img src="videojitter_test/cases/asuswmp_240p_at_240hz/test_output/report.svg">

FAQ.md

@@ -23,6 +23,16 @@ harder and may lead to loss of precision or nonsensical results:
     suffer.
   - If the recording level is set too high, or the instrument is saturated by
     excessive light levels, clipping may occur.
+- **Instrument noise**.
+  - Completely random frame time variations around frame times, with no visible
+    discrete steps nor patterns, are often caused by random background noise in
+    the recording.
+  - This takes the form of "fuzzy lines" on videojitter charts. See this
+    [example][noise].
+  - Signal-to-noise ratio can sometimes be improved by increasing display
+    brightness, moving the instrument closer to the display, or increasing
+    instrument gain.
+  - Better instruments will produce less noise.
 - Video playback systems that exhibit **[tearing][]** or make use of **"frame
   blending", "[motion interpolation][]"** or [similar techniques][].
   - These make it impossible to tell when original video frames begin and end,
@@ -61,7 +71,8 @@ harder and may lead to loss of precision or nonsensical results:
     because the shape of "truncated" transitions is different from the shape of
     a "full" transition.
   - Ideally your instrument should settle faster than the frame duration you are
-    trying to measure.
+    trying to measure. Most photodiode-based instruments should be more than
+    fast enough.
   - Even if your instrument is fast enough, at high enough frame rates, the
     display itself may be the bottleneck - consider that many LCD panels may
     struggle to fully transition between black and white in less than a few
@@ -265,6 +276,7 @@ with.
 [motion blur reduction techniques]:
   https://tftcentral.co.uk/articles/motion_blur
 [motion interpolation]: https://en.wikipedia.org/wiki/Motion_interpolation
+[noise]: EXAMPLES.md#recording-noise
 [incorrectly locate the delayed transition]:
   EXAMPLES.md#artefacts-caused-by-overly-slow-displayinstrument
 [PWM backlights]: https://tftcentral.co.uk/articles/pulse_width_modulation