Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Real thoughts come only after having posted. Everybody knows that it is impossible to think and write at the same time. After all we only have a single conscience.
Can you help answer these questions from other members on NexusFi?
A short note on the OpeningRange V31 and Initial Balance Range Bands V31 Indicators.
There are several NinjaTrader bugs that affect the indicator and occur, when you use it on volume or tick bars with very small periods. The bugs are the consequence of a strange use of NinjaTrader time stamps.
Example:
The RTH session for ES starts at 8:30 Central Time. Let us assume that you use a session template, which allows to separate the night session from the day session. The night session ends at 8:30, the day session starts at 8:30. Now for the time stamps the following applies:
Minute Bars: The bar stamped 8:30:00 AM belongs to the night session.
Tick and Volume bars: The last bar of the night session has the time stamp 8:29:59 or earlier. If there are bars that have the time stamp 8:30:00, they belong to the new session.
This solution is not very useful, but contributes to general confusion.
How do I confuse myself ?
Following the strange decision that some bars time-stamped 8:30:00 belong to the prior, and some bars to the following session, there is a number of bugs affecting NinjaScript methods.
Bug #1: If you apply Bars.Session.GetNextBeginEnd() to bars with a time stamp 0f 8:30:00, it will return the session start for the night session. For minute bars this is correct, but for tick and volume bars timestamped with 8:30:00 this is right away false.
Bug #2: When data is loaded from the cache, and there are several tick or volume bars with a time stamp of 8:30:00, they are all qualified as FirstBarsOfSession, so the condition Bars.FirstBarsOfSession is always reutrned as true. So I have had charts with 10 consecutive first session bars.
Solution
The problem that some bars with the time-stamp 8:30:00 belong to the prior and some to the following session will confuse NinjaTrader developers and NinjaTrader users in the same way. The best idea would be to change this.
Although it is certainly possible to correct the NinjaScript methods Bars.Session.GetNextBeginEnd() and Bars.FirstBarOfSession, this would not help users, who will be confused when they have to apply that strange logic.
Example attached: Same problems appear on Better Renko charts, as they are built from ticks as well.
Since we only offer electronic inbound channels (email, web form and support forum) for support, there is often an initial misconception that we do not provide telephone support. This could not be further from the truth. All inbound inquiries funnel into a centralized help desk system that is managed by a team of twenty plus technical support representatives. It is our policy to resolve inquiries accurately and quickly and each support team member is encouraged to utilize telephone, remote PC login or direct users to private training sessions if they feel that it is required to reach client satisfaction. We implemented this support model early in our existence since we felt it would be the most effective way to administer support to a large, time sensitive user base in an efficient and cost effective manner.
Good observations. The difference you are seeing between minute bars vs. tick/volume bars is actually expected based on how the bars are built though.
A 8:30:00 bar for a minute bar contains information from 8:29:00 to 8:29:59 and is timestamped as 8:30:00. The 8:31 bar contains 8:30:00 to 8:30:59. You can see how it is very distinct in the cutoff point. The 8:30:00 bar actually contains information that is not of the current session. It contains info in the “prior” session or before the session begin.
For a tick/volume chart, because ticks come in at various microseconds which is not shown with the seconds granularity of timestamps, the 8:30:00 AM bar can actually be representing something like 8:30:00.100 to 8:30:00.400. This would still come up as 8:30:00AM, but it actually represents ticks that were after the session begin so it would be applicable for the current session. This is why you see the behavior with Bars.Session.GetNextBeginEnd(). The minute bar of 8:30 does not contain any information for the current session, but the tick bar very well can while both showing the same timestamp due to timestamps only going to the seconds granularity and not more.
For bug #2, this was recently identified and is resolved for our next release, 7.0.1000.5. Please try again in the next release and you should not see it tag multiple bars as FirstBarOfSession off a cache load of your chart.
The bars with the time stamp 8:30:00, which come after the session begin return the session begin of the prior session. So if I apply GetNextBeginEnd() to that new session 8:30:00 bar, it will return yesterday 15:30:00 as the session begin, which is obviously false!
If you have a session rolling from 6:00 day N to 6:00 day N+1, and you ask GetNextBeginEnd at 6:00 day N+1, you will be sent to the session of the previous day N.
To me this is false because as Ray pointed out, ticks timestamped 6:00:00 happen between 6:00:00.000 and 6:00:00.999, so in any case they are posterior to 06:00:00.00 and thus belong to N+1 day.
Ninja timestamps their bars at bar close. Maybe if they timestamped bars at bar open, as Sierra Chart and other platforms do, this issue would be moot.
This is just a rounding issue. A tick bar that closes at 8:30:00:150 (150 milliseconds), will be rounded to 8:30:00:000.
If you use something like 5 tick bars on ES, you can well have 10 consecutive bars that close prior to 8:30:00:500. All these 10 bars will be rounded to 8:30:00. Then with this time stamp, if you call GetNextBegindEnd(), they will all be affected to the old session, although they belong to the new session.
The opening range indicator for example takes the first bar of the session, then determines the session begin time via GetNextBeginEnd(). Then the duration of the opening range duration is added to calculate the end time of the opening range. The bug produces an end time within the prior session, as GetNextBeginEnd() returns the false session. So the opening range is abruptly closed after the first bar, as the duration has already been exceeded.
Only happens to scalpers with a first bar that closes after less than 500 milliseconds after the session open. Never happened to me, so only know this, because I had several complaints.
At any rate, it seem strange to me that (e.g. on a 3 min chart) Ninja's RTH opening bar is stamped 09:33:00 (ET), and Sierra's is stamped 09:30:00, yet all of the ticks inside that bar are timestamped > 09:30:00 and < 09:33:00. Therefore Ninja's 3min bar timestamp is ahead of all of the tick's timestamps within. Wouldn't Ninja's futuristic timestamp be a problem on any timeframe when program calls are made on the bar's timestamp?
