diff --git a/EXAMPLES.md b/EXAMPLES.md
index 195c885..d7173bf 100644
--- a/EXAMPLES.md
+++ b/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
+
+
+
+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:
+
+
+
+The same noisy signal can also look like this if a lowpass filter was applied:
+
+
+
+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
diff --git a/FAQ.md b/FAQ.md
index 6122c00..e76fae5 100644
--- a/FAQ.md
+++ b/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
diff --git a/INSTRUMENT.md b/INSTRUMENT.md
index 1c7df8c..ec4b633 100644
--- a/INSTRUMENT.md
+++ b/INSTRUMENT.md
@@ -7,9 +7,9 @@ As explained [in the README][], videojitter requires an _instrument_ to record
the physical light output of the display you are trying to measure.
You may already have hardware to do this, especially if you have access to a
-lab. Basically, if you have a way to capture the output of a [sufficiently
-fast][requirements] light sensor into a WAV file, you're already good to go and
-the rest of this document should be of no interest to you.
+lab. Basically, if you have a way to capture the output of a [sufficiently fast
+and noise-free][requirements] light sensor into a WAV file, you're already good
+to go and the rest of this document should be of no interest to you.
If, however, you are missing this crucial piece of equipment and are looking for
a solution, do read on…
@@ -19,14 +19,14 @@ a solution, do read on…
You can build an instrument by putting together the following parts:
- A suitable light sensor from an electronics store;
-- The microphone input jack of an audio interface (e.g. on a computer or a USB
- audio interface);
+- The input microphone/line-in jack of an audio interface (e.g. on a computer or
+ a USB audio interface);
- Some wires/adapter to make the sensor fit into the audio jack.
That's it. Really - it's as simple as that. You can get easily get away with
spending less than $30 on the above. In fact, if you already have a suitable
-microphone input (which is quite possible), you can probably get away with
-spending less than half that.
+audio input (which is likely), you can probably get away with spending less than
+half that.
As for tools, depending on the adapter you use, you may only need a
screwdriver - no soldering required.
@@ -34,92 +34,132 @@ screwdriver - no soldering required.
## Hold on, how could that possibly work?
The output of a light sensor is an analog signal which can be measured by any
-suitable [ADC][]. A microphone audio input is such an ADC, and its
-characteristics (sample rate and bit depth) are perfectly appropriate (overkill,
-even) for our needs. Conceptually, an audio input is really just a specialized
-oscilloscope… and the resulting signal can easily be saved into a WAV file for
+suitable [ADC][]. The inputs on an audio interface are ADCs, and their
+characteristics (sample rate, bit depth, max input voltage) are sufficient for
+our needs. Conceptually, such audio inputs are really just specialized
+oscilloscopes… and the resulting signal can easily be saved into a WAV file for
videojitter to consume.
-The other missing piece is a power supply, as most light sensors require some
-current to flow through them to operate. But here's the really neat part: a
-microphone input jack [is also a power supply][]! Indeed, some types of
-microphones require a DC voltage to operate; for this reason, most microphone
-inputs make a small amount of DC current available on the input pins, and that
-is enough to power a light sensor.
+This may seem difficult to believe, but yes, it does mean that if you naively
+shove a light sensor directly into an audio input, chances are it will just
+work!
-So: we can use the microphone input to power the light sensor _and_ read its
-output at the same time. We don't need anything else!
+That said, behind the scenes there are some subtleties related to DC bias
+voltage depending on the type of light sensor and ADC used. See the [appendix][]
+for details. Luckily, you don't need to care about this too much as most
+combinations will still work anyway.
## What about accuracy/performance?
-The quality of the instrument mostly comes down to the [speed of the light
-sensor used][requirements] and not much else.
+Even bad hardware choices will likely still result in a usable instrument that
+meets the [requirements][] reasonably well.
-To give an idea, videojitter was developed and tested using a [Panasonic AMS3][]
-which cost the author ~$2 (not a typo) in 2014. Its 10%-90% response time is
-rated at 8.5 milliseconds which is perfectly adequate for measurements up to 120
-FPS. In the right conditions, that $2 piece of kit has been observed to produce
-extremely clean measurements with transition time variance measured in
-double-digit *micro*seconds (again, not a typo).
+With carefully selected components (and perhaps a bit of trial and error), the
+instrument can be made essentially perfect for all intents and purposes. Note
+this doesn't necessarily mean a bigger budget. For example, 120 FPS measurements
+with frame timestamp standard deviations as low as 10-30 µs have been achieved
+with the [OSRAM SFH 213][osram-sfh213] photodiode connected to a cheap consumer
+audio interface (ASUS Xonar U3). Here's how much that photodiode costs: $0.85.
+No, that's not a typo. videojitter itself was developed and tested with similar
+hardware.
## Okay I'm sold, what do I need to do?
-### Step 1: acquire a suitable microphone input
+### Step 1: acquire a suitable audio input
You probably already have one. Most should work in theory, although it may be a
bit hit-and-miss in practice as these devices are obviously not designed for
this use case. An an example, videojitter was developed and tested using the
ASUS Xonar U3 shown in the pictures.
-If in doubt you can use a voltmeter on the microphone jack to check for the
-presence of DC voltage. Typically it's between 1-4 volts.
+Note that there may be significant differences in behavior depending on whether
+the input is labeled as a "line input" or "microphone input". Indeed there are
+electrical differences between the two types. That doesn't mean one is always
+preferred over the other - it depends on the situation. See the [appendix][] for
+details.
-
-
-**Note:** audio inputs marked as _line_ inputs are unlikely to work as these
-don't usually provide a DC voltage - you want an input specifically labelled as
-a microphone input.
+If you don't have a suitable input, look for an audio interface that provides
+one. You can usually just search for something like "USB audio" on Amazon and
+pick the cheapest result you can find. Even dirt-cheap, no-name garbage devices
+should work just fine and their specs will still be overkill for videojitter.
+USB interfaces as cheap as $10 have been shown to work.
-If you don't have a suitable microphone input, look for an audio interface that
-provides one. You can usually just search for something like "USB audio" on
-Amazon and pick the cheapest result you can find. Even dirt-cheap, no-name
-garbage devices should work just fine and their specs will still be overkill for
-videojitter. USB interfaces as cheap as $10 have been shown to work.
+If you have multiple inputs at your disposal, the best approach is to experiment
+and pick the one that provides the best results, i.e. the least [noise][] and
+the fastest [speed][].
### Step 2: acquire a suitable light sensor
-
-
-When it comes to light sensors, electronics shops such as [Conrad][] and
-[Mouser][] should provide plenty of options.
-
-Make sure the light sensor supply voltage range is compatible with the DC
-voltage supplied by the microphone input you want to use it with. Typically
-you'd want a light sensor that can work with a ~3 V supply or whereabouts.
-
-If you have multiple sensors to choose from, pick the fastest one. The spec
-sheet should tell you how fast the sensor is. For example:
-
-
+
+
+
+
+
+What we need is a light sensor or, more technically, a [photodetector][].
+Several kinds exist. For our purposes, the most suitable is a [photodiode][].
+Avoid [photoresistors][], which are too slow.
+
+(Note: this document was not written nor reviewed by anyone with a background in
+(opto)electronics. It could be that there are even better choices -
+phototransistors or Photo ICs perhaps - or better ways to decide between
+individual components. Suggestions on how to improve this document are more than
+welcome.)
+
+Photodiodes can be obtained from any electronics store, such as [Conrad][],
+[Mouser][], [DigiKey][], etc. Even [Amazon][] has some, but beware of fake
+clones.
+
+There are plenty of choices available, which can be a bit dizzying. Here are
+some specific models that have been verified to work for making videojitter
+recordings:
+
+| Manufacturer | Model | Performance (noise) | Notes |
+| ------------------ | ----------------------------------- | ------------------- | -------------------------------- |
+| Advanced Photonics | [PDB-C134][ap-pdbc134] | Fair | |
+| Kingbright | [WP7113PD1C][kingbright-wp7113pd1c] | Fair | |
+| Marktech | [MTD1114M3B][marktech-mtd1114m3b] | Bad | |
+| OSRAM | [BPW 34][osram-bpw34] | Good | |
+| OSRAM | [BPX 65][osram-bpx65] | Bad | |
+| OSRAM | [SFH 203][osram-sfh203] | Excellent | |
+| OSRAM | [SFH 206 K][osram-sfh206k] | Excellent | |
+| OSRAM | [SFH 213][osram-sfh213] | Excellent | Best measured performance so far |
+| Panasonic | [AMS302][panasonic-ams302] | Excellent | Discontinued; requires DC |
+| TT Electronics | [OP 905][tt-op905] | Fair | |
+| TT Electronics | [OP 906][tt-op906] | Fair | |
+| TT Electronics | [OP 950][tt-op950] | Bad | Good if not subjected to DC |
+| TT Electronics | [OP 954][tt-op954] | Bad | |
+| Vishay | [BPW20RF][vishay-bpw20rf] | Excellent | |
+| Vishay | [BPW24R][vishay-bpw24r] | Excellent | |
+| Vishay | [BPW34][vishay-bpw34] | Excellent | |
+| Vishay | [BPW46][vishay-bpw46] | Good | |
+| Vishay | [TEFD4300][vishay-tefd4300] | Fair | Excellent if not subjected to DC |
+
+The above table should only be used as a rough guide - the results may vary
+depending on the ADC used and the light levels being measured.
+
+If you pick a photodiode not on the above list, pay attention to the following
+characteristics:
+
+- **Spectral bandwidth:** many photodiodes are designed to be used as infrared
+ (IR) receivers, and will barely react to visible light.
+ - Check the photodiode specs; it should have at least some sensitivity in the
+ visible range (400-700 nm).
+ - If the photodiode is coated in black, it very likely means it is
+ infrared-only.
+- **Angle:** smaller angles are usually preferable as it makes the diode more
+ sensitive (less noisy) when pointed directly at the display. It also reduces
+ ambient light pickup.
+
+Note that photodiode datasheets often advertise obscenely fast switching times -
+microseconds, sometimes even nanoseconds. Keep in mind that these figures often
+[assume ideal conditions][] - which we are not going to approach here. That
+being said, even the slowest photodiode in the worst setup would likely be at
+least one order of magnitude faster than the fastest of displays. (The Panasonic
+AMS302 is a notable exception with its 8.5 ms response time, likely due to its
+internal amplifier.)
### Step 3: connect the light sensor to the microphone input receptacle
-Some types of light sensors are polarized, meaning the two leads are not
-interchangeable. In that case the sensor needs to be plugged in the right way
-around. This will be mentioned in the light sensor spec sheet. If the light
-sensor is non-polarized, it doesn't matter which way you plug it in.
-
-
-
-The way you connect the light sensor to the audio jack depends on which type of
-[jack][] you have:
-
-- **TS mono microphone jack**: connect the anode (-) to the sleeve and the
- cathode (+) to the tip.
-- **TRS stereo microphone jack:** connect the anode (-) to the sleeve and the
- cathode (+) to the tip (left channel) or ring (right channel).
-- **TRRS combined headphone and microphone jack:** [varies][]
-
The most straightforward way to make the connection is to use an audio jack to
[screw terminal block][] adapter, which can be obtained for a few bucks on e.g.
Amazon:
@@ -135,6 +175,14 @@ nothing else than a screwdriver - no soldering required.
Of course, you can also go for a cleaner, more permanent solution using a
properly soldered jack plug if you so desire.
+Photodiodes are polarized, meaning the two leads are not interchangeable. The
+"correct" way to plug in a photodiode is a surprisingly subtle question.
+Depending on the characteristics of the audio input used, sometimes both ways
+will work equally well, sometimes one way works much better than the other, and
+sometimes only one way works at all. The easiest way to solve this conundrum is
+to simply try it both ways and compare the results. For more details, see the
+[appendix][].
+
### Step 4: testing
After putting all the pieces together, you can use any audio recording software
@@ -155,20 +203,143 @@ example:
+Note that, in many setups, the signal level will be much lower, requiring you to
+zoom in vertically to find the signal.
+
That's it! You now have an instrument that can be used to make videojitter
measurements. Read the [instructions][] to find out how.
+## Appendix: polarity, DC bias, forward voltage, reverse voltage, photovoltatic mode, photoconductive mode, oh my!
+
+Somewhat intruigingly, despite being a polarized component, current can flow
+both ways in a photodiode - but the resulting behavior is quite different. This
+makes the question "which way should I plug my photodiode" surprisingly
+complicated.
+
+- In the simplest case, the photodiode can generate its own current, by
+ converting light into electricity. This is called **photovoltaic mode**, in
+ which the photodiode creates a **forward voltage**, so called because current
+ flows from the cathode (-) to the anode (+).
+- However, the photodiode can also be subjected to a **reverse voltage**, where
+ the cathode is connected to the positive side of a power supply, and the anode
+ to the negative side. This is called **photoconductive mode**. In that case,
+ the photodiode basically acts as a light-sensitive resistor, and will let
+ current pass through if subjected to light.
+
+videojitter recordings can be made in both modes, but performance (noise and
+speed) may differ.
+
+### Which mode am I using?
+
+A standard "line in" audio input basically acts as a voltmeter or oscilloscope -
+it only senses voltage, it does not supply power. Connecting a photodiode to
+such an input will necessarily put it in photovoltaic mode. In this case it does
+not matter which way the photodiode is plugged in, because analog audio inputs
+are symmetric around zero volts and will measure negative and positive voltages
+equally well. This is the simple case.
+
+Things get way more interesting if you use a typical "microphone" audio input.
+This is because, somewhat shockingly, a microphone input [is also a power
+supply][]! Indeed, some types of microphones require a DC voltage to operate;
+for this reason, most microphone inputs make a small amount of DC current
+available on the input pins. The unloaded DC voltage varies, but it's typically
+between 1 and 4 volts.
+
+
+
+This means that, depending on the way you plug a photodiode into a microphone
+audio input, you could end up impressing a forward voltage or a reverse voltage
+upon it. If you go for the latter (which is preferable - see next section), you
+will end up using the photodiode in photoconductive mode.
+
+To use a photodiode in the recommended reverse mode, connect its anode (+) to
+the ground of the microphone input (i.e. the "sleeve" of the [jack][]). The
+anode is usually the "marked" side; the cathode is the shorter lead. If in
+doubt, refer to the spec sheet, or directly measure the photovoltaic forward
+voltage using a voltmeter. Or, even simpler, just try it both ways and use the
+direction that produces the best recordings.
+
+### What difference does it make?
+
+Performance may differ depending on which mode is used:
+
+- **Photovoltaic mode with no DC bias** ("line in" case)
+ - Typically provides the best noise performance.
+ - Theoretically slower but the difference in speed doesn't seem noticeable in
+ practice.
+ - All photodiodes would be expected to give good results in this mode.
+- **Photovoltaic mode with a DC bias** ("microphone in" case, forward polarity)
+ - In this direction, the DC current passes straight through the photodiode,
+ which acts as a wire.
+ - Usually the worst performing mode by far, presumably because the DC current
+ interacts badly with the signal from the photodiode itself.
+ - This mode typically produces [extremely noisy][noise], barely usable
+ results. In many cases videojitter is not even able to recover any signal
+ from the noise.
+- **Photoconductive mode with a DC bias** ("microphone in" case, reverse
+ polarity)
+ - Typically provides somewhat reasonable performance, but somewhat worse than
+ photovoltaic mode. By how much depends on the specific hardware used.
+ - Photodiodes with a good rating in the [table above][] would be expected to
+ give good results in this mode.
+
+In photovoltaic mode, the response of the photodiode is logarithmic with respect
+to light level, but in photoconductive mode it is linear. For this reason, the
+shape of the waveform itself can be quite different between the two modes -
+don't be surprised! videojitter won't care, though.
+
+[appendix]:
+ #appendix-polarity-dc-bias-forward-voltage-reverse-voltage-photovoltatic-mode-photoconductive-mode-oh-my
[ADC]: https://en.wikipedia.org/wiki/Analog-to-digital_converter
+[Amazon]: https://www.amazon.com/s?k=photodiode
+[ap-pdbc134]:
+ https://www.advancedphotonix.com/wp-content/uploads/2022/04/DS-PDB-C134-1.pdf
+[assume ideal conditions]: https://www.vishay.com/docs/48454/48454.pdf
[Audacity]: https://www.audacityteam.org/
[is also a power supply]:
https://en.wikipedia.org/wiki/Phone_connector_(audio)#/media/File:Jackplug-wiring.svg
[jack]: https://en.wikipedia.org/wiki/Phone_connector_(audio)
-[Conrad]: https://www.conrad.com/
-[Mouser]: https://www.mouser.co.uk/
+[Conrad]: https://www.conrad.com/en/o/photodiodes-5204104.html
+[DigiKey]:
+ https://www.digikey.com/en/products/filter/optical-sensors/photodiodes/543
+[Mouser]:
+ https://www.mouser.co.uk/c/optoelectronics/optical-detectors-sensors/photodiodes/
+[noise]: EXAMPLES.md#recording-noise
[in the README]: README.md#getting-an-instrument
[instructions]: README.md#how-do-i-use-it
-[Panasonic AMS3]:
+[kingbright-wp7113pd1c]:
+ https://www.mouser.com/datasheet/2/216/WP7113PD1C-1388741.pdf
+[marktech-mtd1114m3b]:
+ https://marktechopto.com/pdf/products/datasheet/MTD1114M3B.pdf
+[osram-bpw34]:
+ https://ams-osram.com/products/photodetectors/photodiodes/osram-dil-bpw-34
+[osram-bpx65]:
+ https://ams-osram.com/products/photodetectors/photodiodes/osram-metal-can-to18-bpx-65
+[osram-sfh203]:
+ https://ams-osram.com/products/photodetectors/photodiodes/osram-radial-t1-34-sfh-203
+[osram-sfh206k]:
+ https://ams-osram.com/products/photodetectors/photodiodes/osram-radial-sidelooker-sfh-206-k
+[osram-sfh213]:
+ https://ams-osram.com/products/photodetectors/photodiodes/osram-radial-t1-34-sfh-213
+[panasonic-ams302]:
https://industrial.panasonic.com/cdbs/www-data/pdf/ADD8000/ADD8000C6.pdf
+[photodetector]: https://en.wikipedia.org/wiki/Photodetector
+[photodiode]: https://en.wikipedia.org/wiki/Photodiode
+[photoresistors]: https://en.wikipedia.org/wiki/Photoresistor
[requirements]: README.md#requirements-on-the-instrument
[screw terminal block]: https://en.wikipedia.org/wiki/Screw_terminal_block
-[varies]: https://en.wikipedia.org/wiki/Phone_connector_(audio)#TRRS_standards
+[speed]: EXAMPLES.md#artefacts-caused-by-overly-slow-displayinstrument
+[table above]: #step-2-acquire-a-suitable-light-sensor
+[tt-op905]:
+ https://www.ttelectronics.com/Products/Sensors/Optoelectronics/Components/OP905
+[tt-op906]:
+ https://www.ttelectronics.com/Products/Sensors/Optoelectronics/Components/OP906
+[tt-op950]:
+ https://www.ttelectronics.com/Products/Sensors/Optoelectronics/Components/OP950
+[tt-op954]:
+ https://www.ttelectronics.com/Products/Sensors/Optoelectronics/Components/OP954
+[vishay-bpw20rf]: https://www.vishay.com/en/product/81570/
+[vishay-bpw24r]: https://www.vishay.com/en/product/81520/
+[vishay-bpw34]: https://www.vishay.com/en/product/81521/
+[vishay-bpw46]: https://www.vishay.com/en/product/81524/
+[vishay-tefd4300]: https://www.vishay.com/en/product/83471/
diff --git a/README.md b/README.md
index 97a4676..ba0861f 100644
--- a/README.md
+++ b/README.md
@@ -85,8 +85,8 @@ time and write the resulting signal to a WAV file for videojitter to consume. In
videojitter terminology, this light recording device is called the _instrument_.
If you have access to a lab, you may already have hardware to do this - for
-example, you may already have a suitable light sensor, a power supply, and an
-oscilloscope that can export WAV files. In that case, great! You're good to go.
+example, you may already have a suitable photodiode and an oscilloscope that can
+export WAV files. In that case, great! You're good to go.
Otherwise, you will need to obtain the hardware or build it yourself. But don't
let that scare you! Building your own instrument is much simpler than you may
@@ -95,8 +95,27 @@ that can be assembled in minutes. Read [this guide][] to find out how.
#### Requirements on the instrument
-The most important performance metric for the instrument is its _speed_, i.e.
-how quickly it reacts to changes in light level.
+When it comes to instrument performance, there are two aspects to consider:
+noise and speed. Other properties of the instrument, such as sampling rate, are
+usually not the bottleneck as even dirt-cheap solutions typically have tons of
+margin there.
+
+##### Noise
+
+The signal captured by the instrument is necessarily contaminated by some amount
+of random background noise. Noise makes it harder for videojitter to determine
+the precise time at which a transition occurred. This results in random
+variations in the reported transition timestamps.
+
+The best instruments will allow videojitter to produce transition timestamps
+with reported standard deviations of less than 50 microseconds. Standard
+deviations above 500 microseconds will make videojitter charts hard to read
+because noise-induced deviations will be hard to distinguish from the real ones.
+
+##### Speed
+
+Instruments do not react to light changes immediately; they have some built-in
+inertia that results in changes in the light waveform being "smeared" in time.
As a rule of thumb, for good results, the instrument should be at least as fast
as the minimum frame duration you are looking to measure. So, for example, the
@@ -105,15 +124,15 @@ as the minimum frame duration you are looking to measure. So, for example, the
that sensor will start to show its limits around 120 frames per second or so. It
is perfectly adequate for measuring typical 24 FPS video.
-Even if the instrument is too slow, videojitter will likely still be able to
-provide somewhat usable results - typically the only real problem is a loss of
-precision which gets worse around sudden frame duration changes. Note that such
-measurement artifacts can also be caused by the display itself being too slow to
-refresh - they are not necessarily the instrument's fault.
+In practice, typical photodiode-based instruments are expected to be much faster
+than even the fastest displays, making speed a non-issue. On the other hand,
+photoresistors are usually too slow to be usable.
-Other properties of the instrument include sampling rate and signal to noise
-ratio (SNR). These are usually not the bottleneck as even dirt-cheap instruments
-typically have tons of margin there.
+Even if the instrument is somewhat slow, videojitter will likely still be able
+to provide somewhat usable results - typically the only real problem is a loss
+of precision which gets worse around sudden frame duration changes. Note that
+such measurement artifacts can also be caused by the display itself being too
+slow to refresh - they are not necessarily the instrument's fault.
### Step 1: install videojitter
@@ -175,7 +194,8 @@ from the display apart from ambient light.
Connect your instrument and point it towards the display of the video playback
system under test. It is best to place the instrument some distance away from
the display so that the blinking squares of the warmup/cooldown pattern (more on
-that later) can be distinguished from the actual test signal.
+that later) can be distinguished from the actual test signal. Don't place it too
+far away though, as the signal-to-noise ratio will suffer.
Set up your instrument and hit the start button in whatever software you are
using to record the data (e.g. Audacity). There is no need to precisely
@@ -227,8 +247,15 @@ waveform, you can use [Audacity][].
In particular you'd want to check that the test signal is actually present - it
should be visually obvious from the waveform where the test signal begins and
-ends. In this example the test signal starts at around 25 seconds into the
-recording and ends 60 seconds later:
+ends. Note, though, that some instruments can produce very weak signals, which
+may require you to zoom in vertically. You may be able to increase the strength
+of the signal by making the display brighter or bringing the instrument closer
+(but not so close as to get videojitter confused about the warmup/cooldown
+patterns). Increasing the gain of the instrument may or may not improve things,
+depending on whether background noise gets amplified as well.
+
+In this example the test signal starts at around 25 seconds into the recording
+and ends 60 seconds later:
diff --git a/img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png b/img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png
new file mode 100644
index 0000000..5f46db5
Binary files /dev/null and b/img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png differ
diff --git a/img/lg_119p_inst_osram_bpw34_u3f-noise.png b/img/lg_119p_inst_osram_bpw34_u3f-noise.png
new file mode 100644
index 0000000..187b21e
Binary files /dev/null and b/img/lg_119p_inst_osram_bpw34_u3f-noise.png differ
diff --git a/img/osram-bpw34.png b/img/osram-bpw34.png
new file mode 100644
index 0000000..ed2f6e0
Binary files /dev/null and b/img/osram-bpw34.png differ
diff --git a/img/osram-sfh213.png b/img/osram-sfh213.png
new file mode 100644
index 0000000..b362e00
Binary files /dev/null and b/img/osram-sfh213.png differ
diff --git a/img/panasonic-ams3-cad.png b/img/panasonic-ams3-cad.png
deleted file mode 100644
index 106a6b7..0000000
Binary files a/img/panasonic-ams3-cad.png and /dev/null differ
diff --git a/img/panasonic-ams3-specs.png b/img/panasonic-ams3-specs.png
deleted file mode 100644
index 41ff2c9..0000000
Binary files a/img/panasonic-ams3-specs.png and /dev/null differ
diff --git a/img/vishay-bpw20rf.png b/img/vishay-bpw20rf.png
new file mode 100644
index 0000000..9c00e97
Binary files /dev/null and b/img/vishay-bpw20rf.png differ
diff --git a/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore
index 071998d..f77ffd3 100644
--- a/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore
+++ b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore
@@ -2,3 +2,6 @@
!/test_output/*.stdout
!/test_output/report.csv
!/test_output/report.json
+
+# Used in docs
+!/test_output/report.svg
diff --git a/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg
new file mode 100644
index 0000000..366502e
--- /dev/null
+++ b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg
@@ -0,0 +1,954 @@
+
\ No newline at end of file
+
+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:
+
+
+
+The same noisy signal can also look like this if a lowpass filter was applied:
+
+
+
+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
diff --git a/FAQ.md b/FAQ.md
index 6122c00..e76fae5 100644
--- a/FAQ.md
+++ b/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
diff --git a/INSTRUMENT.md b/INSTRUMENT.md
index 1c7df8c..ec4b633 100644
--- a/INSTRUMENT.md
+++ b/INSTRUMENT.md
@@ -7,9 +7,9 @@ As explained [in the README][], videojitter requires an _instrument_ to record
the physical light output of the display you are trying to measure.
You may already have hardware to do this, especially if you have access to a
-lab. Basically, if you have a way to capture the output of a [sufficiently
-fast][requirements] light sensor into a WAV file, you're already good to go and
-the rest of this document should be of no interest to you.
+lab. Basically, if you have a way to capture the output of a [sufficiently fast
+and noise-free][requirements] light sensor into a WAV file, you're already good
+to go and the rest of this document should be of no interest to you.
If, however, you are missing this crucial piece of equipment and are looking for
a solution, do read on…
@@ -19,14 +19,14 @@ a solution, do read on…
You can build an instrument by putting together the following parts:
- A suitable light sensor from an electronics store;
-- The microphone input jack of an audio interface (e.g. on a computer or a USB
- audio interface);
+- The input microphone/line-in jack of an audio interface (e.g. on a computer or
+ a USB audio interface);
- Some wires/adapter to make the sensor fit into the audio jack.
That's it. Really - it's as simple as that. You can get easily get away with
spending less than $30 on the above. In fact, if you already have a suitable
-microphone input (which is quite possible), you can probably get away with
-spending less than half that.
+audio input (which is likely), you can probably get away with spending less than
+half that.
As for tools, depending on the adapter you use, you may only need a
screwdriver - no soldering required.
@@ -34,92 +34,132 @@ screwdriver - no soldering required.
## Hold on, how could that possibly work?
The output of a light sensor is an analog signal which can be measured by any
-suitable [ADC][]. A microphone audio input is such an ADC, and its
-characteristics (sample rate and bit depth) are perfectly appropriate (overkill,
-even) for our needs. Conceptually, an audio input is really just a specialized
-oscilloscope… and the resulting signal can easily be saved into a WAV file for
+suitable [ADC][]. The inputs on an audio interface are ADCs, and their
+characteristics (sample rate, bit depth, max input voltage) are sufficient for
+our needs. Conceptually, such audio inputs are really just specialized
+oscilloscopes… and the resulting signal can easily be saved into a WAV file for
videojitter to consume.
-The other missing piece is a power supply, as most light sensors require some
-current to flow through them to operate. But here's the really neat part: a
-microphone input jack [is also a power supply][]! Indeed, some types of
-microphones require a DC voltage to operate; for this reason, most microphone
-inputs make a small amount of DC current available on the input pins, and that
-is enough to power a light sensor.
+This may seem difficult to believe, but yes, it does mean that if you naively
+shove a light sensor directly into an audio input, chances are it will just
+work!
-So: we can use the microphone input to power the light sensor _and_ read its
-output at the same time. We don't need anything else!
+That said, behind the scenes there are some subtleties related to DC bias
+voltage depending on the type of light sensor and ADC used. See the [appendix][]
+for details. Luckily, you don't need to care about this too much as most
+combinations will still work anyway.
## What about accuracy/performance?
-The quality of the instrument mostly comes down to the [speed of the light
-sensor used][requirements] and not much else.
+Even bad hardware choices will likely still result in a usable instrument that
+meets the [requirements][] reasonably well.
-To give an idea, videojitter was developed and tested using a [Panasonic AMS3][]
-which cost the author ~$2 (not a typo) in 2014. Its 10%-90% response time is
-rated at 8.5 milliseconds which is perfectly adequate for measurements up to 120
-FPS. In the right conditions, that $2 piece of kit has been observed to produce
-extremely clean measurements with transition time variance measured in
-double-digit *micro*seconds (again, not a typo).
+With carefully selected components (and perhaps a bit of trial and error), the
+instrument can be made essentially perfect for all intents and purposes. Note
+this doesn't necessarily mean a bigger budget. For example, 120 FPS measurements
+with frame timestamp standard deviations as low as 10-30 µs have been achieved
+with the [OSRAM SFH 213][osram-sfh213] photodiode connected to a cheap consumer
+audio interface (ASUS Xonar U3). Here's how much that photodiode costs: $0.85.
+No, that's not a typo. videojitter itself was developed and tested with similar
+hardware.
## Okay I'm sold, what do I need to do?
-### Step 1: acquire a suitable microphone input
+### Step 1: acquire a suitable audio input
You probably already have one. Most should work in theory, although it may be a
bit hit-and-miss in practice as these devices are obviously not designed for
this use case. An an example, videojitter was developed and tested using the
ASUS Xonar U3 shown in the pictures.
-If in doubt you can use a voltmeter on the microphone jack to check for the
-presence of DC voltage. Typically it's between 1-4 volts.
+Note that there may be significant differences in behavior depending on whether
+the input is labeled as a "line input" or "microphone input". Indeed there are
+electrical differences between the two types. That doesn't mean one is always
+preferred over the other - it depends on the situation. See the [appendix][] for
+details.
-
-
-**Note:** audio inputs marked as _line_ inputs are unlikely to work as these
-don't usually provide a DC voltage - you want an input specifically labelled as
-a microphone input.
+If you don't have a suitable input, look for an audio interface that provides
+one. You can usually just search for something like "USB audio" on Amazon and
+pick the cheapest result you can find. Even dirt-cheap, no-name garbage devices
+should work just fine and their specs will still be overkill for videojitter.
+USB interfaces as cheap as $10 have been shown to work.
-If you don't have a suitable microphone input, look for an audio interface that
-provides one. You can usually just search for something like "USB audio" on
-Amazon and pick the cheapest result you can find. Even dirt-cheap, no-name
-garbage devices should work just fine and their specs will still be overkill for
-videojitter. USB interfaces as cheap as $10 have been shown to work.
+If you have multiple inputs at your disposal, the best approach is to experiment
+and pick the one that provides the best results, i.e. the least [noise][] and
+the fastest [speed][].
### Step 2: acquire a suitable light sensor
-
-
-When it comes to light sensors, electronics shops such as [Conrad][] and
-[Mouser][] should provide plenty of options.
-
-Make sure the light sensor supply voltage range is compatible with the DC
-voltage supplied by the microphone input you want to use it with. Typically
-you'd want a light sensor that can work with a ~3 V supply or whereabouts.
-
-If you have multiple sensors to choose from, pick the fastest one. The spec
-sheet should tell you how fast the sensor is. For example:
-
-
+
+
+
+
+What we need is a light sensor or, more technically, a [photodetector][].
+Several kinds exist. For our purposes, the most suitable is a [photodiode][].
+Avoid [photoresistors][], which are too slow.
+
+(Note: this document was not written nor reviewed by anyone with a background in
+(opto)electronics. It could be that there are even better choices -
+phototransistors or Photo ICs perhaps - or better ways to decide between
+individual components. Suggestions on how to improve this document are more than
+welcome.)
+
+Photodiodes can be obtained from any electronics store, such as [Conrad][],
+[Mouser][], [DigiKey][], etc. Even [Amazon][] has some, but beware of fake
+clones.
+
+There are plenty of choices available, which can be a bit dizzying. Here are
+some specific models that have been verified to work for making videojitter
+recordings:
+
+| Manufacturer | Model | Performance (noise) | Notes |
+| ------------------ | ----------------------------------- | ------------------- | -------------------------------- |
+| Advanced Photonics | [PDB-C134][ap-pdbc134] | Fair | |
+| Kingbright | [WP7113PD1C][kingbright-wp7113pd1c] | Fair | |
+| Marktech | [MTD1114M3B][marktech-mtd1114m3b] | Bad | |
+| OSRAM | [BPW 34][osram-bpw34] | Good | |
+| OSRAM | [BPX 65][osram-bpx65] | Bad | |
+| OSRAM | [SFH 203][osram-sfh203] | Excellent | |
+| OSRAM | [SFH 206 K][osram-sfh206k] | Excellent | |
+| OSRAM | [SFH 213][osram-sfh213] | Excellent | Best measured performance so far |
+| Panasonic | [AMS302][panasonic-ams302] | Excellent | Discontinued; requires DC |
+| TT Electronics | [OP 905][tt-op905] | Fair | |
+| TT Electronics | [OP 906][tt-op906] | Fair | |
+| TT Electronics | [OP 950][tt-op950] | Bad | Good if not subjected to DC |
+| TT Electronics | [OP 954][tt-op954] | Bad | |
+| Vishay | [BPW20RF][vishay-bpw20rf] | Excellent | |
+| Vishay | [BPW24R][vishay-bpw24r] | Excellent | |
+| Vishay | [BPW34][vishay-bpw34] | Excellent | |
+| Vishay | [BPW46][vishay-bpw46] | Good | |
+| Vishay | [TEFD4300][vishay-tefd4300] | Fair | Excellent if not subjected to DC |
+
+The above table should only be used as a rough guide - the results may vary
+depending on the ADC used and the light levels being measured.
+
+If you pick a photodiode not on the above list, pay attention to the following
+characteristics:
+
+- **Spectral bandwidth:** many photodiodes are designed to be used as infrared
+ (IR) receivers, and will barely react to visible light.
+ - Check the photodiode specs; it should have at least some sensitivity in the
+ visible range (400-700 nm).
+ - If the photodiode is coated in black, it very likely means it is
+ infrared-only.
+- **Angle:** smaller angles are usually preferable as it makes the diode more
+ sensitive (less noisy) when pointed directly at the display. It also reduces
+ ambient light pickup.
+
+Note that photodiode datasheets often advertise obscenely fast switching times -
+microseconds, sometimes even nanoseconds. Keep in mind that these figures often
+[assume ideal conditions][] - which we are not going to approach here. That
+being said, even the slowest photodiode in the worst setup would likely be at
+least one order of magnitude faster than the fastest of displays. (The Panasonic
+AMS302 is a notable exception with its 8.5 ms response time, likely due to its
+internal amplifier.)
### Step 3: connect the light sensor to the microphone input receptacle
-Some types of light sensors are polarized, meaning the two leads are not
-interchangeable. In that case the sensor needs to be plugged in the right way
-around. This will be mentioned in the light sensor spec sheet. If the light
-sensor is non-polarized, it doesn't matter which way you plug it in.
-
-
-
-The way you connect the light sensor to the audio jack depends on which type of
-[jack][] you have:
-
-- **TS mono microphone jack**: connect the anode (-) to the sleeve and the
- cathode (+) to the tip.
-- **TRS stereo microphone jack:** connect the anode (-) to the sleeve and the
- cathode (+) to the tip (left channel) or ring (right channel).
-- **TRRS combined headphone and microphone jack:** [varies][]
-
The most straightforward way to make the connection is to use an audio jack to
[screw terminal block][] adapter, which can be obtained for a few bucks on e.g.
Amazon:
@@ -135,6 +175,14 @@ nothing else than a screwdriver - no soldering required.
Of course, you can also go for a cleaner, more permanent solution using a
properly soldered jack plug if you so desire.
+Photodiodes are polarized, meaning the two leads are not interchangeable. The
+"correct" way to plug in a photodiode is a surprisingly subtle question.
+Depending on the characteristics of the audio input used, sometimes both ways
+will work equally well, sometimes one way works much better than the other, and
+sometimes only one way works at all. The easiest way to solve this conundrum is
+to simply try it both ways and compare the results. For more details, see the
+[appendix][].
+
### Step 4: testing
After putting all the pieces together, you can use any audio recording software
@@ -155,20 +203,143 @@ example:
+Note that, in many setups, the signal level will be much lower, requiring you to
+zoom in vertically to find the signal.
+
That's it! You now have an instrument that can be used to make videojitter
measurements. Read the [instructions][] to find out how.
+## Appendix: polarity, DC bias, forward voltage, reverse voltage, photovoltatic mode, photoconductive mode, oh my!
+
+Somewhat intruigingly, despite being a polarized component, current can flow
+both ways in a photodiode - but the resulting behavior is quite different. This
+makes the question "which way should I plug my photodiode" surprisingly
+complicated.
+
+- In the simplest case, the photodiode can generate its own current, by
+ converting light into electricity. This is called **photovoltaic mode**, in
+ which the photodiode creates a **forward voltage**, so called because current
+ flows from the cathode (-) to the anode (+).
+- However, the photodiode can also be subjected to a **reverse voltage**, where
+ the cathode is connected to the positive side of a power supply, and the anode
+ to the negative side. This is called **photoconductive mode**. In that case,
+ the photodiode basically acts as a light-sensitive resistor, and will let
+ current pass through if subjected to light.
+
+videojitter recordings can be made in both modes, but performance (noise and
+speed) may differ.
+
+### Which mode am I using?
+
+A standard "line in" audio input basically acts as a voltmeter or oscilloscope -
+it only senses voltage, it does not supply power. Connecting a photodiode to
+such an input will necessarily put it in photovoltaic mode. In this case it does
+not matter which way the photodiode is plugged in, because analog audio inputs
+are symmetric around zero volts and will measure negative and positive voltages
+equally well. This is the simple case.
+
+Things get way more interesting if you use a typical "microphone" audio input.
+This is because, somewhat shockingly, a microphone input [is also a power
+supply][]! Indeed, some types of microphones require a DC voltage to operate;
+for this reason, most microphone inputs make a small amount of DC current
+available on the input pins. The unloaded DC voltage varies, but it's typically
+between 1 and 4 volts.
+
+
diff --git a/img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png b/img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png
new file mode 100644
index 0000000..5f46db5
Binary files /dev/null and b/img/lg_119p_inst_osram_bpw34_u3f-noise-lowpass.png differ
diff --git a/img/lg_119p_inst_osram_bpw34_u3f-noise.png b/img/lg_119p_inst_osram_bpw34_u3f-noise.png
new file mode 100644
index 0000000..187b21e
Binary files /dev/null and b/img/lg_119p_inst_osram_bpw34_u3f-noise.png differ
diff --git a/img/osram-bpw34.png b/img/osram-bpw34.png
new file mode 100644
index 0000000..ed2f6e0
Binary files /dev/null and b/img/osram-bpw34.png differ
diff --git a/img/osram-sfh213.png b/img/osram-sfh213.png
new file mode 100644
index 0000000..b362e00
Binary files /dev/null and b/img/osram-sfh213.png differ
diff --git a/img/panasonic-ams3-cad.png b/img/panasonic-ams3-cad.png
deleted file mode 100644
index 106a6b7..0000000
Binary files a/img/panasonic-ams3-cad.png and /dev/null differ
diff --git a/img/panasonic-ams3-specs.png b/img/panasonic-ams3-specs.png
deleted file mode 100644
index 41ff2c9..0000000
Binary files a/img/panasonic-ams3-specs.png and /dev/null differ
diff --git a/img/vishay-bpw20rf.png b/img/vishay-bpw20rf.png
new file mode 100644
index 0000000..9c00e97
Binary files /dev/null and b/img/vishay-bpw20rf.png differ
diff --git a/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore
index 071998d..f77ffd3 100644
--- a/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore
+++ b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/.gitignore
@@ -2,3 +2,6 @@
!/test_output/*.stdout
!/test_output/report.csv
!/test_output/report.json
+
+# Used in docs
+!/test_output/report.svg
diff --git a/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg
new file mode 100644
index 0000000..366502e
--- /dev/null
+++ b/videojitter_test/cases/lg_119p_inst_osram_bpw34_u3f/test_output/report.svg
@@ -0,0 +1,954 @@
+
\ No newline at end of file