I’m getting some dropouts (going to zero) and spikes (less common but random high readings) showing up on my coolant temp gauge.
Temp readings are being sent from my Link ECU to the Seeedstudio Can Analyzer. I logged the CAN Monitor in Realdash and see the dropouts there, but when I log with the Seeedstudio application, I don’t see any. I also don’t see any dropouts when logging directly on the Link either.
It only seems to be happening on the coolant temp and nothing else.
Any suggestions?
What baud rate you are running the CAN adapter? Lowering the baud rate may help if your device is working on its limits.
But what I don’t understand is why it doesn’t show up in the log using the Seeedstudio software, only the “can monitor” in Realdash.
Dropouts and spikes in data are usually caused by dropped/incomplete/interleaving frames in data stream. All CAN software has some kind of method to detect and discard this invalid data. It could be that RealDash is not handling these situations well enough in your scenario.
This also happens on arduino, but it is extremely rare! The speed is 2,000,000 baud!
I added a new CAN channel just for the coolant temp and that seems to solve the problem (even though I don’t like the solution). The old coolant temp is still on the CAN, I’m just not pulling from the old one. So I’ve actually increased traffic. I did not try lowering the baud yet.
It should be noted that the original coolant temp that I have problems with is in a Composite ID format.
The composite id system is not that well tested, as it was added quite recently. I will take a look if I can find something on that.
Thanks for looking into it. I will say everything else seems to be working fine on the composite ID. I’m pretty happy with it. My setup is a little bit unique because the can is communicating between my AiM PDM and my link ECU, and I plan to run the real dash remotely over LTE as a pit telemetry monitor. So I’m trying to use as much from the CAN already without introducing new channels.
It could be that Realdash in a coincidence finds the Composite ID value in the same Frame ID, so it takes whatever value is in front, I’ve seen that happen.