X-Like

[simonr]

My 'plan' was to use an MCP2515 CAN Controller which is dead easy to use, has an SPI interface and pre-existing libraries to make the coding easier!

As it's evolving I'll have 3 Analog, 1 i2C & 5 Digital IO lines on a D15 connector plus CAN on a D9 (Open-CAN Standard) out the back of the meter.

Supply it with a pre-populated D15 connector.

3 Add-on boards. GPS, Cellular (though it might make sense to roll these together) and a multiplexer to expand one of the 3 Analog inputs to 8 using 3 digital lines to select giving 10 Analog in's.

If CAN is in use, it uses 3 digital lines - leaving only 2. One of these will be connected to a relay internally (so you can switch heavier loads - e.g. Radiator fan). The second one can be a general output - perhaps to drive a relay. Split-charge maybe?

I've not used DesignSpark - in the past I've used Eagle mostly but I'll have a look, it wouldn't be hard for it to be better! I'm going to prototype it using off the shelf modules which makes the whole thing more likely to work first time! Use these to get the software working, then migrate it to a custom PCB or two.

Si

The multiplexer can live under the bonnet (outside the dash) to make wiring easier.

[FridgeFreezer]

I'm at the luddite end of this - I'd quite like a smart gauge but gauge with a needle that blends in on a defender dashboard, it's very hard to find a display that's daylight-readable but not irritatingly bright at night or that flickers out of the corner of your eye. Shame a round e-ink screen would likely be prohibitively expensive.

Also, while I can see OBD or CAN driven / multiplexed sensors from remote box etc. is very cool at the top end, at the bottom end a fairly cheap gauge that can be set to work with any common automotive sensor (mostly temperature or pressure) seems like an attractive prospect where you can buy 3 or 4 of them and just slot the whole lot into your dashboard and configure them as required, rather than spending £250 on a single 52mm gauge that then tries to do everything in one small display.

[robertspark]

I know that my thought process of hoping to put two 7" LCD screens for a lr dash is probably going to get me into the "pass the bucket thread stakes" but I'm sorry the plastic bezzel dash or whatever you want to call in in a defender is a bit well carp and not robust at all

Hence I'd happily buy a more modern looking solution with some better information guages in it able to allow me to view EGT (via separate modules) or even dual lambda sensors (via LC1 or LC2 programmable 5v linear output), revcounter etc, etc

Other options like SD card modules to log or record canbus data would allow the system to be very expandable in the long run and if its got the ability for some of us to customise card a bit with custom sketches/ code or modules I think your onto a winner

Not sure how you're going to get out of filling boxes at the moment Si or spending your days answering the phone or forum with technical support questions. If it could be done a bit megasquirt style it may free up time with distributed or collaborative working

Rob

[elbekko]

Canbus is for robustness speed and volume of data transfer that needs to be addressable or read by many nodes at once could use modbus given most of the sensors will slaves and data traffic not that great and little required to be addressable

I have been using max6675 via spi for ktype thermocouples

Maybe for flexibility the ability for multiple interface options so you could connect to i2c spi canbus (with optional module), modbus serial or even Ethernet? (Very easy to wire then...)

Modbus is very easy component wise, canbus I would have thought would be harder from scratch to develop the software side unless you reuse the megasquirt code implantation

What do you use Si for your PCB design. I've been using designspark

Rob

I wouldn't see the system as a master/slave thing really. Just a bus on which modules broadcast values, and modules read values. Usually this will be the gauge reading the values, but I'm imagining modules that combine a sensor value with a value that's already being transmitted on the bus. Leave the dependency nightmare to the developers of the modules.

I sure hope CANbus isn't that difficult, as I plan on doing a bit with it myself soon (reverse engineering the ECM <-> TCM comms in the Bosch P38). For those wanting to learn more: http://www.kvaser.com/can-protocol-tutorial/

[robertspark]

No canbus is not that difficult, but it helps if a library has already been created which you can just integrate to send and receive messages.

canbushack.com is worth a read

The problem comes with trying to hack it given only the heavy industrial plant canbus addresses (PGN's) are listed in an easy to access list, other manufactuers (audi, ford, BMW, GM [vauxhall, etc] all have their own canbus addresses for data being transmitted.... because of landrovers ownership route (bmw, ford, tata etc it could be somewhat difficult to figure out what they actually used.... ).

By address I mean the identifier (called a "PGN" under J1939) that is assigned to a reading, so identifier PGN 65270 = IAT (or manifold air temp), PGN 65262=EngTemp etc. Basically the same j1939 list (I can post a link to the list later if anyone is interested... May be worthwhile following the same addressing strategy given it would make it easy to standardise canbus transmissions and you may be able to pick up on obd2 info

Link to J1939 list here if desired to try to implement the same / similar addressing method...

Rob

[simonr]

I think my intentions are half way inbetween the two extremes Fridge highlighted.

Most Land Rovers do not have CAN - so it needs to have enough basic inputs to read ordinary sensors. However, the cost of adding CAN is very low, so it makes sense to include it for the vehicles that have. At the moment, there are lots of CAN gauges and a couple of direct reading but none that i can find that do both at the same time. If your car has all the sensors already - it makes sense to use them if possible!

I agree about the display issue. I bought a small ePaper display which was too expensive and actually didn't work that well even with an electroluminescent backing. The contrast ratio was poor in the dark and it didn't update anywhere near fast enough for a gauge.

What has inspired this is getting hold of a nice OLED display that is readable in sunlight with the shade provided by the instrument panel and fully dimmable for use at night. No noticable flicker even when you update the screen (if you draw the screen in RAM then swap the page the display is looking at). It's the first that I'm happy to have as a gauge.

To be viable as a product, it has to capture the biggest market possible. It won't suit everybody - particularly the people who want clockwork dials - but I think there are enough who would like a modular, adaptable gauge with a low entry price to make it a goer.

With regard to packing boxes - I have a plan for that!

[elbekko]

You mention using an OLED. Aren't you afraid of burn-in? My old Samsung Galaxy S2 had the static elements of an app I use in the car burned in. Purposefully picked the Galaxy S4 Active after that with a TFT screen to prevent just that.

I can imagine that in the cause of a gauge, that menu elements etc might get burned in?

[CwazyWabbit]

......

The problem comes with trying to hack it given only the heavy industrial plant canbus addresses (PGN's) are listed in an easy to access list, other manufactuers (audi, ford, BMW, GM [vauxhall, etc] all have their own canbus addresses for data being transmitted.... because of landrovers ownership route (bmw, ford, tata etc it could be somewhat difficult to figure out what they actually used.... ).

.....

I may at some point in the future have access to a CAN bus sniffer so it's possible we could find out given an example vehicle.

[elbekko]

I may at some point in the future have access to a CAN bus sniffer so it's possible we could find out given an example vehicle.

Something like this? Need to write the software at some point, but the hardware side has been taken care of.

[robertspark]

Haha this forum... Amazing who knows what...

I did write a piece on j1939 on my last post but it didn't edit or add it,

[CwazyWabbit]

Something like this? Need to write the software at some point, but the hardware side has been taken care of.

We were looking at these http://www.totalphase.com/products/komodo-canduo/

There seem to be lots of CAN projects around, I'd not seen that one before elbekko

[elbekko]

Oh, that's a bit spendier, but no doubt also better supported and more professional. This one was €35 or so delivered, and works with the Raspberry Pi 2.

[CwazyWabbit]

Don't get me wrong, I'd be buying the one you suggested or the Arduino one if it was my wallet.

[landroversforever]

Si, have you come across PanelPilot gauges? Work uses them quite a bit on systems. They each have two inputs that are programmable for warning lights etc. you can choose gauge style/design/label

http://www.panelpilot.com

These are the ones I've used: http://www.panelpilot.com/panelpilotm

When I get to the gauges part of my build, I'll be investigating these.

Like fridge, I like a more analogue type gauge. I'd hate switching between different things. With a normal type gauge I like that a quick glance can tell me all I need to know.

[CwazyWabbit]

I have one of those sitting on the shelf Ross, haven't got around to trying it yet. What do you use them for at work?

[robertspark]

Ahh but remember that you can set high or low level alerts with what Si is proposing hence if it triggers a high or low it may flick to the display or item of concern. Hance if you had say 3 dials same as a fender dash you could display any combination of things perminantly but under an alert the screen would change

(Priority is an issue that would need dealing with as a setting including if you had two things fault (high or low at once) or a consequential fault)

Rob

[simonr]

I figured that if there is an alert, it will switch to that screen and set full brightness. If there are two or more, cycle through the ones that are out of range. When you press either button, go back to whatever it was doing before. If the problem still persists a few mins later, display the error again. If you press both buttons, cancel & ignore the error until it clears and re-occurs.

If you decide that one of the errors is the one you want to look at, cancel the error and scroll to that screen. Something like that anyway!

Si

[landroversforever]

I have one of those sitting on the shelf Ross, haven't got around to trying it yet. What do you use them for at work?

They're used on the turbo pump controller cubicles I believe and some other monitoring kit. I must add I don't personally use them at work, but ive come across them.

Also used them when my mate retired his generator and redid the control panel. So had a number of them for fuel level, eng temp, oil pressure etc.

[RangeyRover]

Hi Simon,

Following with interest. This guy is making a lot of headway interfacing LS1 canbus with BMW canbus.

He also interfaced to a D2 at one point.

http://www.bimmerforums.com/forum/showthread.php?1887229-E46-Can-bus-project

Commoditising the hardware to do this is, is a real opportunity to my mind.

Heaps of Petrol D2 crying out for a re engine in the states and Oz.

RR

[robertspark]

LS engines are another kettle of fish to a degree, yes they are Canbus, but the implementation is called GMLAN, and it's both high speed and low speed (i think there is a GMLAN Hi and GMLAN Lo pin / bus / wire....)

Given you're after gauge functions most of the information can be obtained from OBD2 PID requests. If you're thinking of tagging the gauges onto the canbus network, then it's best that the gauge nodes and any other addon ancillary gauge related devices only send low priority messages so that they do not hold up the network... this will allow you to tag onto the vehicles canbus network, read PID's and also transmit data (or requests) to addon modules all at the same time, it also means that you can install devices anywhere you want in the vehicle.

I can ramble on about this and get into bits and bytes but its probably only of use to Si in his application or if you're wanting to attempt to decode the can messages on your network (not an easy task).

OBD PID's should be all you really need (for gauge functions) unless you want to turn the wipers and lights on etc etc.

I would really like to implement canbus on my 90 to cut down on wiring (all you need is B+, gnd & two can wires to each corner of your car, then an addon module that has fuses, and IO's that you can then programme to do whatever you want to do in a standard format), but life is proving too short for a one man band (and the wife demands I pay the bills with a day job.... )

Rob

[simonr]

My intention was only to use OBD2 PID's as I only really want it to be a meter. However, if someone else wanted to re-purpose the hardware (as it will be open source hardware & software) to send & receive CAN messages - they can!

I have no doubt I'll do a bit of 'hacking' with it at some point!

I found this on line (on a Russian Forum):

Which I quite liked! The display I'm using is a different aspect ratio and higher resolution so it doesn't exactly translate - but I liked the gauges and pictograms for the different functions. In principal it's the closest I've found to what I want to achieve.

Si

[Maverik]

Very interesting project, I've been looked into machinery condition monitoring for years now through work, never found justification to spend the money on a system for my truck, but very much would like to monitor more than the engine temperature.

Not got any technical know-how to add at the mo, but I'd like to support your idea, cheap, flexibility, simplicity/open source will get you a long way. Will be keeping an eye on this.

Mav

[RangeyRover]

Hi Simon,

Some of the work has already been done with this.

https://github.com/magister54/opengauge

Might be useful to Fork, as development appears to have slowed.

RR

[simonr]

Thanks for the link RangeyRover. There are a few good snippets of code in there.

Although there are some bits in there for reading Analogue sensors, the main thrust of the project is to use OBD and most of it relates to MPG reading / HyperMiling. I figure if you are interested in HyperMiling, a Land Rover is not the best starting point as a choice of vehicle!

My intention is the other way round - an Analogue gauge with an OBD add-on so it can be used on later vehicles (later than mine!). There's a whole load of things I'd like to measure which will never be a part of OBD such as voltages from multiple batteries, Current, Hydraulic pressure.

Something else I've always fancied is a steering position indicator - Off Road, it's sometimes hard to tell which direction your wheels are pointing! I did this previously with a Range Rover axle position sensor to measure the steering angle, linked to a centre zero ammeter which read +/-100. It worked rather well!

I think I'll start a new project on GitHub and credit OpenGauge in the ProjectHome page.

Si

[robertspark]

Range rover axle position sensor? Have you got link?