Alternative to voltage table

[biell]

This issue is in relation to the development branch renewed_squashedchanges_reporting3.

I recommend updating the use of Chi's table in https://github.com/OnewheelCommunityEdition/OWCE_App/blob/ebc3b549e24e4ceb3b6add40d9c786b5db39b264/OWCE/OWCE/Converters/BatteryVoltageConverter.cs#L13-L30 with a formula capable of turning any voltage into a reliable battery percent. I also think this formula, which differs slightly sometimes from the table, is more accurate:

             99.9
    -----------------------   -  9
    0.8 + 1.28^(54-voltage)

You can see my formula graphed against the Chi and JW tables here: https://docs.google.com/spreadsheets/d/e/2PACX-1vRgvPnKWKoAIzlZRZNHjioP0K4lhBsjdK1Zt53t6K9rvzW6l2g2RnwV4AeIifzPlVxJso9RfYfwlf9V/pubchart?oid=1488611128&format=interactive to see for yourself how it compares.

[beeradmoore]

Hey @biell , is the formula you listed one that Chi created elsewhere or did you make that?

I very much like the idea of a formula for simplicty, however in the back of my head I still have this thought of, what if we want a different graph per battery pack. EG. We could have a list of turtles that match Chi better, and match JW better. Then when you say you use an external battery it will have the correct curve, all without having to make the formula.

I am not knowledgable enough in the area of batteries to know if stock, chi, jw, home made, all would use the same battery curve or not. If you could fill me in on that it would be great.

I guess worse case scenario even if we were to use an equation we could just have multiple equations. Also at the end of the day, either option is better than the current solution, which is no option.

[biell]

Thank you, @beeradmoore . I developed this formula b/c the table supplied by Chi makes no sense. The table supplied by JW is actually more accurate, IMO, and it is a straight line (which is not how batteries work either). I reached out to Bara, and they developed the Chi table after multiple tests, but I think the multiple tests all led them back to the same location, which I strongly believe is at the bottom of a hill. If you look at the graph of their table, it makes no sense based on how batteries work, to have such a long slow drop off at the end like that. A battery would follow a curved discharge similar to the one I have presented. How it looks against a time or mileage axis is dependent heavily on hills and terrain. On a treadmill, voltage would follow a curve like mine.

I added a similar formula to pOnewheel ( https://github.com/ponewheel/android-ponewheel/blob/master/app/src/main/java/net/kwatts/powtools/util/Battery.java ) and Onewave ( https://github.com/biell/Onewave/blob/battery_mods/app/src/main/java/com/nanowheel/nanoux/nanowheel/util/Battery.java ) for my Two-X. I worked on it for months and tuned it so was it is relatively accurate even when riding at 10MPH. I also made a bunch of mistakes, so I am not suggesting we replicate my old method. But some concepts are worth looking into (e.g. a decay algorithm to normalize voltage while riding and accounting for Amp draw). I got it tuned for a Plus, but never got around to tuning for an XR. That said, I did base my current formula on that one. The LiFePO4 batteries in a Plus are different than the NMC batteries in an XR, and the Plus provides a number of unique challenges. Mostly, the LiFePO4 batteries spend like 75% of their life within 2 volts of nominal, and so the equation hast to be REALLY accurate. The NMC drain is more gradual, and therefore more forgiving.

The formula for a Plus vs a Plus with a Two-X should be similar, but slightly different. The formula for Chi and a JW should be identical, as they are basically the same product with the same cell count and Watt Hour rating. A stock XR should have a similar formula to the one I have listed, but maybe a slight change. The Pint and Quart should also be similar.

I don't know about VNR, but I think this just wouldn't work for CNR. I don't know what a voltage curve would look like for CNR, but I imagine it would hang out over 60v for a really long time, then follow a normal curve after that.

Someone can make suggestions about my formula, any tweaking is welcomed. But, I think using a formula is way better than a table. However, as you mention, keeping a table option around for people to manually input when there isn't a formula ready to use may be a good idea as a backup.

[biell]

I have gathered a little more data, and I think the following slight modification is a better equation. The lines are almost indistinguishable, but this one is a little more level around nominal, and drops off faster at the lower voltages.

         99.9
-----------------------   -  10
0.8 + 1.29^(54-voltage)

When my CBXR broke and ran off my stock battery, this line looked to be close; however, I didn't get enough data to say it is as accurate as it is for a CBXR/JWXR. If the CBXR/JWXR and stock XR can use the same equation, then it is possible a Pint, Quart, and Pint X could all have the same equation.

If this were added to the app, the best way to improve these equations over time would be for the app to log some key data and have an option to upload that data so it could be combined with other rider's data to tweek the equations.

[beeradmoore]

I like the idea of storing this data for analysis.

So is 54 and 10 specific to nominal/max voltage? From memory some of the boards have different voltage packs (GT I know for sure does) so should this equation work for them or what are the key pieces to be changeable?

[biell]

The 54 is absolutely for nominal. The 10 started out as 9, and yes 54+9=63. But, after you are close, you have to start tweaking and do whatever it takes to match what you are seeing in real-world usage.

The equation is relatively normalized, for example, this is the equation for a Plus with a Two-X battery (different cells, LiFePO4, with different nominal voltage) that I have been working on for a really long time which is relatively accurate while riding about 10MPH against a decaying average of voltage. I would need to redo this for a static, not-in-use OW to be accurate. Back when I did it, I was heavily focused on trying to make it work while in motion. Technically, this is the equation I used below 51.7 volts, I used a slightly different one above. Mostly that has to do with the way LiFePO4 batteries work and how much time they spend near nominal (from 90% to 10% they are within 1 volt of nominal).

        99.9
--------------------  +  1
1 + 7^(51.7-voltage)

At the very least, we would need a different equation for each battery Serial layout (OG/Plus, XR, Pint, GT). It is possible we would need one for each supported Serial and Parallel layout (OG/Plus 16s1p, OG/Plus Two-X 16s2p, XR15s2p, CBXR/JWXR 15s3p, Pint/Quart 15s1p, Pint X 15s2p [I think this is correct], GT 18s2p). If different Cell sizes matter (which they may), then the Pint and Quart would need a different equation. I have no idea how CNR, VNR, etc. would affect the equation.

The first priorities would be CBXR/JWXR and Quart since they are the hands down favorite. Two-X, CB+, etc. would go second based on what data we could collect from actual users unless we learned enough about VNR to find out that there was something to be done.

[Colbey]

Has there been any builds or branches with this included yet? Just put a Quart in a Pint and was going to be doing a CBXR or JWXR in an XR soon. Riding along and watching voltage instead of percentage made me wonder if this particular feature was already somewhere in the app and I had just not found it yet.

[biell]

This equation is built into Owie, so if you wanted to go crazy and install an Owie chip during your battery upgrade, then OWCE and all apps (including FM's app) would report a mostly correct %remaining whenever you stop riding for a few seconds.

[Colbey]

Ahh, I guess that is why the switch is disabled in my app currently. Thanks for letting me know!

[beeradmoore]

There are some branches on other forks that people have done which has this built in. Other people have gone and done it with formulas similar to what @biell mentioned above.

Overall position though is voltage sag gives inaccurate battery reading. So within the same minute you may look at it while riding, while going uphill, while going downhill, when you have just stopped and maybe when you have stopped and been off board for 30seconds, all could report different battery %. Off by how much? I've been told as low as +/-1% and up around +/-10%

1% inaccurate is acceptable, 10% is not. So then the difficult part of the problem isn't converting voltage to battery %, its how do you let the user know that the battery % you are seeing is correct vs an estimate.

I think the general idea is we need to be able to record ride data from various people with various boards and various batteries so we can replay it through the app and see what happens to the numbers in all different scenarios. Replaying through the app is currently in and functional, recording data is in and functional, but both are pretty much in developer mode. Cleaning up the ability for users to record rides and export that data is what I am working on today.

We are getting there, but (unfortunately slow) baby steps.

[Colbey]

No worries man, the app is an amazing piece of work as it is, nicely done! I have only done native app dev stuff so still getting my feet wet with the xamarin thing but I intend to mess around a little bit. Thanks for the update and thanks for the app in general! Here to help however I can so cant wait for the recording of rides and such to make it into the app as a whole.

[biell]

Overall position though is voltage sag gives inaccurate battery reading.

I was able to smooth this out in pOnewheel and Onewave for Plus's with battery mods by using a combination of decaying averages and amp usage corrections, but I was never able to make it fully stable. I got very accurate at either stopped or a constant speed on flat terrain. But, I was never able to fix it up enough for hills. The nice thing about a Plus is that it provides access to all the data. Newer XRs and Pints provide limited data back to the app, which could make things harder.

Ultimately, I used these methods as my backup, and used Amp Hour counting as my primary method, when conditions allowed.

[Ryan526]

Overall position though is voltage sag gives inaccurate battery reading.

I was able to smooth this out in pOnewheel and Onewave for Plus's with battery mods by using a combination of decaying averages and amp usage corrections, but I was never able to make it fully stable. I got very accurate at either stopped or a constant speed on flat terrain. But, I was never able to fix it up enough for hills. The nice thing about a Plus is that it provides access to all the data. Newer XRs and Pints provide limited data back to the app, which could make things harder.

Ultimately, I used these methods as my backup, and used Amp Hour counting as my primary method, when conditions allowed.

Speaking for myself I'm not at all concerned about having to step off my onewheel to see an accurate battery percentage. I just want to ditch the need to reference a voltage chart.

Is there a repository I can bring into visual studio and build a .apk that has support for quarts/jwfm battery's?

[Colbey]

Is there a repository I can bring into visual studio and build a .apk that has support for quarts/jwfm battery's?

not sure if its been included yet and I need to clean up my stuff and its probalby out of date, but i have a working demo using @biell's code on my fork of this. shows the reported and adjusted values on the phone and apple watch. not sure if there is an android watch version yet. its in its own branch at https://github.com/Colbey/OWCE_App/tree/Chi-battery-voltage-percentage-display the left is the "OneWheel" value and the right is the "adjusted by the chart" value

[biell]

@Colbey that is not my code. I opened this issue to document a better method than using a table. A single equation can provide a much more accurate %remaining than a table. The above equations assume that AmpHour draw equates to usage; however that isn't really the case as you need to drain more amps as the voltage goes down to achieve the same watts. I haven't fully perfected it, but my current working equation which takes into account the ratio of amps to voltage is:

                    99.9
-----------------------------------------   -  10
(0.93 + 1.26^(54-voltage)) * (54/voltage)

[Colbey]

Ahh ok, thats what it was. Sorry to confuse, it has been a while since I messed with that build so forgot the whole backstory and did not re-read this entire thread before answering. That code was enough to get me what I was looking for anyway.