First of all, let's keep in mind that the formula for OBV is an infinite cumulative series:
if C>C1, then OBVnew = OBVprev + V
if C<C1, then OBVnew = OBVprev - V
The actual value of OBV depends on where you start in the series - any PCF's you write MUST take this into account.

The MoneyStream formula is proprietary, but is similarly cumulative like the OBV ... so the comments and conclusions below can be applied equally well to it.

The way that OBV is handled in the TC plots, and displayed in the databox, is related to the Zoom factor and the other indicators present on the chart. To demo this, plot OBV on the top pane, in Zoom 5, and turn on the databox to see its value. Now, plot a totally separate 500-day Simple MA of price in the same pane. Voila! The OBV value changes, since, TC starts its OBV series-calc with the OLDEST bar that is required for ANY indicator being displayed at the time - and the addition of the 500dSMA forced the OBV calc to "go back" a lot further.

However, if you check the DIFFERENCE between OBV today and OBV yesterday using the databox, with and without the 500-day Price SMA present, you will find that the two differences are (essentially) equal. There *is* a bug in TC ... the difference SHOULD be exactly equal in magnitude to today's VOLUME ... which it isn't ... but it's close enuf for plotting purposes ... probably some kind of goofy internal roundoff error.

The way that OBV works in PCF's is sort of similar ... but it is not related to the chart. Instead, TC decides what the OLDEST bar required for the PCF is, then calc's the OBV from that value forward. This makes the OBV calc as efficient as possible, btw. To see how this works, create the following PCF and use the Test function to find the internal values:
(Abs(OBV.0-OBV.1) - V) * C0/C0
Note that the Result of this equation will ALWAYS be zero, for any day and for any symbol. OBV.0 is the 1-day SMA of the OBV value, as of today, and OBV.1 is the 1-day SMA of the OBV value, as of yesterday. They are syntactically equivalent to OBV1.0 and OBV1.1

OK, now change that PCF to:
(Abs(OBV.0-OBV.1) - V) * C1/C1
Check the Test values ... the two OBV's are the same. Now try:
(Abs(OBV.0-OBV.1) - V) * C2/C2
Check the Test values ... the two OBV's again are the same. Now try:
(Abs(OBV.0-OBV.1) - V) * C3/C3
Check the Test values ... the two OBV's are DIFFERENT. Why?

In order to calculate OBV.1, TC has to use THREE bars ... it needs to know the C2, C1, C0, V1 and V0 in order to fulfill the demands of the logic. So, for the first three cases, the final Cx/Cx term did not "push back" the earliest required bar ... thus the OBV calc's were the same in all three cases.

However the fourth case, with C3/C3 at the end, forced the OBV calcs to go back one bar earlier since C3 is older. Therefore, V2 was included in the OBV.0 and OBV.1 calc in that formula.

W recommends that any time you work with cumulative indicators such as OBV and MS you should always use a difference vs a prior OBV or MS baseline value ... or (less reliable) divide by that prior baseline value. Although this does work, it sometimes forces the user to morph their formulae to something unnecessarily complex and time-consuming to calc.

Instead of doing that, we can take advantage of the internal calc-rule derived above to force an OBV baseline, without requiring subtraction or division by another OBV or MS value. We can keep the "baseline limit" simple by just multiplying by Cx/Cx, where "x" is at least one bar OLDER than the oldest OBV or MS function in the PCF. Even tho the MS formula is proprietary and I've not been privy to it from W, I've demonstrated to my own satisfaction that MS1.0 relies only on today's and yesterday's values ... therefore, as with OBV, only one extra day "older" is required.

If you want to find the Min or Max OBV during the past 4 days, for instance, you can use the equation:
Min(OBV,4) * C4/C4
Max(OBV,4) * C4/C4
Check it out yourself ... compare the Test results of those PCF's with the values:
OBV*C4/C4, OBV.1*C4/C4, OBV.2*C4/C4, OBV.3*C4/C4
You will find that the Min and the Max value in fact equal one of the individual OBV's during that period.

Alternatively, you could ADD the quantity (C4-C4) instead of multiplying by the quotient ... probably a better longterm solution, since it's less likely to create floating-point or divide-by-zero error in odd casess.

HOWEVER, if you leave out the C4/C4 term, or if you use something less than "4", then the OBV values are not interpreted properly. Keep in mind: Min & Max(OBV,4) look at the last four bars, which requires FIVE bars of info to calc the OBV from. C4 is the FIFTH closing value back, including today (C0).

Now, for a semi-practical application ... let's create an OSCILLATOR that shows what today's OBV is as a percentage of the difference between the Max and Min OBV value of the past 16 days ....
100* (OBV-Min(OBV,16)) / (Max(OBV,16) - Min(OBV,16))
This uses the typical W-recommended method of using differences (for the numerator) ... and relies on the "fixed anchor" method in the denominator. The C16/C16 multiplier is NOT needed.

Let's look at a little bit more interesting example ... find the 1-standard deviation upper Bollinger Band around the 5-day moving average of the OBV. As documented elsewhere, the formula for this upper-BB based on Close is:
AvgC5 + 1 * Sqr( ( ( C*C + C1*C1 + C2*C2 + C3*C3 + C4*C4 ) - 5 * AvgC5*AvgC5 ) / 4 )

If we want to use OBV instead, then we should be able to substitute it in for C:
Avg(OBV,5) + 1 * Sqr( ( ( OBV*OBV + OBV.1*OBV.1 + OBV.2*OBV.2 + OBV.3*OBV.3 + OBV.4*OBV.4 ) - 5 * Avg(OBV,5)*Avg(OBV,5) ) / 4 )

The question is ... will this be a legit value? Answer ... yes, as long as we remember that the OBV values in the formula are all calc'd from five days ago, forward.

Let's write a PCF for the OBV crossing its upper 5,10 BB, so we can compare it to the TC plotted results:
OBV today > its UBB
and
OBV yesterday < its UBB

The full form of that would be:
OBV > Avg(OBV,5) + 1 * Sqr( ( ( OBV*OBV + OBV.1*OBV.1 + OBV.2*OBV.2 + OBV.3*OBV.3 + OBV.4*OBV.4 ) - 5 * Avg(OBV,5)*Avg(OBV,5) ) / 4 )
and
OBV.1 < Avg(OBV.1,5) + 1 * Sqr( ( ( OBV.1*OBV.1 + OBV.2*OBV.2 + OBV.3*OBV.3 + OBV.4*OBV.4 + OBV.5*OBV.5 ) - 5 * Avg(OBV.1,5)*Avg(OBV.1,5) ) / 4 )

Save this PCF, recalc it, and Sort the SP-500 watchlist by it so that the Trues are on top of the list. Now plot the OBV in the top pane, and apply a 5,10 BB child to it. Zoom 9 to see things clearly. Spacebar through the WL ... you will see that the PCF correctly models what is shown on the graph.

Why does this work? The plotted OBV values are much different than the PCF-calc'd values ... we know from the discussion above that the PCF calc's only work with the past six bars, but the plotted values in Zoom 9 are working with something more than 20 bars (W does not reveal how much additional lookback is going on). So ... why does it work?

The answer is, we are comparing apples with apples in each case. We are NOT comparing the PCF value of OBV to the plotted value of the 5,10 BB of OBV ... if we did (try it!), there would be a huge discrepancy. Instead, we are keeping each of the two comparisons internally self-consistent ... the PCF contains its own baseline, and the plot contains its own baseline ... but BOTH of those baselines are long enough to handle the calculation that is being asked of them.

** So what's the big deal, anyways? **

Why write up this long thing to just show that the PCF's work fine?

The problem that sometimes arises is that people take a look at the OBV values in a Test window, or as the result of a value-based OBV PCF, or in the databox for a plotted OBV, and get all (unpleasantly) excited about lack of agreement between them.

Hopefully this long writeup will not only have clearly explained the how's and do's/don'ts of OBV-ing things, but also will have provided a couple of useful indicators along the way.

Have Fun!

Jim Dean