A Low Cost Coulomb Counter

RickInPhoenix

10 µW
Joined
Mar 16, 2021
Messages
5
Location
Phoenix, Arizona
I have developed a Coulomb Counter based on the ATtiny85 system-on-a-chip. The total cost of the electronics is around $10. It has run on my Lectric XP for a few months with good results. I freely give my design to the community: https://rick.sparber.org/eBikeGauge.pdf
 
Welcome to the forum. :)

Your gauge
View attachment eBikeGauge.pdf
is a different take on UI than most, very minimalist, with just the LED flashes to communicate, vs the text/numerics or even GUI that all the others I've used / seen have.

I'm just beginning to figure out arduino to do some stuff that nothing else does yet for my SB Cruiser trike (and future builds), and though I don't need this kind of battery meter because the Cycle Analyst does that for me, I might eventually work out a way to use your basic idea except with an LED that changes color rather than flashing (as with my personal capabilities I would have to stop completely to have time to count flashes, but I could get the gist of battery state with a color along the "rainbow", if it "continously shaded" the color from violet down thru blue, green, yellow, orange, to red. Since I don't like bright point sources, but would need something daylight visible, that is also not too bright while riding in traffic at night, I'd probably use three PWM'd outputs to drive the R, G, and B of a larger-surface-area LED (array?), perhaps a half inch on a side with a diffuse surface, and an analog input to read a light sensor (photoresistor in a voltage divider?) to dim the LED as ambient light also dims. If no analog input is available, then the photoresistor could control an offset of the base voltage to a transistor that controls the current thru the common connection of the RGB LED(s).


Another type of GUI that looks more like the regular battery bars voltage meters common on ebikes use, but is also a coulomb counter similar to yours, is Jeremy Harris' project over here:
https://endless-sphere.com/forums/viewtopic.php?f=2&t=22675
His is a much larger presence on the handlebars, however, than yours.


I also like a number of other ideas and project and helpful guides you have on your site here:
https://rick.sparber.org/ma.html
 
Thank you SO much for your detailed critique.

The story of using only red LEDs is short - my sunglasses block yellow and green.

The readability of the flash sequence is not as simple a story. Since I was the only test subject in the room, I designed something that I found pleasing. I have a simulation mode in my software and plan to put up a YouTube video of the flashing. Normally, it takes about 2 hours to drain my battery during a ride. The simulator compresses this to about 2 minutes. This should give you a better sense of the interface's readability. I hope you watch it and provide me your insights. [see https://www.youtube.com/watch?v=f5i9Q-v4eYM]

As you noted, this is a minimalist design, at least in the hardware. I enjoy using the ATtiny85 but there aren't many interface pins there. I also enjoy using AA batteries but there isn't much available power since I want them to last about a year. I also don't have much space on my handlebars for a readout.

Your suggested interface sound very interesting. I do hope you pursue it and publish your results.

I did look at the LCD battery gauge used by Jeremy Harris but the size, cost, and complexity put me off. It is hard to beat two red LEDs with a resolution of +/- 1/12th of full scale. The "Energy Bar" on my eBike has a resolution of 1/10th of full scale. Of course, it reads volts which can give wildly wrong answers.

I see a lot of commonality with Jeremy's design and certainly like that meter. A major difference is that I let the user define Full and Empty. I can accommodate a wide range of capacities plus the user preference for what they call Empty. My eBike reads out current so I don't have that feature. I also have a few "bells and whistles" including a test of the AA batteries and a failure indication when the EEPROM no longer accepts data. I figure it will wear out in about 7 years. May my eBike last this long.

I have added a few pages explaining my human/machine interface design journey, starting on page 45. I'm sure most will say TMI!

I have a section of my website dedicated to my Lectric XP: https://rick.sparber.org/ma.html#eBike

Peace,

Rick
 
RickInPhoenix said:
The story of using only red LEDs is short - my sunglasses block yellow and green.
I guess that nixes you using the multicolor idea I had above. :lol:

I don't usually wear sunglasses, except the few times I ride when the sun is nearly at the horizon. Before that time, my canopy generally keeps it out of my eyes (my trike isn't really efficient...but it does most of the jobs I need it to ;) ). After that time, I don't need them, and I prefer riding at night because I'm more visible to other road traffic that way, and I look "larger" on the road than I do in the daytime, so I get a wider space given to me in the lane.


The readability of the flash sequence is not as simple a story. Since I was the only test subject in the room, I designed something that I found pleasing. I have a simulation mode in my software and plan to put up a YouTube video of the flashing. Normally, it takes about 2 hours to drain my battery during a ride. The simulator compresses this to about 2 minutes. This should give you a better sense of the interface's readability. I hope you watch it and provide me your insights. [see https://www.youtube.com/watch?v=f5i9Q-v4eYM]
Based on the video, it probably works well enough for anyone that can spare the time / attention to wait for a flash (or sequence) to happen, to find out what the battery state is. Since it works for you, then it does the job it needs to. :)

My guess is it would also work for many others (I wont' say most, because from my experiences here I think that most prefer some graphical format like a segmented bar because it's familiar to them from their phones and other devices...whether the bar represents voltage or actual wh, or something else, they generally don't even seem to care).

For myself, if I'm in traffic (common) I can't often spare a glance down for anything, much less a sustained look, expecially around Metrocenter where I commute and do most of my riding, as I am watching for idiots all around me (pedestrians stepping off the sidewalk directly in front of me without looking, cyclists riding the wrong way in a bike lane, or riding off the sidewalk into the street without looking first, cars moving into my lane where I already am, or accelerating around me to then right hook me to pull into a driveway, cars pulling halfway out of a driveway and stopping, fully across my path so I then have to move out of my lane into the next one to avoid them if traffic allows, or skid to a stop if it's possible (usually not enough distance), etc etc etc. :roll: ).

I even limited the speed on my trike (eventually overrideable with an emergency button or throttle movement) to the 20mph max we have here because I usually can't keep an eye on the speedometer either. If I'm in an area where the speed limit is less than 20, I wont' have that problem so I don't need the limit either. But mostly I'm on 30-45mph roads with traffic.

But for myself, I also don't typically need to know battery remaining, as I have a much larger capacity than I use on any one trip, so that I can if needed do an unplanned long-range trip of 20+ miles, and I recharge about once a week. (I probably use 5-6Ah a day for work commutes).

Anyway...sorry, I'm just rambling again--I waste a lot of time doing that. :)


As you noted, this is a minimalist design, at least in the hardware. I enjoy using the ATtiny85 but there aren't many interface pins there. I also enjoy using AA batteries but there isn't much available power since I want them to last about a year. I also don't have much space on my handlebars for a readout.
There are a number of seriously minimalist bikes around here, that would probably benefit from this type of gauge, for those that need or want one at all. If you're interested, there's a thread for "your creations before and after pics" that features a number of them over the years.



Your suggested interface sound very interesting. I do hope you pursue it and publish your results.
I hope I have time (and remember)...but I have a lot of ideas that never get touched, which is one reason I rattle off a lot of stuff in various threads, so that perhaps someone else that needs that idea will see it and be inspired. :)

I should probably link this thread over in my Nano TidBits thread so I don't forget about it and perhaps eventually work on that after I've completed the necessary goals of that thread. :)


I did look at the LCD battery gauge used by Jeremy Harris but the size, cost, and complexity put me off. It is hard to beat two red LEDs with a resolution of +/- 1/12th of full scale. The "Energy Bar" on my eBike has a resolution of 1/10th of full scale. Of course, it reads volts which can give wildly wrong answers.
I'm sure there are simpler and cheaper ways to implement JH's idea. Myself I like the "analog gauge" style; for certain types of information it's more useful and easier ot interpret at a glance than numbers (which are only really needed for precision), but I would be more likely to make one out of an *actual* analog gauge movement, even though it'd be more complicated and power hungry, if I were to use that type of design. Match the style of my old Simpson 360 multimeter. :lol:

If it matters, there is opensource firmware for a number of systems now, in various threads here on the forum (and their github repositories), some of which is just for displays. I have not looked into them, but I would expect that some of them may have updated the voltage-based bar into a coulomb-counting bar. If not, then as long as there's space for the code, I imagine it shouldn't be too complicated to do at least a basic implementation of that in some of them, for those that already can physically measure watts / amps. (not all of the systems have this info available to the display)


I see a lot of commonality with Jeremy's design and certainly like that meter. A major difference is that I let the user define Full and Empty. I can accommodate a wide range of capacities plus the user preference for what they call Empty. My eBike reads out current so I don't have that feature. I also have a few "bells and whistles" including a test of the AA batteries and a failure indication when the EEPROM no longer accepts data. I figure it will wear out in about 7 years. May my eBike last this long.
The eeprom monitor is unusual; I don't know how the code works in most devices but I don't think I've ever encountered anything short of computer mass storage media that bother. They usually just leave the user to wonder why things aren't working anymore. ;) I hadn't even thought about having anything like that in my devices (realistically I probably wouldn't end up adding it, but it's a handy troubleshooting tool!).

For myself, I prefer to have everything powered by the main bike battery, or the lighting power system, rather than individual batteries. So for my nanos they'll each have a tiny converter from battery voltage to what the nano itself will handle. It's probably less efficient, but I don't generally have to think about things that way. (the lighting battery is separate from the traction primarily because even if I run out of motor power, I don't want to run out of lighting power and be on the way home in the dark, etc).

I have added a few pages explaining my human/machine interface design journey, starting on page 45. I'm sure most will say TMI!
I have a section of my website dedicated to my Lectric XP: https://rick.sparber.org/ma.html#eBike
When I have time and energy, I'll read both of those, as I'm always interested in others' UI needs, experiences, etc.

This is because I've done a lot of beta testing (mostly music creation stuff) in previous decades and found that mostly the programmers and designers of software and hardware are not interested in what an actual user of something needs or wants, they are only interested in imposing their design ideas on their users because they ahve this "cool idea" in their heads and are bound and determined that it is the best thing since sliced bread. :/ Sometimes, they're right. Usually, they're not. But they're in charge of their stuff, not the users.... :( Sometimes a designer or programmer actually listens to user input, but I've found that is not typical. When it is someone designing something just for themselves (like your stuff here), it doesn't matter, but when it's a company designing a product for public sale, it makes a great deal of difference--it's possibly why all of the companies I ever tested things for no longer exist (none of them really listened to any of their testers or end users).

(sorry, I get grumpy about UI stuff; its' probably my biggest sore spot short of customizability)
 
Thanks for your additional insights. Although you are not a good fit for this device, it is helpful to read your objections and think about ways I could address them.

I will update my article this morning with a section on alternate human/machine interfaces.

Rick
 
Thanks for sharing!

Some ideas I would like to share:
1. seems you are not considering the battery internal resistance. At our EBike OpenSource firmware, the user can configure the battery internal resistance and that makes a big difference. An on our hardware and firmware, the system measures automatically the battery resistance for user to validate. I would say the battery SOC estimation can be like -30% if you not consider battery resistance (in our case, our motor can pull almost 1000W, it is very different when using 100W or 1000W from the battery).
Other important thing is the temperature as the resistance can change a LOT with a temperature, like if you ride at 30ºC or at 0ºC.

2. you could use a board with LED and wireless and a very small button battery, we are doing that four our fully wireless EBike remote and the CR2032 battery works for 2 years: https://opensourceebike.github.io/remote/build_remote

ebike_wireless_remote-08.jpg


ebike_wireless_remote-01.jpg


3. this kind of projects are better to stay on GitHub, like this: https://github.com/OpenSourceEBike/TSDZ2_wireless
 
Thanks for your comments.

I know I have a lot to learn about SOC systems. Can you point me to papers that explain how internal resistance impacts Coulomb counting?

I see your wireless remote but did not see a link to the rest of your system. Can you explain the theory behind your SOC strategy?

I will stick my neck out a bit and say that it appears that we have very different goals. My Lectric XP has an "Energy Bar" which reads out voltage. It is only accurate under no load conditions and when the battery is at or below 3/4 full. My goal was to come up with a low cost system that improved on it. I'm not looking for perfect, just better. The cost of the electronics is around 10 USD. I also wanted the circuit to learn the battery with minimal input from the user.

I will be watching my system's accuracy as we head towards summer. Here in Phoenix, it can be 120 degrees F in the shade. If my SOC readings becomes noticeably off, I will do another calibration. My circuit can measure temperature and that would be a software only change so would be well worth the effort as long as it does not require input from the user.

Rick
 
RickInPhoenix said:
Thanks for your comments.

I know I have a lot to learn about SOC systems. Can you point me to papers that explain how internal resistance impacts Coulomb counting?

I see your wireless remote but did not see a link to the rest of your system. Can you explain the theory behind your SOC strategy?

I will stick my neck out a bit and say that it appears that we have very different goals. My Lectric XP has an "Energy Bar" which reads out voltage. It is only accurate under no load conditions and when the battery is at or below 3/4 full. My goal was to come up with a low cost system that improved on it. I'm not looking for perfect, just better. The cost of the electronics is around 10 USD. I also wanted the circuit to learn the battery with minimal input from the user.

I will be watching my system's accuracy as we head towards summer. Here in Phoenix, it can be 120 degrees F in the shade. If my SOC readings becomes noticeably off, I will do another calibration. My circuit can measure temperature and that would be a software only change so would be well worth the effort as long as it does not require input from the user.

Rick
Hmmm, I quick saw your document...and I thought it had to have a current sensor to be a Coulomb counter...

If you can measure the battery current and voltage, then you can measure the voltage drop for a current like 10 amps. If you divide the voltage drop for the current, that is ohms law, and you get the resistance - that is all the resistance include the one from the cables.

We then even calculate and show to user a graph for the Wh energy usage per km - this is very important for range estimation as sometimes we do long days riding and low speed and I limit / configure on the display the max power of like 100 or 75 watts.

About the temperature how do not know the values but let's say you fully discharge your battery while riding at 30 degrees and your systems counts 250Wh. Other day at 0 degrees, it counts like 150Wh, then you make a linear approximation and say that at like 15 degrees the resistance changed to be 1.66 times higher.

I have an electric car for several years now and I know very well that temperature gives a big impact, this is well described for lithium batteries.
 
casainho,

Yes, my system does have a current sensor. I measure the voltage drop across one of the power cables. This lets me manage ampere-hours (Ah). During calibration, the user tells the system when the battery is full and when they feel the battery is empty. This change in ampere-hours is then used to predict the SOC the next time the battery is full. Each time the user fully charges the battery, they tell the system to Initialize. As they ride, the current is measured once per second and is used to decrement the count. The remaining count drives the Ah display.

You described measuring volts and current. This is part of the procedure used to define the battery's Thevenin Equivalent circuit. It does assume linearity which may not be entirely true. You would get an estimate of the Open Circuit Voltage (OCV) and the Equivalent Series Resistance (ESR). If I was managing the SOC via voltage, the OCV would be important. If I was managing delivered energy, then they both would be important. By focusing only on ampere-hours, neither matter. I did find some advanced strategies that use Ah and OCV but they require characterizing the battery first. This is not an option for me. Besides, I don't have access to the battery's voltage.

I will definitely be looking into the effects of temperature on Ah. This would be a very nice improvement in the software. I just have to be sure that the associated error is less than the potential benefit since I will be dealing with nominal values. I can measure the ambient temperature at the end of the calibration ride plus know the ambient temperature while discharging the battery. No other information is available.

Thanks for your insights.

Rick
 
Back
Top