So a couple of items. At the present moment the tool is IQFEED DDE specific. However, it is built in a way to support any DDE capable data feed. You will just need to specify the syntax. Only two pieces of syntax is required and the 6 setting values for pace. To customize for your datafeed, all you need to do is plug in into cell B12 the DDE syntax for the symbols tick timestamp. For DDE, it is IQLink|'@ESM6'!'T Time' This streams the timestamps of the incoming datafeed. For IQFEED, it is only reads to the current minute as opposed to the current second. For our purposes, it is OK and I have written in code to work around it. So the above DDE syntax is to retrieve the time associated with each tick according to your datafeed service. In B13, you plug in the DDE syntax for the symbols CUMULATIVE VOLUME as opposed to the tick volume. If you plug in the tick volume, this PRV tool will not operate properly. The back end code is generic so as to populate the visuals with what we are interested in seeing PRV (ie. pace). As usual, there is some tuning. This tuning though is done very infrequently. It may change very slowly over the course of seasons. In cells B21 through B26, you plug in the volume settings for each pace. We will need to go into some legwork at how to arrive at values. Some of you may need to update your settings from what you are using. The concepts are exactly the same, but the values have shifted a bit and this primarily due to the increasing amount of volume. For the time being, you can plug in the standard values for the pace and I will go through the set of values I have arrived at; this may include some math that many of you may be uncomfortable with. However, it will also lead to a bunch of opportunities that I believe some of you can start monitoring for... Finally, there is only one other field that is available for your convenience; cell B4. In cell B4 you plug in the fractal you're monitoring. The sheet previously attached is defaulted to the 5M fractal. However, you can modify it to a 10M, 15M, 20M, PiM and the PRV should scale flawlessly. Keep in mind that if you change the FRACTAL value, you will also need to set the pace settings to the values for the given fractal you choose to monitor. As you can see from the sheet, the increments for 5 of the paces is the same within each pace but varies across each pace. As Grob knows, we have to get into the pace issue since it became clear that a bunch of you got glued onto the STR.SQU. What alot of other lurkers who use PRV won't tell you is that PRV is one of the most comforting tools in confirming the strength of a CONTINUATION. As mentioned earlier, when the pace is FAST to REDLINED (as I call it), there is no need to start trading hyperactively. In other words, the direction of the market is being driven and sustained. In other words, contrary to what most traders believe, the greater the pace, the easier it is to maintain being on the right side of the market (ie. hold). Of course, the presumption is that you had previously acted to get to the right side of the market. cont.... MAK
Awesome! I've wondered for a while now: are the volume levels that have described the market paces (which Grob gave many moons ago) constant, or variable and dependent on the total market volume? Open the spreadsheet... and I believe I just got my answer (which I've suspected all along.) You've also provided a good model for me to answer some other questions. If you are taking requests for tools, I could really use a cloning machine, and a tachyon stasis field generator. Obviously I'll gladly collaborate with you on these, but my quantum- and bio- engineering KSE sets are on the micro scale. Thanks for the tool Mak - always raising the bar! Anthony
Using a 5M reference frame, you can see that the current 6 bars are being used. For me, I usually only need the last 2 bars, sometimes 3. So, I usually crop the app to show the last 3 bars on a screen that is to the LEFT of my NOW SCREEN. The layout of that screen is not important so I won't be posting a pic of it. Whatever you use should be sufficient and besides, the focus for the moment is the PRV. For those of you who are new to PRV, I will briefly explain how the monitoring works and it should be relatively simple to get how it is that the tool fits everywhere. As I mentioned above, most of the time I am only concerned with the previous 2 bars. If a stall is present, then 3 bars. The CURRENT (ie. NOW bar) is displayed in column P. Column R is set up conveniently to identify the pace at a glance. I have color-coded the pace settings so as to be intuitive. If I was being logical, the colors would range in the opposite direction since color intensity increases as you go from RED to LIGHT YELLOW. However, because the tool is visual, I have opted for the more intuitive gradiation with respect to pace. The way the tool works is that it performs a realtime PRV that resets every FRACTAL bar length. As you monitor it, you will see that each new bar will run its course and the PRV level will be somewhat noisy during the first few moments of the bar and then level off. This works quite nicely simply because our level of detail is fairly sufficient at a pace level. In other words, usually it takes about 30-90 seconds of the beginning of each bar for the PRV level to settle to the stable pace setting (ie. the projected 5M volume that will result at the end of the bar). So why is this important? Since we deal with PV, we are monitoring whether or not VOLUME is increasing or decreasing w.r.t. the previous bar (ie. CONTINUE/CHANGE; INCR/DECR). This means that as soon as 30sec into a bar, it is easy to do analysis of the relationship of the NOW bar to the previous bar and well, we know how the rest goes logically speaking. Additionally, there is also an immediate form of A/D here which was rather difficult to code and still will require alot more polishing before that can be made available. However, do not expect this tool anytime soon since it currently requires a not so obvious technology interface that most people are not familiar with. In a nutshell, that is the visuals of PRV. I will need to organize the technicals of how to calibrate it on a broad level. You can think of the calibration much like how it is done in the equities paradigm. The calibration technique will be transferrable to any sufficiently liquid instrument. Regards, MAK
I am waiting for the day that we can quantum tunnel large groups of molecules. It would cut down my commute time by many orders of magnitude. In any event, the pace settings listed on the sheet are not tuned. I just punched them in as a rough measure (ie. good enough type of thing). Regards, MAK
Ah yes, and therein lies the rub...... This thing is getting out of hand. I have this awful feeling that other people may be starting to take this stuff seriously. p.s. two rockets today, one small loser, one nice winner.
LOL... Judging from the PM's I get, I doubt it. People are too lazy to go thru the thread... However, yesterday you nailed it right on the head. For alot of things we do, you have to use pairs of items. With rockets, it is necessity to wash when the rocket FAILS. Sometimes what alot newbs don't understand is the whole RICH vs RIGHT. It took me a long time to realize the flaw in gunning to always be right. It is requirement to be right when you use targets, that's for sure. Otherwise the R:R thing doesn't apply. How much profit is in a rocket? As long as the rocket doesn't fail is the answer (ie. HOLD as long as it delivers profits). Out of curiosity, have you paralleled the the levels into NQ? Regards, MAK
Mak "sweet Jesus" back at ya - that is one handsome XLS you posted - it is all encompassing. It is worth a thousand words being able to see what has been described frequently - your summary following same confirms we are on the right track and this in itself is very encouraging. sincere thanks for your efforts and generosity - Grob must be proud. In ref to my logs - apologies - I could have sent you the xls earlier and saved you some time diagnosing the values shown - was waiting a day to make sure it was stable. In any case we look forward to your thoughts on the filter we have in place when you have time. Clearly if it diminishes its usefulness we will change it back to log every occurrence of str/squ. many thanks again for generous efforts IRL
The beauty of the rocket is that you dont have to do a whole lot of thinking. I will often jump the gun a bit on entries but the stoch fastline crossover is a pretty good exit. Most people have a problem with hanging in there so it can help to ignore price and just watch your indicators once you are in. One good rocket will make up for several small losers. I am just observing NQ for the time being.
Will this thing be instantaneous? ie what you see on the DOM is what you get?(All charts lag so it would be great if this didn't).
Tall orders are tall orders. This is why I am sometimes reluctant to post tools simply because things quickly become, "this is a good start but it would be better if ...". Seeing how you have not seen this tool in action, your presumptions are unfounded. DOM and PRV have no direct relationship (albeit there is a very prevalent INdirect relationship). DOM changes are far quicker than tick changes. Unless you are referring to a DOM tool which I had only passed out to Grob, then the answer to your Q is still irrelevant. This is partially due to the fact that most people do not sweep all data simultaneously. However, both tools (PRV & STR.NEUT.SQU) will be as fast as your DDE. If you are using an IB version, you are likely to have as much as a millisecond lead and this is in comparison to BOOKTRADER which is non-snapshot whereas MARKETDEPTH is snapshot. In any event, my recommendation is to just monitor it come Monday. Alternatively, you can just dive into the PRV sheet's code and modify it. If you notice overhead, then go to "calculate" function and reduce the number of events that are triggering the "calculate" function. As you probably already know, the "calculate" function of the DATA sheet is triggered every time a value changes. There are only 2 triggering DDE functions that will fire a "calculate" event. The 2 DDE functions are located in cell "G1" and the second one is located in the last data row of column B. Since "G1" changes and thus triggers a "calculate" event far more frequently than the other cell of column B, you could simply take "G1" and move it to some place on the PRV sheet. You will then need to modify the code to pull down the cumulative volume from the PRV sheet instead of the DATA sheet. However, I have not noticed this performance measure to be necessary. In any event, we still need to get into the pace settings discussion on how to calibrate it for any fractal and instrument. REGARDS, MAK