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)
Using OnMarketData() on Historical data with a recording engine
I think that the optimal setup for GomRecorderIndicators used to write data, is to put them on tick interval charts. There is no need to use writing recorders on any other type of chart than a tick chart. All of my recorders that have write data set to true are on dedicated tick interval recorder charts in one workspace that is not used for anything else, and that runs in the background.
I found that when my recording indicator and data consuming indicator are both on tick charts, I am now getting perfect matches on almost all bars between (buyvolume + sellvolume) and Volume[0]. To get there, I needed to implement RJay's FirstTickOfBar fix for NT7, and also to count the BetwenBidAsk and Unknown ticks, using Gomi's "direction" to determine whether they are buys or sells.
The file created by the GomRecorder needs to be able to be used by data consuming indicators that could be on any type of chart. Charts with intervals of ticks and seconds should work fine. On minute based charts there are some problems due to the lower precision of the time stamps. However you can get around this by using seconds intervals, such as 300 for a 5 minute chart. This forces Ninnie to use the one second time stamps. Gomi pointed this out a long time ago.
With volume interval charts there are problems when a spillover trade with volume of more than one causes the volume counted to go over the nominal interval volume of the chart. Example: We have a 100 volume chart and are up to 98 contracts traded. The next tick has a volume of 25. If all of those are included in the current bar of the volume indicator, it will have a total volume of 123, but Volume [0] will still be 100, as it is for all bars.
The child indicators such as CD, GomDeltaIndicator, etc are where the adjustments should be made on volume based charts, when one trade spills over to the next bar. I don't see how the GomRecorder itself can compensate for this, since it has no way of knowing what kind of chart it will be called upon to supply data to.
When I get around to it I will see if I can code changes to the BuySellVolume indicator and to GomDeltaIndicator to make them work correctly on constant volume charts. I am interested in the GomDeltaIndicator because it is the data source for the GomVolumeLadder, which is often used on volume interval charts.
Regarding range, Renko, etc charts, I don't even want to think about them right now.
I am surprised that type of chart you record on should make a difference. The recorder is based on Market Data events and those are kind of independent of the bar logic in NT. Do you have any specific observations which made you arrive at that conclusion or is it based more on empirical observations about what works and what does not?
I made a small change on the volume ladder to add the last tick to the new bar. I do not mess with the old bar since it does not matter that much.
Assuming that you are asking about the charts that I use for recording: They have an interval of about 100 ticks and only go back about 50 bars, so that they will load fast. To make sure I don't miss anything I usually use the default 24/7 session template.
Before I shut down Ninnie I close all the workspaces except the Recorder workspace. Then it's the only one that loads automagically® when Ninnie restarts.
Then I start up the other workspaces one by one and leave the Recorder one running in the background. The only reason I look at it once in a while is to check that everything is Recording OK.
A good news : I've been working to try to improve the tick engine of the recorder, for now I've been able to get 100% perfect match of Vol[0] as compared to gomi volume, for second charts, tick charts, range charts and volume charts (by splitting volume). I also improved the non-splitting volume chart by sending the ticks a bit differently.
A few charts : first indie is Vol[0], second indie is Volume read from Gom tick engine, and third indie is the diff : so should be 0.
I was also thinking of making the gom interface sensitive to the type of bar being used to work around these last tick issues; it is great you are already attempting it.
One of the biggest challenges with the gom indicators is keeping the tick data base current. I was wondering if you would consider a mode where the recorder uses one file per day of data, instead of one file for the entire history of the instrument.
It would be much easier to maintain a clean tick database; you can just download and save the data from your vendor after midnight, while recording the current data live. This will also allow you to update historical data without shutting off the recorder. The biggest challenge I face is keeping the database current, without shutting off the live recorder.
Ideally the on disk file-structure for that will involve instrument specific sub-folders within the GOMFOLDER directory.
I can pitch in some coding time if that helps, but I do not understand all the nuances of the GomRecorder to do it independently.
I think we still have a problem. I have a CL template with 3 sessions (6:00PM to 9:AM, 9:00AM to 2:30PM, 2:30 PM to 5:15PM EST). Today (Friday) the last day of the week, the recorder stopped sending ticks at 9:00AM when the session rolled over the pit session.
Earlier on, I used to face problems on Monday morning ES (again a 3 session template). I think that is fixed, but the Friday problem remains.
I had the exact same problem with TF and 3 session template. today is the first day that everything is working fine. don't know if it has something to do with NT7 rc1 version. are you using the same version?
