36 replies to this topic

[techieboy]

Yeah, yeah, I know it's not CAN-bus but it's probably the quickest way to guarantee the Borgmeister checks this thread.

 

I've just inherited a data logger from a friends race car. It looks like quite a decent bit of kit and supports 7 external analogue sensors (plus an 8th dedicated to the battery) and also 3 frequency based channels for RPM (and I'm not sure what else you'd measure - wheel speed maybe).

 

In an ideal world, I'd hook up to the OBD port and grab existing OEM sensor data leaving me with plenty of inputs for extra sensors. But the Z22SE ECU is too flaky and can't output data fast enough and his the occasional misfire/hiccough as a result. Unfortunately, the data logger doesn't support ye olde OBD2 but it does have a high speed CAN input for grabbing as much OEM data travelling around an existing CAN as you want. I'm not really sure how CAN works as far as sensors on a modern car is concerned and whether most sensor data is just old school direct to the main ECU and the ECU then fires that around to other ECU's/dashboards etc over CAN or whether sensors themselves directly (possibly via a "black box" of some form) broadcast over CAN. So does anyone know if it's possible to effectively create your own CAN to broadcast additional sensor data around the car? 

[slindborg]

twat

 

 

yes its entirely possible to make a K-Line to CAN convertor.

As it stands, in simple terms, the ECU would read the coolant temp sensor, it would then pass it through to the CAN functions which will add that value to the next scheduled message containing that varaible.

 

The small issue with using the OBD route is the Z22 ECU does get a little upset if you try to pull too much from it.

might be easier to "life hack" a scangauge to output over CAN what its read from KWP

 

ORRRRR as you say, make up a network with some new sensors and piggyback off others etc.

Edited by slindborg, 11 November 2014 - 11:23 AM.

[slindborg]

infact, you could probably butcher an ELM327 into doing the job.

 

Ohhhh found an arduino project using a 327 and some codes to read the stuff... wont take much to send

Edited by slindborg, 11 November 2014 - 11:29 AM.

[FLD]

all this extra data will do is scare you into not driving the car.  Best option is to continue in blissful ignorance!

[techieboy]

So how do sensors (and even switches and relays) work on an OEM CAN setup? Does each sensor have some form of controller/transceiver of some form that combines the sensor data with a unique address into a single packet of data and fire that onto the CAN. Then (in this case) the datalogger reads that packet and says ah, that address corresponds to throttle position sensor and therefore this next bit of data is the TPS value and logs it?

[techieboy]

all this extra data will do is scare you into not driving the car.  Best option is to continue in blissful ignorance!

I am already blissfully unaware. I don't have OBDTuner, so don't have IAT induced nightmares. That's why I want everything to go into a logger and then I can bin the gauges. My existing data logger (performance box and micro-input module) only displays lap times and doesn't care about what it logs from sensors and even has a nice piece of gaffer tape over the display.

[slindborg]

So how do sensors (and even switches and relays) work on an OEM CAN setup? Does each sensor have some form of controller/transceiver of some form that combines the sensor data with a unique address into a single packet of data and fire that onto the CAN. Then (in this case) the datalogger reads that packet and says ah, that address corresponds to throttle position sensor and therefore this next bit of data is the TPS value and logs it?

 

in efect, yes.

 

CAN was supposed to be the saviour of vehicle weight and complexity.... every device would have power, ground and two CAN lines going to it and that would be it for the loom. Sadly the reality is you cant do that and you need controllers.

you can have 11bit ID's or 29bit ID's so gives lots of scope for message numbers, 8bytes of data per message, a sending speed typlically 83.3kbps to 1Mbps, and rates from 1ms to on demand (usually 10, 20, 50, 100, 250, 500, 1000 ms)

Lower numbered message ID's have higher priority over higher numbered ones (should you care). could go on but you are snoring now.

 

Example, Door controller.

Its a unit with a microprocessor in there and a load of input and output drivers/conditioners.

You have the window switch, you have the window motor. On its own the unit can run the window from the switch, but with CAN you can send a message (usually 8bytes) with a window demand so you can control it from another door. Same with locking, puddle lamps, door status and all kinds of other shite you never thought possible from really mundane stuff that no one notices till its not working....This is what I did for Pagani, Delta, a bit for Ginetta, a bit fo Koenigseeeegggggggg, and started for Morgan.

 

As FLD says, do you "need" to know this info? I bet you dont but it would be a fun project

[slindborg]

by the way, with all the pissing about of making a KWP-CAN interface, you might aswell just make a KWP logger and drag in some other inputs if you care rather than having two extra boxes

[techieboy]

So if I popped the rear clam on one of your 'eggs and looked at, for example, the coolant temp sensor. I'd hazard a guess that it will look just like a regular Bosch 2 pin coolant sensor as fitted to every car on the road that doesn't use the Delphi equivalent. That sensor isn't CAN aware is it - it's just a dumb resistive analogue sensor? So it's either wired direct to the main engine management ECU (like the VX's is) and the ECU then CANifies it for any other system that might want to know, or it's connected into some form of analogue->digital converter first that writes a wrapper for the sensor value and then fires it off to the ECU and any other interested systems.  

As FLD says, do you "need" to know this info? I bet you dont but it would be a fun project

Do I need most of it? No and certainly not "live". Would it be good to have some of it for reference? Yes. The appeal of CAN is the speed of it and the fact you can effectively send as much data as you want across it and the logger just decodes and records whatever you ask it to. If we could reliably log at a decent refresh rate from the OBD port that would be great. Over OBD I'd naturally log things like coolant temp, IAT, MAP, throttle position, lambda (even rpm if it were really fast enough) and that would leave 7 spare analogue sensor channels on the logger to capture other stuff. But it's sh!t and as we know barfs when demand is high so they'd need to be logged direct, especially for anything that isn't effectively static. I'd instantly dump the oil pressure and temp gauges and wire their respective sensors to the logger and then I'd be stuck with one or maybe two spare channels. I'd like to log the wideband so that might be all of the inputs taken now. Then if I wanted gearbox temps I'm stuck. If we ever wanted to find the temperature difference pre and post laminova, I couldn't do that. Likewise fuel pressure. I've even got two EGT thermocouples and amplifier here but would have nowhere to connect them to if I ever wanted to drill some more holes in my exhaust.

[slindborg]

So if I popped the rear clam on one of your 'eggs and looked at, for example, the coolant temp sensor. I'd hazard a guess that it will look just like a regular Bosch 2 pin coolant sensor as fitted to every car on the road that doesn't use the Delphi equivalent. That sensor isn't CAN aware is it - it's just a dumb resistive analogue sensor? So it's either wired direct to the main engine management ECU (like the VX's is) and the ECU then CANifies it for any other system that might want to know, or it's connected into some form of analogue->digital converter first that writes a wrapper for the sensor value and then fires it off to the ECU and any other interested systems.
 

[color=rgb(255,0,0);]Yes and No. The sensors will either be dumb resistors, PWM output or LIN (lets not go down there). But yes they all go back to the engine ECU which will then send the values out over CAN in the message protocol.[/color]

[color=rgb(255,0,0);]Due to the KWP 2000 protocol being slow and crap, I would really suggest piggy backing off the sensors, but then you will need to calibrate against them which might be a pain, and also be coy about not screwing up the readings or fault detection. This would then be ideal to belt round the car as CAN, but I would also ask the question as to why would you use CAN when you could just log direct on that interface device.[/color]

 

 

 

As FLD says, do you "need" to know this info? I bet you dont but it would be a fun project

Do I need most of it? No and certainly not "live". Would it be good to have some of it for reference? Yes.

The appeal of CAN is the speed of it and the fact you can effectively send as much data as you want across it and the logger just decodes and records whatever you ask it to.

If we could reliably log at a decent refresh rate from the OBD port that would be great. Over OBD I'd naturally log things like coolant temp, IAT, MAP, throttle position, lambda (even rpm if it were really fast enough) and that would leave 7 spare analogue sensor channels on the logger to capture other stuff. But it's sh!t and as we know barfs when demand is high so they'd need to be logged direct, especially for anything that isn't effectively static. I'd instantly dump the oil pressure and temp gauges and wire their respective sensors to the logger and then I'd be stuck with one or maybe two spare channels. I'd like to log the wideband so that might be all of the inputs taken now. Then if I wanted gearbox temps I'm stuck. If we ever wanted to find the temperature difference pre and post laminova, I couldn't do that. Likewise fuel pressure. I've even got two EGT thermocouples and amplifier here but would have nowhere to connect them to if I ever wanted to drill some more holes in my exhaust.

 

 

See in red

 

I've looked at designing a data logger in the past but was soon shot down by Randy because the hardware exists in many many forms and prices these days, its how you process it that counts... maybe there is a market for a cheap but effective logger that takes some info from the ODB/KWP2000 port.

 

Ohhhh, thought, not that you will like it. I wonder if Peter could do something cunning and implement CAN in the dutch setup

 

 

[techieboy]

by the way, with all the pissing about of making a KWP-CAN interface, you might aswell just make a KWP logger and drag in some other inputs if you care rather than having two extra boxes

I want as few boxes as possible but if there's a relatively straightforward way to CAN'ify some of these sensors and free up dedicated inputs, that would be handy. Not least of which, wiring should be simpler if there's just a pair of wires with an RJ45 on the end, running into the car. The data logger also has 20hz GPS built-in, 3-axis accelerometer, bluetooth output to a virtual dashboard application for Android phones/tablets and even a 3g chip (though given mobile reception at most UK circuits that's next to useless, even if I wanted to use it) to broadcast live telemetry to a website and better yet, it was free. I'm all about upcycling these days.

[techieboy]

[color=#ff0000;]Yes and No. The sensors will either be dumb resistors, PWM output or LIN (lets not go down there). But yes they all go back to the engine ECU which will then send the values out over CAN in the message protocol.[/color]
[color=#ff0000;]Due to the KWP 2000 protocol being slow and crap, I would really suggest piggy backing off the sensors, but then you will need to calibrate against them which might be a pain, and also be coy about not screwing up the readings or fault detection. This would then be ideal to belt round the car as CAN, but I would also ask the question as to why would you use CAN when you could just log direct on that interface device.[/color]

I'd love to piggyback off the existing sensors where possible. The logger is high impedance so theoretically it wouldn't affect the signal that the ECU sees but I'm not sure I'd want to be fcuking about with the TPS's. That sounds too much like a recipe for disaster.

I guess something like this is probably what I'm looking for?

[slindborg]

Ohh, nice, how much? I'll guess at a minimum of £150+vat

[Mangham54]

 

I guess something like this is probably what I'm looking for?

 

 

Either that or an Audi TTS.

[techieboy]

Maybe I should just fit Matt Bentley's aftermarket ECU, that might have CAN output on it and it already supports some additional sensors.

 

Just need him to do his official write-up. And move premises. And finish Graemes conversion.

[slindborg]

oh yeah, I recall they were doing something... hopefully its not a megasquirt in drag

 

 

 

Maybe I should just fit Matt Bentley's aftermarket ECU, that might have CAN output on it and it already supports some additional sensors.

 

Just need him to do his official write-up. And move premises. And finish Graemes conversion.

 

[techieboy]

Ohh, nice, how much? I'll guess at a minimum of £150+vat

  No idea. It's British and looks très expensive to me but was the first thing that I found that looks vaguely like what is needed.

[techieboy]

Either that or an Audi TTS.

Got the Audi. If I was interested in plugging this logger into that, it would work a treat straight away as it's CAN'd to death. I'd even be able to log what radio station I was listening to, at what volume, at the end of the Hangar Straight.

[slindborg]

and which speakers were doing what

[techieboy]

It would probably record any moments of slight panic I had, over the integrated handsfree as well.