Digital Instrument Cluster Development

Since my last post I've been spending most of my spare time developing the software for my digital instrument cluster. I started this over the christmas break by mocking up a Honda S2000 style cluster. This required quite a bit of math that even if I paid attention in trigonometry in school I probably still never would have remembered. But after some pain and headaches I was able to get something that looked somewhat like a Honda S2000 cluster.

Over the last few weeks I have extended this basic screen into a fully working application using the model/view/presenter development design pattern which for what I am doing makes adding new cluster designs, data providers and logic very simple. Think of is a a plug and play system with lots of small components that can easily be interchanged without rewritting software.

I've added three color schemes to the S2000 cluster based on some color designs that Qube Engineering actually make for the real Honda cluster. Here are some samples of the computer based cluster images and below them their originals.










Because I dont have a working Mazda CAN bus system (still collecting parts for the RX8 to get the system working, they should arrive by Friday I hope) I have been using my fiance's Toyota Echo for testing using generic OBD-II (on board diagnostics) port to obtain the data needed for display on a cluster. The problem with this is that I have to query the car for this data and I can only get between 4-6 responses from the car per second so data isn't displayed all that fast. On a CAN bus system I can get hundreds of packets of data in a second so data display will be in real time (the cluster on CAN equiped vehicles uses the exact same data) and in essence be getting the data from the source. The other benefit of the CAN bus is that I am able to obtain information that simply isn't available via diagnostic commands such as when the indicators are on, handbrake is up, brakes are active and quite a lot more.

I've recorded and uploaded two live test runs videos. The first one is a very short test run showing a few more revs, while the second one is recorded in peak hour traffic leaving the city.

Both of the recordings show the following data:

• Vehicle Speed
• Engine RPM
• Coolant Temperature Gauge
• Intake Air Temperature (Top left hand side of the info box)
• Current time
  
• Coolant Temperature (Top right of the info box prefixed by 'w')
• Odometer (Bottom left of the info box)
• Selected Gear (Calculated based on known gear ratios, engine rpm and vehicle speed)
  
• Trip Meter A (Bottom right of info box)
  

The odometer and trip meters are also a calculated value based on the vehicle speed. After some live testing I noticed that they seemed to read a little higher than the cars on board trip meter. I expectED inconsistencies because of the lag in data coming from the OBD requests but I thought I would see how they both compared to a GPS odometer on a clear day. It turns out after 30km of highway/city driving my odometer was about ~50m more than the GPS unit, whereas the cars odometer was ~500m less than the GPS unit. Some more testing in a car with better electronics will be needed to triple check everything but from what I can see the odometer I wrote is actually quite accurate! Nice...

Down the track once I have a working dash running from CAN data I will add some more gadgets such as GPS navigation (basic and driven from google maps like xGPS) combined with an accelerometer (probably from a Wiimote normaly used for a Nintendo Wii) and digital compass. With these combined I should be able to make a halfway decent navigation system that knows which way my car is facing at a standstill. This will also double as a data logger and lap timer for when I race on the track.

So I will know gear, speed, revs, g-forces etc for every single point I am on the race track. A display like what you can get on popular racing games like Gran Turismo shouldn't be to hard to acheive either!

I do have a few other things in the works for the cluster such as a better design based on a Lexus but I will save that for another post once I have made the software more reliable and robust. Until then....

S15 Sold, Engine Delivered

Well after about five weeks and very few actual shoppers and plenty of time wasters I've finally sold my S15. And not a moment too soon, next week I need to make final payment on my clubman so everything is running smooth at the moment.

I also had the RX8 engine and parts delivered yesterday. This on the other hand was not the smoothest of deliveries. Firstly they tried to deliver it on Tuesday without calling me first so that I could arrange to be home to unpackage the 320kg box off the truck. So I arranged for redelivery the following day between 9-12am. It didn't arrive... So after about 5 phone calls to TNT the package arrived at 5:05pm. A wonderful day of daytime TV it was...

I've also been looking into how I am going to tackle the task of wiring everything up. I have the majority of the electrical components from the donor RX8 and I learned recently thanks to a blog named Madox.NET the some Mazda's (RX8 included) run a CAN network that allows all of the electronics in the car to talk to each other much like computers do on a normal network.

With some specialist devices such as OBDLink a normal computer can also talk on this network through the cars diagnostic port. This port will allow me to do two things, firstly I will be able to check error codes from the engine ECU which will help me to pass emissions and trouble shoot setup issues. Secondly I will be able to intercept signals that would normally go to the dash for things like engine revs, speed, trip computer etc

What I am proposing to do is instead of using a dash from a car or motor bike is to instead use an Asus EEE PC T91 tablet PC with the CAN hardware and some software I will develop myself to create my own dash. Because I will be getting data directly from the Mazda sensors, some of which isn't normally displayed to the driver I will be able to show all ADR required gauges and more. What's great about this is it will be far cheaper and easier than buying seperate gauges and having to install new sensors for them. Plus, if I can have a whole range of dash designs and flick through them with a touch of the screen and adding warning lights/buzzers will be a matter of a few lines of code rather than a heap of wiring/cutting etc...

Here is a sample screen shot of a RX8 style dash design written in .Net using Dundas Gauges, I also added a basic three stage shift light that lights up yellow, then organge then completely red when it's time to shift.