GS450h RPM feedback always 0

[Bigpie]

I've got the GS450h inverter/transmission setup in my BMW, with zombieverter, it's driving nice but the speed param is always 0. I added spot params for mg1 rpm and mg2 rpm and these are always 0.
I've attached a capture from a cheap logic analyser driving back and forward a little, if anyone could take a look who knows the sync serial protocol and identify if there rpms are in there or if they're 0?
Thanks

[Zechy]

Hi Jamie

The data seems to be corrupted.

With my cheap logic analyser, it only worked properly if I capture one channel at a time. MTH example below

Syncserial settings:

[Bigpie]

Logs.zip

(4.21 MiB) Downloaded 162 times

Are these any better?

[Bigpie]

Separate.zip

(983.92 KiB) Downloaded 173 times

And separate

[Bigpie]

My picoscope captures look better

[Zechy]

Logs.zipAre these any better?

Still not looking good.
Do you connect MTH- to ground and MTH+ to channel 0 when capturing the data on the analyser?

[Bigpie]

Nope, I had ground to ground and mth+ to channel 0 will try that

[Zechy]

My picoscope captures look better

Sorry. I couldn't figure out how to decode picoscope data.

[uhi22]

Is somewhere an explanation how this communication works (on physical layer and logical layer)?

[Zechy]

Is somewhere an explanation how this communication works (on physical layer and logical layer)?

There is some information here https://openinverter.org/wiki/Toyota_In ... e_Protocol

[Bigpie]

These look a lot better.

[uhi22]

Found this thread,
viewtopic.php?t=205
where they explain the physical layer. One conclusion is to use a CAN transceiver to convert the differential signals to logic level. Then we have 500kBaud async serial with the usual start-data-stop, which should be decodable with the Saleae software.

[Zechy]

These look a lot better.

Looking good

I invert the signal

20240630_forJamie.xlsx

(16.64 MiB) Downloaded 165 times

[Zechy]

To test if the speed is coming into the ZombieVerter correctly, try and write it to the temperature

[Bigpie]

Is that spreadsheet using my data?
That seems to be working mostly, the bus voltage is about x2 what it should be

[Zechy]

Is that spreadsheet using my data?
That seems to be working mostly, the bus voltage is about x2 what it should be

Yes that's your data.

Bus voltage gets divided by 2

[Bigpie]

I've getting my invudc to be 117V in Zombie, which is around 1/3 of the value :S

[Bigpie]

So it seems I have some sort of comms issue.
I've added a counter in as below

Code: Select all

     if(VerifyMTHChecksum(100)==0 || dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF)==0)
        {
            statusInv=0;
        }
        else
        {
            //exchange data and prepare next HTM frame
            dma_clear_interrupt_flags(DMA1, DMA_CHANNEL6, DMA_TCIF);
            statusInv=1;
            dc_bus_voltage=(((mth_data[82]|mth_data[83]<<8)-5)/2);
            temp_inv_water=(mth_data[42]|mth_data[43]<<8);
            temp_inv_inductor=(mth_data[86]|mth_data[87]<<8);
            mg1_speed=mth_data[6]|mth_data[7]<<8;
            mg2_speed=mth_data[31]|mth_data[32]<<8;

            Param::SetInt(Param::mth6, mth_data[6]);
            Param::SetInt(Param::mth7, mth_data[7]);
            Param::SetInt(Param::mth5, mth_data[5]);
            Param::SetInt(Param::mth30, mth_data[30]);
            Param::SetInt(Param::mth31, mth_data[31]);
            Param::SetInt(Param::mth32, mth_data[32]);
            Param::SetInt(Param::mth33, mth_data[33]);
            Param::SetInt(Param::state4Counter, counter);
            if(counter>200)
            {
                counter = 0;
            }
            else
            {
                counter++;
            }

        }

counter seems to work until I engage drive or reverse. The Sync serial lines wires are the OEM harness and not extended. Ive depinned them from zombie and checked the crimps. Checked the inverter grounding.

[uhi22]

To collect the things together I added some links to the different threads here: https://openinverter.org/wiki/Toyota_In ... a_Protocol

To understand what is happening on physical layer I propose to do the following measurements:
1. With osci ground connected to the VCU ground, measure the MTH+ and MTH-, using two osci channels. These should show zero difference in "recessive" mode (most of the time), and a clean difference during the "active" time. The above shown picture contains spikes which should not be there.

image.png (20.61 KiB) Viewed 5932 times

2. With osci ground connected to the VCU ground, measure inside the VCU what the receiver IC made from the differential signal. From the schematic https://github.com/damienmaguire/Stm32- ... ematic.pdf we see that a CAN transceiver is used to convert the differential signal coming on MTH+ and MTH-, to a logic level signal. The logic level side should show the clean serial signal.

Another question is regarding the message validity check. Does the VCU check the CRC of the incoming data, or does it just report what it got, even if it is garbage?

[Bigpie]

There is a checksum performed, as soon as I put the car in to Drive or Reverse the MTH gets messed up

Code: Select all

 case 3:
        if(VerifyMTHChecksum(100)==0 || dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF)==0)
        {
            statusInv=0;
        }
        else
        {
            //exchange data and prepare next HTM frame
            dma_clear_interrupt_flags(DMA1, DMA_CHANNEL6, DMA_TCIF);
            statusInv=1;
            dc_bus_voltage=(((mth_data[82]|mth_data[83]<<8)-5)/2);
            temp_inv_water=(mth_data[42]|mth_data[43]<<8);
            temp_inv_inductor=(mth_data[86]|mth_data[87]<<8);
            mg1_speed=mth_data[6]|mth_data[7]<<8;
            mg2_speed=mth_data[31]|mth_data[32]<<8;
           

I'll do some probing.

[Bigpie]

This is the MTH pairs with a 3rd calculated channel of B-A which seems to do a good job of eliminating the noise.

[Bigpie]

And attached scope to the RX and CAN of the IC

[uhi22]

Indeed, the difference and the digital level looks quite good.

There is a checksum performed, as soon as I put the car in to Drive or Reverse the MTH gets messed up

Indeed, there is a checksum verification, and the code behind makes sense. Even there is a small chance, that totally corrupted data still has the right checksum, I would draw the conclusion: If the checksum is correct, then the data packet is valid. For me this looks like that the data format, which was found by reverse-engineering, is not always used. Maybe your GS450 uses a different format as soon as you are in drive or reverse. So basically starting from scratch, record the MTH data with a logic analyzer while changing the RPM and the voltage, and find which bytes are changing and what is the scaling. Maybe there is a "format identifier" at the beginning of the MTH data, which selects different message layouts.

[tom91]

checksum, I would draw the conclusion: If the checksum is correct, then the data packet is valid.
For me this looks like that the data format, which was found by reverse-engineering, is not always used.

Why would this work for everyone so far? @Jamie please post the part number of your inverter.

From the findings so far it seems that the STM32 is saying the transfer does not complete.

Code: Select all

387         if(VerifyMTHChecksum(100)==0 || dma_get_interrupt_flag(DMA1, DMA_CHANNEL6, DMA_TCIF)==0)

With the checksum check remove it still goes into this if statement to change InvState, thus there is a lower level issue. However reviewing the scope and serial data derived it is just the "standard" GS450h message packets.

Please keep in mind there are many other out there running various Toyota/Lexus inverter without any feedback of a similar issue that was not resolved with tidying wiring, 12V supply and grounds.

[uhi22]

My interpretation of the code:
If checksum is wrong OR dma is not finished
THEN treat inverter data as "Not present"
ELSE take some physical values out of the 100 bytes received data.

So a wrong checksum would lead to stuck values, not to write bullshit into vdc etc.

Means: lowlevel data corruption would be detected and correctly handled from my PoV.