36 replies to this topic

[slindborg]

now thats worth listening to

 

in all seriousness, I'll have a look at what could be done with a pikey KWP K-Line to CAN interface

[Mangham54]

 

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.

 

 

That is what I meant, when I had the Pissrat, it was hilarious watching the car log everything that was going on, particularly when it used to throw a paddy about the rear right speaker 'operating out of accepted tolerances'. I think that may have been caused by it being creased with half the rubber torn.

[Exmantaa]

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.

I could tell you to use the LSJ ecu, that supports aGM-LAN /CAN line, but for ease of mind it's just as easy to go for OBD. The logging function that Peter build is quite good and fast, as it saves the dsta direct in the ecu's memory space and you read-out later. (so you can see why your engine blew up, haha)

[techieboy]

I could tell you to use the LSJ ecu, that supports aGM-LAN /CAN line

See, that would be ideal. All of the LSJ's standard data available out of the OBD port (datalogger company are working on an OBD->CAN interface cable at the moment) no data overload misfires and standard fault codes as well. Then 7 spare inputs on the data logger. Maybe I should get up in the attic and dust off the LSJ ECU and loom.  

but for ease of mind it's just as easy to go for OBD. The logging function that Peter build is quite good and fast, as it saves the dsta direct in the ecu's memory space and you read-out later. (so you can see why your engine blew up, haha)

Agreed, the logging is good and the interface is nice and easy. But it would mean downloading data after each stop onto a laptop and trying to synch up multiple datasources (and video) again, as it can't handle additional sensors. That's one of the problems I've got currently.

[Exmantaa]

What do you actually want to log extra? I can only imagine some temps, but once that is in grip you just drive the thing... ps, just steal Joe's lsj set-up, as he will not notice that it's missing anyway....

Edited by Exmantaa, 11 November 2014 - 07:58 PM.

[techieboy]

What do you actually want to log extra? I can only imagine some temps, but once that is in grip you just drive the thing...

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 or steering angle. 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.

ps, just steal Joe's lsj set-up, as he will not notice that it's missing anyway....

There's an idea. Not sure how well a Harrop map would work with an M62 though. Is his all sorted now? Last thing I read was you were having problems with really rich running (or maybe it was really lean ). Can the ECU still support CAN H&L over our OBD socket, or does that need extra wires back to the ECU?

[slindborg]

It would need extra wiring

[techieboy]

Not insurmountable then? Guess it's literally two wires for two unused pins in the socket, back to the relevant ECU plug.

[slindborg]

yep, ideally twisted with a 25mm twist (or chuck in a drill and spin it up )

[Exmantaa]

Not insurmountable then? Guess it's literally two wires for two unused pins in the socket, back to the relevant ECU plug.

 

Yes, 1 wire is use for the slow OBDII signal (logging and ecu programming) and a dedicated ecu pin is used for CAN (GM-LAN as they call it). And you need a ground off course.

Edited by Exmantaa, 12 November 2014 - 04:11 PM.

[slindborg]

So its not real can.... Ffs gm are just utter doodahs

[techieboy]

GMLAN which stands for (General Motor Local Area Network) is an application- and transport-layer protocol using CAN for lower layer services. Transport-layer services include the transmission of multi-CAN-frame messages based on the ISO 15765-2 multi-frame messaging scheme. It was developed and is used primarily by General Motors for in-vehicle communication and diagnostics. GM's Tech2 uses the CANdi (Controller Area Network diagnostic interface) adapter to communicate over GMLAN. Some software applications that allow interfacing to GMLAN are Intrepid Control Systems, Inc.'s Vehicle Spy 3, Vector's CANoe, Dearborn Group's Hercules, ETAS' ES-1222, ES590, ES715, and ES580 products, ScanTool.net's OBDLink MX and EControls by Enovation Controls' CANCapture.

Not sure whether ISO 15765-2 is a standard standard or something more obscure.

[slindborg]

It's basically kwp over can rather than over Kline as you have now. 15865-4 is the kiddie where its real can using the proper 'standard' 8 bytes of data message length etc

[techieboy]

Yep, looks like typical GM cheap sh*t

GMLAN is a single wire CAN Bus that operates at 33.333 kbit with 29-bit header packets and is commonly used for transmission of non-critical information between such nodes on automobiles as the following; Dash cluster Entertainment system (head unit) Satellite Navigation (OnStar for example) HVAC controls Immobiliser / alarm / other security systems Door locks and door status Power Windows Interior / exterior lighting Reversing sensors

[slindborg]

any GM wonders why its in the sh*t

[techieboy]

Holy guacamole, $625 for this.

 

 

 

Guess it would do the job though and give me an extra 8+2 channels.

[slindborg]

It would take me about 15 years, but I could do similar for about £20

could do it faster but bigger and worse with some arduino bits for about £100