Instructions to change fuel maps on 14CUX Griffith, Chimaera

[stevesprint]

robertf03 said:

I'm at the point where I think my MAF has had it at 260k.

My willem burner still barely works, might be time to upgrade to a USB programmer

Robert - Good to see you’re still knocking around here, 260K arrr that’s k’s not miles still impressive. I would pop round and lend you my AFM for the weekend if I could, its the sort of thing that happens around here.

Sounds like it’s time to treat yourself to a new eprom programmer, my TOP8563 at £30 wouldn't break the bank and has been faultless on different speed computer, apparently it doesn’t work on 64-bit Windows.

Have you ever connected your LM-1 to a computer? Do you know if the serial output is recognisable in Hyper Terminal or does it only work with Innovate software?

When you get a chance please can you upload current the 14CUX definition file to TunerPro’s website, it contains all your original tables and scalars plus more. You can download it from www.stevesprint.com/remap-14cux/TunerPro-xdf.zip

Sorry to bombard you all at once, Cheers, Steve

Edited by stevesprint on Thursday 21st November 22:41

[stevesprint]

cmb said:

Done. I just released version 0.5.1 -- check 'Options', 'Edit settings', where you'll find a new option to "Periodically refresh fuel map data".

Corrr !!! you would never receive that level of customer service in the real business world.
Jools, I’m jealous you have your very own option in RoverGauge, that's not fare.

[stevesprint]

robertf03 said:

That is miles, not km. I meant 'k' as in thousand

I have hooked up the LM-1 to a computer. It is ascii data, I've had homebrew programs log multiple serial ports(GM ALDL data, LM-1 data, and a GPS NMEA 0183 data as the vehicle had no VSS.) I have the protocol saved in an email archive at home. I'll dig around for it this evening.

I would really appreciate that, their is no urgentcy. I guess I would prefer a separate module like the LM-1 or 2 so I can choose a AFR guage to match my dash plus the analogue output is programmable.

robertf03 said:

Anyone know if a 3am is compatible with a 5am MAF?

Don't know, but if it's scaled 0 - 5v then yes, maybe Mark will know. Thanks again.

[stevesprint]

shpub said:

Be very careful with this as the timing of when data is requested from the ECU and actually received varies quite considerably, especially as the load is increased on the ECU. So this will cause jitter in the timing in that there is no guarantee that the AFM reading is actually the same reading as when the gas analyser took its reading. This is not a problem on a rolling road as the road is used to hold the mapping consistent so that one cell is used and so that the measurements that are received should be consistent. This means that response times are less of a worry as the tuner can wait until things settle down. Rolling road tuners gas analyser systems are usually faster responding which also helps a lot.

What this means is that the gas reading could be from one condition and the RG data from another without knowing how close or how far apart they are.

Is that Steve Heath the author? I couldn’t be without your Griffith and Chimaera bible, thanks, I’ve thumb though my copy so much I really need a second one. Thinking about it I’ve also got your drop links and a few other goodies of yours. We miss you at the Growl !!!

Anyway, thanks for bring the potential timing issue to my attention. However after a close examination of a RoverGauge log file I’m still feel positive and enthusiastic. RoverGauge consistently outputs 3 to 4 log records a second up 4,500rpm and only 1 - 2 records a second above 5,000rpm. This does mean at the higher revs we’ll have to drive steadily, consistently and avoid sudden engine changes, sounds like the best way to drive. The RoverGauge screen does update instantly with all unnecessary readouts turned off so hopefully the logout file won’t lag behind and if it does I add a delay to the AFR log.

The Plx wideband sensor module is very fast and outputs 10 records a second so I’ll only use the AFR records that match within 0.1 of a second of a RoverGauge Record.

I fully realise this whole process is actually quite risky especially with cats and any fuel changes will first have to be closely monitored via the dash AFR gauge to check the fuelling doesn’t goes to lean or rich.

Hopefully in the long term Colin & Dan will eventually provide the ultimate solution by reusing the windscreen heater input to log the AFR readings. In the mean time I’ll carry on playing as I’m leaning and having so much fun, plus if it actually works it’s an added bonus.

Edited by stevesprint on Friday 22 November 10:25

[stevesprint]

danbourassa said:

Here is something interesting that I just noticed. The top map is map 0 for 94 Griffith 500 (R2967, checksum $55). The bottom map is map 0 for 95 Griffith 500 (R2967, checksum $5B). We know that the later map was leaned out in the mid-range rows, but that's not why I'm posting this. If you look at the values in the 3rd last row, you will notice a couple of values that are wildly out of place. I can't believe these are not mistakes. Stranger still is that they leaned out these values along with the others.


limpHomeMap DB $21,$21,$21,$21,$1F,$1D,$1A,$19,$19,$19,$19,$19,$18,$14,$14,$14
DB $3F,$3E,$3D,$3B,$3A,$39,$39,$39,$3B,$3C,$3B,$39,$35,$30,$30,$30
DB $60,$5F,$5E,$5F,$60,$63,$61,$61,$61,$62,$60,$5F,$55,$4C,$4C,$4C
DB $92,$92,$90,$90,$8C,$90,$90,$88,$88,$84,$85,$85,$79,$6C,$6C,$6C
DB $B7,$B4,$B5,$B5,$B6,$B1,$AB,$AB,$AB,$AB,$A9,$A8,$97,$8E,$8E,$8E
DB $FF,$1C,$D7,$1C,$D7,$DA,$DD,$DE,$E8,$DD,$D8,$D8,$D3,$D3,$BF,$C9
DB $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FA,$DC,$E6,$E6,$E6,$E4,$F0
DB $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FB,$FA,$FA,$FA,$FD,$FD

limpHomeMap DB $21,$21,$21,$21,$1F,$1D,$1A,$19,$19,$19,$19,$19,$18,$14,$14,$14
DB $3F,$3E,$3D,$3B,$3A,$39,$39,$39,$3B,$3C,$3B,$39,$35,$30,$30,$30
DB $5D,$5C,$5B,$5C,$5D,$60,$5E,$5E,$5E,$5F,$5D,$5C,$53,$4A,$4A,$4A
DB $8E,$8E,$8C,$8C,$88,$8C,$8C,$84,$84,$80,$81,$81,$75,$69,$69,$69
DB $B2,$AF,$B0,$B0,$B1,$AC,$A6,$A6,$A6,$A6,$A4,$A3,$93,$8A,$8A,$8A
DB $FF,$1B,$D1,$1B,$D1,$D4,$D7,$D8,$E1,$D7,$D2,$D2,$CD,$CD,$B9,$C3
DB $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FA,$DC,$E6,$E6,$E6,$E4,$F0
DB $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FB,$FA,$FA,$FA,$FD,$FD

Dan,
I agree 1B in column 2 and 4 does look out of place, that’s what we call TVR engineering. Maybe these two tables below contain the numbers you are looking for in the 1995 map, or maybe it was deliberate as both tables have a dip in the same place, hummm 480rpm & 700rpm.

Mark 1 400 Chimmaera R2967 Checksum 9B
21 21 21 21 1F 1D 1A 19 19 19 19 19 18 14 14 14 
3F 3E 3D 3B 3A 39 39 39 3B 3C 3B 39 35 30 30 30 
5D 5C 5B 5C 5D 60 5E 5E 5E 5F 5D 5C 53 4A 4A 4A 
8E 8E 8C 8C 88 8C 8C 84 84 80 81 81 75 69 69 69 
B2 AF B0 B0 B1 AC A6 A6 A6 A6 A4 A3 93 8A 8A 8A 
FF FF D1 D1 D1 D4 D7 D8 E1 D7 D2 D2 CD CD B9 C3 
FF FF FF FF FF FF FF FF FF FA DC E6 E6 E6 E4 F0 
FF FF FF FF FF FF FF FF FF FF FB FA FA FA FD FD

Unknown 450 Chimaera R2967 Checksum E0
21 21 21 21 1F 1D 1A 19 19 19 19 19 18 14 14 14 
3F 3E 3D 3B 3A 39 39 39 3B 3C 3B 39 35 30 30 30 
5D 5C 5B 5C 5D 60 5E 5E 5E 5F 5D 5C 53 4A 4A 4A 
8E 8E 8C 8C 88 8C 8C 84 84 80 81 81 75 69 69 69 
B2 AF B0 B0 B1 AC A6 A6 A6 A6 A4 A3 93 8A 8A 8A 
FF FF D1 D1 D1 D4 D7 D8 E1 D7 D2 D2 CD CD B9 C3 
FF FF FF FF FF FF FF FF FF FA DC E6 E6 E6 E4 F0 
FF FF FF FF FF FF FF FF FF FF FB FA FA FA FD FD

I’m very surprised TVR changed the limp home maps between 1994 and 1995 as the limp home map on the Precat 400's & 430's are the same as Land Rover 2422 including the adjustment factor. Arrr, is the limp home map more important with cats???

I'm more interested in what else goes on between addresses 112 and 266 near the three idle values.

Interestingly, the initial 500’s spec was 340bhp, as I’m sure everyone knows, and were referred to as 500’s. In 1995 & 1996 the literature changed and then referred to as 500HC, maybe the difference names was due the different maps. The big change came in 1997 when the spec power output was reduced to 320bhp to improve low speed shunting. The Steve Heath bible says the power output changed twice so if it wasn’t in 1995 then when was the other power change?

Edited by stevesprint on Saturday 23 November 10:30

[stevesprint]

Quinny said:

Steve.... Just as a point of reference, my old Griif was a 500 pre serp..... Bog standard from the factory, the plenumn had 500HC on it...

My friends 96 serp griff, the badge says 500

Quinny - I'm pleased to see you have returned to the fold and confusing things as usually, that’s not difficult in the TVR world. Have I got it the wrong way around? Who knows but this thread confuses the 500/500HC mystery even further.
http://www.pistonheads.com/gassing/topic.asp?h=33&... .

Quinny is the old Griff master I bought my Griff 500 T5 from 5 years ago with the external linkage. You can see from the pictures below how the external linkage would foul the top cross members, so TVR lowered the cross member on the T5 Griffs and Chimmies. Wooops I’m off topic again, sorry, but as Quinnys box was so good I swapped the rear housings, actually John Reid the old TVR race manager did it for me.

[stevesprint]

danbourassa said:

The multiplier is an 8-bit value that is fuel map specific. Add $10A to the base address of the fuel map to find it. Right now, I'm looking at fuel map 5 for one of the R2967 tunes and I see that $C6AF plus $10A equals $C7B9 and the value is $91. Other values I typically see are $B2 and $B9. I think that Steve has some experience adjusting this value and may be a good resource

Jools - The multiplier is the Table Row Scalars I previously added to TunerPro that you successfully adjusted for the first Griff 500 with the 20AM. I’ll add the MAF Scalar Offset to TunerPro tonight (Monday) so you’ve got it for tomorrow, but please play with caution as we don’t know how it behaves. You can re-download the TunerPro definition from www.stevesprint.com/remap-14cux

Dan – Am I right thinking the scalar/multipler expands and shrinks the view you have of the fuel table, a bit like the further away you stand the wider field of view you have, and the offset moves the centre point of the view so like moving your head up and down. I’m glad to see the offset value is the same on different TVR maps otherwise I would of had issues running my R2422 data in R2967 code.

[stevesprint]

spitfire4v8 said:

hard to explain but on changing to the 20am i was using , say, row 2 at idle and row 6 at full throttle .. then rescaling the afm allows me to use row 8 on full throttle but the idle is now on row 2.5 if you see what I mean

Interesting, sounds like the offset might just be the ticket, perfect explanation.

spitfire4v8 said:

Still doesn't account for the fact that when the fuel table is all mapped I have this big flat spot on snapping the throttle open.

Dan - Robert added the throttle direct table to TunerPro so is it worth Jools trying to adjust the second column to see if it helps the flat spot when snapping open the throttle???

danbourassa said:

The top row is always the coolant sensor count value and this tells the software what column of data to use. Only one column is in play at any given engine temperature. For example, if the coolant temp count reads 0x23 (approx 190 deg F),
only the second column would be in play (the next column to the right of this value).
So, using the example below, if you want to tune a fully warmed engine, you are now down to just 5 values to be concerned about.

; this 6 x 10 table is used to calc the throttle pot direction & rate (the 1st derivative)
; the resultant value is offset by adding 1024, stored at 0x005D/5E and ultimately used
; to dynamically adjust the fueling

New  New
Map2 Map5
3FB    731 : 18 31 5A 73 89 99 B3 CC DD EA    ; <-- coolant temp reading (low is hot, high is cold)
405    73B : 05 06 08 0A 10 1C 23 28 30 30    ; <-- throttle opening (compare value or limit)
40F    745 : 04 06 07 08 08 00 00 00 00 00    ; <-- throttle closing (compare value or limit)
419    74F : 2D 32 3C 50 64 FF FF FF FF FF    ; <-- throttle opening (multiplier)
423    759 : 1C 18 10 0C 0B 14 14 19 19 19    ; <-- throttle opening (multiplier)
42D    763 : 24 18 10 0C 0B 1E 1E 1E 1E 1E    ; <-- throttle closing (multiplier)

[stevesprint]

Gents - Thanks for making 2013 so exciting!!

danbourassa said:

I can't give Steve a hard time anymore about little things like forgetting magic numbers.

lol, seven point five million, it now just rolls off the tough.

Mark and Jools - It’s brilliant you have conquered the larger AFM, is the Lucas 20AM the same thing as a Sagem 20AM, also which wires go on what pins of the 20AM.

Santa delivered me an Innovate LC2 so I can have even more 14CUX fun next year, lets hope I can decode the RS232 binary data stream.

Best Wishes for the New Year
Cheers Steve

[stevesprint]

spitfire4v8 said:

On the subject of rovergauge, can I ask Colin to add a feature for open loop maps at the same time. I understand the MAF trim voltage is measured and stored for open loop maps, but the software doesn't do anything with it so I suspect that it was just to make it available to Testbook. I'd like this voltage displayed in place of the Lambda bar graphs for open loop please Colin.

blitzracing said:

Friday 25th October - Which map are you running? If its the non catalyst green tune, the CO trim will only affect the mixture up to around 2400 rpm, above that its all down to sensors map and fuel pressure. If its the catalyst map its should not be running rich below 3400 rpm unless you have run out of trim range. Above this its the same as the green term in terms of its sensors and map adjustment.

Joolz and Mark is the MAF trim voltage and the CO trim the same thing?

[stevesprint]

blitzracing said:

As you guys are doing such a good job of pulling the 14CUX mapping to bits, I treated myself to sorting the ignition timing out. Mapping this looks a load easier than the 14CUX!

Mark – Did you go for the vacuum advance version or the Throttle Position Sensor version???
I like the idea you can switch between two stored maps without a computer so you can quickly switch between unleaded and super unleaded, plus it has a configurable soft limiter.
Please let us know how you get on because one day I might have to be a copycat.

[stevesprint]

davep said:

Still no open loop version, had nothing new to play with over Christmas

Well I hope Colin & Dan have had a well-deserved rest over the Christmas break. What’s the hurry for an open loop version? RoverGauge already displays everything useful and the lambda trims are greyed out for us open loopers. I’m just very grateful they have developed RoverGauge for free with some really useful updates.
Best 14cux Wishes for the New Year, Cheers, Steve

[stevesprint]

davep said:

I'm trying to follow Steve's 14CUX programming procedure using the TOP853, only got as far as loading the correct driver, which in the end required the resurrection of an old laptop running Vista. I tried the Win 7 drivers but after getting past the unsigned driver control discovered that Topwin7 doesn't support the TOP853 Programmer version I have. Shame because the demo version shows lots of nice features.

blitzracing said:

Ive just realised I upgraded my garage laptop to win7- not thinking this would be an issue- rats! Ill keep hold of the old XP disc to pop back in it if a workaround cant be found.

Dave & Mark - My TOP853 EPROM programmer works reliably on my netbook running windows 7 (32bit) but with TOPWIN version 6.36 so your TOP853 should also work on Windows 7. I wouldn’t worry too much about Topwin version 7 as 6.36 does everything required and is reliable. For any hex editing/copy/paste/comparing etc I use the free HxD Hex editor.

You can download all the software I use from www.stevesprint.com/remap-14cux , should you require further info please do not hesitate to ask.

[stevesprint]

blitzracing said:

As you guys are doing such a good job of pulling the 14CUX mapping to bits, I treated myself to sorting the ignition timing out. Mapping this looks a load easier than the 14CUX!

I’m very impressed you’ve taken the plunge with an Aldon Amethyst. I totally agree with you about the output of our Lucas ignition amp so I’m sure the hardware will work a treat, please let me know if you need a hand with the software. Have you created a new thread for the Aldon Amethyst??
Good Luck, Steve

[stevesprint]

davep said:

I was simply going through the 'must use the latest OS, Topwin software and drivers' phase - to no avail.

I know exactly what you mean, if I can be of further assistance please don’t hesitate to ask.

davep said:

As to an open loop version of RG my comments were a bit tongue in cheek, but Dan did mention that the 'real time' display of the CO trim voltage level in place of the Lambda fields was a possibility.

Sorry Dave I should have realised. The CO trim is a mystery as Dan says its measured and stored but not used by the ECU software and Mark says it affects the mixture up to about 2400rpm. I looking forward to testing it myself in the spring once I’ve fitted my new wideband lambda sensor.

[stevesprint]

Dan, Colin and Robert have you been hit by the USA big freeze?? If so we hope you all are ok including your Rover V8 powered vehicles.
Best Wishes, Steve

[stevesprint]

Dan
Impressive very impressive, you’ve written 11 to 12 thousand lines of code plus provided us with the data, makefile/build files and a free assembler. I’ve successfully run buildall and all the bins were created with no error or differences. I’m looking forward to getting my hands dirty and will start by creating a data_R2967_??.asm for Precat Griffs 400 and 430.

I’m sure you can tell I’m seriously interested in this project but my 14cux play time is limited at the moment as I’m currently working on my Griff. One of my projects is fitting the correct 14cux lambda sensors plus a wideband sensor. So I hope to be ready for more 14cux action in a month. In the mean time I will keep an eye on the forum.

Its incredible you can now recreate the bins.

Thanks again, Steve

[stevesprint]

Dave and Dan.
The penny has dropped, but Dan you had to go through, understand and comment over 10,000 lines of assembler code and separate out the code paths for the different tunes. Sounds like you made the most of the freezing weather to finish off your years of work. I’ve had a quick look and although I don’t understand assember I do understand your comments enough to have ago at creating data_R2967_??.asm for Precat Griffs, which is effectively what I ran in the autumn. With that in mind I hope Colin would be kind enough to display the checksum in RoverGauge. Dave do you have a 400 or 430??

Colin thanks for porting CRASM from Linux to Windows and adding 6803 support, your months/years of hard work means I can compile the bins on my windows pc in seconds.

Thanks again, Steve

Edited by stevesprint on Thursday 9th January 08:43

[stevesprint]

cmb said:

Since I've been a CRASM maintainer, I've done a couple of releases that address bugs and stability issues.

The 14CUX firmware build procedure is kinda geared toward a Linux environment because I never use Windows (apart from doing the Win32 RoverGauge builds.) However, since the build uses all open-source tools, we've been able to make it work under Windows as well. We've been managing the firmware source in a private Git repository so far, but I'd like to move it to a public repo fairly soon so that people are able to pull down the very latest changes if they're so inclined.

Colin, you have done all this for the 14cux, their is no end to your list of talents.

cmb said:

Steve, when you say that you'd like to see the checksum displayed in RoverGauge, are you referring to the checksum fixer byte? (That's probably more useful than the checksum itself, which is normally just 0x01.) I'll plan to add a display for this, as well as for the "Ident" byte that sometimes changes independently of the tune revision number.

Sorry yes the checksum fixer so we can see what variant of 2967 is running.
The Ident would also be very useful so we could change it to something more meaning full.

[stevesprint]

I've finally had a chance to create a 430 PreCat assember data file for Dan's rebuild project. It's available from www.stevesprint.com/remap-14cux , it also includes the build batch file, test reference bin and the full ready to use bin. It uses TVR's later code, Revision 2967, merged with all the 430 fuel data. The new 430 bin file Dan's rebuild project generates is exactly the same as the bin I previously hand created and ran faultlessly during the autumn.

Dan
It might be a good idea if you update my prom on your google drive with www.stevesprint.com/remap-14cux/TVR_R2967_with_430... as I’ve reset the Revision number to 2967 and the ID to 4300. Please note the lower half is padded with FF’s as on other TVR R2967 proms and the upper half matches exactly to the rom image generated from data_R2967_AA.asm.

Also Dan, I hope you don’t mind I’ve added a link on my remap-14cux web page to your 14cux google drive.