Instructions to change fuel maps on 14CUX Griffith, Chimaera

Instructions to change fuel maps on 14CUX Griffith, Chimaera

Author
Discussion

davep

1,143 posts

284 months

Monday 2nd November 2015
quotequote all
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Steve, JOOI which tune and map are you running there?

MPO

264 posts

112 months

Monday 2nd November 2015
quotequote all
davep said:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Steve, JOOI which tune and map are you running there?
Dave

You know Steve :-)

You should see mine, nothing standard anymore... :-)

Got a Wide Band on your Xmas List?

MPO

davep

1,143 posts

284 months

Monday 2nd November 2015
quotequote all
MPO said:
You should see mine, nothing standard anymore... :-)
Got a Wide Band on your Xmas List?
Spill the beans then Glyn.

It's sort of on there, so fingers crossed ... that's if I still have the Griff, decisions, decisions.

stevesprint

Original Poster:

1,114 posts

179 months

Monday 2nd November 2015
quotequote all
Today's Google home page reminds me of the 14CUX team.



Colin and Dan
Did you have the same google home page on George Boole 200th Birthday??

Cheers
Steve smile

danbourassa

246 posts

137 months

Tuesday 3rd November 2015
quotequote all
stevesprint said:
Today's Google home page reminds me of the 14CUX team.

Colin and Dan
Did you have the same google home page on George Boole 200th Birthday??

Cheers
Steve smile
No, we have Day of the Dead (Dia de los Muertos). I didn't realize until now that it varies by country.

Does anyone know if the 14CUX has a MAF hot-wire burn-off cycle? If so, I imagine that the control for it must be contained entirely in the MAF which can tell when the engine stops.

davep

1,143 posts

284 months

Tuesday 3rd November 2015
quotequote all
stevesprint said:
Today's Google home page reminds me of the 14CUX team.



Cheers
Steve smile
Steve, poor old NOR and NAND don't get a mention, you're always leaving them out! I'm sure there's a 'logic' for the selected functions but I can't fathom it.

I prefer Venn (he never gets a mention does he) diagrams, much prettier.

davep

1,143 posts

284 months

Tuesday 3rd November 2015
quotequote all
danbourassa said:
No, we have Day of the Dead (Dia de los Muertos). I didn't realize until now that it varies by country.

Does anyone know if the 14CUX has a MAF hot-wire burn-off cycle? If so, I imagine that the control for it must be contained entirely in the MAF which can tell when the engine stops.
Dan, wouldn't the amount of current needed to do a burn-off require a separate relay controlled supply? Hotwire temperatures for burn-off are very high I believe.

davep

1,143 posts

284 months

Tuesday 3rd November 2015
quotequote all
Just a thought but now that 14CUX Wideband O2 sensing, AFR logging and MAF scaling is becoming the norm, will it be worthwhile looking at getting tighter control on injector bank scaling and latency via code changes (TunerPro), since we have handles on cranking enrichment, air flow and battery (main) voltage? Parameters such as flow rate and pressure shouldn't be too difficult to fathom out.

blitzracing

6,387 posts

220 months

Tuesday 3rd November 2015
quotequote all
danbourassa said:
No, we have Day of the Dead (Dia de los Muertos). I didn't realize until now that it varies by country.

Does anyone know if the 14CUX has a MAF hot-wire burn-off cycle? If so, I imagine that the control for it must be contained entirely in the MAF which can tell when the engine stops.
I dont think its that clever- but you do a get a big spike on the output on initial turn on, but this is due to a cold wire, so little resistance until the wire heats up and the voltage stabilises. The circuits inside seem to be just current regulation and op amps to amplify the voltage change. More to the point you also loose the 12 volt feed when the ignition goes off, so you cant do anything then anyway.

Griffian

22 posts

101 months

Sunday 8th November 2015
quotequote all
Hi, I'm a recent returnee to PH having been lurking but inactive since the days when P stood for Petrol!

I have Griff 500 with mostly standard engine/induction setup. Having been chasing a nasty intermittent misfire problem for almost 2 years, I have avoided any mods till now. I think I have finally resolved the problem which was some fused tracks on the ECU PCB. I'm now keen to fit the intersesting bits I've accumulated to make the car breathe better.

I have been fascinated and impressed by the progress of Rovergauge and the firmware and remapping work. Having been in the 8-bit world 'back in the day', including a passing aquaintance with 6502 assembler, I'm comfortable with the patching and tweaking, burning PROMS etc. and I'm interested to delve deeper, and help the joint effort if I can.

Apologies if I've missed something in trawling the 48 forum pages (and the stevesprint guides), but I have a few status questions:

1) Has anyone sucessfully done a DIY remap to cater for the 20AM or Bosch AFMs? I saw that Dan was taking about tweaking the linearisation algorithm but couldn't see if that was successful. I assume the other method is just compensate in the fueling map even if the load points are unevenly spread.

2) I saw Steve's prebuilt hybrid firmware and wondered if anyone had done an extended rev table with a 500 fuel map? Perhaps on R3652 if there is any advantage.

3) Lastly (for now), how's the work on an optimised home-brew ECU image? I gather that a few people had ideas on speeding up rev and roadspeed calculations and the idea of hijacking the heater A-D channel for wideband sounded great.

Just to throw a tiny bit of reciprocal info back the other way:

The Airies 526 28 pin ZIF socket is low profile and fits well in the turned pin PROM socket on the 14CUX. I know from ancient experience the de-facto standard green Textool ones usually require you to desolder the socket.

http://uk.farnell.com/aries/28-526-10/skt-dil-zif-...

I have ordered a TL866CS PROM burner for about £35-40 which looks to be widely compatible and works with 64 bit windows. Will send a link if it turns out to work!

Keep on Tivving!

Edited by Griffian on Sunday 8th November 16:15


Edited by Griffian on Sunday 8th November 16:17


Edited by Griffian on Sunday 8th November 16:24


Edited by Griffian on Sunday 8th November 16:28

cmb

103 posts

175 months

Sunday 8th November 2015
quotequote all
stevesprint said:
Colin
Brilliant, thanks.

The Row scalar always displays correctly and the RPM limit also displays correctly if you start the engine before connecting. However, I’ve noticed if you connect before firing up the RPM limit defaults to InitialRpmLimit of 5403rpm in data.asm.

There's no rush as winter has finally arrived.
Thanks again
Steve
I'll try to address this soon -- I'm thinking it's a result of the RPM limit location only being populated after the ICI has been run.

stevesprint

Original Poster:

1,114 posts

179 months

Monday 9th November 2015
quotequote all
Griffian said:
Hi, I'm a recent returnee to PH having been lurking but inactive since the days when P stood for Petrol!

I have Griff 500 with mostly standard engine/induction setup. Having been chasing a nasty intermittent misfire problem for almost 2 years, I have avoided any mods till now. I think I have finally resolved the problem which was some fused tracks on the ECU PCB. I'm now keen to fit the intersesting bits I've accumulated to make the car breathe better.

I have been fascinated and impressed by the progress of Rovergauge and the firmware and remapping work. Having been in the 8-bit world 'back in the day', including a passing aquaintance with 6502 assembler, I'm comfortable with the patching and tweaking, burning PROMS etc. and I'm interested to delve deeper, and help the joint effort if I can.
Griffian
Welcome back and thanks for your kind words, you’re old 8-bit skills should come in handy. I’m pleased to hear you’ve finally resolved your misfire but I must know if your misfire was always at the same rpm point or at random rpm???

Griffian said:
1) Has anyone sucessfully done a DIY remap to cater for the 20AM or Bosch AFMs? I saw that Dan was taking about tweaking the linearisation algorithm but couldn't see if that was successful. I assume the other method is just compensate in the fueling map even if the load points are unevenly spread.
Jools has successfully remapped and rescales several 500’s running 20AM by changing the AFM scalar in map 5. See “AFM Table Row Scalar” on my Prom address page @ http://www.stevesprint.com/remap-14cux/addresses.h... .

Griffian said:
2) I saw Steve's prebuilt hybrid firmware and wondered if anyone had done an extended rev table with a 500 fuel map? Perhaps on R3652 if there is any advantage.
It would be a pleasure to knock up a 500 firmware with the extended RPM and my R3652 as I’ve don’t a lot of work on the startup and slowing down idle but I don’t know how it will effect the fuelling as the 500's bottom row is rich then goes lean and rich again. ($FF,$FF,$FF,$FF,$F5,$FD).
Griffian said:
3) Lastly (for now), how's the work on an optimised home-brew ECU image? I gather that a few people had ideas on speeding up rev and roadspeed calculations and the idea of hijacking the heater A-D channel for wideband sounded great.
I’ll let Dan answer this one, no pressure Dan. The main issue is the processor runs out of time to output log records above 5,000 rpm. I’ve now realised logging the wideband though RoverGauge would make matters worse but MPO and I have been successfully merging our LC2 wideband logs with the RoverGauge log. Do you already have a wideband sensor????


Griffian said:
I have ordered a TL866CS PROM burner for about £35-40 which looks to be widely compatible and works with 64 bit windows. Will send a link if it turns out to work!
Please let us know how your TL866CS PROM burner works on 64-bit Windows.

Griffian

22 posts

101 months

Tuesday 10th November 2015
quotequote all
Thank you for your very in-depth reply.
stevesprint said:
... I must know if your misfire was always at the same rpm point or at random rpm???
It was random or possibly temperature related - it could go OK for hundreds of miles then suddenly drop into a misfire 'mode' so serious that the engine would barely run and certainly wouldn't idle without throttle. This could persist for minutes at a time but sometimes resolved with a full switch-off and restart. I suspected everything from the fuel pump to EMI from a phone charger.

When checking the ECU for dry joints, I found almost literally a smoking gun. There were scorch marks on the inside of the ECU case and about 6-7 obviously blown earth tracks on the rear of the PCB near the connector but no obvious component damage. Further examination revealed a couple of clean unburnt breaks in the earth plane which were under the lacquer on the top side of the board. I don't know what triggered the fusing, but I suspect the 'original' breaks may have meant some overloading of thinner tracks. Anyway, I made a temporary repair by soldering extra copper wires all over the place which seemed to work but I no longer trusted it so have now replaced it with one from a newer Disco after swapping the PROMS. I can't be sure its solved until I've put some more miles on it but so far, so good!

stevesprint said:
Jools has successfully remapped and rescales several 500’s running 20AM by changing the AFM scalar in map 5. See “AFM Table Row Scalar” on my Prom address page @ http://www.stevesprint.com/remap-14cux/addresses.h... .
Ah yes, I remember reading about scaling and offsets now. I'll have another look. I have a 2nd hand Lucas 20AM and a Bosch AFM neither of which I've tested yet, but I'm favouring the 20AM even though it's narrower as it's probably not going to outflow standard 500 heads, should be simpler to rescale and will look more 'period' under the bonnet.

stevesprint said:
It would be a pleasure to knock up a 500 firmware with the extended RPM and my R3652 as I’ve don’t a lot of work on the startup and slowing down idle but I don’t know how it will effect the fuelling as the 500's bottom row is rich then goes lean and rich again. ($FF,$FF,$FF,$FF,$F5,$FD).
Thanks - I'm very grateful. Hmm, that last row does look odd and in fact the earlier rows also show dips and/or tailing off towards higher revs. On the assumption that the 500 is airflow restricted, I can see why it might not be a big deal that the fueling doesn't increase after 5500 RPM. On the second assumption that replacing AFM and trumpets and widening the throttle will overcome that, I guess that the multiplier would need upping a little and the (squashed in 2 dimensions) original table values would need reducing proportionately so that the new bottom right of the map could give a little more fuel.

stevesprint said:
I’ve now realised logging the wideband though RoverGauge would make matters worse but MPO and I have been successfully merging our LC2 wideband logs with the RoverGauge log. Do you already have a wideband sensor????
Not yet, but I'm thinking it will be the best way of remapping. I know I should probably just get one of the established experts to do it, but I get a perverse pleasure from understanding how things work and doing it myself. I do have a MIG welder and some stainless wire, but don't know how big the boss would be and where to put it - does it need to be the first point the banks merge or can it be further downstream? I'd be more comfortable hiding it in a thicker, cheaper section in case I cock it up.

Feel free to suggest taking some of this dialogue offline or to a different topic if it's becoming OT.

blitzracing

6,387 posts

220 months

Tuesday 10th November 2015
quotequote all
Griffian said:
On the assumption that the 500 is airflow restricted, I can see why it might not be a big deal that the fueling doesn't increase after 5500 RPM. On the second assumption that replacing AFM and trumpets and widening the throttle will overcome that, I guess that the multiplier would need upping a little and the (squashed in 2 dimensions) original table values would need reducing proportionately so that the new bottom right of the map could give a little more fuel.
There is a bit more to it than that- the engines volumetric efficiency is dropping off towards 6000 rpm, so you have to back the fuelling off to compensate for the drop in available air in the combustion camber. This allows the peak BHP to be maintained for longer, as if you leave the fuelling as is from 5400 rpm it runs too rich- nice and safe, but not good for power.

danbourassa

246 posts

137 months

Wednesday 11th November 2015
quotequote all
Griffian said:
3) Lastly (for now), how's the work on an optimised home-brew ECU image? I gather that a few people had ideas on speeding up rev and roadspeed calculations and the idea of hijacking the heater A-D channel for wideband sounded great.
Hi Griffian,

You're very welcome to join our team! Stock shares in assembly language programmers are on the rise.

http://www.theregister.co.uk/2015/10/31/brush_up_o...

I have lots of ideas for improving the 14CUX code. Some are simple, such as deleting obsolete and ineffective code (there is a surprising amount). Some are more complicated. The main goal is to have a little breathing room at max RPM. Right now it looks like the processor is 100% utilized at about 5000 to 5500 RPM. As noted earlier, serial port communication then grinds to a halt. I don't even understand how the system appears to function up to 6000 RPM and beyond.

Work on the 14CUX code is usually seasonal for me so I haven't done much lately but it's time to get back into it.

stevesprint

Original Poster:

1,114 posts

179 months

Friday 20th November 2015
quotequote all
Griffian said:
It was random or possibly temperature related - it could go OK for hundreds of miles then suddenly drop into a misfire 'mode' so serious that the engine would barely run and certainly wouldn't idle without throttle. This could persist for minutes at a time but sometimes resolved with a full switch-off and restart. I suspected everything from the fuel pump to EMI from a phone charger.
What a nightmare, sounds very random and annoying, interesting an ECU reboot sometimes resolved it.

Griffian said:
I made a temporary repair by soldering extra copper wires all over the place which seemed to work
Was their any signs of water ingress, anyway sounds like you’re also very handy with a soldering iron.

Griffian said:
Ah yes, I remember reading about scaling and offsets now. I'll have another look. I have a 2nd hand Lucas 20AM and a Bosch AFM neither of which I've tested yet, but I'm favouring the 20AM even though it's narrower as it's probably not going to outflow standard 500 heads, should be simpler to rescale and will look more 'period' under the bonnet.
You’re right to favour the 20AM as Mark Blitz has pointed out the output curve of the 20AM is very similar shape to the 5AM where as the Bosch output curve is different and therefore involve remapping more cells in the main fuel table to compensate.
Griffian said:
Thanks - I'm very grateful. Hmm, that last row does look odd and in fact the earlier rows also show dips and/or tailing off towards higher revs.
Here’s a link to an original Griffith 500 1995 chip that I’ve only extended the rpm points to 6250 rpm.
www.stevesprint.com/remap-14cux/bins/TVR_R2967_500...
Please use RPM’s above 3,000 rpm at your own risk especially while you don’t have an AFR sensor/Gauge.

Griffian said:
On the second assumption that replacing AFM and trumpets and widening the throttle will overcome that, I guess that the multiplier would need upping a little and the (squashed in 2 dimensions) original table values would need reducing proportionately so that the new bottom right of the map could give a little more fuel.
Sounds like you definitely need an AFR sensor.

Griffian said:
does it need to be the first point the banks merge or can it be further downstream? I'd be more comfortable hiding it in a thicker, cheaper section in case I cock it up.
Ideally yes for best results and least lag but it will still work further down stream. Mine is actually further down the Y piece and works perfectly well.

I personally choose an Innovate LC2 wideband sensor as it outputs about 10 records a second and makes merging with the RoverGauge log more accurate.
http://www.innovatemotorsports.com/products/lc2.ph... I mounted the controller behind the right headlamp as it causes interference on the radio.

If you buy a different Wideband sensor I’ll certainly try and help you merge your AFR log with RoveGauge but no guarantees I’ll make it work.

Griffian

22 posts

101 months

Sunday 22nd November 2015
quotequote all
stevesprint said:
Was their any signs of water ingress, anyway sounds like you’re also very handy with a soldering iron.
No obvious water, just scorching. You might not be so complimentary if you saw it wink

stevesprint said:
Here’s a link to an original Griffith 500 1995 chip that I’ve only extended the rpm points to 6250 rpm.
www.stevesprint.com/remap-14cux/bins/TVR_R2967_500...
Please use RPM’s above 3,000 rpm at your own risk especially while you don’t have an AFR sensor/Gauge.
Thanks - I'll have a look at that. I have now spent some time analysing the rev table and the corresponding code. I think I've found some extra information and perhaps a simpler/safer way of doing this now. I'll put up a separate post with my theory.

stevesprint said:
Ideally yes for best results and least lag but it will still work further down stream. Mine is actually further down the Y piece and works perfectly well.

...

If you buy a different Wideband sensor I’ll certainly try and help you merge your AFR log with RoveGauge but no guarantees I’ll make it work.
Thanks for the offer but I'm sure one of the ones you have already worked on will be fine. I had further thoughts about placement:

I'm not keen on adding an O2 sensor at the Y piece, and any further down will be after the main cat so I guess will also skew the readings further. I only plan to put the sensor in temporarily when remapping.

What I'm considering now is to do the Joolz trick of duplicating my map from 5 to 2 and frigging the tune resistor to go open loop. Then I thought I could run with the wideband sensor in place of one of the standard sensors whilst I log it? It would obviously only measure one bank, but Im guessing it's a similar level of inaccuracy to a blended reading after the cat.

If the map starts out reasonably close, I would think there's not too much risk of frying the cat given that it normally runs open loop at higher revs anyway.

Standing by to be told how crazy an idea this is...

blitzracing

6,387 posts

220 months

Monday 23rd November 2015
quotequote all
Problem is tread size- the 14CUX Lambda sensors have a have much smaller thread that a wideband one- so you cant fit one there. You best bet is to weld a new boss on for the larger sensor. The 2 sides of the V8 dont fuel perfectly evenly, so if you remove lambda feedback, and fit a wideband on one side only you will get a slightly skewed reading- but its not a major issue, considering how crude it is at best anyway.

Griffian

22 posts

101 months

Monday 23rd November 2015
quotequote all
blitzracing said:
the 14CUX Lambda sensors have a much smaller thread than a wideband one
Thanks for telling me that. I'd read that they were all 18mm but now I see that the Titania ones also come in 12mm. DOH!

Looks like I'll have to put it in the Y-piece above the main cat then. I'm really not sure my welding skills (or MIG) are up to that so I think I'll get someone with a TIG to fit the boss. I presume there's nothing to hit inside with the drill/cutter until you get down to the parallel section.

stevesprint

Original Poster:

1,114 posts

179 months

Wednesday 25th November 2015
quotequote all
Griffian said:
Thanks - I'll have a look at that. I have now spent some time analysing the rev table and the corresponding code. I think I've found some extra information and perhaps a simpler/safer way of doing this now. I'll put up a separate post with my theory.
Sounds very interesting and can’t wait to see your theory. Do you mean safe for the mixture ie not dangerously lean, or safer way to amend the chip binary file or safely create a smooth RPM curve.

I'm sure you've seen in Dan's rebuild project that he has moved the RPM table to the end of the data.asm file so all the tuning parameters are together. https://drive.google.com/drive/folders/0B5NpvdM0NR... or latest source code is at https://github.com/colinbourassa/14cux-firmware

Dan has also written a standalone PC program in C to simulate how the 14CUX reads the RPM table so we can test any changes we make still produce a smooth RPM curve or in Dan's own words a "smooth monotonic function". For further information on the 4 columns of the RPM table please see the readme file with Dan's simulation program at www.stevesprint.com/remap-14cux/RpmTable.zip, also contains the 6250 RPM table.
With Dan's help I managed to update the RPM table to stretch the fuel table to 6250rpm maintaining a smooth RPM curve which you are very welcome to use or let me know if you need a hand creating your own RPM table.

Griffian said:
Thanks for the offer but I'm sure one of the ones you have already worked on will be fine. I had further thoughts about placement:

I'm not keen on adding an O2 sensor at the Y piece, and any further down will be after the main cat so I guess will also skew the readings further.
Sorry I forget I'm in the minority without cats. However I'm very curious to know how accurate the AFR readings are on a rolling road with the wideband sensor pushed up the exhaust tail pipe. Everyone seems to trust rolling road AFR readings and they are measured after the cats and with a delay.

Griffian said:
I only plan to put the sensor in temporarily when remapping.
Makes sense if you don't have a dashboard AFR gauge because the wideband always has to be powered up when installed.

Griffian said:
What I'm considering now is to do the Joolz trick of duplicating my map from 5 to 2 and frigging the tune resistor to go open loop. ...
Last year we proved in the code while running maps 1 to 3 the CO trim screw effectively gives you manual control of the long term lambda trim as they are stored in the same memory address and applied the same, plus the short term trim is disabled. Therefore when copying map 5 to map 2 you must remember to set the CO trim screw to the mid point of 1.25v or to save adjusting the CO trim screw you can disable the CO Trim analogue input as I've done in one of my maps. You must also make sure all the extended data is the same including scalars, throttle direction table, crank table and temp based adjustment table. Don't make the mistake I made and also copy the ADC mux table (input order of analogue inputs), but at least we learnt from my mistake.
Good Luck and when fitting the Lambda probe make sure its at about 10 o'clock or 2 o'clock in the pipe.
Enjoy & Cheers, Steve Sprint