Corrupt packages and interference in the bus

[FortunyPT]

Hi!

I've been using this lib for a long time to read the bus messages of my Peugeot 206, but sometimes it causes all the dash lights to go crazy and lose speed and rpm information, and after waiting for a bit, everything starts working again. One thing I noticed is fuel consumption information doesn't get picked up very often on the bus, at least while error-free. My theory is that the message is very long and very easily corrupted most of the time.

I recently upgraded the original clock to a "new" one from another 206 that is also a trip computer, and whenever the ESP8266 is connected and reading packets, fuel consumption info isn't displayed or just freezes in a value, and when I press the stalk button to change or reset the trip it doesn't do anything. When I disconnect the SN65HVD230 and ESP8266 everything works fine as it should but things get funky whenever I connect everything back up.

I tried adding and removing the diodes and the 470 ohm resistor but nothing changed. At this point, I'm considering changing to another bus reader or adding a galvanically isolated 3.3V power supply to see if it makes a difference.

Is there anything that I'm missing in my setup?

[0xCAFEDECAF]

I have used the setup with the SN65HVD230 only once or twice. My current setups (that I have been using for a few years now) are based on the MCP2551 with the level shifter. It seemed the latter was more stable.

I have a 406, and have experienced the vehicle equipment go crazy only once, that was while uploading a new .bin file to the ESP while the CTX wire was connected. Normally the CTX wire is not connected in my vehicle setup. I have also a desk setup, there it is connected and never gives problems. But maybe the vehicle equipment is more sensitive.

Do you have the CTX wire connected? If you do, you may want to disconnect it. It is the yellow wire going from pin D3 on the ESP to pin CTX on the SN65HVD230, resp. pin ASDA on the level shifter to pin CTX on the MCP2551.

Additionally, a pull up or pull down resistor may be needed on the CTX pin of the transceiver module. I think it needs to be pulled down but I'm not sure. I always leave it disconnected and it works fine.

[FortunyPT]

No CTX connected, I'm using only the VanBuxRX object. I forgot to mention that I previously tried the pull-up resistor in the CTX pin, there is no noticeable difference, but I left it there.

Just a few moments ago I removed the 120-ohm resistor of the SN65HVD230 board that is in series with CANH and CANL. With the car off, everything still works fine, but I'll take it for a drive and see if there is any improvement.

I think the SN65HVD230 and MCP2551 aren't all that different apart from the logic level, but one noticeable difference between the dev board with the SN65HVD230 and the dev board with the MCP2551 is the CANH and CANL series resistor. In fact, there are two resistors in the MCP2551 board that are half the value of the one I have on the SN65HVD230, and both are connected to GND via a capacitor on each side of the CAN logic.

I'll try to add those resistors and capacitors to the existing circuit to see if it helps with anything, but given the price of the MCP2551 board, I'll order some as well.

[0xCAFEDECAF]

Sounds good. If you order the MCP2551 board, don't forget to order the level converter as well.

Here is a result found by Googling for "can bus termination":

"the 120Ω resistance can be split into two 60 ohm resistors with a capacitor in between to ground (Typically 4.7uF). This has the benefit of creating a low-pass filter for the common-mode noise on the network."

[morcibacsi]

The 120 Ohms resistor isn't needed on the VAN bus. In fact it is causing issues even with a VAN bus controller (TSS463)

[FortunyPT]

I went for a drive after removing the resistor with every node of the bus turned on to make maximum interference and everything worked flawlessly! Like @morcibacsi said, the 120 Ohm isn't really necessary and, in my case, turned out to be the source of error in the VanBus.

[0xCAFEDECAF]

Thanks @morcibacsi ! I was never aware of that. And thanks @FortunyPT for testing!

I will test this modification in my setup and update the README.md .

[0xCAFEDECAF]

Long time no hear; I guess this ticket can be closed.