Graphics interface for the 14CUX
Discussion
It lives!
It did not take too much messing about in the end. Software wise, the USB to serial converter plugs and plays quite happily in both XP and windows 7. It will appear as a new com port in device manager when you plug it it, and you need to make note of the com port number windows assigns it (Comm 7, 8, 9 etc) to set up the Rovergauge interface. You also need to download the FT- Prog program and reprogram the USB device itself to invert the receive signal from the 14CUX. Its not difficult, but Im not going to go through it here. The baud rate is set by the Rovergauge software, wich makes things a whole lot easier than trying to get windows to do it for you.
The hardware really is dead simple, it just needs a TTS connector and a 400 ohm resistor as per the web site connected to the USB serial adaptor. As it says on the web site the TTS connector is not common place, but Ive found one (I hope anyway) from a Bentley parts supplier- apparently its an air con connector. I will look into getting a handful in so I can make more interface cables if there is a need.
Once I has happy the hardware was working, I plugged it into the loom, and fired up the Rovergauge. It refused to talk to the Comm port whatever I did on my Windows 7 laptop, but burst into life on an XP machine. You need to have the ignition on, then hit the connect button to get the communication started. I will query the Windows 7 issue with the guy who has written the software, to see if there any more clues on this one.
In terms of its use, its pretty straight forward, will nice clear readings on the gauges. It also shows the map you are using, and you can actually see the load points in the map changing dynamically,(This is a slow process- I though it would change really fast all the time) so it shows you the hex value directly as its seen in the Eprom. This could be very interesting if you are looking to change the fueling in the chip! I have not been able to read the level of correction the Lambda probes are applying to the map if its out, as my current set up joints the exhaust headers before the lambda probes, so the ECU cant correct the mixture as the two banks are joined upstream. I need to test this on a car with the cat map.
When you switch the igntion off it holds the last data received from the ECU,(which could be useful if you are chasing an intermittent fault) or there is also a data logging function, but Ive not played with this yet.
This is an excellent bit of software if you just want sensor readings, basic fault codes and mapping data, and makes a nice addition to the ECU mate in terms of its mapping data layout.
It did not take too much messing about in the end. Software wise, the USB to serial converter plugs and plays quite happily in both XP and windows 7. It will appear as a new com port in device manager when you plug it it, and you need to make note of the com port number windows assigns it (Comm 7, 8, 9 etc) to set up the Rovergauge interface. You also need to download the FT- Prog program and reprogram the USB device itself to invert the receive signal from the 14CUX. Its not difficult, but Im not going to go through it here. The baud rate is set by the Rovergauge software, wich makes things a whole lot easier than trying to get windows to do it for you.
The hardware really is dead simple, it just needs a TTS connector and a 400 ohm resistor as per the web site connected to the USB serial adaptor. As it says on the web site the TTS connector is not common place, but Ive found one (I hope anyway) from a Bentley parts supplier- apparently its an air con connector. I will look into getting a handful in so I can make more interface cables if there is a need.
Once I has happy the hardware was working, I plugged it into the loom, and fired up the Rovergauge. It refused to talk to the Comm port whatever I did on my Windows 7 laptop, but burst into life on an XP machine. You need to have the ignition on, then hit the connect button to get the communication started. I will query the Windows 7 issue with the guy who has written the software, to see if there any more clues on this one.
In terms of its use, its pretty straight forward, will nice clear readings on the gauges. It also shows the map you are using, and you can actually see the load points in the map changing dynamically,(This is a slow process- I though it would change really fast all the time) so it shows you the hex value directly as its seen in the Eprom. This could be very interesting if you are looking to change the fueling in the chip! I have not been able to read the level of correction the Lambda probes are applying to the map if its out, as my current set up joints the exhaust headers before the lambda probes, so the ECU cant correct the mixture as the two banks are joined upstream. I need to test this on a car with the cat map.
When you switch the igntion off it holds the last data received from the ECU,(which could be useful if you are chasing an intermittent fault) or there is also a data logging function, but Ive not played with this yet.
This is an excellent bit of software if you just want sensor readings, basic fault codes and mapping data, and makes a nice addition to the ECU mate in terms of its mapping data layout.
Mark: the actual mapping data does change frequently.
The reason why it takes so long to fetch is partly to do with the implementation and the comms protocol. There is no handshaking. The protocol requires that data is sent, replied to and so on so that the data itself is the actual handshaking. This puts a lot of timing overhead on the comms. The app sends a byte through Windoze, down through the driver and out via the USB. The ECU will then respond. If this is missed because of delays or only part is received, then the transfer can be corrupt or aborted. The other issue is that the ECU treats any data requests as very low priority. It only has a lickle brain and so there can be a very long delay between receiving data e.g seconds is not uncommon or even not at all.
What does this all mean? The first thing is it is very difficult to actually get a snap shot of the data so that all the information that is displayed is actually concurrent. So when the ECU information is shown, you don't know if it is concurrent with the other data or taken earlier or even worse is a mixture of the two. This does make interpreting the mapping side in particular very misleading.
This is not a big issue with things like temperatures but is with fast changing data like AFM values and throttle pots.
PS For those who have experienced high idle problems... Spent most of this weekend ECUmating the 14cux with a programmable rev input and speed input and I think I have finally cracked it. I can get my engine simulator to demonstrate the same symptoms now. Holding high revs for an eternity. It looks like a combination of several factors including the TVR speedo conversion unit.
The reason why it takes so long to fetch is partly to do with the implementation and the comms protocol. There is no handshaking. The protocol requires that data is sent, replied to and so on so that the data itself is the actual handshaking. This puts a lot of timing overhead on the comms. The app sends a byte through Windoze, down through the driver and out via the USB. The ECU will then respond. If this is missed because of delays or only part is received, then the transfer can be corrupt or aborted. The other issue is that the ECU treats any data requests as very low priority. It only has a lickle brain and so there can be a very long delay between receiving data e.g seconds is not uncommon or even not at all.
What does this all mean? The first thing is it is very difficult to actually get a snap shot of the data so that all the information that is displayed is actually concurrent. So when the ECU information is shown, you don't know if it is concurrent with the other data or taken earlier or even worse is a mixture of the two. This does make interpreting the mapping side in particular very misleading.
This is not a big issue with things like temperatures but is with fast changing data like AFM values and throttle pots.
PS For those who have experienced high idle problems... Spent most of this weekend ECUmating the 14cux with a programmable rev input and speed input and I think I have finally cracked it. I can get my engine simulator to demonstrate the same symptoms now. Holding high revs for an eternity. It looks like a combination of several factors including the TVR speedo conversion unit.
shpub said:
PS For those who have experienced high idle problems... Spent most of this weekend ECUmating the 14cux with a programmable rev input and speed input and I think I have finally cracked it. I can get my engine simulator to demonstrate the same symptoms now. Holding high revs for an eternity. It looks like a combination of several factors including the TVR speedo conversion unit.
Steve, this is very interesting stuff. Please keep us informed of your progress. The issue with the com port not being recognised above com 9 is a Windows issue,(both XP and Windows 7) but as long as you can keep the com port below 9 its fine. The code writer will fix this when he next updates the program to overcome this . You can change the assigned port numbers under the advance settings for the ports under device manager to get it to work.
Just an update. The software now has some extra nice touches like stepper motor and fuel pump control,and target idle speed (its a reading, this not a changeable parameter), and more updates are to follow soon. It also runs quite nicely off a CD if you dont want to load software onto your PC. On the hardware side, I have not been able to get the Lucas TTS connector to make up interface leads, so Ive had to make connectors from scratch, which have turned out OK, so if anyone wants a pre programed lead with connector, CD and instructions drop me a line, as Im making a few kits up to order.
Steve, Blitz,
I've mailed the developer, working with BlackBerry and having a USB port/QT runtime on our new devices this could make a really nice marraige. I'll let you all know how I get on, although if he says yes I'll need a lot of input. I'm no software/hardware/electronics expert.
I've mailed the developer, working with BlackBerry and having a USB port/QT runtime on our new devices this could make a really nice marraige. I'll let you all know how I get on, although if he says yes I'll need a lot of input. I'm no software/hardware/electronics expert.
Currently the Rovergauge does not have the full list of features as the ECUmate, the biggest being no display for the lambda trim values, which is being worked on currently. Its also not as easy to use as the ECUmate, if only because you have to have a laptop with you for road tests, which is never that easy in a cramped cockpit but I personally like the mapping table info RoverGauge gives you,(and the fact you can extract it easily) as I think there is potentual to be able to alter the values and program different fuel maps into the 5 available map space in the Eprom (This will require an Eprom programmer to write the new maps back to the Eprom- RoverGauge cant do this).
Cables have costed out ar £35 inc postage, Ill include all the software you need and instructions with it as well.
Cables have costed out ar £35 inc postage, Ill include all the software you need and instructions with it as well.
Just a general update.
The latest software now has facility to:
Read all the sensor inputs, engine temp, fuel temp, speed input, RPM, AFM, throttle pot, main voltage, and lambda off sets for both banks to monitor fueling against base map and sensor inputs.
ECU load settings (for auto boxes)
Read and show live fuel mapping data- and specifically what map the car is running, inc the limp home map
Read and reset error codes.
Display programmed idle speed.
Read and POSITION the stepper motor
Pulse the fuel pump or run continuosly for tesing fuel pump relay and pump supply
The scales for the AFM and Throttle pot readings are in percent based on a sensor voltage peak of 5 volts, so the throttle pot and AFM voltages can be checked directly against 100 percent = 5 volts. This can be represented by a correctly set up throttle pot going from 5% to 97% over its whole range. An AFM will show 30-33 % at idle depending on engine size. This reading will change if the idle is higher or lower than its programmed to be-
There is the ability to copy the entire Eprom contents as a .bin file, including the fuel maps.
There is a basic logging facility that will give all the sensor data in a serial text format that could be observered at a later date. This will require some expertise in say Excel to display the data in graphical form. You can alter the scan rate for the sensor data, but as the ECU has a very slow CPU in it, some of the sensor data stops updating as the engine RPM rises, and the CPU is busy doing the fueling, and not updating the serial output.
Ive probibly missed something out......
The latest software now has facility to:
Read all the sensor inputs, engine temp, fuel temp, speed input, RPM, AFM, throttle pot, main voltage, and lambda off sets for both banks to monitor fueling against base map and sensor inputs.
ECU load settings (for auto boxes)
Read and show live fuel mapping data- and specifically what map the car is running, inc the limp home map
Read and reset error codes.
Display programmed idle speed.
Read and POSITION the stepper motor
Pulse the fuel pump or run continuosly for tesing fuel pump relay and pump supply
The scales for the AFM and Throttle pot readings are in percent based on a sensor voltage peak of 5 volts, so the throttle pot and AFM voltages can be checked directly against 100 percent = 5 volts. This can be represented by a correctly set up throttle pot going from 5% to 97% over its whole range. An AFM will show 30-33 % at idle depending on engine size. This reading will change if the idle is higher or lower than its programmed to be-
There is the ability to copy the entire Eprom contents as a .bin file, including the fuel maps.
There is a basic logging facility that will give all the sensor data in a serial text format that could be observered at a later date. This will require some expertise in say Excel to display the data in graphical form. You can alter the scan rate for the sensor data, but as the ECU has a very slow CPU in it, some of the sensor data stops updating as the engine RPM rises, and the CPU is busy doing the fueling, and not updating the serial output.
Ive probibly missed something out......
PoleDriver said:
Can we have a version for the 'Flapper' system next please? 
My software might actually work with the 13CU already. (Is the 13CU the "flapper" system you're referring to?) I haven't been able to do any testing with this system, as it was only used in the 1987-88 Range Rover in the States. If it uses the same 5-way TTS connector, it's worth a try.
I've installed and tested the software on my Laptop and it looks like its working well. The instructions too were spot on - Thanks Blitz
However, I have two issues that the software has highlighted.
1. My MPH dial (in roverguage) sat at a constant 36mph - didn't move once on the 15 minute journey I did, where as my speedo was working fine and showing my speed at all times. What do you think this might be?
2. Is it normal to have a minus figure on one Lambda and a positive figure on the other Lambda? Mine showed +13 on the left hand side and -2 on the right hand side. I'll run a few more tests when i can to verify to see if it changes.
One thing i did notice that if you have your laptop connected and rover guage running in "connected " mode. When you indicate left or right, the frost warning light comes on and blinks in time to the indicator... very odd indeed
However, I have two issues that the software has highlighted.
1. My MPH dial (in roverguage) sat at a constant 36mph - didn't move once on the 15 minute journey I did, where as my speedo was working fine and showing my speed at all times. What do you think this might be?
2. Is it normal to have a minus figure on one Lambda and a positive figure on the other Lambda? Mine showed +13 on the left hand side and -2 on the right hand side. I'll run a few more tests when i can to verify to see if it changes.
One thing i did notice that if you have your laptop connected and rover guage running in "connected " mode. When you indicate left or right, the frost warning light comes on and blinks in time to the indicator... very odd indeed
The speed readings are purely the way TVR have frigged the ECU speed input signal. The system works by going from no speed input to a fixed speed input at about 3 mph, so Rovergauge is simply telling you the speed generated by the TVR speedo correcting box under the dash.
The Lambda readings are not quite what we thought they would show initially. The data read is held in the battery backed up part of the ECU, and on the surface appears to be a long fuel trim value that the ECU learns, not the short term fuel trim that will be seen cycling as it does with a test meter on the Lambda probes or how its displayed by the ECUmate. I did not think the ECU was smart enough to have 2 levels of fuel trim like modern ECU's do, but this will be some really useful data if we can display both fuel trim levels and this assumption is correct. I did think there was something wrong with my set up as I saw no more tham 3% trim on an Adams Tornado chip, but now I think the basic fuel map is spot on, so very little trim is needed. We have also seen 100% trim added to a car with a Torqueflow AFM. In terms of its reading, if its less than 100% (lower the better) then you will be OK. Dont expect both sides to be the same, as the lambda readings vary between the left and right bank even if you supply both sides with exactly the same amount of fuel- I suspect this is due to the plenum feeding from one side and slightly different air flows.
The Lambda readings are not quite what we thought they would show initially. The data read is held in the battery backed up part of the ECU, and on the surface appears to be a long fuel trim value that the ECU learns, not the short term fuel trim that will be seen cycling as it does with a test meter on the Lambda probes or how its displayed by the ECUmate. I did not think the ECU was smart enough to have 2 levels of fuel trim like modern ECU's do, but this will be some really useful data if we can display both fuel trim levels and this assumption is correct. I did think there was something wrong with my set up as I saw no more tham 3% trim on an Adams Tornado chip, but now I think the basic fuel map is spot on, so very little trim is needed. We have also seen 100% trim added to a car with a Torqueflow AFM. In terms of its reading, if its less than 100% (lower the better) then you will be OK. Dont expect both sides to be the same, as the lambda readings vary between the left and right bank even if you supply both sides with exactly the same amount of fuel- I suspect this is due to the plenum feeding from one side and slightly different air flows.
Gassing Station | General TVR Stuff & Gossip | Top of Page | What's New | My Stuff