Instructions to change fuel maps on 14CUX Griffith, Chimaera

Instructions to change fuel maps on 14CUX Griffith, Chimaera

Author
Discussion

danbourassa

246 posts

136 months

Friday 6th September 2013
quotequote all
blitzracing said:
This is the bit that gets me. We have a preset voltage value for the CO trim in closed loop, but Ive not managed to see any effect, certainly on the mixture or short term trim values. Are we saying this voltage will be a starting point for the long trim mid point?
I don't understand this as well as I would like. It seems that the long term trim eventually reacts to some statistics that are being kept, probably to keep the short term centered for best dynamic range. I do remember an earlier post where someone had 100% long term and brought it into range with the CO trim. I don't remember if before and after voltages were stated. That would be useful info.

davep

1,141 posts

283 months

Saturday 7th September 2013
quotequote all
Dan, I’m still trying to figure a basic internal flow for the firmware and I see from their pattern and repeat frequency that the entries in C7A9: suggest some form of Check Value/A-D Conversion Sequence, i.e.:

C7A9 : 87 86 02 03 84 02 8D 88 02 8B 80 85 81 8E FA FA

7 – Road speed
6 – Air Conditioner load
2 – Airflow
3 - Throttle pot position
4 – Coolant temperature
2 – Airflow
D – O2 sens. Ref. V
8 – Main Voltage
2 - Airflow
B – Fuel temperature
0 – Inertia switch
5 - Gearbox neutral switch
1 – Heated rear screen
E – Diagnostics

With no entries for C and F – O2 sensors, nor 9- AFM sensor voltage and A – Tune resistor (as your cars are NAS I guess).

The sequence in my promimage Fuel Map 2 is:

C44A : 87 86 02 03 84 02 8D 88 02 8B 80 85 81 09 8E FA

So 9- AFM sensor voltage is checked and one of the FA resets is dropped.

Am I barking up the wrong tree? If not any ideas as to why Airflow is converted three times in each sequence and when is this table setup?


Edited by davep on Saturday 7th September 12:02

danbourassa

246 posts

136 months

Saturday 7th September 2013
quotequote all
Dave, the O2 sensors are measured in the spark interrupt routine. Just one is measured each time through. They alternate. The MAF or throttle pot is also measured again in this interrupt since these are the most important inputs (and the quickest to change). The tune resistor IS measured by the last entry. The A in FA indicates channel A which is the tune resistor. The F sets a flag to terminate the list after this last measurement is complete. All maps measure channel 2 (air flow) but only open loop maps measure channel 9 (CO trim).

stevesprint

Original Poster:

1,114 posts

178 months

Sunday 8th September 2013
quotequote all
danbourassa said:
I didn't know there was an inline resistor. Colin and I did a little experimenting with the road speed input a few month ago. I think we determined that pulse amplitude was not important.
On a John Eales ECU plug wiring diagram I received 13 years ago the road speed sensor reed switch is protected by a diode. More recently I’ve noticed the following on the ACT website about 1/3 down the page.

“The signal should go up and down between 0-2.0 Volts and 10.5-13.0 Volts, changing every 4-5 metres. This signal is 8000 pulses per mile”.
“The reed switch is mounted on a simple circuit board in series with a 120 Ohm resistor”.

http://www.actproducts.co.uk/2011/lucas-14cux-fuel...

So I don’t know what is correct, or maybe it should have both !!!

blitzracing

6,387 posts

219 months

Monday 9th September 2013
quotequote all
Its just needs a 12v square wave input.

stevesprint

Original Poster:

1,114 posts

178 months

Tuesday 10th September 2013
quotequote all
A fun night in with an Ostrich

With the engine running I copied a complete image with a weaker map to the Ostrich and the idle dropped for a moment, RoverGauge displayed the updated map after disconnecting and reconnecting. I then copied my standard map back to the Ostrich and the idle picked up for a moment and again RoverGauge displayed the changes after disconnection and reconnecting.

robertf03

59 posts

200 months

Tuesday 10th September 2013
quotequote all
Very nice Steve. I've emailed Mark (the author of Tunerpro) for the SDK, hopefully we'll be able to live tune these things soon. Have you had any problems changing ROMS on the fly? (i.e. does it throw a checksum error?) Maybe Collin knows, is the checksum evaluated after start up?

For those that don't know, the ostrich 2.0 has address tracing capabilities. I haven't used it, as my ostrich 2.0 is dead and I haven't bothered to RMA it since my original 1.0 still works.

One of the really cool things that tunerpro can do, that most of the high end aftermarket ecm tuning software also does, is it can have a diagnostic program implemented in it and created a floating red box over the table that you are currently editing so you know what cell you are at. You can rip out a fuel table in no time on a steady state dyno.

Edited by robertf03 on Tuesday 10th September 02:28

stevesprint

Original Poster:

1,114 posts

178 months

Tuesday 10th September 2013
quotequote all
Further to my science experience on an Ostrich last night, and to answer an email, I must clarify I was updating the whole prom image in one hit via emutility. I reduced every value in map 2 and the ajdustment factor down by 10 in hex just to prove updates take immediate effect and yes they do!!!

The moment of truth comes next, will an individual map entry updated via TunerProRT also have an immediate effect? Do we need to correct the checkksum in real time? Stay tuned for the next instalment, Dun! Dun!! Dunnn!!!


stevesprint

Original Poster:

1,114 posts

178 months

Tuesday 10th September 2013
quotequote all
robertf03 said:
Have you had any problems changing ROMS on the fly? (i.e. does it throw a checksum error?)
NO, it didn’t throw a checksum error on the fly when I switched maps at idle and my second map did have a checksum error, I guess that’s a useful test in itself. I'll do some further testing to see when the checksum is tested.
It would be good for TuneProRT to correct the checksum on the fly and ready for copying to EPROM. At least the checksum error has no ill effect on a running engine and therefore could be corrected afterwards ready for copying to EPROM. Please note I have edited this message, sorry.


Edited by stevesprint on Tuesday 10th September 18:42

stevesprint

Original Poster:

1,114 posts

178 months

Tuesday 10th September 2013
quotequote all
YES !!! - I’ve re-mapped my 14CUX in Real-Time!!! - Have I made 14CUX history???

Before – Watch the bottom line of the map


After – RoverGauge displays the amended map without turning off the engine.


I must thank Robert for his TunerPro defination file, Spitfire4v8 for the loan of his Ostrich, Colin/Dan for cracking the secret addresses in the black box and Mark for his Lambda box and tech support.
This wouldn’t have happened without all the different skills from around the world pulling in the same direction. I’m going to crack open a beer.

CHEERS!!! Steve (re-mapper) Sprint

P.S. Although we now have a workable solution we still need to add tuning features to TunerPro and simplify the checksum.

cmb

103 posts

174 months

Wednesday 11th September 2013
quotequote all
stevesprint said:
O, it didn’t throw a checksum error on the fly when I switched maps at idle and my second map did have a checksum error, I guess that’s a useful test in itself. I'll do some further testing to see when the checksum is tested.
It would be good for TuneProRT to correct the checksum on the fly and ready for copying to EPROM. At least the checksum error has no ill effect on a running engine and therefore could be corrected afterwards ready for copying to EPROM. Please note I have edited this message, sorry.


Edited by stevesprint on Tuesday 10th September 18:42
If we're talking about the ROM checksum, then you'll only see an error if it's bad when the ECU is turned on. There's a bit that gets set in RAM when the ROM test is complete, and the test is not run again after that.

Ribol

11,199 posts

257 months

Wednesday 11th September 2013
quotequote all
stevesprint said:
YES !!! - I’ve re-mapped my 14CUX in Real-Time!!! - Have I made 14CUX history???
Well done clap Would this be how the likes of Mark Adams do it, or is this another/new way?

For those of us not blessed with geekness.................

I'll take a wild guess that the numbers running across horizontally 200 > 5502 are RPM?

In which case are the numbers running vertically 13 > 100 a way of describing conditions/load for want of better words?

At say 2000rpm you have changed the value @ 100 from FC to EC, is that the quantity of fuel supplied by the injectors dictated by the map? Could you explain the significance of those letters rather than numbers?

Sorry for the no doubt daft questions but on behalf of myself and anyone else who also doesn't get it, but is too embarrassed to ask, I thank you hehe

spitfire4v8

3,990 posts

180 months

Wednesday 11th September 2013
quotequote all
the numbering/lettering is a way of getting a bigger range into the digits .. the range goes from zero to F so you start counting zero,one, two .. nine, A,B,C .. F so you get a range of zero to 16 in real terms. put that into two digits and you get zero to 16 times 16 , or in our terms a range of zero to 256. see here
http://en.wikipedia.org/wiki/Hexadecimal

Edited by spitfire4v8 on Wednesday 11th September 08:12

Ribol

11,199 posts

257 months

Wednesday 11th September 2013
quotequote all
http://www.statman.info/conversions/hexadecimal.ht...

So Steve has changed value from 252 to 236 and this is a measure of the amount of fuel supplied, weakened in this example?

davep

1,141 posts

283 months

Wednesday 11th September 2013
quotequote all
Nice one SteveSprint!

I've been playing with TunePro and Robert's xdf file and I've the same fuel table as your pre-mapped example (needs a table title change):



It's really useful to be able to compare maps in this way. I've always thought my chip had been re-mapped as part of an engine upgrade, from the comparison with yours clearly it hasn't.

Let us know what changes in fueling you achieve.

LongBaz383BHP

2,087 posts

216 months

Wednesday 11th September 2013
quotequote all
Morning Steve
Can I be the first to purchase this system. I am sure it would be invaluable to sorting out my lean running at higher revs N/A. Also for checking fueling when running the nitrous.
Thanks for all your hard work and what look like late nights.
Cheers
Barrie

Sardonicus

18,928 posts

220 months

Wednesday 11th September 2013
quotequote all
Got to take my hat off to this post and it's contributors best thing I have read in an Ice Age on PH bow well done fella's thumbup

blitzracing

6,387 posts

219 months

Wednesday 11th September 2013
quotequote all
The next challange now is to turn off the lambda feeback so the ECU does not correct the mixture on the fly and alter your gas readings as you make changes to the map. Mark Adams described it as trying to put up a level shelf on a moving boat..... If I get a spot at the weekend Ill try running the cat map without probes connected and see if it drops back to limp home map. If it does not, and simply runs with 0% fuel trim, Id say let the mapping commence. smile

spitfire4v8

3,990 posts

180 months

Wednesday 11th September 2013
quotequote all
blitzracing said:
The next challange now is to turn off the lambda feeback so the ECU does not correct the mixture on the fly and alter your gas readings as you make changes to the map. Mark Adams described it as trying to put up a level shelf on a moving boat..... If I get a spot at the weekend Ill try running the cat map without probes connected and see if it drops back to limp home map. If it does not, and simply runs with 0% fuel trim, Id say let the mapping commence. smile
this is the stage we need to get to to map cat cars .. I can't believe at this moment that the lucas lambda control is so rubbish that it makes mapping in closed loop such a lottery, but of course I won't know until it's been tried.

robertf03

59 posts

200 months

Wednesday 11th September 2013
quotequote all
Is the spark interrupt routine stored on the chip and could we remove the call to the o2 update?