can we replicate BTH data gs450h/prius?... Unlocking the PHEV

[Bigpie]

Any of these captures from HTM from stationary to moving off in EV mode?

[0tik]

Stationary car in a P gear and the battery is charging. It's HTB, not HTM btw.

[Bigpie]

ah, if you're able, would you grab a HTM when going from stationary to driving forward a little?

[0tik]

>Start recording, run to the driver seat, start the car straight away with depressed brake, change gears from P to D, accelerate and brake, switch from D to P, push start button to turn car off, run to the laptop in trunk to turn off recording.

[Bigpie]

Awesome. Thank you very much

[0tik]

I'm suspecting that data speed is faster than 24mhz, given that bit time is 62/42 for 16/24ms/s sampling speed. Also the start pattern makes me think there could be glitches because it's the only place with both channels sending (almost) the same signal at the same time.

[lastphaseofthis]

amazing work! really this is one step closer to simulating the hybrid battery computer and thus achieaving the goals.

I have continue pursuing the other direction keeping the battery ecu and lying to it or modifying its firmware.

this is my 20ah(can do 100a , 150a for 5 second) 70 cell lipofe4 battery. hooking it into the prius this morning and will test mpg and eletric only range, try and see how much SOC it will use of the 20a. i have enough space in the box for 84 cells . 5 vs 6 cells per voltage block, 18.5 vs 21.9v fully charged per voltage block. the computer firmware will have to be modified to use 6 cells, but 5> we are about to find out!

[0tik]

In all honesty it looks like madness. How are you going to get an alarming notification when one of your cells goes under/overvolted? Cant wait to see data log from dr.prius and hybrid assistant app.
Meanwhile here's another log by different kind of a crappy dongle captured by PulseView. 2 sessions differing by trigger up/down hence the missing first 1.6us high state part in "sesja 2" file. Starting sequence makes me thing again that logic 2 knockoff dongle is trash. This parts highlits glitching in logic 2 too.
https://drive.google.com/drive/folders/ ... tW9YKrj4Sf
edit: I started reading about modbus and want to cry and drop all of this to hell. This looks way over my head. How many hours of learning are we talking here?

[lastphaseofthis]

this is my first test, driving out, voltage block 11 looks to be .2 volts lower at times then the rest, so i will charge up the battery by holding the pedals and then see what the difference is at the cell level, by removing the battery and taking off the top and bottom and if one cell is found very off then it gets charged and we will repeat. for now

the test shows 105!

[0tik]

Now it came to me that if you already have the battery on the bench, is it possible for you to open up its brain and trace from which chip the signal lines are coming from?

[lastphaseofthis]

yes, i have already done so, but didnt post the damn pic lol.

edit: oh ya you want the data lines not the voltage block signals. those are in CAN on this prius ecu, but will take out my gs 450h ecu and report back in a few!

[0tik]

Yes. It must be something different than CAN on GS. I edit my findings on the 1st page. Ha! I wish they kept CAN there. Would make all of this hella easier.

[0tik]

Finally some progress. Here are screenshots from osciloscope and new dump from pulseview. It seems I was having loads of signal glitches before. Crappy connections. Although used an option for 1us glitch filter this time. Picture 5 and 6 shows red and green wires. Capture files taken separately obviously. I didn't want to damage capture device. Will do more capturing tomorrow and acquire second probe for the scope. Also important thing - engine was off, so hv battery voltage readings should be kinda stable.

https://drive.google.com/file/d/1GC9-Vn ... sp=sharing

Given bit time asymmetry it seems i'd have to butcher battery ecu and tap between transceiver and the actual IC. Otherwise there's no way to to read this crap. Unless someone figures out which transceiver should be connected for sniffing.

Attached images are green wire first, then red. Red wire is lower voltage.

After powering up this little wireshare transceiver, no signal on any UART side pins. Perhaps it needs a wake up call from another device on UART side.
Funny thing is, After hooking up RS485 side to the car, both signals are shorted to ground (No matter polarity. Switched A and B and same result). If i unplug a single wire, either red or blue, then signal voltage range goes back to normal. There's still 200mv signal between red/green that i have captured. I guess that's enough for car to work since it did so. I have captured them without transcevier connected so +1,8/-1,8 v range.
below is my full folder. "differential 1 24mhz" and "differential 2 24mhz" files are captures with swapped GND/D0.

https://drive.google.com/file/d/1XbyO9z ... sp=sharing

NOW THE MAD PART!!!
- "differential 1 24mhz" 9600baud rate and invert RX gives frame errors... BUT "differential 2 24mhz" at 9600 baud works perfectly, as in not a single frame error across a hundred packets... BUT bit timing is off, like "50/50 kinda random" off. Like literally some bits are less than half of this baud rate. BUT I have compared 3 packets and they have the same amount of data AND a lot of values are the same for all of those 3 packets.

Why i think its mad? Because i have established that the baud rate must be 38400 or 28800 based on previous captures.

Edit: Scratch that boys. We're going places! You know the saying about placing an infinite number of monkeys and infinite number of typewriters in a room? Amazing things are bound to happen. 19200 baudrate with an odd parity bit fits like a glove! Turns out an oscilloscope was unnecessary after all. But I do not regret buying it all. Will be useful when shit hits the (Taiwanese) fan.

Edit: Added a screenshot of different decodings. Perhaps someone notices something at first glance.

Edit: Made proper data gathering. Samples + dr prius screenshots. If this doesn't work, then the next step is to mess physically with temp and voltage sensors to get boundary values. I don't really have a place for this
https://drive.google.com/file/d/1mwW_1t ... sp=sharing

Edit: Another idea - Someone could inject this data stream on a loop to the Hybrid Vehicle Control ECU while having obd dongle with dr. prius running on a phone. Would this show my battery parameters in the app? Or straight away look for CAN PIDs that dr. prius uses to gather data. Buy rs485 dongle for arduino and send data on loop through bth. Listen on can pins of HVC ECU. Although it seems kinda pointless when you don't know which bytes to change to change data.

Edit: https://rs485.com/rs485spec.html This website rules out RS422 by its minimum of 2V signal level. But I don't think it changes anything. I had a talk with an IT guy who encouraged me to make my own UART/rs385 relay with arduino since, as he told, even a monkey could do it with the help of cyber monkey called ChatGPT, before paying someone to write the code for me.

Code: Select all

#include <Arduino.h>

const byte data[] = {
  0x28, 0xD7, 0xFF, 0x6B, 0x6C, 0x00, 0x68, 0x00, 0xFF, 0x00,
  0x6C, 0x6E, 0x48, 0x00, 0x25, 0x7E, 0x29, 0xD6, 0xFF, 0x69,
  0x6B, 0x5D, 0x6A, 0x00, 0xFF, 0x6A, 0x6B, 0x00, 0x68, 0xBF,
  0x66, 0xF4, 0x2A, 0xD5, 0xFF, 0x6C, 0x69, 0x9A, 0x6A, 0x00,
  0xFF, 0x6B, 0x6A, 0xA1, 0x6A, 0x9C, 0xA7, 0xF2, 0x2B, 0xD4,
  0xFF, 0x6B, 0x6A, 0x8A, 0x6A, 0x00, 0xFF, 0x00, 0x6C, 0x00,
  0x48, 0x00, 0x25, 0x9A
};

const int RSE_PIN = 10;
const unsigned long FRAME_DELAY_US = 1019;  // 573 (frame) + 446 (desired delay)
const unsigned long LOOP_DELAY_MS = 9;

void setup() {
  pinMode(RSE_PIN, OUTPUT);
  digitalWrite(RSE_PIN, HIGH); // Always in transmit mode

  Serial1.begin(19200, SERIAL_8O1);  // 8 data bits, Odd parity, 1 stop bit
}

void loop() {
  for (byte b : data) {
    unsigned long t_start = micros();
    Serial1.write(b);
    
    // Wait until full frame duration (573 us) + 446 us inter-frame gap
    while (micros() - t_start < FRAME_DELAY_US) {
      // Busy wait to ensure spacing
    }
  }

  delay(LOOP_DELAY_MS);  // Wait before repeating the whole transmission
}

This code seems to work although timing between bytes varies way more than car's does. Loop delay is even worse as it can be timed only to milliseconds. When trying microseconds, DUE simply ignores loop delay. Voltages of my WaveShare SP3485 dont match car's too. Hope i won't fry anything.

Edit: now look at that. A screenshot from 15.05 data packet sent by Arduino. Sure I still got plenty of DTC errors on the dashboard but most values are legit spoofed. Charging amps sometimes changed for a second to 6.30amps, and voltage did flip sometimes too. I guess byte/bit timing again is to blame. But then other packets give rock solid values even when the engine is running.

Changing any byte makes most values go default. Apart from max chrg and max dchrg, soc, 12v bat. Have to find a checksum to progress.

Picture with 8.6v12 bat corresponds to 12.52 picture. Car even goes into ready with "check hybrid system" message. Engine running. All values stables and nothing changes. Although I'm afraid of damaging my car. Engine sounded odd. Perhaps something to do with real HV voltage being off from truth.

Edit: When exported to 8 column by 12 rows grid, data gives a lot of hints. It is useless for now until checksum is figured out.
Edit: Tried this data set.

38 217 255 105 107 255 105 0 255 107 108 0 104 255 103 215 39 216 255 107 108 87 106 0 255 107 108 213 106 255 232 138 40 215 255 107 108 0 104 0 255 0 108 110 72 0 37 126 41 214 255 105 107 93 106 0 255 106 107 0 104 191 102 244 42 213 255 108 105 154 106 0 255 107 106 161 106 156 167 242 43 212 255 107 106 138 106 0 255 0 108 0 72 0 37 154

11813 byte sum
95+96
lsb+lsb
37+154

value = (MSB * 256) + LSB
= (0x9A * 256) + 0x25
= (154 * 256) + 37
= 39424 + 37
= 39461
way off.

Now I am going to take a break from all of this. My brain is fried. But if you need aa single absurdly big data sniffing log, let me know so i can help.

Resuming the struggle (decimal):
byte 1: counter. rolling over 32, 38, 44, 50, 56
byte 6: always 255
byte 8: always 0
byte 12: always 0
byte 22: always 87
byte 28: always 213
byte 30: always 255
byte 38: always 0 (went 88 at 50%SOC)
byte 40: always 0
byte 42: always 0
byte 46: always 0
byte 56: always 0
byte 60: always 0
byte 72: always 0
byte 88: always 0
byte 92: always 0
byte 94: always 0
Last two bytes are not a checksum because there are packets with equal last 2 bytes but unequal sum of other bytes. There are bytes that were same at first 2 captures and went up in third. Bytes 7, 13, 15, 23, 29, 39, 45, 55, 61, 71, 77, 87. This doesn't make sense since none of the values at the screenshots correspond to this upward change.
To be honest values above might not be invariable since I didn't try making huge changes in real time. Will try to make chatgpt write a script for arduino with the rolling byte code and more strict timing of data stream to make DTC errors go away. But it all seems pointless without having battery on a workbench If any of you have proprietary software that could write graphs from my captured data and would share it privately in exchange for NDA or something, then im up for it.

[0tik]

I was thinking about redacting my previous posts to make is as informative as possible but looking at this sort of a diary gives me perspective on the development and progress of my knowledge and understanding of the topic. (And oh boy how wrong I was about about MANY things )

Now where i am stuck at in tldr way:

So far i can:
-capture (AND READ!) data coming from battery to hybrid ecu.
-send data from arduino to hybrid ecu.

What i need to do next:
- Have a working MiTM device with code that can alter single bytes coming out from battery to hybrid ECU.

My target right now is to make a MiTM device between battery and hybrid (Arduino + chatgpt code). This way one can alter single bytes and see what happens. No need for pulling anything apart. But the problem is that it doesn't work so far. While disconnecting BTH and sending a single message/frame from Arduino kinda works although with DTC codes, it stops working with my MiTM device made out of an Arduino and two Waveshare RS485 Board (3.3V). Arduino's terminal and oscilloscope do not show any signal on TTL/serial side of rs485 board. Im kinda busy lately so that's where my research have stopped.

Device works? Great. Time to alter bytes.
Device doesn't work? Bad. Time to figure out why.

While physically changing battery parameters is one way to decipher BTH data, a working MiTM device would STILL be the next step needed to move forward with this project.

Here's the code for MiTM device. Serial2 RSE pin connected to 3.3v since its always in send mode. Serial1 RSE disconnected since its in listen mode by default. Posting this is probably moot since I believe lack of serial signal/data is unrelated to the software and RS485 transceiver should output a serial signal with just VCC(3.3v),GND,A,B connected.

Code: Select all

void setup() {
  Serial.begin(115200);   // debug
  Serial1.begin(19200);   // RS-485 odbiornik
  Serial2.begin(19200);   // RS-485 nadajnik
}

void loop() {
  if (Serial1.available()) {
    uint8_t byteReceived = Serial1.read();

    Serial.print("Odebrano bajt: ");
    Serial.println(byteReceived, HEX);

    Serial2.write(byteReceived);
  }
}

Update: Connecting rs485 dongle to either battery alone or parallel to the connection drops AB voltage delta from 5v to 250mv. There's no serial output on the dongle. Nothing shows up neither on the oscilloscope, nor in arduino IDE serial monitor. There should be a 3v3v signal that goes from transceiver to arduino . I have tried 2 transceivers without success. I hit a wall here. Perhaps I should add or remove resistors from RS transceiver??? Or it doesn't work because it's 3.3v version and I should buy 5v version... I doubt in both solutions.

[0tik]

Come on guys! I have called a dozen of electronic repair shops and made a few ads on facebook groups but nobody wants to have a look at the car and figure out why RS485/TTL converter isn't working.

[T1Terry]

This is not along the lines of what you are looking for, but I think a valid question anyway ...... How do you plan to balance the 5 or 6 cells that make up the 2 module sample the Prius BMS looks at?

The original NiMh has 6 cells submerged in a bath of KOH that the high cells can boil to allow the low cells to balance using the basic "equalise" method lead acid flooded cell batteries used for all those years in the communication industry.

LFP, NMC and LTO don't have this ability, they are never going to balance using the waste resistor burn off the high cells without using resistors so big you are powering a space heater ....

Induction active balancing does work, but regen is in the hundred amps or so, there is simply no way to shift that sort of charge rate over the short time period it is applied to the battery.

T1 Terry

[0tik]

Simply by using a BMS with build in balancing capabilities.

[maciek16c]

Looks like you have 120 ohm termination on rs485 transceiver, try removing it. I had the same problem when trying to read data using can transceiver connected to uart and after removing it signal amplitude was better. What data can you read? Are you sure it's 19200 baud? When i looked at oscilloscope with decoding function, the best fitting setings were 9600 7N1. There were no uart frame errors and decoding was stable - 96 byte packets.

[0tik]

God damn it all to hell. Another obstacle. Output signal is shorter in time than input signal. Using 120ohmresistor doesn't change nothing. Below is arduino code for Leonardo with two rs485/serial dongles. 45us down to 16us bit time. Although output data seems to be totally wrong. Frame errors and totally different bits and less of them, than on the input side.

Code: Select all

#include <Arduino.h>

void setup() {
  // UART sprzętowy na pinach 0 (RX) i 1 (TX)
  Serial1.begin(19200); // domyślnie 8N1

  // USB Serial dla terminala IDE
  Serial.begin(9600);
  while (!Serial);
  Serial.println("Leonardo uruchomione (RS485/Serial podgląd, 8O1)...");

  // --- Ustawienia UART na 8O1 ---
  UCSR1C = (UCSR1C & ~((1 << UPM11) | (1 << UPM10))) | (1 << UPM11);  
  // UPM11=1, UPM10=0 → parzystość: odd (O), stop bits: 1, data bits: 8
}

void loop() {
  // Jeśli przyszły dane z RS485 (Serial1)
  if (Serial1.available()) {
    byte b = Serial1.read();

    // Pokaż bajt w terminalu IDE
    Serial.print("RX: 0x");
    if (b < 0x10) Serial.print('0');
    Serial.print(b, HEX);
    Serial.print("  (");
    if (b >= 32 && b <= 126) Serial.write(b); // ASCII drukowalne
    else Serial.print('.');
    Serial.println(')');

    // Wyślij odebrany bajt z powrotem (echo)
    Serial1.write(b);
  }
}

[0tik]

Code: Select all

Serial.print("RX: 0x");
    if (b < 0x10) Serial.print('0');
    Serial.print(b, HEX);
    Serial.print("  (");
    if (b >= 32 && b <= 126) Serial.write(b); // ASCII drukowalne
    else Serial.print('.');
    Serial.println(')');

I bet this means only ascii bytes are being forwarded and ChatGPT is playing dumb again as it did obvious mistakes before today. Although i asked about it and chat says its all okay. But that's where i had to end it today. My laptop's battery died and my fingers became numb from the cold. Having a garage with light, heat and electricity is a blessing.

[0tik]

I made it work. But there are still problems. Something about parameters of this signal upsets the car. UART data is proper good. 2 attached pics are a/gnd and b/gnd. Attached .sr is AB output (one acts as GND) from trensceiver. Bridging AB with resistor made signal analyser dead silent/no data at all / car won't start.

[0tik]

Weird. Cant edit my previous post. Probably because I deleted most of it as it became useless.
Anyway. Look at attached uart comparison file. Uart data is not coming out properly through Arduino. Transceiver-arduino works flawlessly. But arduino output on TX pin is ommiting some bytes. Now I have to figure out why.

WHAT IS WRONG WITH ARDUINO AND THE CODE??? Plesae dont kill me with "shitty connections".

Below is code that I am using now.

Code: Select all

#include <Arduino.h>

void setup() {
  // UART sprzętowy na pinach 0 (RX) i 1 (TX)
  Serial1.begin(19200, SERIAL_8O1);  // 8 bitów, odd parity, 1 stop bit
}

void loop() {
  if (Serial1.available()) {
    byte b = Serial1.read();
    Serial1.write(b);  // echo: wyślij bajt z powrotem 1:1
  }
}

[maciek16c]

I built a MITM device using an Arduino Due and two RS-485 transceivers: https://github.com/maciek16c/GS450H-bat ... ngineering
It forwards data from Serial1 to Serial2 without errors and can modify a selected byte by adding a specified value. Unfortunately, there’s probably a checksum — when I add even 1 to some module voltage, the HVECU detects an error.
There are also python scripts for data logging and simple log analysis
To make transmission work i had to add 500us delay between bytes

[0tik]

I had to go with Leonardo because due dont support 5v TTL. Uno don't support 8o1 serial encoding. What exact transceivers are you using? Mine were somehow faulty and I had to go with 5x more expensive and galvanically isolated ones.

Did you try last 2 bytes as a checksum? Can you physically tamper with the battery? If yes then perhaps unplugging temp sensors or a single voltage probe can help a lot in figuring out checksum bytes.

[maciek16c]

I used max485 (cheapest one) and just powered it from 3.3V (it might be below recommended minimum, i haven't checked datasheet, but it works). On receiving one i removed 120 ohm termination. I tried using crc calculator with different algorithms but couldn't find fitting one if crc is in last bytes.
I have no easy access to battery interior and also there is some noise in voltage measurements so there is too much data changing all the time