NEW Windows 64 bit AJP Diagnostic Software
Discussion
I noticed that the 2.4MB large Example Log.csv loads and displays correctly.
Comparing it in Excel to a log recorded by myself I noticed that the example has pairs of columns where the left one is titled hex_Throttle1 and the right Throttle1 and so forth whereas the files I recorded do without columns containing hexadecimal data.
Strangely the small 3kB log files I recorded and that are displayed do not show the hex data so it seems it is not required to be displayed correctly.
Comparing it in Excel to a log recorded by myself I noticed that the example has pairs of columns where the left one is titled hex_Throttle1 and the right Throttle1 and so forth whereas the files I recorded do without columns containing hexadecimal data.
Strangely the small 3kB log files I recorded and that are displayed do not show the hex data so it seems it is not required to be displayed correctly.
If the application is loading the example file ok, it shows that it's working as expected. The hex_ values are the raw data returned from the MBE. In the initial versions of the application they were included in the logged data as a means of checking that the calculated values were correct, however once that was verified I removed them from the log to reduce the file size. They have no impact on loading stored data and are meaningless unless you know the formula for calculating the actual value.
What I have found is that if the log file is corrupt - it will not load. This can happen if the file is not closed before quitting the application. So - order of operation - 1. start app, 2. start recording, 3. stop recording, 4. close app. I noticed this once when my laptop ran out of power while recording a long run. While I could see the data in the csv file when I opened it in Notepad - it would not load into the app. I suspect that the file is missing an End Of File character which prevents the C# library from opening and reading the file successfully. Hope this helps.
What I have found is that if the log file is corrupt - it will not load. This can happen if the file is not closed before quitting the application. So - order of operation - 1. start app, 2. start recording, 3. stop recording, 4. close app. I noticed this once when my laptop ran out of power while recording a long run. While I could see the data in the csv file when I opened it in Notepad - it would not load into the app. I suspect that the file is missing an End Of File character which prevents the C# library from opening and reading the file successfully. Hope this helps.
hardtailer said:
It worked! 500ms and 50ms respectively did the trick!
Adaptives 1-3
Adaptives 4-6
Does this map indicate that the throttle bodies on cil 4-6 should be synch'ed?
Can't replay csv-logfiles, however. Unsure if that's because of very little RAM on the ebook?
Finally got around to trying again and pleased to say these settings allow me to see the adaptive maps! Adaptives 1-3
Adaptives 4-6
Does this map indicate that the throttle bodies on cil 4-6 should be synch'ed?
Can't replay csv-logfiles, however. Unsure if that's because of very little RAM on the ebook?
Haven't tried logging yet.
As for your figures, would suggest to me that synchronisation should be checked on all cylinders, but especially between between the front three and back three, as 1-3 only registering three values at idle and 4-6 out of range.
My logged files are most probably corrupt as the connection between the USB to serial converter and ebook is dodgy...
I synched the TBs, reset adaptive maps and drove the car. First row of adaptives has been filled on both banks and bank 2 (4-6) reads between 26 and 32 (red colour all of them) in the first row up to 2750 rpm. Bank1 all bright yellow, I.e smaller values.
Haven't got the screenshot on this device so no pics at the moment.
Engine picks up smoothly from idle and pulls cleanly and well since synching and resetting adaptives and relearning them..
What else could be a reason for bank2 needing so much adapting?
I synched the TBs, reset adaptive maps and drove the car. First row of adaptives has been filled on both banks and bank 2 (4-6) reads between 26 and 32 (red colour all of them) in the first row up to 2750 rpm. Bank1 all bright yellow, I.e smaller values.
Haven't got the screenshot on this device so no pics at the moment.
Engine picks up smoothly from idle and pulls cleanly and well since synching and resetting adaptives and relearning them..
What else could be a reason for bank2 needing so much adapting?
Edited by hardtailer on Thursday 20th July 06:25
Edited by hardtailer on Thursday 20th July 06:44
hardtailer said:
My logged files are most probably corrupt as the connection between the USB to serial converter and ebook is dodgy...
I synched the TBs, reset adaptive maps and drove the car. First row of adaptives has been filled on both banks and bank 2 (4-6) reads between 26 and 32 (red colour all of them) in the first row up to 2750 rpm. Bank1 all bright yellow, I.e smaller values.
Haven't got the screenshot on this device so no pics at the moment.
Engine picks up smoothly from idle and pulls cleanly and well since synching and resetting adaptives and relearning them..
What else could be a reason for bank2 needing so much adapting?
I synched the TBs, reset adaptive maps and drove the car. First row of adaptives has been filled on both banks and bank 2 (4-6) reads between 26 and 32 (red colour all of them) in the first row up to 2750 rpm. Bank1 all bright yellow, I.e smaller values.
Haven't got the screenshot on this device so no pics at the moment.
Engine picks up smoothly from idle and pulls cleanly and well since synching and resetting adaptives and relearning them..
What else could be a reason for bank2 needing so much adapting?
Edited by hardtailer on Thursday 20th July 06:25
Edited by hardtailer on Thursday 20th July 06:44
My thinking is that for every throttle position, from idle to fully open, the engine will have a target speed. So for idle the throttle will be at site 1 and the rpm will be say - 1000. With the throttle on site 8 the rpm would be 4000rpm, and at throttle on site 15, the engine speed would be 8000. Idealised figures for explantion purposes, but you could draw a diagonal line from top left to bottom right on the chart and the engine should be at it's natural state. For all other chart locations - the engine is trying to get to it's natural state
Now if the engine speed is above it's natural position - say 3000rpm when the throttle pot is on site 1 (idle, 18 degree-ish) - the ECU see's 3000 rpm, the engine is sucking in a lot of air, so according to the reading from the O2 sensor in the exhaust the ECU needs to add a lot more fuel. Hence the big positive number in the adaptive chart. This is more likely to happen on site one because as you're driving at speed you very often lift your foot off the pedal - effectively in over-run condition. So these are conditions that are met quite frequently.
Similarly - if you were sitting at idle and floor the pedal, the engine would be getting way too much fuel and the adaptive value would be a large negative. Not something I ever do.
Bear in mind that the adaptive values are added to the base map, so in a well mapped system these wild variances should already be factored in to keep the adaptive values as close to zero as possible.
That's my simplistic view on it. Of course I could be completely wrong. No doubt someone with a better understanding will point out the errors in my theory.
Now if the engine speed is above it's natural position - say 3000rpm when the throttle pot is on site 1 (idle, 18 degree-ish) - the ECU see's 3000 rpm, the engine is sucking in a lot of air, so according to the reading from the O2 sensor in the exhaust the ECU needs to add a lot more fuel. Hence the big positive number in the adaptive chart. This is more likely to happen on site one because as you're driving at speed you very often lift your foot off the pedal - effectively in over-run condition. So these are conditions that are met quite frequently.
Similarly - if you were sitting at idle and floor the pedal, the engine would be getting way too much fuel and the adaptive value would be a large negative. Not something I ever do.
Bear in mind that the adaptive values are added to the base map, so in a well mapped system these wild variances should already be factored in to keep the adaptive values as close to zero as possible.
That's my simplistic view on it. Of course I could be completely wrong. No doubt someone with a better understanding will point out the errors in my theory.
Thanks for your reply. "...for every throttle position, from idle to fully open, the engine will have a target speed."
For completeness sake: This is true only as long as the driving resistance doesnt change. As soon as this changes (going up or down a hill as the biggest factor) that "target" speed will change. As such the ECU needs injector and ignition timing values for all rpms at each engine load=throttle opening. Even on the overrun this is required for a smooth transition into a lower or back to a higher ('tip in') engine load.
It's a shame that the load axis doesn't show the exact % of throttle opening range for each row.
Thinking that the high values for bank 2 point to false air entering the intake I checked and indeed this was the case.
Removed them all only to find no sealant at any of them. Put a thin bead of rtv and refitted the throttle bodies.
After balancing them (idle rpm 850-900 at operating temp), resetting the throttle pots and adaptives using the above software I went for a drive.
Throttle response from standstill was noticeably smoother and I expected to find adaptives in row 1 of both banks to be more similar than before.
This is what I got.
Bank 2 hasn't changed much but bank 1 has compared to the maps posted earlier even though bank 1 tested negative for (i.e. no) false air...
Throttle bodies show no wear of the spindle 'bearing' surfaces.
I'll check for a leaky joint between manifold and cat next.
Logging still doesn't yield readable files even though I repaired the intermittent connection between ECU and e-book.
Sorry for taking this thread off topic but thought it best to continue here instead of opening a new thread.
For completeness sake: This is true only as long as the driving resistance doesnt change. As soon as this changes (going up or down a hill as the biggest factor) that "target" speed will change. As such the ECU needs injector and ignition timing values for all rpms at each engine load=throttle opening. Even on the overrun this is required for a smooth transition into a lower or back to a higher ('tip in') engine load.
It's a shame that the load axis doesn't show the exact % of throttle opening range for each row.
Thinking that the high values for bank 2 point to false air entering the intake I checked and indeed this was the case.
Removed them all only to find no sealant at any of them. Put a thin bead of rtv and refitted the throttle bodies.
After balancing them (idle rpm 850-900 at operating temp), resetting the throttle pots and adaptives using the above software I went for a drive.
Throttle response from standstill was noticeably smoother and I expected to find adaptives in row 1 of both banks to be more similar than before.
This is what I got.
Bank 2 hasn't changed much but bank 1 has compared to the maps posted earlier even though bank 1 tested negative for (i.e. no) false air...
Throttle bodies show no wear of the spindle 'bearing' surfaces.
I'll check for a leaky joint between manifold and cat next.
Logging still doesn't yield readable files even though I repaired the intermittent connection between ECU and e-book.
Sorry for taking this thread off topic but thought it best to continue here instead of opening a new thread.
Edited by hardtailer on Saturday 19th August 10:19
Edited by hardtailer on Saturday 19th August 10:42
notaping said:
Ok. Some more fixes.
The 'reset' buttons should now work & I've re-worked the logic that loads the adpative map data - so it should be more stable.
It's a slow process, but I think it's getting there. Once again - feedback appreciated.
https://api.onedrive.com/v1.0/shares/s!AuU8U8VUHEO...
I just downloaded it, I’m assuming this is still the latest version?The 'reset' buttons should now work & I've re-worked the logic that loads the adpative map data - so it should be more stable.
It's a slow process, but I think it's getting there. Once again - feedback appreciated.
https://api.onedrive.com/v1.0/shares/s!AuU8U8VUHEO...
As far as I can see so far works perfectly on a windows 11 laptop.
Thanks very much for all the work you have put onto this!
I’d totally forgotten I had used the one from EvoOlli 10 years ago, I’ll stick with your ls now I have it though, is it the logging that you have added to yours?
I have used the logging feature with the Emerald K6 in the other Cerb & know how useful that is so I’m looking forward to that.
I’m just at the checking everything over before first fire up stage at the moment.
The ECU has been out of the car for months so it’s not too surprising the adaptives are all zero at the moment, hopefully something will show up there soon.
Is there any kind of fault history or is it just a state that records a fault & stays till you clear it?
I noticed you usefully made the text go red when the sensor is unplugged, I guess that is fault currently present. The background red just showing there has been a fault before, with nothing extra hidden away anywhere?
I just wanted to check before clearing the fault codes.
Lastly is it normal for the lambda readout to show 0v when the engine isn’t running?
As I said I’m just trying to find out what is & isn’t working before trying to fire it up properly.
Luckone - thanks for downloading the app. Yes this is the latest version available. I'm currently working on an updated version for a Windows tablet - with touchscreen capabilities etc, but development has stalled. A bit busy on other things just now.
The Faults and Logged Faults are a straight read from the MBE. I don't store a history in the app.
This might be helpful - from the original TVR software - RTHELP.TXT:
"Logged faults are ones that have been detected in the past and may or may not still be
present. NOTE: FAULTS WILL BE LOGGED IF ANY SENSOR WIRES ARE
DISCONNECTED WHILST THE IGNITION IS TURNED ON!
Current faults will turn the MIL lamp on. Logged faults will not.
Observing the logged faults can be useful when tracing intermittent faults."
If you click on the wee engine icon at the right of the menu bar it will open up a help screen. That will tell you what all the colours mean in the app.
Looking at the image you've posted - I would reset the faults now and then see what comes up again. The throttle pots look wrong. They should be reading about 17-18% when the engine is off. Also the Water temp is too high (if the engine is cold). It should be more in line with the air temp. Lambdas will be zero when not running.
From the original TVR software - RTHELP.TXT:
"LAMBDA 1 & LAMBDA 2
Lambda 1&2 show the signals from the lambda sensors on each bank. After starting the
sensors will take at least 30 seconds to warm up, before they will read correctly.
Once warmed up, the lambda signals should switch between approx. 0 & 1-1.5 volts.
0 volts shows that the fuel mixture is lean, 1 volt shows that the mixture is rich.
"LAMBDA 1 & LAMBDA 2
These faults are shown if the lambda sensor signal rises above 1.7V.If it occurs the
MIL lamp will be turned on.
Lambda fault
can be caused by: Water ingress into the lambda sensor's connector or wiring.
Mechanical damage to sensor or wiring, causing a short
between the supply and signal wires.
Faulty sensor"
If you have access to the original software it's worth reading through RTHELP.TXT - Loads of good info in there.
The Faults and Logged Faults are a straight read from the MBE. I don't store a history in the app.
This might be helpful - from the original TVR software - RTHELP.TXT:
"Logged faults are ones that have been detected in the past and may or may not still be
present. NOTE: FAULTS WILL BE LOGGED IF ANY SENSOR WIRES ARE
DISCONNECTED WHILST THE IGNITION IS TURNED ON!
Current faults will turn the MIL lamp on. Logged faults will not.
Observing the logged faults can be useful when tracing intermittent faults."
If you click on the wee engine icon at the right of the menu bar it will open up a help screen. That will tell you what all the colours mean in the app.
Looking at the image you've posted - I would reset the faults now and then see what comes up again. The throttle pots look wrong. They should be reading about 17-18% when the engine is off. Also the Water temp is too high (if the engine is cold). It should be more in line with the air temp. Lambdas will be zero when not running.
From the original TVR software - RTHELP.TXT:
"LAMBDA 1 & LAMBDA 2
Lambda 1&2 show the signals from the lambda sensors on each bank. After starting the
sensors will take at least 30 seconds to warm up, before they will read correctly.
Once warmed up, the lambda signals should switch between approx. 0 & 1-1.5 volts.
0 volts shows that the fuel mixture is lean, 1 volt shows that the mixture is rich.
"LAMBDA 1 & LAMBDA 2
These faults are shown if the lambda sensor signal rises above 1.7V.If it occurs the
MIL lamp will be turned on.
Lambda fault
can be caused by: Water ingress into the lambda sensor's connector or wiring.
Mechanical damage to sensor or wiring, causing a short
between the supply and signal wires.
Faulty sensor"
If you have access to the original software it's worth reading through RTHELP.TXT - Loads of good info in there.
notaping said:
Looking at the image you've posted - I would reset the faults now and then see what comes up again. The throttle pots look wrong. They should be reading about 17-18% when the engine is off. Also the Water temp is too high (if the engine is cold). It should be more in line with the air temp. Lambdas will be zero when not running.
If you have access to the original software it's worth reading through RTHELP.TXT - Loads of good info in there.
Thanks for the quick & detailed reply, it all makes good sense. I reset the faults & nothing came backIf you have access to the original software it's worth reading through RTHELP.TXT - Loads of good info in there.
The pots aren’t attached to the throttle bodies yet, I just wanted to check the ECU could see them.
The coolant pipes aren’t attached to the engine yet either, I had just filled the pipe with the sensor with hot water to see how close the dash gauge was before I installed it properly. Glad I did, dam thing is reading 20deg higher than the ECU sensor! (I checked the temp with a thermometer, it agreed with the ECU sensor).
I’d forgotten till I found my post from 10 years ago about the other software, I read through all the help files from both versions of the original software back then. I do remember now how much information there was in there.
I have used VMs with XP to run software for other older cars a few times so I’ll have to try to get the original software up on those some time & have a proper look again.
A big thank-you to Gordon for sharing;
First time this diagnostics used in anger since installing. Found it fantastic for balancing and setting pots while looking out for abnormalities. Nice large readout full screen (15” laptop) can be seen from the cabin while adjusting pots etc.
Thanks to this i found;
Lazy alternator & injectors need cleaning / slight over fuel at idle. Other than that car is driving the best it’s ever been in my ownership..
bounce:
First time this diagnostics used in anger since installing. Found it fantastic for balancing and setting pots while looking out for abnormalities. Nice large readout full screen (15” laptop) can be seen from the cabin while adjusting pots etc.
Thanks to this i found;
Lazy alternator & injectors need cleaning / slight over fuel at idle. Other than that car is driving the best it’s ever been in my ownership..
bounce:
notaping said:
Yes this is the latest version available. I'm currently working on an updated version for a Windows tablet - with touchscreen capabilities etc, but development has stalled. A bit busy on other things just now.
Awesome news - I just bought one of these (Windows 11 tablet for < £100!) for exactly that reason - so that I can easily take it to the car and back for testing without needing keyboard etc so happy to do any testing you need when you do have a chance to add touch support 
Glad it's of use. It's now got touch screen capabilities. Latest version ...
32bit & 64bit installers
AJPDiagnostics_x86.msi - https://api.onedrive.com/v1.0/shares/s!AuU8U8VUHEO...
AJPDiagnostics_x64.msi - https://api.onedrive.com/v1.0/shares/s!AuU8U8VUHEO...
Optimized for a windows tablet (but still runs fine on a laptop) - I've moved the menu from a top bar to a tab (middle left) which open a menu screen. Bigger buttons for fat fingers Also, gains a bit of headroom on the screens. Oh - and it has swipe left / right to move between screens (of limited use).
I managed to find a DELL VENUE 10inch for £25 on ebay. It's on constantly, recording every trip now. Last run (last year) highlighted a failing Lamba sensor - and boy was it running rough. The grey trace on bottom graph.
The adaptives were all over the place. A job I'm just about to tackle.
Unfortunately the app will still only communicate via a serial - usb adapter. I'm looking at getting bluetooth working and will update if / when available.
Cheers - Gordon
32bit & 64bit installers
AJPDiagnostics_x86.msi - https://api.onedrive.com/v1.0/shares/s!AuU8U8VUHEO...
AJPDiagnostics_x64.msi - https://api.onedrive.com/v1.0/shares/s!AuU8U8VUHEO...
Optimized for a windows tablet (but still runs fine on a laptop) - I've moved the menu from a top bar to a tab (middle left) which open a menu screen. Bigger buttons for fat fingers
Also, gains a bit of headroom on the screens. Oh - and it has swipe left / right to move between screens (of limited use).I managed to find a DELL VENUE 10inch for £25 on ebay. It's on constantly, recording every trip now. Last run (last year) highlighted a failing Lamba sensor - and boy was it running rough. The grey trace on bottom graph.
The adaptives were all over the place. A job I'm just about to tackle.
Unfortunately the app will still only communicate via a serial - usb adapter. I'm looking at getting bluetooth working and will update if / when available.
Cheers - Gordon
Juddder said:
notaping said:
Yes this is the latest version available. I'm currently working on an updated version for a Windows tablet - with touchscreen capabilities etc, but development has stalled. A bit busy on other things just now.
Awesome news - I just bought one of these (Windows 11 tablet for < £100!) for exactly that reason - so that I can easily take it to the car and back for testing without needing keyboard etc so happy to do any testing you need when you do have a chance to add touch support Byker28i said:
Interesting, which tablet did you get?
That's an HP Pro x2 612 G2 with a 64bit Pentium 4410Y CPU, 4Gb RAM and Windows 11 Pro - in A+ condition from eBay it was £85.00 and has a full size USB socket on the side so you can just plug your USB to Serial adapter in to the side, Windows 11 automatically loads the drivers for it, and off you goThere are a few similar devices around like the Dell Venue 11 Gordon mentions above which are also similar kind of price if you dig through eBay
Of course now the prices are going to go through the roof as we're all after one (only joking) but it just seemed a better option to me than taking my Mac running Virtual Box to boot up a Windows XP image and then share the USB devices through vs. plug-in and go
Edited by Juddder on Wednesday 3rd April 16:22
Gassing Station | Cerbera | Top of Page | What's New | My Stuff