I keep running into complications every time i try to convert or write something that i want to deal with the overnight session. I know i can use MPD and set custom session but i also want to be able to use things with multiple instruments which wont always have the same ETH session times. For instance, im trying to use this Imbalance indicator that was in a chart in the forum.....
100 * (SUM(PVP_ABOVE - PVP_BELOW, POS) / SESST_VOL)
I converted the SESST_VOL to ON Session and created custom indicators for the 2 PVP's to use in MPD's, but MPD does not contain the choice to use ON session like SESST does. I was able to get it to work on a chart with a custom ETH session and by making the SESST_VOL change i mentioned. I just placed an indicator the plots the previous Days close in the chart and set up a schedule to open it every morning 15 seconds after the ETH session ends just to capture the variable i need, but it does not always update when the chart opens. Even though that kind of works, I still would like to be able to use it with ES,CL and GC just to name a few and they all have different ETH times so I need some kind of work around.
I found a signal on a chart here in the forum that is for Overnight session. Its just.... SESST > 0 . SESST is set as Bars into period for all bars of ON Session. I was wondering if there was a way to just work that signal into the formula above? Or is there some way to write a condition that will use POS to compare times somehow to accomplish what I want?
Thanks,
Dean
Hi Dean,
great question - You are clearly entering the "advanced" phase in terms of RTL token usage and custom indicator design. You gathered all the right puzzle pieces, but you were just missing the very "final" move.
Let's call SESST_BAR the token referring to the bar count (ie "Bars into period") of the current ON session.
To get the developing "imbalance" value (as per your formula) during the ON session (and then keep that value unchanged when the RTH session starts), the following formula should work :
( 100 * (SUM(((SESST_BAR>0)*(PVP_ABOVE - PVP_BELOW)), POS) / SESST_VOL) )
The general trick is to "filter" your Sum expressions (here the PVP data), so that (SESST_BAR>0)*(PVP_ABOVE - PVP_BELOW) is returning zero outside of the ON session
This way, the cumulative SUM operation will continue for the duration of the full session (as POS is set to "Bars from start of (full) Session"), but it will only add zeros because of that filter. At the same time, the SESST_VOL figure won't change anymore (as it stopped accumulating volume from the first bar of the RTH session onwards), so the CI value, corresponding to the final bar of the ON session, should remain unchanged during the RTH session.
I don't know your exact PVP token syntax (it seems that this formula might calculate what is generally referred as the "Overnight inventory") so I am just able to share screenshots below with the typical settings for the SESST_BAR and SESST_VOL tokens.
Let me know if this is the right solution to your question (I didn't have time to test it..)
Cheers
Eddy
Finally got around to implementing the formula you provided me. The indicator works exactly as intended!
Thank you,
Dean
Eddy,
One last thing. Implementing that kind of condition in a custom indicator to capture data during a specific timeframe has been something i have not been able to wrap my head around. In your post you said... "The general trick is to "filter" your Sum expressions (here the PVP data), so that (SESST_BAR>0)*(PVP_ABOVE - PVP_BELOW) is returning zero outside of the ON session".
If im looking at this correctly, filtering in this instance is accomplished by using a statement that returns a boolean condition like (SESST_BAR>0) and then basically multiplying by it like you did here... ((SESST_BAR>0)*(PVP_ABOVE - PVP_BELOW))? Or is that usage only pertinent to SUM like this..
SUM(((SESST_BAR>0)*(PVP_ABOVE - PVP_BELOW)), POS)?
By any chance are there any posts or videos that you know of that are related to this specifically?
Thanks,
Dean
Hi Dean,
The boolean trick works everywhere in RTL (not necessarily inside a SUM statement of a custom indicator). It works in Custom Indicators, Signals, SET statement for trading rules, etc
Let's say, for example, that you want to create a custom indicator that would return
1) the High of the bar if the VPOC value of that bar is up,
2) the Low of the bar if the VPOC value of that bar is constant or down
The syntax of that indicator would be (VPOC>VPOC.1)*HI+(VPOC<=VPOC.1)*LO
you are testing both conditions in 2 boolean statements (VPOC>VPOC.1) & (VPOC<=VPOC.1) and, as only one will be true (ie equal to1), the CI will return the expected HI/LO value.
Cheers
Eddy
Note : to access the VPOC of a given bar, use the VPS token or the MA token and rename it VPOC (the VPOC token doesn't t exist natively..)
Eddy,
Had 3 more questions pertaining to all this. Ive used the boolean trick with success on a few more custom indicators and was wondering if its also possible to get the last value of the ETH session to plot on a DaySession chart? The trick from above wont work on a DaySession chart and i believe thats due to the fact that the boolean condition needs ETH bars to calculate, which the daysession chart obviously does not have. I ended up taking one of the CI's i created that works on a full session chart and i placed it in an MPD set to Full Session thinking that would give me the data but it does not return anything. Can this even be done? If so what am i doing wrong?
After looking at your post again, I realized you mentioned MA and VPS tokens only to retrieve VPOC data. Ive used MA but didnt even know about VPS token. Thank you for that. However, ive been creating my presets using SESST directly in MPD's. Assuming thats also acceptable?
One last thing, I also noticed that SESST has Price choices of Bar, All and Day for VWAP and VPOC. What does each actually return? Ive been using Day for any VPOC's and VWAP's ive made presets for so far and they seem to be correct. I tried using the other 2 choices and am just curious as to what they are returning.
Thanks,
Dean
Great information. I appreciate you clarifying that.
Thanks,
Dean