Page 1 of 1

Reverse engineering OEM Hardware

Posted: Sat Mar 23, 2024 10:20 am
by Jacobsmess
Ok I'm breaking this out from my project thread as I'm hoping there might be some useful general guidance for other newbs like me.
I'm jumping in the deep end with trying to reverse engineer a Lexus UX300E BMS and suspect there are simpler systems to reverse engineer to cut your teeth.
So the Lexus UX300E BMS controls everything in the battery pack and it is split into two units. The "Battery Computer Assembly" (BCA) and the "Battery Voltage Sensor" (BVS).
The BVS monitors only the battery module cell taps and the thermistors (33 in the entire pack 3 per module).
The BCA communicates with the BVS then controls the battery heaters, air cooling, coolant solenoids and possibly some other things I can't remember off the top of my head.
The BMS system uses 2 CAN networks, CAN 1 with a lot of CAN IDs and CAN 2 with only 5 IDs.
So far, I've setup an ESP32-S3 with Uhis wifican and using Savvycan, I've been making logs of things.
I've identified CANIDs that appear with the BVS only (by logging can logs of the BCA with and without the BVS connected), this should narrow down the CANIDs that are relevant to the voltage and thermisors of the cells only.
I've then looked at these CANIDs and saved logs of each one that showed a variation in the bytes (or bits?) as I unplugged each cell module as well as any cumulative changes (unplugging several cell modules).
From this I think i've got a god starting point but i'm unsure of where to go next. I guess Identifying the difference between cell voltage readings and cell temperature readings would be a good start. Perhaps I need to remove the thermistor from the cell modules and heat one with a heair dryer or something whilst watching the relevant CANIDs, or I could apply a small charge voltage across the cell modules one by one and observe the change in CANIDs, if doing so, would a benchtop current limited power supply be safe to apply across the 30ishV cell module, I feel like it should be ok but it's worth checking.
Finally, so far I've leaft each cell module disconnected from one another, am I right in doing this or is the BMS likely to want to monitor the difference across the entire pack voltage?
Heres a dropbox link to all the CAN info I've logged so far. https://www.dropbox.com/scl/fo/1u1v28ob ... kw7n9&dl=0
I've looked for Toyota and Lexus CAN DBC/Logs but nothing seems to be useful so far (some of the current CAN logs may have incorrect DBC definitions applied)

Thanks y'all

Re: Reverse engineering OEM Hardware

Posted: Sat Mar 23, 2024 10:33 am
by Jacobsmess
from the CAN IDs so far two seem to be very stable (data does not change at all), would it be save to assume these are some form of handshake/wakeup? if so I might try playing these pack to just the BVS unit and seeing if it starts sending CAN at me as so far when I tried it with just a few powered pins using the wiring diagram I didn't can anything on the CAN lines.

Re: Reverse engineering OEM Hardware

Posted: Sat Mar 23, 2024 1:06 pm
by Jacobsmess
Another thought, is it likely I can just hook up the bench PSU to the BVS cell taps with no cells connected and use this to see what happens at different cell voltages on the CAN or is it likely the BMS will just go into fault mode or something.
I guess the only surefire way of knowing is testing.

Re: Reverse engineering OEM Hardware

Posted: Sat Mar 23, 2024 1:48 pm
by Jacobsmess
What I'm not sure on and what I'm hoping someone might be able to help with is interpreting the values. Are there any rules of thumb? if I find a CANID that responds to voltage changes on a particular cell I can work out the scaling etc. but is it likely that a CANID will contain one cell voltage? multiple volatges? to what resolution? from what I've seen, BMS report differences to mV?
Hopefully this should become clearer as time goes on but any help in understanding and centralising this sort of knowledge would be great.

Re: Reverse engineering OEM Hardware

Posted: Sat Mar 23, 2024 3:03 pm
by tom91
Have a look at some DBC files for variaous decoded BMSes to gain a bit of an understanding what info you would be looking for and how it is organised by other OEMS.

Some explanition on DBC files: https://www.csselectronics.com/pages/ca ... base-intro
CANdb from vector is available as freeware and is a good way of editing and viewing dbc files https://www.vector.com/int/en/download/candb-31-sp3/

A module based example is the VW Egolf can: https://github.com/Tom-evnut/VW-bms/blo ... VWtest.dbc

Nissan Leaf CAN bus, including battery info: https://github.com/dalathegreat/leaf_can_bus_messages
Some various including BMW I3 Logs and dbc files: https://github.com/dalathegreat/EV-CANlogs

Re: Reverse engineering OEM Hardware

Posted: Sat Mar 23, 2024 10:01 pm
by Jacobsmess
tom91 wrote: Sat Mar 23, 2024 3:03 pm Have a look at some DBC files for variaous decoded BMSes to gain a bit of an understanding what info you would be looking for and how it is organised by other OEMS.

Some explanition on DBC files: https://www.csselectronics.com/pages/ca ... base-intro
CANdb from vector is available as freeware and is a good way of editing and viewing dbc files https://www.vector.com/int/en/download/candb-31-sp3/

A module based example is the VW Egolf can: https://github.com/Tom-evnut/VW-bms/blo ... VWtest.dbc

Nissan Leaf CAN bus, including battery info: https://github.com/dalathegreat/leaf_can_bus_messages
Some various including BMW I3 Logs and dbc files: https://github.com/dalathegreat/EV-CANlogs
Thanks, I've gone through a lot of information, some which is currently over my head and I'll have to re-read a few times, other than I understand but am not sure how best to apply it.
My aim is to be able to interpret information from the BMS and then display it and understand the limits of its responses to environmental conditions (the temperature it uses for turning on a cooling fan). I'm not sure there will be a helpful DBC file, I've not found anything so far as I suspect no one else is looking at Toyota/lexus BMS systems from what I've seen so far.
I do have some PIDs for a Prius I will compare with things but as I'm new to CAN I may be misinterpreting what a PID is.
I messed around a bit more today hoping to identify canIDs that changed with conditions (hair dryer on a thermistor) but couldn't find anything specific but feel this simplistic approach might actually be the most fruitful albeit time consuming approach.

Re: Reverse engineering OEM Hardware

Posted: Thu Apr 18, 2024 1:19 pm
by Jacobsmess
So... I'm cross posting this here as it might be a bit more widely read than my project thread....
I managed to blow up the BMS, or at least 7 diodes of the BMS. I'm looking to replace them and I've identified the parameters of the diodes with the help of a friend. The breakdown voltage is 8V and the voltage drop across the diode is 0.78V. the footprint is around 2.2mm (measured with cheap calipers and by eye).
I believe they are zener diodes. Anyone able to advise on what may or may not be a suitable replacement? Is any diode with those rough parameters suitable or is it likely that it'll need to be exact this?
Secondly, is it likely that other parts of the BMS may also be broken? Visually everything except the diodes is fine, given the issue (pop) happened upon plugging in one of the modules that I believe then shorted to the BMS casing via a bus bar, potentially around 300V but I'm not certain. Is it likely other components (ICs?) are also broken?
Thanks

Re: Reverse engineering OEM Hardware

Posted: Thu Apr 18, 2024 1:21 pm
by tom91
If the diodes fail, it means they are outside of their design operational window. Thus any other components on those sense lines will be hit hard by what ever voltage caused that failure.

She if fubar, you never gotten it reverse engineered to a point where you understood what it was saying. So this clearly is a time and money pit.

My advice chuck it in the bin.

Re: Reverse engineering OEM Hardware

Posted: Sun Apr 28, 2024 8:29 am
by RetroZero
@Jacobsmess ,Sorry to hear about your BMS blow up. I am following and not far behind you in the whole Can ID and reverse engineering parts of my build. Thanks for asking the right questions and thanks to all contributing. I have a crocodile clip CAN reader on the way to hopefully speed things up.
I posted a csv file from a log I did on a bench test. Don't know if it's worth anything. download/file.php?id=31050

Re: Reverse engineering OEM Hardware

Posted: Sun Apr 28, 2024 4:33 pm
by RetroZero
Whilst waiting on my 'CanCrocodile', I found some info on CAN Id's. https://hackaday.io/project/6288-can-bu ... ress-found
Could I not use this data in SavvyCan and send it to the instrument cluster I have on my bench? I just want the rpm needle to move a few times to continue testing and understanding this better.

Re: Reverse engineering OEM Hardware

Posted: Wed May 01, 2024 3:40 pm
by RetroZero
Still waiting on that CanCrocodile. In the meantime.....I managed to capture some data and also identify the ID's that switch on lights and command the Rev counter. This is a huge step for me into understanding CAN and the bits and Bytes.
So now what? I'm looking at DBC links from previous posts, but I don't think I understand the subject enough.
Whether we play back messages from a running vehicle, or from a log file with data switching lights and guages, we need to have a DBC file to translate everything.
This file is created by the data we have retrieved whilst, for example playing back a log using SavvyCan.
Do we have to create this manually for each message? Is this the correct sequence and the only route?

Re: Reverse engineering OEM Hardware

Posted: Fri May 03, 2024 3:06 pm
by RetroZero
So, I was too eager to get CAN sniffing and ordered a Crocodile reader for J1708 and not CAN. Back to surfing again.

Re: Reverse engineering OEM Hardware

Posted: Fri May 03, 2024 3:37 pm
by RetroZero
Any suggestions as to a reliable"crocodile" contactless can sniffer/reader. I'm sure there are alternatives to the over the counter solutions.

Re: Reverse engineering OEM Hardware

Posted: Sun May 26, 2024 9:12 pm
by RetroZero
So, I got my CANcrocodile, along with an ESP32-S3-Pico board. My wonderful friend CHATgpt just doesn't seem to be able to dumb things down enough for me to create an interface to use the CANcrocodile to sniff the CAN Bus. Looking for a real person to come to the party...please and thankyou.

Re: Reverse engineering OEM Hardware

Posted: Mon May 27, 2024 12:35 am
by jrbe
You could try Claude / anthropic, usually smarter than chatgpt and usually explains things better.

Re: Reverse engineering OEM Hardware

Posted: Mon May 27, 2024 8:55 pm
by uhi22
RetroZero wrote: Sun May 26, 2024 9:12 pm So, I got my CANcrocodile, along with an ESP32-S3-Pico board. My wonderful friend CHATgpt just doesn't seem to be able to dumb things down enough for me to create an interface to use the CANcrocodile to sniff the CAN Bus.
Did not get the point where you are stuck. Do you have the CAN hardware running and searching for a software? Or do you have savvyCAN already running and looking for the way to connect the hardware? Could you explain/link/foto what is a CANcrocodile and how you intend to use it?

My setup for CAN is: SavvyCAN on windows laptop. As interface I use my wifican https://github.com/uhi22/wifican which is not much more than a ESP32-S3 and a CAN transceiver. This has two lines on the CAN side: CAN-High and CAN-Low, which I connect to the CAN bus. No crocodile here.

Re: Reverse engineering OEM Hardware

Posted: Tue May 28, 2024 5:34 am
by RetroZero
Thanks @uhi22. I'm running your wifican setup. Its working great and I'm mucking about with it to understand things better. I purchased a CANcrododile to read data from working EV's without a physical connection to the can bus. The pickup sensor (crocodile clip) doesn't have an interface, so need to build something.
If I simply connect the crocodile clip to the current wifican setup, I can see that it's reading data, but it's not the same. The attached photo shows a J1708 pickup sensor and the CAN one as well.
Basically, I have savvycan running and would like to connect the new hardware.

Edit. Its now attached

Re: Reverse engineering OEM Hardware

Posted: Tue May 28, 2024 5:57 am
by Jacobsmess
RetroZero wrote: Tue May 28, 2024 5:34 am The attached photo shows a J1708 pickup sensor, but I have the CAN one as well.
There is no attachment

Re: Reverse engineering OEM Hardware

Posted: Tue May 28, 2024 8:11 pm
by RetroZero
It's attached now

Re: Reverse engineering OEM Hardware

Posted: Tue May 28, 2024 8:31 pm
by uhi22
Looks good. Just wire CANH, CANL and ground to the wifican and add a 12V supply. Then clip it to a CAN and show us what you see. What is missing?

Re: Reverse engineering OEM Hardware

Posted: Tue May 28, 2024 8:41 pm
by RetroZero
Will do that tomorrow or the weekend and report back.

Re: Reverse engineering OEM Hardware

Posted: Sat Jun 01, 2024 8:12 pm
by RetroZero
So got,to play around with CanCrocodile today.
From what I understand, in order for the CAN Bus on my instrument cluster setup to function, it requires the ESP32-S3 with wifican and CAN transeiver to be connected - a closed loop. The cluster then sends out CAN data. I see the chassis number passing by on ID 0x65F for example.

I then connected the CanCrocodile CAN-H and CAN-L to the same Can BUS. Added an external 12v and GND.

As soon as it is connected, the Can BUS stops sending data. Chassis number stays on last displayed info.

I then connected the CanCrocodile in parralel (with another CAN transceiver) to the TX and RX lines, as well as the CAH-H and CAN-L. Identicle shutdown of data sending.
Should i be setting up and independant interface to use with the CanCrocodile?