ECU Diagnostics - CAN Bus, hunt for answers

[aerobod - near CYYC]

@Jonathan,

The address of the 3D maps in the ECU memory can be determined in the .ec2 file and definitely maps to the chipfile (.ecc file) that is loaded, they are all 131071 bytes long for the 992 and 9A4 ECUs and addressed as 2 pages in the ECU memory (page 0x00 from 0x0000 to 0xffff and page 0x01 from 0x0000 to 0xfffe).

I have confirmed with my unlocked ECU that the target Lambda map for TPS vs RPM is at page 0x00 from address 0xc000 to 0xcfff and that 1D (MBE uses that term for discrete variables) RPM values for soft engine cut is at page 0x00 address 0x700c (MSB) and 0x700d (LSB) and hard engine cut is at 0x700e (MSB) and 0x700f (LSB).

From an old .ecc file I had backed up from the locked 992 ECU I had fitted originally, most of the values across the chipfile were returned by Easimap into the backup file as 0xff. So the question with locked ECUs that still has to be tested is whether when they are directly queried via the CANbus is there a config parameter in the ECU that just returns 0xff for any address in the memory pages 0x00 and 0x01, or is this obfuscation done within the Easimap code and direct query will return the map values?

[ECR]

I have visions of some poor guy sitting in a back office at MBE getting very concerned as you relentlessly unpick all his hard work.

Still fascinated by this ....

[CtrMint]

I wrote to their Technical Director, asking for support.... got blanked.... 

[Purplemeanie]

I suspect they're surprised nobody got this far already. And in fact I bet that the engine tuners out there know this stuff already but are keeping quiet.

Like I said before, they weren't exactly hiding anything. If they'd have encrypted the .ec2 files or put some simple obfuscation on the connection protocol then I think we'd have struggled a bit more.

John

[CtrMint]

So...  don't laugh!

Hope you like the attached video, I've tried to show the 'Dash' in operation.  I took the car out onto a quiet road, and having got the engine warm attached the Dash, then recorded it in use.  Unfortunately the strong sun made recording tricky.  My vlog style was also terrible, first attempt!

The video did show the data sampling rate is probably too low for practical use.  The sample rate is straightforward to change, but difficult to find the right balance without actual driving taking place.  I think the graphics need some work too, but that's going to take place once I've fitted a 7" screen and the Pi.  

I may also delay tinkering with the graphics until I've developed my data logging solution.  I intend to build a tool using Matlibplot to analyze data recorded during drives.

I also need to nail my wifi setup!

There's still lots to do!!

[Jonathan Kay]

Thanks, both.

If we can see all the inputs to the ECU (and I think we can) and we can see all the outputs (again, I think we can) then as we drive the car around (or perhaps more scientifically on a rolling road) we should be able to deduce the map - especially as we know how many maps there are (from the unlocked ECU maps that are around) and what format they take.

 

How far could you get on the bench? I was wondering if you could inject signals mimicking what would come from the real sensors... perhaps with another Raspberry Pi with an array of D-A converters?

 

Jonathan

[Jonathan Kay]

My desk vibrates when you rev it! ;-)

Just Bluetooth and the battery on the wheel? No other wiring?

And could you develop it so that the display could be either in the wheel or higher in the line of sight to see which works better?

Jonathan

[Purplemeanie]

Jonathan,

  the idea behind my wheel computer is to have the electronics on the wheel doing the display and the main processing in a Raspberry Pi sat under the dash and connected to the OBD port of the car.

  I toyed with the idea of having this wheel computer as a dash mounted display... but I got to thinking that the wheel would often be in the way and then it struck me that putting it on the wheel would make more sense. Once I'd built a 3D model of the wheel (and the electronics I thought I could get away with) then I thought it would probably work (I was going to say fly... but I hope it doesn't do that).

  I've also mocked up a few solutions using larger screens and different LED strip layouts. But I think a bigger screen would drain a battery too much and other LED options would be too bright and lower "resolution".

  I've built a number of these sorts of things over the years and I think it will work... battery life might be a problem but I've left room for more battery capacity in case its a problem. If it can last 6 to 8 hours then that'll be fine for what I'm thinking.

  A dash mounted unit would be possible though. And I might knock one up to see how that works too.

  I've also toyed with the idea of creating a head-up-display. The angle of a Caterham wind screen doesn't seem too conducive to a HUD but I might give that a go too at some point. I really like the one I have on my Beemer, and so that might be the ideal display.

  Something I prototyped a few years ago using similar technology (it's an alerting device for people who are deaf - yes people who are deaf do use phones... they use videophones! :-) ). So the idea is that the top LED array would be able to show a shift-light configuration but would also be able to scroll text/data if I wanted. The brightness of these things will need to adjust with ambient light levels and I've found that any LED array also needs a difuser in front of it... all things that'll go into the wheel-computer... along with indicator buttons and indictor self-cancelling gyro setup (yeh... I know Beemer drivers don't usually use indicators... but there are exceptions!).

 

John

[CtrMint]

@Jonathan, Anything is possible with regards inputs.  

Some months back I'd looked into fitting infrared (contactless) thermal sensors.  I initially thought about fitting one either side of the radiator ports to measure temps pre and post cooling.  The idea came about following discussions relating to overcooling etc.   I then went on to look at possibly fitting 4 sensors for each of the exhaust headers.  I thought that would be interesting as it would show which of the cylinders was working hardest etc.   Due to cost I've now decided to move away from such an idea.  Sensors which cover the temperatures needs were just too expensive for such curiosity.

 

[Purplemeanie]

If anyone's interested then I've got the bulk of the posts finished on all of this on my website here:

https://www.purplemeanie.co.uk/index.php/2019/08/31/ecu-diagnostics-part-1-introduction/

If anyone finds any errors or omissions then I'll be more than happy to correct and/update. I'm still learning lots about the car's ECU and will keep posting to my blog when I find things.

And as always, I'm sure you'll find my site a great cure for insomnia if you ever need one - there's over 26,000 words or write up on this ECU topic already! :-)

John

[CharlesElliott]

That's a great resource John. Whilst your comment about one CAN device is true for sending data, the rev counter is also on the CANbus and provides digital signals to most of the instruments. I think it uses some sort of PCM but I never looked into it. 

[Purplemeanie]

Hi Charles,

thanks for that info.

I think that then makes a lot more sense if the rev-counter uses the default broadcast OBD data - what I called MBE-Broadcast in my blog posts. It was bugging me that it must be there for a reason and I had thought that perhaps the shift-lights shipped with many cars were the reason for the broadcasts to be there. But it makes sense that the rev-counter might use it. I had also thought that it might be a hang over from the days of stacked-dashes.

I've updated the CAN bus post on my blog along with the MBE-Broadcast post too.

If I get some time I might see if I can make sure it's the MBE-broadcast protocol that's definitely being used by the rev-counter. CAN bus is certainly not a PCM signal but should be simple enough to check what the rev-counter is doing from the wiring and maybe even do some tests with a CAN bus gateway to inject some dummy data into the rev-counter if it does indeed use CAN bus.

John

[ Edit: having done some more research with the build manual wiring diagram I'm not so sure now that the rev-counter is on the CAN bus. I'll need to do some more digging around and will post back here when I find out, or someone else can chime in]

[CharlesElliott]

Hi John

yes, it's not PCM into the rev counter but the feed out to the gauges (eg the fuel gauge) is a PCM like signal rather than the pure analogue signal that comes into the rev counter. (The fuel gauge isn't on the CANbus but it seems similar for all outputs). 

Charles 

 

[Purplemeanie]

Hi Charles,

having done some more research with the build manual wiring diagram I'm not so sure now that the rev-counter is on the CAN bus. I'll need to do some more digging around and will post back here when I find out, or someone else can chime in.

John

[CharlesElliott]

CAN H/L are definitely in the multi connector on the back of the rev counter. UR and SR. Although that doesn't define what they are and aren't used for!

 

[Purplemeanie]

Hi Charles,

  I think I see where I'm getting confused - though I need to double check everything.

  On checking the Sigma wiring diagram it seems there is CAN bus there. But there's no sign of it on the 420 Duratec wiring diagram (my car) for the tacho. I'll need to do some more research and probably make sure I'm more specific that I'm only talking about Duratec and possibly even only 420 on my Blog.

John

[CharlesElliott]

Yes, it does look like that from the R400 diagram. Could well be a different tacho. 

[aerobod - near CYYC]

The R400 instruments use analogue signals, but are driven by stepper motors.

[sf4018]

Hi all, new to the site, good to meet you all. I'm going to throw one more nugget of info into the mix. I recently built a 420R here in the US and developed a CAN bus configuration file for my AiM Motorsports gear (Solo2DL/Smartycam/etc). I'm guessing it would work (or at least be close) for the other Duratec model variations. AiM also added a CAN config to their standard list in Race Studio 3 for a Caterham 420R, but it's a little different and cannot be customized. I couldn't see a way to upload a non picture file, so if anyone wants the AiM Race Studio 3 .xc1 file, DM me!

Here's a screen grab of the gear in action....

It's a bit ropey visually but proof of concept is good.

For my car at least no throttle input gives 23.5% (60 decimal), max throttle is 93.7% (239 decimal), so I customized the scaling to convert this odd range of 60-239 decimal to 0-100%. I can't make sense of why it's like that, but it works.

Cheers

Simon

[aerobod - near CYYC]

Closed throttle is normally just over 1.2V and full throttle around 4.7V on the TPS for a throttle bodied 420R / R400. Your car at 23.5% of 5V would be 1.18V at idle and 93.7% of 5V would be 4.69V at full throttle, so sounds correct when measuring throttle opening based on voltage.

[Jonathan Kay]

Welcome, Simon.

I couldn't see a way to upload a non picture file...

It is possible, see eg the Bolt List. It should also work by linking to the file on an external server, as in the Forum User Guide.

Jonathan

[CtrMint]

@sf4018, love the AIM products, though they are quite expensive.

I'm still working on the project.  Although I have far less time at present, so development has slowed some what.

I'm also at a bit of a cross roads, unsure what to do with the display in the car.  The 'logging' element is complete, however I'm looking for the best analytical platform for the data.  This got me thinking whether there is any advantage in an open community based analysis platform?  

For the cost of a Raspberry Pi, 30 to 40GBP and a cable it's possible for anyone with the current generation ECU to log a choice of values during a drive.  Logging could be to flash card.  These values could then be uploaded a community environment, for open analysis or visibility, including shared diagnostics and reference.  Hopefully helping questions like, my car does this should it do that?  I suspect there would be benefits in awareness of minor design flaws, I know many people have suggested the cars are overcooled.  Note speed is not present, only RPM so no issues there.  You'd also be able to select which values to log anyway.

From a tooling perspective, I would suggest Elasticsearch, it packs the capability for 'big data' not that I suspect the data would be that big, but it does have the analytical tools to provide useful insights and charting.  Elasticsearch is free, although lacks security so a authorization product would need to sit on top.  This might be as simple as OpenSSH creating a tunnel.

Am I right out there on my own with this?  Or would there be general interest for it?

 

[sf4018]

I've uploaded the AiM CAN protocol .xc1 file to here....

Caterham_Seven 420R_@20190725_002350_002469.xc1_.gdb

...just download this file and delete the "_.gdb" suffix. The file is used by Race Studio 3 software. 

Simon

[John Vine]

Re #120:

Closed throttle is normally just over 1.2V and full throttle around 4.7V on the TPS for a throttle bodied 420R / R400.

My 2008 R400D on RBs is pretty much the opposite (according to Easimap):

Closed:
Throttle Site=0.0
Throttle Angle=4.66v

WOT:
Throttle Site=15.1
Throttle Angle=0.92v

JV

[aerobod - near CYYC]

Hi John, RBs are completely different in TPS setup, they also use the unconventional Cosworth voltage setting that decreases as throttle opens. According to SBD Motorsports, Cosworth wired up the TPSs accidently the "wrong" way around when they started using them and haven't changed since - urban legend perhaps, but from a source who may well know the truth!