openinverter forum

For anyone building their own version of the Huebner BMS, I've just corrected a couple of errors in the Isolator BoM (RS485 Version). The crystal should be 11.0592MHz and the processor should be an ATMEGA88P.

Also been working on some enclosures for the various modules that can be 3d printed. Here's one for the battery measurement module:

There's a few tweaks then I'll put the stl files somewhere in case anyone wants to make some for their system.

Thats awesome, even got the sine wave on it

Just got started on the CAN isolator software

That's great news. In the meantime, I think there was a plan for a high level linux computer (RPi, beagle board) front end. Is there something available to try out?

I was just wondering, could you do the case "Lego" style? I.e. in a way that you can stack them so you don't need to mount all of them individually. Like some notches that slide into each other on opposite sides.

I had the same thought myself. I'll take a look.

I realised there was a mistake on the Huebner BMS wiring diagram I made. The connections on the 1st isolator module connector JP2 were reversed. Also I swapped the position of JP2 and JP3 on the diagram to match the actual PCB:
I've updated the version earlier in this thread and updated the Wiki page.

Very nice, thanks for updating the wiki also
Right now I designed the CAN isolator with jumpers for address selection and screw clamps for CAN & power. But I'm thinking I should go back to RJ45 for CAN, power and address selection. There is a standard for CAN on RJ45: https://www.opendcc.de/info/can/can_connector.html and it has two free pins.

The reason for screw clamps/crimp connectors was increased robustness. What do you think about RJ45 in a car?

So finally the first 100-batch of slave modules are approaching Europe. Will finish up the CAN isolator and get some made.
So, say in 2 weeks time I can ship out to beta testers.

johu wrote: ↑Wed Nov 27, 2019 9:43 pm The reason for screw clamps/crimp connectors was increased robustness. What do you think about RJ45 in a car?

I am using RJ45 for current measuring/wattmeter module. The thing is you have to support cable about 5cm from the connection port so that it doesnt vibrate/flap around. I had to replace one cable and one socket before i figured how to support.
So if you would setup your socket on one side and then route cable along the board and support it on the other side by a step and plastic tie i think it would be OK.

What I take away from your post is that it's a bit tricky Actually I had some issues with RJ45 in my car, I remember now. Not the connector itself but the solder joint came loose.
I've ordered the the isolators with AMP connectors now.

johu wrote: ↑Sat Nov 30, 2019 7:01 pm What I take away from your post is that it's a bit tricky Actually I had some issues with RJ45 in my car, I remember now. Not the connector itself but the solder joint came loose.
I've ordered the the isolators with AMP connectors now.

Well now that cable is supported and working for like 4 years now. I think spiders are living in my contact box, which is good as i dont have a reason to disturb them. .
Contact box for Peugeot will be a lot denser with all that cable endings... poor spiders will get lost navigating the forest of wires.

What is the status for the first batch? Like I mentioned before, I'm interested in 24 slave modules and 2 isolator modules to use with SimpBMS at 500 kbps baud rate to match my DC/DC converter and charger.

Well, look what came in the mail today
Big shoutout to Patrik and Daniela from Ledaros who made it possible.

Now lies some work ahead. Unfortunately the Zeners fitted to all board need to be replaced by normal diodes as they cause a vampire drain. With that done it's time for software flashing and calibration. Prior to that I need to clean up my desk
I will also send out an isolator. Time to make the first software and wait for the PCBs to show up.

For all testers:
As you can see the cell cables were not manufactured as needed: they have plugs on both sides. Just cut one off. The comms cable is not included as the desired length is unclear. You will need to obtain 3-pole JST connectors. Intemediate modules only have two pins populated, only the first and last module have all three populated with B+ and in or out connected to the isolator.

You can start sending your shipping addresses and an email address via PM

Well done! This is great work!

If there are still some left I would like to test them in my Morris Minor. I would need 14 slave modules and 2 isolator modules.

Running the first tests with the CAN isolator.

It has some glitches but they are easy to fix. The so-called 5V-tolerant pin actually never rises above 3.7V. So when using it as on open-drain driver for the opto, the opto is constantly on. Mitigated this with a series Zener, next version will just not rely on 5V tolerance.

Great work Johannes. Have you got anything to share yet?

Will share the board design soon.
Today I did the calibration firmware. So basically I moved away from having the calibration done externally via Python script. Now a dedicated firmware does the calibration. Basically the board is connected to 4 known voltages whos physical values are known to the firmware. From that it calculates the appropriate gain factors.
The plan is to get some automation going where another Blue pill first flashes the calibration firmware, waits for it to complete and then flashes the application firmware.

Committed an updated version of the BMS slave board. It will now have the programming header populated which should make automated flashing and calibration easier. Also the board position (1st in string or not) is now selected by putting a jumper on the respective pins of the programming header.
I have evaluated many different ways to achieve this:

• Solder bridges: not end user friendly to have to use a soldering iron
• short circuit bridges (i.e. PCB trace that needs to be cut): also not very user friendly
• DIP switch or similar: expensive, lot of board space. Very user friendly
• Jumper: cheap, medium user friendly, might fall off?

So obviously nothing is ideal but I found jumpers to be the best compromise. In a rugged environment it could be glued in place.

Also added the CAN isolator schematic.
https://github.com/jsphuebner/bms-hardware

Have pretty much finalized the calibration procedure so should be able to send boards out in a week or so. Unfortunately they all have Zener fitted that I need to replace by regular diodes. Silly last minute change of mine

This is my programming station: a BeagleBone Green. It's SPI interface is used by a custom avrdude with "linuxspi" driver and the pins are beefed up with a 74F1244 tri-state driver. Shunt references provide the necessary reference voltages for calibration and a button lets you start the calibration and programming procedure, fully automated.

Working together with Andy (sonachan1) we have developed the calibrator as a nice BeagleBone Cape with through hole parts (want to upload some renderings?)
The fact of having this calibrator spawned another simplification: the bit-length-encoded protocol has its root back from the IR communication and the fact that the Attinys RC clock skew is like +/-10%. Not so if you can calibrate it. And the calibrator can calibrate it, thats why it's called the calibrator, haha. That brings it down to +/-1% which is good enough for UART communication. So thats what I did. Soft-UART in the slave modules (10kbaud) and hardware UART in the STM32.
Works great and I hope it will be less susceptible to noise. It certainly raises performance and concerning the slave modules it is a pure software mod.

Here's a screen grab of what we have so far. The boards are on their way from China after Chinese New Year.

Today I finally got around to testing the UART communication in Polo. I used the calibrator only for calibrating the system clock and left the other calibration factors untouched.
The result very much justified switching to a standard protocol. During charging I'm getting real time updates. When driving it depends on the load situation a bit. On high loads I get frequent updates, on lower loads communication still lags, especially on the longer string with 25 modules. Now that I'm writing this I remember the longer string only has 1nF vs. 10nF low pass filter, so that is most probably the culprit. So I'm thinking we will get really good updates rates on the mass produced hardware.

Intro video:

Hi Johannes,

New BMS looks great.

Do you have any plans to incorporate Chademo charging control in the master unit?

This would be a great addition considering CAN bus would be available.

CCS would be great too but this seems a little more difficult and Ethernet based comms?

Thanks for your development effort!

Mike