Troubleshooting
This page is organized by what you see on the pane, not by what is set in the dialog. When something surprises you mid-session, you do not want to skim a settings reference until you find the right knob; you want the...
Written By Axiom Admin
Last updated 22 days ago
Troubleshooting
This page is organized by what you see on the pane, not by what is set in the dialog. When something surprises you mid-session, you do not want to skim a settings reference until you find the right knob; you want the symptom to be the index entry. Each entry below names the symptom, the probable causes in roughly most-likely order, and the fix. Where the symptom is actually expected behavior rather than a defect, that is called out clearly so you do not chase a fix you do not need.
Three ground rules before you diagnose:
Read the status row first. TradingView displays runtime errors directly on the indicator's status row. The majority of "the pane went blank" reports resolve in five seconds the moment the reader looks at that row and sees the message naming the offending slot.
Confirm
On Bar Close?before anything else. A surprising number of "the line is behaving strangely" reports trace back to the repaint switch being in a different position than the reader remembered. Check it per slot in the Power User group, and when in doubt check every active slot β OFF does not carry a visual marker on its own slot beyond the drifting motion.Distinguish defects from documented behavior before changing settings. Several of the symptoms listed below are expected behavior that a reader who has not read the rest of the pack will misread as bugs. A hidden slot steering the blend, a window-pinned line, a repeat-firing alert β none of those is a defect. Each is called out below, with the expected behavior named explicitly. Mis-classifying a documented behavior as a defect is how a reader ends up chasing a fix that makes the pane worse.
The pane is completely blank
Symptom
You added the indicator or changed a setting, and the pane now has no lines β just the reference levels and empty space.
Most likely causes, in order
A runtime error fired. The status row will name the offending slot. Three configurations trigger a hard error:
A slot's
TimeFrame:is lower than the chart timeframe.A slot's
Lower TF Precision:is equal to or greater than itsTimeFrame:.A slot's
Window:is less than itsTimeFrame:.
The fix is to adjust the offending setting to satisfy the constraint. See MTF & Repainting for what each guardrail refuses and why.
Every slot is disabled.
Enable CVD NNis off on all ten slots. The pane cannot render anything. Re-enable at least one.Every slot's
Blended Weight:is zero andPlot Blended CVD/Signalis off. Slots render, but theirHide Plotmay also be on for every slot. Check that at least one slot is both enabled and not hidden.
When it is expected
Immediately after provoking a runtime error during Quick Start, the pane is supposed to be blank and the status row is supposed to show the message. Restore the setting and the pane returns.
One slot is missing but the others are drawing
Symptom
You expected CVD 03 (or any other slot) to draw a line and it is not there, but the other slots are fine.
Most likely causes
The slot is disabled. Check
Enable CVD NNin the slot's group.Hide CVD NN Plotis on. The slot is computing and contributing to the blend; its line is just hidden. Toggle this off to see it.The slot's timeframe needs more history than the chart has shown yet. A 60-minute slot on a fresh chart may take an hour to produce its first value. Scroll back a few days or wait for a slot-TF bar to close.
The slot's
Blended Weight:is0. This does not hide the line β weight controls blend contribution, not visibility. If the slot is enabled and not hidden, weight zero does not explain a missing line. Confirm one of the above instead.
The line I hid is still visibly affecting the blend
Symptom
You set Hide CVD NN Plot on a slot, expecting it to "stop contributing," and the blend did not change as you hoped.
What is happening
Hide CVD NN Plot hides the drawing only. The slot's CVD still computes, its weight still steers the blend, and its per-slot alerts still fire. This is documented behavior, not a defect β see Visuals & Logic for why visibility and math are separated.
Fix
To exclude the slot from the blend only: set
Blended Weight:to0.To exclude the slot from alignment alerts and per-slot alerts: set
Enable CVD NNtofalse.To hide the line while keeping the slot in the blend:
Hide CVD NN Plot = trueis already the right choice.
The blend line looks like a straight horizontal
Symptom
The blended CVD is flat at or near 50 for long stretches. The slots underneath it are moving normally, but the blend itself is a nearly horizontal line.
Most likely causes
Your weights are configured so the slots cancel each other. If two slots are at equal weight and consistently on opposite sides of their signals, their weighted mean will hover near the middle. Inspect each slot's position and color. If the stack is actively disagreeing, the blend being near 50 is accurate, not a defect. See Visuals & Logic for the "active cancellation" reading.
Master Smoothing is on and its length is very high. The master pass is delaying the blend's response. Lower the master length or turn it off to confirm.
All slots are clustered near 50 themselves. Tape is quiet; the blend is quiet because its inputs are. Expected behavior.
A slot line is hitting or sitting on 0 or 100 for many bars
Symptom
A slot's line has pinned itself at the top or bottom of the pane and is not moving off it.
Most likely causes
The slot's
Window:is too short. A window that is short relative to the slot's activity compresses the normalization range so hard that every reading saturates at one end or the other. Extend the window to a longer timeframe and watch the slot redistribute.The slot is in Session mode and you are just past a reset. Immediately after a session rollover, the window has only a few bars of history; the normalization range is narrow and readings bunch at extremes. Give the window time to develop (several bars minimum).
The instrument genuinely had a one-directional session. On a very strong trending day, the slot can reasonably pin near 80 or 20 because that is where participation actually sat. Not a defect; the pane is telling the truth about the tape.
The line is wiggling on every chart bar and I expected step-and-hold
Symptom
A slot with a higher timeframe than the chart is updating on every chart bar instead of stepping and holding.
Most likely cause
On Bar Close? is set to false on that slot. The slot is in its OFF posture β reading the live higher-timeframe bar and drifting as it forms. Open the slot's Power User group and confirm the switch.
Fix
Set On Bar Close? back to true. The line should resume step-and-hold behavior within one slot-TF bar.
When it is expected
If you deliberately switched to OFF for a reason documented in MTF & Repainting, the drift is the intended posture. Read that page again before concluding the drift is "wrong."
Dashed reset markers are not appearing where I expected them
Symptom
You expected a dashed vertical line at the start of each day (or week) and it is not there.
Most likely causes
The slot is in Rolling mode. Rolling mode has no resets. There will never be a dashed vertical for a slot in Rolling mode. Check
Window Mode:.You are looking at the wrong slot's color. Each slot's dashed marker is drawn in that slot's color. CVD 03's markers are blue; CVD 01's are teal. On a busy pane, it is easy to scan for one color and miss the others.
The
Window:is longer than you thought. A slot withWindow:set toW(weekly) will only have reset markers once per week, not once per day.You are running an Optional Ticker with a different session calendar. The slot's session calendar follows the symbol. A slot on BTCUSDT resets on UTC midnight; a slot on SPY resets at US cash open. They will not align.
My per-slot alert fires but the pane state disagrees
Symptom
A TradingView alert for CVD 01 Is Bullish (or similar) fired, but when you look at the pane on the bar that just closed, the slot looks bearish or neutral.
Most likely causes
You are looking at a different chart from the one the alert is watching. Alerts are chart-specific in TradingView. If you wired the alert on one chart and are viewing another, the states will not match.
TradingView is showing you the current forming bar, not the bar that closed when the alert fired. Scroll back one bar on your chart and inspect the slot at that bar. The alert always references the bar whose close triggered it.
The alert's frequency setting does not match the way you expect to consume the state. The script's alert conditions are gated to confirmed chart bars, but TradingView alert settings can still make repeat behavior feel different from what you meant. Re-set the alert's frequency to
Once Per Bar Closeto align it with the confirmed-close state.Stale alert condition. You changed a setting after creating the alert, and the alert's cached condition does not reflect the new configuration. Delete and recreate the alert.
Verification
Run the three-step verification in Alerts: confirm it fires on the right timeframe, confirm it matches pane state at close, provoke the opposite state to confirm it stops firing.
My alert is firing dozens of times during a sustained state
Symptom
You set a CVD 01 Is Bullish alert and it has fired fifty times in an hour.
What is happening
Per-slot and blended alerts do not edge-detect. They fire on every confirmed bar where the state holds. If CVD 01 has been bullish for fifty bars, the alert fires fifty times. This is documented repeat-fire behavior. See Alerts.
Fix options
Set TradingView's alert frequency to
Once Per Bar Closeto align with the script's confirmed-chart-bar gate. Does not stop cross-bar repeats.Set the alert's firing behavior to
Only Once. The alert fires once and disarms. You re-arm manually.Consume the alert externally and debounce it in your own alerting stack.
The pane says a slot is bullish but price is falling
Symptom
CVD 01 is at full opacity (bullish color) and has been for a stretch, but price is down.
What is happening
CVD measures participation, not price. A slot can read as bullish while price falls β buyers participating actively while sellers overpower them in the order book is not a contradiction; it is two different facets of the tape. Divergence between CVD and price is itself a read some traders value, though this indicator does not detect or flag divergences.
When to investigate further
If slot and blend agree with each other and both disagree with price for a sustained period, you are reading a CVD-versus-price disagreement. That is information, not an error. Note it, understand what your workflow wants you to do with it, and carry on.
When to suspect a defect
If the slot is at an extreme (near 0 or 100) and price action looks indecisive rather than strong, the window normalization may be compressed (see the "pinned at extremes" symptom above). Extend the Window: and confirm.
An optional-ticker slot is showing completely different rhythm from the rest
Symptom
A slot with Optional Ticker: set is behaving very differently from the chart-symbol slots on the same pane.
Most likely causes
Session-calendar mismatch. SPY on a US equity calendar and BTCUSDT on a UTC calendar reset at different wall-clock times. The slot rhythms are not expected to align.
Different venue liquidity and activity patterns. A BTC perp on Binance and BTC spot on Coinbase can look different minute-by-minute even though both are "BTC." Each slot is reading its venue's tape.
The optional-ticker symbol has thin data at the chosen timeframe. Very illiquid symbols can produce sparse bars that behave poorly under the estimator. Check the symbol's own chart at the slot's timeframe.
Fix
If session mismatch is the issue, consider switching the affected slot to Rolling mode so the reset-edge misalignment disappears.
If data thinness is the issue, raise the slot's timeframe or choose a different, more liquid symbol for the study.
For cross-venue studies, see Workflows for the documented pattern and the validation step before trusting a blend across venues.
The line looks "crude" on old bars but fine on recent bars
Symptom
When you scroll back several days or weeks, a slot's line becomes visibly less responsive or smoother than the same slot's behavior on recent bars.
What is happening
TradingView's intrabar history runs out past a certain depth that varies by plan and symbol. When the estimator cannot walk the lower-timeframe precision window for a bar, it falls back to a single-bar OHLCV delta using only the slot-TF bar's OHLCV. The fallback read is cruder than the full-precision read. The pane does not visually announce the fallback.
Fix
For live and near-live trading, this does not affect you. TradingView has ample intrabar history for recent bars.
For historical study or backtesting, take the fallback seriously. The historical range your backtest reads may include fallback output. See Limitations & Trust Boundaries.
There is no toggle that turns the fallback off. It is the estimator's honest best-effort read on data it does not have intrabars for.
Changing Pressure Sensitivity or Wick Weight had no visible effect
Symptom
You moved Pressure Sensitivity: or Wick Weight: and the slot's line did not visibly change.
Most likely causes
The change was too small. A step of
0.05is a small change. Move further (e.g.,1.50to3.00) to see the character shift clearly.Wick Weight on a wick-quiet instrument. If the bars do not have meaningful wicks, changing the wick weight changes almost nothing about the intent score. Try the same change on a wick-heavy instrument to feel the knob's grain.
You changed a Power User field that is not live for the current MA type. Power User ALMA, KAMA/FRAMA, JMA/Jurik-style, Laguerre, and VAMA fields are dormant unless the slot's MA type is the matching family. Confirm your MA type selection.
Master Smoothing made the pane feel slower
Symptom
You enabled Master Smoothing and now the blend is visibly delayed relative to the slots beneath it.
What is happening
Master smoothing adds a second smoothing pass on top of the blend. It trades responsiveness for quietness. This is the intended tradeoff.
Fix options
Lower the
Master Length.Switch to a faster MA family for the master pass (EMA is faster than SMA at the same length).
Turn it off if you need the blend to react as quickly as the slots do.
A slot's color contradicts the alert that just fired
Symptom
CVD 01 Is Bullish just fired but the CVD 01 line looks dimmed on the pane.
Most likely causes
You are looking at the wrong bar. Alerts fire on the confirmed bar's close. Scroll back to that bar and inspect.
The slot's CVD crossed back below its signal after the alert fired. The alert fired at the close of the previous bar; the current forming bar has already flipped. Expected behavior.
You are looking at the wrong chart. Alerts are wired to specific charts in TradingView. If the alert is wired to a 5-minute chart and you are on the 15-minute, states differ.
I cannot find the OB/OS crossing alert
Symptom
You are looking for an "alert when a line crosses 80" or "alert when blend crosses 20" and cannot find it in the Alerts dialog.
What is happening
There is no such alert in this indicator. The 80 and 20 guides (and the 50 midline) are cosmetic reference levels only β they do not feed any alert condition. See Alerts for the full inventory of what is and is not wired up.
Fix
If you need a threshold alert, use TradingView's own alert-on-plot mechanism on one of the slot lines the indicator exposes. That is out-of-scope for this indicator but a standard TradingView feature.
When nothing in this page matches
Four final checks that resolve a surprising number of "I give up" cases. Work them in order; each one is cheaper than the next.
Refresh the chart. TradingView occasionally leaves indicator state in an odd place after long idle sessions, a symbol switch, or a settings flurry. A page reload is free and clears most of those wedges. Do this first, because if it fixes the symptom you have just saved yourself a long diagnostic session.
Reset the indicator's settings to defaults and add your changes back one at a time. If you have been tuning for a while and the pane no longer looks like what you expect, the defaults are the only known-good configuration you can compare against. Reset, confirm the default pane looks like the Quick Start's "correct first pane" section, then reintroduce your changes in the order you originally made them. The change that reproduces the symptom is the culprit, and catching it this way usually takes less time than staring at ten slots of settings trying to spot the one that differs.
Reproduce on a second instrument. If the surprising behavior follows you across instruments, it is a setting or a misunderstanding on your side. If it is specific to one instrument, that instrument's data stream β thin liquidity, session calendar, missing intrabar history β is part of the story, and the fix is usually a configuration choice at the slot level rather than a broad setting change.
Screenshot the pane, the Inputs dialog, and the status row, and step away. Most "nothing matches" cases benefit from a five-minute break followed by a fresh look. Compare the screenshots to the Quick Start's correct-first-pane section and to the "what to watch" tables in Workflows. The gap between what you have and what you expect usually announces itself on the second look in a way it did not on the first. If after all of this the pane is still misbehaving in a way the pack does not anticipate, that is the moment to reach for support with a concrete reproduction rather than a description.
Where to go next
For the meaning of each slot control, Settings.
For the pane's visual vocabulary and ambiguous-state readings, Visuals & Logic.
For the timing posture and runtime guardrails in detail, MTF & Repainting.
For what the alerts do and do not commit to, Alerts.
For the honest limits on what this pane can tell you, Limitations & Trust Boundaries.