← Seeing Monitor product page & download

The seeing monitor points at Polaris continuously and estimates atmospheric seeing from how much the star's image jitters from frame to frame.

How It Works

Measuring image motion (the "SIMM" technique)

Rather than a traditional Differential Image Motion Monitor (DIMM), which needs a dual-aperture mask and a moving telescope, this project uses a Single Image Motion Monitor (SIMM) approach: a fixed camera stares continuously at Polaris, and the software finds the star's sub-pixel centroid position in each of 256 short (~0.01s) exposures — about one minute per cycle. Very short exposures "freeze" the atmosphere in each frame, so what moves from frame to frame is the star's apparent position, not its shape.

Removing drift, then computing RMS

Polaris drifts slowly across the frame over the course of a cycle, just from ordinary sky motion and small tracking imperfections — that drift isn't seeing, so it's fitted as a straight line (position vs. time) and subtracted out first. The root-mean-square (RMS) of what's left — the residual motion in X and Y — is the raw measurement everything else is built from.

Converting motion to a seeing value

Seeing is computed from the single-aperture Kolmogorov image-motion relation: RMS motion gives the Fried parameter r₀ (the atmosphere's coherence length), which gives a seeing FWHM.

r₀ = λ × ( θ² / 0.179 × (D/λ)^(1/3) )^-0.6
seeing = 0.98 × λ / r₀ (then zenith-corrected)

Zenith correction

Seeing measured looking at Polaris is measured off-zenith, by an amount that depends on your latitude (Polaris sits at an altitude roughly equal to your latitude). Under Kolmogorov turbulence theory, the atmosphere's coherence length (the Fried parameter, r₀) — and so seeing itself — scales with airmass as cos(zenith angle)^0.6. The app applies this correction automatically once your latitude is configured, converting the raw line-of-sight measurement to the zenith-equivalent value that seeing is conventionally reported as.

Seeing vs. image FWHM — two different measurements

These are two different quantities, and they are not interchangeable. The "seeing" value above is inferred: it comes from how much the star's position jitters over a whole cycle, converted through the turbulence model. "Image FWHM" is measured: the star's actual width in one frame, from half-maximum crossings of its intensity profile.

Both respond to the atmosphere, and both also respond to focus, optical quality and how finely your pixels sample the star. Neither one isolates a single cause, so a difference between them is not by itself evidence that either is wrong. Note that seeing monitors conventionally report their motion-derived value as "zenith FWHM seeing" — that name refers to the inferred number, not to a directly measured image width.

Stacked FWHM

Image FWHM (above) measures the star's width in a single ~0.01s frame. Stacked FWHM instead sums a configurable number of the most recent frames together without re-registering them frame-to-frame, then measures the star's width in that combined image — approximating what a real multi-second astrophotography sub-exposure would actually look like, rather than an idealized single instant.

Stacked FWHM is shown on the Tonight graph by default and can be hidden from that plot (the underlying value is still recorded in the log either way) via Tools → Options....

Scientific Basis and Measurement Limitations

This instrument estimates seeing from the residual image motion of a single aperture: it watches how much one star's position moves in a fixed camera, removes a straight-line drift, and converts what remains into arcseconds using the Kolmogorov turbulence model described above. The seeing convention used here is a wavelength of 600 nm, with the zenith correction applied when it is enabled and your latitude is set.

What that means in practice

• Removing drift does not separate the atmosphere from everything else. A straight-line fit removes steady drift. Vibration reaching the mount, wind shake and the error in measuring the star's centre each frame all remain in the residual and are read as seeing.
• This is not a DIMM, and does not inherit a DIMM's main protection. A Differential Image Motion Monitor compares two apertures, so motion common to both — shake, tracking error — largely cancels. A single-aperture measurement has no such cancellation, which makes mechanical isolation considerably more important here. The published DIMM literature below is still the right place to understand the physics and the standard pitfalls; just don't assume its error budget applies unchanged.
• Inferred seeing and measured Image FWHM are different quantities and will not generally agree, as described in the previous section.
• Published theory does not validate this particular instrument. The references below establish the physical relationships and the known measurement pitfalls. None of them is a calibration of this software, this camera or your site, and nothing here should be read as an accuracy guarantee. The absolute accuracy of this monitor has not been established against an independent reference.

Known sensitivities

Three effects are well documented for image-motion seeing measurements generally and apply here. Detector and photon noise add apparent motion, which pushes measured seeing in the direction of looking worse — a fainter star or a noisier frame is not a neutral change. Finite exposure time works the other way: any exposure long enough to partly average the motion suppresses the measured variance, so seeing can read better than it is. How the star's position is estimated — the window, the threshold, the background — itself changes what quantity is being measured, so two reasonable centroid algorithms on identical frames need not agree.

References

These are the primary sources for the physics and for the cautions above.

• Martin, H. M. (1987), “Image motion as a measure of seeing quality”, Publications of the Astronomical Society of the Pacific, 99, 1360. doi:10.1086/132126.
  Treats absolute image motion measured with a single aperture alongside differential two-aperture motion — the closest published treatment of the measurement geometry this instrument uses — and shows that finite exposure time matters critically.
• Tokovinin, A. (2002), “From Differential Image Motion to Seeing”, Publications of the Astronomical Society of the Pacific, 114(800), 1156–1166. doi:10.1086/342683.
  Source of the seeing convention used here (ε = 0.98 λ/r₀). Also shows that windowing and thresholding change which tilt quantity is actually measured, and models how detector readout noise and non-zero exposure bias the motion variance.
• Tokovinin, A. & Kornilov, V. (2007), “Accurate seeing measurements with MASS and DIMM”, Monthly Notices of the Royal Astronomical Society, 381(3), 1179–1189. doi:10.1111/j.1365-2966.2007.12307.x.
  On accuracy limits: the authors discuss reaching roughly 10% absolute accuracy with carefully controlled MASS and DIMM instruments when biases are managed, and consider pushing that to 1% unrealistic because seeing is itself a model-dependent parameter of a non-stationary process. That discussion concerns those instruments — it is not a figure for this monitor, whose absolute accuracy has not been established.
• Kornilov, V. & Safonov, B. (2011), “Differential image motion in the short-exposure regime”, Monthly Notices of the Royal Astronomical Society, 418(3), 1878–1888. doi:10.1111/j.1365-2966.2011.19604.x.
  On finite exposure specifically: how wind moving the turbulence during an exposure smooths out image motion and biases the result, even at short exposures.
• Roddier, F. (1981), “The Effects of Atmospheric Turbulence in Optical Astronomy”, Progress in Optics, 19, 281–376.
  The standard review of the underlying theory — turbulence, the Fried parameter r₀, and how they set the image quality a telescope can achieve.

Main Window

X.XX" seeing

The primary number — an estimate of atmospheric seeing at your location, in arcseconds. This is the value that matches standard seeing-quality charts (e.g. <1.0" excellent, 1–2" average, >2.5" poor). It's computed from how much the star's centroid position jitters over a ~256-frame (~1 minute) cycle — not from the width of the star's image in any single frame.

Zenith status

Whether the seeing number above has been corrected to zenith-equivalent (matching the standard convention for reporting seeing).

• Zenith-corrected — correction is on and your latitude is set.
• Uncorrected - set latitude in Night Schedule — correction is turned on (the default) but can't run yet because your latitude hasn't been configured. Set it via Tools → Configure Night Schedule, even if you don't use the scheduling feature itself.
• Uncorrected — you've turned the correction off deliberately (Tools → Options).

Focus quality (image FWHM)

A different quantity from seeing — the actual measured width of the star's image in a single frame, rather than a value inferred from how the star moves.

Don't compare this number to seeing-quality charts — they describe the inferred seeing value, not a measured image width. It is most useful for watching focus, but it is not a pure focus reading: the atmosphere, optical quality and how finely your pixels sample the star all affect it too. See Seeing vs. image FWHM.

Tonight graph

The scrolling chart at the bottom of the window, spanning the whole night on a fixed time axis. Plots Seeing, a stacked image FWHM, and star brightness, on a fixed 0–7" vertical scale (configurable via Tools → Options...) so the range stays consistent from night to night; a reading above the top of the scale clips there rather than stretching the axis. See "Stacked FWHM" under How It Works for what that value means and why it commonly reads higher than Seeing — it can also be hidden from this graph entirely via Tools → Options... if it's not useful for your setup. A cloud-out or other gap in the data shows as a genuine empty stretch rather than a smoothed-over line.

Camera

Shows the connected camera's model name, or "not connected."

Status line

Shows what's currently happening — connect/disconnect confirmations, "Logging to <path>", lost-lock warnings, settings-saved messages, scheduler auto-start/stop notices, and error messages.

Cycle progress

Frame N/256 within the current ~1-minute measurement cycle. Resets to 1 at the start of each new cycle.

Schedule

The current night's auto start/stop times (see Configure Night Schedule below), or "disabled" if the nightly schedule isn't on.

Night

Running stats for the current monitoring session only (reset every time monitoring starts, manually or via the schedule): average, min, and max seeing, plus a trend (up/down/steady) based on the last 15 cycles — so it reflects recent direction, not the whole session.

Start Monitoring / Stop Monitoring

Starts or stops the measurement loop. Requires a camera to already be connected (Camera menu) — you'll get a message telling you so if not. Stopping and restarting resets the "Night" stats above.

Star view

A live, auto-stretched close-up of the star being tracked, updated every captured frame while monitoring runs. The border/background flashes dark red on any individual frame whose lock was rejected (cloud, jump, hot pixel, etc.) — occasional flashes are normal; constant red usually means something is wrong (clouds, tracking problem, wrong star centered).

Recent cycles

One line per completed measurement cycle: time, seeing, the star's mean X/Y position, the drift-corrected X/Y RMS jitter (pixels) that the seeing value was computed from, the alternate axis-mode seeing, and the star's average brightness (counts). A cycle that loses lock entirely doesn't appear here — it shows up as a status-line message instead. A cycle whose star was too dim to trust (see "Reference star counts" under Configure Camera / Optics) is marked "dim lock - seeing zeroed" instead.

Camera Menu

Connect → QHY... / ZWO... / Player One... / SBIG...

Connects to the first detected camera of that brand. Also auto-detects and saves the camera's pixel size (used in the plate-scale math for focus-quality/FWHM) and remembers which brand you used, so the night-schedule auto-start feature knows what to reconnect later.

SBIG cameras (developed against the ST-i) need SBIG/Diffraction Limited's own driver installed separately first - it isn't bundled with Seeing Monitor the way the QHY/ZWO SDKs are. It must specifically be the 64-bit driver; Seeing Monitor runs as a 64-bit process and cannot load a 32-bit one. If you're not sure which one is installed, or Connect → SBIG... reports the driver can't be found, download SBIGDriverChecker64 from SBIG/Diffraction Limited and run its update checker - it will install/update the 64-bit driver for you.

Seeing Monitor automatically finds and loads the driver from wherever the Driver Checker installed it (Program Files), so no manual file copying is needed once the 64-bit driver is actually present.

Player One cameras likewise need Player One's own USB driver installed separately first (download from Player One Astronomy's website) - Seeing Monitor bundles their SDK's capture library, but not the driver itself.

Disconnect

Releases the camera. Also stops monitoring first if it's running.

Tools Menu

Focus / Alignment Mode...

Opens a live-view window for manual focusing and mount alignment — exposure/gain sliders, raw pixel min/max readout, a live "In 5x5 / In 9x9" included-energy readout, and (if ASTAP is configured) a plate-solve button that overlays the NCP and Polaris positions so you can center the pole in frame. Requires the camera to be connected first, and can't be opened while monitoring is running (they can't share the camera at the same time).

The "In 5x5 / In 9x9" numbers show what percentage of the star's total light is concentrated within a 5x5 and 9x9 pixel box around it. Out-of-focus optics spread light across an uneven gradient (scintillation makes the illumination across the lens patchy, and an out-of-focus image turns that into a real centroid shift — the same effect a Foucault knife-edge test shows), which quietly inflates the seeing reading even when the star doesn't look obviously blurry. Adjust focus until these percentages are as high as they'll go.

Seeing History...

Opens a dedicated window for browsing every night ever logged, not just the current session — backed by a local database that imports your existing seeing-log files automatically and safely (it only ever reads them; the original text logs never change).

• Filter any date range, grouped by Day, Week, Month, Season, or Year. The back/forward arrows jump straight to the nearest night that actually has data in that direction, rather than blindly shifting by the range width.
• Three ways to look at it: a sortable table (with Export to CSV...), a Trend line chart (median inside a shaded best/worst band), and a Calendar heat-map (a real month grid at Day level, a wrapping grid of period cards at coarser groupings).
• A five-band color scale (Excellent / Good / Average / Below Average / Poor, tuned to typical seeing at this kind of site) colors Trend and Calendar and doubles as a clickable filter — click a legend chip to show only that band.
• Click any Trend point or Calendar cell to drill into that period's detail. From a coarser grouping this steps one level deeper each click (Year → Season → Month → Week → Day, with a Back button), down to that night's actual raw readings.
• Trend, Calendar, and the drill-down popup each have their own Save as PNG... button.

Configure ASTAP...

Path to astap_cli.exe (browse to find it), plus a search RA/Dec hint and radius to speed up plate solving. Leave the path blank to keep the Solve button disabled in Focus/Alignment mode.

ASTAP's own installer lets you pick which star database to download separately from the program itself. For a field of view (roughly 2–3° across, typical of a short-focal-length seeing-monitor lens), the D50 or D20 database is sufficient and much smaller than the wide-field G/V series meant for narrow-FOV imaging setups — see astap.htm under "Star databases" for the full size-vs-FOV guidance if your optics differ.

Configure Camera / Optics...

Pixel size (auto-filled on connect, but overridable here), focal length, aperture diameter, with a live plate-scale (arcsec/pixel) preview, a "use combined X+Y motion" checkbox, a noise-floor field (arcsec), and a minimum star-counts field. Hover the "(?)" next to each for details.

The seeing calculation uses pixel size, focal length, and aperture diameter directly — changing any of them changes the reported seeing (as well as the FWHM conversion and ASTAP search hints), so only change these if the optics actually changed.

The "use combined X+Y motion" checkbox is off by default: the formula's 0.179 coefficient applies to motion in a single axis, so X-axis-only (despite a fully valid Y-axis being measured too) is the direct default. Both modes are always computed regardless of this setting, so you can compare them against real conditions ("Alt. axis mode" in the recent-cycles list) before deciding whether to turn it on.

The noise floor is entered in arcsec of seeing — the number this app displays when it is shown a source that isn't really moving — not a pixel or arcsec figure for how much the centroid wobbles.

When set, the app computes sqrt(measured² − floor²), applied after the zenith correction. Worth knowing what that is and isn't: measurement noise combines with real motion in the motion domain (pixels of wobble), whereas this subtraction happens in the seeing domain (arcsec of FWHM), and because seeing rises faster than motion does, the two are not the same operation. It is the approximate correction implemented by this application, not an exact noise model.

It defaults to 0 (no correction), and leaving it there is the right choice until your instrument's own floor has actually been characterised. A floor measured on different optics or a different sensor does not carry over to yours.

Investigating your own floor (an experiment, not a calibration procedure). Pointing the camera at a stationary LED indoors and reading the displayed seeing is a reasonable investigative test, but the number it shows is not automatically the floor to enter. A single reading mostly tells you what that one source, at that one brightness, on that one patch of sensor, produced on that one run. If you want to explore it:

• Set this field to 0 first — any existing floor value would otherwise be subtracted from the very thing you are trying to measure.
• Use a source of brightness comparable to the star you actually monitor, and sample several positions on the sensor — centroid noise varies with both signal level and where the spot lands on the pixel grid.
• Record the conditions: exposure time, gain, the optics in use, and whether zenith correction was enabled — the result is specific to all of them and is not transferable between configurations.
• Repeat it. Take multiple runs and look at the spread, not one number. A single reading gives you no way to tell a real floor from a fluctuation.

Treat anything you derive this way as a working estimate for your own rig. It has not been validated against an independent reference, and neither has the correction it feeds.

Reference star counts guards against a dim/cloud-obscured/defocused star still producing a geometrically plausible lock whose RMS is mostly sky/centroid noise rather than real jitter. If a cycle's average brightness falls below a quarter of the reference value, its seeing/RMS are zeroed instead of trusted (flagged "dim lock" in the recent-cycles list). This field is OPTIONAL and defaults to 0 — left alone, the app learns its own reference automatically from the brightest clean, well-tracked cycle it's seen so far (shown live under this setting as "Auto-learned so far"), so a fresh install is protected with no setup required. Only enter a number here to force a specific value instead of letting it learn on its own.

Configure Night Schedule...

Set a nightly auto start/stop window for monitoring — either by typing start/stop times directly, or by entering your latitude/longitude (as degrees/minutes/seconds with N/S/E/W) and clicking Calculate to fill them in from nautical or astronomical twilight for tonight. Once enabled, the app recomputes the actual twilight times fresh every day from your saved location (so it tracks seasonal drift automatically) and will auto-connect the camera and start/stop monitoring to stay inside that window — even overriding a manual start/stop outside it.

Your latitude here is also what powers the zenith-correction feature, whether or not you use scheduling.

Logging Setup...

Where the tab-separated seeing log gets written (with a live full-path preview and a button to open that folder directly), plus a reminder that the file naming/column format itself isn't meant to be changed casually — it's kept stable for compatibility with any downstream tools built against the existing log files.

Log columns. The first twelve are the long-standing format and never change: Frame, Date, Time, Seeing, X-Cen, Y-Cen, X-rms, Y-rms, StarCts, Bgrnd, 5x5 Box, 9x9 Box. From version 3.0.10 two more are appended:

13. Image FWHM (arcsec)

The star's measured image width on the cycle's last accepted frame — the same number shown as “Focus quality” on the main window. This is a sharpness measure, not a seeing measure: Seeing (column 4) comes from how much the star's centre moved across the whole cycle, which is a different quantity.

14. Stacked FWHM (arcsec)

The same measurement on an average of the last few seconds of frames, which is what the Tonight graph plots. Because those frames are averaged without re-aligning them, this deliberately includes the star motion accumulated over that period — that is what makes it comparable to the FWHM you would measure on a real multi-second exposure, rather than a pure optical sharpness figure.

Both are left empty when there was no measurement for that cycle, rather than written as 0.00 — a real FWHM is never zero, so an empty field is the only honest way to say “not measured”.

If you have your own scripts reading these files: rows written before you upgraded still have twelve fields and rows written after have fourteen, and both can appear in the same file — the header of a night already in progress is left alone, because other software may be reading the file at that moment. Tell your scripts to accept at least twelve fields rather than exactly twelve, and to work out a row's format from how many fields it has rather than from the header line. (The header has always had more tab-separated pieces than a data row has fields, so it was never a reliable guide to column positions.) Anything that already reads the first twelve columns by position keeps working untouched.

Configure Plot Snapshot...

Automatically saves tonight's chart as a PNG to a folder of your choosing after every completed cycle — handy for publishing current seeing conditions to a website, or comparing conditions across a small network of sites. Off by default.

• Save to folder and a filename template using .NET date-format tokens (e.g. {0:MMddyy}) — the file overwrites in place through one night and rolls over automatically to a new name the next.
• Choose Chart Style... opens a picker with four chart designs (Refined Line, a thin trace with reference lines called out; Instrument Panel, a fine grid with a compact stat readout and the trace plotted as discrete points rather than a connected line; Stacked Tile, a compact card meant to sit next to other sites' tiles on a shared page; and Seeing & Transparency, mirroring the main window's own Tonight graph style — a Seeing trace plus a relative star-brightness/transparency band along the bottom, with no Stacked FWHM line), two export sizes (Standard 900×550 or Compact 680×460), and a snapshot theme (Match app theme, Always light, or Always dark — independent of your own Dark Mode setting below, so a public snapshot can stay one way even if you run the app the other way at night). Every combination previews live against a real recorded night before you commit to it.
• For Refined Line and Instrument Panel, the same dialog also has checkboxes for which of the four reference lines (Median/Average/Lowest/Highest) show up on the chart — this applies to both the snapshot and the Seeing History drill-down popup.

Remote Upload Setup...

Pushes the plot snapshot and/or the current night's seeing log straight to a remote server after every cycle, instead of relying on an external script or manual copying.

• Independent checkboxes for uploading the plot snapshot and the seeing log — turn on whichever one (or both) you actually want.
• Upload every cycle, or throttle to every N minutes to cut down on traffic (the files on disk still update every cycle either way, so a throttled upload never sends stale content).
• Each upload can optionally be renamed on the server - type a base name (e.g. SeeingGraph) next to either checkbox and it always uploads under that name, with the extension fixed to .png/.txt, instead of the local file's dated name. Useful if a server-side consumer should always find one stable filename rather than an ever-growing set of dated ones. This only renames the uploaded copy - it never renames the file on this computer.
• FTP, FTPS, SFTP, and S3 are all supported, with FTP/FTPS/SFTP and S3 on separate tabs so switching protocols never mixes up which fields mean what. Each tab has its own Test Connection button (checks the connection without transferring anything) and Clear Configuration button.
• Passwords and the S3 secret key are encrypted before being saved, using Windows' own per-user credential protection — a copied config file is unreadable on another machine or under another Windows account.

Options...

• Reject hot-pixel spikes in star search and centroid — applies to the original (pre-3.0.9) star-centre method, which is still computed alongside the current one for comparison. The measurement that produces your logged Seeing value since 3.0.9 uses a brightness cut-off instead of a neighbour test (the neighbour test was found to discard a tightly-focused star's own brightest pixel), so this option no longer affects the logged result. On by default; safe to leave on.
• Correct seeing to zenith-equivalent — see "Zenith status" above. Needs your latitude set (Configure Night Schedule) to actually do anything.
• Launch Seeing Monitor automatically when Windows starts — registers the app to start at login (no admin rights needed). Pairs well with Configure Night Schedule, which already auto-connects the camera and starts monitoring once the scheduled window arrives — this closes the remaining gap of getting the app itself running again after a reboot.
• Observatory name — printed as the header on Seeing History's Trend/Calendar charts and on the plot snapshot, so an exported image is self-identifying once it's off this machine (e.g. shown on a shared webpage).
• Seeing plot axis range — the fixed min/max (in arcsec, default 0–7") used by every seeing chart in the app (Tonight graph, Seeing History Trend, the drill-down popup, and the plot snapshot), so the vertical scale stays consistent from night to night instead of auto-fitting to each night's data. A reading above the top clips at the axis rather than stretching the range.
• Show Stacked FWHM on Tonight graph — on by default; turn off if Stacked FWHM isn't useful for your setup (e.g. it reads much larger than Seeing due to defocus) so it stops affecting the Tonight graph's scale. See "Stacked FWHM" under How It Works. This only hides the line on this graph — the value is still recorded in the log either way.

The four reference-line checkboxes (Median/Average/Lowest/Highest) used to live here; they've moved into Choose Chart Style... under Configure Plot Snapshot, next to the styles they actually apply to.

Dark Mode

A checkable menu item that switches the whole app — main window, Seeing History, and every settings dialog, including native window title bars — to a dark color scheme. Remembered between sessions.

Help Menu

User Guide...

This page.

Change Log...

What changed in each released version.

Check for Updates...

Checks a small version manifest hosted online and, if a newer release is available, offers to open the download page in your browser. Requires an internet connection - if the check itself fails (no connection, server unreachable), you'll see an explicit error message rather than a false "you're up to date."

If you have the optional ASCOM driver installed and a newer one is available, this check mentions it too. It won't say anything about the driver if you don't have it — use ASCOM Driver... below for that.

ASCOM Driver...

The optional ASCOM driver lets N.I.N.A., PHD2 and other ASCOM clients read this monitor's seeing value as an ObservingConditions device — it reports seeing through the standard StarFWHM property. You don't need it unless you use ASCOM.

This item tells you where you stand and, when there's something to get, offers to open the download page in your browser:

• Not installed — explains what the driver is and offers the download.
• Installed and current — shows the version you have.
• Installed but out of date — shows both versions and offers the newer one. It installs over the top of the one you have.

The driver is a separate download with its own installer and its own version number; it is not included in the Seeing Monitor installer and is never installed or updated automatically. Install the ASCOM Platform first, then run the driver's installer, then use its Setup button in your client's device chooser to point it at your log folder. Seeing Monitor only ever opens the download page — it never downloads or runs the installer for you.

Diagnostic Logging

Off by default. When ticked, each cycle also appends a row to a second file beside the night's log, SeeingLog_MMDDYY_centroid_compare.csv, recording per-cycle diagnostics: the result the previous (pre-3.0.9) star-centre method would have given on the same frames, how many frames had no star or were rejected or dropped as too dim, the measured pixel noise, whether the "star too dim" check fired, and the reason any cycle was skipped. Your main log is not changed in any way. The file is about 50-100 KB per night. Leave this off unless you have a question about your readings - then turn it on, run a night, and send the file along with the log; it is what makes an odd reading explainable after the fact. Takes effect from the next cycle, so it can be switched on mid-run.

About Seeing Monitor...

App name, version, and supported camera brands.