Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MrBlc]

Hi

So, first off, all homage to skonk's amazing work in this thread: https://www.electricmotorcycleforum.com/boards/index.php?topic=13489.0
It is the springboard that sent me down the rabbithole of building upon his work.
I had several reasons for doing so..
- Hardware - that arduino + 3 layers would never fit my bike within the range of the bike's cable connector.
- More web control
- added support for HomeAssistant

What i made is exactly what i sought out to create.
DISCLAIMER: I used and still use Claude AI as i am NOT as proficient a coder as i would've loved to be. I do however have experience as a project manager and a product developer as well as being an electrical engineer.
I mentioned in the thread i referenced above that i had already made something there. I ended up discarding that one and restarting from (almost) scratch.
So.. I took the header files from skonk's project and restarted a new arduino project using a LilyGo T2-CAN unit as it is both 2 isolated CAN bus transceivers as well as a beefier processing unit.
In addition it handles 12-24VDC input, so i could skip one of the PSU's from that project, keeping this even more lean.

Anyway.. I am _almost_ ready to post my new version. it has taken the better part of my life these past few weeks, but it's finally functioning well enough that I'm doing cosmetic fixes..
So.. Here's some screenshots for you:
First iteration i made.. Quite heavily dependent on AI (but i did like the lowkey design of it):



This one kinda reveals i'm not a native english speaking user.. 





Still..
I went back to the design board rather than relying on adaptations of others.
I wrote myself an overview of functionality, and began building the thing from scratch. (+ those previously mentioned header files)
I built it section by section and bugfixed them as i did before continuing onto the next "module".
It is not "perfect" yet.. But what i have now, supports 1,2,3 and 4 chargers (because i had already controls at home to decide how many chargers to energize)
I made it possible to read the different CAN addresses Elcon chargers have, so it would be possible to get data from all 3, before i figured out they are all set up with the same ID.. As such, it's currently set up to just take the static setting in the screenshots instead and i made that a setting to adjust from HA so i can tie that in to possible automations from HA.
I wanted both coarse and fine adjustment control of the chargespeeds, so the slider seen below adjusts on a per 100w increment. Btw, the slider adjusts to the number of chargers you tell it is available.

And so for the people that think AI just ruins everything:
I have security audited this app and tightened controls and functions to a fairly high level. I know nothing is airtight, but security is not without thought here.

Some screenshots:





Oh, and also.. This platform handles OTA updates so i don't have to go out in the garage with the laptop every time i had to upload a new version (and there were A LOT of versions) as well as doing logging to the web so i could look at debug pointers. stuff i can clean up before publishing..

Next on my roadmap is designing a companion pcb for the bike/psu part for those that don't have the tools to build their own.
I'd also like to make a pilot signal pcb/module so it conforms to that part too, but that would require a lot of designing, so it's not first on my list..

[zerodog]

Way to go!

[MrBlc]

Thanks?

I am looking for testers although it does seem to work stable on my bike.
My biggest issue right now is wifi coverage in the garage.
Documentation also has some way to go.. I have tried to make it as user friendly as possible while retaining a certain level of security, but having intimate knowledge of the inner workings blinds me for alternative ways to perceive it.
+ there's a certain threshold to technical know-how when it comes to connecting this all together electrically.
I want to solve that by designing a PCB, and have barely started working on that, but i am not well versed in automotive connectors and i need to find one with at least 8 pins + screen for good termination. (as well as it being fairly waterproof)
If i didn't have to take into account for water ingress and vibrations, i would've just used a U/FTP patch cord and RJ-45, but although the cable would fare well, the connector would not.
Fortunately i will be attending a fair in a few weeks where i have some contacts in the world of industrial connectors. i plan on talking with them there to see if they have any good suggestions. Pricing and availability is also key points in regards to this. They have to be easy to source as i have no plans to setup production/distribution on this myself..

[T.S. Zarathustra]

That user interface and options look awesome.
Nothing wrong in getting help from AI, it is constantly improving.
Norwegian? I have some friends in Haugesund.
I'd love to have a look at your documentation. Documentation is a large part of my current job.
Does your controller 'speak' I2C or UART. If so you can use one twisted pair for short distance communications instead of eight wires. Could be hardwired if you don't intend to disconnect them often.

[MrBlc]

Thanks
I have been to Haugesund. It's far away from where i am, but a very nice (yet windy) city.

Apart from what i wrote in the Readme on the github page, i haven't written much documentation apart from what is commented in the code.

There was no need to do I2C or UART on this.. The link i have is for transferring DC Power and CAN bus data.. There's also a few pins in reserve for some future plans i have.
I was aiming for a connector setup because i am still developing the PCB, and i know i would want to extend its functionality from DC+CAN bus to also do EVSE charge pilot signal processing. - and then be able to just do a swap-out type of upgrade. keeping it easy for the user to choose/upgrade..

[MrBlc]

FYI: This has not been vibecoded and forgotten..
There is a reason why i haven't updated here lately... I'm still tweaking and testing things. This is also why i haven't published the url to the firmware yet.. This development takes a lot of time (time i don't really have). But.. It is usable at its stage today. I'd say about 90% ready. The controller is now able to manage the charge cycle to preset stages and balance out the process at either 79, 80, 90 or 100% with a cell deviance down to single digit mV. (Best i have seen so far was 3 mV)

I am currently seeing some issues at 100% that i'm working on, but the other 3 stages works quite well.
OTA updates are also signed (you have to set the key before compiling) and the portal is locked behind user/pass you the owner defines. I'm going at this with security and stability in mind and it is showing promise so far.

If there are features you'd be looking for in a controller like this, i am open to suggestions.
I am fortunately more able to chat during daytime than i am working on this unit, so lets start talking. 

[Specter]

mrblc don't worry too much about a few mv for charge / balance as at those levels, half an amp charge current which is nothing in these proportions we use it, can send it skittering quite a bit,  you'll end up chasing your tail all day trying to control it.  think about it you have a 8 ah cell, and are dribbling 25 ma to top if off, how many weeks will that take

good job so far on it though.  the more stuff we have to keep our bikes running, the better off we are as a community overall, especially, as we have seen sadly too many times,  oem's go bye bye real fast at times.

aaron

[MrBlc]

Thank you Specter.

I take it you're referring to the 100% section i wrote about.
It's actually not the mA's left to cram into the batteries that is the issue there. It's the way it behaves. ..And since i am a sucker for a good UX, i tend to drill down into those kind of issues..
The charge mode works in 3 (4) modes; bulk, absorption, float and complete. Keywords well familiar in the world of solar.
At the top, the charging process tapers off naturally, and as it stands right now, it never goes from "bulk" stage to any other stage, meaning it's the BMS taking care of it all. I prefer to have better control. The BMS is the fallback protective device (in my eyes at least).
I have been noodling some ideas i will test out whenever i am back at the computer at home to change this. I want to make this controller into something that both works as on-the-go and as a set-it-and-forget-it type of system for when it's at home.

Today i got to test it on a Easee chargerobot, and that gave me a new list of bugs to tackle, so.. yeah.. fun times!

[Specter]

remember lithium batteries don't float, thats a good way to tear them up.  lead acid loves a trickle current, lith, no.   also you dont need to balance very tightly each time you charge lith either.  a week of 20 to 80 then on saturdays, top it off and balance, as an example will work very well on them.  most manus recommend a 20 80 run for the longevity of the battery. worry about balance when you get to 50 to 100 mv of inbalance or so. although some people like to keep it around 20.  having the larger span wont hurt a thing if you are running them in the 20 80 area, but can get problematic if you frequently run em past those boundries, as when a battery does swing out, its voltages swing fast and hard well into the damage area.

aaron

[T.S. Zarathustra]

UX is one of the most important features of any project (I frequently bore people with explanations of Norman-doors and DOET . What I've seen of this project so far is excellent. Someone once said that the last 10% of any project takes 90% of the time. Hopefully yours is closer to 99% finished.

[MrBlc]

Considering the annoyance of these bugs, it definitely feels like lower to me. But that just proves the 10/90 importance of UX work.
Since today is the gf's birthday, i got to knock down the most important one.  (she does NOT like to have my attention the entire day, so leaving her the rest of the house and vanish into the office for some time is a net positive) 

The process of charging stages does actually take this into account. Apart from the stage of "complete" if forgotten to its own devices, the stage it will spend most time in is by far the bulk stage.
I have tried to explain this in a little more detail in the accompanying manual.. At any rate, the "float" stage will never exceed 1 hour and it consists of shutting off the chargers and letting the battery rest.
The idea of having a "complete" stage rather than making "float" being the one, is so i can use MQTT to signal to HA "you can shut off the chargers power supply now. we are completely finished". + it makes for a good UX. If you see "complete" you know for sure nothing is actively working with something.
Weirdly, making this charge process is one of the things i spent the least amount of time on, but still gave so much to the result of what it does..