openinverter forum

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

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

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

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

Awesome. Thank you very much

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.

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!

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?

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!

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?

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!

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.

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