Dear all, I recently experienced some interferences between my OVMS module (Lilygo based) and the CAN bus of the car. The car was complaining once in while about problems with certain components. I first thought it might be related to my hardware. Checking some discussions, I realized, that, at least for the Smart EQ, this seems to be a common problem, independent of the used hardware. I traced this down to a crashing firmware (edge version), which leads to a disturbance of CAN1 (ESP32CAN). Actually I emulated a car (Smart EQ) with an Arduino and two CAN interfaces and recorded the bus errors and transmission problems. For this I crashed the firmware intentionally once a minute. The efficiency of occurring errors is pretty high, but not each crash leads to transmission problems. It actually does not help to disable the write access to the bus, since this is only implemented in software. The hardware listen-only mode of the CAN transceiver SN65HVD233 is not implemented yet (see below). In conclusion, CAN1 is inherently sensitive to to a crashing firmware due to the undefined GPIO transients on the ESP32CAN TX pin. What helps, is to switch the transceiver into the listen-only mode (RS pin high). In this case two pins have to conspire to achieve a dominant state on the bus. The MCP2515 based bus is not effected by crashes. I propose to implement the hardware based listen-only mode in case, that the write access is disabled anyway. I implemented this now for the ESP32CAN as well as for the MCP2515 code. See https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3-Lilygo-Suppo... This branch includes only the changes wrt to the switching of the listen-only mode. I will issue a corresponding pull request. In the code for the cars, the can bus mode has to be specified: if (write_is_enabled) RegisterCanBus(busno,CAN_MODE_ACTIVE, speed); else RegisterCanBus(busno,CAN_MODE_LISTEN, speed); In case the config changes: if (write_is_enabled) SetCanbusMode(busno,CAN_MODE_ACTIVE); else SetCanbusMode(busno,CAN_MODE_LISTEN); As an example, I implemented this for vehicle_smarteq in the above repo. Another measure of security would be to shift for newer hardware to a different CAN transceiver chip. I use now the TI TCAN330, which is pin and functionally compatible with the SN65HVD233, but has a feature called DOT (Dominant Time Out), which will return the bus to a recessive state after a few msecs, in case the dominant state is applied for a too long time. Best regards Christian