Troubleshooting

This page is organized by what you see on the chart, not by the setting that controls it. When something is wrong, you rarely start from the setting; you start from the symptom. Each entry below names the symptom, lis...

Written By Axiom Admin

Last updated 22 days ago

Troubleshooting

This page is organized by what you see on the chart, not by the setting that controls it. When something is wrong, you rarely start from the setting; you start from the symptom. Each entry below names the symptom, lists the likely causes in order of probability, and points you at the fix or the page that explains the underlying behavior.

A note before you scroll. Most "bugs" reported against this kind of indicator are not bugs β€” they are honest behaviors with surprising visual presentations, or they are configuration errors that happen to compose into something that looks broken. The entries below are written to distinguish three classes: a setup error you can correct, a misread that resolves once you understand what the pane is actually saying, and a genuine product limit that no setting will move. The fix for each class is different, and the most common waste of time is treating a misread as a setup error and burning an hour changing settings that were never the cause.

If the pane is behaving in a way that is not listed below, start with the diagnostic checklist at the bottom of For the Geeks. It covers the fastest common-case checks.

Pane and slot symptoms

The pane is blank or nothing is drawing

  • The indicator may have thrown a runtime error at load time. Check the status bar at the bottom of the pane for an error message. The most common causes are a slot timeframe lower than the chart, a lower-TF precision equal to or higher than its slot's timeframe, or a window smaller than its slot's timeframe. The error message names the slot. Fix the offending slot and reload.

  • All five slots may be disabled. Open the Inputs dialog and confirm that Enable CVD 01 is on, at minimum.

A slot I enabled is not drawing on the pane

  • Hide CVD 0N Plot is ON for that slot. Turn it off. The slot has been running the whole time; only the line was hidden.

  • The slot is enabled but its value is currently na. This is most common on the first bars after load or when the requested ticker/timeframe has not returned a value. A normal session reset restarts the window but does not automatically make the slot na.

The blend moves but I cannot see what is driving it

  • One or more slots are enabled with Hide Plot ON. Hidden slots still contribute to the blend with their assigned weights. Temporarily unhide them to see the contributors.

  • A slot is pointed at an Optional Ticker. The slot is running against a different symbol than the chart, and its behavior will not correspond to what you see in price on the chart. Check the slot's ticker setting.

A slot's line is behaving differently on older bars than on recent bars

  • The slot has fallen back to single-bar OHLCV estimation because intrabar data at the requested precision has aged out. This is expected behavior on long histories. The line does not visually announce the change. See the intrabar history fallback section of MTF and Repainting. Mitigation: use a lower-TF precision whose history window covers your chart.

A slot is pinned near 0 or near 100 for a long stretch

  • Genuine one-sided pressure in a strong trend. Check the slot stack and the chart context.

  • A quiet instrument window where the cumulative's observed high and low are very close together. The bounded normalization amplifies small moves into large line movements. Check the instrument's absolute price behavior across the same window; if price has barely moved, this is the second case.

  • See the "Boundedness is a normalization guarantee, not a structure guarantee" framing in Limitations and Trust Boundaries.

My pane leaves the 0-to-100 band

  • Not possible under normal operation. The normalization clamps the slot lines to 0-to-100, and the structure features clamp their channel lines to 0-to-100. If you see something outside the band, the indicator may have failed to load correctly. Remove and re-add it. If the symptom persists, the indicator version may have been modified; check the source.

Session and window symptoms

I expected a dashed vertical session-reset line and it did not appear

  • The slot is in Rolling mode. Rolling windows do not produce reset markers β€” by design, because the window is a sliding window rather than a reset event. Change Window Mode to Session if you want the reset marker.

  • Hide CVD 0N Plot is ON for that slot. Hiding the plot also hides the slot's reset marker.

  • The anchor timeframe did not change on that bar because the slot is pointed at an Optional Ticker with a different session from the chart. The reset will land on the ticker's session boundary, not the chart's.

The reset dash is landing in an unexpected place

  • The slot is pointed at an Optional Ticker that trades on a different exchange. The session boundary is the ticker's, not the chart's. Expected behavior, not a bug.

  • The Window Length value is something other than what you think it is. Re-check the slot's settings.

A slot behaves strangely in the first bars after a reset

  • This is normal. Fresh resets accumulate very little evidence at first, and the normalization range is very narrow. The slot can move widely against small amounts of accumulated delta until the window has filled in. An All CVD Slots Bullish or All CVD Slots Bearish alert that fires close to a reset is often reset-noise. See the session-reset ambiguous-state section of Visuals and Logic.

Divergence symptoms

I do not see any divergence triangles

  • Show Div is off. Open the Blend Div group and turn it on.

  • Pivot Len is set very high and no pivots have had time to confirm. The strict pivot definition needs Pivot Len bars to the right of every pivot before the pivot confirms. On a 5-minute chart with Pivot Len of 50, confirmation arrives roughly four hours after each pivot.

  • The instrument is in a regime where no divergence has formed between chart-price pivots and the blended CVD. This is not a bug. Not every chart has divergences.

I see too many divergence triangles

  • Pivot Len is too low for the swing scale you read. Lowering the lookback produces more triangles at a noisier scale, not stronger ones. Raise the lookback to a value that matches the swing scale you actually care about. The pack will not name a "best" value β€” the right value depends on what you trade.

A divergence triangle appeared on a bar that is not the pivot bar

  • Plot On Pivot is OFF. This is the default and the honest real-time posture, and it is what you want in a working configuration. The triangle sits on the confirmation bar, which is Pivot Len bars after the original pivot. The pivot itself is earlier β€” count back exactly Pivot Len bars from the triangle to find it on the chart.

  • If you want the triangle to visually sit on the pivot bar for historical review, toggle Plot On Pivot to ON. But read the next section first, because the cost of using ON in a working configuration is real.

A divergence triangle appeared on a past bar I did not expect

  • Plot On Pivot is ON. The triangle has been visually back-shifted by Pivot Len bars so it sits on the original pivot bar. The alert still fired on the confirmation bar. The marker was not visible at the back-shifted bar in real time. The visual is correct about where the geometry formed and silent about when the script could have known.

  • This is a display control, not a timing change. See MTF and Repainting for the full treatment and why using Plot On Pivot ON in a working configuration can train the wrong instinct.

  • If you do choose to use ON for replay study, do it deliberately. Toggle ON for review, do the work, toggle OFF before the next live session. The act of toggling is what keeps the timing distinction alive in your head.

The divergence alert fired but the marker does not seem to line up with the alert bar

  • Plot On Pivot is ON. The marker is on the pivot bar; the alert fired on the confirmation bar Pivot Len bars later. Toggle Plot On Pivot OFF to make the marker and the alert bar coincide. This is one of the most common confused-state symptoms with the divergence module and it is almost always the same root cause.

The divergence module is detecting a "divergence" that I would not call a divergence

  • The strict pivot definition is independent of your intuitive read. A pivot low that meets the Pivot Len criterion may still be part of a continuation pattern you would not call a pivot. The module is doing what it is told; the question is whether the lookback matches the swing scale you read.

  • This is a misread, not a setup error. The fix is not in the indicator's settings (although raising or lowering Pivot Len will change which pivots qualify); the fix is in matching your reading frame to what the module is actually testing for. See the divergence subsections of Visuals and Logic and the Workflows divergence-as-question workflow.

A divergence triangle appears coherent but does not seem to "do anything" afterward

  • This is the most common honest behavior of the divergence module and it is named here so you can recognize it as honest. Confirmed divergences print into continuations as often as they print into reversals. The module is asking whether a specific geometric pattern formed, not whether the market is about to turn. A triangle that prints and is followed by a continuation is a valid description of geometry on a market that was not turning. It is not a failure of the module.

  • The right response is logging, not parameter changing. Add the triangle to the log of triangles you are watching, note what the slot stack and the structure features were doing at the pivot bar, and read the result alongside the next twenty bars of price. Over enough triangles, you will learn the rate at which the geometry resolves into reversals around your instrument. Over enough rate, you will know how much weight the geometry deserves in your process.

Alert symptoms

An alert is firing repeatedly during a sustained state

  • Expected behavior for all state-descriptor alerts. The per-slot, blended, and all-slots-aligned alerts fire on every confirmed bar where the state holds, not only on the flip. See the repeat-fire section of Alerts. Mitigation: add edge detection on the receiving side, throttle in your alert platform, or route the alert to a review queue rather than an executor.

An alert I created is not firing

  • The alert condition may have been evaluated with an Any alert() function call option in the TradingView dialog. STR uses alertcondition() entries; select the specific condition by name rather than the generic any-call option.

  • The slot the alert references may be disabled. Per-slot alerts only fire when the slot is enabled.

  • The alert's confirmation bar has not yet arrived. All alerts gate on barstate.isconfirmed. If you just armed the alert mid-bar, it will not fire until the next bar closes and the state still holds.

  • For divergence alerts: there is no new pivot yet. Divergence alerts can only fire on the bar where a new pivot confirms.

An all-slots-aligned alert fired but one slot is clearly in a different direction

  • The slot you are looking at is disabled. The alignment alert only considers enabled slots.

  • The slot you are looking at has a current value of na. Slots returning na are skipped by the alignment check and do not count against agreement.

I expected an alert on a Keltner touch, Donchian breakout, or BBWP threshold crossing

  • Those events are not exposed as alerts. The threshold at the BBWP column and the upper and lower lines on Keltner and Donchian are visual references. If you need an alert on one of those events, you need to build it on the receiving side from the data you can export. See Alerts for the full inventory of what is and is not exposed.

I expected an alert on the oscillator's 20 or 80 guide crossing

  • Not exposed. The guide lines are visual only. No alert is generated.

Settings and behavior symptoms

Changing Pressure Sensitivity is not producing an effect

  • Pressure Sensitivity is a per-slot control. Changing it on one slot only affects that slot. If you are reading the blend, the change is diluted by the other slots' unchanged contributions. Change the value on each slot you want to affect, or temporarily isolate the slot by setting other slots' weights to 0.0.

  • The change is too small. Push it to the extremes (0.25 or 4.0) once to confirm the control is active; the difference will be obvious. Then dial back in smaller steps.

Changing Wick Weight is not producing an effect

  • Same pattern as Pressure Sensitivity. Per-slot control; changes are diluted by the blend. And: Wick Weight only shows its influence on bars where wick asymmetry is meaningful. On bars where wicks are roughly balanced, the control has little to do.

Turning Master Smoothing on has not calmed the blend

  • Master Smoothing applies to the blended lines, not to per-slot lines. If you are reading the per-slot lines underneath, they will not change. And: the master smoothing pass adds lag; if the blend was twitching because the slots are fighting, the smoothing will hide the fight without resolving it. The better move is usually to reconsider which slots are in the stack.

The Keltner envelope looks wrong β€” too tight, too wide, or not fitting the blend

  • Defaults are deliberately a familiar Keltner width (KC Mult = 2.0, KC Length = 20). Unusual behavior after changing these is nearly always the change, not the construction. Walk back to defaults and compare.

  • The envelope is derived from the blend itself. If the blend's character has changed β€” a new regime, different underlying slot behavior β€” the envelope changes with it. That is the envelope working correctly, not a malfunction.

The BBWP columns look wrong for the price action I am seeing

  • BBWP on STR is measured on the blend, not on price. A low BBWP column during a wild price stretch is saying the blend's own width has been compressed even as price has been moving. That is legitimate information, not a miscalibration. See the BBWP section of Limitations and Trust Boundaries.

  • If the chart does not yet have a full BBWP lookback of valid width values, the columns can be absent because the script has no valid percentile to plot yet. That is warm-up by omission, not a hidden low-volatility reading.

The Donchian channel is hugging the 0 or 100 boundary

  • The blend has been sitting near a pane extreme, pinning the upper or lower stepline against the 0-to-100 ceiling or floor. See the Donchian boundedness note in For the Geeks. The channel's "new high" event means something slightly different near the pane's extremes than in the middle.

Error messages

Slot 0N timeframe must be β‰₯ chart timeframe

  • The slot's TimeFrame setting is lower than the chart's timeframe. Change either the slot or the chart so the slot's timeframe is at least as large as the chart's.

Slot 0N lower-TF precision must be < slot timeframe

  • The slot's Lower TF Precision is equal to or higher than the slot's own timeframe. Set the precision to a strictly lower timeframe.

Slot 0N window must be β‰₯ slot timeframe

  • The slot's Window Length value is smaller than the slot's own timeframe. In Session mode, ensure the window anchor is at least as large as the slot's timeframe. In Rolling mode, ensure the rolling duration is at least as large.

The exact wording of the error messages may vary; the general shape will match the rules above. In every case, the slot label is in the message so you can fix the right slot.

When you cannot tell which class a symptom belongs to

If you have read the relevant section above and still cannot tell whether you are looking at a setup error, a misread, or a product limit, run this short triage in order.

  1. Did the indicator throw a runtime error at any point during the session? If yes, the symptom is downstream of the error. Fix the error first.

  2. Have you changed defaults? If yes, walk back to defaults on the suspected feature and observe whether the symptom persists. If it disappears at defaults, the change you made was the cause. If it persists, the defaults themselves are not responsible.

  3. Is the symptom present on a different instrument with the same configuration? If yes, the symptom is configuration-driven, not instrument-driven. If no, the instrument's behavior is contributing β€” boundedness amplification on a quiet instrument, intrabar fallback on a long history, session mismatch on a cross-exchange Optional Ticker. The fix is to read the instrument-specific section above.

  4. Does the symptom go away when you remove a feature from the pane? If yes, the symptom is reading more weight into multi-feature agreement than the features deserve. The features share a source; their visual coherence is a property of the shared source, not independent corroboration. See Limitations and Trust Boundaries.

  5. If none of the above resolves the symptom, you may be looking at a genuine product limit. The pack tries to surface those explicitly on Limitations and Trust Boundaries. If the symptom is not there either, that is worth telling us about β€” limits we have not named are limits we cannot teach.

Where to go next

  • For why the runtime guardrails exist and what they are protecting you from, MTF and Repainting.

  • For the mental model behind the estimator and the structure features, For the Geeks.

  • For the honest limits that make some of the symptoms above genuinely expected behavior rather than bugs, Limitations and Trust Boundaries.

  • For the alert inventory and what each alert does and does not commit to, Alerts.