Auto Fibonacci RetraceNOTE: This script is for educational purposes only.
This Pine Script v6 indicator automates the drawing of Fibonacci retracement levels on a TradingView chart based on detected pivot highs and lows. It's designed to identify the most recent swing points in a price trend and plot horizontal lines at standard Fibonacci ratios (0%, 23.6%, 38.2%, 50%, 61.8%, 78.6%, 100%), along with optional labels for each level. The script is useful for traders who want dynamic, hands-free Fib retracements that update as new pivots form, helping to spot potential support/resistance zones without manual intervention.
Key Features
Automatic Pivot Detection: Uses TradingView's built-in ta.pivothigh and ta.pivotlow functions to find recent swing highs and lows. The sensitivity is adjustable via user inputs for "Left Bars" and "Right Bars" (default: 5 each), which define how many bars are checked on either side to confirm a pivot.
Trend Direction Awareness: Determines if the current swing is an uptrend (recent high after low) or downtrend (recent low after high) and orients the Fib levels accordingly—starting from the low in uptrends or high in downtrends.
Dynamic Drawing:
Plots dashed horizontal lines extending to the right of the chart for each Fib level.
Colors are predefined for visual distinction (e.g., blue for 23.6%, orange for 61.8%).
Lines and labels are cleared and redrawn only when a new pivot is detected or on initial load to prevent chart clutter.
Customizable Labels: Optional labels show the percentage (e.g., "61.8%") and can be positioned on the "Left" (at the swing start) or "Right" (pinned to the current bar, updating dynamically). Labels use semi-transparent backgrounds for readability.
Performance Optimizations: Uses arrays to manage lines and labels efficiently, with reverse-indexed loops for safe deletion. The max_bars_back=500 ensures it handles historical data without excessive computation.
User Inputs:
Left/Right Bars: Tune pivot detection (higher values for major trends, lower for shorter swings).
Show Fib Levels/Labels: Toggle visibility.
Label Position: "Left" or "Right" for placement flexibility.
Usage Instructions
Adding to Chart: Copy-paste into TradingView's Pine Editor, save as a new indicator, and add it to your chart via the "Indicators" menu.
Customization: Adjust inputs in the indicator settings panel. For example, set Left/Right Bars to 10 for daily charts in strong trends.
Best Practices:
Use on trending markets (e.g., stocks, forex, crypto like BTC/USD); avoid choppy sideways action.
Combine with other indicators (e.g., RSI for overbought/oversold confirmation) for better trade signals.
Test on historical data—zoom out to see how it redraws on past swings.
Limitations: Relies on pivot functions, so it may lag slightly (pivots confirm after "Right Bars"). Not a trading strategy—use for analysis only. No alerts built-in, but you can add alertcondition if extending it.
Potential Enhancements: Add extensions (e.g., 161.8%), user-defined levels, or alerts on price touches via simple modifications.
This script provides a clean, efficient way to visualize Fib retracements automatically, saving time compared to manual drawing. If you need further tweaks or integration into a full strategy, let me know!
"bar"に関するスクリプトを検索
Taiwan Pagoda Chart (Triple)The code is open-source.
======================
Indicator Name
Taiwan Pagoda Chart
This is a technical analysis charting method similar to candlesticks but with different logic, designed to filter market noise and identify trend reversal points.
Key Features
Dynamic Pagoda Line Plotting
Unlike traditional candlesticks that plot every bar, the Pagoda line only updates when the price breaks above the previous high or below the previous low by a certain threshold.
Bullish (rising) bars are shown in green; bearish (falling) bars in red.
Multiple Optional Filters
T-value filter: Sets a minimum price change threshold to avoid signals from minor fluctuations.
Price percentage filter: Dynamically adjusts sensitivity based on a percentage of the previous Pagoda bar’s range.
ATR volatility filter: Uses Average True Range (ATR) to widen the threshold during high volatility and tighten it during low volatility.
Visual Design
Semi-transparent Pagoda structure for better visual context.
A bold central trend line to clearly show the underlying market direction.
Trading Signal Alerts
Bullish reversal (turning green): Potential buy signal.
Bearish reversal (turning red): Potential sell signal.
Optional on-chart labels (B / S) and support for TradingView alert notifications.
Highly Customizable
Users can freely adjust colors, line width, filtering rules, and signal visibility—making it adaptable to various trading styles.
Ideal Use Cases
Trend following
Reducing false breakouts
Helping medium-to-long-term traders identify high-probability entry and exit points
AI Adaptive MA - Machine Learning Trading Algorithm🤖 AI-Powered Self-Learning Trading Algorithm
This indicator uses machine learning to automatically optimize trading parameters in real-time, continuously learning from market behavior to improve signal accuracy.
How the AI Works:
- Runs backtesting loops across 45+ MA configurations simultaneously
- Scores each model based on recent prediction accuracy
- Auto-selects the highest-performing configuration
- Filters signals using multi-factor ML validation
Real-Time Stats Dashboard:
Shows the AI's current selected model, performance score, and trend detection
Key ML Features:
- Continuous Learning: Adapts every bar to changing markets
- Pattern Recognition: Identifies optimal MA periods automatically
- Smart Filtering: ML-based signal validation reduces false positives
- No Manual Optimization: The algorithm handles everything
Understanding the Score:
The AI's performance score shows how well the selected MA is working:
- 0-10: Poor - Choppy market, reduce trading
- 10-20: Moderate - Normal conditions
- 20-30: Good - Reliable signals
- 30+: Excellent - Strong trend, increase confidence
Score = Higher prediction accuracy over last 20 bars
The score tells you when to trust signals more (high score) or be cautious (low score). Sudden drops indicate market regime changes.
Why It's Different:
Unlike static indicators, this is a true adaptive AI system that learns and evolves with market conditions - similar to how quant funds use ML for signal generation.
Perfect for traders wanting to leverage artificial intelligence without coding their own algorithms.
Note: 70+ bar learning period required for AI initialization.
ValueAtTime█ OVERVIEW
This library is a Pine Script® programming tool for accessing historical values in a time series using UNIX timestamps . Its data structure and functions index values by time, allowing scripts to retrieve past values based on absolute timestamps or relative time offsets instead of relying on bar index offsets.
█ CONCEPTS
UNIX timestamps
In Pine Script®, a UNIX timestamp is an integer representing the number of milliseconds elapsed since January 1, 1970, at 00:00:00 UTC (the UNIX Epoch ). The timestamp is a unique, absolute representation of a specific point in time. Unlike a calendar date and time, a UNIX timestamp's meaning does not change relative to any time zone .
This library's functions process series values and corresponding UNIX timestamps in pairs , offering a simplified way to identify values that occur at or near distinct points in time instead of on specific bars.
Storing and retrieving time-value pairs
This library's `Data` type defines the structure for collecting time and value information in pairs. Objects of the `Data` type contain the following two fields:
• `times` – An array of "int" UNIX timestamps for each recorded value.
• `values` – An array of "float" values for each saved timestamp.
Each index in both arrays refers to a specific time-value pair. For instance, the `times` and `values` elements at index 0 represent the first saved timestamp and corresponding value. The library functions that maintain `Data` objects queue up to one time-value pair per bar into the object's arrays, where the saved timestamp represents the bar's opening time .
Because the `times` array contains a distinct UNIX timestamp for each item in the `values` array, it serves as a custom mapping for retrieving saved values. All the library functions that return information from a `Data` object use this simple two-step process to identify a value based on time:
1. Perform a binary search on the `times` array to find the earliest saved timestamp closest to the specified time or offset and get the element's index.
2. Access the element from the `values` array at the retrieved index, returning the stored value corresponding to the found timestamp.
Value search methods
There are several techniques programmers can use to identify historical values from corresponding timestamps. This library's functions include three different search methods to locate and retrieve values based on absolute times or relative time offsets:
Timestamp search
Find the value with the earliest saved timestamp closest to a specified timestamp.
Millisecond offset search
Find the value with the earliest saved timestamp closest to a specified number of milliseconds behind the current bar's opening time. This search method provides a time-based alternative to retrieving historical values at specific bar offsets.
Period offset search
Locate the value with the earliest saved timestamp closest to a defined period offset behind the current bar's opening time. The function calculates the span of the offset based on a period string . The "string" must contain one of the following unit tokens:
• "D" for days
• "W" for weeks
• "M" for months
• "Y" for years
• "YTD" for year-to-date, meaning the time elapsed since the beginning of the bar's opening year in the exchange time zone.
The period string can include a multiplier prefix for all supported units except "YTD" (e.g., "2W" for two weeks).
Note that the precise span covered by the "M", "Y", and "YTD" units varies across time. The "1M" period can cover 28, 29, 30, or 31 days, depending on the bar's opening month and year in the exchange time zone. The "1Y" period covers 365 or 366 days, depending on leap years. The "YTD" period's span changes with each new bar, because it always measures the time from the start of the current bar's opening year.
█ CALCULATIONS AND USE
This library's functions offer a flexible, structured approach to retrieving historical values at or near specific timestamps, millisecond offsets, or period offsets for different analytical needs.
See below for explanations of the exported functions and how to use them.
Retrieving single values
The library includes three functions that retrieve a single stored value using timestamp, millisecond offset, or period offset search methods:
• `valueAtTime()` – Locates the saved value with the earliest timestamp closest to a specified timestamp.
• `valueAtTimeOffset()` – Finds the saved value with the earliest timestamp closest to the specified number of milliseconds behind the current bar's opening time.
• `valueAtPeriodOffset()` – Finds the saved value with the earliest timestamp closest to the period-based offset behind the current bar's opening time.
Each function has two overloads for advanced and simple use cases. The first overload searches for a value in a user-specified `Data` object created by the `collectData()` function (see below). It returns a tuple containing the found value and the corresponding timestamp.
The second overload maintains a `Data` object internally to store and retrieve values for a specified `source` series. This overload returns a tuple containing the historical `source` value, the corresponding timestamp, and the current bar's `source` value, making it helpful for comparing past and present values from requested contexts.
Retrieving multiple values
The library includes the following functions to retrieve values from multiple historical points in time, facilitating calculations and comparisons with values retrieved across several intervals:
• `getDataAtTimes()` – Locates a past `source` value for each item in a `timestamps` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified timestamps.
• `getDataAtTimeOffsets()` – Finds a past `source` value for each item in a `timeOffsets` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified millisecond offsets behind the current bar's opening time.
• `getDataAtPeriodOffsets()` – Finds a past value for each item in a `periods` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified period offsets behind the current bar's opening time.
Each function returns a tuple with arrays containing the found `source` values and their corresponding timestamps. In addition, the tuple includes the current `source` value and the symbol's description, which also makes these functions helpful for multi-interval comparisons using data from requested contexts.
Processing period inputs
When writing scripts that retrieve historical values based on several user-specified period offsets, the most concise approach is to create a single text input that allows users to list each period, then process the "string" list into an array for use in the `getDataAtPeriodOffsets()` function.
This library includes a `getArrayFromString()` function to provide a simple way to process strings containing comma-separated lists of periods. The function splits the specified `str` by its commas and returns an array containing every non-empty item in the list with surrounding whitespaces removed. View the example code to see how we use this function to process the value of a text area input .
Calculating period offset times
Because the exact amount of time covered by a specified period offset can vary, it is often helpful to verify the resulting times when using the `valueAtPeriodOffset()` or `getDataAtPeriodOffsets()` functions to ensure the calculations work as intended for your use case.
The library's `periodToTimestamp()` function calculates an offset timestamp from a given period and reference time. With this function, programmers can verify the time offsets in a period-based data search and use the calculated offset times in additional operations.
For periods with "D" or "W" units, the function calculates the time offset based on the absolute number of milliseconds the period covers (e.g., `86400000` for "1D"). For periods with "M", "Y", or "YTD" units, the function calculates an offset time based on the reference time's calendar date in the exchange time zone.
Collecting data
All the `getDataAt*()` functions, and the second overloads of the `valueAt*()` functions, collect and maintain data internally, meaning scripts do not require a separate `Data` object when using them. However, the first overloads of the `valueAt*()` functions do not collect data, because they retrieve values from a user-specified `Data` object.
For cases where a script requires a separate `Data` object for use with these overloads or other custom routines, this library exports the `collectData()` function. This function queues each bar's `source` value and opening timestamp into a `Data` object and returns the object's ID.
This function is particularly useful when searching for values from a specific series more than once. For instance, instead of using multiple calls to the second overloads of `valueAt*()` functions with the same `source` argument, programmers can call `collectData()` to store each bar's `source` and opening timestamp, then use the returned `Data` object's ID in calls to the first `valueAt*()` overloads to reduce memory usage.
The `collectData()` function and all the functions that collect data internally include two optional parameters for limiting the saved time-value pairs to a sliding window: `timeOffsetLimit` and `timeframeLimit`. When either has a non-na argument, the function restricts the collected data to the maximum number of recent bars covered by the specified millisecond- and timeframe-based intervals.
NOTE : All calls to the functions that collect data for a `source` series can execute up to once per bar or realtime tick, because each stored value requires a unique corresponding timestamp. Therefore, scripts cannot call these functions iteratively within a loop . If a call to these functions executes more than once inside a loop's scope, it causes a runtime error.
█ EXAMPLE CODE
The example code at the end of the script demonstrates one possible use case for this library's functions. The code retrieves historical price data at user-specified period offsets, calculates price returns for each period from the retrieved data, and then populates a table with the results.
The example code's process is as follows:
1. Input a list of periods – The user specifies a comma-separated list of period strings in the script's "Period list" input (e.g., "1W, 1M, 3M, 1Y, YTD"). Each item in the input list represents a period offset from the latest bar's opening time.
2. Process the period list – The example calls `getArrayFromString()` on the first bar to split the input list by its commas and construct an array of period strings.
3. Request historical data – The code uses a call to `getDataAtPeriodOffsets()` as the `expression` argument in a request.security() call to retrieve the closing prices of "1D" bars for each period included in the processed `periods` array.
4. Display information in a table – On the latest bar, the code uses the retrieved data to calculate price returns over each specified period, then populates a two-row table with the results. The cells for each return percentage are color-coded based on the magnitude and direction of the price change. The cells also include tooltips showing the compared daily bar's opening date in the exchange time zone.
█ NOTES
• This library's architecture relies on a user-defined type (UDT) for its data storage format. UDTs are blueprints from which scripts create objects , i.e., composite structures with fields containing independent values or references of any supported type.
• The library functions search through a `Data` object's `times` array using the array.binary_search_leftmost() function, which is more efficient than looping through collected data to identify matching timestamps. Note that this built-in works only for arrays with elements sorted in ascending order .
• Each function that collects data from a `source` series updates the values and times stored in a local `Data` object's arrays. If a single call to these functions were to execute in a loop , it would store multiple values with an identical timestamp, which can cause erroneous search behavior. To prevent looped calls to these functions, the library uses the `checkCall()` helper function in their scopes. This function maintains a counter that increases by one each time it executes on a confirmed bar. If the count exceeds the total number of bars, indicating the call executes more than once in a loop, it raises a runtime error .
• Typically, when requesting higher-timeframe data with request.security() while using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should be offset with the history-referencing operator to prevent lookahead bias on historical bars. However, the call in this script's example code enables lookahead without offsetting the `expression` because the script displays results only on the last historical bar and all realtime bars, where there is no future data to leak into the past. This call ensures the displayed results use the latest data available from the context on realtime bars.
Look first. Then leap.
█ EXPORTED TYPES
Data
A structure for storing successive timestamps and corresponding values from a dataset.
Fields:
times (array) : An "int" array containing a UNIX timestamp for each value in the `values` array.
values (array) : A "float" array containing values corresponding to the timestamps in the `times` array.
█ EXPORTED FUNCTIONS
getArrayFromString(str)
Splits a "string" into an array of substrings using the comma (`,`) as the delimiter. The function trims surrounding whitespace characters from each substring, and it excludes empty substrings from the result.
Parameters:
str (series string) : The "string" to split into an array based on its commas.
Returns: (array) An array of trimmed substrings from the specified `str`.
periodToTimestamp(period, referenceTime)
Calculates a UNIX timestamp representing the point offset behind a reference time by the amount of time within the specified `period`.
Parameters:
period (series string) : The period string, which determines the time offset of the returned timestamp. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the `referenceTime` value's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
referenceTime (series int) : The millisecond UNIX timestamp from which to calculate the offset time.
Returns: (int) A millisecond UNIX timestamp representing the offset time point behind the `referenceTime`.
collectData(source, timeOffsetLimit, timeframeLimit)
Collects `source` and `time` data successively across bars. The function stores the information within a `Data` object for use in other exported functions/methods, such as `valueAtTimeOffset()` and `valueAtPeriodOffset()`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to collect. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: (Data) A `Data` object containing collected `source` values and corresponding timestamps over the allowed time range.
method valueAtTime(data, timestamp)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to the specified `timestamp`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest saved timestamp that is closest to the value.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the specified `timestamp` ("int").
valueAtTime(source, timestamp, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to the specified `timestamp`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest bar whose timestamp is closest to the value.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : (simple string) Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the specified `timestamp` ("int").
- The current bar's `source` value ("float").
method valueAtTimeOffset(data, timeOffset)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest saved timestamp closest to `timeOffset` milliseconds behind the current bar's opening time. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest saved timestamp that is closest to the calculated offset time.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
valueAtTimeOffset(source, timeOffset, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to `timeOffset` milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest bar's timestamp that is closest to the calculated offset time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
- The current bar's `source` value ("float").
method valueAtPeriodOffset(data, period)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the calculated offset behind the bar's opening time ("int").
valueAtPeriodOffset(source, period, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the calculated offset behind the current bar's opening time ("int").
- The current bar's `source` value ("float").
getDataAtTimes(timestamps, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the UNIX timestamps specified in the `timestamps` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timestamps (array) : An array of "int" values representing UNIX timestamps. The function retrieves `source` and time data for each element in this array.
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each item in the `timestamps` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtTimeOffsets(timeOffsets, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the time offsets specified in the `timeOffsets` array. Each offset in the array represents the absolute number of milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timeOffsets (array) : An array of "int" values representing the millisecond time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day and one week behind the current bar's opening time.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each offset specified in the `timeOffsets` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtPeriodOffsets(periods, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to a calculated offset behind the current bar's opening time. Each calculated offset represents the amount of time covered by a period specified in the `periods` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
periods (array) : An array of period strings, which determines the time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day, week, and month behind the current bar's opening time. Each "string" in the array must contain a unit and an optional multiplier. Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each period specified in the `periods` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
ATAI Volume analysis with price action V 1.00ATAI Volume Analysis with Price Action
1. Introduction
1.1 Overview
ATAI Volume Analysis with Price Action is a composite indicator designed for TradingView. It combines per‑side volume data —that is, how much buying and selling occurs during each bar—with standard price‑structure elements such as swings, trend lines and support/resistance. By blending these elements the script aims to help a trader understand which side is in control, whether a breakout is genuine, when markets are potentially exhausted and where liquidity providers might be active.
The indicator is built around TradingView’s up/down volume feed accessed via the TradingView/ta/10 library. The following excerpt from the script illustrates how this feed is configured:
import TradingView/ta/10 as tvta
// Determine lower timeframe string based on user choice and chart resolution
string lower_tf_breakout = use_custom_tf_input ? custom_tf_input :
timeframe.isseconds ? "1S" :
timeframe.isintraday ? "1" :
timeframe.isdaily ? "5" : "60"
// Request up/down volume (both positive)
= tvta.requestUpAndDownVolume(lower_tf_breakout)
Lower‑timeframe selection. If you do not specify a custom lower timeframe, the script chooses a default based on your chart resolution: 1 second for second charts, 1 minute for intraday charts, 5 minutes for daily charts and 60 minutes for anything longer. Smaller intervals provide a more precise view of buyer and seller flow but cover fewer bars. Larger intervals cover more history at the cost of granularity.
Tick vs. time bars. Many trading platforms offer a tick / intrabar calculation mode that updates an indicator on every trade rather than only on bar close. Turning on one‑tick calculation will give the most accurate split between buy and sell volume on the current bar, but it typically reduces the amount of historical data available. For the highest fidelity in live trading you can enable this mode; for studying longer histories you might prefer to disable it. When volume data is completely unavailable (some instruments and crypto pairs), all modules that rely on it will remain silent and only the price‑structure backbone will operate.
Figure caption, Each panel shows the indicator’s info table for a different volume sampling interval. In the left chart, the parentheses “(5)” beside the buy‑volume figure denote that the script is aggregating volume over five‑minute bars; the center chart uses “(1)” for one‑minute bars; and the right chart uses “(1T)” for a one‑tick interval. These notations tell you which lower timeframe is driving the volume calculations. Shorter intervals such as 1 minute or 1 tick provide finer detail on buyer and seller flow, but they cover fewer bars; longer intervals like five‑minute bars smooth the data and give more history.
Figure caption, The values in parentheses inside the info table come directly from the Breakout — Settings. The first row shows the custom lower-timeframe used for volume calculations (e.g., “(1)”, “(5)”, or “(1T)”)
2. Price‑Structure Backbone
Even without volume, the indicator draws structural features that underpin all other modules. These features are always on and serve as the reference levels for subsequent calculations.
2.1 What it draws
• Pivots: Swing highs and lows are detected using the pivot_left_input and pivot_right_input settings. A pivot high is identified when the high recorded pivot_right_input bars ago exceeds the highs of the preceding pivot_left_input bars and is also higher than (or equal to) the highs of the subsequent pivot_right_input bars; pivot lows follow the inverse logic. The indicator retains only a fixed number of such pivot points per side, as defined by point_count_input, discarding the oldest ones when the limit is exceeded.
• Trend lines: For each side, the indicator connects the earliest stored pivot and the most recent pivot (oldest high to newest high, and oldest low to newest low). When a new pivot is added or an old one drops out of the lookback window, the line’s endpoints—and therefore its slope—are recalculated accordingly.
• Horizontal support/resistance: The highest high and lowest low within the lookback window defined by length_input are plotted as horizontal dashed lines. These serve as short‑term support and resistance levels.
• Ranked labels: If showPivotLabels is enabled the indicator prints labels such as “HH1”, “HH2”, “LL1” and “LL2” near each pivot. The ranking is determined by comparing the price of each stored pivot: HH1 is the highest high, HH2 is the second highest, and so on; LL1 is the lowest low, LL2 is the second lowest. In the case of equal prices the newer pivot gets the better rank. Labels are offset from price using ½ × ATR × label_atr_multiplier, with the ATR length defined by label_atr_len_input. A dotted connector links each label to the candle’s wick.
2.2 Key settings
• length_input: Window length for finding the highest and lowest values and for determining trend line endpoints. A larger value considers more history and will generate longer trend lines and S/R levels.
• pivot_left_input, pivot_right_input: Strictness of swing confirmation. Higher values require more bars on either side to form a pivot; lower values create more pivots but may include minor swings.
• point_count_input: How many pivots are kept in memory on each side. When new pivots exceed this number the oldest ones are discarded.
• label_atr_len_input and label_atr_multiplier: Determine how far pivot labels are offset from the bar using ATR. Increasing the multiplier moves labels further away from price.
• Styling inputs for trend lines, horizontal lines and labels (color, width and line style).
Figure caption, The chart illustrates how the indicator’s price‑structure backbone operates. In this daily example, the script scans for bars where the high (or low) pivot_right_input bars back is higher (or lower) than the preceding pivot_left_input bars and higher or lower than the subsequent pivot_right_input bars; only those bars are marked as pivots.
These pivot points are stored and ranked: the highest high is labelled “HH1”, the second‑highest “HH2”, and so on, while lows are marked “LL1”, “LL2”, etc. Each label is offset from the price by half of an ATR‑based distance to keep the chart clear, and a dotted connector links the label to the actual candle.
The red diagonal line connects the earliest and latest stored high pivots, and the green line does the same for low pivots; when a new pivot is added or an old one drops out of the lookback window, the end‑points and slopes adjust accordingly. Dashed horizontal lines mark the highest high and lowest low within the current lookback window, providing visual support and resistance levels. Together, these elements form the structural backbone that other modules reference, even when volume data is unavailable.
3. Breakout Module
3.1 Concept
This module confirms that a price break beyond a recent high or low is supported by a genuine shift in buying or selling pressure. It requires price to clear the highest high (“HH1”) or lowest low (“LL1”) and, simultaneously, that the winning side shows a significant volume spike, dominance and ranking. Only when all volume and price conditions pass is a breakout labelled.
3.2 Inputs
• lookback_break_input : This controls the number of bars used to compute moving averages and percentiles for volume. A larger value smooths the averages and percentiles but makes the indicator respond more slowly.
• vol_mult_input : The “spike” multiplier; the current buy or sell volume must be at least this multiple of its moving average over the lookback window to qualify as a breakout.
• rank_threshold_input (0–100) : Defines a volume percentile cutoff: the current buyer/seller volume must be in the top (100−threshold)%(100−threshold)% of all volumes within the lookback window. For example, if set to 80, the current volume must be in the top 20 % of the lookback distribution.
• ratio_threshold_input (0–1) : Specifies the minimum share of total volume that the buyer (for a bullish breakout) or seller (for bearish) must hold on the current bar; the code also requires that the cumulative buyer volume over the lookback window exceeds the seller volume (and vice versa for bearish cases).
• use_custom_tf_input / custom_tf_input : When enabled, these inputs override the automatic choice of lower timeframe for up/down volume; otherwise the script selects a sensible default based on the chart’s timeframe.
• Label appearance settings : Separate options control the ATR-based offset length, offset multiplier, label size and colors for bullish and bearish breakout labels, as well as the connector style and width.
3.3 Detection logic
1. Data preparation : Retrieve per‑side volume from the lower timeframe and take absolute values. Build rolling arrays of the last lookback_break_input values to compute simple moving averages (SMAs), cumulative sums and percentile ranks for buy and sell volume.
2. Volume spike: A spike is flagged when the current buy (or, in the bearish case, sell) volume is at least vol_mult_input times its SMA over the lookback window.
3. Dominance test: The buyer’s (or seller’s) share of total volume on the current bar must meet or exceed ratio_threshold_input. In addition, the cumulative sum of buyer volume over the window must exceed the cumulative sum of seller volume for a bullish breakout (and vice versa for bearish). A separate requirement checks the sign of delta: for bullish breakouts delta_breakout must be non‑negative; for bearish breakouts it must be non‑positive.
4. Percentile rank: The current volume must fall within the top (100 – rank_threshold_input) percent of the lookback distribution—ensuring that the spike is unusually large relative to recent history.
5. Price test: For a bullish signal, the closing price must close above the highest pivot (HH1); for a bearish signal, the close must be below the lowest pivot (LL1).
6. Labeling: When all conditions above are satisfied, the indicator prints “Breakout ↑” above the bar (bullish) or “Breakout ↓” below the bar (bearish). Labels are offset using half of an ATR‑based distance and linked to the candle with a dotted connector.
Figure caption, (Breakout ↑ example) , On this daily chart, price pushes above the red trendline and the highest prior pivot (HH1). The indicator recognizes this as a valid breakout because the buyer‑side volume on the lower timeframe spikes above its recent moving average and buyers dominate the volume statistics over the lookback period; when combined with a close above HH1, this satisfies the breakout conditions. The “Breakout ↑” label appears above the candle, and the info table highlights that up‑volume is elevated relative to its 11‑bar average, buyer share exceeds the dominance threshold and money‑flow metrics support the move.
Figure caption, In this daily example, price breaks below the lowest pivot (LL1) and the lower green trendline. The indicator identifies this as a bearish breakout because sell‑side volume is sharply elevated—about twice its 11‑bar average—and sellers dominate both the bar and the lookback window. With the close falling below LL1, the script triggers a Breakout ↓ label and marks the corresponding row in the info table, which shows strong down volume, negative delta and a seller share comfortably above the dominance threshold.
4. Market Phase Module (Volume Only)
4.1 Concept
Not all markets trend; many cycle between periods of accumulation (buying pressure building up), distribution (selling pressure dominating) and neutral behavior. This module classifies the current bar into one of these phases without using ATR , relying solely on buyer and seller volume statistics. It looks at net flows, ratio changes and an OBV‑like cumulative line with dual‑reference (1‑ and 2‑bar) trends. The result is displayed both as on‑chart labels and in a dedicated row of the info table.
4.2 Inputs
• phase_period_len: Number of bars over which to compute sums and ratios for phase detection.
• phase_ratio_thresh : Minimum buyer share (for accumulation) or minimum seller share (for distribution, derived as 1 − phase_ratio_thresh) of the total volume.
• strict_mode: When enabled, both the 1‑bar and 2‑bar changes in each statistic must agree on the direction (strict confirmation); when disabled, only one of the two references needs to agree (looser confirmation).
• Color customisation for info table cells and label styling for accumulation and distribution phases, including ATR length, multiplier, label size, colors and connector styles.
• show_phase_module: Toggles the entire phase detection subsystem.
• show_phase_labels: Controls whether on‑chart labels are drawn when accumulation or distribution is detected.
4.3 Detection logic
The module computes three families of statistics over the volume window defined by phase_period_len:
1. Net sum (buyers minus sellers): net_sum_phase = Σ(buy) − Σ(sell). A positive value indicates a predominance of buyers. The code also computes the differences between the current value and the values 1 and 2 bars ago (d_net_1, d_net_2) to derive up/down trends.
2. Buyer ratio: The instantaneous ratio TF_buy_breakout / TF_tot_breakout and the window ratio Σ(buy) / Σ(total). The current ratio must exceed phase_ratio_thresh for accumulation or fall below 1 − phase_ratio_thresh for distribution. The first and second differences of the window ratio (d_ratio_1, d_ratio_2) determine trend direction.
3. OBV‑like cumulative net flow: An on‑balance volume analogue obv_net_phase increments by TF_buy_breakout − TF_sell_breakout each bar. Its differences over the last 1 and 2 bars (d_obv_1, d_obv_2) provide trend clues.
The algorithm then combines these signals:
• For strict mode , accumulation requires: (a) current ratio ≥ threshold, (b) cumulative ratio ≥ threshold, (c) both ratio differences ≥ 0, (d) net sum differences ≥ 0, and (e) OBV differences ≥ 0. Distribution is the mirror case.
• For loose mode , it relaxes the directional tests: either the 1‑ or the 2‑bar difference needs to agree in each category.
If all conditions for accumulation are satisfied, the phase is labelled “Accumulation” ; if all conditions for distribution are satisfied, it’s labelled “Distribution” ; otherwise the phase is “Neutral” .
4.4 Outputs
• Info table row : Row 8 displays “Market Phase (Vol)” on the left and the detected phase (Accumulation, Distribution or Neutral) on the right. The text colour of both cells matches a user‑selectable palette (typically green for accumulation, red for distribution and grey for neutral).
• On‑chart labels : When show_phase_labels is enabled and a phase persists for at least one bar, the module prints a label above the bar ( “Accum” ) or below the bar ( “Dist” ) with a dashed or dotted connector. The label is offset using ATR based on phase_label_atr_len_input and phase_label_multiplier and is styled according to user preferences.
Figure caption, The chart displays a red “Dist” label above a particular bar, indicating that the accumulation/distribution module identified a distribution phase at that point. The detection is based on seller dominance: during that bar, the net buyer-minus-seller flow and the OBV‑style cumulative flow were trending down, and the buyer ratio had dropped below the preset threshold. These conditions satisfy the distribution criteria in strict mode. The label is placed above the bar using an ATR‑based offset and a dashed connector. By the time of the current bar in the screenshot, the phase indicator shows “Neutral” in the info table—signaling that neither accumulation nor distribution conditions are currently met—yet the historical “Dist” label remains to mark where the prior distribution phase began.
Figure caption, In this example the market phase module has signaled an Accumulation phase. Three bars before the current candle, the algorithm detected a shift toward buyers: up‑volume exceeded its moving average, down‑volume was below average, and the buyer share of total volume climbed above the threshold while the on‑balance net flow and cumulative ratios were trending upwards. The blue “Accum” label anchored below that bar marks the start of the phase; it remains on the chart because successive bars continue to satisfy the accumulation conditions. The info table confirms this: the “Market Phase (Vol)” row still reads Accumulation, and the ratio and sum rows show buyers dominating both on the current bar and across the lookback window.
5. OB/OS Spike Module
5.1 What overbought/oversold means here
In many markets, a rapid extension up or down is often followed by a period of consolidation or reversal. The indicator interprets overbought (OB) conditions as abnormally strong selling risk at or after a price rally and oversold (OS) conditions as unusually strong buying risk after a decline. Importantly, these are not direct trade signals; rather they flag areas where caution or contrarian setups may be appropriate.
5.2 Inputs
• minHits_obos (1–7): Minimum number of oscillators that must agree on an overbought or oversold condition for a label to print.
• syncWin_obos: Length of a small sliding window over which oscillator votes are smoothed by taking the maximum count observed. This helps filter out choppy signals.
• Volume spike criteria: kVolRatio_obos (ratio of current volume to its SMA) and zVolThr_obos (Z‑score threshold) across volLen_obos. Either threshold can trigger a spike.
• Oscillator toggles and periods: Each of RSI, Stochastic (K and D), Williams %R, CCI, MFI, DeMarker and Stochastic RSI can be independently enabled; their periods are adjustable.
• Label appearance: ATR‑based offset, size, colors for OB and OS labels, plus connector style and width.
5.3 Detection logic
1. Directional volume spikes: Volume spikes are computed separately for buyer and seller volumes. A sell volume spike (sellVolSpike) flags a potential OverBought bar, while a buy volume spike (buyVolSpike) flags a potential OverSold bar. A spike occurs when the respective volume exceeds kVolRatio_obos times its simple moving average over the window or when its Z‑score exceeds zVolThr_obos.
2. Oscillator votes: For each enabled oscillator, calculate its overbought and oversold state using standard thresholds (e.g., RSI ≥ 70 for OB and ≤ 30 for OS; Stochastic %K/%D ≥ 80 for OB and ≤ 20 for OS; etc.). Count how many oscillators vote for OB and how many vote for OS.
3. Minimum hits: Apply the smoothing window syncWin_obos to the vote counts using a maximum‑of‑last‑N approach. A candidate bar is only considered if the smoothed OB hit count ≥ minHits_obos (for OverBought) or the smoothed OS hit count ≥ minHits_obos (for OverSold).
4. Tie‑breaking: If both OverBought and OverSold spike conditions are present on the same bar, compare the smoothed hit counts: the side with the higher count is selected; ties default to OverBought.
5. Label printing: When conditions are met, the bar is labelled as “OverBought X/7” above the candle or “OverSold X/7” below it. “X” is the number of oscillators confirming, and the bracket lists the abbreviations of contributing oscillators. Labels are offset from price using half of an ATR‑scaled distance and can optionally include a dotted or dashed connector line.
Figure caption, In this chart the overbought/oversold module has flagged an OverSold signal. A sell‑off from the prior highs brought price down to the lower trend‑line, where the bar marked “OverSold 3/7 DeM” appears. This label indicates that on that bar the module detected a buy‑side volume spike and that at least three of the seven enabled oscillators—in this case including the DeMarker—were in oversold territory. The label is printed below the candle with a dotted connector, signaling that the market may be temporarily exhausted on the downside. After this oversold print, price begins to rebound towards the upper red trend‑line and higher pivot levels.
Figure caption, This example shows the overbought/oversold module in action. In the left‑hand panel you can see the OB/OS settings where each oscillator (RSI, Stochastic, Williams %R, CCI, MFI, DeMarker and Stochastic RSI) can be enabled or disabled, and the ATR length and label offset multiplier adjusted. On the chart itself, price has pushed up to the descending red trendline and triggered an “OverBought 3/7” label. That means the sell‑side volume spiked relative to its average and three out of the seven enabled oscillators were in overbought territory. The label is offset above the candle by half of an ATR and connected with a dashed line, signaling that upside momentum may be overextended and a pause or pullback could follow.
6. Buyer/Seller Trap Module
6.1 Concept
A bull trap occurs when price appears to break above resistance, attracting buyers, but fails to sustain the move and quickly reverses, leaving a long upper wick and trapping late entrants. A bear trap is the opposite: price breaks below support, lures in sellers, then snaps back, leaving a long lower wick and trapping shorts. This module detects such traps by looking for price structure sweeps, order‑flow mismatches and dominance reversals. It uses a scoring system to differentiate risk from confirmed traps.
6.2 Inputs
• trap_lookback_len: Window length used to rank extremes and detect sweeps.
• trap_wick_threshold: Minimum proportion of a bar’s range that must be wick (upper for bull traps, lower for bear traps) to qualify as a sweep.
• trap_score_risk: Minimum aggregated score required to flag a trap risk. (The code defines a trap_score_confirm input, but confirmation is actually based on price reversal rather than a separate score threshold.)
• trap_confirm_bars: Maximum number of bars allowed for price to reverse and confirm the trap. If price does not reverse in this window, the risk label will expire or remain unconfirmed.
• Label settings: ATR length and multiplier for offsetting, size, colours for risk and confirmed labels, and connector style and width. Separate settings exist for bull and bear traps.
• Toggle inputs: show_trap_module and show_trap_labels enable the module and control whether labels are drawn on the chart.
6.3 Scoring logic
The module assigns points to several conditions and sums them to determine whether a trap risk is present. For bull traps, the score is built from the following (bear traps mirror the logic with highs and lows swapped):
1. Sweep (2 points): Price trades above the high pivot (HH1) but fails to close above it and leaves a long upper wick at least trap_wick_threshold × range. For bear traps, price dips below the low pivot (LL1), fails to close below and leaves a long lower wick.
2. Close break (1 point): Price closes beyond HH1 or LL1 without leaving a long wick.
3. Candle/delta mismatch (2 points): The candle closes bullish yet the order flow delta is negative or the seller ratio exceeds 50%, indicating hidden supply. Conversely, a bearish close with positive delta or buyer dominance suggests hidden demand.
4. Dominance inversion (2 points): The current bar’s buyer volume has the highest rank in the lookback window while cumulative sums favor sellers, or vice versa.
5. Low‑volume break (1 point): Price crosses the pivot but total volume is below its moving average.
The total score for each side is compared to trap_score_risk. If the score is high enough, a “Bull Trap Risk” or “Bear Trap Risk” label is drawn, offset from the candle by half of an ATR‑scaled distance using a dashed outline. If, within trap_confirm_bars, price reverses beyond the opposite level—drops back below the high pivot for bull traps or rises above the low pivot for bear traps—the label is upgraded to a solid “Bull Trap” or “Bear Trap” . In this version of the code, there is no separate score threshold for confirmation: the variable trap_score_confirm is unused; confirmation depends solely on a successful price reversal within the specified number of bars.
Figure caption, In this example the trap module has flagged a Bear Trap Risk. Price initially breaks below the most recent low pivot (LL1), but the bar closes back above that level and leaves a long lower wick, suggesting a failed push lower. Combined with a mismatch between the candle direction and the order flow (buyers regain control) and a reversal in volume dominance, the aggregate score exceeds the risk threshold, so a dashed “Bear Trap Risk” label prints beneath the bar. The green and red trend lines mark the current low and high pivot trajectories, while the horizontal dashed lines show the highest and lowest values in the lookback window. If, within the next few bars, price closes decisively above the support, the risk label would upgrade to a solid “Bear Trap” label.
Figure caption, In this example the trap module has identified both ends of a price range. Near the highs, price briefly pushes above the descending red trendline and the recent pivot high, but fails to close there and leaves a noticeable upper wick. That combination of a sweep above resistance and order‑flow mismatch generates a Bull Trap Risk label with a dashed outline, warning that the upside break may not hold. At the opposite extreme, price later dips below the green trendline and the labelled low pivot, then quickly snaps back and closes higher. The long lower wick and subsequent price reversal upgrade the previous bear‑trap risk into a confirmed Bear Trap (solid label), indicating that sellers were caught on a false breakdown. Horizontal dashed lines mark the highest high and lowest low of the lookback window, while the red and green diagonals connect the earliest and latest pivot highs and lows to visualize the range.
7. Sharp Move Module
7.1 Concept
Markets sometimes display absorption or climax behavior—periods when one side steadily gains the upper hand before price breaks out with a sharp move. This module evaluates several order‑flow and volume conditions to anticipate such moves. Users can choose how many conditions must be met to flag a risk and how many (plus a price break) are required for confirmation.
7.2 Inputs
• sharp Lookback: Number of bars in the window used to compute moving averages, sums, percentile ranks and reference levels.
• sharpPercentile: Minimum percentile rank for the current side’s volume; the current buy (or sell) volume must be greater than or equal to this percentile of historical volumes over the lookback window.
• sharpVolMult: Multiplier used in the volume climax check. The current side’s volume must exceed this multiple of its average to count as a climax.
• sharpRatioThr: Minimum dominance ratio (current side’s volume relative to the opposite side) used in both the instant and cumulative dominance checks.
• sharpChurnThr: Maximum ratio of a bar’s range to its ATR for absorption/churn detection; lower values indicate more absorption (large volume in a small range).
• sharpScoreRisk: Minimum number of conditions that must be true to print a risk label.
• sharpScoreConfirm: Minimum number of conditions plus a price break required for confirmation.
• sharpCvdThr: Threshold for cumulative delta divergence versus price change (positive for bullish accumulation, negative for bearish distribution).
• Label settings: ATR length (sharpATRlen) and multiplier (sharpLabelMult) for positioning labels, label size, colors and connector styles for bullish and bearish sharp moves.
• Toggles: enableSharp activates the module; show_sharp_labels controls whether labels are drawn.
7.3 Conditions (six per side)
For each side, the indicator computes six boolean conditions and sums them to form a score:
1. Dominance (instant and cumulative):
– Instant dominance: current buy volume ≥ sharpRatioThr × current sell volume.
– Cumulative dominance: sum of buy volumes over the window ≥ sharpRatioThr × sum of sell volumes (and vice versa for bearish checks).
2. Accumulation/Distribution divergence: Over the lookback window, cumulative delta rises by at least sharpCvdThr while price fails to rise (bullish), or cumulative delta falls by at least sharpCvdThr while price fails to fall (bearish).
3. Volume climax: The current side’s volume is ≥ sharpVolMult × its average and the product of volume and bar range is the highest in the lookback window.
4. Absorption/Churn: The current side’s volume divided by the bar’s range equals the highest value in the window and the bar’s range divided by ATR ≤ sharpChurnThr (indicating large volume within a small range).
5. Percentile rank: The current side’s volume percentile rank is ≥ sharp Percentile.
6. Mirror logic for sellers: The above checks are repeated with buyer and seller roles swapped and the price break levels reversed.
Each condition that passes contributes one point to the corresponding side’s score (0 or 1). Risk and confirmation thresholds are then applied to these scores.
7.4 Scoring and labels
• Risk: If scoreBull ≥ sharpScoreRisk, a “Sharp ↑ Risk” label is drawn above the bar. If scoreBear ≥ sharpScoreRisk, a “Sharp ↓ Risk” label is drawn below the bar.
• Confirmation: A risk label is upgraded to “Sharp ↑” when scoreBull ≥ sharpScoreConfirm and the bar closes above the highest recent pivot (HH1); for bearish cases, confirmation requires scoreBear ≥ sharpScoreConfirm and a close below the lowest pivot (LL1).
• Label positioning: Labels are offset from the candle by ATR × sharpLabelMult (full ATR times multiplier), not half, and may include a dashed or dotted connector line if enabled.
Figure caption, In this chart both bullish and bearish sharp‑move setups have been flagged. Earlier in the range, a “Sharp ↓ Risk” label appears beneath a candle: the sell‑side score met the risk threshold, signaling that the combination of strong sell volume, dominance and absorption within a narrow range suggested a potential sharp decline. The price did not close below the lower pivot, so this label remains a “risk” and no confirmation occurred. Later, as the market recovered and volume shifted back to the buy side, a “Sharp ↑ Risk” label prints above a candle near the top of the channel. Here, buy‑side dominance, cumulative delta divergence and a volume climax aligned, but price has not yet closed above the upper pivot (HH1), so the alert is still a risk rather than a confirmed sharp‑up move.
Figure caption, In this chart a Sharp ↑ label is displayed above a candle, indicating that the sharp move module has confirmed a bullish breakout. Prior bars satisfied the risk threshold — showing buy‑side dominance, positive cumulative delta divergence, a volume climax and strong absorption in a narrow range — and this candle closes above the highest recent pivot, upgrading the earlier “Sharp ↑ Risk” alert to a full Sharp ↑ signal. The green label is offset from the candle with a dashed connector, while the red and green trend lines trace the high and low pivot trajectories and the dashed horizontals mark the highest and lowest values of the lookback window.
8. Market‑Maker / Spread‑Capture Module
8.1 Concept
Liquidity providers often “capture the spread” by buying and selling in almost equal amounts within a very narrow price range. These bars can signal temporary congestion before a move or reflect algorithmic activity. This module flags bars where both buyer and seller volumes are high, the price range is only a few ticks and the buy/sell split remains close to 50%. It helps traders spot potential liquidity pockets.
8.2 Inputs
• scalpLookback: Window length used to compute volume averages.
• scalpVolMult: Multiplier applied to each side’s average volume; both buy and sell volumes must exceed this multiple.
• scalpTickCount: Maximum allowed number of ticks in a bar’s range (calculated as (high − low) / minTick). A value of 1 or 2 captures ultra‑small bars; increasing it relaxes the range requirement.
• scalpDeltaRatio: Maximum deviation from a perfect 50/50 split. For example, 0.05 means the buyer share must be between 45% and 55%.
• Label settings: ATR length, multiplier, size, colors, connector style and width.
• Toggles : show_scalp_module and show_scalp_labels to enable the module and its labels.
8.3 Signal
When, on the current bar, both TF_buy_breakout and TF_sell_breakout exceed scalpVolMult times their respective averages and (high − low)/minTick ≤ scalpTickCount and the buyer share is within scalpDeltaRatio of 50%, the module prints a “Spread ↔” label above the bar. The label uses the same ATR offset logic as other modules and draws a connector if enabled.
Figure caption, In this chart the spread‑capture module has identified a potential liquidity pocket. Buyer and seller volumes both spiked above their recent averages, yet the candle’s range measured only a couple of ticks and the buy/sell split stayed close to 50 %. This combination met the module’s criteria, so it printed a grey “Spread ↔” label above the bar. The red and green trend lines link the earliest and latest high and low pivots, and the dashed horizontals mark the highest high and lowest low within the current lookback window.
9. Money Flow Module
9.1 Concept
To translate volume into a monetary measure, this module multiplies each side’s volume by the closing price. It tracks buying and selling system money default currency on a per-bar basis and sums them over a chosen period. The difference between buy and sell currencies (Δ$) shows net inflow or outflow.
9.2 Inputs
• mf_period_len_mf: Number of bars used for summing buy and sell dollars.
• Label appearance settings: ATR length, multiplier, size, colors for up/down labels, and connector style and width.
• Toggles: Use enableMoneyFlowLabel_mf and showMFLabels to control whether the module and its labels are displayed.
9.3 Calculations
• Per-bar money: Buy $ = TF_buy_breakout × close; Sell $ = TF_sell_breakout × close. Their difference is Δ$ = Buy $ − Sell $.
• Summations: Over mf_period_len_mf bars, compute Σ Buy $, Σ Sell $ and ΣΔ$ using math.sum().
• Info table entries: Rows 9–13 display these values as texts like “↑ USD 1234 (1M)” or “ΣΔ USD −5678 (14)”, with colors reflecting whether buyers or sellers dominate.
• Money flow status: If Δ$ is positive the bar is marked “Money flow in” ; if negative, “Money flow out” ; if zero, “Neutral”. The cumulative status is similarly derived from ΣΔ.Labels print at the bar that changes the sign of ΣΔ, offset using ATR × label multiplier and styled per user preferences.
Figure caption, The chart illustrates a steady rise toward the highest recent pivot (HH1) with price riding between a rising green trend‑line and a red trend‑line drawn through earlier pivot highs. A green Money flow in label appears above the bar near the top of the channel, signaling that net dollar flow turned positive on this bar: buy‑side dollar volume exceeded sell‑side dollar volume, pushing the cumulative sum ΣΔ$ above zero. In the info table, the “Money flow (bar)” and “Money flow Σ” rows both read In, confirming that the indicator’s money‑flow module has detected an inflow at both bar and aggregate levels, while other modules (pivots, trend lines and support/resistance) remain active to provide structural context.
In this example the Money Flow module signals a net outflow. Price has been trending downward: successive high pivots form a falling red trend‑line and the low pivots form a descending green support line. When the latest bar broke below the previous low pivot (LL1), both the bar‑level and cumulative net dollar flow turned negative—selling volume at the close exceeded buying volume and pushed the cumulative Δ$ below zero. The module reacts by printing a red “Money flow out” label beneath the candle; the info table confirms that the “Money flow (bar)” and “Money flow Σ” rows both show Out, indicating sustained dominance of sellers in this period.
10. Info Table
10.1 Purpose
When enabled, the Info Table appears in the lower right of your chart. It summarises key values computed by the indicator—such as buy and sell volume, delta, total volume, breakout status, market phase, and money flow—so you can see at a glance which side is dominant and which signals are active.
10.2 Symbols
• ↑ / ↓ — Up (↑) denotes buy volume or money; down (↓) denotes sell volume or money.
• MA — Moving average. In the table it shows the average value of a series over the lookback period.
• Σ (Sigma) — Cumulative sum over the chosen lookback period.
• Δ (Delta) — Difference between buy and sell values.
• B / S — Buyer and seller share of total volume, expressed as percentages.
• Ref. Price — Reference price for breakout calculations, based on the latest pivot.
• Status — Indicates whether a breakout condition is currently active (True) or has failed.
10.3 Row definitions
1. Up volume / MA up volume – Displays current buy volume on the lower timeframe and its moving average over the lookback period.
2. Down volume / MA down volume – Shows current sell volume and its moving average; sell values are formatted in red for clarity.
3. Δ / ΣΔ – Lists the difference between buy and sell volume for the current bar and the cumulative delta volume over the lookback period.
4. Σ / MA Σ (Vol/MA) – Total volume (buy + sell) for the bar, with the ratio of this volume to its moving average; the right cell shows the average total volume.
5. B/S ratio – Buy and sell share of the total volume: current bar percentages and the average percentages across the lookback period.
6. Buyer Rank / Seller Rank – Ranks the bar’s buy and sell volumes among the last (n) bars; lower rank numbers indicate higher relative volume.
7. Σ Buy / Σ Sell – Sum of buy and sell volumes over the lookback window, indicating which side has traded more.
8. Breakout UP / DOWN – Shows the breakout thresholds (Ref. Price) and whether the breakout condition is active (True) or has failed.
9. Market Phase (Vol) – Reports the current volume‑only phase: Accumulation, Distribution or Neutral.
10. Money Flow – The final rows display dollar amounts and status:
– ↑ USD / Σ↑ USD – Buy dollars for the current bar and the cumulative sum over the money‑flow period.
– ↓ USD / Σ↓ USD – Sell dollars and their cumulative sum.
– Δ USD / ΣΔ USD – Net dollar difference (buy minus sell) for the bar and cumulatively.
– Money flow (bar) – Indicates whether the bar’s net dollar flow is positive (In), negative (Out) or neutral.
– Money flow Σ – Shows whether the cumulative net dollar flow across the chosen period is positive, negative or neutral.
The chart above shows a sequence of different signals from the indicator. A Bull Trap Risk appears after price briefly pushes above resistance but fails to hold, then a green Accum label identifies an accumulation phase. An upward breakout follows, confirmed by a Money flow in print. Later, a Sharp ↓ Risk warns of a possible sharp downturn; after price dips below support but quickly recovers, a Bear Trap label marks a false breakdown. The highlighted info table in the center summarizes key metrics at that moment, including current and average buy/sell volumes, net delta, total volume versus its moving average, breakout status (up and down), market phase (volume), and bar‑level and cumulative money flow (In/Out).
11. Conclusion & Final Remarks
This indicator was developed as a holistic study of market structure and order flow. It brings together several well‑known concepts from technical analysis—breakouts, accumulation and distribution phases, overbought and oversold extremes, bull and bear traps, sharp directional moves, market‑maker spread bars and money flow—into a single Pine Script tool. Each module is based on widely recognized trading ideas and was implemented after consulting reference materials and example strategies, so you can see in real time how these concepts interact on your chart.
A distinctive feature of this indicator is its reliance on per‑side volume: instead of tallying only total volume, it separately measures buy and sell transactions on a lower time frame. This approach gives a clearer view of who is in control—buyers or sellers—and helps filter breakouts, detect phases of accumulation or distribution, recognize potential traps, anticipate sharp moves and gauge whether liquidity providers are active. The money‑flow module extends this analysis by converting volume into currency values and tracking net inflow or outflow across a chosen window.
Although comprehensive, this indicator is intended solely as a guide. It highlights conditions and statistics that many traders find useful, but it does not generate trading signals or guarantee results. Ultimately, you remain responsible for your positions. Use the information presented here to inform your analysis, combine it with other tools and risk‑management techniques, and always make your own decisions when trading.
chrono_utilsLibrary "chrono_utils"
Collection of objects and common functions that are related to datetime windows session days and time
ranges. The main purpose of this library is to handle time-related functionality and make it easy to reason about a
future bar and see if it is part of a predefined user session and/or inside a datetime window. All existing session
functions I found in the documentation e.g. "not na(time(timeframe, session, timezone))" are not suitable for
strategies, since the execution of the orders is delayed by one bar due to the execution happening at the bar close.
So a prediction for the next bar is necessary. Moreover, a history operator with a negative value is not allowed e.g.
`not na(time(timeframe, session, timezone) )` expression is not valid. Thus, I created this library to overcome
this small but very important limitation. In the meantime, I added useful functionality to handle session-based
behavior. An interesting utility that emerged from this development is data anomaly detection where a comparison
between the prediction and the actual value is happening. If those two values are different then a data inconsistency
happens between the prediction bar and the actual bar (probably due to a holiday or half session day etc..)
exTimezone(timezone)
exTimezone - Convert extended timezone to timezone string
Parameters:
timezone (simple string) : - The timezone or a special string
Returns: string representing the timezone
nameOfDay(day)
nameOfDay - Convert the day id into a short nameOfDay
Parameters:
day (int) : - The day id to convert
Returns: - The short name of the day
today()
today - Get the day id of this day
Returns: - The day id
nthDayAfter(day, n)
nthDayAfter - Get the day id of n days after the given day
Parameters:
day (int) : - The day id of the reference day
n (int) : - The number of days to go forward
Returns: - The day id of the day that is n days after the reference day
nextDayAfter(day)
nextDayAfter - Get the day id of next day after the given day
Parameters:
day (int) : - The day id of the reference day
Returns: - The day id of the next day after the reference day
nthDayBefore(day, n)
nthDayBefore - Get the day id of n days before the given day
Parameters:
day (int) : - The day id of the reference day
n (int) : - The number of days to go forward
Returns: - The day id of the day that is n days before the reference day
prevDayBefore(day)
prevDayBefore - Get the day id of previous day before the given day
Parameters:
day (int) : - The day id of the reference day
Returns: - The day id of the previous day before the reference day
tomorrow()
tomorrow - Get the day id of the next day
Returns: - The next day day id
normalize(num, min, max)
normalizeHour - Check if number is inthe range of
Parameters:
num (int)
min (int)
max (int)
Returns: - The normalized number
normalizeHour(hourInDay)
normalizeHour - Check if hour is valid and return a noralized hour range from
Parameters:
hourInDay (int)
Returns: - The normalized hour
normalizeMinute(minuteInHour)
normalizeMinute - Check if minute is valid and return a noralized minute from
Parameters:
minuteInHour (int)
Returns: - The normalized minute
monthInMilliseconds(mon)
monthInMilliseconds - Calculate the miliseconds in one bar of the timeframe
Parameters:
mon (int) : - The month of reference to get the miliseconds
Returns: - The number of milliseconds of the month
barInMilliseconds()
barInMilliseconds - Calculate the miliseconds in one bar of the timeframe
Returns: - The number of milliseconds in one bar
method init(this, fromDateTime, toDateTime)
init - Initialize the time window object from boolean values of each session day
Namespace types: DateTimeWindow
Parameters:
this (DateTimeWindow) : - The time window object that will hold the from and to datetimes
fromDateTime (int) : - The starting datetime of the time window
toDateTime (int) : - The ending datetime of the time window
Returns: - The time window object
method init(this, refTimezone, chTimezone, fromDateTime, toDateTime)
init - Initialize the time window object from boolean values of each session day
Namespace types: DateTimeWindow
Parameters:
this (DateTimeWindow) : - The time window object that will hold the from and to datetimes
refTimezone (simple string) : - The timezone of reference of the 'from' and 'to' dates
chTimezone (simple string) : - The target timezone to convert the 'from' and 'to' dates
fromDateTime (int) : - The starting datetime of the time window
toDateTime (int) : - The ending datetime of the time window
Returns: - The time window object
method init(this, sun, mon, tue, wed, thu, fri, sat)
init - Initialize the session days object from boolean values of each session day
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object that will hold the day selection
sun (bool) : - Is Sunday a trading day?
mon (bool) : - Is Monday a trading day?
tue (bool) : - Is Tuesday a trading day?
wed (bool) : - Is Wednesday a trading day?
thu (bool) : - Is Thursday a trading day?
fri (bool) : - Is Friday a trading day?
sat (bool) : - Is Saturday a trading day?
Returns: - The session days objectfrom_chart
method init(this, unixTime)
init - Initialize the object from the hour and minute of the session time in exchange timezone (syminfo.timezone)
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
unixTime (int) : - The unix time
Returns: - The session time object
method init(this, hourInDay, minuteInHour)
init - Initialize the object from the hour and minute of the session time in exchange timezone (syminfo.timezone)
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
hourInDay (int) : - The hour of the time
minuteInHour (int) : - The minute of the time
Returns: - The session time object
method init(this, hourInDay, minuteInHour, refTimezone)
init - Initialize the object from the hour and minute of the session time
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
hourInDay (int) : - The hour of the time
minuteInHour (int) : - The minute of the time
refTimezone (string) : - The timezone of reference of the 'hour' and 'minute'
Returns: - The session time object
method init(this, startTime, endTime)
init - Initialize the object from the start and end session time in exchange timezone (syminfo.timezone)
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session
startTime (SessionTime) : - The time the session begins
endTime (SessionTime) : - The time the session ends
Returns: - The session time range object
method init(this, startTimeHour, startTimeMinute, endTimeHour, endTimeMinute, refTimezone)
init - Initialize the object from the start and end session time
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session
startTimeHour (int) : - The time hour the session begins
startTimeMinute (int) : - The time minute the session begins
endTimeHour (int) : - The time hour the session ends
endTimeMinute (int) : - The time minute the session ends
refTimezone (string)
Returns: - The session time range object
method init(this, days, timeRanges)
init - Initialize the user session object from session days and time range
Namespace types: UserSession
Parameters:
this (UserSession) : - The user-defined session object that will hold the day and the time range selection
days (SessionDays) : - The session days object that defines the days the session is happening
timeRanges (SessionTimeRange ) : - The array of all the session time ranges during a session day
Returns: - The user session object
method to_string(this)
to_string - Formats the time window into a human-readable string
Namespace types: DateTimeWindow
Parameters:
this (DateTimeWindow) : - The time window object with the from and to datetimes
Returns: - The string of the time window
method to_string(this)
to_string - Formats the session days into a human-readable string with short day names
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object with the day selection
Returns: - The string of the session day short names
method to_string(this)
to_string - Formats the session time into a human-readable string
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
Returns: - The string of the session time
method to_string(this)
to_string - Formats the session time into a human-readable string
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object with the start and end time of the daily session
Returns: - The string of the session time
method to_string(this)
to_string - Formats the user session into a human-readable string
Namespace types: UserSession
Parameters:
this (UserSession) : - The user-defined session object with the day and the time range selection
Returns: - The string of the user session
method to_string(this)
to_string - Formats the bar into a human-readable string
Namespace types: Bar
Parameters:
this (Bar) : - The bar object with the open and close times
Returns: - The string of the bar times
method to_string(this)
to_string - Formats the chart session into a human-readable string
Namespace types: ChartSession
Parameters:
this (ChartSession) : - The chart session object that contains the days and the time range shown in the chart
Returns: - The string of the chart session
method get_size_in_secs(this)
get_size_in_secs - Count the seconds from start to end in the given timeframe
Namespace types: DateTimeWindow
Parameters:
this (DateTimeWindow) : - The time window object with the from and to datetimes
Returns: - The number of seconds inside the time widow for the given timeframe
method get_size_in_secs(this)
get_size_in_secs - Calculate the seconds inside the session
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object with the start and end time of the daily session
Returns: - The number of seconds inside the session
method get_size_in_bars(this)
get_size_in_bars - Count the bars from start to end in the given timeframe
Namespace types: DateTimeWindow
Parameters:
this (DateTimeWindow) : - The time window object with the from and to datetimes
Returns: - The number of bars inside the time widow for the given timeframe
method get_size_in_bars(this)
get_size_in_bars - Calculate the bars inside the session
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object with the start and end time of the daily session
Returns: - The number of bars inside the session for the given timeframe
method from_chart(this)
from_chart - Initialize the session days object from the chart
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object that will hold the day selection
Returns: - The user session object
method from_chart(this)
from_chart - Initialize the session time range object from the chart
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session
Returns: - The session time range object
method from_chart(this)
from_chart - Initialize the session object from the chart
Namespace types: ChartSession
Parameters:
this (ChartSession) : - The chart session object that will hold the days and the time range shown in the chart
Returns: - The chart session object
method to_sess_string(this)
to_sess_string - Formats the session days into a session string with day ids
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object
Returns: - The string of the session day ids
method to_sess_string(this)
to_sess_string - Formats the session time into a session string
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
Returns: - The string of the session time
method to_sess_string(this)
to_sess_string - Formats the session time into a session string
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object with the start and end time of the daily session
Returns: - The string of the session time
method to_sess_string(this)
to_sess_string - Formats the user session into a session string
Namespace types: UserSession
Parameters:
this (UserSession) : - The user-defined session object with the day and the time range selection
Returns: - The string of the user session
method to_sess_string(this)
to_sess_string - Formats the chart session into a session string
Namespace types: ChartSession
Parameters:
this (ChartSession) : - The chart session object that contains the days and the time range shown in the chart
Returns: - The string of the chart session
method from_sess_string(this, sess)
from_sess_string - Initialize the session days object from the session string
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object that will hold the day selection
sess (string) : - The session string part that represents the days
Returns: - The session days object
method from_sess_string(this, sess)
from_sess_string - Initialize the session time object from the session string in exchange timezone (syminfo.timezone)
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object that will hold the hour and minute of the time
sess (string) : - The session string part that represents the time HHmm
Returns: - The session time object
method from_sess_string(this, sess, refTimezone)
from_sess_string - Initialize the session time object from the session string
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object that will hold the hour and minute of the time
sess (string) : - The session string part that represents the time HHmm
refTimezone (simple string) : - The timezone of reference of the 'hour' and 'minute'
Returns: - The session time object
method from_sess_string(this, sess)
from_sess_string - Initialize the session time range object from the session string in exchange timezone (syminfo.timezone)
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session
sess (string) : - The session string part that represents the time range HHmm-HHmm
Returns: - The session time range object
method from_sess_string(this, sess, refTimezone)
from_sess_string - Initialize the session time range object from the session string
Namespace types: SessionTimeRange
Parameters:
this (SessionTimeRange) : - The session time range object that will hold the start and end time of the daily session
sess (string) : - The session string part that represents the time range HHmm-HHmm
refTimezone (simple string) : - The timezone of reference of the time ranges
Returns: - The session time range object
method from_sess_string(this, sess)
from_sess_string - Initialize the user session object from the session string in exchange timezone (syminfo.timezone)
Namespace types: UserSession
Parameters:
this (UserSession) : - The user-defined session object that will hold the day and the time range selection
sess (string) : - The session string that represents the user session HHmm-HHmm,HHmm-HHmm:ddddddd
Returns: - The session time range object
method from_sess_string(this, sess, refTimezone)
from_sess_string - Initialize the user session object from the session string
Namespace types: UserSession
Parameters:
this (UserSession) : - The user-defined session object that will hold the day and the time range selection
sess (string) : - The session string that represents the user session HHmm-HHmm,HHmm-HHmm:ddddddd
refTimezone (simple string) : - The timezone of reference of the time ranges
Returns: - The session time range object
method nth_day_after(this, day, n)
nth_day_after - The nth day after the given day that is a session day (true) in the object
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object with the day selection
day (int) : - The day id of the reference day
n (int) : - The number of days after
Returns: - The day id of the nth session day of the week after the given day
method nth_day_before(this, day, n)
nth_day_before - The nth day before the given day that is a session day (true) in the object
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object with the day selection
day (int) : - The day id of the reference day
n (int) : - The number of days after
Returns: - The day id of the nth session day of the week before the given day
method next_day(this)
next_day - The next day that is a session day (true) in the object
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object with the day selection
Returns: - The day id of the next session day of the week
method previous_day(this)
previous_day - The previous day that is session day (true) in the object
Namespace types: SessionDays
Parameters:
this (SessionDays) : - The session days object with the day selection
Returns: - The day id of the previous session day of the week
method get_sec_in_day(this)
get_sec_in_day - Count the seconds since the start of the day this session time represents
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
Returns: - The number of seconds passed from the start of the day until that session time
method get_ms_in_day(this)
get_ms_in_day - Count the milliseconds since the start of the day this session time represents
Namespace types: SessionTime
Parameters:
this (SessionTime) : - The session time object with the hour and minute of the time of the day
Returns: - The number of milliseconds passed from the start of the day until that session time
method eq(this, other)
eq - Compare two bars
Namespace types: Bar
Parameters:
this (Bar) : - The bar object with the open and close times
other (Bar) : - The bar object to compare with
Returns: - Whether this bar is equal to the other one
method get_open_time(this)
get_open_time - The open time object
Namespace types: Bar
Parameters:
this (Bar) : - The bar object with the open and close times
Returns: - The open time object
method get_close_time(this)
get_close_time - The close time object
Namespace types: Bar
Parameters:
this (Bar) : - The bar object with the open and close times
Returns: - The close time object
method get_time_range(this)
get_time_range - Get the time range of the bar
Namespace types: Bar
Parameters:
this (Bar) : - The bar object with the open and close times
Returns: - The time range that the bar is in
getBarNow()
getBarNow - Get the current bar object with time and time_close timestamps
Returns: - The current bar
getFixedBarNow()
getFixedBarNow - Get the current bar with fixed width defined by the timeframe. Note: There are case like SPX 15min timeframe where the last session bar is only 10min. This will return a bar of 15 minutes
Returns: - The current bar
method is_in_window(this, win)
is_in_window - Check if the given bar is between the start and end dates of the window
Namespace types: Bar
Parameters:
this (Bar) : - The bar to check if it is between the from and to datetimes of the window
win (DateTimeWindow) : - The time window object with the from and to datetimes
Returns: - Whether the current bar is inside the datetime window
method is_in_timerange(this, rng)
is_in_timerange - Check if the given bar is inside the session time range
Namespace types: Bar
Parameters:
this (Bar) : - The bar to check if it is between the from and to datetimes
rng (SessionTimeRange) : - The session time range object with the start and end time of the daily session
Returns: - Whether the bar is inside the session time range and if this part of the next trading day
method is_in_days(this, days)
is_in_days - Check if the given bar is inside the session days
Namespace types: Bar
Parameters:
this (Bar) : - The bar to check if its day is a trading day
days (SessionDays) : - The session days object with the day selection
Returns: - Whether the current bar day is inside the session
method is_in_session(this, sess)
is_in_session - Check if the given bar is inside the session as defined by the input params (what "not na(time(timeframe.period, this.to_sess_string()) )" should return if you could write it
Namespace types: Bar
Parameters:
this (Bar) : - The bar to check if it is between the from and to datetimes
sess (UserSession) : - The user-defined session object with the day and the time range selection
Returns: - Whether the current time is inside the session
method next_bar(this, offsetBars)
next_bar - Predicts the next bars open and close time based on the charts session
Namespace types: ChartSession
Parameters:
this (ChartSession) : - The chart session object that contains the days and the time range shown in the chart
offsetBars (simple int) : - The number of bars forward
Returns: - Whether the current time is inside the session
DateTimeWindow
DateTimeWindow - Object that represents a datetime window with a beginning and an end
Fields:
fromDateTime (series int) : - The beginning of the datetime window
toDateTime (series int) : - The end of the datetime window
SessionDays
SessionDays - Object that represent the trading days of the week
Fields:
days (map) : - The map that contains all days of the week and their session flag
SessionTime
SessionTime - Object that represents the time (hour and minutes)
Fields:
hourInDay (series int) : - The hour of the day that ranges from 0 to 24
minuteInHour (series int) : - The minute of the hour that ranges from 0 to 59
minuteInDay (series int) : - The minute of the day that ranges from 0 to 1440. They will be calculated based on hourInDay and minuteInHour when method is called
SessionTimeRange
SessionTimeRange - Object that represents a range that extends from the start to the end time
Fields:
startTime (SessionTime) : - The beginning of the time range
endTime (SessionTime) : - The end of the time range
isOvernight (series bool) : - Whether or not this is an overnight time range
UserSession
UserSession - Object that represents a user-defined session
Fields:
days (SessionDays) : - The map of the user-defined trading days
timeRanges (SessionTimeRange ) : - The array with all time ranges of the user-defined session during the trading days
Bar
Bar - Object that represents the bars' open and close times
Fields:
openUnixTime (series int) : - The open time of the bar
closeUnixTime (series int) : - The close time of the bar
chartDayOfWeek (series int)
ChartSession
ChartSession - Object that represents the default session that is shown in the chart
Fields:
days (SessionDays) : - A map with the trading days shown in the chart
timeRange (SessionTimeRange) : - The time range of the session during a trading day
isFinalized (series bool)
`security()` revisited [PineCoders]NOTE
The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work.
█ OVERVIEW
This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders.
We will discuss:
• How to use our new `f_security()` function.
• The behavior of Pine code and security() on the three very different types of bars that make up any chart.
• Why what you see on a chart is a simulation, and should be taken with a grain of salt.
• Why we are presenting a new version of a function handling security() calls.
• Other topics of interest to coders using higher timeframe (HTF) data.
█ WARNING
We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use:
f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src )
previousDayClose = f_security(syminfo.tickerid, "D", close, false)
If that's all you're interested in, you are done.
If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice.
Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing.
What is a chart?
A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars.
Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit.
█ FEATURES
This script's "Inputs" tab has four settings:
• Repaint : Determines whether the functions will use their repainting or non-repainting mode.
Note that the setting will not affect the behavior of the yellow plot, as it always repaints.
• Source : The source fetched by the security() calls.
• Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.
• Show timeframe reminder : Displays a reminder of the timeframe after the last bar.
█ THE CHART
The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:
A — The type of chart bars we are looking at, indicated by the colored band at the top.
B — The plots resulting of calling security() with the close price in different ways.
C — Points of interest on the chart.
A — Chart bars
The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:
1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.
2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.
The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.
3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active.
Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars.
B — Plots
The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:
1 — Yellow : A normal, repainting security() call.
2 — Silver : Our recommended security() function.
3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.
4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.
5 — Black : A lame attempt at fooling traders that MUST be avoided.
All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior.
C — Points of interest on the chart
Historical bars do not show actual repainting behavior
To appreciate what a repainting security() call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update.
Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars.
Non-repainting plots are more accurate on historical bars
Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time:
The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless.
► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.
The other is that in realtime, your script will be using more reliable data and behave more consistently.
Misleading plots
Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests.
When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist.
You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late.
Data Window
The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars:
security(ticker, i_timeframe, i_source )
// which is equivalent to:
security(ticker, i_timeframe, i_source)
When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar:
// Historical bars:
security(ticker, i_timeframe, i_source )
// Realtime bar (and thus, elapsed realtime bars):
security(ticker, i_timeframe, i_source )
The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting.
In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe.
After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations.
█ NOTES
Why are we revisiting security() ?
For four reasons:
1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .
Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,
which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.
We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.
2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose
a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.
3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.
4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting.
Handling tuples
When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example.
Does it repaint?
We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does.
As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description.
► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close.
Data feeds
A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes.
Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data.
Alternatives
There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice.
When `lookahead` is useful
When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts.
Warning users
Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call.
Intrabar timeframes
security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this.
█ TERMINOLOGY
Timeframe
Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term.
Multi-timeframe (MTF)
Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative Volume at Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries.
Colophon
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function.
█ THANKS
Thanks to apozdnyakov for his help with the innards of security() .
Thanks to bmistiaen for proofreading our description.
Look first. Then leap.
Waindrops [Makit0]█ OVERALL
Plot waindrops (custom volume profiles) on user defined periods, for each period you get high and low, it slices each period in half to get independent vwap, volume profile and the volume traded per price at each half.
It works on intraday charts only, up to 720m (12H). It can plot balanced or unbalanced waindrops, and volume profiles up to 24H sessions.
As example you can setup unbalanced periods to get independent volume profiles for the overnight and cash sessions on the futures market, or 24H periods to get the full session volume profile of EURUSD
The purpose of this indicator is twofold:
1 — from a Chartist point of view, to have an indicator which displays the volume in a more readable way
2 — from a Pine Coder point of view, to have an example of use for two very powerful tools on Pine Script:
• the recently updated drawing limit to 500 (from 50)
• the recently ability to use drawings arrays (lines and labels)
If you are new to Pine Script and you are learning how to code, I hope you read all the code and comments on this indicator, all is designed for you,
the variables and functions names, the sometimes too big explanations, the overall structure of the code, all is intended as an example on how to code
in Pine Script a specific indicator from a very good specification in form of white paper
If you wanna learn Pine Script form scratch just start HERE
In case you have any kind of problem with Pine Script please use some of the awesome resources at our disposal: USRMAN , REFMAN , AWESOMENESS , MAGIC
█ FEATURES
Waindrops are a different way of seeing the volume and price plotted in a chart, its a volume profile indicator where you can see the volume of each price level
plotted as a vertical histogram for each half of a custom period. By default the period is 60 so it plots an independent volume profile each 30m
You can think of each waindrop as an user defined candlestick or bar with four key values:
• high of the period
• low of the period
• left vwap (volume weighted average price of the first half period)
• right vwap (volume weighted average price of the second half period)
The waindrop can have 3 different colors (configurable by the user):
• GREEN: when the right vwap is higher than the left vwap (bullish sentiment )
• RED: when the right vwap is lower than the left vwap (bearish sentiment )
• BLUE: when the right vwap is equal than the left vwap ( neutral sentiment )
KEY FEATURES
• Help menu
• Custom periods
• Central bars
• Left/Right VWAPs
• Custom central bars and vwaps: color and pixels
• Highly configurable volume histogram: execution window, ticks, pixels, color, update frequency and fine tuning the neutral meaning
• Volume labels with custom size and color
• Tracking price dot to be able to see the current price when you hide your default candlesticks or bars
█ SETTINGS
Click here or set any impar period to see the HELP INFO : show the HELP INFO, if it is activated the indicator will not plot
PERIOD SIZE (max 2880 min) : waindrop size in minutes, default 60, max 2880 to allow the first half of a 48H period as a full session volume profile
BARS : show the central and vwap bars, default true
Central bars : show the central bars, default true
VWAP bars : show the left and right vwap bars, default true
Bars pixels : width of the bars in pixels, default 2
Bars color mode : bars color behavior
• BARS : gets the color from the 'Bars color' option on the settings panel
• HISTOGRAM : gets the color from the Bearish/Bullish/Neutral Histogram color options from the settings panel
Bars color : color for the central and vwap bars, default white
HISTOGRAM show the volume histogram, default true
Execution window (x24H) : last 24H periods where the volume funcionality will be plotted, default 5
Ticks per bar (max 50) : width in ticks of each histogram bar, default 2
Updates per period : number of times the histogram will update
• ONE : update at the last bar of the period
• TWO : update at the last bar of each half period
• FOUR : slice the period in 4 quarters and updates at the last bar of each of them
• EACH BAR : updates at the close of each bar
Pixels per bar : width in pixels of each histogram bar, default 4
Neutral Treshold (ticks) : delta in ticks between left and right vwaps to identify a waindrop as neutral, default 0
Bearish Histogram color : histogram color when right vwap is lower than left vwap, default red
Bullish Histogram color : histogram color when right vwap is higher than left vwap, default green
Neutral Histogram color : histogram color when the delta between right and left vwaps is equal or lower than the Neutral treshold, default blue
VOLUME LABELS : show volume labels
Volume labels color : color for the volume labels, default white
Volume Labels size : text size for the volume labels, choose between AUTO, TINY, SMALL, NORMAL or LARGE, default TINY
TRACK PRICE : show a yellow ball tracking the last price, default true
█ LIMITS
This indicator only works on intraday charts (minutes only) up to 12H (720m), the lower chart timeframe you can use is 1m
This indicator needs price, time and volume to work, it will not work on an index (there is no volume), the execution will not be allowed
The histogram (volume profile) can be plotted on 24H sessions as limit but you can plot several 24H sessions
█ ERRORS AND PERFORMANCE
Depending on the choosed settings, the script performance will be highly affected and it will experience errors
Two of the more common errors it can throw are:
• Calculation takes too long to execute
• Loop takes too long
The indicator performance is highly related to the underlying volatility (tick wise), the script takes each candlestick or bar and for each tick in it stores the price and volume, if the ticker in your chart has thousands and thousands of ticks per bar the indicator will throw an error for sure, it can not calculate in time such amount of ticks.
What all of that means? Simply put, this will throw error on the BITCOIN pair BTCUSD (high volatility with tick size 0.01) because it has too many ticks per bar, but lucky you it will work just fine on the futures contract BTC1! (tick size 5) because it has a lot less ticks per bar
There are some options you can fine tune to boost the script performance, the more demanding option in terms of resources consumption is Updates per period , by default is maxed out so lowering this setting will improve the performance in a high way.
If you wanna know more about how to improve the script performance, read the HELP INFO accessible from the settings panel
█ HOW-TO SETUP
The basic parameters to adjust are Period size , Ticks per bar and Pixels per bar
• Period size is the main setting, defines the waindrop size, to get a better looking histogram set bigger period and smaller chart timeframe
• Ticks per bar is the tricky one, adjust it differently for each underlying (ticker) volatility wise, for some you will need a low value, for others a high one.
To get a more accurate histogram set it as lower as you can (min value is 1)
• Pixels per bar allows you to adjust the width of each histogram bar, with it you can adjust the blank space between them or allow overlaping
You must play with these three parameters until you obtain the desired histogram: smoother, sharper, etc...
These are some of the different kind of charts you can setup thru the settings:
• Balanced Waindrops (default): charts with waindrops where the two halfs are of same size.
This is the default chart, just select a period (30m, 60m, 120m, 240m, pick your poison), adjust the histogram ticks and pixels and watch
• Unbalanced Waindrops: chart with waindrops where the two halfs are of different sizes.
Do you trade futures and want to plot a waindrop with the first half for the overnight session and the second half for the cash session? you got it;
just adjust the period to 1860 for any CME ticker (like ES1! for example) adjust the histogram ticks and pixels and watch
• Full Session Volume Profile: chart with waindrops where only the first half plots.
Do you use Volume profile to analize the market? Lucky you, now you can trick this one to plot it, just try a period of 780 on SPY, 2760 on ES1!, or 2880 on EURUSD
remember to adjust the histogram ticks and pixels for each underlying
• Only Bars: charts with only central and vwap bars plotted, simply deactivate the histogram and volume labels
• Only Histogram: charts with only the histogram plotted (volume profile charts), simply deactivate the bars and volume labels
• Only Volume: charts with only the raw volume numbers plotted, simply deactivate the bars and histogram
If you wanna know more about custom full session periods for different asset classes, read the HELP INFO accessible from the settings panel
EXAMPLES
Full Session Volume Profile on MES 5m chart:
Full Session Unbalanced Waindrop on MNQ 2m chart (left side Overnight session, right side Cash Session):
The following examples will have the exact same charts but on four different tickers representing a futures contract, a forex pair, an etf and a stock.
We are doing this to be able to see the different parameters we need for plotting the same kind of chart on different assets
The chart composition is as follows:
• Left side: Volume Labels chart (period 10)
• Upper Right side: Waindrops (period 60)
• Lower Right side: Full Session Volume Profile
The first example will specify the main parameters, the rest of the charts will have only the differences
MES :
• Left: Period size: 10, Bars: uncheck, Histogram: uncheck, Execution window: 1, Ticks per bar: 2, Updates per period: EACH BAR,
Pixels per bar: 4, Volume labels: check, Track price: check
• Upper Right: Period size: 60, Bars: check, Bars color mode: HISTOGRAM, Histogram: check, Execution window: 2, Ticks per bar: 2,
Updates per period: EACH BAR, Pixels per bar: 4, Volume labels: uncheck, Track price: check
• Lower Right: Period size: 2760, Bars: uncheck, Histogram: check, Execution window: 1, Ticks per bar: 1, Updates per period: EACH BAR,
Pixels per bar: 2, Volume labels: uncheck, Track price: check
EURUSD :
• Upper Right: Ticks per bar: 10
• Lower Right: Period size: 2880, Ticks per bar: 1, Pixels per bar: 1
SPY :
• Left: Ticks per bar: 3
• Upper Right: Ticks per bar: 5, Pixels per bar: 3
• Lower Right: Period size: 780, Ticks per bar: 2, Pixels per bar: 2
AAPL :
• Left: Ticks per bar: 2
• Upper Right: Ticks per bar: 6, Pixels per bar: 3
• Lower Right: Period size: 780, Ticks per bar: 1, Pixels per bar: 2
█ THANKS TO
PineCoders for all they do, all the tools and help they provide and their involvement in making a better community
scarf for the idea of coding a waindrops like indicator, I did not know something like that existed at all
All the Pine Coders, Pine Pros and Pine Wizards, people who share their work and knowledge for the sake of it and helping others, I'm very grateful indeed
I'm learning at each step of the way from you all, thanks for this awesome community;
Opensource and shared knowledge: this is the way! (said with canned voice from inside my helmet :D)
█ NOTE
This description was formatted following THIS guidelines
═════════════════════════════════════════════════════════════════════════
I sincerely hope you enjoy reading and using this work as much as I enjoyed developing it :D
GOOD LUCK AND HAPPY TRADING!
Delta Volume Columns Pro [LucF]█ OVERVIEW
This indicator displays volume delta information calculated with intrabar inspection on historical bars, and feed updates when running in realtime. It is designed to run in a pane and can display either stacked buy/sell volume columns or a signal line which can be calculated and displayed in many different ways.
Five different models are offered to reveal different characteristics of the calculated volume delta information. Many options are offered to visualize the calculations, giving you much leeway in morphing the indicator's visuals to suit your needs. If you value delta volume information, I hope you will find the time required to master Delta Volume Columns Pro well worth the investment. I am confident that if you combine a proper understanding of the indicator's information with an intimate knowledge of the volume idiosyncrasies on the markets you trade, you can extract useful market intelligence using this tool.
█ WARNINGS
1. The indicator only works on markets where volume information is available,
Please validate that your symbol's feed carries volume information before asking me why the indicator doesn't plot values.
2. When you refresh your chart or re-execute the script on the chart, the indicator will repaint because elapsed realtime bars will then recalculate as historical bars.
3. Because the indicator uses different modes of calculation on historical and realtime bars, it's critical that you understand the differences between them. Details are provided further down.
4. Calculations using intrabar inspection on historical bars can only be done from some chart timeframes. See further down for a list of supported timeframes.
If the chart's timeframe is not supported, no historical volume delta will display.
█ CONCEPTS
Chart bars
Three different types of bars are used in charts:
1. Historical bars are bars that have already closed when the script executes on them.
2. The realtime bar is the current, incomplete bar where a script is running on an open market. There is only one active realtime bar on your chart at any given time.
The realtime bar is where alerts trigger.
3. Elapsed realtime bars are bars that were calculated when they were realtime bars but have since closed.
When a script re-executes on a chart because the browser tab is refreshed or some of its inputs are changed, elapsed realtime bars are recalculated as historical bars.
Why does this indicator use two modes of calculation?
Historical bars on TradingView charts contain OHLCV data only, which is insufficient to calculate volume delta on them with any level of precision. To mine more detailed information from those bars we look at intrabars , i.e., bars from a smaller timeframe (we call it the intrabar timeframe ) that are contained in one chart bar. If your chart Is running at 1D on a 24x7 market for example, most 1D chart bars will contain 24 underlying 1H bars in their dilation. On historical bars, this indicator looks at those intrabars to amass volume delta information. If the intrabar is up, its volume goes in the Buy bin, and inversely for the Sell bin. When price does not move on an intrabar, the polarity of the last known movement is used to determine in which bin its volume goes.
In realtime, we have access to price and volume change for each update of the chart. Because a 1D chart bar can be updated tens of thousands of times during the day, volume delta calculations on those updates is much more precise. This precision, however, comes at a price:
— The script must be running on the chart for it to keep calculating in realtime.
— If you refresh your chart you will lose all accumulated realtime calculations on elapsed realtime bars, and the realtime bar.
Elapsed realtime bars will recalculate as historical bars, i.e., using intrabar inspection, and the realtime bar's calculations will reset.
When the script recalculates elapsed realtime bars as historical bars, the values on those bars will change, which means the script repaints in those conditions.
— When the indicator first calculates on a chart containing an incomplete realtime bar, it will count ALL the existing volume on the bar as Buy or Sell volume,
depending on the polarity of the bar at that point. This will skew calculations for that first bar. Scripts have no access to the history of a realtime bar's previous updates,
and intrabar inspection cannot be used on realtime bars, so this is the only to go about this.
— Even if alerts only trigger upon confirmation of their conditions after the realtime bar closes, they are repainting alerts
because they would perhaps not have calculated the same way using intrabar inspection.
— On markets like stocks that often have different EOD and intraday feeds and volume information,
the volume's scale may not be the same for the realtime bar if your chart is at 1D, for example,
and the indicator is using an intraday timeframe to calculate on historical bars.
— Any chart timeframe can be used in realtime mode, but plots that include moving averages in their calculations may require many elapsed realtime bars before they can calculate.
You might prefer drastically reducing the periods of the moving averages, or using the volume columns mode, which displays instant values, instead of the line.
Volume Delta Balances
This indicator uses a variety of methods to evaluate five volume delta balances and derive other values from those balances. The five balances are:
1 — On Bar Balance : This is the only balance using instant values; it is simply the subtraction of the Sell volume from the Buy volume on the bar.
2 — Average Balance : Calculates a distinct EMA for both the Buy and Sell volumes, and subtracts the Sell EMA from the Buy EMA.
3 — Momentum Balance : Starts by calculating, separately for both Buy and Sell volumes, the difference between the same EMAs used in "Average Balance" and
an SMA of double the period used for the "Average Balance" EMAs. The difference for the Sell side is subtracted from the difference for the Buy side,
and an RSI of that value is calculated and brought over the −50/+50 scale.
4 — Relative Balance : The reference values used in the calculation are the Buy and Sell EMAs used in the "Average Balance".
From those, we calculate two intermediate values using how much the instant Buy and Sell volumes on the bar exceed their respective EMA — but with a twist.
If the bar's Buy volume does not exceed the EMA of Buy volume, a zero value is used. The same goes for the Sell volume with the EMA of Sell volume.
Once we have our two intermediate values for the Buy and Sell volumes exceeding their respective MA, we subtract them. The final "Relative Balance" value is an ALMA of that subtraction.
The rationale behind using zero values when the bar's Buy/Sell volume does not exceed its EMA is to only take into account the more significant volume.
If both instant volume values exceed their MA, then the difference between the two is the signal's value.
The signal is called "relative" because the intermediate values are the difference between the instant Buy/Sell volumes and their respective MA.
This balance flatlines when the bar's Buy/Sell volumes do not exceed their EMAs, which makes it useful to spot areas where trader interest dwindles, such as consolidations.
The smaller the period of the final value's ALMA, the more easily you will see the balance flatline. These flat zones should be considered no-trade zones.
5 — Percent Balance : This balance is the ALMA of the ratio of the "On Bar Balance" value, i.e., the volume delta balance on the bar (which can be positive or negative),
over the total volume for that bar.
From the balances and marker conditions, two more values are calculated:
1 — Marker Bias : It sums the up/down (+1/‒1) occurrences of the markers 1 to 4 over a period you define, so it ranges from −4 to +4, times the period.
Its calculation will depend on the modes used to calculate markers 3 and 4.
2 — Combined Balances : This is the sum of the bull/bear (+1/−1) states of each of the five balances, so it ranges from −5 to +5.
█ FEATURES
The indicator has two main modes of operation: Columns and Line .
Columns
• In Columns mode you can display stacked Buy/Sell volume columns.
• The buy section always appears above the centerline, the sell section below.
• The top and bottom sections can be colored independently using eight different methods.
• The EMAs of the Buy/Sell values can be displayed (these are the same EMAs used to calculate the "Average Balance").
Line
• Displays one of seven signals: the five balances or one of two complementary values, i.e., the "Marker Bias" or the "Combined Balances".
• You can color the line and its fill using independent calculation modes to pack more information in the display.
You can thus appraise the state of 3 different values using the line itself, its color and the color of its fill.
• A "Divergence Levels" feature will use the line to automatically draw expanding levels on divergence events.
Default settings
Using the indicator's default settings, this is the information displayed:
• The line is calculated on the "Average Balance".
• The line's color is determined by the bull/bear state of the "Percent Balance".
• The line's fill gradient is determined by the advances/declines of the "Momentum Balance".
• The orange divergence dots are calculated using discrepancies between the polarity of the "On Bar Balance" and the chart's bar.
• The divergence levels are determined using the line's level when a divergence occurs.
• The background's fill gradient is calculated on advances/declines of the "Marker Bias".
• The chart bars are colored using advances/declines of the "Relative Balance". Divergences are shown in orange.
• The intrabar timeframe is automatically determined from the chart's timeframe so that a minimum of 50 intrabars are used to calculate volume delta on historical bars.
Alerts
The configuration of the marker conditions explained further is what determines the conditions that will trigger alerts created from this script. Note that simply selecting the display of markers does not create alerts. To create an alert on this script, you must use ALT-A from the chart. You can create multiple alerts triggering on different conditions from this same script; simply configure the markers so they define the trigger conditions for each alert before creating the alert. The configuration of the script's inputs is saved with the alert, so from then on you can change them without affecting the alert. Alert messages will mention the marker(s) that triggered the specific alert event. Keep in mind, when creating alerts on small chart timeframes, that discrepancies between alert triggers and markers displayed on your chart are to be expected. This is because the alert and your chart are running two distinct instances of the indicator on different servers and different feeds. Also keep in mind that while alerts only trigger on confirmed conditions, they are calculated using realtime calculation mode, which entails that if you refresh your chart and elapsed realtime bars recalculate as historical bars using intrabar inspection, markers will not appear in the same places they appeared in realtime. So it's important to understand that even though the alert conditions are confirmed when they trigger, these alerts will repaint.
Let's go through the sections of the script's inputs.
Columns
The size of the Buy/Sell columns always represents their respective importance on the bar, but the coloring mode for tops and bottoms is independent. The default setup uses a standard coloring mode where the Buy/Sell columns are always in the bull/bear color with a higher intensity for the winning side. Seven other coloring modes allow you to pack more information in the columns. When choosing to color the top columns using a bull/bear gradient on "Average Balance", for example, you will have bull/bear colored tops. In order for the color of the bottom columns to continue to show the instant bar balance, you can then choose the "On Bar Balance — Dual Solid Colors" coloring mode to make those bars the color of the winning side for that bar. You can display the averages of the Buy and Sell columns. If you do, its coloring is controlled through the "Line" and "Line fill" sections below.
Line and Line fill
You can select the calculation mode and the thickness of the line, and independent calculations to determine the line's color and fill.
Zero Line
The zero line can display dots when all five balances are bull/bear.
Divergences
You first select the detection mode. Divergences occur whenever the up/down direction of the signal does not match the up/down polarity of the bar. Divergences are used in three components of the indicator's visuals: the orange dot, colored chart bars, and to calculate the divergence levels on the line. The divergence levels are dynamic levels that automatically build from the line's values on divergence events. On consecutive divergences, the levels will expand, creating a channel. This implementation of the divergence levels corresponds to my view that divergences indicate anomalies, hesitations, points of uncertainty if you will. It precludes any attempt to identify a directional bias to divergences. Accordingly, the levels merely take note of divergence events and mark those points in time with levels. Traders then have a reference point from which they can evaluate further movement. The bull/bear/neutral colors used to plot the levels are also congruent with this view in that they are determined by the line's position relative to the levels, which is how I think divergences can be put to the most effective use. One of the coloring modes for the line's fill uses advances/declines in the line after divergence events.
Background
The background can show a bull/bear gradient on six different calculations. As with other gradients, you can adjust its brightness to make its importance proportional to how you use it in your analysis.
Chart bars
Chart bars can be colored using seven different methods. You have the option of emptying the body of bars where volume does not increase, as does my TLD indicator, and you can choose whether you want to show divergences.
Intrabar Timeframe
This is the intrabar timeframe that will be used to calculate volume delta using intrabar inspection on historical bars. You can choose between four modes. The three "Auto-steps" modes calculate, from the chart's timeframe, the intrabar timeframe where the said number of intrabars will make up the dilation of chart bars. Adjustments are made for non-24x7 markets. "Fixed" mode allows you to select the intrabar timeframe you want. Checking the "Show TF" box will display in the lower-right corner the intrabar timeframe used at any given moment. The proper selection of the intrabar timeframe is important. It must achieve maximal granularity to produce precise results while not unduly slowing down calculations, or worse, causing runtime errors. Note that historical depth will vary with the intrabar timeframe. The smaller the timeframe, the shallower historical plots you will be.
Markers
Markers appear when the required condition has been confirmed on a closed bar. The configuration of the markers when you create an alert is what determines when the alert will trigger. Five markers are available:
• Balances Agreement : All five balances are either bullish or bearish.
• Double Bumps : A double bump is two consecutive up/down bars with +/‒ volume delta, and rising Buy/Sell volume above its average.
• Divergence confirmations : A divergence is confirmed up/down when the chosen balance is up/down on the previous bar when that bar was down/up, and this bar is up/down.
• Balance Shifts : These are bull/bear transitions of the selected signal.
• Marker Bias Shifts : Marker bias shifts occur when it crosses into bull/bear territory.
Periods
Allows control over the periods of the different moving averages used to calculate the balances.
Volume Discrepancies
Stock exchanges do not report the same volume for intraday and daily (or higher) resolutions. Other variations in how volume information is reported can also occur in other markets, namely Forex, where volume irregularities can even occur between different intraday timeframes. This will cause discrepancies between the total volume on the bar at the chart's timeframe, and the total volume calculated by adding the volume of the intrabars in that bar's dilation. This does not necessarily invalidate the volume delta information calculated from intrabars, but it tells us that we are using partial volume data. A mechanism to detect chart vs intrabar timeframe volume discrepancies is provided. It allows you to define a threshold percentage above which the background will indicate a difference has been detected.
Other Settings
You can control here the display of the gray dot reminder on realtime bars, and the display of error messages if you are using a chart timeframe that is not greater than the fixed intrabar timeframe, when you use that mode. Disabling the message can be useful if you only use realtime mode at chart timeframes that do not support intrabar inspection.
█ RAMBLINGS
On Volume Delta
Volume is arguably the best complement to interpret price action, and I consider volume delta to be the most effective way of processing volume information. In periods of low-volatility price consolidations, volume will typically also be lower than normal, but slight imbalances in the trend of the buy/sell volume balance can sometimes help put early odds on the direction of the break from consolidation. Additionally, the progression of the volume imbalance can help determine the proximity of the breakout. I also find volume delta and the number of divergences very useful to evaluate the strength of trends. In trends, I am looking for "slow and steady", i.e., relatively low volatility and pauses where price action doesn't look like world affairs are being reassessed. In my personal mythology, this type of trend is often more resilient than high-volatility breakouts, especially when volume balance confirms the general agreement of traders signaled by the low-volatility usually accompanying this type of trend. The volume action on pauses will often help me decide between aggressively taking profits, tightening a stop or going for a longer-term movement. As for reversals, they generally occur in high-volatility areas where entering trades is more expensive and riskier. While the identification of counter-trend reversals fascinates many traders to no end, they represent poor opportunities in my view. Volume imbalances often precede reversals, but I prefer to use volume delta information to identify the areas following reversals where I can confirm them and make relatively low-cost entries with better odds.
On "Buy/Sell" Volume
Buying or selling volume are misnomers, as every unit of volume transacted is both bought and sold by two different traders. While this does not keep me from using the terms, there is no such thing as “buy only” or “sell only” volume. Trader lingo is riddled with peculiarities.
Divergences
The divergence detection method used here relies on a difference between the direction of a signal and the polarity (up/down) of a chart bar. When using the default "On Bar Balance" to detect divergences, however, only the bar's volume delta is used. You may wonder how there can be divergences between buying/selling volume information and price movement on one bar. This will sometimes be due to the calculation's shortcomings, but divergences may also occur in instances where because of order book structure, it takes less volume to increase the price of an asset than it takes to decrease it. As usual, divergences are points of interest because they reveal imbalances, which may or may not become turning points. To your pattern-hungry brain, the divergences displayed by this indicator will — as they do on other indicators — appear to often indicate turnarounds. My opinion is that reality is generally quite sobering and I have no reliable information that would tend to prove otherwise. Exercise caution when using them. Consequently, I do not share the overwhelming enthusiasm of traders in identifying bullish/bearish divergences. For me, the best course of action when a divergence occurs is to wait and see what happens from there. That is the rationale underlying how my divergence levels work; they take note of a signal's level when a divergence occurs, and it's the signal's behavior from that point on that determines if the post-divergence action is bullish/bearish.
Superfluity
In "The Bed of Procrustes", Nassim Nicholas Taleb writes: To bankrupt a fool, give him information . This indicator can display lots of information. While learning to use a new indicator inevitably requires an adaptation period where we put it through its paces and try out all its options, once you have become used to it and decide to adopt it, rigorously eliminate the components you don't use and configure the remaining ones so their visual prominence reflects their relative importance in your analysis. I tried to provide flexible options for traders to control this indicator's visuals for that exact reason — not for window dressing.
█ LIMITATIONS
• This script uses a special characteristic of the `security()` function allowing the inspection of intrabars — which is not officially supported by TradingView.
It has the advantage of permitting a more robust calculation of volume delta than other methods on historical bars, but also has its limits.
• Intrabar inspection only works on some chart timeframes: 3, 5, 10, 15 and 30 minutes, 1, 2, 3, 4, 6, and 12 hours, 1 day, 1 week and 1 month.
The script’s code can be modified to run on other resolutions.
• When the difference between the chart’s timeframe and the intrabar timeframe is too great, runtime errors will occur. The Auto-Steps selection mechanisms should avoid this.
• All volume is not created equally. Its source, components, quality and reliability will vary considerably with sectors and instruments.
The higher the quality, the more reliably volume delta information can be used to guide your decisions.
You should make it your responsibility to understand the volume information provided in the data feeds you use. It will help you make the most of volume delta.
█ NOTES
For traders
• The Data Window shows key values for the indicator.
• While this indicator displays some of the same information calculated in my Delta Volume Columns ,
I have elected to make it a separate publication so that traders continue to have a simpler alternative available to them. Both code bases will continue to evolve separately.
• All gradients used in this indicator determine their brightness intensities using advances/declines in the signal—not their relative position in a pre-determined scale.
• Volume delta being relative, by nature, it is particularly well-suited to Forex markets, as it filters out quite elegantly the cyclical volume data characterizing the sector.
If you are interested in volume delta, consider having a look at my other "Delta Volume" indicators:
• Delta Volume Realtime Action displays realtime volume delta and tick information on the chart.
• Delta Volume Candles builds volume delta candles on the chart.
• Delta Volume Columns is a simpler version of this indicator.
For coders
• I use the `f_c_gradientRelativePro()` from the PineCoders Color Gradient Framework to build my gradients.
This function has the advantage of allowing begin/end colors for both the bull and bear colors. It also allows us to define the number of steps allowed for each gradient.
I use this to modulate the gradients so they perform optimally on the combination of the signal used to calculate advances/declines,
but also the nature of the visual component the gradient applies to. I use fewer steps for choppy signals and when the gradient is used on discrete visual components
such as volume columns or chart bars.
• I use the PineCoders Coding Conventions for Pine to write my scripts.
• I used functions modified from the PineCoders MTF Selection Framework for the selection of timeframes.
█ THANKS TO:
— The devs from TradingView's Pine and other teams, and the PineCoders who collaborate with them. They are doing amazing work,
and much of what this indicator does could not be done without their recent improvements to Pine.
— A guy called Kuan who commented on a Backtest Rookies presentation of their Volume Profile indicator using a `for` loop.
This indicator started from the intrabar inspection technique illustrated in Kuan's snippet.
— theheirophant , my partner in the exploration of the sometimes weird abysses of `security()`’s behavior at intrabar timeframes.
— midtownsk8rguy , my brilliant companion in mining the depths of Pine graphics.
Volume Based Sampling [BackQuant]Volume Based Sampling
What this does
This indicator converts the usual time-based stream of candles into an event-based stream of “synthetic” bars that are created only when enough trading activity has occurred . You choose the activity definition:
Volume bars : create a new synthetic bar whenever the cumulative number of shares/contracts traded reaches a threshold.
Dollar bars : create a new synthetic bar whenever the cumulative traded dollar value (price × volume) reaches a threshold.
The script then keeps an internal ledger of these synthetic opens, highs, lows, closes, and volumes, and can display them as candles, plot a moving average calculated over the synthetic closes, mark each time a new sample is formed, and optionally overlay the native time-bars for comparison.
Why event-based sampling matters
Markets do not release information on a clock: activity clusters during news, opens/closes, and liquidity shocks. Event-based bars normalize for that heteroskedastic arrival of information: during active periods you get more bars (finer resolution); during quiet periods you get fewer bars (coarser resolution). Research shows this can reduce microstructure pathologies and produce series that are closer to i.i.d. and more suitable for statistical modeling and ML. In particular:
Volume and dollar bars are a common event-time alternative to time bars in quantitative research and are discussed extensively in Advances in Financial Machine Learning (AFML). These bars aim to homogenize information flow by sampling on traded size or value rather than elapsed seconds.
The Volume Clock perspective models market activity in “volume time,” showing that many intraday phenomena (volatility, liquidity shocks) are better explained when time is measured by traded volume instead of seconds.
Related market microstructure work on flow toxicity and liquidity highlights that the risk dealers face is tied to information intensity of order flow, again arguing for activity-based clocks.
How the indicator works (plain English)
Choose your bucket type
Volume : accumulate volume until it meets a threshold.
Dollar Bars : accumulate close × volume until it meets a dollar threshold.
Pick the threshold rule
Dynamic threshold : by default, the script computes a rolling statistic (mean or median) of recent activity to set the next bucket size. This adapts bar size to changing conditions (e.g., busier sessions produce more frequent synthetic bars).
Fixed threshold : optionally override with a constant target (e.g., exactly 100,000 contracts per synthetic bar, or $5,000,000 per dollar bar).
Build the synthetic bar
While a bucket fills, the script tracks:
o_s: first price of the bucket (synthetic open)
h_s: running maximum price (synthetic high)
l_s: running minimum price (synthetic low)
c_s: last price seen (synthetic close)
v_s: cumulative native volume inside the bucket
d_samples: number of native bars consumed to complete the bucket (a proxy for “how fast” the threshold filled)
Emit a new sample
Once the bucket meets/exceeds the threshold, a new synthetic bar is finalized and stored. If overflow occurs (e.g., a single native bar pushes you past the threshold by a lot), the code will emit multiple synthetic samples to account for the extra activity.
Maintain a rolling history efficiently
A ring buffer can overwrite the oldest samples when you hit your Max Stored Samples cap, keeping memory usage stable.
Compute synthetic-space statistics
The script computes an SMA over the last N synthetic closes and basic descriptors like average bars per synthetic sample, mean and standard deviation of synthetic returns, and more. These are all in event time , not clock time.
Inputs and options you will actually use
Data Settings
Sampling Method : Volume or Dollar Bars.
Rolling Lookback : window used to estimate the dynamic threshold from recent activity.
Filter : Mean or Median for the dynamic threshold. Median is more robust to spikes.
Use Fixed? / Fixed Threshold : override dynamic sizing with a constant target.
Max Stored Samples : cap on synthetic history to keep performance snappy.
Use Ring Buffer : turn on to recycle storage when at capacity.
Indicator Settings
SMA over last N samples : moving average in synthetic space . Because its index is sample count, not minutes, it adapts naturally: more updates in busy regimes, fewer in quiet regimes.
Visuals
Show Synthetic Bars : plot the synthetic OHLC candles.
Candle Color Mode :
Green/Red: directional close vs open
Volume Intensity: opacity scales with synthetic size
Neutral: single color
Adaptive: graded by how large the bucket was relative to threshold
Mark new samples : drop a small marker whenever a new synthetic bar prints.
Comparison & Research
Show Time Bars : overlay the native time-based candles to visually compare how the two sampling schemes differ.
How to read it, step by step
Turn on “Synthetic Bars” and optionally overlay “Time Bars.” You will see that during high-activity bursts, synthetic bars print much faster than time bars.
Watch the synthetic SMA . Crosses in synthetic space can be more meaningful because each update represents a roughly comparable amount of traded information.
Use the “Avg Bars per Sample” in the info table as a regime signal. Falling average bars per sample means activity is clustering, often coincident with higher realized volatility.
Try Dollar Bars when price varies a lot but share count does not; they normalize by dollar risk taken in each sample. Volume Bars are ideal when share count is a better proxy for information flow in your instrument.
Quant finance background and citations
Event time vs. clock time : Easley, López de Prado, and O’Hara advocate measuring intraday phenomena on a volume clock to better align sampling with information arrival. This framing helps explain volatility bursts and liquidity droughts and motivates volume-based bars.
Flow toxicity and dealer risk : The same authors show how adverse selection risk changes with the intensity and informativeness of order flow, further supporting activity-based clocks for modeling and risk management.
AFML framework : In Advances in Financial Machine Learning , event-driven bars such as volume, dollar, and imbalance bars are presented as superior sampling units for many ML tasks, yielding more stationary features and fewer microstructure distortions than fixed time bars. ( Alpaca )
Practical use cases
1) Regime-aware moving averages
The synthetic SMA in event time is not fooled by quiet periods: if nothing of consequence trades, it barely updates. This can make trend filters less sensitive to calendar drift and more sensitive to true participation.
2) Breakout logic on “equal-information” samples
The script exposes simple alerts such as breakout above/below the synthetic SMA . Because each bar approximates a constant amount of activity, breakouts are conditioned on comparable informational mass, not arbitrary time buckets.
3) Volatility-adaptive backtests
If you use synthetic bars as your base data stream, most signal rules become self-paced : entry and exit opportunities accelerate in fast markets and slow down in quiet regimes, which often improves the realism of slippage and fill modeling in research pipelines (pair this indicator with strategy code downstream).
4) Regime diagnostics
Avg Bars per Sample trending down: activity is dense; expect larger realized ranges.
Return StdDev (synthetic) rising: noise or trend acceleration in event time; re-tune risk.
Interpreting the info panel
Method : your sampling choice and current threshold.
Total Samples : how many synthetic bars have been formed.
Current Vol/Dollar : how much of the next bucket is already filled.
Bars in Bucket : native bars consumed so far in the current bucket.
Avg Bars/Sample : lower means higher trading intensity.
Avg Return / Return StdDev : return stats computed over synthetic closes .
Research directions you can build from here
Imbalance and run bars
Extend beyond pure volume or dollar thresholds to imbalance bars that trigger on directional order flow imbalance (e.g., buy volume minus sell volume), as discussed in the AFML ecosystem. These often further homogenize distributional properties used in ML. alpaca.markets
Volume-time indicators
Re-compute classical indicators (RSI, MACD, Bollinger) on the synthetic stream. The premise is that signals are updated by traded information , not seconds, which may stabilize indicator behavior in heteroskedastic regimes.
Liquidity and toxicity overlays
Combine synthetic bars with proxies of flow toxicity to anticipate spread widening or volatility clustering. For instance, tag synthetic bars that surpass multiples of the threshold and test whether subsequent realized volatility is elevated.
Dollar-risk parity sampling for portfolios
Use dollar bars to align samples across assets by notional risk, enabling cleaner cross-asset features and comparability in multi-asset models (e.g., correlation studies, regime clustering). AFML discusses the benefits of event-driven sampling for cross-sectional ML feature engineering.
Microstructure feature set
Compute duration in native bars per synthetic sample , range per sample , and volume multiple of threshold as inputs to state classifiers or regime HMMs . These features are inherently activity-aware and often predictive of short-horizon volatility and trend persistence per the event-time literature. ( Alpaca )
Tips for clean usage
Start with dynamic thresholds using Median over a sensible lookback to avoid outlier distortion, then move to Fixed thresholds when you know your instrument’s typical activity scale.
Compare time bars vs synthetic bars side by side to develop intuition for how your market “breathes” in activity time.
Keep Max Stored Samples reasonable for performance; the ring buffer avoids memory creep while preserving a rolling window of research-grade data.
Screener based on Profitunity strategy for multiple timeframes
Screener based on Profitunity strategy by Bill Williams for multiple timeframes (max 5, including chart timeframe) and customizable symbol list. The screener analyzes the Alligator and Awesome Oscillator indicators, Divergent bars and high volume bars.
The maximum allowed number of requests (symbols and timeframes) is limited to 40 requests, for example, for 10 symbols by 4 requests of different timeframes. Therefore, the indicator automatically limits the number of displayed symbols depending on the number of timeframes for each symbol, if there are more symbols than are displayed in the screener table, then the ordinal numbers are displayed to the left of the symbols, in this case you can display the next group of symbols by increasing the value by 1 in the "Show tickers from" field, if the "Group" field is enabled, or specify the symbol number by 1 more than the last symbol in the screener table. 👀 When timeframe filtering is applied, the screener table displays only the columns of those timeframes for which the filtering value is selected, which allows displaying more symbols.
For each timeframe, in the "TIMEFRAMES > Prev" field, you can enable the display of data for the previous bar relative to the last (current) one, if the market is open for the requested symbol. In the "TIMEFRAMES > Y" field, you can enable filtering depending on the location of the last five bars relative to the Alligator indicator lines, which are designated by special symbols in the screener table:
⬆️ — if the Alligator is open upwards (Lips > Teeth > Jaw) and none of the bars is closed below the Lips line;
↗️ — if one of the bars, except for the penultimate one, is closed below Lips, or two bars, except for the last one, are closed below Lips, or the Alligator is open upwards only below four bars, but none of the bars is closed below Lips;
⬇️ — if the Alligator is open downwards (Lips < Teeth < Jaw), but none of the bars is closed above Lips;
↘️ — if one of the bars, except the penultimate one, is closed above the Lips, or two bars, except the last one, are closed above the Lips, or the Alligator is open down only above four bars, but none of the bars are closed above the Lips;
➡️ — in other cases, including when the Alligator lines intersect and one of the bars is closed behind the Lips line or two bars intersect one of the Alligator lines.
In the "TIMEFRAMES > Show bar change value for TF" field, you can add a column to the right of the selected timeframe column with the percentage change between the closing price of the last bar (current) and the closing price of the previous bar ((close – previous close) / previous close * 100). Depending on the percentage value, the background color of the screener table cell will change: dark red if <= -3%; red if <= -2%, light red if <= -0.5%; dark green if >= 3%; green if >= 2%; light green if >= 0.5%.
For each timeframe, the screener table displays the symbol of the latest (current) bar, depending on the closing price relative to the bar's midpoint ((high + low) / 2) and its location relative to the Alligator indicator lines: ⎾ — the bar's closing price is above its midpoint; ⎿ — the bar's closing price is below its midpoint; ├ — the bar's closing price is equal to its midpoint; 🟢 — Bullish Divergent bar, i.e. the bar's closing price is above its midpoint, the bar's high is below all Alligator lines, the bar's low is below the previous bar's low; 🔴 — Bearish Divergent bar, i.e. the bar's closing price is below its midpoint, the bar's low is above all Alligator lines, the bar's high is above the previous bar's high. When filtering is enabled in the "TIMEFRAMES > Filtering by Divergent bar" field, the data in the screener table cells will be displayed only for those timeframes that have a Divergent bar. A high bar volume signal is also displayed — 📶/📶² if the bar volume is greater than 40%/70% of the average volume value calculated using a simple moving average (SMA) in the 140 bar interval from the last bar.
In the indicator settings in the "SYMBOL LIST" field, each ticker (for example: OANDA:SPX500USD) must be on a separate line. If the market is closed, then the data for requested symbols will be limited to the time of the last (current) bar on the chart, for example, if the current symbol was traded yesterday, and the requested symbol is traded today, when requesting data for an hourly timeframe, the last bar will be for yesterday, if the timeframe of the current chart is not higher than 1 day. Therefore, by default, a warning will be displayed on the chart instead of the screener table that if the market is open, you must wait for the screener to load (after the first price change on the current chart), or if the highest timeframe in the screener is 1 day, you will be prompted to change the timeframe on the current chart to 1 week, if the screener requests data for the timeframe of 1 week, you will be prompted to change the timeframe on the current chart to 1 month, or switch to another symbol on the current chart for which the market is open (for example: BINANCE:BTCUSDT), or disable the warning in the field "SYMBOL LIST > Do not display screener if market is close".
The number of the last columns with the color of the AO indicator that will be displayed in the screener table for each timeframe is specified in the indicator settings in the "AWESOME OSCILLATOR > Number of columns" field.
For each timeframe, the direction of the trend between the price of the highest and lowest bars in the specified range of bars from the last bar is displayed — ↑ if the trend is up (the highest bar is to the right of the lowest), or ↓ if the trend is down (the lowest bar is to the right of the highest). If there is a divergence on the AO indicator in the specified interval, the symbol ∇ is also displayed. The average volume value is also calculated in the specified interval using a simple moving average (SMA). The number of bars is set in the indicator settings in the "INTERVAL FOR HIGHEST AND LOWEST BARS > Bars count" field.
In the indicator settings in the "STYLE" field you can change the position of the screener table relative to the chart window, the background color, the color and size of the text.
***
Скринер на основе стратегии Profitunity Билла Вильямса для нескольких таймфреймов (максимум 5, включая таймфрейм графика) и настраиваемого списка символов. Скринер анализирует индикаторы Alligator и Awesome Oscillator, Дивергентные бары и бары с высоким объемом.
Максимально допустимое количество запросов (символы и таймфреймы) ограничено 40 запросами, например, для 10 символов по 4 запроса разных таймфреймов. Поэтому в индикаторе автоматически ограничивается количество отображаемых символов в зависимости от количества таймфреймов для каждого символа, если символов больше чем отображено в таблице скринера, то слева от символов отображаются порядковые номера, в таком случае можно отобразить следующую группу символов, увеличив значение на 1 в настройках индикатора поле "Show tickers from", если включено поле "Group", или указать номер символа на 1 больше, чем последний символ в таблице скринера. 👀 Когда применяется фильтрация по таймфрейму, в таблице скринера отображаются только столбцы тех таймфреймов, для которых выбрано значение фильтрации, что позволяет отображать большее количество символов.
Для каждого таймфрейма в настройках индикатора в поле "TIMEFRAMES > Prev" можно включить отображение данных для предыдущего бара относительно последнего (текущего), если для запрашиваемого символа рынок открыт. В поле "TIMEFRAMES > Y" можно включить фильтрацию, в зависимости от расположения последних пяти баров относительно линий индикатора Alligator, которые обозначаются специальными символами в таблице скринера:
⬆️ — если Alligator открыт вверх (Lips > Teeth > Jaw) и ни один из баров не закрыт ниже линии Lips;
↗️ — если один из баров, кроме предпоследнего, закрыт ниже Lips, или два бара, кроме последнего, закрыты ниже Lips, или Alligator открыт вверх только ниже четырех баров, но ни один из баров не закрыт ниже Lips;
⬇️ — если Alligator открыт вниз (Lips < Teeth < Jaw), но ни один из баров не закрыт выше Lips;
↘️ — если один из баров, кроме предпоследнего, закрыт выше Lips, или два бара, кроме последнего, закрыты выше Lips, или Alligator открыт вниз только выше четырех баров, но ни один из баров не закрыт выше Lips;
➡️ — в остальных случаях, в то числе когда линии Alligator пересекаются и один из баров закрыт за линией Lips или два бара пересекают одну из линий Alligator.
В поле "TIMEFRAMES > Show bar change value for TF" можно добавить справа от выбранного столбца таймфрейма столбец с процентным изменением между ценой закрытия последнего бара (текущего) и ценой закрытия предыдущего бара ((close – previous close) / previous close * 100). В зависимости от величины процента будет меняться цвет фона ячейки таблицы скринера: темно-красный, если <= -3%; красный, если <= -2%, светло-красный, если <= -0.5%; темно-зеленый, если >= 3%; зеленый, если >= 2%; светло-зеленый, если >= 0.5%.
Для каждого таймфрейма в таблице скринера отображается символ последнего (текущего) бара, в зависимости от цены закрытия относительно середины бара ((high + low) / 2) и расположения относительно линий индикатора Alligator: ⎾ — цена закрытия бара выше его середины; ⎿ — цена закрытия бара ниже его середины; ├ — цена закрытия бара равна его середине; 🟢 — Бычий Дивергентный бар, т.е. цена закрытия бара выше его середины, максимум бара ниже всех линий Alligator, минимум бара ниже минимума предыдущего бара; 🔴 — Медвежий Дивергентный бар, т.е. цена закрытия бара ниже его середины, минимум бара выше всех линий Alligator, максимум бара выше максимума предыдущего бара. При включении фильтрации в поле "TIMEFRAMES > Filtering by Divergent bar" данные в ячейках таблицы скринера будут отображаться только для тех таймфреймов, где есть Дивергентный бар. Также отображается сигнал высокого объема бара — 📶/📶², если объем бара больше чем на 40%/70% среднего значения объема, рассчитанного с помощью простой скользящей средней (SMA) в интервале 140 баров от последнего бара.
В настройках индикатора в поле "SYMBOL LIST" каждый тикер (например: OANDA:SPX500USD) должен быть на отдельной строке. Если рынок закрыт, то данные для запрашиваемых символов будут ограничены временем последнего (текущего) бара на графике, например, если текущий символ торговался последний день вчера, а запрашиваемый символ торгуется сегодня, при запросе данных для часового таймфрейма, последний бар будет за вчерашний день, если таймфрейм текущего графика не выше 1 дня. Поэтому по умолчанию на графике будет отображаться предупреждение вместо таблицы скринера о том, что если рынок открыт, то необходимо дождаться загрузки скринера (после первого изменения цены на текущем графике), или если в скринере самый высокий таймфрейм 1 день, то будет предложено изменить на текущем графике таймфрейм на 1 неделю, если в скринере запрашиваются данные для таймфрейма 1 неделя, то будет предложено изменить на текущем графике таймфрейм на 1 месяц, или же переключиться на другой символ на текущем графике, для которого рынок открыт (например: BINANCE:BTCUSDT), или отключить предупреждение в поле "SYMBOL LIST > Do not display screener if market is close".
Количество последних столбцов с цветом индикатора AO, которые будут отображены в таблице скринера для каждого таймфрейма, указывается в настройках индикатора в поле "AWESOME OSCILLATOR > Number of columns".
Для каждого таймфрейма отображается направление тренда между ценой самого высокого и самого низкого баров в указанном интервале баров от последнего бара — ↑, если тренд направлен вверх (самый высокий бар справа от самого низкого), или ↓, если тренд направлен вниз (самый низкий бар справа от самого высокого). Если есть дивергенция на индикаторе AO в указанном интервале, то также отображается символ — ∇. В указанном интервале также рассчитывается среднее значение объема с помощью простой скользящей средней (SMA). Количество баров устанавливается в настройках индикатора в поле "INTERVAL FOR HIGHEST AND LOWEST BARS > Bars count".
В настройках индикатора в поле "STYLE" можно изменить положение таблицы скринера относительно окна графика, цвет фона, цвет и размер текста.
FvgCalculations█ OVERVIEW
This library provides the core calculation engine for identifying Fair Value Gaps (FVGs) across different timeframes and for processing their interaction with price. It includes functions to detect FVGs on both the current chart and higher timeframes, as well as to check for their full or partial mitigation.
█ CONCEPTS
The library's primary functions revolve around the concept of Fair Value Gaps and their lifecycle.
Fair Value Gap (FVG) Identification
An FVG, or imbalance, represents a price range where buying or selling pressure was significant enough to cause a rapid price movement, leaving an "inefficiency" in the market. This library identifies FVGs based on three-bar patterns:
Bullish FVG: Forms when the low of the current bar (bar 3) is higher than the high of the bar two periods prior (bar 1). The FVG is the space between the high of bar 1 and the low of bar 3.
Bearish FVG: Forms when the high of the current bar (bar 3) is lower than the low of the bar two periods prior (bar 1). The FVG is the space between the low of bar 1 and the high of bar 3.
The library provides distinct functions for detecting FVGs on the current (Low Timeframe - LTF) and specified higher timeframes (Medium Timeframe - MTF / High Timeframe - HTF).
FVG Mitigation
Mitigation refers to price revisiting an FVG.
Full Mitigation: An FVG is considered fully mitigated when price completely closes the gap. For a bullish FVG, this occurs if the current low price moves below or touches the FVG's bottom. For a bearish FVG, it occurs if the current high price moves above or touches the FVG's top.
Partial Mitigation (Entry/Fill): An FVG is partially mitigated when price enters the FVG's range but does not fully close it. The library tracks the extent of this fill. For a bullish FVG, if the current low price enters the FVG from above, that low becomes the new effective top of the remaining FVG. For a bearish FVG, if the current high price enters the FVG from below, that high becomes the new effective bottom of the remaining FVG.
FVG Interaction
This refers to any instance where the current bar's price range (high to low) touches or crosses into the currently unfilled portion of an active (visible and not fully mitigated) FVG.
Multi-Timeframe Data Acquisition
To detect FVGs on higher timeframes, specific historical bar data (high, low, and time of bars at indices and relative to the higher timeframe's last completed bar) is required. The requestMultiTFBarData function is designed to fetch this data efficiently.
█ CALCULATIONS AND USE
The functions in this library are typically used in a sequence to manage FVGs:
1. Data Retrieval (for MTF/HTF FVGs):
Call requestMultiTFBarData() with the desired higher timeframe string (e.g., "60", "D").
This returns a tuple of htfHigh1, htfLow1, htfTime1, htfHigh3, htfLow3, htfTime3.
2. FVG Detection:
For LTF FVGs: Call detectFvg() on each confirmed bar. It uses high , low, low , and high along with barstate.isconfirmed.
For MTF/HTF FVGs: Call detectMultiTFFvg() using the data obtained from requestMultiTFBarData().
Both detection functions return an fvgObject (defined in FvgTypes) if an FVG is found, otherwise na. They also can classify FVGs as "Large Volume" (LV) if classifyLV is true and the FVG size (top - bottom) relative to the tfAtr (Average True Range of the respective timeframe) meets the lvAtrMultiplier.
3. FVG State Updates (on each new bar for existing FVGs):
First, check for overall price interaction using fvgInteractionCheck(). This function determines if the current bar's high/low has touched or entered the FVG's currentTop or currentBottom.
If interaction occurs and the FVG is not already mitigated:
Call checkMitigation() to determine if the FVG has been fully mitigated by the current bar's currentHigh and currentLow. If true, the FVG's isMitigated status is updated.
If not fully mitigated, call checkPartialMitigation() to see if the price has further entered the FVG. This function returns the newLevel to which the FVG has been filled (e.g., currentLow for a bullish FVG, currentHigh for bearish). This newLevel is then used to update the FVG's currentTop or currentBottom.
The calling script (e.g., fvgMain.c) is responsible for storing and managing the array of fvgObject instances and passing them to these update functions.
█ NOTES
Bar State for LTF Detection: The detectFvg() function relies on barstate.isconfirmed to ensure FVG detection is based on closed bars, preventing FVGs from being detected prematurely on the currently forming bar.
Higher Timeframe Data (lookahead): The requestMultiTFBarData() function uses lookahead = barmerge.lookahead_on. This means it can access historical data from the higher timeframe that corresponds to the current bar on the chart, even if the higher timeframe bar has not officially closed. This is standard for multi-timeframe analysis aiming to plot historical HTF data accurately on a lower timeframe chart.
Parameter Typing: Functions like detectMultiTFFvg and detectFvg infer the type for boolean (classifyLV) and numeric (lvAtrMultiplier) parameters passed from the main script, while explicitly typed series parameters (like htfHigh1, currentAtr) expect series data.
fvgObject Dependency: The FVG detection functions return fvgObject instances, and fvgInteractionCheck takes an fvgObject as a parameter. This UDT is defined in the FvgTypes library, making it a dependency for using FvgCalculations.
ATR for LV Classification: The tfAtr (for MTF/HTF) and currentAtr (for LTF) parameters are expected to be the Average True Range values for the respective timeframes. These are used, if classifyLV is enabled, to determine if an FVG's size qualifies it as a "Large Volume" FVG based on the lvAtrMultiplier.
MTF/HTF FVG Appearance Timing: When displaying FVGs from a higher timeframe (MTF/HTF) on a lower timeframe (LTF) chart, users might observe that the most recent MTF/HTF FVG appears one LTF bar later compared to its appearance on a native MTF/HTF chart. This is an expected behavior due to the detection mechanism in `detectMultiTFFvg`. This function uses historical bar data from the MTF/HTF (specifically, data equivalent to `HTF_bar ` and `HTF_bar `) to identify an FVG. Therefore, all three bars forming the FVG on the MTF/HTF must be fully closed and have shifted into these historical index positions relative to the `request.security` call from the LTF chart before the FVG can be detected and displayed on the LTF. This ensures that the MTF/HTF FVG is identified based on confirmed, closed bars from the higher timeframe.
█ EXPORTED FUNCTIONS
requestMultiTFBarData(timeframe)
Requests historical bar data for specific previous bars from a specified higher timeframe.
It fetches H , L , T (for the bar before last) and H , L , T (for the bar three periods prior)
from the requested timeframe.
This is typically used to identify FVG patterns on MTF/HTF.
Parameters:
timeframe (simple string) : The higher timeframe to request data from (e.g., "60" for 1-hour, "D" for Daily).
Returns: A tuple containing: .
- htfHigh1 (series float): High of the bar at index 1 (one bar before the last completed bar on timeframe).
- htfLow1 (series float): Low of the bar at index 1.
- htfTime1 (series int) : Time of the bar at index 1.
- htfHigh3 (series float): High of the bar at index 3 (three bars before the last completed bar on timeframe).
- htfLow3 (series float): Low of the bar at index 3.
- htfTime3 (series int) : Time of the bar at index 3.
detectMultiTFFvg(htfHigh1, htfLow1, htfTime1, htfHigh3, htfLow3, htfTime3, tfAtr, classifyLV, lvAtrMultiplier, tfType)
Detects a Fair Value Gap (FVG) on a higher timeframe (MTF/HTF) using pre-fetched bar data.
Parameters:
htfHigh1 (float) : High of the first relevant bar (typically high ) from the higher timeframe.
htfLow1 (float) : Low of the first relevant bar (typically low ) from the higher timeframe.
htfTime1 (int) : Time of the first relevant bar (typically time ) from the higher timeframe.
htfHigh3 (float) : High of the third relevant bar (typically high ) from the higher timeframe.
htfLow3 (float) : Low of the third relevant bar (typically low ) from the higher timeframe.
htfTime3 (int) : Time of the third relevant bar (typically time ) from the higher timeframe.
tfAtr (float) : ATR value for the higher timeframe, used for Large Volume (LV) FVG classification.
classifyLV (bool) : If true, FVGs will be assessed to see if they qualify as Large Volume.
lvAtrMultiplier (float) : The ATR multiplier used to define if an FVG is Large Volume.
tfType (series tfType enum from no1x/FvgTypes/1) : The timeframe type (e.g., types.tfType.MTF, types.tfType.HTF) of the FVG being detected.
Returns: An fvgObject instance if an FVG is detected, otherwise na.
detectFvg(classifyLV, lvAtrMultiplier, currentAtr)
Detects a Fair Value Gap (FVG) on the current (LTF - Low Timeframe) chart.
Parameters:
classifyLV (bool) : If true, FVGs will be assessed to see if they qualify as Large Volume.
lvAtrMultiplier (float) : The ATR multiplier used to define if an FVG is Large Volume.
currentAtr (float) : ATR value for the current timeframe, used for LV FVG classification.
Returns: An fvgObject instance if an FVG is detected, otherwise na.
checkMitigation(isBullish, fvgTop, fvgBottom, currentHigh, currentLow)
Checks if an FVG has been fully mitigated by the current bar's price action.
Parameters:
isBullish (bool) : True if the FVG being checked is bullish, false if bearish.
fvgTop (float) : The top price level of the FVG.
fvgBottom (float) : The bottom price level of the FVG.
currentHigh (float) : The high price of the current bar.
currentLow (float) : The low price of the current bar.
Returns: True if the FVG is considered fully mitigated, false otherwise.
checkPartialMitigation(isBullish, currentBoxTop, currentBoxBottom, currentHigh, currentLow)
Checks for partial mitigation of an FVG by the current bar's price action.
It determines if the price has entered the FVG and returns the new fill level.
Parameters:
isBullish (bool) : True if the FVG being checked is bullish, false if bearish.
currentBoxTop (float) : The current top of the FVG box (this might have been adjusted by previous partial fills).
currentBoxBottom (float) : The current bottom of the FVG box (similarly, might be adjusted).
currentHigh (float) : The high price of the current bar.
currentLow (float) : The low price of the current bar.
Returns: The new price level to which the FVG has been filled (e.g., currentLow for a bullish FVG).
Returns na if no new partial fill occurred on this bar.
fvgInteractionCheck(fvg, highVal, lowVal)
Checks if the current bar's price interacts with the given FVG.
Interaction means the price touches or crosses into the FVG's
current (possibly partially filled) range.
Parameters:
fvg (fvgObject type from no1x/FvgTypes/1) : The FVG object to check.
Its isMitigated, isVisible, isBullish, currentTop, and currentBottom fields are used.
highVal (float) : The high price of the current bar.
lowVal (float) : The low price of the current bar.
Returns: True if price interacts with the FVG, false otherwise.
Percentage price changeThis indicator marks bars whose values increase or decrease by an amount greater than or equal to the value of the specified parameter as a percentage. Bars that meet the condition are marked with labels, boxes and colors. In addition to the standard method of calculating the percentage change at the closing price of the current and previous bars, the indicator allows you to choose non-standard calculation methods (at the prices of opening and closing the current bar, as well as at the prices of the maximum at the minimum of the current bar). You can choose to display the percentage changes of individual bars as well as a series of bars. You can select the number of bars in a series of bars. You can also apply filters by the direction of the bars in the series or by the percentage of individual bars in the series.
It is important to remember that in version 5 of Pine Script™, the maximum possible number of labels and the maximum possible number of boxes cannot exceed 500!
There are several main parameters that can be changed in section PARAMETERS FOR CALCULATION:
1. 'Bars count' - The number of bars for which the percentage rise or fall is calculated.
2. ‘Percentage change’ - sets the price change as a percentage. Bars with a price range above or equal to the specified value will be marked on the chart.
3. ‘First and second points of calculation’ - the first and second points for calculating the percentage change. Here you can set several different values for the calculation:
- 'Cl.pr., Close' - Closing price of the previous bar and closing price of the current bar (or a series of bars) (these values are used for the standard calculation of the percentage change on the chart).
- 'Open, Close' - Opening and closing prices of the current bar (or a series of bars).
- 'High|Low' - Highest and lowest price of the current bar (or a series of bars).
- 'Cl.pr.|High|Low' - Highest or lowest price of the current bar (or a series of bars) (depending on whether the bar is going up or down) or closing price of the previous bar for first point (one of these values is automatically selected, which gives a larger result, depending on whether there is a gap between these values). Highest or lowest price of the current bar for second point.
In the LIMITS section, you can set the following parameters.
1. ‘Only for the last bar’ - If this option is selected, the indicator will be applied only for the last bar (or series of bars).
2. 'Only bars in one direction' - A condition that takes into account sequences from the selected number of bars going in only one direction. If at least one bar has a different direction from the other bars, then such a sequence will not be taken into account. This only works if the 'Bars count' is > 1.
3. "Cut off higher values" - This field cuts off higher values. Bars with a price range above or equal to the specified value will not be marked on the chart. This can be used in some cases to make the chart less loaded with data and more visual. Of course, you can also use this option however you want.
4. ‘Min percent in series of bars’ - If the value 'Number of bars' is > 1, then a series of bars is taken into account, in which the percentage change of individual bars is greater than or equal to the set value.
In the DATE RANGE section, you can set the limits of the time and date range in which the calculation will be performed. In some cases, this can be used in order not to exceed the limit on the number of labels or boxes, which cannot exceed 500. Of course, you can also use this option however you want. By default, the date range is unlimited.
'Timezone offset, hours' - It is used only for the correct display of the limits of the date range in the parameter table.
In the PRICE INCREASE LABELS and PRICE REDUCTION LABELS section, you can define the design of labels bars and boxes, such as colors, shapes, sizes, and location. You can set the colors of the bars separately on the Style tab. On the Style tab, you can also turn on/off the display of frames, labels and color markings of bars.
The PARAMETER TABLE section is designed to adjust the display of the table for a more visual display of the selected values of all parameters on the Arguments tab. Depending on which values have been set and which parameters have been enabled or disabled, the table will change its appearance, display or hide some rows. A single line 'Total found' will be displayed all the time. It shows the count of bars that meet the condition and count of labels or boxes used in the diagram. Since the bars are labeled with labels or boxes, their number cannot exceed 500 for Pine script version 5.
1. 'Pos.' - sets the main position of the table on the screen.
2. 'X off.', 'Y off.' - You can set the offset of the table along the X and Y axes. This option can be useful to avoid overlapping multiple tables if you want to use two or more instances of this indicator on your chart. The minimum value is -30, the maximum is 30. Positive values shift the table to the right on the X axis and up on the Y axis. Negative values shift the table to the left on the X axis and down on the Y axis.
3. 'Font color' - The font color in the table.
'Warn. font color', 'Warn. backgr. color' - The font and background colors in the 'Total found' row in the table. If the number of labels or boxes exceeds 500, the font and background will be colored in these colors.
4. ‘Font size’ – Sets the font size in the table.
5. 'Show hours and minutes in date/time range' - changes the date and time format of time range from {yyyy.MM.dd HH:mm} to {yyyy.MM.dd}.
6. 'View all params' - used to display all parameters, even those duplicated in the main line of the indicator.
7. ‘Title’ – If desired, you can make a header for the table.
The last row of the table shows the number of bars found that meet the conditions. Since these bars are marked with labels (in the case of one bar) or boxes (in the case of series of bars), the limit that can be marked on the chart is 500. Exceeding this value will be displayed in the table and additionally highlighted in red font. This will signal that not all bars found are displayed on the chart.
On the Style tab, you can turn the table display on/off.
Higher-timeframe requests█ OVERVIEW
This publication focuses on enhancing awareness of the best practices for accessing higher-timeframe (HTF) data via the request.security() function. Some "traditional" approaches, such as what we explored in our previous `security()` revisited publication, have shown limitations in their ability to retrieve non-repainting HTF data. The fundamental technique outlined in this script is currently the most effective in preventing repainting when requesting data from a higher timeframe. For detailed information about why it works, see this section in the Pine Script™ User Manual .
█ CONCEPTS
Understanding repainting
Repainting is a behavior that occurs when a script's calculations or outputs behave differently after restarting it. There are several types of repainting behavior, not all of which are inherently useless or misleading. The most prevalent form of repainting occurs when a script's calculations or outputs exhibit different behaviors on historical and realtime bars.
When a script calculates across historical data, it only needs to execute once per bar, as those values are confirmed and not subject to change. After each historical execution, the script commits the states of its calculations for later access.
On a realtime, unconfirmed bar, values are fluid . They are subject to change on each new tick from the data provider until the bar closes. A script's code can execute on each tick in a realtime bar, meaning its calculations and outputs are subject to realtime fluctuations, just like the underlying data it uses. Each time a script executes on an unconfirmed bar, it first reverts applicable values to their last committed states, a process referred to as rollback . It only commits the new values from a realtime bar after the bar closes. See the User Manual's Execution model page to learn more.
In essence, a script can repaint when it calculates on realtime bars due to fluctuations before a bar's confirmation, which it cannot reproduce on historical data. A common strategy to avoid repainting when necessary involves forcing only confirmed values on realtime bars, which remain unchanged until each bar's conclusion.
Repainting in higher-timeframe (HTF) requests
When working with a script that retrieves data from higher timeframes with request.security() , it's crucial to understand the differences in how such requests behave on historical and realtime bars .
The request.security() function executes all code required by its `expression` argument using data from the specified context (symbol, timeframe, or modifiers) rather than on the chart's data. As when executing code in the chart's context, request.security() only returns new historical values when a bar closes in the requested context. However, the values it returns on realtime HTF bars can also update before confirmation, akin to the rollback and recalculation process that scripts perform in the chart's context on the open bar. Similar to how scripts operate in the chart's context, request.security() only confirms new values after a realtime bar closes in its specified context.
Once a script's execution cycle restarts, what were previously realtime bars become historical bars, meaning the request.security() call will only return confirmed values from the HTF on those bars. Therefore, if the requested data fluctuates across an open HTF bar, the script will repaint those values after it restarts.
This behavior is not a bug; it's simply the default behavior of request.security() . In some cases, having the latest information from an unconfirmed HTF bar is precisely what a script needs. However, in many other cases, traders will require confirmed, stable values that do not fluctuate across an open HTF bar. Below, we explain the most reliable approach to achieve such a result.
Achieving consistent timing on all bars
One can retrieve non-fluctuating values with consistent timing across historical and realtime feeds by exclusively using request.security() to fetch the data from confirmed HTF bars. The best way to achieve this result is offsetting the `expression` argument by at least one bar (e.g., `close [1 ]`) and using barmerge.lookahead_on as the `lookahead` argument.
We discourage the use of barmerge.lookahead_on alone since it prompts the function to look toward future values of HTF bars across historical data, which is heavily misleading. However, when paired with a requested `expression` that includes a one-bar historical offset, the "future" data the function retrieves is not from the future. Instead, it represents the last confirmed bar's values at the start of each HTF bar, thus preventing the results on realtime bars from fluctuating before confirmation from the timeframe.
For example, this line of code uses a request.security() call with barmerge.lookahead_on to request the close price from the "1D" timeframe, offset by one bar with the history-referencing operator [ ] . This line will return the daily price with consistent timing across all bars:
float htfClose = request.security(syminfo.tickerid, "1D", close , lookahead = barmerge.lookahead_on)
Note that:
• This technique only works as intended for higher-timeframe requests .
• When designing a script to work specifically with HTFs, we recommend including conditions to prevent request.security() from accessing timeframes equal to or lower than the chart's timeframe, especially if you intend to publish it. In this script, we included an if structure that raises a runtime error when the requested timeframe is too small.
• A necessary trade-off with this approach is that the script must wait for an HTF bar's confirmation to retrieve new data on realtime bars, thus delaying its availability until the open of the subsequent HTF bar. The time elapsed during such a delay varies with each market, but it's typically relatively small.
👉 Failing to offset the function's `expression` argument while using barmerge.lookahead_on will produce historical results with lookahead bias , as it will look to the future states of historical HTF bars, retrieving values before the times at which they're available in the feed. See the `lookahead` and Future leak with `request.security()` sections in the Pine Script™ User Manual for more information.
Evolving practices
The fundamental technique outlined in this publication is currently the only reliable approach to requesting non-repainting HTF data with request.security() . It is the superior approach because it avoids the pitfalls of other methods, such as the one introduced in the `security()` revisited publication. That publication proposed using a custom `f_security()` function, which applied offsets to the `expression` and the requested result based on historical and realtime bar states. At that time, we explored techniques that didn't carry the risk of lookahead bias if misused (i.e., removing the historical offset on the `expression` while using lookahead), as requests that look ahead to the future on historical bars exhibit dangerously misleading behavior.
Despite these efforts, we've unfortunately found that the bar state method employed by `f_security()` can produce inaccurate results with inconsistent timing in some scenarios, undermining its credibility as a universal non-repainting technique. As such, we've deprecated that approach, and the Pine Script™ User Manual no longer recommends it.
█ METHOD VARIANTS
In this script, all non-repainting requests employ the same underlying technique to avoid repainting. However, we've applied variants to cater to specific use cases, as outlined below:
Variant 1
Variant 1, which the script displays using a lime plot, demonstrates a non-repainting HTF request in its simplest form, aligning with the concept explained in the "Achieving consistent timing" section above. It uses barmerge.lookahead_on and offsets the `expression` argument in request.security() by one bar to retrieve the value from the last confirmed HTF bar. For detailed information about why this works, see the Avoiding Repainting section of the User Manual's Other timeframes and data page.
Variant 2
Variant 2 ( fuchsia ) introduces a custom function, `htfSecurity()`, which wraps the request.security() function to facilitate convenient repainting control. By specifying a value for its `repaint` parameter, users can determine whether to allow repainting HTF data. When the `repaint` value is `false`, the function applies lookahead and a one-bar offset to request the last confirmed value from the specified `timeframe`. When the value is `true`, the function requests the `expression` using the default behavior of request.security() , meaning the results can fluctuate across chart bars within realtime HTF bars and repaint when the script restarts.
Note that:
• This function exclusively handles HTF requests. If the requested timeframe is not higher than the chart's, it will raise a runtime error .
• We prefer this approach since it provides optional repainting control. Sometimes, a script's calculations need to respond immediately to realtime HTF changes, which `repaint = true` allows. In other cases, such as when issuing alerts, triggering strategy commands, and more, one will typically need stable values that do not repaint, in which case `repaint = false` will produce the desired behavior.
Variant 3
Variant 3 ( white ) builds upon the same fundamental non-repainting approach used by the first two. The difference in this variant is that it applies repainting control to tuples , which one cannot pass as the `expression` argument in our `htfSecurity()` function. Tuples are handy for consolidating `request.*()` calls when a script requires several values from the same context, as one can request a single tuple from the context rather than executing multiple separate request.security() calls.
This variant applies the internal logic of our `htfSecurity()` function in the script's global scope to request a tuple containing open and `srcInput` values from a higher timeframe with repainting control. Historically, Pine Script™ did not allow the history-referencing operator [ ] when requesting tuples unless the tuple came from a function call, which limited this technique. However, updates to Pine over time have lifted this restriction, allowing us to pass tuples with historical offsets directly as the `expression` in request.security() . By offsetting all items in a tuple `expression` by one bar and using barmerge.lookahead_on , we effectively retrieve a tuple of stable, non-repainting HTF values.
Since we cannot encapsulate this method within the `htfSecurity()` function and must execute the calculations in the global scope, the script's "Repainting" input directly controls the global `offset` and `lookahead` values to ensure it behaves as intended.
Variant 4 (Control)
Variant 4, which the script displays as a translucent orange plot, uses a default request.security() call, providing a reference point to compare the difference between a repainting request and the non-repainting variants outlined above. Whenever the script restarts its execution cycle, realtime bars become historical bars, and the request.security() call here will repaint the results on those bars.
█ Inputs
Repainting
The "Repainting" input (`repaintInput` variable) controls whether Variant 2 and Variant 3 are allowed to use fluctuating values from an unconfirmed HTF bar. If its value is `false` (default), these requests will only retrieve stable values from the last confirmed HTF bar.
Source
The "Source" input (`srcInput` variable) determines the series the script will use in the `expression` for all HTF data requests. Its default value is close .
HTF Selection
This script features two ways to specify the higher timeframe for all its data requests, which users can control with the "HTF Selection" input (`tfTypeInput` variable):
1) If its value is "Fixed TF", the script uses the timeframe value specified by the "Fixed Higher Timeframe" input (`fixedTfInput` variable). The script will raise a runtime error if the selected timeframe is not larger than the chart's.
2) If the input's value is "Multiple of chart TF", the script multiplies the value of the "Timeframe Multiple" input (`tfMultInput` variable) by the chart's timeframe.in_seconds() value, then converts the result to a valid timeframe string via timeframe.from_seconds() .
Timeframe Display
This script features the option to display an "information box", i.e., a single-cell table that shows the higher timeframe the script is currently using. Users can toggle the display and determine the table's size, location, and color scheme via the inputs in the "Timeframe Display" group.
█ Outputs
This script produces the following outputs:
• It plots the results from all four of the above variants for visual comparison.
• It highlights the chart's background gray whenever a new bar starts on the higher timeframe, signifying when confirmations occur in the requested context.
• To demarcate which bars the script considers historical or realtime bars, it plots squares with contrasting colors corresponding to bar states at the bottom of the chart pane.
• It displays the higher timeframe string in a single-cell table with a user-specified size, location, and color scheme.
Look first. Then leap.
lower_tfLibrary "lower_tf"
█ OVERVIEW
This library is an enhanced (opinionated) version of the library originally developed by PineCoders contained in lower_tf .
It is a Pine Script® programming tool for advanced lower-timeframe selection and intra-bar analysis.
█ CONCEPTS
Lower Timeframe Analysis
Lower timeframe analysis refers to the analysis of price action and market microstructure using data from timeframes shorter than the current chart period. This technique allows traders and analysts to gain deeper insights into market dynamics, volume distribution, and the price movements occurring within each bar on the chart. In Pine Script®, the request.security_lower_tf() function allows this analysis by accessing intrabar data.
The library provides a comprehensive set of functions for accurate mapping of lower timeframes, dynamic precision control, and optimized historical coverage using request.security_lower_tf().
█ IMPROVEMENTS
The original library implemented ten precision levels. This enhanced version extends that to twelve levels, adding two ultra-high-precision options:
Coverage-Based Precision (Original 5 levels):
1. "Covering most chart bars (least precise)"
2. "Covering some chart bars (less precise)"
3. "Covering fewer chart bars (more precise)"
4. "Covering few chart bars (very precise)"
5. "Covering the least chart bars (most precise)"
Intrabar-Count-Based Precision (Expanded from 5 to 7 levels):
6. "~12 intrabars per chart bar"
7. "~24 intrabars per chart bar"
8. "~50 intrabars per chart bar"
9. "~100 intrabars per chart bar"
10. "~250 intrabars per chart bar"
11. "~500 intrabars per chart bar" ← NEW
12. "~1000 intrabars per chart bar" ← NEW
The key enhancements in this version include:
1. Extended Precision Range: Adds two ultra-high-precision levels (~500 and ~1000 intrabars) for advanced microstructure analysis requiring maximum granularity.
2. Market-Agnostic Implementation: Eliminates the distinction between crypto/forex and traditional markets, removing the mktFactor variable in favor of a unified, predictable approach across all asset classes.
3. Explicit Precision Mapping: Completely refactors the timeframe selection logic using native Pine Script® timeframe properties ( timeframe.isseconds , timeframe.isminutes , timeframe.isdaily , timeframe.isweekly , timeframe.ismonthly ) and explicit multiplier-based lookup tables. The original library used minute-based calculations with market-dependent conditionals that produced inconsistent results. This version provides deterministic, predictable mappings for every chart timeframe, ensuring consistent precision behavior regardless of asset type or market hours.
An example of the differences can be seen side-by-side in the chart below, where the original library is on the left and the enhanced version is on the right:
█ USAGE EXAMPLE
// This Pine Script® code is subject to the terms of the Mozilla Public License 2.0 at mozilla.org
// © andre_007
//@version=6
indicator("lower_tf Example")
import andre_007/lower_tf/1 as LTF
import PineCoders/Time/5 as PCtime
//#region ———————————————————— Example code
// ————— Constants
color WHITE = color.white
color GRAY = color.gray
string LTF1 = "Covering most chart bars (least precise)"
string LTF2 = "Covering some chart bars (less precise)"
string LTF3 = "Covering less chart bars (more precise)"
string LTF4 = "Covering few chart bars (very precise)"
string LTF5 = "Covering the least chart bars (most precise)"
string LTF6 = "~12 intrabars per chart bar"
string LTF7 = "~24 intrabars per chart bar"
string LTF8 = "~50 intrabars per chart bar"
string LTF9 = "~100 intrabars per chart bar"
string LTF10 = "~250 intrabars per chart bar"
string LTF11 = "~500 intrabars per chart bar"
string LTF12 = "~1000 intrabars per chart bar"
string TT_LTF = "This selection determines the approximate number of intrabars analyzed per chart bar. Higher numbers of
intrabars produce more granular data at the cost of less historical bar coverage, because the maximum number of
available intrabars is 200K.
\n\nThe first five options set the lower timeframe based on a specified relative level of chart bar coverage.
The last five options set the lower timeframe based on an approximate number of intrabars per chart bar."
string TAB_TXT = "Uses intrabars at the {0} timeframe.\nAvg intrabars per chart bar:
{1,number,#.#}\nChart bars covered: {2} of {3} ({4,number,#.##}%)"
string ERR_TXT = "No intrabar information exists at the {1}{0}{1} timeframe."
// ————— Inputs
string ltfModeInput = input.string(LTF3, "Intrabar precision", options = , tooltip = TT_LTF)
bool showInfoBoxInput = input.bool(true, "Show information box ")
string infoBoxSizeInput = input.string("normal", "Size ", inline = "01", options = )
string infoBoxYPosInput = input.string("bottom", "↕", inline = "01", options = )
string infoBoxXPosInput = input.string("right", "↔", inline = "01", options = )
color infoBoxColorInput = input.color(GRAY, "", inline = "01")
color infoBoxTxtColorInput = input.color(WHITE, "T", inline = "01")
// ————— Calculations
// @variable A "string" representing the lower timeframe for the data request.
// NOTE:
// This line is a good example where using `var` in the declaration can improve a script's performance.
// By using `var` here, the script calls `ltf()` only once, on the dataset's first bar, instead of redundantly
// evaluating unchanging strings on every bar. We only need one evaluation of this function because the selected
// timeframe does not change across bars in this script.
var string ltfString = LTF.ltf(ltfModeInput, LTF1, LTF2, LTF3, LTF4, LTF5, LTF6, LTF7, LTF8, LTF9, LTF10, LTF11, LTF12)
// @variable An array containing all intrabar `close` prices from the `ltfString` timeframe for the current chart bar.
array intrabarCloses = request.security_lower_tf(syminfo.tickerid, ltfString, close)
// Calculate the intrabar stats.
= LTF.ltfStats(intrabarCloses)
int chartBars = bar_index + 1
// ————— Visuals
// Plot the `avgIntrabars` and `intrabars` series in all display locations.
plot(avgIntrabars, "Average intrabars", color.silver, 6)
plot(intrabars, "Intrabars", color.blue, 2)
// Plot the `chartBarsCovered` and `chartBars` values in the Data Window and the script's status line.
plot(chartBarsCovered, "Chart bars covered", display = display.data_window + display.status_line)
plot(chartBars, "Chart bars total", display = display.data_window + display.status_line)
// Information box logic.
if showInfoBoxInput
// @variable A single-cell table that displays intrabar information.
var table infoBox = table.new(infoBoxYPosInput + "_" + infoBoxXPosInput, 1, 1)
// @variable The span of the `ltfString` timeframe formatted as a number of automatically selected time units.
string formattedLtf = PCtime.formattedNoOfPeriods(timeframe.in_seconds(ltfString) * 1000)
// @variable A "string" containing the formatted text to display in the `infoBox`.
string txt = str.format(
TAB_TXT, formattedLtf, avgIntrabars, chartBarsCovered, chartBars, chartBarsCovered / chartBars * 100, "'"
)
// Initialize the `infoBox` cell on the first bar.
if barstate.isfirst
table.cell(
infoBox, 0, 0, txt, text_color = infoBoxTxtColorInput, text_size = infoBoxSizeInput,
bgcolor = infoBoxColorInput
)
// Update the cell's text on the latest bar.
else if barstate.islast
table.cell_set_text(infoBox, 0, 0, txt)
// Raise a runtime error if no intrabar data is available.
if ta.cum(intrabars) == 0 and barstate.islast
runtime.error(str.format(ERR_TXT, ltfString, "'"))
//#endregion
█ EXPORTED FUNCTIONS
ltf(userSelection, choice1, choice2, ...)
Returns the optimal lower timeframe string based on user selection and current chart timeframe. Dynamically calculates precision to balance granularity with historical coverage within the 200K intrabar limit.
ltfStats(intrabarValues)
Analyzes an intrabar array returned by request.security_lower_tf() and returns statistics: number of intrabars in current bar, total chart bars covered, and average intrabars per bar.
█ CREDITS AND LICENSING
Original Concept : PineCoders Team
Original Lower TF Library :
License : Mozilla Public License 2.0
Quantum Rotational Field MappingQuantum Rotational Field Mapping (QRFM):
Phase Coherence Detection Through Complex-Plane Oscillator Analysis
Quantum Rotational Field Mapping applies complex-plane mathematics and phase-space analysis to oscillator ensembles, identifying high-probability trend ignition points by measuring when multiple independent oscillators achieve phase coherence. Unlike traditional multi-oscillator approaches that simply stack indicators or use boolean AND/OR logic, this system converts each oscillator into a rotating phasor (vector) in the complex plane and calculates the Coherence Index (CI) —a mathematical measure of how tightly aligned the ensemble has become—then generates signals only when alignment, phase direction, and pairwise entanglement all converge.
The indicator combines three mathematical frameworks: phasor representation using analytic signal theory to extract phase and amplitude from each oscillator, coherence measurement using vector summation in the complex plane to quantify group alignment, and entanglement analysis that calculates pairwise phase agreement across all oscillator combinations. This creates a multi-dimensional confirmation system that distinguishes between random oscillator noise and genuine regime transitions.
What Makes This Original
Complex-Plane Phasor Framework
This indicator implements classical signal processing mathematics adapted for market oscillators. Each oscillator—whether RSI, MACD, Stochastic, CCI, Williams %R, MFI, ROC, or TSI—is first normalized to a common scale, then converted into a complex-plane representation using an in-phase (I) and quadrature (Q) component. The in-phase component is the oscillator value itself, while the quadrature component is calculated as the first difference (derivative proxy), creating a velocity-aware representation.
From these components, the system extracts:
Phase (φ) : Calculated as φ = atan2(Q, I), representing the oscillator's position in its cycle (mapped to -180° to +180°)
Amplitude (A) : Calculated as A = √(I² + Q²), representing the oscillator's strength or conviction
This mathematical approach is fundamentally different from simply reading oscillator values. A phasor captures both where an oscillator is in its cycle (phase angle) and how strongly it's expressing that position (amplitude). Two oscillators can have the same value but be in opposite phases of their cycles—traditional analysis would see them as identical, while QRFM sees them as 180° out of phase (contradictory).
Coherence Index Calculation
The core innovation is the Coherence Index (CI) , borrowed from physics and signal processing. When you have N oscillators, each with phase φₙ, you can represent each as a unit vector in the complex plane: e^(iφₙ) = cos(φₙ) + i·sin(φₙ).
The CI measures what happens when you sum all these vectors:
Resultant Vector : R = Σ e^(iφₙ) = Σ cos(φₙ) + i·Σ sin(φₙ)
Coherence Index : CI = |R| / N
Where |R| is the magnitude of the resultant vector and N is the number of active oscillators.
The CI ranges from 0 to 1:
CI = 1.0 : Perfect coherence—all oscillators have identical phase angles, vectors point in the same direction, creating maximum constructive interference
CI = 0.0 : Complete decoherence—oscillators are randomly distributed around the circle, vectors cancel out through destructive interference
0 < CI < 1 : Partial alignment—some clustering with some scatter
This is not a simple average or correlation. The CI captures phase synchronization across the entire ensemble simultaneously. When oscillators phase-lock (align their cycles), the CI spikes regardless of their individual values. This makes it sensitive to regime transitions that traditional indicators miss.
Dominant Phase and Direction Detection
Beyond measuring alignment strength, the system calculates the dominant phase of the ensemble—the direction the resultant vector points:
Dominant Phase : φ_dom = atan2(Σ sin(φₙ), Σ cos(φₙ))
This gives the "average direction" of all oscillator phases, mapped to -180° to +180°:
+90° to -90° (right half-plane): Bullish phase dominance
+90° to +180° or -90° to -180° (left half-plane): Bearish phase dominance
The combination of CI magnitude (coherence strength) and dominant phase angle (directional bias) creates a two-dimensional signal space. High CI alone is insufficient—you need high CI plus dominant phase pointing in a tradeable direction. This dual requirement is what separates QRFM from simple oscillator averaging.
Entanglement Matrix and Pairwise Coherence
While the CI measures global alignment, the entanglement matrix measures local pairwise relationships. For every pair of oscillators (i, j), the system calculates:
E(i,j) = |cos(φᵢ - φⱼ)|
This represents the phase agreement between oscillators i and j:
E = 1.0 : Oscillators are in-phase (0° or 360° apart)
E = 0.0 : Oscillators are in quadrature (90° apart, orthogonal)
E between 0 and 1 : Varying degrees of alignment
The system counts how many oscillator pairs exceed a user-defined entanglement threshold (e.g., 0.7). This entangled pairs count serves as a confirmation filter: signals require not just high global CI, but also a minimum number of strong pairwise agreements. This prevents false ignitions where CI is high but driven by only two oscillators while the rest remain scattered.
The entanglement matrix creates an N×N symmetric matrix that can be visualized as a web—when many cells are bright (high E values), the ensemble is highly interconnected. When cells are dark, oscillators are moving independently.
Phase-Lock Tolerance Mechanism
A complementary confirmation layer is the phase-lock detector . This calculates the maximum phase spread across all oscillators:
For all pairs (i,j), compute angular distance: Δφ = |φᵢ - φⱼ|, wrapping at 180°
Max Spread = maximum Δφ across all pairs
If max spread < user threshold (e.g., 35°), the ensemble is considered phase-locked —all oscillators are within a narrow angular band.
This differs from entanglement: entanglement measures pairwise cosine similarity (magnitude of alignment), while phase-lock measures maximum angular deviation (tightness of clustering). Both must be satisfied for the highest-conviction signals.
Multi-Layer Visual Architecture
QRFM includes six visual components that represent the same underlying mathematics from different perspectives:
Circular Orbit Plot : A polar coordinate grid showing each oscillator as a vector from origin to perimeter. Angle = phase, radius = amplitude. This is a real-time snapshot of the complex plane. When vectors converge (point in similar directions), coherence is high. When scattered randomly, coherence is low. Users can see phase alignment forming before CI numerically confirms it.
Phase-Time Heat Map : A 2D matrix with rows = oscillators and columns = time bins. Each cell is colored by the oscillator's phase at that time (using a gradient where color hue maps to angle). Horizontal color bands indicate sustained phase alignment over time. Vertical color bands show moments when all oscillators shared the same phase (ignition points). This provides historical pattern recognition.
Entanglement Web Matrix : An N×N grid showing E(i,j) for all pairs. Cells are colored by entanglement strength—bright yellow/gold for high E, dark gray for low E. This reveals which oscillators are driving coherence and which are lagging. For example, if RSI and MACD show high E but Stochastic shows low E with everything, Stochastic is the outlier.
Quantum Field Cloud : A background color overlay on the price chart. Color (green = bullish, red = bearish) is determined by dominant phase. Opacity is determined by CI—high CI creates dense, opaque cloud; low CI creates faint, nearly invisible cloud. This gives an atmospheric "feel" for regime strength without looking at numbers.
Phase Spiral : A smoothed plot of dominant phase over recent history, displayed as a curve that wraps around price. When the spiral is tight and rotating steadily, the ensemble is in coherent rotation (trending). When the spiral is loose or erratic, coherence is breaking down.
Dashboard : A table showing real-time metrics: CI (as percentage), dominant phase (in degrees with directional arrow), field strength (CI × average amplitude), entangled pairs count, phase-lock status (locked/unlocked), quantum state classification ("Ignition", "Coherent", "Collapse", "Chaos"), and collapse risk (recent CI change normalized to 0-100%).
Each component is independently toggleable, allowing users to customize their workspace. The orbit plot is the most essential—it provides intuitive, visual feedback on phase alignment that no numerical dashboard can match.
Core Components and How They Work Together
1. Oscillator Normalization Engine
The foundation is creating a common measurement scale. QRFM supports eight oscillators:
RSI : Normalized from to using overbought/oversold levels (70, 30) as anchors
MACD Histogram : Normalized by dividing by rolling standard deviation, then clamped to
Stochastic %K : Normalized from using (80, 20) anchors
CCI : Divided by 200 (typical extreme level), clamped to
Williams %R : Normalized from using (-20, -80) anchors
MFI : Normalized from using (80, 20) anchors
ROC : Divided by 10, clamped to
TSI : Divided by 50, clamped to
Each oscillator can be individually enabled/disabled. Only active oscillators contribute to phase calculations. The normalization removes scale differences—a reading of +0.8 means "strongly bullish" regardless of whether it came from RSI or TSI.
2. Analytic Signal Construction
For each active oscillator at each bar, the system constructs the analytic signal:
In-Phase (I) : The normalized oscillator value itself
Quadrature (Q) : The bar-to-bar change in the normalized value (first derivative approximation)
This creates a 2D representation: (I, Q). The phase is extracted as:
φ = atan2(Q, I) × (180 / π)
This maps the oscillator to a point on the unit circle. An oscillator at the same value but rising (positive Q) will have a different phase than one that is falling (negative Q). This velocity-awareness is critical—it distinguishes between "at resistance and stalling" versus "at resistance and breaking through."
The amplitude is extracted as:
A = √(I² + Q²)
This represents the distance from origin in the (I, Q) plane. High amplitude means the oscillator is far from neutral (strong conviction). Low amplitude means it's near zero (weak/transitional state).
3. Coherence Calculation Pipeline
For each bar (or every Nth bar if phase sample rate > 1 for performance):
Step 1 : Extract phase φₙ for each of the N active oscillators
Step 2 : Compute complex exponentials: Zₙ = e^(i·φₙ·π/180) = cos(φₙ·π/180) + i·sin(φₙ·π/180)
Step 3 : Sum the complex exponentials: R = Σ Zₙ = (Σ cos φₙ) + i·(Σ sin φₙ)
Step 4 : Calculate magnitude: |R| = √
Step 5 : Normalize by count: CI_raw = |R| / N
Step 6 : Smooth the CI: CI = SMA(CI_raw, smoothing_window)
The smoothing step (default 2 bars) removes single-bar noise spikes while preserving structural coherence changes. Users can adjust this to control reactivity versus stability.
The dominant phase is calculated as:
φ_dom = atan2(Σ sin φₙ, Σ cos φₙ) × (180 / π)
This is the angle of the resultant vector R in the complex plane.
4. Entanglement Matrix Construction
For all unique pairs of oscillators (i, j) where i < j:
Step 1 : Get phases φᵢ and φⱼ
Step 2 : Compute phase difference: Δφ = φᵢ - φⱼ (in radians)
Step 3 : Calculate entanglement: E(i,j) = |cos(Δφ)|
Step 4 : Store in symmetric matrix: matrix = matrix = E(i,j)
The matrix is then scanned: count how many E(i,j) values exceed the user-defined threshold (default 0.7). This count is the entangled pairs metric.
For visualization, the matrix is rendered as an N×N table where cell brightness maps to E(i,j) intensity.
5. Phase-Lock Detection
Step 1 : For all unique pairs (i, j), compute angular distance: Δφ = |φᵢ - φⱼ|
Step 2 : Wrap angles: if Δφ > 180°, set Δφ = 360° - Δφ
Step 3 : Find maximum: max_spread = max(Δφ) across all pairs
Step 4 : Compare to tolerance: phase_locked = (max_spread < tolerance)
If phase_locked is true, all oscillators are within the specified angular cone (e.g., 35°). This is a boolean confirmation filter.
6. Signal Generation Logic
Signals are generated through multi-layer confirmation:
Long Ignition Signal :
CI crosses above ignition threshold (e.g., 0.80)
AND dominant phase is in bullish range (-90° < φ_dom < +90°)
AND phase_locked = true
AND entangled_pairs >= minimum threshold (e.g., 4)
Short Ignition Signal :
CI crosses above ignition threshold
AND dominant phase is in bearish range (φ_dom < -90° OR φ_dom > +90°)
AND phase_locked = true
AND entangled_pairs >= minimum threshold
Collapse Signal :
CI at bar minus CI at current bar > collapse threshold (e.g., 0.55)
AND CI at bar was above 0.6 (must collapse from coherent state, not from already-low state)
These are strict conditions. A high CI alone does not generate a signal—dominant phase must align with direction, oscillators must be phase-locked, and sufficient pairwise entanglement must exist. This multi-factor gating dramatically reduces false signals compared to single-condition triggers.
Calculation Methodology
Phase 1: Oscillator Computation and Normalization
On each bar, the system calculates the raw values for all enabled oscillators using standard Pine Script functions:
RSI: ta.rsi(close, length)
MACD: ta.macd() returning histogram component
Stochastic: ta.stoch() smoothed with ta.sma()
CCI: ta.cci(close, length)
Williams %R: ta.wpr(length)
MFI: ta.mfi(hlc3, length)
ROC: ta.roc(close, length)
TSI: ta.tsi(close, short, long)
Each raw value is then passed through a normalization function:
normalize(value, overbought_level, oversold_level) = 2 × (value - oversold) / (overbought - oversold) - 1
This maps the oscillator's typical range to , where -1 represents extreme bearish, 0 represents neutral, and +1 represents extreme bullish.
For oscillators without fixed ranges (MACD, ROC, TSI), statistical normalization is used: divide by a rolling standard deviation or fixed divisor, then clamp to .
Phase 2: Phasor Extraction
For each normalized oscillator value val:
I = val (in-phase component)
Q = val - val (quadrature component, first difference)
Phase calculation:
phi_rad = atan2(Q, I)
phi_deg = phi_rad × (180 / π)
Amplitude calculation:
A = √(I² + Q²)
These values are stored in arrays: osc_phases and osc_amps for each oscillator n.
Phase 3: Complex Summation and Coherence
Initialize accumulators:
sum_cos = 0
sum_sin = 0
For each oscillator n = 0 to N-1:
phi_rad = osc_phases × (π / 180)
sum_cos += cos(phi_rad)
sum_sin += sin(phi_rad)
Resultant magnitude:
resultant_mag = √(sum_cos² + sum_sin²)
Coherence Index (raw):
CI_raw = resultant_mag / N
Smoothed CI:
CI = SMA(CI_raw, smoothing_window)
Dominant phase:
phi_dom_rad = atan2(sum_sin, sum_cos)
phi_dom_deg = phi_dom_rad × (180 / π)
Phase 4: Entanglement Matrix Population
For i = 0 to N-2:
For j = i+1 to N-1:
phi_i = osc_phases × (π / 180)
phi_j = osc_phases × (π / 180)
delta_phi = phi_i - phi_j
E = |cos(delta_phi)|
matrix_index_ij = i × N + j
matrix_index_ji = j × N + i
entangle_matrix = E
entangle_matrix = E
if E >= threshold:
entangled_pairs += 1
The matrix uses flat array storage with index mapping: index(row, col) = row × N + col.
Phase 5: Phase-Lock Check
max_spread = 0
For i = 0 to N-2:
For j = i+1 to N-1:
delta = |osc_phases - osc_phases |
if delta > 180:
delta = 360 - delta
max_spread = max(max_spread, delta)
phase_locked = (max_spread < tolerance)
Phase 6: Signal Evaluation
Ignition Long :
ignition_long = (CI crosses above threshold) AND
(phi_dom > -90 AND phi_dom < 90) AND
phase_locked AND
(entangled_pairs >= minimum)
Ignition Short :
ignition_short = (CI crosses above threshold) AND
(phi_dom < -90 OR phi_dom > 90) AND
phase_locked AND
(entangled_pairs >= minimum)
Collapse :
CI_prev = CI
collapse = (CI_prev - CI > collapse_threshold) AND (CI_prev > 0.6)
All signals are evaluated on bar close. The crossover and crossunder functions ensure signals fire only once when conditions transition from false to true.
Phase 7: Field Strength and Visualization Metrics
Average Amplitude :
avg_amp = (Σ osc_amps ) / N
Field Strength :
field_strength = CI × avg_amp
Collapse Risk (for dashboard):
collapse_risk = (CI - CI) / max(CI , 0.1)
collapse_risk_pct = clamp(collapse_risk × 100, 0, 100)
Quantum State Classification :
if (CI > threshold AND phase_locked):
state = "Ignition"
else if (CI > 0.6):
state = "Coherent"
else if (collapse):
state = "Collapse"
else:
state = "Chaos"
Phase 8: Visual Rendering
Orbit Plot : For each oscillator, convert polar (phase, amplitude) to Cartesian (x, y) for grid placement:
radius = amplitude × grid_center × 0.8
x = radius × cos(phase × π/180)
y = radius × sin(phase × π/180)
col = center + x (mapped to grid coordinates)
row = center - y
Heat Map : For each oscillator row and time column, retrieve historical phase value at lookback = (columns - col) × sample_rate, then map phase to color using a hue gradient.
Entanglement Web : Render matrix as table cell with background color opacity = E(i,j).
Field Cloud : Background color = (phi_dom > -90 AND phi_dom < 90) ? green : red, with opacity = mix(min_opacity, max_opacity, CI).
All visual components render only on the last bar (barstate.islast) to minimize computational overhead.
How to Use This Indicator
Step 1 : Apply QRFM to your chart. It works on all timeframes and asset classes, though 15-minute to 4-hour timeframes provide the best balance of responsiveness and noise reduction.
Step 2 : Enable the dashboard (default: top right) and the circular orbit plot (default: middle left). These are your primary visual feedback tools.
Step 3 : Optionally enable the heat map, entanglement web, and field cloud based on your preference. New users may find all visuals overwhelming; start with dashboard + orbit plot.
Step 4 : Observe for 50-100 bars to let the indicator establish baseline coherence patterns. Markets have different "normal" CI ranges—some instruments naturally run higher or lower coherence.
Understanding the Circular Orbit Plot
The orbit plot is a polar grid showing oscillator vectors in real-time:
Center point : Neutral (zero phase and amplitude)
Each vector : A line from center to a point on the grid
Vector angle : The oscillator's phase (0° = right/east, 90° = up/north, 180° = left/west, -90° = down/south)
Vector length : The oscillator's amplitude (short = weak signal, long = strong signal)
Vector label : First letter of oscillator name (R = RSI, M = MACD, etc.)
What to watch :
Convergence : When all vectors cluster in one quadrant or sector, CI is rising and coherence is forming. This is your pre-signal warning.
Scatter : When vectors point in random directions (360° spread), CI is low and the market is in a non-trending or transitional regime.
Rotation : When the cluster rotates smoothly around the circle, the ensemble is in coherent oscillation—typically seen during steady trends.
Sudden flips : When the cluster rapidly jumps from one side to the opposite (e.g., +90° to -90°), a phase reversal has occurred—often coinciding with trend reversals.
Example: If you see RSI, MACD, and Stochastic all pointing toward 45° (northeast) with long vectors, while CCI, TSI, and ROC point toward 40-50° as well, coherence is high and dominant phase is bullish. Expect an ignition signal if CI crosses threshold.
Reading Dashboard Metrics
The dashboard provides numerical confirmation of what the orbit plot shows visually:
CI : Displays as 0-100%. Above 70% = high coherence (strong regime), 40-70% = moderate, below 40% = low (poor conditions for trend entries).
Dom Phase : Angle in degrees with directional arrow. ⬆ = bullish bias, ⬇ = bearish bias, ⬌ = neutral.
Field Strength : CI weighted by amplitude. High values (> 0.6) indicate not just alignment but strong alignment.
Entangled Pairs : Count of oscillator pairs with E > threshold. Higher = more confirmation. If minimum is set to 4, you need at least 4 pairs entangled for signals.
Phase Lock : 🔒 YES (all oscillators within tolerance) or 🔓 NO (spread too wide).
State : Real-time classification:
🚀 IGNITION: CI just crossed threshold with phase-lock
⚡ COHERENT: CI is high and stable
💥 COLLAPSE: CI has dropped sharply
🌀 CHAOS: Low CI, scattered phases
Collapse Risk : 0-100% scale based on recent CI change. Above 50% warns of imminent breakdown.
Interpreting Signals
Long Ignition (Blue Triangle Below Price) :
Occurs when CI crosses above threshold (e.g., 0.80)
Dominant phase is in bullish range (-90° to +90°)
All oscillators are phase-locked (within tolerance)
Minimum entangled pairs requirement met
Interpretation : The oscillator ensemble has transitioned from disorder to coherent bullish alignment. This is a high-probability long entry point. The multi-layer confirmation (CI + phase direction + lock + entanglement) ensures this is not a single-oscillator whipsaw.
Short Ignition (Red Triangle Above Price) :
Same conditions as long, but dominant phase is in bearish range (< -90° or > +90°)
Interpretation : Coherent bearish alignment has formed. High-probability short entry.
Collapse (Circles Above and Below Price) :
CI has dropped by more than the collapse threshold (e.g., 0.55) over a 5-bar window
CI was previously above 0.6 (collapsing from coherent state)
Interpretation : Phase coherence has broken down. If you are in a position, this is an exit warning. If looking to enter, stand aside—regime is transitioning.
Phase-Time Heat Map Patterns
Enable the heat map and position it at bottom right. The rows represent individual oscillators, columns represent time bins (most recent on left).
Pattern: Horizontal Color Bands
If a row (e.g., RSI) shows consistent color across columns (say, green for several bins), that oscillator has maintained stable phase over time. If all rows show horizontal bands of similar color, the entire ensemble has been phase-locked for an extended period—this is a strong trending regime.
Pattern: Vertical Color Bands
If a column (single time bin) shows all cells with the same or very similar color, that moment in time had high coherence. These vertical bands often align with ignition signals or major price pivots.
Pattern: Rainbow Chaos
If cells are random colors (red, green, yellow mixed with no pattern), coherence is low. The ensemble is scattered. Avoid trading during these periods unless you have external confirmation.
Pattern: Color Transition
If you see a row transition from red to green (or vice versa) sharply, that oscillator has phase-flipped. If multiple rows do this simultaneously, a regime change is underway.
Entanglement Web Analysis
Enable the web matrix (default: opposite corner from heat map). It shows an N×N grid where N = number of active oscillators.
Bright Yellow/Gold Cells : High pairwise entanglement. For example, if the RSI-MACD cell is bright gold, those two oscillators are moving in phase. If the RSI-Stochastic cell is bright, they are entangled as well.
Dark Gray Cells : Low entanglement. Oscillators are decorrelated or in quadrature.
Diagonal : Always marked with "—" because an oscillator is always perfectly entangled with itself.
How to use :
Scan for clustering: If most cells are bright, coherence is high across the board. If only a few cells are bright, coherence is driven by a subset (e.g., RSI and MACD are aligned, but nothing else is—weak signal).
Identify laggards: If one row/column is entirely dark, that oscillator is the outlier. You may choose to disable it or monitor for when it joins the group (late confirmation).
Watch for web formation: During low-coherence periods, the matrix is mostly dark. As coherence builds, cells begin lighting up. A sudden "web" of connections forming visually precedes ignition signals.
Trading Workflow
Step 1: Monitor Coherence Level
Check the dashboard CI metric or observe the orbit plot. If CI is below 40% and vectors are scattered, conditions are poor for trend entries. Wait.
Step 2: Detect Coherence Building
When CI begins rising (say, from 30% to 50-60%) and you notice vectors on the orbit plot starting to cluster, coherence is forming. This is your alert phase—do not enter yet, but prepare.
Step 3: Confirm Phase Direction
Check the dominant phase angle and the orbit plot quadrant where clustering is occurring:
Clustering in right half (0° to ±90°): Bullish bias forming
Clustering in left half (±90° to 180°): Bearish bias forming
Verify the dashboard shows the corresponding directional arrow (⬆ or ⬇).
Step 4: Wait for Signal Confirmation
Do not enter based on rising CI alone. Wait for the full ignition signal:
CI crosses above threshold
Phase-lock indicator shows 🔒 YES
Entangled pairs count >= minimum
Directional triangle appears on chart
This ensures all layers have aligned.
Step 5: Execute Entry
Long : Blue triangle below price appears → enter long
Short : Red triangle above price appears → enter short
Step 6: Position Management
Initial Stop : Place stop loss based on your risk management rules (e.g., recent swing low/high, ATR-based buffer).
Monitoring :
Watch the field cloud density. If it remains opaque and colored in your direction, the regime is intact.
Check dashboard collapse risk. If it rises above 50%, prepare for exit.
Monitor the orbit plot. If vectors begin scattering or the cluster flips to the opposite side, coherence is breaking.
Exit Triggers :
Collapse signal fires (circles appear)
Dominant phase flips to opposite half-plane
CI drops below 40% (coherence lost)
Price hits your profit target or trailing stop
Step 7: Post-Exit Analysis
After exiting, observe whether a new ignition forms in the opposite direction (reversal) or if CI remains low (transition to range). Use this to decide whether to re-enter, reverse, or stand aside.
Best Practices
Use Price Structure as Context
QRFM identifies when coherence forms but does not specify where price will go. Combine ignition signals with support/resistance levels, trendlines, or chart patterns. For example:
Long ignition near a major support level after a pullback: high-probability bounce
Long ignition in the middle of a range with no structure: lower probability
Multi-Timeframe Confirmation
Open QRFM on two timeframes simultaneously:
Higher timeframe (e.g., 4-hour): Use CI level to determine regime bias. If 4H CI is above 60% and dominant phase is bullish, the market is in a bullish regime.
Lower timeframe (e.g., 15-minute): Execute entries on ignition signals that align with the higher timeframe bias.
This prevents counter-trend trades and increases win rate.
Distinguish Between Regime Types
High CI, stable dominant phase (State: Coherent) : Trending market. Ignitions are continuation signals; collapses are profit-taking or reversal warnings.
Low CI, erratic dominant phase (State: Chaos) : Ranging or choppy market. Avoid ignition signals or reduce position size. Wait for coherence to establish.
Moderate CI with frequent collapses : Whipsaw environment. Use wider stops or stand aside.
Adjust Parameters to Instrument and Timeframe
Crypto/Forex (high volatility) : Lower ignition threshold (0.65-0.75), lower CI smoothing (2-3), shorter oscillator lengths (7-10).
Stocks/Indices (moderate volatility) : Standard settings (threshold 0.75-0.85, smoothing 5-7, oscillator lengths 14).
Lower timeframes (5-15 min) : Reduce phase sample rate to 1-2 for responsiveness.
Higher timeframes (daily+) : Increase CI smoothing and oscillator lengths for noise reduction.
Use Entanglement Count as Conviction Filter
The minimum entangled pairs setting controls signal strictness:
Low (1-2) : More signals, lower quality (acceptable if you have other confirmation)
Medium (3-5) : Balanced (recommended for most traders)
High (6+) : Very strict, fewer signals, highest quality
Adjust based on your trade frequency preference and risk tolerance.
Monitor Oscillator Contribution
Use the entanglement web to see which oscillators are driving coherence. If certain oscillators are consistently dark (low E with all others), they may be adding noise. Consider disabling them. For example:
On low-volume instruments, MFI may be unreliable → disable MFI
On strongly trending instruments, mean-reversion oscillators (Stochastic, RSI) may lag → reduce weight or disable
Respect the Collapse Signal
Collapse events are early warnings. Price may continue in the original direction for several bars after collapse fires, but the underlying regime has weakened. Best practice:
If in profit: Take partial or full profit on collapse
If at breakeven/small loss: Exit immediately
If collapse occurs shortly after entry: Likely a false ignition; exit to avoid drawdown
Collapses do not guarantee immediate reversals—they signal uncertainty .
Combine with Volume Analysis
If your instrument has reliable volume:
Ignitions with expanding volume: Higher conviction
Ignitions with declining volume: Weaker, possibly false
Collapses with volume spikes: Strong reversal signal
Collapses with low volume: May just be consolidation
Volume is not built into QRFM (except via MFI), so add it as external confirmation.
Observe the Phase Spiral
The spiral provides a quick visual cue for rotation consistency:
Tight, smooth spiral : Ensemble is rotating coherently (trending)
Loose, erratic spiral : Phase is jumping around (ranging or transitional)
If the spiral tightens, coherence is building. If it loosens, coherence is dissolving.
Do Not Overtrade Low-Coherence Periods
When CI is persistently below 40% and the state is "Chaos," the market is not in a regime where phase analysis is predictive. During these times:
Reduce position size
Widen stops
Wait for coherence to return
QRFM's strength is regime detection. If there is no regime, the tool correctly signals "stand aside."
Use Alerts Strategically
Set alerts for:
Long Ignition
Short Ignition
Collapse
Phase Lock (optional)
Configure alerts to "Once per bar close" to avoid intrabar repainting and noise. When an alert fires, manually verify:
Orbit plot shows clustering
Dashboard confirms all conditions
Price structure supports the trade
Do not blindly trade alerts—use them as prompts for analysis.
Ideal Market Conditions
Best Performance
Instruments :
Liquid, actively traded markets (major forex pairs, large-cap stocks, major indices, top-tier crypto)
Instruments with clear cyclical oscillator behavior (avoid extremely illiquid or manipulated markets)
Timeframes :
15-minute to 4-hour: Optimal balance of noise reduction and responsiveness
1-hour to daily: Slower, higher-conviction signals; good for swing trading
5-minute: Acceptable for scalping if parameters are tightened and you accept more noise
Market Regimes :
Trending markets with periodic retracements (where oscillators cycle through phases predictably)
Breakout environments (coherence forms before/during breakout; collapse occurs at exhaustion)
Rotational markets with clear swings (oscillators phase-lock at turning points)
Volatility :
Moderate to high volatility (oscillators have room to move through their ranges)
Stable volatility regimes (sudden VIX spikes or flash crashes may create false collapses)
Challenging Conditions
Instruments :
Very low liquidity markets (erratic price action creates unstable oscillator phases)
Heavily news-driven instruments (fundamentals may override technical coherence)
Highly correlated instruments (oscillators may all reflect the same underlying factor, reducing independence)
Market Regimes :
Deep, prolonged consolidation (oscillators remain near neutral, CI is chronically low, few signals fire)
Extreme chop with no directional bias (oscillators whipsaw, coherence never establishes)
Gap-driven markets (large overnight gaps create phase discontinuities)
Timeframes :
Sub-5-minute charts: Noise dominates; oscillators flip rapidly; coherence is fleeting and unreliable
Weekly/monthly: Oscillators move extremely slowly; signals are rare; better suited for long-term positioning than active trading
Special Cases :
During major economic releases or earnings: Oscillators may lag price or become decorrelated as fundamentals overwhelm technicals. Reduce position size or stand aside.
In extremely low-volatility environments (e.g., holiday periods): Oscillators compress to neutral, CI may be artificially high due to lack of movement, but signals lack follow-through.
Adaptive Behavior
QRFM is designed to self-adapt to poor conditions:
When coherence is genuinely absent, CI remains low and signals do not fire
When only a subset of oscillators aligns, entangled pairs count stays below threshold and signals are filtered out
When phase-lock cannot be achieved (oscillators too scattered), the lock filter prevents signals
This means the indicator will naturally produce fewer (or zero) signals during unfavorable conditions, rather than generating false signals. This is a feature —it keeps you out of low-probability trades.
Parameter Optimization by Trading Style
Scalping (5-15 Minute Charts)
Goal : Maximum responsiveness, accept higher noise
Oscillator Lengths :
RSI: 7-10
MACD: 8/17/6
Stochastic: 8-10, smooth 2-3
CCI: 14-16
Others: 8-12
Coherence Settings :
CI Smoothing Window: 2-3 bars (fast reaction)
Phase Sample Rate: 1 (every bar)
Ignition Threshold: 0.65-0.75 (lower for more signals)
Collapse Threshold: 0.40-0.50 (earlier exit warnings)
Confirmation :
Phase Lock Tolerance: 40-50° (looser, easier to achieve)
Min Entangled Pairs: 2-3 (fewer oscillators required)
Visuals :
Orbit Plot + Dashboard only (reduce screen clutter for fast decisions)
Disable heavy visuals (heat map, web) for performance
Alerts :
Enable all ignition and collapse alerts
Set to "Once per bar close"
Day Trading (15-Minute to 1-Hour Charts)
Goal : Balance between responsiveness and reliability
Oscillator Lengths :
RSI: 14 (standard)
MACD: 12/26/9 (standard)
Stochastic: 14, smooth 3
CCI: 20
Others: 10-14
Coherence Settings :
CI Smoothing Window: 3-5 bars (balanced)
Phase Sample Rate: 2-3
Ignition Threshold: 0.75-0.85 (moderate selectivity)
Collapse Threshold: 0.50-0.55 (balanced exit timing)
Confirmation :
Phase Lock Tolerance: 30-40° (moderate tightness)
Min Entangled Pairs: 4-5 (reasonable confirmation)
Visuals :
Orbit Plot + Dashboard + Heat Map or Web (choose one)
Field Cloud for regime backdrop
Alerts :
Ignition and collapse alerts
Optional phase-lock alert for advance warning
Swing Trading (4-Hour to Daily Charts)
Goal : High-conviction signals, minimal noise, fewer trades
Oscillator Lengths :
RSI: 14-21
MACD: 12/26/9 or 19/39/9 (longer variant)
Stochastic: 14-21, smooth 3-5
CCI: 20-30
Others: 14-20
Coherence Settings :
CI Smoothing Window: 5-10 bars (very smooth)
Phase Sample Rate: 3-5
Ignition Threshold: 0.80-0.90 (high bar for entry)
Collapse Threshold: 0.55-0.65 (only significant breakdowns)
Confirmation :
Phase Lock Tolerance: 20-30° (tight clustering required)
Min Entangled Pairs: 5-7 (strong confirmation)
Visuals :
All modules enabled (you have time to analyze)
Heat Map for multi-bar pattern recognition
Web for deep confirmation analysis
Alerts :
Ignition and collapse
Review manually before entering (no rush)
Position/Long-Term Trading (Daily to Weekly Charts)
Goal : Rare, very high-conviction regime shifts
Oscillator Lengths :
RSI: 21-30
MACD: 19/39/9 or 26/52/12
Stochastic: 21, smooth 5
CCI: 30-50
Others: 20-30
Coherence Settings :
CI Smoothing Window: 10-14 bars
Phase Sample Rate: 5 (every 5th bar to reduce computation)
Ignition Threshold: 0.85-0.95 (only extreme alignment)
Collapse Threshold: 0.60-0.70 (major regime breaks only)
Confirmation :
Phase Lock Tolerance: 15-25° (very tight)
Min Entangled Pairs: 6+ (broad consensus required)
Visuals :
Dashboard + Orbit Plot for quick checks
Heat Map to study historical coherence patterns
Web to verify deep entanglement
Alerts :
Ignition only (collapses are less critical on long timeframes)
Manual review with fundamental analysis overlay
Performance Optimization (Low-End Systems)
If you experience lag or slow rendering:
Reduce Visual Load :
Orbit Grid Size: 8-10 (instead of 12+)
Heat Map Time Bins: 5-8 (instead of 10+)
Disable Web Matrix entirely if not needed
Disable Field Cloud and Phase Spiral
Reduce Calculation Frequency :
Phase Sample Rate: 5-10 (calculate every 5-10 bars)
Max History Depth: 100-200 (instead of 500+)
Disable Unused Oscillators :
If you only want RSI, MACD, and Stochastic, disable the other five. Fewer oscillators = smaller matrices, faster loops.
Simplify Dashboard :
Choose "Small" dashboard size
Reduce number of metrics displayed
These settings will not significantly degrade signal quality (signals are based on bar-close calculations, which remain accurate), but will improve chart responsiveness.
Important Disclaimers
This indicator is a technical analysis tool designed to identify periods of phase coherence across an ensemble of oscillators. It is not a standalone trading system and does not guarantee profitable trades. The Coherence Index, dominant phase, and entanglement metrics are mathematical calculations applied to historical price data—they measure past oscillator behavior and do not predict future price movements with certainty.
No Predictive Guarantee : High coherence indicates that oscillators are currently aligned, which historically has coincided with trending or directional price movement. However, past alignment does not guarantee future trends. Markets can remain coherent while prices consolidate, or lose coherence suddenly due to news, liquidity changes, or other factors not captured by oscillator mathematics.
Signal Confirmation is Probabilistic : The multi-layer confirmation system (CI threshold + dominant phase + phase-lock + entanglement) is designed to filter out low-probability setups. This increases the proportion of valid signals relative to false signals, but does not eliminate false signals entirely. Users should combine QRFM with additional analysis—support and resistance levels, volume confirmation, multi-timeframe alignment, and fundamental context—before executing trades.
Collapse Signals are Warnings, Not Reversals : A coherence collapse indicates that the oscillator ensemble has lost alignment. This often precedes trend exhaustion or reversals, but can also occur during healthy pullbacks or consolidations. Price may continue in the original direction after a collapse. Use collapses as risk management cues (tighten stops, take partial profits) rather than automatic reversal entries.
Market Regime Dependency : QRFM performs best in markets where oscillators exhibit cyclical, mean-reverting behavior and where trends are punctuated by retracements. In markets dominated by fundamental shocks, gap openings, or extreme low-liquidity conditions, oscillator coherence may be less reliable. During such periods, reduce position size or stand aside.
Risk Management is Essential : All trading involves risk of loss. Use appropriate stop losses, position sizing, and risk-per-trade limits. The indicator does not specify stop loss or take profit levels—these must be determined by the user based on their risk tolerance and account size. Never risk more than you can afford to lose.
Parameter Sensitivity : The indicator's behavior changes with input parameters. Aggressive settings (low thresholds, loose tolerances) produce more signals with lower average quality. Conservative settings (high thresholds, tight tolerances) produce fewer signals with higher average quality. Users should backtest and forward-test parameter sets on their specific instruments and timeframes before committing real capital.
No Repainting by Design : All signal conditions are evaluated on bar close using bar-close values. However, the visual components (orbit plot, heat map, dashboard) update in real-time during bar formation for monitoring purposes. For trade execution, rely on the confirmed signals (triangles and circles) that appear only after the bar closes.
Computational Load : QRFM performs extensive calculations, including nested loops for entanglement matrices and real-time table rendering. On lower-powered devices or when running multiple indicators simultaneously, users may experience lag. Use the performance optimization settings (reduce visual complexity, increase phase sample rate, disable unused oscillators) to improve responsiveness.
This system is most effective when used as one component within a broader trading methodology that includes sound risk management, multi-timeframe analysis, market context awareness, and disciplined execution. It is a tool for regime detection and signal confirmation, not a substitute for comprehensive trade planning.
Technical Notes
Calculation Timing : All signal logic (ignition, collapse) is evaluated using bar-close values. The barstate.isconfirmed or implicit bar-close behavior ensures signals do not repaint. Visual components (tables, plots) render on every tick for real-time feedback but do not affect signal generation.
Phase Wrapping : Phase angles are calculated in the range -180° to +180° using atan2. Angular distance calculations account for wrapping (e.g., the distance between +170° and -170° is 20°, not 340°). This ensures phase-lock detection works correctly across the ±180° boundary.
Array Management : The indicator uses fixed-size arrays for oscillator phases, amplitudes, and the entanglement matrix. The maximum number of oscillators is 8. If fewer oscillators are enabled, array sizes shrink accordingly (only active oscillators are processed).
Matrix Indexing : The entanglement matrix is stored as a flat array with size N×N, where N is the number of active oscillators. Index mapping: index(row, col) = row × N + col. Symmetric pairs (i,j) and (j,i) are stored identically.
Normalization Stability : Oscillators are normalized to using fixed reference levels (e.g., RSI overbought/oversold at 70/30). For unbounded oscillators (MACD, ROC, TSI), statistical normalization (division by rolling standard deviation) is used, with clamping to prevent extreme outliers from distorting phase calculations.
Smoothing and Lag : The CI smoothing window (SMA) introduces lag proportional to the window size. This is intentional—it filters out single-bar noise spikes in coherence. Users requiring faster reaction can reduce the smoothing window to 1-2 bars, at the cost of increased sensitivity to noise.
Complex Number Representation : Pine Script does not have native complex number types. Complex arithmetic is implemented using separate real and imaginary accumulators (sum_cos, sum_sin) and manual calculation of magnitude (sqrt(real² + imag²)) and argument (atan2(imag, real)).
Lookback Limits : The indicator respects Pine Script's maximum lookback constraints. Historical phase and amplitude values are accessed using the operator, with lookback limited to the chart's available bar history (max_bars_back=5000 declared).
Visual Rendering Performance : Tables (orbit plot, heat map, web, dashboard) are conditionally deleted and recreated on each update using table.delete() and table.new(). This prevents memory leaks but incurs redraw overhead. Rendering is restricted to barstate.islast (last bar) to minimize computational load—historical bars do not render visuals.
Alert Condition Triggers : alertcondition() functions evaluate on bar close when their boolean conditions transition from false to true. Alerts do not fire repeatedly while a condition remains true (e.g., CI stays above threshold for 10 bars fires only once on the initial cross).
Color Gradient Functions : The phaseColor() function maps phase angles to RGB hues using sine waves offset by 120° (red, green, blue channels). This creates a continuous spectrum where -180° to +180° spans the full color wheel. The amplitudeColor() function maps amplitude to grayscale intensity. The coherenceColor() function uses cos(phase) to map contribution to CI (positive = green, negative = red).
No External Data Requests : QRFM operates entirely on the chart's symbol and timeframe. It does not use request.security() or access external data sources. All calculations are self-contained, avoiding lookahead bias from higher-timeframe requests.
Deterministic Behavior : Given identical input parameters and price data, QRFM produces identical outputs. There are no random elements, probabilistic sampling, or time-of-day dependencies.
— Dskyz, Engineering precision. Trading coherence.
Hellenic EMA Matrix - Α Ω PremiumHellenic EMA Matrix - Alpha Omega Premium
Complete User Guide
Table of Contents
Introduction
Indicator Philosophy
Mathematical Constants
EMA Types
Settings
Trading Signals
Visualization
Usage Strategies
FAQ
Introduction
Hellenic EMA Matrix is a premium indicator based on mathematical constants of nature: Phi (Phi - Golden Ratio), Pi (Pi), e (Euler's number). The indicator uses these universal constants to create dynamic EMAs that adapt to the natural rhythms of the market.
Key Features:
6 EMA types based on mathematical constants
Premium visualization with Neon Glow and Gradient Clouds
Automatic Fast/Mid/Slow EMA sorting
STRONG signals for powerful trends
Pulsing Ribbon Bar for instant trend assessment
Works on all timeframes (M1 - MN)
Indicator Philosophy
Why Mathematical Constants?
Traditional EMAs use arbitrary periods (9, 21, 50, 200). Hellenic Matrix goes further, using universal mathematical constants found in nature:
Phi (1.618) - Golden Ratio: galaxy spirals, seashells, human body proportions
Pi (3.14159) - Pi: circles, waves, cycles
e (2.71828) - Natural logarithm base: exponential growth, radioactive decay
Markets are also a natural system composed of millions of participants. Using mathematical constants allows tuning into the natural rhythms of market cycles.
Mathematical Constants
Phi (Phi) - Golden Ratio
Phi = 1.618033988749895
Properties:
Phi² = Phi + 1 = 2.618
Phi³ = 4.236
Phi⁴ = 6.854
Application: Ideal for trending movements and Fibonacci corrections
Pi (Pi) - Pi Number
Pi = 3.141592653589793
Properties:
2Pi = 6.283 (full circle)
3Pi = 9.425
4Pi = 12.566
Application: Excellent for cyclical markets and wave structures
e (Euler) - Euler's Number
e = 2.718281828459045
Properties:
e² = 7.389
e³ = 20.085
e⁴ = 54.598
Application: Suitable for exponential movements and volatile markets
EMA Types
1. Phi (Phi) - Golden Ratio EMA
Description: EMA based on the golden ratio
Period Formula:
Period = Phi^n × Base Multiplier
Parameters:
Phi Power Level (1-8): Power of Phi
Phi¹ = 1.618 → ~16 period (with Base=10)
Phi² = 2.618 → ~26 period
Phi³ = 4.236 → ~42 period (recommended)
Phi⁴ = 6.854 → ~69 period
Recommendations:
Phi² or Phi³ for day trading
Phi⁴ or Phi⁵ for swing trading
Works excellently as Fast EMA
2. Pi (Pi) - Circular EMA
Description: EMA based on Pi for cyclical movements
Period Formula:
Period = Pi × Multiple × Base Multiplier
Parameters:
Pi Multiple (1-10): Pi multiplier
1Pi = 3.14 → ~31 period (with Base=10)
2Pi = 6.28 → ~63 period (recommended)
3Pi = 9.42 → ~94 period
Recommendations:
2Pi ideal as Mid or Slow EMA
Excellently identifies cycles and waves
Use on volatile markets (crypto, forex)
3. e (Euler) - Natural EMA
Description: EMA based on natural logarithm
Period Formula:
Period = e^n × Base Multiplier
Parameters:
e Power Level (1-6): Power of e
e¹ = 2.718 → ~27 period (with Base=10)
e² = 7.389 → ~74 period (recommended)
e³ = 20.085 → ~201 period
Recommendations:
e² works excellently as Slow EMA
Ideal for stocks and indices
Filters noise well on lower timeframes
4. Delta (Delta) - Adaptive EMA
Description: Adaptive EMA that changes period based on volatility
Period Formula:
Period = Base Period × (1 + (Volatility - 1) × Factor)
Parameters:
Delta Base Period (5-200): Base period (default 20)
Delta Volatility Sensitivity (0.5-5.0): Volatility sensitivity (default 2.0)
How it works:
During low volatility → period decreases → EMA reacts faster
During high volatility → period increases → EMA smooths noise
Recommendations:
Works excellently on news and sharp movements
Use as Fast EMA for quick adaptation
Sensitivity 2.0-3.0 for crypto, 1.0-2.0 for stocks
5. Sigma (Sigma) - Composite EMA
Description: Composite EMA combining multiple active EMAs
Composition Methods:
Weighted Average (default):
Sigma = (Phi + Pi + e + Delta) / 4
Simple average of all active EMAs
Geometric Mean:
Sigma = fourth_root(Phi × Pi × e × Delta)
Geometric mean (more conservative)
Harmonic Mean:
Sigma = 4 / (1/Phi + 1/Pi + 1/e + 1/Delta)
Harmonic mean (more weight to smaller values)
Recommendations:
Enable for additional confirmation
Use as Mid EMA
Weighted Average - most universal method
6. Lambda (Lambda) - Wave EMA
Description: Wave EMA with sinusoidal period modulation
Period Formula:
Period = Base Period × (1 + Amplitude × sin(2Pi × bar / Frequency))
Parameters:
Lambda Base Period (10-200): Base period
Lambda Wave Amplitude (0.1-2.0): Wave amplitude
Lambda Wave Frequency (10-200): Wave frequency in bars
How it works:
Period pulsates sinusoidally
Creates wave effect following market cycles
Recommendations:
Experimental EMA for advanced users
Works well on cyclical markets
Frequency = 50 for day trading, 100+ for swing
Settings
Matrix Core Settings
Base Multiplier (1-100)
Multiplies all EMA periods
Base = 1: Very fast EMAs (Phi³ = 4, 2Pi = 6, e² = 7)
Base = 10: Standard (Phi³ = 42, 2Pi = 63, e² = 74)
Base = 20: Slow EMAs (Phi³ = 85, 2Pi = 126, e² = 148)
Recommendations by timeframe:
M1-M5: Base = 5-10
M15-H1: Base = 10-15 (recommended)
H4-D1: Base = 15-25
W1-MN: Base = 25-50
Matrix Source
Data source selection for EMA calculation:
close - closing price (standard)
open - opening price
high - high
low - low
hl2 - (high + low) / 2
hlc3 - (high + low + close) / 3
ohlc4 - (open + high + low + close) / 4
When to change:
hlc3 or ohlc4 for smoother signals
high for aggressive longs
low for aggressive shorts
Manual EMA Selection
Critically important setting! Determines which EMAs are used for signal generation.
Use Manual Fast/Slow/Mid Selection
Enabled (default): You select EMAs manually
Disabled: Automatic selection by periods
Fast EMA
Fast EMA - reacts first to price changes
Recommendations:
Phi Golden (recommended) - universal choice
Delta Adaptive - for volatile markets
Must be fastest (smallest period)
Slow EMA
Slow EMA - determines main trend
Recommendations:
Pi Circular (recommended) - excellent trend filter
e Natural - for smoother trend
Must be slowest (largest period)
Mid EMA
Mid EMA - additional signal filter
Recommendations:
e Natural (recommended) - excellent middle level
Pi Circular - alternative
None - for more frequent signals (only 2 EMAs)
IMPORTANT: The indicator automatically sorts selected EMAs by their actual periods:
Fast = EMA with smallest period
Mid = EMA with middle period
Slow = EMA with largest period
Therefore, you can select any combination - the indicator will arrange them correctly!
Premium Visualization
Neon Glow
Enable Neon Glow for EMAs - adds glowing effect around EMA lines
Glow Strength:
Light - subtle glow
Medium (recommended) - optimal balance
Strong - bright glow (may be too bright)
Effect: 2 glow layers around each EMA for 3D effect
Gradient Clouds
Enable Gradient Clouds - fills space between EMAs with gradient
Parameters:
Cloud Transparency (85-98): Cloud transparency
95-97 (recommended)
Higher = more transparent
Dynamic Cloud Intensity - automatically changes transparency based on EMA distance
Cloud Colors:
Phi-Pi Cloud:
Blue - when Pi above Phi (bullish)
Gold - when Phi above Pi (bearish)
Pi-e Cloud:
Green - when e above Pi (bullish)
Blue - when Pi above e (bearish)
2 layers for volumetric effect
Pulsing Ribbon Bar
Enable Pulsing Indicator Bar - pulsing strip at bottom/top of chart
Parameters:
Ribbon Position: Top / Bottom (recommended)
Pulse Speed: Slow / Medium (recommended) / Fast
Symbols and colors:
Green filled square - STRONG BULLISH
Pink filled square - STRONG BEARISH
Blue hollow square - Bullish (regular)
Red hollow square - Bearish (regular)
Purple rectangle - Neutral
Effect: Pulsation with sinusoid for living market feel
Signal Bar Highlights
Enable Signal Bar Highlights - highlights bars with signals
Parameters:
Highlight Transparency (88-96): Highlight transparency
Highlight Style:
Light Fill (recommended) - bar background fill
Thin Line - bar outline only
Highlights:
Golden Cross - green
Death Cross - pink
STRONG BUY - green
STRONG SELL - pink
Show Greek Labels
Shows Greek alphabet letters on last bar:
Phi - Phi EMA (gold)
Pi - Pi EMA (blue)
e - Euler EMA (green)
Delta - Delta EMA (purple)
Sigma - Sigma EMA (pink)
When to use: For education or presentations
Show Old Background
Old background style (not recommended):
Green background - STRONG BULLISH
Pink background - STRONG BEARISH
Blue background - Bullish
Red background - Bearish
Not recommended - use new Gradient Clouds and Pulsing Bar
Info Table
Show Info Table - table with indicator information
Parameters:
Position: Top Left / Top Right (recommended) / Bottom Left / Bottom Right
Size: Tiny / Small (recommended) / Normal / Large
Table contents:
EMA list - periods and current values of all active EMAs
Effects - active visual effects
TREND - current trend state:
STRONG UP - strong bullish
STRONG DOWN - strong bearish
Bullish - regular bullish
Bearish - regular bearish
Neutral - neutral
Momentum % - percentage deviation of price from Fast EMA
Setup - current Fast/Slow/Mid configuration
Trading Signals
Show Golden/Death Cross
Golden Cross - Fast EMA crosses Slow EMA from below (bullish signal) Death Cross - Fast EMA crosses Slow EMA from above (bearish signal)
Symbols:
Yellow dot "GC" below - Golden Cross
Dark red dot "DC" above - Death Cross
Show STRONG Signals
STRONG BUY and STRONG SELL - the most powerful indicator signals
Conditions for STRONG BULLISH:
EMA Alignment: Fast > Mid > Slow (all EMAs aligned)
Trend: Fast > Slow (clear uptrend)
Distance: EMAs separated by minimum 0.15%
Price Position: Price above Fast EMA
Fast Slope: Fast EMA rising
Slow Slope: Slow EMA rising
Mid Trending: Mid EMA also rising (if enabled)
Conditions for STRONG BEARISH:
Same but in reverse
Visual display:
Green label "STRONG BUY" below bar
Pink label "STRONG SELL" above bar
Difference from Golden/Death Cross:
Golden/Death Cross = crossing moment (1 bar)
STRONG signal = sustained trend (lasts several bars)
IMPORTANT: After fixes, STRONG signals now:
Work on all timeframes (M1 to MN)
Don't break on small retracements
Work with any Fast/Mid/Slow combination
Automatically adapt thanks to EMA sorting
Show Stop Loss/Take Profit
Automatic SL/TP level calculation on STRONG signal
Parameters:
Stop Loss (ATR) (0.5-5.0): ATR multiplier for stop loss
1.5 (recommended) - standard
1.0 - tight stop
2.0-3.0 - wide stop
Take Profit R:R (1.0-5.0): Risk/reward ratio
2.0 (recommended) - standard (risk 1.5 ATR, profit 3.0 ATR)
1.5 - conservative
3.0-5.0 - aggressive
Formulas:
LONG:
Stop Loss = Entry - (ATR × Stop Loss ATR)
Take Profit = Entry + (ATR × Stop Loss ATR × Take Profit R:R)
SHORT:
Stop Loss = Entry + (ATR × Stop Loss ATR)
Take Profit = Entry - (ATR × Stop Loss ATR × Take Profit R:R)
Visualization:
Red X - Stop Loss
Green X - Take Profit
Levels remain active while STRONG signal persists
Trading Signals
Signal Types
1. Golden Cross
Description: Fast EMA crosses Slow EMA from below
Signal: Beginning of bullish trend
How to trade:
ENTRY: On bar close with Golden Cross
STOP: Below local low or below Slow EMA
TARGET: Next resistance level or 2:1 R:R
Strengths:
Simple and clear
Works well on trending markets
Clear entry point
Weaknesses:
Lags (signal after movement starts)
Many false signals in ranging markets
May be late on fast moves
Optimal timeframes: H1, H4, D1
2. Death Cross
Description: Fast EMA crosses Slow EMA from above
Signal: Beginning of bearish trend
How to trade:
ENTRY: On bar close with Death Cross
STOP: Above local high or above Slow EMA
TARGET: Next support level or 2:1 R:R
Application: Mirror of Golden Cross
3. STRONG BUY
Description: All EMAs aligned + trend + all EMAs rising
Signal: Powerful bullish trend
How to trade:
ENTRY: On bar close with STRONG BUY or on pullback to Fast EMA
STOP: Below Fast EMA or automatic SL (if enabled)
TARGET: Automatic TP (if enabled) or by levels
TRAILING: Follow Fast EMA
Entry strategies:
Aggressive: Enter immediately on signal
Conservative: Wait for pullback to Fast EMA, then enter on bounce
Pyramiding: Add positions on pullbacks to Mid EMA
Position management:
Hold while STRONG signal active
Exit on STRONG SELL or Death Cross appearance
Move stop behind Fast EMA
Strengths:
Most reliable indicator signal
Doesn't break on pullbacks
Catches large moves
Works on all timeframes
Weaknesses:
Appears less frequently than other signals
Requires confirmation (multiple conditions)
Optimal timeframes: All (M5 - D1)
4. STRONG SELL
Description: All EMAs aligned down + downtrend + all EMAs falling
Signal: Powerful bearish trend
How to trade: Mirror of STRONG BUY
Visual Signals
Pulsing Ribbon Bar
Quick market assessment at a glance:
Symbol Color State
Filled square Green STRONG BULLISH
Filled square Pink STRONG BEARISH
Hollow square Blue Bullish
Hollow square Red Bearish
Rectangle Purple Neutral
Pulsation: Sinusoidal, creates living effect
Signal Bar Highlights
Bars with signals are highlighted:
Green highlight: STRONG BUY or Golden Cross
Pink highlight: STRONG SELL or Death Cross
Gradient Clouds
Colored space between EMAs shows trend strength:
Wide clouds - strong trend
Narrow clouds - weak trend or consolidation
Color change - trend change
Info Table
Quick reference in corner:
TREND: Current state (STRONG UP, Bullish, Neutral, Bearish, STRONG DOWN)
Momentum %: Movement strength
Effects: Active visual effects
Setup: Fast/Slow/Mid configuration
Usage Strategies
Strategy 1: "Golden Trailing"
Idea: Follow STRONG signals using Fast EMA as trailing stop
Settings:
Fast: Phi Golden (Phi³)
Mid: Pi Circular (2Pi)
Slow: e Natural (e²)
Base Multiplier: 10
Timeframe: H1, H4
Entry rules:
Wait for STRONG BUY
Enter on bar close or on pullback to Fast EMA
Stop below Fast EMA
Management:
Hold position while STRONG signal active
Move stop behind Fast EMA daily
Exit on STRONG SELL or Death Cross
Take Profit:
Partially close at +2R
Trail remainder until exit signal
For whom: Swing traders, trend followers
Pros:
Catches large moves
Simple rules
Emotionally comfortable
Cons:
Requires patience
Possible extended drawdowns on pullbacks
Strategy 2: "Scalping Bounces"
Idea: Scalp bounces from Fast EMA during STRONG trend
Settings:
Fast: Delta Adaptive (Base 15, Sensitivity 2.0)
Mid: Phi Golden (Phi²)
Slow: Pi Circular (2Pi)
Base Multiplier: 5
Timeframe: M5, M15
Entry rules:
STRONG signal must be active
Wait for price pullback to Fast EMA
Enter on bounce (candle closes above/below Fast EMA)
Stop behind local extreme (15-20 pips)
Take Profit:
+1.5R or to Mid EMA
Or to next level
For whom: Active day traders
Pros:
Many signals
Clear entry point
Quick profits
Cons:
Requires constant monitoring
Not all bounces work
Requires discipline for frequent trading
Strategy 3: "Triple Filter"
Idea: Enter only when all 3 EMAs and price perfectly aligned
Settings:
Fast: Phi Golden (Phi³)
Mid: e Natural (e²)
Slow: Pi Circular (3Pi)
Base Multiplier: 15
Timeframe: H4, D1
Entry rules (LONG):
STRONG BUY active
Price above all three EMAs
Fast > Mid > Slow (all aligned)
All EMAs rising (slope up)
Gradient Clouds wide and bright
Entry:
On bar close meeting all conditions
Or on next pullback to Fast EMA
Stop:
Below Mid EMA or -1.5 ATR
Take Profit:
First target: +3R
Second target: next major level
Trailing: Mid EMA
For whom: Conservative swing traders, investors
Pros:
Very reliable signals
Minimum false entries
Large profit potential
Cons:
Rare signals (2-5 per month)
Requires patience
Strategy 4: "Adaptive Scalper"
Idea: Use only Delta Adaptive EMA for quick volatility reaction
Settings:
Fast: Delta Adaptive (Base 10, Sensitivity 3.0)
Mid: None
Slow: Delta Adaptive (Base 30, Sensitivity 2.0)
Base Multiplier: 3
Timeframe: M1, M5
Feature: Two different Delta EMAs with different settings
Entry rules:
Golden Cross between two Delta EMAs
Both Delta EMAs must be rising/falling
Enter on next bar
Stop:
10-15 pips or below Slow Delta EMA
Take Profit:
+1R to +2R
Or Death Cross
For whom: Scalpers on cryptocurrencies and forex
Pros:
Instant volatility adaptation
Many signals on volatile markets
Quick results
Cons:
Much noise on calm markets
Requires fast execution
High commissions may eat profits
Strategy 5: "Cyclical Trader"
Idea: Use Pi and Lambda for trading cyclical markets
Settings:
Fast: Pi Circular (1Pi)
Mid: Lambda Wave (Base 30, Amplitude 0.5, Frequency 50)
Slow: Pi Circular (3Pi)
Base Multiplier: 10
Timeframe: H1, H4
Entry rules:
STRONG signal active
Lambda Wave EMA synchronized with trend
Enter on bounce from Lambda Wave
For whom: Traders of cyclical assets (some altcoins, commodities)
Pros:
Catches cyclical movements
Lambda Wave provides additional entry points
Cons:
More complex to configure
Not for all markets
Lambda Wave may give false signals
Strategy 6: "Multi-Timeframe Confirmation"
Idea: Use multiple timeframes for confirmation
Scheme:
Higher TF (D1): Determine trend direction (STRONG signal)
Middle TF (H4): Wait for STRONG signal in same direction
Lower TF (M15): Look for entry point (Golden Cross or bounce from Fast EMA)
Settings for all TFs:
Fast: Phi Golden (Phi³)
Mid: e Natural (e²)
Slow: Pi Circular (2Pi)
Base Multiplier: 10
Rules:
All 3 TFs must show one trend
Entry on lower TF
Stop by lower TF
Target by higher TF
For whom: Serious traders and investors
Pros:
Maximum reliability
Large profit targets
Minimum false signals
Cons:
Rare setups
Requires analysis of multiple charts
Experience needed
Practical Tips
DOs
Use STRONG signals as primary - they're most reliable
Let signals develop - don't exit on first pullback
Use trailing stop - follow Fast EMA
Combine with levels - S/R, Fibonacci, volumes
Test on demo before real
Adjust Base Multiplier for your timeframe
Enable visual effects - they help see the picture
Use Info Table - quick situation assessment
Watch Pulsing Bar - instant state indicator
Trust auto-sorting of Fast/Mid/Slow
DON'Ts
Don't trade against STRONG signal - trend is your friend
Don't ignore Mid EMA - it adds reliability
Don't use too small Base Multiplier on higher TFs
Don't enter on Golden Cross in range - check for trend
Don't change settings during open position
Don't forget risk management - 1-2% per trade
Don't trade all signals in row - choose best ones
Don't use indicator in isolation - combine with Price Action
Don't set too tight stops - let trade breathe
Don't over-optimize - simplicity = reliability
Optimal Settings by Asset
US Stocks (SPY, AAPL, TSLA)
Recommendation:
Fast: Phi Golden (Phi³)
Mid: e Natural (e²)
Slow: Pi Circular (2Pi)
Base: 10-15
Timeframe: H4, D1
Features:
Use on daily for swing
STRONG signals very reliable
Works well on trending stocks
Forex (EUR/USD, GBP/USD)
Recommendation:
Fast: Delta Adaptive (Base 15, Sens 2.0)
Mid: Phi Golden (Phi²)
Slow: Pi Circular (2Pi)
Base: 8-12
Timeframe: M15, H1, H4
Features:
Delta Adaptive works excellently on news
Many signals on M15-H1
Consider spreads
Cryptocurrencies (BTC, ETH, altcoins)
Recommendation:
Fast: Delta Adaptive (Base 10, Sens 3.0)
Mid: Pi Circular (2Pi)
Slow: e Natural (e²)
Base: 5-10
Timeframe: M5, M15, H1
Features:
High volatility - adaptation needed
STRONG signals can last days
Be careful with scalping on M1-M5
Commodities (Gold, Oil)
Recommendation:
Fast: Pi Circular (1Pi)
Mid: Phi Golden (Phi³)
Slow: Pi Circular (3Pi)
Base: 12-18
Timeframe: H4, D1
Features:
Pi works excellently on cyclical commodities
Gold responds especially well to Phi
Oil volatile - use wide stops
Indices (S&P500, Nasdaq, DAX)
Recommendation:
Fast: Phi Golden (Phi³)
Mid: e Natural (e²)
Slow: Pi Circular (2Pi)
Base: 15-20
Timeframe: H4, D1, W1
Features:
Very trending instruments
STRONG signals last weeks
Good for position trading
Alerts
The indicator supports 6 alert types:
1. Golden Cross
Message: "Hellenic Matrix: GOLDEN CROSS - Fast EMA crossed above Slow EMA - Bullish trend starting!"
When: Fast EMA crosses Slow EMA from below
2. Death Cross
Message: "Hellenic Matrix: DEATH CROSS - Fast EMA crossed below Slow EMA - Bearish trend starting!"
When: Fast EMA crosses Slow EMA from above
3. STRONG BULLISH
Message: "Hellenic Matrix: STRONG BULLISH SIGNAL - All EMAs aligned for powerful uptrend!"
When: All conditions for STRONG BUY met (first bar)
4. STRONG BEARISH
Message: "Hellenic Matrix: STRONG BEARISH SIGNAL - All EMAs aligned for powerful downtrend!"
When: All conditions for STRONG SELL met (first bar)
5. Bullish Ribbon
Message: "Hellenic Matrix: BULLISH RIBBON - EMAs aligned for uptrend"
When: EMAs aligned bullish + price above Fast EMA (less strict condition)
6. Bearish Ribbon
Message: "Hellenic Matrix: BEARISH RIBBON - EMAs aligned for downtrend"
When: EMAs aligned bearish + price below Fast EMA (less strict condition)
How to Set Up Alerts:
Open indicator on chart
Click on three dots next to indicator name
Select "Create Alert"
In "Condition" field select needed alert:
Golden Cross
Death Cross
STRONG BULLISH
STRONG BEARISH
Bullish Ribbon
Bearish Ribbon
Configure notification method:
Pop-up in browser
Email
SMS (in Premium accounts)
Push notifications in mobile app
Webhook (for automation)
Select frequency:
Once Per Bar Close (recommended) - once on bar close
Once Per Bar - during bar formation
Only Once - only first time
Click "Create"
Tip: Create separate alerts for different timeframes and instruments
FAQ
1. Why don't STRONG signals appear?
Possible reasons:
Incorrect Fast/Mid/Slow order
Solution: Indicator automatically sorts EMAs by periods, but ensure selected EMAs have different periods
Base Multiplier too large
Solution: Reduce Base to 5-10 on lower timeframes
Market in range
Solution: STRONG signals appear only in trends - this is normal
Too strict EMA settings
Solution: Try classic combination: Phi³ / Pi×2 / e² with Base=10
Mid EMA too close to Fast or Slow
Solution: Select Mid EMA with period between Fast and Slow
2. How often should STRONG signals appear?
Normal frequency:
M1-M5: 5-15 signals per day (very active markets)
M15-H1: 2-8 signals per day
H4: 3-10 signals per week
D1: 2-5 signals per month
W1: 2-6 signals per year
If too many signals - market very volatile or Base too small
If too few signals - market in range or Base too large
4. What are the best settings for beginners?
Universal "out of the box" settings:
Matrix Core:
Base Multiplier: 10
Source: close
Phi Golden: Enabled, Power = 3
Pi Circular: Enabled, Multiple = 2
e Natural: Enabled, Power = 2
Delta Adaptive: Enabled, Base = 20, Sensitivity = 2.0
Manual Selection:
Fast: Phi Golden
Mid: e Natural
Slow: Pi Circular
Visualization:
Gradient Clouds: ON
Neon Glow: ON (Medium)
Pulsing Bar: ON (Medium)
Signal Highlights: ON (Light Fill)
Table: ON (Top Right, Small)
Signals:
Golden/Death Cross: ON
STRONG Signals: ON
Stop Loss: OFF (while learning)
Timeframe for learning: H1 or H4
5. Can I use only one EMA?
No, minimum 2 EMAs (Fast and Slow) for signal generation.
Mid EMA is optional:
With Mid EMA = more reliable but rarer signals
Without Mid EMA = more signals but less strict filtering
Recommendation: Start with 3 EMAs (Fast/Mid/Slow), then experiment
6. Does the indicator work on cryptocurrencies?
Yes, works excellently! Especially good on:
Bitcoin (BTC)
Ethereum (ETH)
Major altcoins (SOL, BNB, XRP)
Recommended settings for crypto:
Fast: Delta Adaptive (Base 10-15, Sensitivity 2.5-3.0)
Mid: Pi Circular (2Pi)
Slow: e Natural (e²)
Base: 5-10
Timeframe: M15, H1, H4
Crypto market features:
High volatility → use Delta Adaptive
24/7 trading → set alerts
Sharp movements → wide stops
7. Can I trade only with this indicator?
Technically yes, but NOT recommended.
Best approach - combine with:
Price Action - support/resistance levels, candle patterns
Volume - movement strength confirmation
Fibonacci - retracement and extension levels
RSI/MACD - divergences and overbought/oversold
Fundamental analysis - news, company reports
Hellenic Matrix:
Excellently determines trend and its strength
Provides clear entry/exit points
Doesn't consider fundamentals
Doesn't see major levels
8. Why do Gradient Clouds change color?
Color depends on EMA order:
Phi-Pi Cloud:
Blue - Pi EMA above Phi EMA (bullish alignment)
Gold - Phi EMA above Pi EMA (bearish alignment)
Pi-e Cloud:
Green - e EMA above Pi EMA (bullish alignment)
Blue - Pi EMA above e EMA (bearish alignment)
Color change = EMA order change = possible trend change
9. What is Momentum % in the table?
Momentum % = percentage deviation of price from Fast EMA
Formula:
Momentum = ((Close - Fast EMA) / Fast EMA) × 100
Interpretation:
+0.5% to +2% - normal bullish momentum
+2% to +5% - strong bullish momentum
+5% and above - overheating (correction possible)
-0.5% to -2% - normal bearish momentum
-2% to -5% - strong bearish momentum
-5% and below - oversold (bounce possible)
Usage:
Monitor momentum during STRONG signals
Large momentum = don't enter (wait for pullback)
Small momentum = good entry point
10. How to configure for scalping?
Settings for scalping (M1-M5):
Base Multiplier: 3-5
Source: close or hlc3 (smoother)
Fast: Delta Adaptive (Base 8-12, Sensitivity 3.0)
Mid: None (for more signals)
Slow: Phi Golden (Phi²) or Pi Circular (1Pi)
Visualization:
- Gradient Clouds: ON (helps see strength)
- Neon Glow: OFF (doesn't clutter chart)
- Pulsing Bar: ON (quick assessment)
- Signal Highlights: ON
Signals:
- Golden/Death Cross: ON
- STRONG Signals: ON
- Stop Loss: ON (1.0-1.5 ATR, R:R 1.5-2.0)
Scalping rules:
Trade only STRONG signals
Enter on bounce from Fast EMA
Tight stops (10-20 pips)
Quick take profit (+1R to +2R)
Don't hold through news
11. How to configure for long-term investing?
Settings for investing (D1-W1):
Base Multiplier: 20-30
Source: close
Fast: Phi Golden (Phi³ or Phi⁴)
Mid: e Natural (e²)
Slow: Pi Circular (3Pi or 4Pi)
Visualization:
- Gradient Clouds: ON
- Neon Glow: ON (Medium)
- Everything else - to taste
Signals:
- Golden/Death Cross: ON
- STRONG Signals: ON
- Stop Loss: OFF (use percentage stop)
Investing rules:
Enter only on STRONG signals
Hold while STRONG active (weeks/months)
Stop below Slow EMA or -10%
Take profit: by company targets or +50-100%
Ignore short-term pullbacks
12. What if indicator slows down chart?
Indicator is optimized, but if it slows:
Disable unnecessary visual effects:
Neon Glow: OFF (saves 8 plots)
Gradient Clouds: ON but low quality
Lambda Wave EMA: OFF (if not using)
Reduce number of active EMAs:
Sigma Composite: OFF
Lambda Wave: OFF
Leave only Phi, Pi, e, Delta
Simplify settings:
Pulsing Bar: OFF
Greek Labels: OFF
Info Table: smaller size
13. Can I use on different timeframes simultaneously?
Yes! Multi-timeframe analysis is very powerful:
Classic scheme:
Higher TF (D1, W1) - determine global trend
Wait for STRONG signal
This is our trading direction
Middle TF (H4, H1) - look for confirmation
STRONG signal in same direction
Precise entry zone
Lower TF (M15, M5) - entry point
Golden Cross or bounce from Fast EMA
Precise stop loss
Example:
W1: STRONG BUY active (global uptrend)
H4: STRONG BUY appeared (confirmation)
M15: Wait for Golden Cross or bounce from Fast EMA → ENTRY
Advantages:
Maximum reliability
Clear timeframe hierarchy
Large targets
14. How does indicator work on news?
Delta Adaptive EMA adapts excellently to news:
Before news:
Low volatility → Delta EMA becomes fast → pulls to price
During news:
Sharp volatility spike → Delta EMA slows → filters noise
After news:
Volatility normalizes → Delta EMA returns to normal
Recommendations:
Don't trade at news release moment (spreads widen)
Wait for STRONG signal after news (2-5 bars)
Use Delta Adaptive as Fast EMA for quick reaction
Widen stops by 50-100% during important news
Advanced Techniques
Technique 1: "Divergences with EMA"
Idea: Look for discrepancies between price and Fast EMA
Bullish divergence:
Price makes lower low
Fast EMA makes higher low
= Possible reversal up
Bearish divergence:
Price makes higher high
Fast EMA makes lower high
= Possible reversal down
How to trade:
Find divergence
Wait for STRONG signal in divergence direction
Enter on confirmation
Technique 2: "EMA Tunnel"
Idea: Use space between Fast and Slow EMA as "tunnel"
Rules:
Wide tunnel - strong trend, hold position
Narrow tunnel - weak trend or consolidation, caution
Tunnel narrowing - trend weakening, prepare to exit
Tunnel widening - trend strengthening, can add
Visually: Gradient Clouds show this automatically!
Trading:
Enter on STRONG signal (tunnel starts widening)
Hold while tunnel wide
Exit when tunnel starts narrowing
Technique 3: "Wave Analysis with Lambda"
Idea: Lambda Wave EMA creates sinusoid matching market cycles
Setup:
Lambda Base Period: 30
Lambda Wave Amplitude: 0.5
Lambda Wave Frequency: 50 (adjusted to asset cycle)
How to find correct Frequency:
Look at historical cycles (distance between local highs)
Average distance = your Frequency
Example: if highs every 40-60 bars, set Frequency = 50
Trading:
Enter when Lambda Wave at bottom of sinusoid (growth potential)
Exit when Lambda Wave at top (fall potential)
Combine with STRONG signals
Technique 4: "Cluster Analysis"
Idea: When all EMAs gather in narrow cluster = powerful breakout soon
Cluster signs:
All EMAs (Phi, Pi, e, Delta) within 0.5-1% of each other
Gradient Clouds almost invisible
Price jumping around all EMAs
Trading:
Identify cluster (all EMAs close)
Determine breakout direction (where more volume, higher TFs direction)
Wait for breakout and STRONG signal
Enter on confirmation
Target = cluster size × 3-5
This is very powerful technique for big moves!
Technique 5: "Sigma as Dynamic Level"
Idea: Sigma Composite EMA = average of all EMAs = magnetic level
Usage:
Enable Sigma Composite (Weighted Average)
Sigma works as dynamic support/resistance
Price often returns to Sigma before trend continuation
Trading:
In trend: Enter on bounces from Sigma
In range: Fade moves from Sigma (trade return to Sigma)
On breakout: Sigma becomes support/resistance
Risk Management
Basic Rules
1. Position Size
Conservative: 1% of capital per trade
Moderate: 2% of capital per trade (recommended)
Aggressive: 3-5% (only for experienced)
Calculation formula:
Lot Size = (Capital × Risk%) / (Stop in pips × Pip value)
2. Risk/Reward Ratio
Minimum: 1:1.5
Standard: 1:2 (recommended)
Optimal: 1:3
Aggressive: 1:5+
3. Maximum Drawdown
Daily: -3% to -5%
Weekly: -7% to -10%
Monthly: -15% to -20%
Upon reaching limit → STOP trading until end of period
Position Management Strategies
1. Fixed Stop
Method:
Stop below/above Fast EMA or local extreme
DON'T move stop against position
Can move to breakeven
For whom: Beginners, conservative traders
2. Trailing by Fast EMA
Method:
Each day (or bar) move stop to Fast EMA level
Position closes when price breaks Fast EMA
Advantages:
Stay in trend as long as possible
Automatically exit on reversal
For whom: Trend followers, swing traders
3. Partial Exit
Method:
50% of position close at +2R
50% hold with trailing by Mid EMA or Slow EMA
Advantages:
Lock profit
Leave position for big move
Psychologically comfortable
For whom: Universal method (recommended)
4. Pyramiding
Method:
First entry on STRONG signal (50% of planned position)
Add 25% on pullback to Fast EMA
Add another 25% on pullback to Mid EMA
Overall stop below Slow EMA
Advantages:
Average entry price
Reduce risk
Increase profit in strong trends
Caution:
Works only in trends
In range leads to losses
For whom: Experienced traders
Trading Psychology
Correct Mindset
1. Indicator is a tool, not holy grail
Indicator shows probability, not guarantee
There will be losing trades - this is normal
Important is series statistics, not one trade
2. Trust the system
If STRONG signal appeared - enter
Don't search for "perfect" moment
Follow trading plan
3. Patience
STRONG signals don't appear every day
Better miss signal than enter against trend
Quality over quantity
4. Discipline
Always set stop loss
Don't move stop against position
Don't increase risk after losses
Beginner Mistakes
1. "I know better than indicator"
Indicator says STRONG BUY, but you think "too high, will wait for pullback"
Result: miss profitable move
Solution: Trust signals or don't use indicator
2. "Will reverse now for sure"
Trading against STRONG trend
Result: stops, stops, stops
Solution: Trend is your friend, trade with trend
3. "Will hold a bit more"
Don't exit when STRONG signal disappears
Greed eats profit
Solution: If signal gone - exit!
4. "I'll recover"
After losses double risk
Result: huge losses
Solution: Fixed % risk ALWAYS
5. "I don't like this signal"
Skip signals because of "feeling"
Result: inconsistency, no statistics
Solution: Trade ALL signals or clearly define filters
Trading Journal
What to Record
For each trade:
1. Entry/exit date and time
2. Instrument and timeframe
3. Signal type
Golden Cross
STRONG BUY
STRONG SELL
Death Cross
4. Indicator settings
Fast/Mid/Slow EMA
Base Multiplier
Other parameters
5. Chart screenshot
Entry moment
Exit moment
6. Trade parameters
Position size
Stop loss
Take Profit
R:R
7. Result
Profit/Loss in $
Profit/Loss in %
Profit/Loss in R
8. Notes
What was right
What was wrong
Emotions during trade
Lessons
Journal Analysis
Analyze weekly:
1. Win Rate
Win Rate = (Profitable trades / All trades) × 100%
Good: 50-60%
Excellent: 60-70%
Exceptional: 70%+
2. Average R
Average R = Sum of all R / Number of trades
Good: +0.5R
Excellent: +1.0R
Exceptional: +1.5R+
3. Profit Factor
Profit Factor = Total profit / Total losses
Good: 1.5+
Excellent: 2.0+
Exceptional: 3.0+
4. Maximum Drawdown
Track consecutive losses
If more than 5 in row - stop, check system
5. Best/Worst Trades
What was common in best trades? (do more)
What was common in worst trades? (avoid)
Pre-Trade Checklist
Technical Analysis
STRONG signal active (BUY or SELL)
All EMAs properly aligned (Fast > Mid > Slow or reverse)
Price on correct side of Fast EMA
Gradient Clouds confirm trend
Pulsing Bar shows STRONG state
Momentum % in normal range (not overheated)
No close strong levels against direction
Higher timeframe doesn't contradict
Risk Management
Position size calculated (1-2% risk)
Stop loss set
Take profit calculated (minimum 1:2)
R:R satisfactory
Daily/weekly risk limit not exceeded
No other open correlated positions
Fundamental Analysis
No important news in coming hours
Market session appropriate (liquidity)
No contradicting fundamentals
Understand why asset is moving
Psychology
Calm and thinking clearly
No emotions from previous trades
Ready to accept loss at stop
Following trading plan
Not revenging market for past losses
If at least one point is NO - think twice before entering!
Learning Roadmap
Week 1: Familiarization
Goals:
Install and configure indicator
Study all EMA types
Understand visualization
Tasks:
Add indicator to chart
Test all Fast/Mid/Slow settings
Play with Base Multiplier on different timeframes
Observe Gradient Clouds and Pulsing Bar
Study Info Table
Result: Comfort with indicator interface
Week 2: Signals
Goals:
Learn to recognize all signal types
Understand difference between Golden Cross and STRONG
Tasks:
Find 10 Golden Cross examples in history
Find 10 STRONG BUY examples in history
Compare their results (which worked better)
Set up alerts
Get 5 real alerts
Result: Understanding signals
Week 3: Demo Trading
Goals:
Start trading signals on demo account
Gather statistics
Tasks:
Open demo account
Trade ONLY STRONG signals
Keep journal (minimum 20 trades)
Don't change indicator settings
Strictly follow stop losses
Result: 20+ documented trades
Week 4: Analysis
Goals:
Analyze demo trading results
Optimize approach
Tasks:
Calculate win rate and average R
Find patterns in profitable trades
Find patterns in losing trades
Adjust approach (not indicator!)
Write trading plan
Result: Trading plan on 1 page
Month 2: Improvement
Goals:
Deepen understanding
Add additional techniques
Tasks:
Study multi-timeframe analysis
Test combinations with Price Action
Try advanced techniques (divergences, tunnels)
Continue demo trading (minimum 50 trades)
Achieve stable profitability on demo
Result: Win rate 55%+ and Profit Factor 1.5+
Month 3: Real Trading
Goals:
Transition to real account
Maintain discipline
Tasks:
Open small real account
Trade minimum lots
Strictly follow trading plan
DON'T increase risk
Focus on process, not profit
Result: Psychological comfort on real
Month 4+: Scaling
Goals:
Increase account
Become consistently profitable
Tasks:
With 60%+ win rate can increase risk to 2%
Upon doubling account can add capital
Continue keeping journal
Periodically review and improve strategy
Share experience with community
Result: Stable profitability month after month
Additional Resources
Recommended Reading
Technical Analysis:
"Technical Analysis of Financial Markets" - John Murphy
"Trading in the Zone" - Mark Douglas (psychology)
"Market Wizards" - Jack Schwager (trader interviews)
EMA and Moving Averages:
"Moving Averages 101" - Steve Burns
Articles on Investopedia about EMA
Risk Management:
"The Mathematics of Money Management" - Ralph Vince
"Trade Your Way to Financial Freedom" - Van K. Tharp
Trading Journals:
Edgewonk (paid, very powerful)
Tradervue (free version + premium)
Excel/Google Sheets (free)
Screeners:
TradingView Stock Screener
Finviz (stocks)
CoinMarketCap (crypto)
Conclusion
Hellenic EMA Matrix is a powerful tool based on universal mathematical constants of nature. The indicator combines:
Mathematical elegance - Phi, Pi, e instead of arbitrary numbers
Premium visualization - Neon Glow, Gradient Clouds, Pulsing Bar
Reliable signals - STRONG BUY/SELL work on all timeframes
Flexibility - 6 EMA types, adaptation to any trading style
Automation - auto-sorting EMAs, SL/TP calculation, alerts
Key Success Principles:
Simplicity - start with basic settings (Phi/Pi/e, Base=10)
Discipline - follow STRONG signals strictly
Patience - wait for quality setups
Risk Management - 1-2% per trade, ALWAYS
Journal - document every trade
Learning - constantly improve skills
Remember:
Indicator shows probability, not guarantee
Important is series statistics, not one trade
Psychology more important than technique
Quality more important than quantity
Process more important than result
Acknowledgments
Thank you for using Hellenic EMA Matrix - Alpha Omega Premium!
The indicator was created with love for mathematics, markets, and beautiful visualization.
Wishing you profitable trading!
Guide Version: 1.0
Date: 2025
Compatibility: Pine Script v6, TradingView
"In the simplicity of mathematical constants lies the complexity of market movements"
Auto Volume Spread Analysis (VSA) [TANHEF]Auto Volume Spread Analysis (visible volume and spread bars auto-scaled): Understanding Market Intentions through the Interpretation of Volume and Price Movements.
All the sections below contain the same descriptions as my other indicator "Volume Spread Analysis" with the exception of 'Auto Scaling'.
█ Auto-Scaling
This indicator auto-scales spread bars to match the visible volume bars, unlike the previous "Volume Spread Analysis " version which limited the number of visible spread bars to a fixed count. The auto-scaling feature allows for easier navigation through historical data, enabling both more historical spread bars to be viewed and more historical VSA pattern labels being displayed without requiring using the bar replay tool. Please note that this indicator’s auto-scaling feature recalculates the visible bars on the chart, causing the indicator to reload whenever the chart is moved.
Auto-scaled spread bars have two display options (set via 'Spread Bars Method' setting):
Lines: a bar lookback limit of 500 bars.
Polylines: no bar lookback limit as only plotted on visible bars on chart, which uses multiple polylines are used.
█ Simple Explanation:
The Volume Spread Analysis (VSA) indicator is a comprehensive tool that helps traders identify key market patterns and trends based on volume and spread data. This indicator highlights significant VSA patterns and provides insights into market behavior through color-coded volume/spread bars and identification of bars indicating strength, weakness, and neutrality between buyers and sellers. It also includes powerful volume and spread forecasting capabilities.
█ Laws of Volume Spread Analysis (VSA):
The origin of VSA begins with Richard Wyckoff, a pivotal figure in its development. Wyckoff made significant contributions to trading theory, including the formulation of three basic laws:
The Law of Supply and Demand: This fundamental law states that supply and demand balance each other over time. High demand and low supply lead to rising prices until demand falls to a level where supply can meet it. Conversely, low demand and high supply cause prices to fall until demand increases enough to absorb the excess supply.
The Law of Cause and Effect: This law assumes that a 'cause' will result in an 'effect' proportional to the 'cause'. A strong 'cause' will lead to a strong trend (effect), while a weak 'cause' will lead to a weak trend.
The Law of Effort vs. Result: This law asserts that the result should reflect the effort exerted. In trading terms, a large volume should result in a significant price move (spread). If the spread is small, the volume should also be small. Any deviation from this pattern is considered an anomaly.
█ Volume and Spread Analysis Bars:
Display: Volume and spread bars that consist of color coded levels, with the spread bars scaled to match the volume bars. A displayable table (Legend) of bar colors and levels can give context and clarify to each volume/spread bar.
Calculation: Levels are calculated using multipliers applied to moving averages to represent key levels based on historical data: low, normal, high, ultra. This method smooths out short-term fluctuations and focuses on longer-term trends.
Low Level: Indicates reduced volatility and market interest.
Normal Level: Reflects typical market activity and volatility.
High Level: Indicates increased activity and volatility.
Ultra Level: Identifies extreme levels of activity and volatility.
This illustrates the appearance of Volume and Spread bars when scaled and plotted together:
█ Forecasting Capabilities:
Display: Forecasted volume and spread levels using predictive models.
Calculation: Volume and Spread prediction calculations differ as volume is linear and spread is non-linear.
Volume Forecast (Linear Forecasting): Predicts future volume based on current volume rate and bar time till close.
Spread Forecast (Non-Linear Dynamic Forecasting): Predicts future spread using a dynamic multiplier, less near midpoint (consolidation) and more near low or high (trending), reflecting non-linear expansion.
Moving Averages: In forecasting, moving averages utilize forecasted levels instead of actual levels to ensure the correct level is forecasted (low, normal, high, or ultra).
The following compares forecasted volume with actual resulting volume, highlighting the power of early identifying increased volume through forecasted levels:
█ VSA Patterns:
Criteria and descriptions for each VSA pattern are available as tooltips beside them within the indicator’s settings. These tooltips provide explanations of potential developments based on the volume and spread data.
Signs of Strength (🟢): Patterns indicating strong buying pressure and potential market upturns.
Down Thrust
Selling Climax
No Effort ➤ Bearish Result
Bearish Effort ➤ No Result
Inverse Down Thrust
Failed Selling Climax
Bull Outside Reversal
End of Falling Market (Bag Holder)
Pseudo Down Thrust
No Supply
Signs of Weakness (🔴): Patterns indicating strong selling pressure and potential market downturns.
Up Thrust
Buying Climax
No Effort ➤ Bullish Result
Bullish Effort ➤ No Result
Inverse Up Thrust
Failed Buying Climax
Bear Outside Reversal
End of Rising Market (Bag Seller)
Pseudo Up Thrust
No Demand
Neutral Patterns (🔵): Patterns indicating market indecision and potential for continuation or reversal.
Quiet Doji
Balanced Doji
Strong Doji
Quiet Spinning Top
Balanced Spinning Top
Strong Spinning Top
Quiet High Wave
Balanced High Wave
Strong High Wave
Consolidation
Bar Patterns (🟡): Common candlestick patterns that offer insights into market sentiment. These are required in some VSA patterns and can also be displayed independently.
Bull Pin Bar
Bear Pin Bar
Doji
Spinning Top
High Wave
Consolidation
This demonstrates the acronym and descriptive options for displaying bar patterns, with the ability to hover over text to reveal the descriptive text along with what type of pattern:
█ Alerts:
VSA Pattern Alerts: Notifications for identified VSA patterns at bar close.
Volume and Spread Alerts: Alerts for confirmed and forecasted volume/spread levels (Low, High, Ultra).
Forecasted Volume and Spread Alerts: Alerts for forecasted volume/spread levels (High, Ultra) include a minimum percent time elapsed input to reduce false early signals by ensuring sufficient bar time has passed.
█ Inputs and Settings:
Indicator Bar Color: Select color schemes for bars (Normal, Detail, Levels).
Indicator Moving Average Color: Select schemes for bars (Fill, Lines, None).
Price Bar Colors: Options to color price bars based on VSA patterns and volume levels.
Legend: Display a table of bar colors and levels for context and clarity of volume/spread bars.
Forecast: Configure forecast display and prediction details for volume and spread.
Average Multipliers: Define multipliers for different levels (Low, High, Ultra) to refine the analysis.
Moving Average: Set volume and spread moving average settings.
VSA: Select the VSA patterns to be calculated and displayed (Strength, Weakness, Neutral).
Bar Patterns: Criteria for bar patterns used in VSA (Doji, Bull Pin Bar, Bear Pin Bar, Spinning Top, Consolidation, High Wave).
Colors: Set exact colors used for indicator bars, indicator moving averages, and price bars.
More Display Options: Specify how VSA pattern text is displayed (Acronym, Descriptive), positioning, and sizes.
Alerts: Configure alerts for VSA patterns, volume, and spread levels, including forecasted levels.
█ Usage:
The Volume Spread Analysis indicator is a helpful tool for leveraging volume spread analysis to make informed trading decisions. It offers comprehensive visual and textual cues on the chart, making it easier to identify market conditions, potential reversals, and continuations. Whether analyzing historical data or forecasting future trends, this indicator provides insights into the underlying factors driving market movements.
CandleAnalysisLibrary "CandleAnalysis"
A collection of frequently used candle analysis functions in my scripts.
isBullish(barsBack)
Checks if a specific bar is bullish.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar is bullish, otherwise returns false.
isBearish(barsBack)
Checks if a specific bar is bearish.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar is bearish, otherwise returns false.
isBE(barsBack)
Checks if a specific bar is break even.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar is break even, otherwise returns false.
getBodySize(barsBack, inPriceChg)
Calculates a specific candle's body size.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
inPriceChg (bool) : (bool) True to return the body size as a price change value. The default is false (in points).
Returns: The candle's body size in points.
getTopWickSize(barsBack, inPriceChg)
Calculates a specific candle's top wick size.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).
Returns: The candle's top wick size in points.
getBottomWickSize(barsBack, inPriceChg)
Calculates a specific candle's bottom wick size.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).
Returns: The candle's bottom wick size in points.
getBodyPercent(barsBack)
Calculates a specific candle's body size as a percentage of its entire size including its wicks.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: The candle's body size percentage.
isHammer(fib, bullish, barsBack)
Checks if a specific bar is a hammer candle based on a given fibonacci level.
Parameters:
fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.
bullish (bool) : (bool) True if the candle must to be green. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a hammer candle, otherwise returns false.
isShootingStar(fib, bearish, barsBack)
Checks if a specific bar is a shooting star candle based on a given fibonacci level.
Parameters:
fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.
bearish (bool) : (bool) True if the candle must to be red. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a shooting star candle, otherwise returns false.
isDoji(wickSize, bodySize, barsBack)
Checks if a specific bar is a doji candle based on a given wick and body size.
Parameters:
wickSize (float) : (float) The maximum top wick size compared to the bottom and vice versa. The default is 1.5.
bodySize (float) : (bool) The maximum body size as a percentage compared to the entire candle size. The default is 5.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a doji candle.
isBullishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)
Checks if a specific bar is a bullish engulfing candle.
Parameters:
gapTolerance (int)
rejectionWickSize (int) : (int) The maximum top wick size compared to the body as a percentage. The default is 10.
engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a bullish engulfing candle.
isBearishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)
Checks if a specific bar is a bearish engulfing candle.
Parameters:
gapTolerance (int)
rejectionWickSize (int) : (int) The maximum bottom wick size compared to the body as a percentage. The default is 10.
engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a bearish engulfing candle.
MarcosLibraryLibrary "MarcosLibrary"
A colection of frequently used functions in my scripts.
bullFibRet(priceLow, priceHigh, fibLevel)
Calculates a bullish fibonacci retracement value.
Parameters:
priceLow (float) : (float) The lowest price point.
priceHigh (float) : (float) The highest price point.
fibLevel (float) : (float) The fibonacci level to calculate.
Returns: The fibonacci value of the given retracement level.
bearFibRet(priceLow, priceHigh, fibLevel)
Calculates a bearish fibonacci retracement value.
Parameters:
priceLow (float) : (float) The lowest price point.
priceHigh (float) : (float) The highest price point.
fibLevel (float) : (float) The fibonacci level to calculate.
Returns: The fibonacci value of the given retracement level.
bullFibExt(priceLow, priceHigh, thirdPivot, fibLevel)
Calculates a bullish fibonacci extension value.
Parameters:
priceLow (float) : (float) The lowest price point.
priceHigh (float) : (float) The highest price point.
thirdPivot (float) : (float) The third price point.
fibLevel (float) : (float) The fibonacci level to calculate.
Returns: The fibonacci value of the given extension level.
bearFibExt(priceLow, priceHigh, thirdPivot, fibLevel)
Calculates a bearish fibonacci extension value.
Parameters:
priceLow (float) : (float) The lowest price point.
priceHigh (float) : (float) The highest price point.
thirdPivot (float) : (float) The third price point.
fibLevel (float) : (float) The fibonacci level to calculate.
Returns: The fibonacci value of the given extension level.
isBullish(barsBack)
Checks if a specific bar is bullish.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar is bullish, otherwise returns false.
isBearish(barsBack)
Checks if a specific bar is bearish.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar is bearish, otherwise returns false.
isBE(barsBack)
Checks if a specific bar is break even.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar is break even, otherwise returns false.
getBodySize(barsBack, inPriceChg)
Calculates a specific candle's body size.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
inPriceChg (bool) : (bool) True to return the body size as a price change value. The default is false (in points).
Returns: The candle's body size in points.
getTopWickSize(barsBack, inPriceChg)
Calculates a specific candle's top wick size.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).
Returns: The candle's top wick size in points.
getBottomWickSize(barsBack, inPriceChg)
Calculates a specific candle's bottom wick size.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
inPriceChg (bool) : (bool) True to return the wick size as a price change value. The default is false (in points).
Returns: The candle's bottom wick size in points.
getBodyPercent(barsBack)
Calculates a specific candle's body size as a percentage of its entire size including its wicks.
Parameters:
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: The candle's body size percentage.
isHammer(fib, bullish, barsBack)
Checks if a specific bar is a hammer candle based on a given fibonacci level.
Parameters:
fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.
bullish (bool) : (bool) True if the candle must to be green. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a hammer candle, otherwise returns false.
isShootingStar(fib, bearish, barsBack)
Checks if a specific bar is a shooting star candle based on a given fibonacci level.
Parameters:
fib (float) : (float) The fibonacci level to base candle's body on. The default is 0.382.
bearish (bool) : (bool) True if the candle must to be red. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a shooting star candle, otherwise returns false.
isDoji(wickSize, bodySize, barsBack)
Checks if a specific bar is a doji candle based on a given wick and body size.
Parameters:
wickSize (float) : (float) The maximum top wick size compared to the bottom and vice versa. The default is 1.5.
bodySize (float) : (bool) The maximum body size as a percentage compared to the entire candle size. The default is 5.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a doji candle.
isBullishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)
Checks if a specific bar is a bullish engulfing candle.
Parameters:
gapTolerance (int)
rejectionWickSize (int) : (int) The maximum top wick size compared to the body as a percentage. The default is 10.
engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a bullish engulfing candle.
isBearishEC(gapTolerance, rejectionWickSize, engulfWick, barsBack)
Checks if a specific bar is a bearish engulfing candle.
Parameters:
gapTolerance (int)
rejectionWickSize (int) : (int) The maximum bottom wick size compared to the body as a percentage. The default is 10.
engulfWick (bool) : (bool) True if the engulfed candle's wick requires to be engulfed as well. The default is false.
barsBack (int) : (int) The number of bars to look back. The default is 0 (current bar).
Returns: True if the bar matches the requirements of a bearish engulfing candle.
CNTLibraryLibrary "CNTLibrary"
Custom Functions To Help Code In Pinescript V5
Coded By Christian Nataliano
First Coded In 10/06/2023
Last Edited In 22/06/2023
Huge Shout Out To © ZenAndTheArtOfTrading and his ZenLibrary V5, Some Of The Custom Functions Were Heavily Inspired By Matt's Work & His Pine Script Mastery Course
Another Shout Out To The TradingView's Team Library ta V5
//====================================================================================================================================================
// Custom Indicator Functions
//====================================================================================================================================================
GetKAMA(KAMA_lenght, Fast_KAMA, Slow_KAMA)
Calculates An Adaptive Moving Average Based On Perry J Kaufman's Calculations
Parameters:
KAMA_lenght (int) : Is The KAMA Lenght
Fast_KAMA (int) : Is The KAMA's Fastes Moving Average
Slow_KAMA (int) : Is The KAMA's Slowest Moving Average
Returns: Float Of The KAMA's Current Calculations
GetMovingAverage(Source, Lenght, Type)
Get Custom Moving Averages Values
Parameters:
Source (float) : Of The Moving Average, Defval = close
Lenght (simple int) : Of The Moving Average, Defval = 50
Type (string) : Of The Moving Average, Defval = Exponential Moving Average
Returns: The Moving Average Calculation Based On Its Given Source, Lenght & Calculation Type (Please Call Function On Global Scope)
GetDecimals()
Calculates how many decimals are on the quote price of the current market © ZenAndTheArtOfTrading
Returns: The current decimal places on the market quote price
Truncate(number, decimalPlaces)
Truncates (cuts) excess decimal places © ZenAndTheArtOfTrading
Parameters:
number (float)
decimalPlaces (simple float)
Returns: The given number truncated to the given decimalPlaces
ToWhole(number)
Converts pips into whole numbers © ZenAndTheArtOfTrading
Parameters:
number (float)
Returns: The converted number
ToPips(number)
Converts whole numbers back into pips © ZenAndTheArtOfTrading
Parameters:
number (float)
Returns: The converted number
GetPctChange(value1, value2, lookback)
Gets the percentage change between 2 float values over a given lookback period © ZenAndTheArtOfTrading
Parameters:
value1 (float)
value2 (float)
lookback (int)
BarsAboveMA(lookback, ma)
Counts how many candles are above the MA © ZenAndTheArtOfTrading
Parameters:
lookback (int)
ma (float)
Returns: The bar count of how many recent bars are above the MA
BarsBelowMA(lookback, ma)
Counts how many candles are below the MA © ZenAndTheArtOfTrading
Parameters:
lookback (int)
ma (float)
Returns: The bar count of how many recent bars are below the EMA
BarsCrossedMA(lookback, ma)
Counts how many times the EMA was crossed recently © ZenAndTheArtOfTrading
Parameters:
lookback (int)
ma (float)
Returns: The bar count of how many times price recently crossed the EMA
GetPullbackBarCount(lookback, direction)
Counts how many green & red bars have printed recently (ie. pullback count) © ZenAndTheArtOfTrading
Parameters:
lookback (int)
direction (int)
Returns: The bar count of how many candles have retraced over the given lookback & direction
GetSwingHigh(Lookback, SwingType)
Check If Price Has Made A Recent Swing High
Parameters:
Lookback (int) : Is For The Swing High Lookback Period, Defval = 7
SwingType (int) : Is For The Swing High Type Of Identification, Defval = 1
Returns: A Bool - True If Price Has Made A Recent Swing High
GetSwingLow(Lookback, SwingType)
Check If Price Has Made A Recent Swing Low
Parameters:
Lookback (int) : Is For The Swing Low Lookback Period, Defval = 7
SwingType (int) : Is For The Swing Low Type Of Identification, Defval = 1
Returns: A Bool - True If Price Has Made A Recent Swing Low
//====================================================================================================================================================
// Custom Risk Management Functions
//====================================================================================================================================================
CalculateStopLossLevel(OrderType, Entry, StopLoss)
Calculate StopLoss Level
Parameters:
OrderType (int) : Is To Determine A Long / Short Position, Defval = 1
Entry (float) : Is The Entry Level Of The Order, Defval = na
StopLoss (float) : Is The Custom StopLoss Distance, Defval = 2x ATR Below Close
Returns: Float - The StopLoss Level In Actual Price As A
CalculateStopLossDistance(OrderType, Entry, StopLoss)
Calculate StopLoss Distance In Pips
Parameters:
OrderType (int) : Is To Determine A Long / Short Position, Defval = 1
Entry (float) : Is The Entry Level Of The Order, NEED TO INPUT PARAM
StopLoss (float) : Level Based On Previous Calculation, NEED TO INPUT PARAM
Returns: Float - The StopLoss Value In Pips
CalculateTakeProfitLevel(OrderType, Entry, StopLossDistance, RiskReward)
Calculate TakeProfit Level
Parameters:
OrderType (int) : Is To Determine A Long / Short Position, Defval = 1
Entry (float) : Is The Entry Level Of The Order, Defval = na
StopLossDistance (float)
RiskReward (float)
Returns: Float - The TakeProfit Level In Actual Price
CalculateTakeProfitDistance(OrderType, Entry, TakeProfit)
Get TakeProfit Distance In Pips
Parameters:
OrderType (int) : Is To Determine A Long / Short Position, Defval = 1
Entry (float) : Is The Entry Level Of The Order, NEED TO INPUT PARAM
TakeProfit (float) : Level Based On Previous Calculation, NEED TO INPUT PARAM
Returns: Float - The TakeProfit Value In Pips
CalculateConversionCurrency(AccountCurrency, SymbolCurrency, BaseCurrency)
Get The Conversion Currecny Between Current Account Currency & Current Pair's Quoted Currency (FOR FOREX ONLY)
Parameters:
AccountCurrency (simple string) : Is For The Account Currency Used
SymbolCurrency (simple string) : Is For The Current Symbol Currency (Front Symbol)
BaseCurrency (simple string) : Is For The Current Symbol Base Currency (Back Symbol)
Returns: Tuple Of A Bollean (Convert The Currency ?) And A String (Converted Currency)
CalculateConversionRate(ConvertCurrency, ConversionRate)
Get The Conversion Rate Between Current Account Currency & Current Pair's Quoted Currency (FOR FOREX ONLY)
Parameters:
ConvertCurrency (bool) : Is To Check If The Current Symbol Needs To Be Converted Or Not
ConversionRate (float) : Is The Quoted Price Of The Conversion Currency (Input The request.security Function Here)
Returns: Float Price Of Conversion Rate (If In The Same Currency Than Return Value Will Be 1.0)
LotSize(LotSizeSimple, Balance, Risk, SLDistance, ConversionRate)
Get Current Lot Size
Parameters:
LotSizeSimple (bool) : Is To Toggle Lot Sizing Calculation (Simple Is Good Enough For Stocks & Crypto, Whilst Complex Is For Forex)
Balance (float) : Is For The Current Account Balance To Calculate The Lot Sizing Based Off
Risk (float) : Is For The Current Risk Per Trade To Calculate The Lot Sizing Based Off
SLDistance (float) : Is The Current Position StopLoss Distance From Its Entry Price
ConversionRate (float) : Is The Currency Conversion Rate (Used For Complex Lot Sizing Only)
Returns: Float - Position Size In Units
ToLots(Units)
Converts Units To Lots
Parameters:
Units (float) : Is For How Many Units Need To Be Converted Into Lots (Minimun 1000 Units)
Returns: Float - Position Size In Lots
ToUnits(Lots)
Converts Lots To Units
Parameters:
Lots (float) : Is For How Many Lots Need To Be Converted Into Units (Minimun 0.01 Units)
Returns: Int - Position Size In Units
ToLotsInUnits(Units)
Converts Units To Lots Than Back To Units
Parameters:
Units (float) : Is For How Many Units Need To Be Converted Into Lots (Minimun 1000 Units)
Returns: Float - Position Size In Lots That Were Rounded To Units
ATRTrail(OrderType, SourceType, ATRPeriod, ATRMultiplyer, SwingLookback)
Calculate ATR Trailing Stop
Parameters:
OrderType (int) : Is To Determine A Long / Short Position, Defval = 1
SourceType (int) : Is To Determine Where To Calculate The ATR Trailing From, Defval = close
ATRPeriod (simple int) : Is To Change Its ATR Period, Defval = 20
ATRMultiplyer (float) : Is To Change Its ATR Trailing Distance, Defval = 1
SwingLookback (int) : Is To Change Its Swing HiLo Lookback (Only From Source Type 5), Defval = 7
Returns: Float - Number Of The Current ATR Trailing
DangerZone(WinRate, AvgRRR, Filter)
Calculate Danger Zone Of A Given Strategy
Parameters:
WinRate (float) : Is The Strategy WinRate
AvgRRR (float) : Is The Strategy Avg RRR
Filter (float) : Is The Minimum Profit It Needs To Be Out Of BE Zone, Defval = 3
Returns: Int - Value, 1 If Out Of Danger Zone, 0 If BE, -1 If In Danger Zone
IsQuestionableTrades(TradeTP, TradeSL)
Checks For Questionable Trades (Which Are Trades That Its TP & SL Level Got Hit At The Same Candle)
Parameters:
TradeTP (float) : Is The Trade In Question Take Profit Level
TradeSL (float) : Is The Trade In Question Stop Loss Level
Returns: Bool - True If The Last Trade Was A "Questionable Trade"
//====================================================================================================================================================
// Custom Strategy Functions
//====================================================================================================================================================
OpenLong(EntryID, LotSize, LimitPrice, StopPrice, Comment, CommentValue)
Open A Long Order Based On The Given Params
Parameters:
EntryID (string) : Is The Trade Entry ID, Defval = "Long"
LotSize (float) : Is The Lot Size Of The Trade, Defval = 1
LimitPrice (float) : Is The Limit Order Price To Set The Order At, Defval = Na / Market Order Execution
StopPrice (float) : Is The Stop Order Price To Set The Order At, Defval = Na / Market Order Execution
Comment (string) : Is The Order Comment, Defval = Long Entry Order
CommentValue (string) : Is For Custom Values In The Order Comment, Defval = Na
Returns: Void
OpenShort(EntryID, LotSize, LimitPrice, StopPrice, Comment, CommentValue)
Open A Short Order Based On The Given Params
Parameters:
EntryID (string) : Is The Trade Entry ID, Defval = "Short"
LotSize (float) : Is The Lot Size Of The Trade, Defval = 1
LimitPrice (float) : Is The Limit Order Price To Set The Order At, Defval = Na / Market Order Execution
StopPrice (float) : Is The Stop Order Price To Set The Order At, Defval = Na / Market Order Execution
Comment (string) : Is The Order Comment, Defval = Short Entry Order
CommentValue (string) : Is For Custom Values In The Order Comment, Defval = Na
Returns: Void
TP_SLExit(FromID, TPLevel, SLLevel, PercentageClose, Comment, CommentValue)
Exits Based On Predetermined TP & SL Levels
Parameters:
FromID (string) : Is The Trade ID That The TP & SL Levels Be Palced
TPLevel (float) : Is The Take Profit Level
SLLevel (float) : Is The StopLoss Level
PercentageClose (float) : Is The Amount To Close The Order At (In Percentage) Defval = 100
Comment (string) : Is The Order Comment, Defval = Exit Order
CommentValue (string) : Is For Custom Values In The Order Comment, Defval = Na
Returns: Void
CloseLong(ExitID, PercentageClose, Comment, CommentValue, Instant)
Exits A Long Order Based On A Specified Condition
Parameters:
ExitID (string) : Is The Trade ID That Will Be Closed, Defval = "Long"
PercentageClose (float) : Is The Amount To Close The Order At (In Percentage) Defval = 100
Comment (string) : Is The Order Comment, Defval = Exit Order
CommentValue (string) : Is For Custom Values In The Order Comment, Defval = Na
Instant (bool) : Is For Exit Execution Type, Defval = false
Returns: Void
CloseShort(ExitID, PercentageClose, Comment, CommentValue, Instant)
Exits A Short Order Based On A Specified Condition
Parameters:
ExitID (string) : Is The Trade ID That Will Be Closed, Defval = "Short"
PercentageClose (float) : Is The Amount To Close The Order At (In Percentage) Defval = 100
Comment (string) : Is The Order Comment, Defval = Exit Order
CommentValue (string) : Is For Custom Values In The Order Comment, Defval = Na
Instant (bool) : Is For Exit Execution Type, Defval = false
Returns: Void
BrokerCheck(Broker)
Checks Traded Broker With Current Loaded Chart Broker
Parameters:
Broker (string) : Is The Current Broker That Is Traded
Returns: Bool - True If Current Traded Broker Is Same As Loaded Chart Broker
OpenPC(LicenseID, OrderType, UseLimit, LimitPrice, SymbolPrefix, Symbol, SymbolSuffix, Risk, SL, TP, OrderComment, Spread)
Compiles Given Parameters Into An Alert String Format To Open Trades Using Pine Connector
Parameters:
LicenseID (string) : Is The Users PineConnector LicenseID
OrderType (int) : Is The Desired OrderType To Open
UseLimit (bool) : Is If We Want To Enter The Position At Exactly The Previous Closing Price
LimitPrice (float) : Is The Limit Price Of The Trade (Only For Pending Orders)
SymbolPrefix (string) : Is The Current Symbol Prefix (If Any)
Symbol (string) : Is The Traded Symbol
SymbolSuffix (string) : Is The Current Symbol Suffix (If Any)
Risk (float) : Is The Trade Risk Per Trade / Fixed Lot Sizing
SL (float) : Is The Trade SL In Price / In Pips
TP (float) : Is The Trade TP In Price / In Pips
OrderComment (string) : Is The Executed Trade Comment
Spread (float) : is The Maximum Spread For Execution
Returns: String - Pine Connector Order Syntax Alert Message
ClosePC(LicenseID, OrderType, SymbolPrefix, Symbol, SymbolSuffix)
Compiles Given Parameters Into An Alert String Format To Close Trades Using Pine Connector
Parameters:
LicenseID (string) : Is The Users PineConnector LicenseID
OrderType (int) : Is The Desired OrderType To Close
SymbolPrefix (string) : Is The Current Symbol Prefix (If Any)
Symbol (string) : Is The Traded Symbol
SymbolSuffix (string) : Is The Current Symbol Suffix (If Any)
Returns: String - Pine Connector Order Syntax Alert Message
//====================================================================================================================================================
// Custom Backtesting Calculation Functions
//====================================================================================================================================================
CalculatePNL(EntryPrice, ExitPrice, LotSize, ConversionRate)
Calculates Trade PNL Based On Entry, Eixt & Lot Size
Parameters:
EntryPrice (float) : Is The Trade Entry
ExitPrice (float) : Is The Trade Exit
LotSize (float) : Is The Trade Sizing
ConversionRate (float) : Is The Currency Conversion Rate (Used For Complex Lot Sizing Only)
Returns: Float - The Current Trade PNL
UpdateBalance(PrevBalance, PNL)
Updates The Previous Ginve Balance To The Next PNL
Parameters:
PrevBalance (float) : Is The Previous Balance To Be Updated
PNL (float) : Is The Current Trade PNL To Be Added
Returns: Float - The Current Updated PNL
CalculateSlpComm(PNL, MaxRate)
Calculates Random Slippage & Commisions Fees Based On The Parameters
Parameters:
PNL (float) : Is The Current Trade PNL
MaxRate (float) : Is The Upper Limit (In Percentage) Of The Randomized Fee
Returns: Float - A Percentage Fee Of The Current Trade PNL
UpdateDD(MaxBalance, Balance)
Calculates & Updates The DD Based On Its Given Parameters
Parameters:
MaxBalance (float) : Is The Maximum Balance Ever Recorded
Balance (float) : Is The Current Account Balance
Returns: Float - The Current Strategy DD
CalculateWR(TotalTrades, LongID, ShortID)
Calculate The Total, Long & Short Trades Win Rate
Parameters:
TotalTrades (int) : Are The Current Total Trades That The Strategy Has Taken
LongID (string) : Is The Order ID Of The Long Trades Of The Strategy
ShortID (string) : Is The Order ID Of The Short Trades Of The Strategy
Returns: Tuple Of Long WR%, Short WR%, Total WR%, Total Winning Trades, Total Losing Trades, Total Long Trades & Total Short Trades
CalculateAvgRRR(WinTrades, LossTrades)
Calculates The Overall Strategy Avg Risk Reward Ratio
Parameters:
WinTrades (int) : Are The Strategy Winning Trades
LossTrades (int) : Are The Strategy Losing Trades
Returns: Float - The Average RRR Values
CAGR(StartTime, StartPrice, EndTime, EndPrice)
Calculates The CAGR Over The Given Time Period © TradingView
Parameters:
StartTime (int) : Is The Starting Time Of The Calculation
StartPrice (float) : Is The Starting Price Of The Calculation
EndTime (int) : Is The Ending Time Of The Calculation
EndPrice (float) : Is The Ending Price Of The Calculation
Returns: Float - The CAGR Values
//====================================================================================================================================================
// Custom Plot Functions
//====================================================================================================================================================
EditLabels(LabelID, X1, Y1, Text, Color, TextColor, EditCondition, DeleteCondition)
Edit / Delete Labels
Parameters:
LabelID (label) : Is The ID Of The Selected Label
X1 (int) : Is The X1 Coordinate IN BARINDEX Xloc
Y1 (float) : Is The Y1 Coordinate IN PRICE Yloc
Text (string) : Is The Text Than Wants To Be Written In The Label
Color (color) : Is The Color Value Change Of The Label Text
TextColor (color)
EditCondition (int) : Is The Edit Condition of The Line (Setting Location / Color)
DeleteCondition (bool) : Is The Delete Condition Of The Line If Ture Deletes The Prev Itteration Of The Line
Returns: Void
EditLine(LineID, X1, Y1, X2, Y2, Color, EditCondition, DeleteCondition)
Edit / Delete Lines
Parameters:
LineID (line) : Is The ID Of The Selected Line
X1 (int) : Is The X1 Coordinate IN BARINDEX Xloc
Y1 (float) : Is The Y1 Coordinate IN PRICE Yloc
X2 (int) : Is The X2 Coordinate IN BARINDEX Xloc
Y2 (float) : Is The Y2 Coordinate IN PRICE Yloc
Color (color) : Is The Color Value Change Of The Line
EditCondition (int) : Is The Edit Condition of The Line (Setting Location / Color)
DeleteCondition (bool) : Is The Delete Condition Of The Line If Ture Deletes The Prev Itteration Of The Line
Returns: Void
//====================================================================================================================================================
// Custom Display Functions (Using Tables)
//====================================================================================================================================================
FillTable(TableID, Column, Row, Title, Value, BgColor, TextColor, ToolTip)
Filling The Selected Table With The Inputed Information
Parameters:
TableID (table) : Is The Table ID That Wants To Be Edited
Column (int) : Is The Current Column Of The Table That Wants To Be Edited
Row (int) : Is The Current Row Of The Table That Wants To Be Edited
Title (string) : Is The String Title Of The Current Cell Table
Value (string) : Is The String Value Of The Current Cell Table
BgColor (color) : Is The Selected Color For The Current Table
TextColor (color) : Is The Selected Color For The Current Table
ToolTip (string) : Is The ToolTip Of The Current Cell In The Table
Returns: Void
DisplayBTResults(TableID, BgColor, TextColor, StartingBalance, Balance, DollarReturn, TotalPips, MaxDD)
Filling The Selected Table With The Inputed Information
Parameters:
TableID (table) : Is The Table ID That Wants To Be Edited
BgColor (color) : Is The Selected Color For The Current Table
TextColor (color) : Is The Selected Color For The Current Table
StartingBalance (float) : Is The Account Starting Balance
Balance (float)
DollarReturn (float) : Is The Account Dollar Reture
TotalPips (float) : Is The Total Pips Gained / loss
MaxDD (float) : Is The Maximum Drawdown Over The Backtesting Period
Returns: Void
DisplayBTResultsV2(TableID, BgColor, TextColor, TotalWR, QTCount, LongWR, ShortWR, InitialCapital, CumProfit, CumFee, AvgRRR, MaxDD, CAGR, MeanDD)
Filling The Selected Table With The Inputed Information
Parameters:
TableID (table) : Is The Table ID That Wants To Be Edited
BgColor (color) : Is The Selected Color For The Current Table
TextColor (color) : Is The Selected Color For The Current Table
TotalWR (float) : Is The Strategy Total WR In %
QTCount (int) : Is The Strategy Questionable Trades Count
LongWR (float) : Is The Strategy Total WR In %
ShortWR (float) : Is The Strategy Total WR In %
InitialCapital (float) : Is The Strategy Initial Starting Capital
CumProfit (float) : Is The Strategy Ending Cumulative Profit
CumFee (float) : Is The Strategy Ending Cumulative Fee (Based On Randomized Fee Assumptions)
AvgRRR (float) : Is The Strategy Average Risk Reward Ratio
MaxDD (float) : Is The Strategy Maximum DrawDown In Its Backtesting Period
CAGR (float) : Is The Strategy Compounded Average GRowth In %
MeanDD (float) : Is The Strategy Mean / Average Drawdown In The Backtesting Period
Returns: Void
//====================================================================================================================================================
// Custom Pattern Detection Functions
//====================================================================================================================================================
BullFib(priceLow, priceHigh, fibRatio)
Calculates A Bullish Fibonacci Value (From Swing Low To High) © ZenAndTheArtOfTrading
Parameters:
priceLow (float)
priceHigh (float)
fibRatio (float)
Returns: The Fibonacci Value Of The Given Ratio Between The Two Price Points
BearFib(priceLow, priceHigh, fibRatio)
Calculates A Bearish Fibonacci Value (From Swing High To Low) © ZenAndTheArtOfTrading
Parameters:
priceLow (float)
priceHigh (float)
fibRatio (float)
Returns: The Fibonacci Value Of The Given Ratio Between The Two Price Points
GetBodySize()
Gets The Current Candle Body Size IN POINTS © ZenAndTheArtOfTrading
Returns: The Current Candle Body Size IN POINTS
GetTopWickSize()
Gets The Current Candle Top Wick Size IN POINTS © ZenAndTheArtOfTrading
Returns: The Current Candle Top Wick Size IN POINTS
GetBottomWickSize()
Gets The Current Candle Bottom Wick Size IN POINTS © ZenAndTheArtOfTrading
Returns: The Current Candle Bottom Wick Size IN POINTS
GetBodyPercent()
Gets The Current Candle Body Size As A Percentage Of Its Entire Size Including Its Wicks © ZenAndTheArtOfTrading
Returns: The Current Candle Body Size IN PERCENTAGE
GetTopWickPercent()
Gets The Current Top Wick Size As A Percentage Of Its Entire Body Size
Returns: Float - The Current Candle Top Wick Size IN PERCENTAGE
GetBottomWickPercent()
Gets The Current Bottom Wick Size As A Percentage Of Its Entire Bodu Size
Returns: Float - The Current Candle Bottom Size IN PERCENTAGE
BullishEC(Allowance, RejectionWickSize, EngulfWick, NearSwings, SwingLookBack)
Checks If The Current Bar Is A Bullish Engulfing Candle
Parameters:
Allowance (int) : To Give Flexibility Of Engulfing Pattern Detection In Markets That Have Micro Gaps, Defval = 0
RejectionWickSize (float) : To Filter Out long (Upper And Lower) Wick From The Bullsih Engulfing Pattern, Defval = na
EngulfWick (bool) : To Specify If We Want The Pattern To Also Engulf Its Upper & Lower Previous Wicks, Defval = false
NearSwings (bool) : To Specify If We Want The Pattern To Be Near A Recent Swing Low, Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing Low, Defval = 10
Returns: Bool - True If The Current Bar Matches The Requirements of a Bullish Engulfing Candle
BearishEC(Allowance, RejectionWickSize, EngulfWick, NearSwings, SwingLookBack)
Checks If The Current Bar Is A Bearish Engulfing Candle
Parameters:
Allowance (int) : To Give Flexibility Of Engulfing Pattern Detection In Markets That Have Micro Gaps, Defval = 0
RejectionWickSize (float) : To Filter Out long (Upper And Lower) Wick From The Bearish Engulfing Pattern, Defval = na
EngulfWick (bool) : To Specify If We Want The Pattern To Also Engulf Its Upper & Lower Previous Wicks, Defval = false
NearSwings (bool) : To Specify If We Want The Pattern To Be Near A Recent Swing High, Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing High, Defval = 10
Returns: Bool - True If The Current Bar Matches The Requirements of a Bearish Engulfing Candle
Hammer(Fib, ColorMatch, NearSwings, SwingLookBack, ATRFilterCheck, ATRPeriod)
Checks If The Current Bar Is A Hammer Candle
Parameters:
Fib (float) : To Specify Which Fibonacci Ratio To Use When Determining The Hammer Candle, Defval = 0.382 Ratio
ColorMatch (bool) : To Filter Only Bullish Closed Hammer Candle Pattern, Defval = false
NearSwings (bool) : To Specify If We Want The Doji To Be Near A Recent Swing Low, Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing Low, Defval = 10
ATRFilterCheck (float) : To Filter Smaller Hammer Candles That Might Be Better Classified As A Doji Candle, Defval = 1
ATRPeriod (simple int) : To Change ATR Period Of The ATR Filter, Defval = 20
Returns: Bool - True If The Current Bar Matches The Requirements of a Hammer Candle
Star(Fib, ColorMatch, NearSwings, SwingLookBack, ATRFilterCheck, ATRPeriod)
Checks If The Current Bar Is A Hammer Candle
Parameters:
Fib (float) : To Specify Which Fibonacci Ratio To Use When Determining The Hammer Candle, Defval = 0.382 Ratio
ColorMatch (bool) : To Filter Only Bullish Closed Hammer Candle Pattern, Defval = false
NearSwings (bool) : To Specify If We Want The Doji To Be Near A Recent Swing Low, Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing Low, Defval = 10
ATRFilterCheck (float) : To Filter Smaller Hammer Candles That Might Be Better Classified As A Doji Candle, Defval = 1
ATRPeriod (simple int) : To Change ATR Period Of The ATR Filter, Defval = 20
Returns: Bool - True If The Current Bar Matches The Requirements of a Hammer Candle
Doji(MaxWickSize, MaxBodySize, DojiType, NearSwings, SwingLookBack)
Checks If The Current Bar Is A Doji Candle
Parameters:
MaxWickSize (float) : To Specify The Maximum Lenght Of Its Upper & Lower Wick, Defval = 2
MaxBodySize (float) : To Specify The Maximum Lenght Of Its Candle Body IN PERCENT, Defval = 0.05
DojiType (int)
NearSwings (bool) : To Specify If We Want The Doji To Be Near A Recent Swing High / Low (Only In Dragonlyf / Gravestone Mode), Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing High / Low (Only In Dragonlyf / Gravestone Mode), Defval = 10
Returns: Bool - True If The Current Bar Matches The Requirements of a Doji Candle
BullishIB(Allowance, RejectionWickSize, EngulfWick, NearSwings, SwingLookBack)
Checks If The Current Bar Is A Bullish Harami Candle
Parameters:
Allowance (int) : To Give Flexibility Of Harami Pattern Detection In Markets That Have Micro Gaps, Defval = 0
RejectionWickSize (float) : To Filter Out long (Upper And Lower) Wick From The Bullsih Harami Pattern, Defval = na
EngulfWick (bool) : To Specify If We Want The Pattern To Also Engulf Its Upper & Lower Previous Wicks, Defval = false
NearSwings (bool) : To Specify If We Want The Pattern To Be Near A Recent Swing Low, Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing Low, Defval = 10
Returns: Bool - True If The Current Bar Matches The Requirements of a Bullish Harami Candle
BearishIB(Allowance, RejectionWickSize, EngulfWick, NearSwings, SwingLookBack)
Checks If The Current Bar Is A Bullish Harami Candle
Parameters:
Allowance (int) : To Give Flexibility Of Harami Pattern Detection In Markets That Have Micro Gaps, Defval = 0
RejectionWickSize (float) : To Filter Out long (Upper And Lower) Wick From The Bearish Harami Pattern, Defval = na
EngulfWick (bool) : To Specify If We Want The Pattern To Also Engulf Its Upper & Lower Previous Wicks, Defval = false
NearSwings (bool) : To Specify If We Want The Pattern To Be Near A Recent Swing High, Defval = true
SwingLookBack (int) : To Specify How Many Bars Back To Detect A Recent Swing High, Defval = 10
Returns: Bool - True If The Current Bar Matches The Requirements of a Bearish Harami Candle
//====================================================================================================================================================
// Custom Time Functions
//====================================================================================================================================================
BarInSession(sess, useFilter)
Determines if the current price bar falls inside the specified session © ZenAndTheArtOfTrading
Parameters:
sess (simple string)
useFilter (bool)
Returns: A boolean - true if the current bar falls within the given time session
BarOutSession(sess, useFilter)
Determines if the current price bar falls outside the specified session © ZenAndTheArtOfTrading
Parameters:
sess (simple string)
useFilter (bool)
Returns: A boolean - true if the current bar falls outside the given time session
DateFilter(startTime, endTime)
Determines if this bar's time falls within date filter range © ZenAndTheArtOfTrading
Parameters:
startTime (int)
endTime (int)
Returns: A boolean - true if the current bar falls within the given dates
DayFilter(monday, tuesday, wednesday, thursday, friday, saturday, sunday)
Checks if the current bar's day is in the list of given days to analyze © ZenAndTheArtOfTrading
Parameters:
monday (bool)
tuesday (bool)
wednesday (bool)
thursday (bool)
friday (bool)
saturday (bool)
sunday (bool)
Returns: A boolean - true if the current bar's day is one of the given days
AUSSess()
Checks If The Current Australian Forex Session In Running
Returns: Bool - True If Currently The Australian Session Is Running
ASIASess()
Checks If The Current Asian Forex Session In Running
Returns: Bool - True If Currently The Asian Session Is Running
EURSess()
Checks If The Current European Forex Session In Running
Returns: Bool - True If Currently The European Session Is Running
USSess()
Checks If The Current US Forex Session In Running
Returns: Bool - True If Currently The US Session Is Running
UNIXToDate(Time, ConversionType, TimeZone)
Converts UNIX Time To Datetime
Parameters:
Time (int) : Is The UNIX Time Input
ConversionType (int) : Is The Datetime Output Format, Defval = DD-MM-YYYY
TimeZone (string) : Is To Convert The Outputed Datetime Into The Specified Time Zone, Defval = Exchange Time Zone
Returns: String - String Of Datetime
LineWrapperLibrary "LineWrapper"
Wrapper Type for Line. Useful when you want to store the line details without drawing them. Can also be used in scnearios where you collect lines to be drawn and draw together towards the end.
draw(this)
draws line as per the wrapper object contents
Parameters:
this : (series Line) Line object.
Returns: current Line object
draw(this)
draws lines as per the wrapper object array
Parameters:
this : (series array) Array of Line object.
Returns: current Array of Line objects
update(this)
updates or redraws line as per the wrapper object contents
Parameters:
this : (series Line) Line object.
Returns: current Line object
update(this)
updates or redraws lines as per the wrapper object array
Parameters:
this : (series array) Array of Line object.
Returns: current Array of Line objects
get_price(this, bar)
get line price based on bar
Parameters:
this : (series Line) Line object.
bar : (series/int) bar at which line price need to be calculated
Returns: line price at given bar.
get_x1(this)
Returns UNIX time or bar index (depending on the last xloc value set) of the first point of the line.
Parameters:
this : (series Line) Line object.
Returns: UNIX timestamp (in milliseconds) or bar index.
get_x2(this)
Returns UNIX time or bar index (depending on the last xloc value set) of the second point of the line.
Parameters:
this : (series Line) Line object.
Returns: UNIX timestamp (in milliseconds) or bar index.
get_y1(this)
Returns price of the first point of the line.
Parameters:
this : (series Line) Line object.
Returns: Price value.
get_y2(this)
Returns price of the second point of the line.
Parameters:
this : (series Line) Line object.
Returns: Price value.
set_x1(this, x, draw, update)
Sets bar index or bar time (depending on the xloc) of the first point.
Parameters:
this : (series Line) Line object.
x : (series int) Bar index or bar time. Note that objects positioned using xloc.bar_index cannot be drawn further than 500 bars into the future.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_x2(this, x, draw, update)
Sets bar index or bar time (depending on the xloc) of the second point.
Parameters:
this : (series Line) Line object.
x : (series int) Bar index or bar time. Note that objects positioned using xloc.bar_index cannot be drawn further than 500 bars into the future.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_y1(this, y, draw, update)
Sets price of the first point
Parameters:
this : (series Line) Line object.
y : (series int/float) Price.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_y2(this, y, draw, update)
Sets price of the second point
Parameters:
this : (series Line) Line object.
y : (series int/float) Price.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_color(this, color, draw, update)
Sets the line color
Parameters:
this : (series Line) Line object.
color : (series color) New line color
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_extend(this, extend, draw, update)
Sets extending type of this line object. If extend=extend.none, draws segment starting at point (x1, y1) and ending at point (x2, y2). If extend is equal to extend.right or extend.left, draws a ray starting at point (x1, y1) or (x2, y2), respectively. If extend=extend.both, draws a straight line that goes through these points.
Parameters:
this : (series Line) Line object.
extend : (series string) New extending type.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_style(this, style, draw, update)
Sets the line style
Parameters:
this : (series Line) Line object.
style : (series string) New line style.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_width(this, width, draw, update)
Sets the line width.
Parameters:
this : (series Line) Line object.
width : (series int) New line width in pixels.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_xloc(this, x1, x2, xloc, draw, update)
Sets x-location and new bar index/time values.
Parameters:
this : (series Line) Line object.
x1 : (series int) Bar index or bar time of the first point.
x2 : (series int) Bar index or bar time of the second point.
xloc : (series string) New x-location value.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_xy1(this, x, y, draw, update)
Sets bar index/time and price of the first point.
Parameters:
this : (series Line) Line object.
x : (series int) Bar index or bar time. Note that objects positioned using xloc.bar_index cannot be drawn further than 500 bars into the future.
y : (series int/float) Price.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
set_xy2(this, x, y, draw, update)
Sets bar index/time and price of the second point
Parameters:
this : (series Line) Line object.
x : (series int) Bar index or bar time. Note that objects positioned using xloc.bar_index cannot be drawn further than 500 bars into the future.
y : (series int/float) Price.
draw : (series bool) draw line after setting attribute
update : (series bool) update line instead of redraw. Only valid if draw is set.
Returns: Current Line object
delete(this)
Deletes the underlying line drawing object
Parameters:
this : (series Line) Line object.
Returns: Current Line object
Line
Line Wrapper object
Fields:
x1 : (series int) Bar index (if xloc = xloc.bar_index) or bar UNIX time (if xloc = xloc.bar_time) of the first point of the line. Note that objects positioned using xloc.bar_index cannot be drawn further than 500 bars into the future.
y1 : (series int/float) Price of the first point of the line.
x2 : (series int) Bar index (if xloc = xloc.bar_index) or bar UNIX time (if xloc = xloc.bar_time) of the second point of the line. Note that objects positioned using xloc.bar_index cannot be drawn further than 500 bars into the future.
y2 : (series int/float) Price of the second point of the line.
xloc : (series string) See description of x1 argument. Possible values: xloc.bar_index and xloc.bar_time. Default is xloc.bar_index.
extend : (series string) If extend=extend.none, draws segment starting at point (x1, y1) and ending at point (x2, y2). If extend is equal to extend.right or extend.left, draws a ray starting at point (x1, y1) or (x2, y2), respectively. If extend=extend.both, draws a straight line that goes through these points. Default value is extend.none.
color : (series color) Line color.
style : (series string) Line style. Possible values: line.style_solid, line.style_dotted, line.style_dashed, line.style_arrow_left, line.style_arrow_right, line.style_arrow_both.
width : (series int) Line width in pixels.
obj : line object
