So again for this post I’m going to concentrate on one specific aspect of the RX8 CANbus system which a few people have asked me about and that’s making the ODOmeter on the cluster tick up correctly without the factory PCM (ECU) being fitted to the car. This also allows the trip A and B meters to work correctly as they are all linked to the same register.
I’ve mentioned in previously to people that the odo requires a state change to update and I think this is why people haven’t been able to identify what controls it – simply writing a value doesn’t do anything. It is controlled via byte 1 of what I defined as statusMIL, this is CAN ID 0x420 which is the same ID which also controls things like the temperature and oil pressure displays on the dash.
I originally identified how this was controlled during some of my early reverse engineering work on the cluster when I was just sending blocks of values (initially cycling between 00 and FF for all bytes in the array) to CAN ID’s to see if I could make anything happen and I noticed at some stage the trip had increased. Clearly this meant one of the ID’s was doing something and because the same ID also controls various warning lights they also flashed on and off at the same time as the odo incremented which made the identification of the ID rather simple.
Next up I edited the program to count each byte in the CAN data up in order, so for example start with an array with only 00 in each byte then starting at byte 0 increment the value by 1, send the whole array, wait briefly and increment again and so on. When the top value of FF is reached set it back to 00 step on to byte 1 and so on. This allowed me to isolate the specific byte that was controlling the odo changes. Anyway the story goes on and after a lot of trial and error with values and timings I got to this bit of fairly horrible test code:
#include <mcp_can.h>
//#include <mcp_can_dfs.h> //Declaration for Standard Can
#include "mcp2515_can.h" //Declaration for Seeedstudio Can Library
#define CANint 7 // Normally 2
#define LED2 23 // Normally 8
#define LED3 0 // Normally 7
#define NOP __asm__ ("nop\n\t")
const int SPI_CS_PIN = 17;
mcp2515_can CAN0(SPI_CS_PIN); // Declaration for Seeedstudio library
//MCP_CAN CAN0(SPI_CS_PIN); // Set CS to pin 10 - Older Library version
void setup() {
Serial.begin(115200);
delay(1000); //delay to allow for monitor
Serial.println("Init…");
Serial.println("Setup pins");
pinMode(LED2, OUTPUT);
pinMode(SS, OUTPUT);
pinMode(LED3, OUTPUT);
pinMode(CANint, INPUT);
Serial.println("CAN init:");
if (CAN0.begin(CAN_500KBPS) == CAN_OK)
{
Serial.println("OK!");
}
else
{
Serial.println("fail :-(");
while (1)
{
Serial.println("Zzz… ");
delay(1000);
}
}
Serial.println("Good to go!");
}
unsigned char statusPCM[8] = {125,0,0,0,156,0,0,0}; // Write to 201
unsigned char statusMIL[8] = {140,0,0,0,1,0,0,0}; // Write to 420
void loop()
{
unsigned int i=0;
unsigned int j=0;
unsigned int k=0;
float mile=0;
unsigned char num;
//Warning Lights - 0=Error, 1=OK
for(k=0;k<200;k++)
{
for(i=0;i<=206;i++)
{
statusPCM[0] = 50; //RPM Value*67 gives 8500 RPM Reading Redline is 127
statusPCM[1] = 0;
statusPCM[2] = 0;
statusPCM[3] = 0;
statusPCM[4] = 93; //Speed Value=0.63*(Speed)+38.5
statusPCM[5] = 0;
statusPCM[6] = 0;
statusPCM[7] = 0;
statusMIL[0] = 145; // Temp 91-0%; 96-10%; 107-25%; 152=50%; 158-75%; 164=100%
statusMIL[1] = i; // Odo / Trip
statusMIL[2] = 0;
statusMIL[3] = 0;
statusMIL[4] = 1; // Oil Pressure (0=Off, >=1 is OK)
statusMIL[5] = 0; // Check Engine Light
statusMIL[6] = 0; // Battery Charge Light
statusMIL[7] = 0;
CAN0.sendMsgBuf(0x420, 0, 8, statusMIL);
delay(20);
CAN0.sendMsgBuf(0x201, 0, 8, statusPCM);
delay(20);
}
Serial.println("Miles : ");
mile=(k+1)*0.05;
Serial.println(mile);
}
while(1){}
}
Basically much of it is the includes and setup which is common on all CAN code but the more interesting bit is the main loop. In essence it just uses two nested loops to count up to a certain value and transmit the new value each time. All the other CAN is just static values to turn off warning lights on the cluster – the the ID 201 isn’t actually required here but it stops extra things blinking at you! Additionally ignore the comments on the statusPCM, while these sort of work I realised later that the speed and RPM use 2 byte blocks rather than a single byte to display all values.
So in the code there are 2 loops, the first is counter “i” which in this counts up to 206 (which is 207 steps including 0) and the second outer loop “k” which counts up to 200 and for each increment of “i” the new byte value is sent over CAN. Now through experimenting with various values for counters in earlier versions of this code I’d come up with the values you see here which seem to be consistently accurate for me. Basically 207 changes of the byte sent to the dash = 0.05 Miles counted so the extra loop “k” multiplies this up to a useful mileage change we can measure on the cluster. every time “k” increments it also sends and update to the serial monitor so we can keep track of it. We can see that 200 loops of 0.05 miles should result in a count of 10 miles and that’s exactly what we get on the trip meter.
The very last line is one you don’t see in many Arduino programs, “while(1){};” makes the program hang at this step. Basically what it’s doing is a normal while loop except using a static 1 as the condition makes it always true but there’s no code in the curly brackets so it will just sit there endlessly doing nothing rather than starting the main loop again as it would normally. This was simply so I could leave the code running to completion (at this stage I was sending CAN data with much wider time delays than needed to make sure none got missed) without it looping back round without me noticing.
So now we can count it up which is interesting but not especially useful as it is but since my car didn’t move I left it here for a long time with the plan to sort it out later. Anyway following my recent posts resurrecting this project there’s been some interest in how to sort it out so I started working on it within my already butchered about derivative of Dave Blackhursts code, which in itself was a further development of much of my earlier work. I’m aiming to post a version of my finalised code for the complete system once I’m happy I’ve got all the features I want but this should give you enough info to understand how this bit works.
Updates by Timer1 Interrupt
First off lets just say this didn’t work quite right for this task so I moved away from timer interrupts but it does include some interesting bits of timer manipulation so I’m including it anyway.
The best idea I had initially was to use the data from the ABS system which gave an accurate speed for all the wheels individually but the problem was I would need to vary the frequency at which the ODO byte was changed such that the ODO rate matched the speed. My first idea here was to use a hardware timer on the Arduino and use a hardware interrupt to increment and send the CAN packet. This would require the timer count value to be calculated on the fly from the ABS data. First I built and Excel spreadsheet which firstly calculated the frequency we need to update and send CAN data at to give the right ODO reading for a given wheel speed.
So all this does is some basic calculation,
Pulses per mile * mph = pulses per hour
pulses per hour / 3600 = Hz (updates per second)
1000 / Hz = Millisecond interval per update (used to cross reference from the CAN logger)
From this we can fiddle about with values to see what gives enough range on timer1 (because it’s 16 bit which gives us a much wider range of intervals, timer 0 is only 8 bit and usually used elsewhere in the Arduino IDE) to make this work, or for that matter if it even is possible without dynamically changing the pre-scaler value.
Timer 1 is controlled primarily by register OCR1A which is the value it counts to before the timer resets so we need to work out the correct value for the register to do what we want. Rearranging the standard equation gives us this:
OCR1A = (( Clock_Freq / Required_Freq ) / Prescale ) – 1
Now because the count is a 16 bit integer there will be some error created by rounding on the count value so I added another section which updates to show the error vs the required value.
The top two lines are just the standard calculation the middle two lines are where the clock and prescaler values are entered and the OCR1A value is calculated. The 230 and 1.15 come from the previous step automatically. The bottom two lines then return the degree of error resulting.
It looks like we can cover the range we want with a prescaler of 1024 however as the speed goes down below 1mph the period between CAN sends becomes excessively long and beyond the range of the timer (max value of OCR1A is 65535), the limit is approximately 0.21 mph which seems reasonable. This means only 1 update over CAN every 4.1s which it turns out is about the limit anyway because if you make the updates longer than about 4.5s for this ID all the warning lights turn on again between updates but we can handle this case seperately.
Now to get the timer working we need to set up a few other things
We want to use CTC mode resets the count value at the top of the count to make it loop round constantly so WGM12(CTC1) in register TCCR1B should be set to 1.
Next to get the prescaler value of 1024 we need we set CS12 and CS10 to 1. Lastly OCIE1A in TIMSK1 needs to be set to 1 to trigger the interrupt every time the count reaches the count value set bring it all together and we get something like this :
void setupTimer1() {
noInterrupts();
// Clear registers
TCCR1A = 0;
TCCR1B = 0;
TCNT1 = 0;
// Freq (Hz) (Clock (Hz) /((OCR1A + 1) * Prescaler))
OCR1A = 64700;
// Set CTC mode - trigger interrupt on TOP
TCCR1B |= (1 << WGM12);
// Prescaler 1024
TCCR1B |= (1 << CS12) | (1 << CS10);
// Output Compare Match A Interrupt Enable
TIMSK1 |= (1 << OCIE1A);
// Enable Interrupts
interrupts();
}
// Send update to cluster on interrupt
ISR(TIMER1_COMPA_vect) {
// Increment ODO byte each time function is called
// this makes ODO update based on ISR frequency call.
// Check speed is > 0.21 mph ( (left+right/2) * 0.337962 * 100
if ( (frontLeft + frontRight) >= 68){
send420[1]++;
}
CAN0.sendMsgBuf(0x420, 0, 7, send420);
return;
}
Next up to convert from a speed to a timer count value we need to do the same thing on the Arduino that we did in Excel earlier so here’s a quick function which just calculates count.
int calcTimer1Count(float speedKMH){
float freq;
int count;
float speedMPH;
//Serial.print("speed = ");
//Serial.println(speedKMH);
speedMPH = speedKMH / 160.934;
// Required frequency for timer 1 ISR
// 1.15 is 4140 (Pulse per Mile) / 3600 (1hr in seconds)
// 0.7146 is 2572.5 (pulse per KM) / 3600
freq = speedMPH * 1.15;
//Serial.print("freq = ");
//Serial.println(freq);
// Required OCR1A value based on 16Mhz clock, works best with 1024x prescaler giving minimum 0.21mph
count = ((16000000 / freq) / 1024) - 1;
//Serial.print("count = ");
//Serial.println(count);
return count;
}
The input here is km/h because that’s what the ABS values are given in so we might as well convert that here as well.
Now in the main loop we’re scanning for incoming data on CAN and checking what the ID is already for the bits to manage the immobiliser exchange and handily in this Dave Blackhurst has already added code to read the ABS data which we know is coming in on ID 4B0 in two byte blocks so we can just update OCR1A with a function call to our new calculation function with the average of the front wheel speeds whenever new ABS data is received.
if(ID == 0x4B0) {
frontLeft = (buf[0] * 256) + buf[1] - 10000;
frontRight = (buf[2] * 256) + buf[3] - 10000;
rearLeft = (buf[4] * 256) + buf[5] - 10000;
rearRight = (buf[6] * 256) + buf[7] - 10000;
//Going to check front wheel speeds for any issues, ignoring the rears due to problems created by wheelspin
if (frontLeft - frontRight > 500 || frontLeft - frontRight < -500) { //more than 5kph difference in wheel speed
checkEngineMIL = 1; //light up engine warning light and set speed to zero
vehicleSpeed = 0;
} else {
vehicleSpeed = (((frontLeft + frontRight) / 2) / 100); //Get average of front two wheels.
}
//Update timer count value with live speed for ODO
OCR1A = calcTimer1Count((frontLeft + frontRight) / 2);
// Dump speed to serial for debug - this is just a cropped int.
//Serial.println(vehicleSpeed);
}
Now when I ran the whole program I hit a minor issue, it worked initially and the timer speed changed correctly but after a small number of can packets the Arduino stopped sending any other CAN data. I don’t know what caused it – best guess is when the interrupt was called it was blocking something and causing a buffer overrun somewhere else making the Arduino crash but either way I felt a different approach would probably be quicker than solving that so I moved on.
Updates by Delay
So the alternate approach relies on the main loop running quite quickly and simply counts how much time has elapsed since a function was last called and if over the set value calls the function. This basically allows functions to be called in the loop without needing to slow the loop itself down. The down side here vs interrupts is the accuracy of this is entirely based on the speed of the main loop so if the loop slows down the events will move about in time. Also obviously if the loop is only doing something like 10ms per iteration you will never get something to go faster than that!
void loop() {
//Send information on the CanBus every 100ms to avoid spamming the system.
if(millis() - lastRefreshTime >= 100) {
lastRefreshTime += 100;
sendOnTenth();
}
So this is the initial version Dave used in his code to keep the scanning at a decent pace for the CAN reads. The function millis() just returns a counter value in milliseconds since startup. Unfortunately scanning at millisecond rates isn’t going to cut it for the ODO because at say 200mph the update period is 4.35ms so if we work in ms the best we could do assuming the loop ran fast enough is 5ms which means the ODO would be going 15% slower than the vehicle speed. Luckily Arduino also has a similar built in function ‘micros()’ which does the same thing but counts in microseconds. Some of you familiar with binary might be thinking an integer counting up in microseconds will hit its limit very quickly and then it is likely to cause a problem with the calculation however we get round this because the returned value is of type ‘unsigned long’ which gives us a range of up to about 70 minutes before the count resets. Interestingly because of the way data types wrap round like this the variable “lastRefreshTime” can actually be either signed or unsigned and it works the same.
long calcMicrosecODO(float speedKMH){
long uS;
float freq;
float speedMPH;
Serial.print("Speed = ");
Serial.print(speedKMH/100);
Serial.println(" km/h");
speedMPH = speedKMH / 160.934;
// Required frequency for timer 1 ISR
// 1.15 is 4140 (Pulse per Mile) / 3600 (1hr in seconds)
// 0.7146 is 2572.5 (pulse per KM) / 3600
freq = speedMPH * 1.15;
Serial.print("Freq = ");
Serial.print(freq);
Serial.println(" Hz");
uS = 1000000/freq;
if(uS < 4500000 && uS > 0){
return (uS);}
else {
return (4500000);
}
Similarly to the previous interrupt version we have a function which calculates the correct delay required to keep the ODO at the right frequency, there are some minor differences to work in microseconds and if the speed is too slow cap the output at 4500000us (4.5s). Otherwise it’s much the same.
if(ID == 0x4B0) {
frontLeft = (buf[0] * 256) + buf[1] - 10000;
frontRight = (buf[2] * 256) + buf[3] - 10000;
rearLeft = (buf[4] * 256) + buf[5] - 10000;
rearRight = (buf[6] * 256) + buf[7] - 10000;
//Going to check front wheel speeds for any issues, ignoring the rears due to problems created by wheelspin
if (frontLeft - frontRight > 500 || frontLeft - frontRight < -500) { //more than 5kph difference in wheel speed
checkEngineMIL = 1; //light up engine warning light and set speed to zero
vehicleSpeed = 0;
} else {
vehicleSpeed = (((frontLeft + frontRight) / 2) / 100); //Get average of front two wheels.
}
//Update timer count value with live speed for ODO
ODOus = calcMicrosecODO((frontLeft + frontRight) / 2);
Serial.print("ODO Step : ");
Serial.print(ODOus);
Serial.println("us");
// Dump speed to serial for debug - this is just a cropped int.
//Serial.println(vehicleSpeed);
}
Above we see the call for ‘calcMicrosecODO’ which is basically the same as the interrupt version but gives an actual time delay in microseconds rather than a timer count. It is called in this way with a calculation in the parameter field because if it is stored in a variable in between the number gets cropped off at the decimal point even if the variable is a float – I believe this is due to the way Arduino processes floats.
void loop() {
//Send information on the CanBus every 100ms to avoid spamming the system.
if(micros() - lastRefreshTime >= 100000) {
lastRefreshTime += 100000;
sendOnTenth();
}
// Call function to updateMIL on variable timebase
if(micros() - ODORefreshTime >= ODOus) {
ODORefreshTime += ODOus;
sendOnClock();
}
So our extra call for the variable timed refresh is above, it varies a bit from the first one because we have a varying time delay depending on the frequency required which here is a long we are calling ‘ODOus’ which we calculated previously. Obviously because we are using two comparisons we need another refresh time variable to keep them distinct, this is also a long. Also the second one calls a specific function for the variable time refreshes ‘sendOnClock()’
void sendOnClock(){
// Do not increment ODO byte when step is = 4.5s
// slower than this updateMIL must still be called so
// warning lights don't turn on but speed may be zero!
if ( ODOus < 4500000){
send420[1]++;
}
updateMIL();
CAN0.sendMsgBuf(0x420, 0, 7, send420);
}
This function is pretty basic, all it’s doing is checking the resulting ODOus value isn’t 4.5s because if it is this value is means the calculation is at it’s upper limit and the car isn’t moving (specifically the speed is below 0.21 mph). In this state it still updates the warning light registers and sends the CAN packet to keep the warning lights from blinking on but it doesn’t increment the ODO byte value so the ODO doesn’t continue to tick on.
// Time delay for Odo long ODOus = 4500000; // Set to max 4,500,000 to keep dash // MIL warning lights awake at 0 speed
The declaration for ODOus is set as 4,500,000 at start up so it correctly. The only downside to this is it takes a few seconds for the dash lights to go out initially and the oil pressure gauge goes to normal in two steps. This could be dramatically improved either by setting a higher minimum speed at which the ODO ticks because even increasing to 0.5 mph would improve the maximum duration to 1.7 seconds. Another option to avoid this is just to send an update to 0x420 in between the ODO calls. If we keep the one to the other loop ‘sendOnTenth’ without incrementing the ODO value it will just display any changes to the warning lights almost instantly while keeping the ODO working correctly.
void sendOnTenth() {
// PCM Status's to mimic the PCM being there, these may be different for different cars,
// and not all are always required, better safe and include them all.
CAN0.sendMsgBuf(0x203, 0, 7, send203);
CAN0.sendMsgBuf(0x215, 0, 8, send215);
CAN0.sendMsgBuf(0x231, 0, 8, send231);
CAN0.sendMsgBuf(0x240, 0, 8, send240);
CAN0.sendMsgBuf(0x620, 0, 7, send620);
CAN0.sendMsgBuf(0x630, 0, 8, send630);
CAN0.sendMsgBuf(0x650, 0, 1, send650);
updateMIL();
CAN0.sendMsgBuf(0x420, 0, 7, send420); // Duplicated in sendOnClock to update ODO
updatePCM();
CAN0.sendMsgBuf(0x201, 0, 8, send201);
So that’s it but I should probably mention that I’ve not tested this on a live car however I have a program which works out the correct CAN byte values and then builds a correctly formatted string which can be pasted into USBtinViewer and sent to simulate an update from the ABS and the Arduino and cluster all seem to respond correctly:
In this code you will see a scaling factor of 100 which should be correct but on my cluster I seem to get a speedometer reading 1 mph higher than intended from a calculated 5-185mph I actually see 6-186 mph on the cluster. I’m not sure why this is but it may be on purpose due to the common requirement for speedometers to never read lower than true speed. Indicated speed is required to be within -0% / +10% + 4km/h of actual speed in the EU. Technically we could correct this by doing two vehicle speed calculations on the Arduino, one for the odometer calculation using the proper scaling factors to keep it accurate and one for the displayed vehicle speed using a scaling factor which corrects this error. I do not intend to do this but I have found a scaling factor of 99 rather than 100 makes the speedometer match up if required.
As ever your mileage may vary, but hopefully it’ll closer than it was before! As I said earlier this is part of another major overhaul of the code and I’m intending to publish the final version as a complete code when I’m happy I’ve got everything working but that might take some time.