|
Irvine + CA/USA
Experience: Intermediate
Platform: Sierra Chart, NinjaTrader
Trading: ES, ZB, CL
Posts: 4 since Dec 2014
Thanks Given: 6
Thanks Received: 1
|
Hello,
I'm trying to write a NT7 indicator that uses Gomi non-cumulative delta for multiple time frames. I'm getting a discrepancy in the results of the second time frame when it's added as a second bar series than when it's standalone as the primary time frame. e.g. in single time frame case, the bar type is an ES 10-tick range bar, and in the multi-time frame the primary bar is an ES 5-tick range bar and the second is ES 10-tick range. The discrepancy appears to be when the FirstTickOfBar event is issued. Here are some details from logging to illustrate. I'm just referencing the first couple of update events:
Single bar case:
- First GomOnBarUpdate::FirstTickOfBar before any GomOnMarketData
- Second GomOnBarUpdate::FirstTickOfBar at 8/2/2017 3:26:18AM : cumulative delta -1393 after 27843 iterations of GomOnMarketData
Multi bar case:
- First GomOnBarUpdate::FirstTickOfBar for BarsInProgress = 1 after 11 BarsInProgress = 0
- Timestamp is the same, 8/2/2017 3:26:18AM.
- Cumulative delta is -1649 after 27481 iterations of GomOnMarketData. This is the same value as the single bar case at its iteration 27481. But single bar didn't trigger the FirstTickOfBar update until after iteration 27843, by which the delta had become -1393.
I reset the delta in response to FirstTickOfBar after first saving the current accumulated value, so the -1649 would be considered the close of the previous bar. As a sanity test, by iteration 27843 of the multi-bar case, the delta post-reset, i.e. accumulating for the the next bar, is 256. So had it not reset, the delta at that point would have been -1649 + 256 = -1393. This is the same value as the single bar case at that iteration. So the data accumulation is not the issue. It's the syncing of when the FirstTickOfBar events are arriving. For the single bar case it's after 27843 iterations of onMarketData, for the multi-bar case it's after 27481 iterations, and yet both have the same timestamps. Due to this mismatch cuttoffs where the closing delta results are committed are different.
This behavior is the same regardless of the CalculateOnBarClose setting.
An additional note, I've modified the GomRecorderIndicator to allow calling GomOnUpdateDone for all BarsInProgress during this development, as it currently only calls it for BarsInProgress 0. However currently I'm committing the closing values during GomOnUpdate, so I don't think that change should have any bearing. But I haven't looked into this yet.
I posted this question at the Ninjatrader forum but the response I got was that this is a vendor-specific issue since it's based on the Gom framework. I'm hoping someone here might have some insight into this problem.
Is there any way to force the FirstTickOfBar for the second bar series to behave the same as the standalone single bar case?
Alternatively, is there a way to access indicator data from another chart? TradeThePlan.com for instance has an indicator reader, so I'm assuming this should be doable. However i don't know what kind of back door hacking that might have involved.
Thanks for any help,
silverm3170
|
