I have the ignition sw on connection to an arduino which is sending that info through a MCP2515, and I have a USB can analyzer on a linux PC running realdash.
In the can XML is this
<value targetId="167" startbit="7" bitcount="1"></value><!--Ignition ON-->
Watching the can output from the arduino, the can messages on a separate analyzer, anbd watching the can monitor insides Realdash, I never see bit 7 change from a 1 to 0 without me touching the switch. However, I have a text gauge that is displaying Target ID 167 (ignition on) and I will watch it change to 0 then back to 1 for a split second.
I didn’t know if this might be a bug in RD’s reading of canbus, (I am also seeing the same thing on a few other inputs) , of if this might be some sort of problem on the arduino coding. Since I never see that bit bounce on the canbus, I only see it bouncing on the target ID inside realdash, that’s where I’m thinking it’s a bug with realdash, or at least some sort of configuration error inside realdash.
I might have resolved the issue as limiting the canbus transmission to 100ms instead of how ever fast the arduino was sending the messages through the loop of the arduino. This appears to have fixed it as if the canbus module for realdash couldn’t keep up with data coming in.
I might have a similar issue. I am reading some inputs via USB can adapter on Android tablet and sometimes the rpm reading jumps for a moment to maximum. I can’t see for the other readings, because all of them are on/off and it happens very fast. On rpm I see the needle jumping and returning (without car rpm doing any change). Any idea how to fix it?
Very hard to fix unless we would be able to reproduce this on our setups. What we have observed is that if you have a very slow (or very busy) device, something called “frame interleaving” may happen. This is the internal USB buffer filling up faster than it is read, and then there will be CAN frames interleaving each other. While there are quite a bit of code to check this situation it is next to impossible to detect with 100% accuracy.
So if you encounter occasional ‘corrupted’ data on CAN connection, try:
- Measure the resistance on CAN bus to determine the need of terminator resistor.
- On slow devices, simplify your dashboard design to give CPU time for USB data processing.
- Slow down the serial converter baud rate until you no longer experience corrupted frames.