Skip to main content

PJSUniRenko bars
Do we need another UniRenko indie!? Well, err, one that works. Yes! Here it is

BTW – Please be sure to read down the post for why we needed this, especially if you have been using some of the versions available for public download.

So, why did we need this? Simply put, most of the versions that are in use are broken. Very broken! But, wait? How can they have been broken for all this time and nobody noticed!? I used this slightly modified version for at least a couple of years and did not realise, so… I suspect there are at least 50,000 people using the broken versions. Yes, you read that right. 50k! Based on the download numbers I have seen.

A little background. Anyone who has used the Ninjatrader 8 platform for a while has probably heard of other users talking about chart lag, or maybe experienced it themselves. The problem is that bars can be delayed in printing to the screen, especially during volatility (remember that part, it’s important!). Ninja themselves know about it. In fact, there are very common threads about it and pretty standardised support responses when someone asks about it. I see many people reporting it, especially with UniRenko bars. It’s a fact, people suffer from it, and we assume when someone reports all the symptoms, that’s what it is. I mean, if you are sneezing all the time, you probably have a cold or hay fever, right? In this case, it’s not always so.

I had been suffering a few lags here and there during extreme volatility. This has always pretty much been the case. Now, I go to _extreme_ lengths to ensure my code is clean and performant. Eventually, I get to the stage where I decide, it was just a limitation of the NT8 platform. One of the contributing issues is that I trade small time frames and can have 4,000 bars on-screen on a single chart. Those all have to be re-drawn, etc., 5/6 times a second on each chart, and, when you right and say, Hey, Ninja support, I have 6 screens, 24 charts, 80 indicators, and a gazillion bars, they will pretty much tell you the same. So, we accept it. BUT! … I noticed a peculiarity one day. I was getting filled, in real-time, where the bars had not been printed. IF this were a real lag, the fill would be reported later too! Something does not add up here. I start to dig and after some investigation, I fire off an email to support re my suspicions. They ask me for a video. I send it. They tell me it is chart lag…

Not convinced, or accepting their answer, I pull apart the code and finally find out what is going on after much investigation! As many of you will already know. UniRenko bars (like Renko) are a fixed size. They print a new bar when the fixed size is exceeded. Now, here is where the problem was occurring. During volatility, you can get gaps and large moves where few if any trades will print. Price may actually exceed the size of a bar and this would mean you need to print as many bars as is needed to fill that gap. But, it does not! It will print 1 bar max for each price update. So, you get a 10 pt spike with zero liquidity during FOMC, and it will take the next 10 or 20 trades, or whatever, depending on your brick size, staying WITHIN that next few ticks of bar price range for the bars to actually catch up! LAG! Or, apparent lag, anyways. The solution, change the code to keep looping through bars until it has created enough bars to fill the gap on each single price change. Result – Instant amazement about how much different the PA was. Crisper, faster, cleaner! I am rather embarrassed I lived with this issue for so long!

So, yes, I fixed it, and you can download it for free here. I recommend anyone using the standard UniRenko, especially if you download and used the one from the Ninjatrader Ecosystem, to use this instead. I have left it open source, so the authors of broken versions can see the code changes. At last look, the newest version of the one on the Ecosystem (the buggy one) had been downloaded over 15,000 times, so there are a lot of broken versions out there!

So, there you go. I have no idea how many people have been suffering from ‘chart lag’, and just accepting it, or migrating to other platforms, when all the time, it was this issue that no one had noticed. I am glad to have found the issue, and happy to share the solution with the community. Good trades my friends.


If you run into any issues installing this bar type, you might need to uninstall the old Unirenko type first. I intentionally kept the same bar type ID number, as this is a direct replacement, not a new bar type.


Please see the release notes in the documentation for details of updates


Ninjatrader 8


This software is coffee ware. It is free to download and use, but, if you find it useful, please consider using the link in the app or the link on the right of this page to show the author you care and buy him a coffee. Just 1 coffee ( you can buy more if you want! ) – Or, consider it a beer! That’s not a lot for the time it saved you, is it? Without support, the author will neither maintain this product nor make new ones available publicly. Please be sure to check out some of my other Ninjatrader bits and pieces.  Remember, I’ve got to eat and keep the lights on too! Thanks for your support!


  • Scott says:

    Man, this is amazing. Reading this type of post is like watching F1 Drive to Survive. A lot of info is a small package. And like F1 Drive to Survive, you need to review again and again especially if your having a few beers. Cheers

  • Ball says:

    Really? That portion was missing from Monpere’s original UniRenko? Logic to loop if price gapped was already in RenkoBarsType.cs
    But I appreciate your comments in the code, it’s easy to read what you did.
    For a second, my initial thought was that you bypassed the GetNextSession() call, as it is warned that it is memory intensive, but it usually wouldn’t be called that frequently, unless you had micro periods of sessions.

  • The Matador says:

    I actually took the time to read your post about this today. It explains the lagging video I posted on twitter last week. Thank you Paul – you rock!

  • Ball says:

    Hold Up.
    in your “while” loop, you are re-using the same volume from the OnDataPoint.
    I added a test in that loop, after AddBar
    if (maxExceeded || minExceeded)
    { // set volume to 0 for this gap bar
    volume = 0;

    • pjsmith says:

      Good catch. Thank you. I have updated the download.

      • pjsmith says:

        Am wondering though, if zero volume is the right thing to do, also. I suspect pre-calculating the number of bars required and dividing the NT8 reported bar volume by that amount might be better. I will think about this a bit more! I suspect most people are not affected by either.

        • Ball says:

          I wondered the same. Perhaps it should be a minimum volume of 1, instead of 0.
          In my testing of /NQ Mar 14, I had to use a very low value for barRange, i.e. 2, to view this condition of price change jumping the range limit. Even then, It seemed to only require 1 phantom bar to fill the gap. I have not tried it yet on an FOMC or other major economic event. I will consider the calculation of the gap range, and the required number of bars needed to fill it, to be able to divide the volume from the OnDataPoint event, which would of course change the nature of the While… Loop structure to a for X to Y structure… I’ve also eliminated the if (!calculatedOnce) section, as I felt it was redundant, and I added a condition in “subsequent bars”
          // if on first bar, need to calc Limits from open
          if (bars.Count == 1)
          barHighLimit = barOpen + barRangeLimit;
          barLowLimit = barOpen – barRangeLimit;

          to eliminate the first bar being a flat price range (which in reality may not affect much, it just looks weird).
          I also moved the UpdateBar() before the Range Exceeded conditional test, and changed it to use different logic for the bar High and bar Low valued, (barHighLimitExceeded ? thisClose : barHigh) note I renamed vars for better understanding.

          • pjsmith says:

            At least with zero the overall volume is correct, but zero volume on a bar isn’t right either. The more I think about it, the more I think it should be split. But, I think the best that can be expected is an unperfect solution. Re the instruments. It really does depend on which ones you trade. Some are much thinner than others and if you trade CFD’s, the gaps can be much, much larger. I’ve seen really, really big gaps during news. It was quite comical watching the chart trying to catch up. Thanks for sharing your changes.

  • Miraje says:

    Thanks for the post. Is it possible to make a renko bar that is adjusted to an ATR? So the box size changes according to, for instance, a 14-period ATR on a 1-minute timeframe.

    • pjsmith says:

      Yes, and I did in fact spend quite a bit of time and build one that does _exactly_ that. But, I did not do extensive testing and did not find value in it yet, for me, and my trading.

      • Miraje says:

        That’s very interesting. Can I ask why you didn’t find it as valuable as the Unirenko bars?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: