Type C screen navigates without interaction

[morcibacsi]

The screen detects menu navigation buttons even if nothing was pressed. This doesn't happen with Chinese OEM displays.
This symptom appears when using the genuine display. 9664644280 and 9663341780 both failed.

In the following video no buttons were pressed.

Working display:

Not working displays:

[unobayu]

i solve this problem by comment line 570 to 631

[morcibacsi]

So you mean if you remove the reading from the serial port from PSAVanCanBridgeMain.cpp file, the problem goes away?

So you are reffering to this part

// Line 570:
if (inChar == 'm') {
    PrintVanMessageToSerial = !PrintVanMessageToSerial;
}
if (inChar == 'r') {
    vinFlashStorage->Remove();
}
if (inChar == 'V') {
    serialPort->print("VIN: ");
    for (int i = 0; i < 17; ++i)
    {
        serialPort->write(Vin[i]);
    }
    serialPort->println();
}
if (inChar == 'W')
{
    SendRadioButton(CONST_UP_ARROW);
}

...etc
...etc
...etc
...etc

if (inChar == 'T')
{
    //Serial.println("M pressed");

    for (int i = 0; i < 10; ++i)
    {
        tripInfoHandler->TripButtonPress();
    }
} //this is line 632

[gamelaster]

Maybe there is some noise in UART, so accidentally the UART commands get triggered?

[morcibacsi]

Could be... unfortunately in my setup it doesn't get triggered. Also the user who reported this told me that replacing the screen for another one solves the issue which I don't know how solves the noise issue. Anyways... that code can be removed as it was there for an Android app which was never released, so doesn't have any use now.

[unobayu]

yes. i guest reading seial port is the problem. as you know i use my own BT app to control display. so i donot usee bt serialport and remove that line because its not use. but now the problem for display randomly change is dissapear..

[morcibacsi]

So it is not the serial port. Either the display doesn't like dealing with lots of incoming data or something is wrong with the CAN peripheral of the ESP32 (which I don't think is the case as there are display which doesn't have this issue) . There was a similar issue #10 which was resolved by increasing the interval between the trip computer related packets. In 36f50a0 I have introduced some dumb "throttling" on writing the CAN bus and it has been reported that the problem is gone.