Fixed Range FootprintFixed Range Footprint allows you to analyze the Footprint over a specified time period. By enabling the "Extend Right" option, the Footprint transforms into a classic mode, extending from the starting point to the most recent bar in real-time.
Input Options:
Group: Coordinates
"Start range": Defines the starting coordinate for the Footprint period.
"End range": Defines the ending coordinate for the Footprint period.
Group: Row Size
"Ticks Per Row": Directly sets the price step, calculated by multiplying the input value by syminfo.mintick.
"Auto": Activates automatic mode for selecting the "Ticks Per Row" value.
"Max row": Relevant in auto mode; it limits the number of rows within a bar. The automatic calculation for "Ticks Per Row" is based on the first available bar and applied to subsequent bars.
Group: Imbalance
"Imbalance Percent": Sets a percentage-based coefficient to determine price level Imbalance by comparing the diagonal buy price to the previous sell price.
"Stacked levels": Defines the minimum number of consecutive Imbalance levels required to draw extended lines.
Group: Support
"Show Footprint Info": Toggles the display of Footprint information.
Group: Value Area
"Value Area": Sets the percentage for the Value Area.
"POC": Toggles the Point of Control (POC).
"VAH": Toggles the Value Area High (VAH).
"VAL": Toggles the Value Area Low (VAL).
"Show Volume Profile": Displays buy/sell volume at each level.
Group: Alerts
"Alert on New Imbalance": Enables alerts for the creation of new Imbalance levels.
"Alert on New Imbalance Line": Enables alerts for the creation of new Imbalance lines.
"Alert on Stop Past Imbalance Line": Enables alerts when price stops past an Imbalance line.
Pesquisar nos scripts por "文华财经tick价格"
offline_detection Library
Description:
Boolean and alert functions that check if the latest user-selected symbol 'sym' has started printing. Alerts trigger by bar close.
Usage:
Mainly for 24/7 crypto exchanges. If an exchange you have alerts on goes offline, the alerts will not trigger. The offline alert is an alert to alert you of that. It's best to create the alerts while on "CRYPTOCAP:TOTAL" because it has the least downtime. The exchange you want alerts on is controlled by the 'sym' parameter. The alerts need to be enabled yourself.
Limitations:
The alerts may be triggered by no volume in a bar, so it's best to set it on timeframes higher than 1 minute. Alerts are not enabled in libraries so the functions must be imported or copied into another script. alert.freq cannot be changed by input because it becomes a series string in a function. dynamic_requests must be true to export functions using `request.*()` calls.
Example:
import NeoButane/offline_detection/1
thing = "COINBASE:BTCUSD"
offline_detection.offlineAlertNoSpam(thing)
offline_detection.onlineAlert(thing)
warningsign()
Library "offline_detection"
Creates alerts for the user-selected symbol by checking if its latest bar is current by comparing it against another chart.
isItDown(sym)
Checks if 'sym' is offline by requesting time of 'sym'.
Parameters:
sym (simple string) : (const string) The user-selected symbol in the form of "PREFIX:TICKER".
Returns: True if time of 'sym' is not available.
isItDownNoSpam(sym)
Checks if 'sym' is offline by requesting time of 'sym' once.
Parameters:
sym (simple string) : (const string) The user-selected symbol in the form of "PREFIX:TICKER".
Returns: True if time of 'sym' is not available and it was available in the previous bar close.
isItUp(sym)
Checks if 'sym' is online after being offline by using isItDown().
Parameters:
sym (simple string) : (const string) The user-selected symbol in the form of "PREFIX:TICKER".
Returns: True if time of 'sym' is available in the current bar but wasn't prior.
offlineAlert(sym)
Checks if isItDown() is true.
Parameters:
sym (simple string) : (const string) The user-selected symbol in the form of "PREFIX:TICKER".
Returns: An alert when the symbol is not online and the time in UTC. This will continue triggering every bar close until the symbol is online.
offlineAlertNoSpam(sym)
Checks if isItDown() is true.
Parameters:
sym (simple string) : (const string) The user-selected symbol in the form of "PREFIX:TICKER".
Returns: An alert when the symbol is not online and the time in UTC.
onlineAlert(sym)
Checks if isItUp() is true.
Parameters:
sym (simple string) : (const string) The user-selected symbol in the form of "PREFIX:TICKER".
Returns: An alert when the symbol is now online and the time in UTC.
warningsign()
Checks if the current chart is "CRYPTOCAP:TOTAL".
Returns: A reminder on the chart.
Futures Settlement [NeoButane]Traders use settlement prices as both support/resistance and as a target for price to trend towards. The intention of this script is to provide possible entry and exit levels for swing and scalp trades by drawing horizontal lines of true settlement prices provided by TradingView.
The settlement price, which is calculated daily, is used to determine the profit/loss of a trader's futures position. Prior to the daily close, price settlement of futures contracts is performed by taking the average of its traded price during a specified period of time.
Usage
The settlement prices, shown as horizontal lines, serve as support or resistance for entry or exit. There are hundreds of ways to combine this with favorite indicators, or it can be used as levels for pure price action traders.
See how settlement price levels can be used in confluence with oscillators.
Configuration
Toggles to show each settlement. Reprint shows prior weeks or months after they've ended. Back-adjusted futures, which affect expired futures price history on continuous futures charts, should only be enabled on non-standard charts to match the user's chart settings.
What this script does
This script plots the daily, weekly, and monthly settlements for futures, including an average for the two most recent weekly or monthly settlements. The weekly settlement uses the last day of the week's daily settlement and the monthly settlement uses the last day of the month's daily settlement. For symbols that do not have settlement prices, which will be almost if not all symbols that are not futures, the settlement price instead becomes price at the last second before the daily/weekly/monthly close. In those cases, this script becomes a tool for automatically plotting daily/weekly/monthly closes.
See below for two different bitcoin charts. The chart on top is a non-futures chart and a futures chart is at the bottom. Note that CME bitcoin futures settle 4 hours (1500 CST) before bitcoin's daily close (UTC).
How this script works
TradingView has a built-in ability to display daily settlements instead of the actual daily close. This can be enabled in chart settings for futures on the daily timeframe and there is an argument for Pine Script to do so as well. Because settlement times are different for multiple products during the day, the script uses the settlement price from daily timeframe, which is guaranteed to be correct because TradingView is wonderful. I accidentally found the undocumented backadjustment and settlement_at_close when I was trying to use ticker.inherit() to create a symbol with its daily close time changed to another symbol's, which I still haven't figured out. TradingView has since added documentation for both of them, but there's still an ambiguous 'etc.' in the description of ticker.inherit() so maybe there's more secret arguments...
The script is able to be used on non-standard charts by using ticker.standard(), but back-adjustment will need to be changed by input to match chart settings.
References
Investopedia explanation of settlement price.
www.investopedia.com
Settlement prices for ES.
www.cmegroup.com
CME summary of settlement price.
www.cmegroup.com
How to enable settlement price as close for daily intervals in TradingView. This does not affect the use of this script.
www.tradingview.com
About back-adjustment for continuous futures charts in TradingView.
www.tradingview.com
Lines of Chaos (ATR/ADR Levels)Lines of Chaos Indicator
This script is designed to provide traders with ATR (Average True Range) and ADR (Average Daily Range) support and resistance levels.
How it Works:
Support and Resistance Lines: The script plots ATR/ADR-based support and resistance lines based on a moving average of the last ATR/ADR Length days, the previous day's close, and the current day's open. Changing the ATR/ADR Length value changes the number of days of data to average.
EMA: The EMA is colored red when the ticker is potentially bearish. The EMA is colored green when the ticker is potentially bullish. Changing the EMA Length changes the number of data bars to average.
Default Settings: The default settings are optimized for most trading environments.
Key Features:
ATR & ADR Calculation: You can use ATR, ADR, or both. ATR is recommended for most scenarios.
Customizable Lengths: Adjust the ATR/ADR Length to refine the average calculation to your preference, with 14 being the standard value.
EMA for Market Bias: The EMA helps determine the ticker bias. It is colored green when the market is above the average price and red when below. This allows you to more easily determine whether or not the ADR/ATR levels are valid.
Versatile Usage: Suitable for various trading types, ensuring broad applicability across different market conditions.
How to Use:
Bounces off Levels: When the price bounces off a support/resistance level, the price will likely respect this level. This indicates that the price is unlikely to exceed the ticker's average volatility.
Breakthroughs of Levels: When the price breaks through a support/resistance level, the price will likely continue beyond this level. This indicates that the price has moved beyond that ticker's average volatility.
Volume Delta Candles [LuxAlgo]Volume Delta Candles provides insights about Intrabar trading activity in an easy-to-interpret manner. Lower timeframe or real-time data is used for displaying Volume Delta percentage against the total volume as a coloured bar part.
The script also highlights the intrabar price with the maximum trading activity, as well as complementary information.
🔶 USAGE
The tool focuses on intrabar volume to provide more information about the trading activity associated with a candle, without having to use an external volume indicator.
Each indicator components is further explained below:
🔹 Volume Delta
The volume delta is obtained by the difference between buy volume and sell volume, where buy volume is the volume associated with a bullish intrabar candle, and sell volume with a bearish intrabar candle.
Positive volume delta is displayed with a green candle area, while negative delta is displayed with a red candle area.
🔹 Bar Coloring
The script displays VD as a percentage of the whole, or from the candle half, depending on the setting ' Display '.
Bars can be coloured as follows:
Full (100%) when Display is set at ' Full Bar '
Half (50% or 100% of half a bar) when Display is set at ' Half Bar '
A negative VD (more bearish than bullish volume) will fill the bar from the top (or centre) of the bar towards the bottom, and a positive VD will fill a bar from the bottom (or centre) of the bar towards the top.
A negative VD on a green candle will show a red-coloured VD against a green-bordered candle. On the other hand, a positive VD on a red candle will show a green-coloured VD against a red-bordered candle.
Colours for VD sentiment opposite to the candle sentiment can be set differently if desired.
🔹 Highest Volume Price Level
The script displays a white (black on light mode) line highlighting the intrabar price level with the highest volume.
When ' Show Previous Max Volume Price ' is checked, a white (black on light mode) dot is displayed 1 bar to the right.
🔶 DETAILS
🔹 Tick/LTF data
The above example used Lower TimeFrame (LTF) data.
The following example uses real-time tick data ( Settings -> Data From )
Both options, LTF or tick data, will show a vertical dotted line where the data starts.
🔹 LTF settings
When ' Data from ' LTF is chosen and ' Auto ' enabled, the LTF will be the nearest possible x times smaller TF than the current TF. When 'Premium' is disabled, the minimum TF will always be 1 minute to ensure TradingView plans lower than Premium don't get an error.
Examples with current Daily TF (when Premium is enabled):
500 : 3 minute LTF
1500 (default): 1 minute LTF
5000: 30 seconds LTF (1 minute if Premium is disabled)
🔹 Notes
Different LTFs give different data, which means different results; this doesn't mean it isn't correct; they are just different data sets.
(LTF is displayed at the top right corner)
To ensure maximum visibility of values, we recommend using Bars from the Bar's style menu.
🔶 SETTINGS
Data from: Lower TimeFrame or real-time Tick data
Resolution: LTF setting
Auto + multiple: Adjusts the initial set resolution
Premium: Enable when your TradingView plan is Premium or higher
🔹 Intrabar Data
Colours
Display: Full/Half bar
Show previous max volume price: White/black dot, showing previous highest volume price level
🔹 Table
Show TF: Show LTF at the top right corner
Colour + table text size
🔹 Details
Show details: label with 'Volume', 'Delta' (VD) and '%'
See USAGE for more information
Historical Correlation [LuxAlgo]The Historical Correlation tool aims to provide the historical correlation coefficients of up to 10 pairs of user-defined tickers starting from a user-defined point in time.
Users can choose to display the historical values as lines or the most recent correlation values as a heat map.
🔶 USAGE
This tool provides historical correlation coefficients, the correlation coefficient between two assets highlight their linear relationship and is always within the range (-1, 1).
It is a simple and easy to use statistical tool, with the following interpretation:
Positive correlation (values close to +1.0): the two assets move in sync, they rise and fall at the same time.
Negative correlation (values close to -1.0): the two assets move in opposite directions: when one goes up, the other goes down and vice versa.
No correlation (values close to 0): the two assets move independently.
The user must confirm the selection of the anchor point in order for the tool to be executed; this can be done directly on the chart by clicking on any bar, or via the date field in the settings panel.
For the parameter Anchor period , the user can choose between the following values NONE, HOURLY, DAILY, WEEKLY, MONTHLY, QUARTERLY and YEARLY. If NONE is selected, there will be no resetting of the calculations, otherwise the calculations will start from the first bar of the new period.
There is a wide range of trading strategies that make use of correlation coefficients between assets, some examples are:
Pair Trading: Traders may wish to take advantage of divergences in the price movements of highly positively correlated assets; even highly positively correlated assets do not always move in the same direction; when assets with a correlation close to +1.0 diverge in their behavior, traders may see this as an opportunity to buy one and sell the other in the expectation that the assets will return to the likely same price behavior.
Sector rotation: Traders may want to favor some sectors that are expected to perform in the next cycle, tracking the correlation between different sectors and between the sector and the overall market.
Diversification: Traders can aim to have a diversified portfolio of uncorrelated assets. From a risk management perspective, it is useful to know the correlation between the assets in your portfolio, if you hold equal positions in positively correlated assets, your risk is tilted in the same direction, so if the assets move against you, your risk is doubled. You can avoid this increased risk by choosing uncorrelated assets so that they move independently.
Hedging: Traders may want to hedge positions with correlated assets, from a hedging perspective, if you are long an asset, you can hedge going long a negative correlated asset or going short a positive correlated asset.
Traders generally need to develop awareness, a key point is to be aware of the relationships between the assets we hold or trade, the historical correlation is an invaluable tool in our arsenal which allows us to make better informed decisions.
On this chart we have an example of historical correlations for several futures markets.
We can clearly see how positively correlated the Nasdaq100 and Dow30 are with the SP500 over the whole period, or how the correlation between the Euro and the SP500 falls from almost +85% to almost -4% since 2021.
As we can see, correlations, like everything else in the market, are not static and vary over time depending on many factors, from macro to technical and everything in between.
🔹 Heatmap
The chart above shows the tool with the default settings and the Drawing Mode set to 'HEATMAP'.
We can see the current correlation between the assets, in this case the FX pairs.
The highest positive correlation is +90% (+0.90) between EURUSD and GBPUSD.
The highest negative correlation is -78% (-0.78) between EURUSD and USDJPY.
The pair with no correlation is AUDUSD and EURCAD with 1% (0.01)
On the above chart we can see the current correlations for the futures markets.
Currently, the assets that are less correlated to the SP500 are NaturalGas and the Euro, the more positive correlations are Nasdaq100 and Dow20, and the more negative correlations are the Yen, Treasury Bonds and 10-Year Notes.
🔶 DETAILS
🔹 Anchor Period
This chart shows the standard FX correlations with the Anchor Period set to `MONTHLY`.
We can clearly see how the calculations restart with the new month, in this case we can clearly see the differences between the correlations from month to month.
Let us look at the correlation coefficient between GBPUSD and USDJPY
In January, their correlation started at close to -100%, rose to close to +50%, only to fall to close to 0% and remain there for the second half of the month.
In February it was -90% in the first few days of the month and is now around -57%.
And between AUDUSD and EURCAD
Last month their correlation was negative for most of the month, reaching -70% and ending around -14%.
This month their correlation has never gone below +21% and at the time of writing is close to +53%.
🔶 SETTINGS
Anchor point: Starting point from which the tool is executed
Anchor period: At the beginning of each new period, the tool will reset the calculations
Pairs from 1 to 10: For each pair of tickers, you can: enable/disable the pair, select the color and specify the two tickers from which you wish to obtain the correlation
🔹 Style
Drawing Mode: Output style, `LINES` will show the historical correlations as lines, `HEATMAP` will show the current correlations with a color gradient from green for correlations near 1 to red for correlations near -1.
Time & Sales (Tape) [By MUQWISHI]▋ INTRODUCTION :
The “Time and Sales” (Tape) indicator generates trade data, including time, direction, price, and volume for each executed trade on an exchange. This information is typically delivered in real-time on a tick-by-tick basis or lower timeframe, providing insights into the traded size for a specific security.
_______________________
▋ OVERVIEW:
_______________________
▋ Volume Dynamic Scale Bar:
It's a way for determining dominance on the time and sales table, depending on the selected length (number of rows), indicating whether buyers or sellers are in control in selected length.
_______________________
▋ INDICATOR SETTINGS:
#Section One: Table Settings
#Section Two: Technical Settings
(1) Implement By: Retrieve data by
(1A) Lower Timeframe: Fetch data from the selected lower timeframe.
(1B) Live Tick: Fetch data in real-time on a tick-by-tick basis, capturing data as soon as it's observed by the system.
(2) Length (Number of Rows): User able to select number of rows.
(3) Size Type: Volume OR Price Volume.
_____________________
▋ COMMENT:
The values in a table should not be taken as a major concept to build a trading decision.
Please let me know if you have any questions.
Thank you.
@tk · spectral█ OVERVIEW
This script is an indicator that helps traders to identify the price difference between spot and futures of the current crypto plotted into the chart. It works in both types of markets, when the chart is plotting the crypto in spot market, it will compare with its respective futures ticker and vice-versa. If the current asset isn't a crypt ticker, the indicator will not be plotted into the chart.
█ MOTIVATION
Since crypto's derivative market is based on spot market asset's price, to calculate the arbitrage mechanisms that attempts to balance the asset price, this indicator can help traders to identify some spot and futures price divergence that can create an anomaly of funding rate and can push it to an extreme negative — or positive — rate. So, easing to track the price difference between both markets will bring more evidences to identify an artificial price move, specially in crypto assets with low market cap.
█ CONCEPT
The trading concept to use this indicator is the concept of the arbitrage machamism created by exchanges that calculates the funding rate based on spot and futures price difference that will vary from exchange to exchange. This strategy don't works alone. It needs to be aligned together with others indicators like Exponential Moving Averages, Chart Patterns, Support and Resistance, and so on... Even more confluences that you have, bigger are your chances to increase the probability for a successful trade. So, don't use this indicator alone. Compose a trading strategy and use it to improve your analysis.
█ CUSTOMIZATION
This indicator allows the trader to customize the following settings:
GENERAL
Text size
Changes the font size of price difference table to improve accessibility.
Type: string
Options: `tiny`, `small`, `normal`, `large`.
Default: `small`
Position
Changes the position of price difference table.
Type: string
Options: `top_left`, `top_center`, `top_right`, `middle_left`, `middle_center`, `middle_right`, `bottom_left`, `bottom_center`, `bottom_right`.
Default: `bottom_right`
Pair Quote
The ticker quote symbol that will be used to base the ticker comparison from spot to futures (e.g. BTCUSDT which `USDT` is the quote. ETHBTC which `BTC` is the quote).
Type: string
Default: USDT
Spectrum Color
The color of the spectrum candles. Spectrum candles are the candles of the opposite market. If the current ticker is in the spot market, the spectrum candles will be the price of the futures market.
Type: color
Default: #434651
█ FUNCTIONS
The indicator contains the following functions:
stripStarts(src, str)
Strips a defined pattern from a string.
Parameters:
src: (string) Source string
str: (string) String pattern to be stripped from start of source string.
Returns: (string) Stripped string with matched regex pattern.
How To Input CSV List Of Symbol Data Used For ScreenerExample of how to input multiple symbols at once using a CSV list of ticker IDs. The input list is extracted into individual ticker IDs which are then each used within an example screener function that calculates their rate of change. The results for each of the rate of changes are then plotted.
For code brevity this example only demonstrates using up to 4 symbols, but the logic is annotated to show how it can easily be expanded for use with up to 40 ticker IDs.
The CSV list used for input may contain spaces or no spaces after each comma separator, but whichever format (space or no space) is used must be used consistently throughout the list. If the list contains any invalid symbols the script will display a red exclamation mark that when clicked will display those invalid symbols.
If more than 4 ticker IDs are input then only the first 4 are used. If less than 4 ticker IDs are used then the unused screener calls will return `float(na)`. In the published chart the input list is using only 3 ticker IDs so there are only 3 plots shown instead of 4.
NOTICE: This is an example script and not meant to be used as an actual strategy. By using this script or any portion thereof, you acknowledge that you have read and understood that this is for research purposes only and I am not responsible for any financial losses you may incur by using this script!
BankNifty_Bullish_Intraday
The script uses following mechanism to give a signal of BUY if multiple parameters evaluated are all passed.
ENTRY-
1. 5 min MACD should be more than its previous tick
2. 15 min MACD should be more than its previous tick
3. 60 min MACD should be more than its previous tick
4. ADX should be more than 12
5. RSI should be more than 60
6. Stochastic %k should have cross over with %d
7. Bollinger band upper band value should be more than previous tick
EXIT
If the 5 min bar price closes below 5 min EMA , it gives an exit signal.
BankNifty_Bearish_Intraday
The script uses following mechanism to give a signal of SELL if multiple parameters evaluated are all passed.
ENTRY-
1. 5 min MACD should be less than its previous tick
2. 15 min MACD should be less than its previous tick
3. 60 min MACD should be less than its previous tick
4. ADX should be more than 12
5. RSI should be less than 40
6. Stochastic %k should have negative cross over with %d
7. Bollinger band lower band value should be less than previous tick
EXIT
If the 5 min bar price closes above 5 min EMA , it gives an exit signal.
TPO Market Profile [Kioseff Trading]REPOST; SCRIPT WORKS!!
Due to technical error, this script was republished! Thank you for your support (:
Hello!
This indicator comprises a real time TPO Market Profile!
The script works on any timeframe 1 second or greater - the script calculates relative to the timeframe selected for your chart.
The image above shows the 1-minute BTCUSD chart; 650 +/- tick levels are set.
To see the script in full functionality - try using bar replay on a cryptocurrency 1-minute chart (start at the beginning of a regular hours session). Be sure to adjust the tick spread if necessary (:
So far, the script's held up in real time - I've not had any array loop errors or timeouts. The TPO profile updates accordingly with changes in time / high and low prices. Letters are appended to the profile in real time.
The image above shows configurations for the indicator. I plan to update the indicator quite a bit over the coming days - more to come.
You can select the timeframe change the indicator accounts for. For instance, you can have set the indicator to reset every day, every 30 minutes, every 5 minutes, every week, month, etc.
In the image above, I configured the indicator to recalculate every 3 months. Consequently, the indicator will record a TPO profile for three consecutive, reset, then record a TPO profile for the next 3 months. This setting makes the indicator compatible with any timeframe greater than 1 minute.
You can also use a drag & drop time-start bar to modify the starting point for the market profile TPO calculation.
The indicator hosts an option to auto calculate the tick spread between levels. However, as you switch timeframes and assets, sometimes, you'll have to manually set the tick range (:
Thanks for checking it out; more to come!
Sep 4
Release Notes: UPDATE: The indicator can work on seconds-based charts.
The image above shows the indicator working on the 1-second chart.
(Screenshot is old; characters are now numbered instead of strange unicode)
Release Notes: Added value area + vah + val. Font update. Changed characters to numbered once the alphabet is exhausted. POC, VAH, and VAL label located left of the first bar of the interval. Initial balance range can be toggled. Spaced the characters (more legible). Quite a bit of aesthetic changes so check it out!
Soon, I'll release a version of the script that shows VAH, POC, VAL, and TPO letters from previous sessions. I coded this feature into this indicator; however, it was removed due to load time complications. This feature will be its own script (:
If the script has trouble loading please let me know (:
Delta Volume Channels [LucF]█ OVERVIEW
This indicator displays on-chart visuals aimed at making the most of delta volume information. It can color bars and display two channels: one for delta volume, another calculated from the price levels of bars where delta volume divergences occur. Markers and alerts can also be configured using key conditions, and filtered in many different ways. The indicator caters to traders who prefer chart visuals over raw values. It will work on historical bars and in real time, using intrabar analysis to calculate delta volume in both conditions.
█ CONCEPTS
Delta Volume
The volume delta concept divides a bar's volume in "up" and "down" volumes. The delta is calculated by subtracting down volume from up volume. Many calculation techniques exist to isolate up and down volume within a bar. The simplest techniques use the polarity of interbar price changes to assign their volume to up or down slots, e.g., On Balance Volume or the Klinger Oscillator . Others such as Chaikin Money Flow use assumptions based on a bar's OHLC values. The most precise calculation method uses tick data and assigns the volume of each tick to the up or down slot depending on whether the transaction occurs at the bid or ask price. While this technique is ideal, it requires huge amounts of data on historical bars, which usually limits the historical depth of charts and the number of symbols for which tick data is available.
This indicator uses intrabar analysis to achieve a compromise between the simplest and most precise methods of calculating volume delta. In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate volume delta on historical bars on our charts. TradingView's Volume Profile built-in indicators use it, as do the CVD - Cumulative Volume Delta Candles and CVD - Cumulative Volume Delta (Chart) indicators published from the TradingView account . My Volume Delta Columns Pro indicator also uses intrabar analysis. Other volume delta indicators such as my Realtime 5D Profile use realtime chart updates to achieve more precise volume delta calculations. Indicators of that type cannot be used on historical bars however; they only work in real time.
This is the logic I use to assign intrabar volume to up or down slots:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars making up a chart bar have been analyzed and the up or down property of each intrabar's volume determined, the up volumes are added and the down volumes subtracted. The resulting value is volume delta for that chart bar, which can be used as an estimate of the buying/selling pressure on an instrument.
Delta Volume Percent (DV%)
This value is the proportion that delta volume represents of the total intrabar volume in the chart bar. Note that on some symbols/timeframes, the total intrabar volume may differ from the chart's volume for a bar, but that will not affect our calculations since we use the total intrabar volume.
Delta Volume Channel
The DV channel is the space between two moving averages: the reference line and a DV%-weighted version of that reference. The reference line is a moving average of a type, source and length which you select. The DV%-weighted line uses the same settings, but it averages the DV%-weighted price source.
The weight applied to the source of the reference line is calculated from two values, which are multiplied: DV% and the relative size of the bar's volume in relation to previous bars. The effect of this is that DV% values on bars with higher total volume will carry greater weight than those with lesser volume.
The DV channel can be in one of four states, each having its corresponding color:
• Bull (teal): The DV%-weighted line is above the reference line.
• Strong bull (lime): The bull condition is fulfilled and the bar's close is above the reference line and both the reference and the DV%-weighted lines are rising.
• Bear (maroon): The DV%-weighted line is below the reference line.
• Strong bear (pink): The bear condition is fulfilled and the bar's close is below the reference line and both the reference and the DV%-weighted lines are falling.
Divergences
In the context of this indicator, a divergence is any bar where the slope of the reference line does not match that of the DV%-weighted line. No directional bias is assigned to divergences when they occur.
Divergence Channel
The divergence channel is the space between two levels (by default, the bar's low and high ) saved when divergences occur. When price has breached a channel and a new divergence occurs, a new channel is created. Until that new channel is breached, bars where additional divergences occur will expand the channel's levels if the bar's price points are outside the channel.
Prices breaches of the divergence channel will change its state. Divergence channels can be in one of five different states:
• Bull (teal): Price has breached the channel to the upside.
• Strong bull (lime): The bull condition is fulfilled and the DV channel is in the strong bull state.
• Bear (maroon): Price has breached the channel to the downside.
• Strong bear (pink): The bear condition is fulfilled and the DV channel is in the strong bear state.
• Neutral (gray): The channel has not been breached.
█ HOW TO USE THE INDICATOR
Load the indicator on an active chart (see here if you don't know how).
The default configuration displays:
• The DV channel, without the reference or DV%-weighted lines.
• The Divergence channel, without its level lines.
• Bar colors using the state of the DV channel.
The default settings use an Arnaud-Legoux moving average on the close and a length of 20 bars. The DV%-weighted version of it uses a combination of DV% and relative volume to calculate the ultimate weight applied to the reference. The DV%-weighted line is capped to 5 standard deviations of the reference. The lower timeframe used to access intrabars automatically adjusts to the chart's timeframe and achieves optimal balance between the number of intrabars inspected in each chart bar, and the number of chart bars covered by the script's calculations.
The Divergence channel's levels are determined using the high and low of the bars where divergences occur. Breaches of the channel require a bar's low to move above the top of the channel, and the bar's high to move below the channel's bottom.
No markers appear on the chart; if you want to create alerts from this script, you will need first to define the conditions that will trigger the markers, then create the alert, which will trigger on those same conditions.
To learn more about how to use this indicator, you must understand the concepts it uses and the information it displays, which requires reading this description. There are no videos to explain it.
█ FEATURES
The script's inputs are divided in four sections: "DV channel", "Divergence channel", "Other Visuals" and "Marker/Alert Conditions". The first setting is the selection method used to determine the intrabar precision, i.e., how many lower timeframe bars (intrabars) are examined in each chart bar. The more intrabars you analyze, the more precise the calculation of DV% results will be, but the less chart coverage can be covered by the script's calculations.
DV Channel
Here, you control the visibility and colors of the reference line, its weighted version, and the DV channel between them.
You also specify what type of moving average you want to use as a reference line, its source and length. This acts as the DV channel's baseline. The DV%-weighted line is also a moving average of the same type and length as the reference line, except that it will be calculated from the DV%-weighted source used in the reference line. By default, the DV%-weighted line is capped to five standard deviations of the reference line. You can change that value here. This section is also where you can disable the relative volume component of the weight.
Divergence Channel
This is where you control the appearance of the divergence channel and the key price values used in determining the channel's levels and breaching conditions. These choices have an impact on the behavior of the channel. More generous level prices like the default low and high selection will produce more conservative channels, as will the default choice for breach prices.
In this section, you can also enable a mode where an attempt is made to estimate the channel's bias before price breaches the channel. When it is enabled, successive increases/decreases of the channel's top and bottom levels are counted as new divergences occur. When one count is greater than the other, a bull/bear bias is inferred from it.
Other Visuals
You specify here:
• The method used to color chart bars, if you choose to do so.
• The display of a mark appearing above or below bars when a divergence occurs.
• If you want raw values to appear in tooltips when you hover above chart bars. The default setting does not display them, which makes the script faster.
• If you want to display an information box which by default appears in the lower left of the chart.
It shows which lower timeframe is used for intrabars, and the average number of intrabars per chart bar.
Marker/Alert Conditions
Here, you specify the conditions that will trigger up or down markers. The trigger conditions can include a combination of state transitions of the DV and the divergence channels. The triggering conditions can be filtered using a variety of conditions.
Configuring the marker conditions is necessary before creating an alert from this script, as the alert will use the marker conditions to trigger.
Markers only appear on bar closes, so they will not repaint. Keep in mind, when looking at markers on historical bars, that they are positioned on the bar when it closes — NOT when it opens.
Raw values
The raw values calculated by this script can be inspected using a tooltip and the Data Window. The tooltip is visible when you hover over the top of chart bars. It will display on the last 500 bars of the chart, and shows the values of DV, DV%, the combined weight, and the intermediary values used to calculate them.
█ INTERPRETATION
The aim of the DV channel is to provide a visual representation of the buying/selling pressure calculated using delta volume. The simplest characteristic of the channel is its bull/bear state. One can then distinguish between its bull and strong bull states, as transitions from strong bull to bull states will generally happen when buyers are losing steam. While one should not infer a reversal from such transitions, they can be a good place to tighten stops. Only time will tell if a reversal will occur. One or more divergences will often occur before reversals.
The nature of the divergence channel's design makes it particularly adept at identifying consolidation areas if its settings are kept on the conservative side. A gray divergence channel should usually be considered a no-trade zone. More adventurous traders can use the DV channel to orient their trade entries if they accept the risk of trading in a neutral divergence channel, which by definition will not have been breached by price.
If your charts are already busy with other stuff you want to hold on to, you could consider using only the chart bar coloring component of this indicator:
At its simplest, one way to use this indicator would be to look for overlaps of the strong bull/bear colors in both the DV channel and a divergence channel, as these identify points where price is breaching the divergence channel when buy/sell pressure is consistent with the direction of the breach. I have highlighted all those points in the chart below. Not all of them would have produced profitable trades, but nothing is perfect in the markets. Also, keep in mind that the circles identify the visual you would be looking for — not the trade's entry level.
█ LIMITATIONS
• The script will not work on symbols where no volume is available. An error will appear when that is the case.
• Because a maximum of 100K intrabars can be analyzed by a script, a compromise is necessary between the number of intrabars analyzed per chart bar
and chart coverage. The more intrabars you analyze per chart bar, the less coverage you will obtain.
The setting of the "Intrabar precision" field in the "DV channel" section of the script's inputs
is where you control how the lower timeframe is calculated from the chart's timeframe.
█ NOTES
Volume Quality
If you use volume, it's important to understand its nature and quality, as it varies with sectors and instruments. My Volume X-ray indicator is one way you can appraise the quality of an instrument's intraday volume.
For Pine Script™ Coders
• This script uses the new overload of the fill() function which now makes it possible to do vertical gradients in Pine. I use it for both channels displayed by this script.
• I use the new arguments for plot() 's `display` parameter to control where the script plots some of its values,
namely those I only want to appear in the script's status line and in the Data Window.
• I wrote my script using the revised recommendations in the Style Guide from the Pine v5 User Manual.
█ THANKS
To PineCoders . I have used their lower_tf library in this script, to manage the calculation of the LTF and intrabar stats, and their Time library to convert a timeframe in seconds to a printable form for its display in the Information box.
To TradingView's Pine Script™ team. Their innovations and improvements, big and small, constantly expand the boundaries of the language. What this script does would not have been possible just a few months back.
And finally, thanks to all the users of my scripts who take the time to comment on my publications and suggest improvements. I do not reply to all but I do read your comments and do my best to implement your suggestions with the limited time that I have.
Improved Z-ScoreStandard Z-Score scripts lack customization of parameters that I personally desire when doing quantitative analysis. This is an improved Z-Score Indicator to add to your charts that lets you customize various inputs.
Below are the current features:
1) Ticker Type - which data would you like to use for the ticker input - Open, High, Low, Close, OHLC4
2) Ticker Smoothing? - sometimes if you have noisy data, it could be useful to smooth the ticker with a very fast EMA. If this is set to true, the ticker data will be smoothed with an EMA with period that you specify.
3) Ticker Smoothing Period - if Ticker Smoothing? is set to true, this will allow you to specify the smoothing period of the fast EMA - I usually use a 3-period for all of my quantitative analysis, if I am using smoothing.
4) MA Type - Z-Scores are normalized by subtracting a moving average. This allows you to select either a Simple Moving Average (SMA) or an Exponential Moving Average (EMA) - the standard is to use SMA.
5) MA Period - the previous X number of bars that you would like to use for normalization. The default is set to 21 (this is roughly 1 month of trading days data for a daily chart).
5) Standard Deviation Period - Z-Scores are normalized by dividing by the standard deviation over X previous periods. This allows you the chance to customize. Default is 252 (this is roughly 1 year of trading days data for a daily chart).
I can add more features if folks are interested, let me know! I hope you like the script.
Best regards,
-Jim Bosse-
myAlertsLibrary "myAlerts"
My Alerts Functions - To use with autoview
f_order(_price, _qty, _position, _account, _exchange, _i, i_qtyTypeOrder, typeMsg, syminfoticker)
- Write the entry order message
Parameters:
_price : - The order price
_qty : - The order quantity
_position : - The order side
_account : - The user account
_exchange : - The user exchange
_i : - Used for multi-accounts, this represents the index of accounts
i_qtyTypeOrder : - String used to set Thether or Bitcoin Type Orders
typeMsg : - True = Autoview; False = Metatrader
syminfoticker : - Ticker
Returns: - Returns the open order message
f_stop(_stop_price, _slLimit_price, _account, _exchange, _i, i_delayOrders, typeMsg, syminfoticker)
- Write the stop order message
Parameters:
_stop_price : - The order stop price
_slLimit_price : - The order stop limit price
_account : - The user account
_exchange : - The user exchange
_i : - Used for multi-accounts, this represents the index of accounts
i_delayOrders : - Time in seconds to delay command on autoview
typeMsg : - True = Autoview; False = Metatrader
syminfoticker : - Ticker
Returns: - Returns the open order message
f_take(_take_price, _account, _exchange, _i, i_delayOrders, typeMsg, syminfoticker)
- Write the stop order message
Parameters:
_take_price : - The order stop price
_account : - The user account
_exchange : - The user exchange
_i : - Used for multi-accounts, this represents the index of accounts
i_delayOrders : - Time in seconds to delay command on autoview
typeMsg : - True = Autoview; False = Metatrader
syminfoticker : - Ticker
Returns: - Returns the open order message
f_update(_account, _exchange, _i, i_delayOrders, typeMsg, syminfoticker)
- Write the update order message
Parameters:
_account : - The user account
_exchange : - The user exchange
_i : - Used for multi-accounts, this represents the index of accounts
i_delayOrders : - Time in seconds to delay command on autoview
typeMsg : - True = Autoview; False = Metatrader
syminfoticker : - Ticker
Returns: - Returns the open order message
f_exit(_account, _exchange, _i, i_delayOrders, typeMsg, syminfoticker)
- Write the exit order message
Parameters:
_account : - The user account
_exchange : - The user exchange
_i : - Used for multi-accounts, this represents the index of accounts
i_delayOrders : - Time in seconds to delay command on autoview
typeMsg : - True = Autoview; False = Metatrader
syminfoticker : - Ticker
Returns: - Returns the open order message
f_hedge(_account, _exchange, _i, i_delayOrders, typeMsg, syminfoticker)
- Write the exit order message
Parameters:
_account : - The user account
_exchange : - The user exchange
_i : - Used for multi-accounts, this represents the index of accounts
i_delayOrders : - Time in seconds to delay command on autoview
typeMsg : - True = Autoview; False = Metatrader
syminfoticker : - Ticker
Returns: - Returns the open order message
PlurexSignalIntegrationLibrary "PlurexSignalIntegration"
Provides tools for integrating Strategies and Alerts into plurex.io signals.
plurexMarket() Build a Plurex market from a base and quote asset symbol.
Returns: A market string that can be used in Plurex Signal messages.
tickerToPlurexMarket() Builds simple Plurex market string from the syminfo
Returns: A market string that can be used in Plurex Signal messages.
simpleMessage(secret, action, marketOverride) Builds simple Plurex Signal Messages
Parameters:
secret : The secret for your Signal on plurex
action : The action of the message. One of .
marketOverride : Optional, defaults to the syminfo for the ticker. Use the `plurexMarket` function to build your own.
Returns: A json string message that can be used in alerts to send messages to Plurex.
executeStrategy(secret, openLong, openShort, closeLongs, closeShorts, marketOverride) Executes strategy actions with Plurex Signal messages
Parameters:
secret : The secret for your Signal on plurex
openLong : Strategy should open long if true, aggregated with other boolean values
openShort : Strategy should open short if true, aggregated with other boolean values
closeLongs : Strategy should close longs if true, aggregated with other boolean values
closeShorts : Strategy should close shorts if true, aggregated with other boolean values
marketOverride : Optional, defaults to the syminfo for the ticker. Use the `plurexMarket` function to build your own.
RVSILibrary "RVSI"
This Library contains functions that calculate all types of " Relative Volume Strength Index (MZ RVSI ) " depending upon unique volume oscillator. Achieved RVSI value can be used for divergence detection in volume or to adapt dynamic length in Moving Averages or other functions.
rvsi_tfs(vol_src, vol_Len, rvsiLen, _open, _close) Relative Volume Strength Index based on TFS Volume Oscillator
Parameters:
vol_src : Volume Source
vol_Len : Volume Legth for TFS Volume Oscillato
rvsiLen : Period of Relative Volume Strength Index
_open : Ticker Open Value
_close : Ticker Close Value
Returns: Relative Volume Strength Index value based on TFS Volume Oscillator
rvsi_obv(vol_src, rvsiLen, _close) Relative Volume Strength Index based on On Balance Volume
Parameters:
vol_src : Volume Source to Calculate On Balance Volume
rvsiLen : Period of Relative Volume Strength Index
_close : Ticker Close Value
Returns: Relative Volume Strength Index value based on On Balance Volume
rvsi_kvo(vol_src, FastX, SlowX, rvsiLen, _close) Relative Volume Strength Index based on Klinger Volume Oscillator
Parameters:
vol_src : Volume Source
FastX : Volume Fast Length
SlowX : Volume Slow Length
rvsiLen : Period of Relative Volume Strength Index
_close : Ticker Close Value
Returns: Relative Volume Strength Index value based on Klinger Volume Oscillator
rvsi_vzo(vol_src, zLen, rvsiLen, _close) Relative Volume Strength Index based on Volume Zone Oscillator
Parameters:
vol_src : Volume Source
zLen : Volume Legth for Volume Zone Oscillator
rvsiLen : Period of Relative Volume Strength Index
_close : Ticker Close Value
Returns: Relative Volume Strength Index value based on Volume Zone Oscillator
rvsi_cvo_obv(vol_src, ema1len, ema2len, rvsiLen) Relative Volume Strength Index based on Cumulative Volume Oscillator with On Balance Volume as Calculations Source
Parameters:
vol_src : Volume Source
ema1len : EMA Fast Length
ema2len : EMA Slow Length
rvsiLen : Period of Relative Volume Strength Index
Returns: Relative Volume Strength Index value based on Cumulative Volume Oscillator with On Balance Volume as Calculations Source
rvsi_cvo_pvt(vol_src, FastX, SlowX, rvsiLen) Relative Volume Strength Index based on Cumulative Volume Oscillator with Price Volume Trend as Calculations Source
Parameters:
vol_src : Volume Source
FastX : EMA Fast Length
SlowX : EMA Slow Length
rvsiLen : Period of Relative Volume Strength Index
Returns: Relative Volume Strength Index value based on Cumulative Volume Oscillator with Price Volume Trend as Calculations Source
rvsi_cvo_cvd(vol_src, FastX, SlowX, rvsiLen, _open, _close, _high, _low) Relative Volume Strength Index based on Cumulative Volume Oscillator with Cumulative Volume Delta as Calculations Source
Parameters:
vol_src : Volume Source
FastX : EMA Fast Length
SlowX : EMA Slow Length
rvsiLen : Period of Relative Volume Strength Index
_open : Ticker Open Value
_close : Ticker Close Value
_high : Ticker High Value
_low : Ticker Low Value
Returns: Relative Volume Strength Index value based on Cumulative Volume Oscillator with Cumulative Volume Delta as Calculations Source
Double wave-trend Oscillator Buy/Sell signalsBINANCE:ROSEUSDT
This script attempts to use Wave Trend Oscillator's of different lengths in order to identify trade entries and exits for bullish trades. This indicator is strongly recommended to be used with volatile assets or on large time interval charts. You use this script by entering a trade when it signals a green block and exiting when it signals red although these signals could potentially be used as trend reversal signals instead. The script uses two wave trend oscillator's the lengths of which can be edited in the settings, but the general idea is that one is fast and one is slow and these indicate when to buy/sell when they crossover the overbought/sold lines. In the setting you can choose whether the fast or the slow line will be used for buy signal and the other is then used to signal selling. By default this will be ticked on indicating that the fast line crossing over the oversold level will be used for buy signals, if it is ticked off the slow line will be used. The other tickbox is for whether the line used for selling will signal when it first crosses over the overbought line or whether it should signal then it crosses back under the overbought line after having crossed over it, the default value is off indicating that it will signal when it crosses back under the overbought level. The overbought/sold levels should be tweaked on a per asset basis to get the best quality signals.
The original code for the Wave Trend Oscillator comes from LazyBear and was modified and built on to create this indicator.
SeasonalityThis is my attempt to bring an open source Seasonality indicator to TradingView.
There are still outstanding issues I couldn't figure out, so I am hoping some more seasoned Pine Script coders can take the lead from here.
What is Seasonality: www.investopedia.com
How to Use
The indicator plots the avg % change per bar for all complete years, up to 20 years back.
It will only show in the daily resolution.
For charts with more data, you need to scroll back a bit to get the line to display.
Use Offset Adjust in the menu for charts that do not align perfectly to the start of the year.
Use Smoothing in the menu to apply an EMA to the line.
The panel shows YTD % gain, 5-day rolling seasonality, and 20-day rolling seasonality.
Known Issues
Does not work for tickers with over 10,000 bars of data.
Some tickers do not align correctly.
Only works with tickers that have ~252 bars a year.
Areas for Improvement
Figure out a way to use barssince() to get the precise amount of bars for each year. This will make the seasonality calculation and automatic offset more accurate.
Have an option for calendar week, month, and year seasonality.
Webhook Starter Kit [HullBuster]
Introduction
This is an open source strategy which provides a framework for webhook enabled projects. It is designed to work out-of-the-box on any instrument triggering on an intraday bar interval. This is a full featured script with an emphasis on actual trading at a brokerage through the TradingView alert mechanism and without requiring browser plugins.
The source code is written in a self documenting style with clearly defined sections. The sections “communicate” with each other through state variables making it easy for the strategy to evolve and improve. This is an excellent place for Pine Language beginners to start their strategy building journey. The script exhibits many Pine Language features which will certainly ad power to your script building abilities.
This script employs a basic trend follow strategy utilizing a forward pyramiding technique. Trend detection is implemented through the use of two higher time frame series. The market entry setup is a Simple Moving Average crossover. Positions exit by passing through conditional take profit logic. The script creates ten indicators including a Zscore oscillator to measure support and resistance levels. The indicator parameters are exposed through 47 strategy inputs segregated into seven sections. All of the inputs are equipped with detailed tool tips to help you get started.
To improve the transition from simulation to execution, strategy.entry and strategy.exit calls show enhanced message text with embedded keywords that are combined with the TradingView placeholders at alert time. Thereby, enabling a single JSON message to generate multiple execution events. This is genius stuff from the Pine Language development team. Really excellent work!
This document provides a sample alert message that can be applied to this script with relatively little modification. Without altering the code, the strategy inputs can alter the behavior to generate thousands of orders or simply a few dozen. It can be applied to crypto, stocks or forex instruments. A good way to look at this script is as a webhook lab that can aid in the development of your own endpoint processor, impress your co-workers and have hours of fun.
By no means is a webhook required or even necessary to benefit from this script. The setups, exits, trend detection, pyramids and DCA algorithms can be easily replaced with more sophisticated versions. The modular design of the script logic allows you to incrementally learn and advance this script into a functional trading system that you can be proud of.
Design
This is a trend following strategy that enters long above the trend line and short below. There are five trend lines that are visible by default but can be turned off in Section 7. Identified, in frequency order, as follows:
1. - EMA in the chart time frame. Intended to track price pressure. Configured in Section 3.
2. - ALMA in the higher time frame specified in Section 2 Signal Line Period.
3. - Linear Regression in the higher time frame specified in Section 2 Signal Line Period.
4. - Linear Regression in the higher time frame specified in Section 2 Signal Line Period.
5. - DEMA in the higher time frame specified in Section 2 Trend Line Period.
The Blue, Green and Orange lines are signal lines are on the same time frame. The time frame selected should be at least five times greater than the chart time frame. The Purple line represents the trend line for which prices above the line suggest a rising market and prices below a falling market. The time frame selected for the trend should be at least five times greater than the signal lines.
Three oscillators are created as follows:
1. Stochastic - In the chart time frame. Used to enter forward pyramids.
2. Stochastic - In the Trend period. Used to detect exit conditions.
3. Zscore - In the Signal period. Used to detect exit conditions.
The Stochastics are configured identically other than the time frame. The period is set in Section 2.
Two Simple Moving Averages provide the trade entry conditions in the form of a crossover. Crossing up is a long entry and down is a short. This is in fact the same setup you get when you select a basic strategy from the Pine editor. The crossovers are configured in Section 3. You can see where the crosses are occurring by enabling Show Entry Regions in Section 7.
The script has the capacity for pyramids and DCA. Forward pyramids are enabled by setting the Pyramid properties tab with a non zero value. In this case add on trades will enter the market on dips above the position open price. This process will continue until the trade exits. Downward pyramids are available in Crypto and Range mode only. In this case add on trades are placed below the entry price in the drawdown space until the stop is hit. To enable downward pyramids set the Pyramid Minimum Span In Section 1 to a non zero value.
This implementation of Dollar Cost Averaging (DCA) triggers off consecutive losses. Each loss in a run increments a sequence number. The position size is increased as a multiple of this sequence. When the position eventually closes at a profit the sequence is reset. DCA is enabled by setting the Maximum DCA Increments In Section 1 to a non zero value.
It should be noted that the pyramid and DCA features are implemented using a rudimentary design and as such do not perform with the precision of my invite only scripts. They are intended as a feature to stress test your webhook endpoint. As is, you will need to buttress the logic for it to be part of an automated trading system. It is for this reason that I did not apply a Martingale algorithm to this pyramid implementation. But, hey, it’s an open source script so there is plenty of room for learning and your own experimentation.
How does it work
The overall behavior of the script is governed by the Trading Mode selection in Section 1. It is the very first input so you should think about what behavior you intend for this strategy at the onset of the configuration. As previously discussed, this script is designed to be a trend follower. The trend being defined as where the purple line is predominately heading. In BiDir mode, SMA crossovers above the purple line will open long positions and crosses below the line will open short. If pyramiding is enabled add on trades will accumulate on dips above the entry price. The value applied to the Minimum Profit input in Section 1 establishes the threshold for a profitable exit. This is not a hard number exit. The conditional exit logic must be satisfied in order to permit the trade to close. This is where the effort put into the indicator calibration is realized. There are four ways the trade can exit at a profit:
1. Natural exit. When the blue line crosses the green line the trade will close. For a long position the blue line must cross under the green line (downward). For a short the blue must cross over the green (upward).
2. Alma / Linear Regression event. The distance the blue line is from the green and the relative speed the cross is experiencing determines this event. The activation thresholds are set in Section 6 and relies on the period and length set in Section 2. A long position will exit on an upward thrust which exceeds the activation threshold. A short will exit on a downward thrust.
3. Exponential event. The distance the yellow line is from the blue and the relative speed the cross is experiencing determines this event. The activation thresholds are set in Section 3 and relies on the period and length set in the same section.
4. Stochastic event. The purple line stochastic is used to measure overbought and over sold levels with regard to position exits. Signal line positions combined with a reading over 80 signals a long profit exit. Similarly, readings below 20 signal a short profit exit.
Another, optional, way to exit a position is by Bale Out. You can enable this feature in Section 1. This is a handy way to reduce the risk when carrying a large pyramid stack. Instead of waiting for the entire position to recover we exit early (bale out) as soon as the profit value has doubled.
There are lots of ways to implement a bale out but the method I used here provides a succinct example. Feel free to improve on it if you like. To see where the Bale Outs occur, enable Show Bale Outs in Section 7. Red labels are rendered below each exit point on the chart.
There are seven selectable Trading Modes available from the drop down in Section 1:
1. Long - Uses the strategy.risk.allow_entry_in to execute long only trades. You will still see shorts on the chart.
2. Short - Uses the strategy.risk.allow_entry_in to execute short only trades. You will still see long trades on the chart.
3. BiDir - This mode is for margin trading with a stop. If a long position was initiated above the trend line and the price has now fallen below the trend, the position will be reversed after the stop is hit. Forward pyramiding is available in this mode if you set the Pyramiding value in the Properties tab. DCA can also be activated.
4. Flip Flop - This is a bidirectional trading mode that automatically reverses on a trend line crossover. This is distinctively different from BiDir since you will get a reversal even without a stop which is advantageous in non-margin trading.
5. Crypto - This mode is for crypto trading where you are buying the coins outright. In this case you likely want to accumulate coins on a crash. Especially, when all the news outlets are talking about the end of Bitcoin and you see nice deep valleys on the chart. Certainly, under these conditions, the market will be well below the purple line. No margin so you can’t go short. Downward pyramids are enabled for Crypto mode when two conditions are met. First the Pyramiding value in the Properties tab must be non zero. Second the Pyramid Minimum Span in Section 1 must be non zero.
6. Range - This is a counter trend trading mode. Longs are entered below the purple trend line and shorts above. Useful when you want to test your webhook in a market where the trend line is bisecting the signal line series. Remember that this strategy is a trend follower. It’s going to get chopped out in a range bound market. By turning on the Range mode you will at least see profitable trades while stuck in the range. However, when the market eventually picks a direction, this mode will sustain losses. This range trading mode is a rudimentary implementation that will need a lot of improvement if you want to create a reliable switch hitter (trend/range combo).
7. No Trade. Useful when setting up the trend lines and the entry and exit is not important.
Once in the trade, long or short, the script tests the exit condition on every bar. If not a profitable exit then it checks if a pyramid is required. As mentioned earlier, the entry setups are quite primitive. Although they can easily be replaced by more sophisticated algorithms, what I really wanted to show is the diminished role of the position entry in the overall life of the trade. Professional traders spend much more time on the management of the trade beyond the market entry. While your trade entry is important, you can get in almost anywhere and still land a profitable exit.
If DCA is enabled, the size of the position will increase in response to consecutive losses. The number of times the position can increase is limited by the number set in Maximum DCA Increments of Section 1. Once the position breaks the losing streak the trade size will return the default quantity set in the Properties tab. It should be noted that the Initial Capital amount set in the Properties tab does not affect the simulation in the same way as a real account. In reality, running out of money will certainly halt trading. In fact, your account would be frozen long before the last penny was committed to a trade. On the other hand, TradingView will keep running the simulation until the current bar even if your funds have been technically depleted.
Entry and exit use the strategy.entry and strategy.exit calls respectfully. The alert_message parameter has special keywords that the endpoint expects to properly calculate position size and message sequence. The alert message will embed these keywords in the JSON object through the {{strategy.order.alert_message}} placeholder. You should use whatever keywords are expected from the endpoint you intend to webhook in to.
Webhook Integration
The TradingView alerts dialog provides a way to connect your script to an external system which could actually execute your trade. This is a fantastic feature that enables you to separate the data feed and technical analysis from the execution and reporting systems. Using this feature it is possible to create a fully automated trading system entirely on the cloud. Of course, there is some work to get it all going in a reliable fashion. Being a strategy type script place holders such as {{strategy.position_size}} can be embedded in the alert message text. There are more than 10 variables which can write internal script values into the message for delivery to the specified endpoint.
Entry and exit use the strategy.entry and strategy.exit calls respectfully. The alert_message parameter has special keywords that my endpoint expects to properly calculate position size and message sequence. The alert message will embed these keywords in the JSON object through the {{strategy.order.alert_message}} placeholder. You should use whatever keywords are expected from the endpoint you intend to webhook in to.
Here is an excerpt of the fields I use in my webhook signal:
"broker_id": "kraken",
"account_id": "XXX XXXX XXXX XXXX",
"symbol_id": "XMRUSD",
"action": "{{strategy.order.action}}",
"strategy": "{{strategy.order.id}}",
"lots": "{{strategy.order.contracts}}",
"price": "{{strategy.order.price}}",
"comment": "{{strategy.order.alert_message}}",
"timestamp": "{{time}}"
Though TradingView does a great job in dispatching your alert this feature does come with a few idiosyncrasies. Namely, a single transaction call in your script may cause multiple transmissions to the endpoint. If you are using placeholders each message describes part of the transaction sequence. A good example is closing a pyramid stack. Although the script makes a single strategy.close() call, the endpoint actually receives a close message for each pyramid trade. The broker, on the other hand, only requires a single close. The incongruity of this situation is exacerbated by the possibility of messages being received out of sequence. Depending on the type of order designated in the message, a close or a reversal. This could have a disastrous effect on your live account. This broker simulator has no idea what is actually going on at your real account. Its just doing the job of running the simulation and sending out the computed results. If your TradingView simulation falls out of alignment with the actual trading account lots of really bad things could happen. Like your script thinks your are currently long but the account is actually short. Reversals from this point forward will always be wrong with no one the wiser. Human intervention will be required to restore congruence. But how does anyone find out this is occurring? In closed systems engineering this is known as entropy. In practice your webhook logic should be robust enough to detect these conditions. Be generous with the placeholder usage and give the webhook code plenty of information to compare states. Both issuer and receiver. Don’t blindly commit incoming signals without verifying system integrity.
Setup
The following steps provide a very brief set of instructions that will get you started on your first configuration. After you’ve gone through the process a couple of times, you won’t need these anymore. It’s really a simple script after all. I have several example configurations that I used to create the performance charts shown. I can share them with you if you like. Of course, if you’ve modified the code then these steps are probably obsolete.
There are 47 inputs divided into seven sections. For the most part, the configuration process is designed to flow from top to bottom. Handy, tool tips are available on every field to help get you through the initial setup.
Step 1. Input the Base Currency and Order Size in the Properties tab. Set the Pyramiding value to zero.
Step 2. Select the Trading Mode you intend to test with from the drop down in Section 1. I usually select No Trade until I’ve setup all of the trend lines, profit and stop levels.
Step 3. Put in your Minimum Profit and Stop Loss in the first section. This is in pips or currency basis points (chart right side scale). Remember that the profit is taken as a conditional exit not a fixed limit. The actual profit taken will almost always be greater than the amount specified. The stop loss, on the other hand, is indeed a hard number which is executed by the TradingView broker simulator when the threshold is breached.
Step 4. Apply the appropriate value to the Tick Scalar field in Section 1. This value is used to remove the pipette from the price. You can enable the Summary Report in Section 7 to see the TradingView minimum tick size of the current chart.
Step 5. Apply the appropriate Price Normalizer value in Section 1. This value is used to normalize the instrument price for differential calculations. Basically, we want to increase the magnitude to significant digits to make the numbers more meaningful in comparisons. Though I have used many normalization techniques, I have always found this method to provide a simple and lightweight solution for less demanding applications. Most of the time the default value will be sufficient. The Tick Scalar and Price Normalizer value work together within a single calculation so changing either will affect all delta result values.
Step 6. Turn on the trend line plots in Section 7. Then configure Section 2. Try to get the plots to show you what’s really happening not what you want to happen. The most important is the purple trend line. Select an interval and length that seem to identify where prices tend to go during non-consolidation periods. Remember that a natural exit is when the blue crosses the green line.
Step 7. Enable Show Event Regions in Section 7. Then adjust Section 6. Blue background fills are spikes and red fills are plunging prices. These measurements should be hard to come by so you should see relatively few fills on the chart if you’ve set this up as intended. Section 6 includes the Zscore oscillator the state of which combines with the signal lines to detect statistically significant price movement. The Zscore is a zero based calculation with positive and negative magnitude readings. You want to input a reasonably large number slightly below the maximum amplitude seen on the chart. Both rise and fall inputs are entered as a positive real number. You can easily use my code to create a separate indicator if you want to see it in action. The default value is sufficient for most configurations.
Step 8. Turn off Show Event Regions and enable Show Entry Regions in Section 7. Then adjust Section 3. This section contains two parts. The entry setup crossovers and EMA events. Adjust the crossovers first. That is the Fast Cross Length and Slow Cross Length. The frequency of your trades will be shown as blue and red fills. There should be a lot. Then turn off Show Event Regions and enable Display EMA Peaks. Adjust all the fields that have the word EMA. This is actually the yellow line on the chart. The blue and red fills should show much less than the crossovers but more than event fills shown in Step 7.
Step 9. Change the Trading Mode to BiDir if you selected No Trades previously. Look on the chart and see where the trades are occurring. Make adjustments to the Minimum Profit and Stop Offset in Section 1 if necessary. Wider profits and stops reduce the trade frequency.
Step 10. Go to Section 4 and 5 and make fine tuning adjustments to the long and short side.
Example Settings
To reproduce the performance shown on the chart please use the following configuration: (Bitcoin on the Kraken exchange)
1. Select XBTUSD Kraken as the chart symbol.
2. On the properties tab set the Order Size to: 0.01 Bitcoin
3. On the properties tab set the Pyramiding to: 12
4. In Section 1: Select “Crypto” for the Trading Model
5. In Section 1: Input 2000 for the Minimum Profit
6. In Section 1: Input 0 for the Stop Offset (No Stop)
7. In Section 1: Input 10 for the Tick Scalar
8. In Section 1: Input 1000 for the Price Normalizer
9. In Section 1: Input 2000 for the Pyramid Minimum Span
10. In Section 1: Check mark the Position Bale Out
11. In Section 2: Input 60 for the Signal Line Period
12. In Section 2: Input 1440 for the Trend Line Period
13. In Section 2: Input 5 for the Fast Alma Length
14. In Section 2: Input 22 for the Fast LinReg Length
15. In Section 2: Input 100 for the Slow LinReg Length
16. In Section 2: Input 90 for the Trend Line Length
17. In Section 2: Input 14 Stochastic Length
18. In Section 3: Input 9 Fast Cross Length
19. In Section 3: Input 24 Slow Cross Length
20. In Section 3: Input 8 Fast EMA Length
21. In Section 3: Input 10 Fast EMA Rise NetChg
22. In Section 3: Input 1 Fast EMA Rise ROC
23. In Section 3: Input 10 Fast EMA Fall NetChg
24. In Section 3: Input 1 Fast EMA Fall ROC
25. In Section 4: Check mark the Long Natural Exit
26. In Section 4: Check mark the Long Signal Exit
27. In Section 4: Check mark the Long Price Event Exit
28. In Section 4: Check mark the Long Stochastic Exit
29. In Section 5: Check mark the Short Natural Exit
30. In Section 5: Check mark the Short Signal Exit
31. In Section 5: Check mark the Short Price Event Exit
32. In Section 5: Check mark the Short Stochastic Exit
33. In Section 6: Input 120 Rise Event NetChg
34. In Section 6: Input 1 Rise Event ROC
35. In Section 6: Input 5 Min Above Zero ZScore
36. In Section 6: Input 120 Fall Event NetChg
37. In Section 6: Input 1 Fall Event ROC
38. In Section 6: Input 5 Min Below Zero ZScore
In this configuration we are trading in long only mode and have enabled downward pyramiding. The purple trend line is based on the day (1440) period. The length is set at 90 days so it’s going to take a while for the trend line to alter course should this symbol decide to node dive for a prolonged amount of time. Your trades will still go long under those circumstances. Since downward accumulation is enabled, your position size will grow on the way down.
The performance example is Bitcoin so we assume the trader is buying coins outright. That being the case we don’t need a stop since we will never receive a margin call. New buy signals will be generated when the price exceeds the magnitude and speed defined by the Event Net Change and Rate of Change.
Feel free to PM me with any questions related to this script. Thank you and happy trading!
CFTC RULE 4.41
These results are based on simulated or hypothetical performance results that have certain inherent limitations. Unlike the results shown in an actual performance record, these results do not represent actual trading. Also, because these trades have not actually been executed, these results may have under-or over-compensated for the impact, if any, of certain market factors, such as lack of liquidity. Simulated or hypothetical trading programs in general are also subject to the fact that they are designed with the benefit of hindsight. No representation is being made that any account will or is likely to achieve profits or losses similar to these being shown.
Using `varip` variables [PineCoders]█ OVERVIEW
The new varip keyword in Pine can be used to declare variables that escape the rollback process, which is explained in the Pine User Manual's page on the execution model . This publication explains how Pine coders can use variables declared with varip to implement logic that was impossible to code in Pine before, such as timing events during the realtime bar, or keeping track of sequences of events that occur during successive realtime updates. We present code that allows you to calculate for how much time a given condition is true during a realtime bar, and show how this can be used to generate alerts.
█ WARNINGS
1. varip is an advanced feature which should only be used by coders already familiar with Pine's execution model and bar states .
2. Because varip only affects the behavior of your code in the realtime bar, it follows that backtest results on strategies built using logic based on varip will be meaningless,
as varip behavior cannot be simulated on historical bars. This also entails that plots on historical bars will not be able to reproduce the script's behavior in realtime.
3. Authors publishing scripts that behave differently in realtime and on historical bars should imperatively explain this to traders.
█ CONCEPTS
Escaping the rollback process
Whereas scripts only execute once at the close of historical bars, when a script is running in realtime, it executes every time the chart's feed detects a price or volume update. At every realtime update, Pine's runtime normally resets the values of a script's variables to their last committed value, i.e., the value they held when the previous bar closed. This is generally handy, as each realtime script execution starts from a known state, which simplifies script logic.
Sometimes, however, script logic requires code to be able to save states between different executions in the realtime bar. Declaring variables with varip now makes that possible. The "ip" in varip stands for "intrabar persist".
Let's look at the following code, which does not use varip :
//@version=4
study("")
int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
On historical bars, barstate.isnew is always true, so the plot shows a value of "1". On realtime bars, barstate.isnew is only true when the script first executes on the bar's opening. The plot will then briefly display "1" until subsequent executions occur. On the next executions during the realtime bar, the second branch of the if statement is executed because barstate.isnew is no longer true. Since `updateNo` is initialized to `na` at each execution, the `updateNo + 1` expression yields `na`, so nothing is plotted on further realtime executions of the script.
If we now use varip to declare the `updateNo` variable, the script behaves very differently:
//@version=4
study("")
varip int updateNo = na
if barstate.isnew
updateNo := 1
else
updateNo := updateNo + 1
plot(updateNo, style = plot.style_circles)
The difference now is that `updateNo` tracks the number of realtime updates that occur on each realtime bar. This can happen because the varip declaration allows the value of `updateNo` to be preserved between realtime updates; it is no longer rolled back at each realtime execution of the script. The test on barstate.isnew allows us to reset the update count when a new realtime bar comes in.
█ OUR SCRIPT
Let's move on to our script. It has three parts:
— Part 1 demonstrates how to generate alerts on timed conditions.
— Part 2 calculates the average of realtime update prices using a varip array.
— Part 3 presents a function to calculate the up/down/neutral volume by looking at price and volume variations between realtime bar updates.
Something we could not do in Pine before varip was to time the duration for which a condition is continuously true in the realtime bar. This was not possible because we could not save the beginning time of the first occurrence of the true condition.
One use case for this is a strategy where the system modeler wants to exit before the end of the realtime bar, but only if the exit condition occurs for a specific amount of time. One can thus design a strategy running on a 1H timeframe but able to exit if the exit condition persists for 15 minutes, for example. REMINDER: Using such logic in strategies will make backtesting their complete logic impossible, and backtest results useless, as historical behavior will not match the strategy's behavior in realtime, just as using `calc_on_every_tick = true` will do. Using `calc_on_every_tick = true` is necessary, by the way, when using varip in a strategy, as you want the strategy to run like a study in realtime, i.e., executing on each price or volume update.
Our script presents an `f_secondsSince(_cond, _resetCond)` function to calculate the time for which a condition is continuously true during, or even across multiple realtime bars. It only works in realtime. The abundant comments in the script hopefully provide enough information to understand the details of what it's doing. If you have questions, feel free to ask in the Comments section.
Features
The script's inputs allow you to:
• Specify the number of seconds the tested conditions must last before an alert is triggered (the default is 20 seconds).
• Determine if you want the duration to reset on new realtime bars.
• Require the direction of alerts (up or down) to alternate, which minimizes the number of alerts the script generates.
The inputs showcase the new `tooltip` parameter, which allows additional information to be displayed for each input by hovering over the "i" icon next to it.
The script only displays useful information on realtime bars. This information includes:
• The MA against which the current price is compared to determine the bull or bear conditions.
• A dash which prints on the chart when the bull or bear condition is true.
• An up or down triangle that prints when an alert is generated. The triangle will only appear on the update where the alert is triggered,
and unless that happens to be on the last execution of the realtime bar, it will not persist on the chart.
• The log of all triggered alerts to the right of the realtime bar.
• A gray square on top of the elapsed realtime bars where one or more alerts were generated. The square's tooltip displays the alert log for that bar.
• A yellow dot corresponding to the average price of all realtime bar updates, which is calculated using a varip array in "Part 2" of the script.
• Various key values in the Data Window for each parts of the script.
Note that the directional volume information calculated in Part 3 of the script is not plotted on the chart—only in the Data Window.
Using the script
You can try running the script on an open market with a 30sec timeframe. Because the default settings reset the duration on new realtime bars and require a 20 second delay, a reasonable amount of alerts will trigger.
Creating an alert on the script
You can create a script alert on the script. Keep in mind that when you create an alert from this script, the duration calculated by the instance of the script running the alert will not necessarily match that of the instance running on your chart, as both started their calculations at different times. Note that we use alert.freq_all in our alert() calls, so that alerts will trigger on all instances where the associated condition is met. If your alert is being paused because it reaches the maximum of 15 triggers in 3 minutes, you can configure the script's inputs so that up/down alerts must alternate. Also keep in mind that alerts run a distinct instance of your script on different servers, so discrepancies between the behavior of scripts running on charts and alerts can occur, especially if they trigger very often.
Challenges
Events detected in realtime using variables declared with varip can be transient and not leave visible traces at the close of the realtime bar, as is the case with our script, which can trigger multiple alerts during the same realtime bar, when the script's inputs allow for this. In such cases, elapsed realtime bars will be of no use in detecting past realtime bar events unless dedicated code is used to save traces of events, as we do with our alert log in this script, which we display as a tooltip on elapsed realtime bars.
█ NOTES
Realtime updates
We have no control over when realtime updates occur. A realtime bar can open, and then no realtime updates can occur until the open of the next realtime bar. The time between updates can vary considerably.
Past values
There is no mechanism to refer to past values of a varip variable across realtime executions in the same bar. Using the history-referencing operator will, as usual, return the variable's committed value on previous bars. If you want to preserve past values of a varip variable, they must be saved in other variables or in an array .
Resetting variables
Because varip variables not only preserve their values across realtime updates, but also across bars, you will typically need to plan conditions that will at some point reset their values to a known state. Testing on barstate.isnew , as we do, is a good way to achieve that.
Repainting
The fact that a script uses varip does not make it necessarily repainting. A script could conceivably use varip to calculate values saved when the realtime bar closes, and then use confirmed values of those calculations from the previous bar to trigger alerts or display plots, avoiding repaint.
timenow resolution
Although the variable is expressed in milliseconds it has an actual resolution of seconds, so it only increments in multiples of 1000 milliseconds.
Warn script users
When using varip to implement logic that cannot be replicated on historical bars, it's really important to explain this to traders in published script descriptions, even if you publish open-source. Remember that most TradingViewers do not know Pine.
New Pine features used in this script
This script uses three new Pine features:
• varip
• The `tooltip` parameter in input() .
• The new += assignment operator. See these also: -= , *= , /= and %= .
Example scripts
These are other scripts by PineCoders that use varip :
• Tick Delta Volume , by RicadoSantos .
• Tick Chart and Volume Info from Lower Time Frames by LonesomeTheBlue .
Thanks
Thanks to the PineCoders who helped improve this publication—especially to bmistiaen .
Look first. Then leap.
sDEFI Synthetix ExchangeTradingView allows combining/summing up to a maximum of only 10 tickers in its search field. Their support staff suggested I could combine up to 40 by using Pine Script, so here it is, for a specific 'basket' of crypto tokens.
This study displays the combination of price history for Synthetix Exchange’s sDEFI index.
Tokens included in the index are COMP, MKR, KNC, SNX, ZRX, REP, LEND, REN, LRC, BNT, BAL and UMA. You will see the prices only go back as far as July 31st 2020, which is when the most recent of the compilation (UMA) started its trading history on TradingView. (The study can only display prices for days that *all* the tickers were trading.)
The price history will display as a study, below an existing chart. You will need to resize the windows, to see this study at a larger size. (Grab the window border and move it up, once you have added this study to a chart)
Unfortunately you will not be able to interact with it like a normal chart, i.e. drawing trendlines, adding moving averages, notes or annotations, etc.
May I suggest you send a support request to TradingView, asking for them to allow us to enter more than 10 (perhaps up to 40) tickers with + symbol between them, in the search field, which gives a ‘proper’ chart to analyse?
Please note that when publishing this script, I was required to choose a category from a list that does not contain a relevant category. Given that I had to choose something from the list to proceed, I used 'Support and Resistance', since chartists can see S and R levels by looking at this study.
I trust this study is useful for you sDEFI traders.
Price Action and 3 EMAs Momentum plus Sessions FilterThis indicator plots on the chart the parameters and signals of the Price Action and 3 EMAs Momentum plus Sessions Filter Algorithmic Strategy. The strategy trades based on time-series (absolute) and relative momentum of price close, highs, lows and 3 EMAs.
I am still learning PS and therefore I have only been able to write the indicator up to the Signal generation. I plan to expand the indicator to Entry Signals as well as the full Strategy.
The strategy works best on EURUSD in the 15 minutes TF during London and New York sessions with 1 to 1 TP and SL of 30 pips with lots resulting in 3% risk of the account per trade. I have already written the full strategy in another language and platform and back tested it for ten years and it was profitable for 7 of the 10 years with average profit of 15% p.a which can be easily increased by increasing risk per trade. I have been trading it live in that platform for over two years and it is profitable.
Contributions from experienced PS coders in completing the Indicator as well as writing the Strategy and back testing it on Trading View will be appreciated.
STRATEGY AND INDICATOR PARAMETERS
Three periods of 12, 48 and 96 in the 15 min TF which are equivalent to 3, 12 and 24 hours i.e (15 min * period / 60 min) are the foundational inputs for all the parameters of the PA & 3 EMAs Momentum + SF Algo Strategy and its Indicator.
3 EMAs momentum parameters and conditions
• FastEMA = ema of 12 periods
• MedEMA = ema of 48 periods
• SlowEMA = ema of 96 periods
• All the EMAs analyse price close for up to 96 (15 min periods) equivalent to 24 hours
• There’s Upward EMA momentum if price close > FastEMA and FastEMA > MedEMA and MedEMA > SlowEMA
• There’s Downward EMA momentum if price close < FastEMA and FastEMA < MedEMA and MedEMA < SlowEMA
PA momentum parameters and conditions
• HH = Highest High of 48 periods from 1st closed bar before current bar
• LL = Lowest Low of 48 periods from 1st closed bar from current bar
• Previous HH = Highest High of 84 periods from 12th closed bar before current bar
• Previous LL = Lowest Low of 84 periods from 12th closed bar before current bar
• All the HH & LL and prevHH & prevLL are within the 96 periods from the 1st closed bar before current bar and therefore indicative of momentum during the past 24 hours
• There’s Upward PA momentum if price close > HH and HH > prevHH and LL > prevLL
• There’s Downward PA momentum if price close < LL and LL < prevLL and HH < prevHH
Signal conditions and Status (BuySignal, SellSignal or Neutral)
• The strategy generates Buy or Sell Signals if both 3 EMAs and PA momentum conditions are met for each direction and these occur during the London and New York sessions
• BuySignal if price close > FastEMA and FastEMA > MedEMA and MedEMA > SlowEMA and price close > HH and HH > prevHH and LL > prevLL and timeinrange (LDN&NY) else Neutral
• SellSignal if price close < FastEMA and FastEMA < MedEMA and MedEMA < SlowEMA and price close < LL and LL < prevLL and HH < prevHH and timeinrange (LDN&NY) else Neutral
Entry conditions and Status (EnterBuy, EnterSell or Neutral)(NOT CODED YET)
• ENTRY IS NOT AT THE SIGNAL BAR but at the current bar tick price retracement to FastEMA after the signal
• EnterBuy if current bar tick price <= FastEMA and current bar tick price > prevHH at the time of the Buy Signal
• EnterSell if current bar tick price >= FastEMA and current bar tick price > prevLL at the time of the Sell Signal
