Graphics interface for the 14CUX
Discussion
cmb said:
Note that the current version of the software (0.3.4) is displaying the short-term lambda fuel trim inverted. Both the long-term and short-term fuel trim values actually should show a higher number with more fuel delivery. We verified that this is the case by using an oscilloscope to monitor the injector pulse width. I hope to soon release a new version with the correct polarity displayed.
I also experimented by writing different values to the long-term trim memory location. (This location was initially at 0 counts with a warm engine at tickover.) Writing the minimum value (-256 counts) caused the engine to stumble and almost die, but the short-term trim values increased substantially to compensate, and the normal idle speed was restored. Conversely, setting the long-term trim to its maximum value (+255 counts) caused a slight increase in engine speed, but this was again corrected by the short-term trim, which decreased substantially.
--Colin
Hi Colin- Please when you do this dont simply swap the display polarity- but add something like add fuel / subtract fuel, otherwise it will cause great confusion over the different revisions of RoverGauge and documentation thats already out there.I also experimented by writing different values to the long-term trim memory location. (This location was initially at 0 counts with a warm engine at tickover.) Writing the minimum value (-256 counts) caused the engine to stumble and almost die, but the short-term trim values increased substantially to compensate, and the normal idle speed was restored. Conversely, setting the long-term trim to its maximum value (+255 counts) caused a slight increase in engine speed, but this was again corrected by the short-term trim, which decreased substantially.
--Colin
Thanks
Mark
blitzracing said:
You may well hit a stumbling block there as the ECU / CPU runs out of puff at hight RPM, and stops displaying sensor data as its busy controlling the engine.
And it happens quite early as well. On the early ECUmate development, I found it was quite common to get data that actually wasn't related which meant that it was quite difficult to reconcile the information that was being sent. If you asked for some information, it was possible that parts of it had changed in the meantime and corrupted the data without you actually realising that this was going on.
I ended up having to add some sophisticated techniques to ensure that the displayed data was an accurate snapshot and not made from several differing sets of values.
RoverGuage is the best thing that's happened to the 14CUX in twenty years. It's easy to install, in fact you don't install RoverGuage you just copy it to your computer and run it, obviously you have to install the USB driver which is easy.
The best part is it's much more than a fault code readers that just shows for example a throttle pot fault. In addition it also show you at real time the pot's current angle so you can set the max and min position. The Land Rover dealers would certainly find it more useful than their fault code reader.
I'm even more impressed it's been developed by reverse engineering the executable code for passion and not profit. The Authors Colin and Dan Bourassa are very very clever and we need people like them, THANKS!!! I mean how did you work out the commands/addresses to query the ecu? I don't really want to know, it would go over my head.
I must also thank Mark Thompson who makes the robust interface cable.
It's absolutely bl..dy brilliant.
Well done and thanks
SteveSprint
The best part is it's much more than a fault code readers that just shows for example a throttle pot fault. In addition it also show you at real time the pot's current angle so you can set the max and min position. The Land Rover dealers would certainly find it more useful than their fault code reader.
I'm even more impressed it's been developed by reverse engineering the executable code for passion and not profit. The Authors Colin and Dan Bourassa are very very clever and we need people like them, THANKS!!! I mean how did you work out the commands/addresses to query the ecu? I don't really want to know, it would go over my head.
I must also thank Mark Thompson who makes the robust interface cable.
It's absolutely bl..dy brilliant.
Well done and thanks
SteveSprint
blitzracing said:
Hi Colin- Please when you do this dont simply swap the display polarity- but add something like add fuel / subtract fuel, otherwise it will cause great confusion over the different revisions of RoverGauge and documentation thats already out there.
Thanks
Mark
Absolutely. I'll add labels at each end of the horizontal gauges to make it unambiguous in the next version of the software.Thanks
Mark
--Colin
stevesprint said:
RoverGuage is the best thing that's happened to the 14CUX in twenty years. It's easy to install, in fact you don't install RoverGuage you just copy it to your computer and run it, obviously you have to install the USB driver which is easy.
The best part is it's much more than a fault code readers that just shows for example a throttle pot fault. In addition it also show you at real time the pot's current angle so you can set the max and min position. The Land Rover dealers would certainly find it more useful than their fault code reader.
I'm even more impressed it's been developed by reverse engineering the executable code for passion and not profit. The Authors Colin and Dan Bourassa are very very clever and we need people like them, THANKS!!! I mean how did you work out the commands/addresses to query the ecu? I don't really want to know, it would go over my head.
I must also thank Mark Thompson who makes the robust interface cable.
It's absolutely bl..dy brilliant.
Well done and thanks
SteveSprint
Thanks so much for the kind words! I'm really glad that people find it useful.The best part is it's much more than a fault code readers that just shows for example a throttle pot fault. In addition it also show you at real time the pot's current angle so you can set the max and min position. The Land Rover dealers would certainly find it more useful than their fault code reader.
I'm even more impressed it's been developed by reverse engineering the executable code for passion and not profit. The Authors Colin and Dan Bourassa are very very clever and we need people like them, THANKS!!! I mean how did you work out the commands/addresses to query the ecu? I don't really want to know, it would go over my head.
I must also thank Mark Thompson who makes the robust interface cable.
It's absolutely bl..dy brilliant.
Well done and thanks
SteveSprint
I did most of the software work on this project, while my father, Dan, did most of the reverse engineering. He discovered the diagnostic protocol and important memory offsets through careful analysis of the disassembled code. We use DASMx 1.10 -- it's an older disassembler, but it works well.
--Colin
cmb said:
Thanks so much for the kind words! I'm really glad that people find it useful.
I did most of the software work on this project, while my father, Dan, did most of the reverse engineering. He discovered the diagnostic protocol and important memory offsets through careful analysis of the disassembled code. We use DASMx 1.10 -- it's an older disassembler, but it works well.
--Colin
I agree it's very impressive and useful. Handy too to be able to write to a log file but what would be really good would be to be able to read in a log file and step through it while displaying the data via the Rovergauge display I did most of the software work on this project, while my father, Dan, did most of the reverse engineering. He discovered the diagnostic protocol and important memory offsets through careful analysis of the disassembled code. We use DASMx 1.10 -- it's an older disassembler, but it works well.
--Colin
You can convert the log file data into Excel by first editing the file to replace "," with a "tab" using notepad or the like, then cut and paste the result into Excel, so each logged value is in a different cell. You can then use the Graph function if you want some nice graphics. Makes it a whole lot easier than trying to read raw data.
I agree RoverGauge is a great bit of kit, gives real insight into what's actually going on in the Engine Management System.
Going through a log file recently I noticed a few anomalies that I cannot figure out: I'm trying to find the source of a vibration I get on my pre-cat engine so I did a comparison run between a 500 ECU and my 4.6 pre-cat ECU (same part numbers different date codes). On the 500 ECU run, RoverGauge displayed MainVoltage as 13.49 Vdc and TargetIdle in the range 1173 to 1046 rpm, whereas the pre-cat ECU gave 15.3 Vdc and no TargetIdle, the fuel map selection references were exactly the same. The vibration was far worse when running the 500 ECU. I've read that the MainVoltage has a bearing on injector pulse width so could the differences be an indication of a fault somewhere in the ECU?
Going through a log file recently I noticed a few anomalies that I cannot figure out: I'm trying to find the source of a vibration I get on my pre-cat engine so I did a comparison run between a 500 ECU and my 4.6 pre-cat ECU (same part numbers different date codes). On the 500 ECU run, RoverGauge displayed MainVoltage as 13.49 Vdc and TargetIdle in the range 1173 to 1046 rpm, whereas the pre-cat ECU gave 15.3 Vdc and no TargetIdle, the fuel map selection references were exactly the same. The vibration was far worse when running the 500 ECU. I've read that the MainVoltage has a bearing on injector pulse width so could the differences be an indication of a fault somewhere in the ECU?
blitzracing said:
You can convert the log file data into Excel by first editing the file to replace "," with a "tab" using notepad or the like, then cut and paste the result into Excel, so each logged value is in a different cell. You can then use the Graph function if you want some nice graphics. Makes it a whole lot easier than trying to read raw data.
Excel will do the delimiter formatting for you when you import the log file so no need to do a replace.blitzracing said:
You can convert the log file data into Excel by first editing the file to replace "," with a "tab" using notepad or the like, then cut and paste the result into Excel, so each logged value is in a different cell. You can then use the Graph function if you want some nice graphics. Makes it a whole lot easier than trying to read raw data.
Thanks Mark, I'd already done that but thought it would be cool to actually see the logged values on the Rovergauge 'dashboard'.
Just a little bump on this topic to say ive been using rovergauge the last couple of days and it's a cracking piece of kit. Thanks to Mark for the assembled lead (works perfectly) .. I can certainly recommend using rovergauge.
The interesting bit for me was that there's two long term trims learned? One for each bank .. I always thought there was only one long term trim learned but it's fascinating to watch that trimming and then the short term trims switching either side of zero percent.
Another thing that interests is the range of the fuel map. In the 5 litre I was looking at there's plenty filled in at hex=FF. I don't know what the smaller engined car chips are like but it looks like the full range of the 8 bit range is used as there's some parts of the map down at hex=16 or 17.
This therefore means that if you want to increase the fuelling at high airflows on a 5 litre you've first got to access the adjustment factor number so you can scale the map numbers down. There's nowhere higher to go than FF so adding fuel in the map at those points isn't an option until the adjustment factor is increased so allowing smaller numbers which can then be scaled up to increase fuelling. Does that make sense to anyone?
The interesting bit for me was that there's two long term trims learned? One for each bank .. I always thought there was only one long term trim learned but it's fascinating to watch that trimming and then the short term trims switching either side of zero percent.
Another thing that interests is the range of the fuel map. In the 5 litre I was looking at there's plenty filled in at hex=FF. I don't know what the smaller engined car chips are like but it looks like the full range of the 8 bit range is used as there's some parts of the map down at hex=16 or 17.
This therefore means that if you want to increase the fuelling at high airflows on a 5 litre you've first got to access the adjustment factor number so you can scale the map numbers down. There's nowhere higher to go than FF so adding fuel in the map at those points isn't an option until the adjustment factor is increased so allowing smaller numbers which can then be scaled up to increase fuelling. Does that make sense to anyone?
I just released a new version -- 0.3.5. This one fixes the polarity of the short-term lambda trim value, and I added labels to show that negative trim is *reducing* fuel while positive trim is *adding* fuel.
I also added a feature (under the Options menu) to check the PROM revision. It attempts to identify the tune number of the PROM (such as R2419, R3360, etc.) Unfortunately, my collection of ECUs only contains a small number of the Land Rover tunes (plus one for a Griffith), and the software will report "Unknown" if it doesn't recognise the tune.
I can add more tune IDs in a future release, if anyone is able to read the image from their ECU and can send it to me along with the tune number. Land Rover numbers are typically handwritten on a sticker on top of the PROM chip, and are a four-digit number starting with 2 or 3. If the ECU is from a TVR, it won't have a stock Land Rover tune -- in that case, you could just record any part number you see, as well as information about the car (e.g. "TVR Chim 4.0")
--Colin
I also added a feature (under the Options menu) to check the PROM revision. It attempts to identify the tune number of the PROM (such as R2419, R3360, etc.) Unfortunately, my collection of ECUs only contains a small number of the Land Rover tunes (plus one for a Griffith), and the software will report "Unknown" if it doesn't recognise the tune.
I can add more tune IDs in a future release, if anyone is able to read the image from their ECU and can send it to me along with the tune number. Land Rover numbers are typically handwritten on a sticker on top of the PROM chip, and are a four-digit number starting with 2 or 3. If the ECU is from a TVR, it won't have a stock Land Rover tune -- in that case, you could just record any part number you see, as well as information about the car (e.g. "TVR Chim 4.0")
--Colin
spitfire4v8 said:
Just a little bump on this topic to say ive been using rovergauge the last couple of days and it's a cracking piece of kit. Thanks to Mark for the assembled lead (works perfectly) .. I can certainly recommend using rovergauge.
The interesting bit for me was that there's two long term trims learned? One for each bank .. I always thought there was only one long term trim learned but it's fascinating to watch that trimming and then the short term trims switching either side of zero percent.
Another thing that interests is the range of the fuel map. In the 5 litre I was looking at there's plenty filled in at hex=FF. I don't know what the smaller engined car chips are like but it looks like the full range of the 8 bit range is used as there's some parts of the map down at hex=16 or 17.
This therefore means that if you want to increase the fuelling at high airflows on a 5 litre you've first got to access the adjustment factor number so you can scale the map numbers down. There's nowhere higher to go than FF so adding fuel in the map at those points isn't an option until the adjustment factor is increased so allowing smaller numbers which can then be scaled up to increase fuelling. Does that make sense to anyone?
I would have thought that a large block of FFs indicate that what ever it was should really have been running higher flow rate injectors...The interesting bit for me was that there's two long term trims learned? One for each bank .. I always thought there was only one long term trim learned but it's fascinating to watch that trimming and then the short term trims switching either side of zero percent.
Another thing that interests is the range of the fuel map. In the 5 litre I was looking at there's plenty filled in at hex=FF. I don't know what the smaller engined car chips are like but it looks like the full range of the 8 bit range is used as there's some parts of the map down at hex=16 or 17.
This therefore means that if you want to increase the fuelling at high airflows on a 5 litre you've first got to access the adjustment factor number so you can scale the map numbers down. There's nowhere higher to go than FF so adding fuel in the map at those points isn't an option until the adjustment factor is increased so allowing smaller numbers which can then be scaled up to increase fuelling. Does that make sense to anyone?
Not really Rob .. I don't think the fuel map relates directly to the injected quantity. There's the adjustment factor for a start that i didn't know about but these clever guys have found. The fuel map as it is seems to be multiplied by the adjustment factor which looks like it's scaled to give the best full range / resolution within the 00 to FF range. I wonder if the adjustment factor is what Mark Adams changes when he re-scales for different AFMs or to bring a fuel map into a more useable range of numbers? A small engine flowing much more air when it's tuned for instance will reach the top of the map quicker if the adjustment factor is low .. by re-scaling the output voltage of the afm relative to the map you gain back the headroom you had lost with the lower adjustment factor so allowing you to realign the fuelling for higher airflows where previously you had reached the top of the map too soon.
Heres what Colin told me about the adjustment factor:
The 16-bit adjustment value shown above the map is multiplied by the 8-bit value read from the map itself. There is a different adjustment value for each map, and it seems to be the most significant change between maps for different engine displacements. Of course, after this multiplication, there are a number of other adjustments made (based on coolant temperature, fuel temperature, main voltage, and, for cat maps, lambda feedback.)
Ive got a selection of maps I can plug in and see if there is a common values relation to specific engine sizes.
The 16-bit adjustment value shown above the map is multiplied by the 8-bit value read from the map itself. There is a different adjustment value for each map, and it seems to be the most significant change between maps for different engine displacements. Of course, after this multiplication, there are a number of other adjustments made (based on coolant temperature, fuel temperature, main voltage, and, for cat maps, lambda feedback.)
Ive got a selection of maps I can plug in and see if there is a common values relation to specific engine sizes.
I`m on my way there as I type this.....Gassing Station | General TVR Stuff & Gossip | Top of Page | What's New | My Stuff