Can you point me to sample code that uses the currentBars1 logic? I am not sure I quite understand how the above snippet would work as future bars are processed. I am currently focused on the historical data case, but eventually will want to handle all 3 cases. In particular, I don't understand how (CurrentBars < currentBars1) could keep evaluating to true on each primary bar. Or does this calculation only apply to the very last bar of the chart?
I found the answer to the above question in Fat Tails' anaOpeningRangeV42MTF indicator. The comparison sign should be reversed so that it looks like this:
I have been struggling for days trying to align my secondary data series with my first. My primary series is a renko, let's say 3 tick for the sake of argument, and my secondary is a 1 tick series. I wish to accumulate volumes on 1 tick data for swings that I plot on the primary series. It worked fine for larger renko bars, but with smaller renko bars there could be situations in fast markets where several renko bars print with the exact same timestamps. This is when my indicator has problems synchronizing with the data computed from tick data series.
I should mention that I am actually using BetterRenko bars with a brick size of 1 as my primary series for this test case, which sometimes prints bricks that are actually 2 ticks tall.
Any help greatly appreciated!
Last edited by ganamide; September 7th, 2015 at 03:27 PM.
Reason: Found answer to first question and clarified use of BetterRenko
Example problem of MTF indicator with BetterRenko bars having same timestamps
I printed out a bunch of statements to figure out how to work around these insane NT 7 MTF bar processing behaviors. Hopefully this could help someone understand the problem, or better yet, maybe someone can suggest a solution!
Primary data series is a 1 tick BetterRenko. This is a custom bar type I got from futures.io (formerly BMT).
Secondary data series is 1 tick (individual trades)
Code is an indicator with CalculateOnBarClose=false
Information is printed to Output window during OnBarUpdate events
Problem Test Case:
A set of 3 BetterRenko bars that all have the same timestamp
Corresponding tick data are 5 individual tick bars all having the same timestamp and volume of 1
Timestamp is 9/4/15 13:47:20 PST, which does not fall on a session boundary
NQ 09-15 contract data from NT historical data server
Output Results in order received in OnBarUpdate:
1. First BetterRenko bar (made from 1 tick)
2. First and only Tick bar of First BetterRenko bar
3. Second BetterRenko bar (made from 2 ticks)
4. First of two Tick bars of Second BetterRenko bar
5. Third BetterRenko bar (made from 2 ticks)
6. Second of two Tick bars of Second BetterRenko bar
7. First of two Tick bars of Third BetterRenko bar (same close and timestamp as previous tick)
8. Second of two Tick bars of Third BetterRenko bar
Hopefully it is clear how this is a problem. I can't be sure if an update on a tick bar is for the BetterRenko bar that came last, or one that came before that one. I suppose I could try to keep track of volume and prices to guess which BetterRenko bar each tick belongs to, but I don't feel confident that approach would work in all cases. Maybe this would work in conjunction with aligning ticks to timestamps, meaning that there seems to be no problem when a new tick has a different time stamp compared to the previous tick. This sort of re-synchs the two data series.
I solved my problem after hours of toiling. In case anyone is interested, I did it by keeping two cumulative volume counts, one for the primary series and one for the secondary series. Whenever I wanted to align calculations made on the secondary series with the primary series, I would check the cumulative volumes to see which primary bar index aligned with the current secondary bar. Depending on the comparison, I would sometimes have to cycle back through the primary bar volumes to get the right index. I also wrote code to cycle forward, but I never needed to go forward more than 1 bar in my testing. At RTH session close, I had to go back 42 bars for alignment!
Now I can get back to the fun part of system development!
The following 2 users say Thank You to ganamide for this post: