Jump to content

Tach Signal to Cluster Erratic


Recommended Posts

Recently my tachometer in my RX8 has gone rogue. I’ve checked the plugs to the back of the dash and verified the rpm via RealDash on CAN1 to match what Link is broadcasting.

The dash is the OEM Mazda unit and is currently on CAN2 and the CAN outputs pulled from a base file provided here on the forums by Adam. Just 48hours ago the tacho was silky smooth and now it’s very jerky and erratic. At some moments reading 500-800rpms lower while bouncing around. I had to take the frequency to 200hz (was 20hz prior) to get a semi functional Tach again.  

CAN wiring still checks out and is properly twisted and terminated on both ends per standard practice. I’ve verified the signal on CAN2 with my HTG Trans controller that requires an RPM input to function and it matches spot on.

I have a replacement cluster in route as a possible fix if the current one is faulty. The only recent change in terms of CAN was the addition of RealDash but on CAN1 where as the OEM Cluster is on CAN2. 

Anything I might want to put eyes on or double check?

Link to comment
Share on other sites

36 minutes ago, Adamw said:

Not sure it is relevant, but why do you have engine speed added to stream 3?  It looks like Byte 1 is related to fault codes in my notes.

I had to add a multiplier of 4(iirc) to get the Mazda dash matched the the 2JZ rpm. The second output in stream 3 is for the HTG Trans controller which didn’t require a multiplier. Both co-existed prior to this hiccup without fault. I used a previous known hood tune with the same results.

Link to comment
Share on other sites

2 hours ago, Adamw said:

No stream 3 is being sent on ID 1056.  This is for the dash, it controls the coolant temp gauge, oil press gauge, CE light, and charge light.  It shouldnt have RPM in there.   

I believe when I needed to fit a second rpm signal in for the HTG controller I slipped it into the first free 2byte slot I saw. The multiplier needed in 513 for the dash would display 4K idle in HTG software, they lack the ability to scale/offset signals in their software atm I believe. Something I may need to request an adjustment for on their end.

Link to comment
Share on other sites

You usually cant just wack another variable into a message that the dash is expecting - the dash will be expecting specific data in thoose bytes.  In this case Byte 1&2 it is expecting zeros to represent "no faults".  

So If it has been working like that for a while then it possibly isnt your issue and the dash doesnt care but there is definitely potential that some specific combination of values when sent in those bytes upsets the dash.   The quick test would just be to save your map and delete that Eng speed parameter out of that message to see if the tacho behaves any different.  

If that was the problem then it would probably be better to move the GCU to CAN 1 and give it a dedicated stream.

Link to comment
Share on other sites

I’ll give it a shot and report back shortly.

That being the case on stream 2 (513) do you have any notes on what’s expected on bytes 2,3 and 6,7? As I have those assigned for AP Main and MAP currently as inputs to the GCU. Sounds like moving to CAN1 might be the move to make all around as you’ve suggested.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...