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.

).
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)