Tick chart oddity

[DaveE]

I wrote a simple multi-time indicator to report the number of ticks in a bar.
I expected that when I used this indicator on say a 2 tick chart that I would see a constant 2 output, but in fact the number of ticks in each bar ranges from 1 to about 5!
If I try the default value for NT Tick charts of 150 I see the range is about 137 to 163.
Does anyone have an explanation as to why is not the number of ticks in a "x Tick" chart bar is not a consistant x?

[NinjaTrader_RyanM1]

Hi DaveE,

What is the script you're using for this test?

[DaveE]

Steps to reproduce:
Create indicator BarTickCount
In Variables section:

private int tcount;

In Initialize:

Add(PeriodType.Tick,1);

In OnStartUp:

tcount=0;

In OnBarUpdate:

if (BarsInProgress==1)
{//new tick
tcount++;
}

if (BarsInProgress==0)
{//close of primary bar (that we want to count ticks for)
Value.Set(tcount);
tcount=0;
}

In OnBarUpdate:

Put this indicator on a "1 tick" chart: Result: Constant 1 as expected.
But on "2 tick" chart (or higher) result is variable.
There seems to be a problem in analysing the ticks inside a bar because adding a smaller bar (such as 1 tick here) in an indicator causes the 1 tick bar OnBarUpdate to fire after the tick that closes the primary bar. It would be nice if the programmer could specify the event order, but I dont think NT has provided for this?
So as it stands I think this method will always miss the final tick of the primary bar (which instead goes into stats for next primary bar). But this offset problem should give a consistent error of no more than 1 tick, and should not cause the high variation in tick count between bars.

[NinjaTrader_RyanM1]

To track this in multiseries you'll need COBC = false and real time. The COBC = true bar referencing in a multiseries script just doesn't offer what you need to implement this historically.

To successfully work this in multiseries script, please try with the following changes, and cobc = false.

if (Historical) return;

if (BarsInProgress == 1)
{
tcount++;
Value.Set(tcount);
}

if (BarsInProgress == 0)
{
if (FirstTickOfBar) tcount = 0;
}


The differences in bar referencing historically & cobc true compared to real time & cobc false are detailed here in the section: How Bar Data is Referenced

http://www.ninjatrader.com/support/helpGuides/nt7/multi_time_frame__instruments.htm

[DaveE]

Thanks for the code suggestion Ryan,
But such indicators are not useful to me unless they can run on historical data. NT is storing the full sequence of tick data, so there should be a way to analyse the ticks inside historical longer bars (at least for periods where tick data has been stored).

Putting the indicator to the side for the moment, let me point out something on the tick charts themselves.
Context: Im using tick data from IB, so I assume the NT adds a timestamp to each tick based on my PC datetime (NT seems to round to nearest second)?.
If a open a "1 tick" chart I see each tick in sequence (even if successive ticks have the same time and price). This is as expected.
PROBLEM: If I also add a "2 tick" dataseries (same instrument) to the same chart then the chart is messed up as follows:
Now the sequence of ticks occuring in the same second disapears. They are all shown in the same column (as a vertical line). This means you can now only see separate ticks in the same second if the price was different.
This seems to indicate that currently when two tick dataseries are "matched" in NT, the matching is using "time to the nearest second" instead of the raw tick sequence (which is obviously stored somewhere). I suspect its this "matching by second" that is messing up the events when trying to get tick information inside historical bars.

BTW I understand what the link you sent http://www.ninjatrader.com/support/h...nstruments.htm is saying about "referencing historically & cobc" but the example given in that link assumes the shorter bar is trying to get info from the longer bar. I have not seen an NT example where the primary bar is trying to get information from a shorter added dataseries. Are you saying this is not supported for historical bars in general (or just for historical tick bars)?

[NinjaTrader_RyanM1]

Yes, it seems you have a good handle on how this works. The issue is how bars are referenced in multiseries script, and your resetting mechanism doesn't allow for even splitting. In a 1 tick series you will for sure have bars with the exact same time stamp. So when resetting during BIP = 0, sometimes you have bars over 1000, sometimes less. All ticks are there but resetting on bip = 0 doesn't work. All you have are time stamps, not the exact sequence.

An alternative approach for this to work historically may be to identify the volume of BIP = 0, and reset your value when the accumulated volume on bip 1 = volume of bip 0.

I have not seen an NT example where the primary bar is trying to get information from a shorter added dataseries. Are you saying this is not supported for historical bars in general (or just for historical tick bars)?

This is supported for NT7, and works similarly. Basically, when accessing historically, you can't access added series values when they are time stamped in advance of any other series.