NEW Windows 64 bit AJP Diagnostic Software
Discussion
Hardtailer, Thanks for trying the app and for your feedback.
Correct me if I'm wrong here, but I believe you might be in the Netherlands - and if so, this is almost certainly a problem with numeric punctuation. The range values for each ECU parameter are stored in a config file in "Program Files\KCC\AJP Diagnostics\Resources\Config" and for most parameters the value has a decimal "point". I think this is being interpreted as a thousand separator on your machine and throwing all the calculations out.
Unfortunately it's not just a simple case of swapping the punctuation in the config files because the values are comma separated and changing a point to a comma will mess up the parsing routine.
The quick and annoying fix for you is to change your computers locale to the UK while running the app. Not ideal, but it should work. Meanwhile I'll have a think about a more robust or configurable option. Unfortunately my time is very limited just now to work on the app, so I can't give any timescale for a fix.
The adaptives are a different problem which I think might be a timing issue (processor speed and MBE response times etc) - which is why it always works on my laptop because that's been used while testing. I know others have reported problems. I've included a configurable variable in the application config file - "C:\Program Files\KCC\AJP Diagnostics\AJPDiagnostics.exe.config". Look for <add key="AdaptiveDataReadWaitTime" value="200" /> - change the value to 300/400/500 etc. Or reduce the value - 50 etc. Basically - experiment and see what happens. You'll need to restart the app after changing the value.
The application tries to read the data from the MBE - if there's nothing in the input buffer it waits for a specific time, then tries to read the buffer again. It tries this a number of times before giving up and going back to reading the realtime engine parameters. This is why I'm hoping that adjusting the wait time might fix the issue.
If you get any success with this, please let me know. Also, if anyone else out there has managed to read adaptive values - would be good to know.
Cheers.
Correct me if I'm wrong here, but I believe you might be in the Netherlands - and if so, this is almost certainly a problem with numeric punctuation. The range values for each ECU parameter are stored in a config file in "Program Files\KCC\AJP Diagnostics\Resources\Config" and for most parameters the value has a decimal "point". I think this is being interpreted as a thousand separator on your machine and throwing all the calculations out.
Unfortunately it's not just a simple case of swapping the punctuation in the config files because the values are comma separated and changing a point to a comma will mess up the parsing routine.
The quick and annoying fix for you is to change your computers locale to the UK while running the app. Not ideal, but it should work. Meanwhile I'll have a think about a more robust or configurable option. Unfortunately my time is very limited just now to work on the app, so I can't give any timescale for a fix.
The adaptives are a different problem which I think might be a timing issue (processor speed and MBE response times etc) - which is why it always works on my laptop because that's been used while testing. I know others have reported problems. I've included a configurable variable in the application config file - "C:\Program Files\KCC\AJP Diagnostics\AJPDiagnostics.exe.config". Look for <add key="AdaptiveDataReadWaitTime" value="200" /> - change the value to 300/400/500 etc. Or reduce the value - 50 etc. Basically - experiment and see what happens. You'll need to restart the app after changing the value.
The application tries to read the data from the MBE - if there's nothing in the input buffer it waits for a specific time, then tries to read the buffer again. It tries this a number of times before giving up and going back to reading the realtime engine parameters. This is why I'm hoping that adjusting the wait time might fix the issue.
If you get any success with this, please let me know. Also, if anyone else out there has managed to read adaptive values - would be good to know.
Cheers.
hardtailer - That's good news the figures are now correct with the decimal point fix. Hope you get some use out of it.
I've had another look into the Adaptives problem. There's obviously a bigger problem than I initially thought. I've been playing around with the 'wait' numbers in the config file and have found that there is only a very narrow window where it works. This wasn't obvious from initial testing, but from the few feedback comments and some trials today I must admit - it is a bit flaky!
I've used the following values for the InterfaceWaitTime & the AdaptiveDataReadWaitTime . . .
I've found that ADRWT between 40 & 60 works best, any greater and the values tend to disappear? And if the IWT is too small the application seems to loose connection after reading the adaptive values.
Not good. Will delve back into the code to see what's going on.
On the plus side - It does work if you find the correct values. I read these successfully today . .
I'll keep plugging away . . .
I've had another look into the Adaptives problem. There's obviously a bigger problem than I initially thought. I've been playing around with the 'wait' numbers in the config file and have found that there is only a very narrow window where it works. This wasn't obvious from initial testing, but from the few feedback comments and some trials today I must admit - it is a bit flaky!
I've used the following values for the InterfaceWaitTime & the AdaptiveDataReadWaitTime . . .
I've found that ADRWT between 40 & 60 works best, any greater and the values tend to disappear? And if the IWT is too small the application seems to loose connection after reading the adaptive values.
Not good. Will delve back into the code to see what's going on.
On the plus side - It does work if you find the correct values. I read these successfully today . .
I'll keep plugging away . . .
Hardtailer, Glad you got it working. Unfortunately I can't help with interpreting the values. Mine's a V8, I know nothing about Sp6 setup - sorry. Perhaps there's someone out there with Sp6 tuning experience who can offer some advice on this.
I haven't come across a csv loading problem before. What are the symptoms? Do you get any error messages?
I haven't come across a csv loading problem before. What are the symptoms? Do you get any error messages?
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.
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.
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.
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
Hi classic105.
I think this problem was reported once before. The software is initiated by reading comma separated config files. I believe you're located in France - in which case your decimal separator is a comma. This creates problems when trying to parse the config files.
Changing the locale of your PC to the UK should fix the problem. Not ideal I know, but not something I considered when writing the software.
Cheers.
I think this problem was reported once before. The software is initiated by reading comma separated config files. I believe you're located in France - in which case your decimal separator is a comma. This creates problems when trying to parse the config files.
Changing the locale of your PC to the UK should fix the problem. Not ideal I know, but not something I considered when writing the software.
Cheers.
That's great. Large screen, home use etc - that was my initial goal, but that was when I was using my laptop. Now with a tablet, I have it running every journey (day trips). The benefit there is that if a problem develops (and let's face it - they usually do) - you have a before and after recording of the engine. It makes diagnosing the problem a lot easier.
If you've been using your phone via a bluetooth adapter, there's a possibility it might work with the app. When you've paired the adapter with the tablet - go into "More Bluetooth Options" --> "COM Ports" and Add a virtual pair of ports for the bluetooth device. The app should pick up the outgoing port and connect as normal. Note - I've been unable to test this as I don't have a working bluetooth adapter, but according to all the bumf online - this should work.
G.
If you've been using your phone via a bluetooth adapter, there's a possibility it might work with the app. When you've paired the adapter with the tablet - go into "More Bluetooth Options" --> "COM Ports" and Add a virtual pair of ports for the bluetooth device. The app should pick up the outgoing port and connect as normal. Note - I've been unable to test this as I don't have a working bluetooth adapter, but according to all the bumf online - this should work.
G.
If you're going for a bluetooth device - Windows won't create virtual COM ports for BLE devices. You need the older Bluetooth adapters.
The adapter I got was S2B5232E - as listed on RS-AJP site. This turns out to be a BLE device and while it obviously works using bluetooth (GATT) protocols, I can't communicate using old serial port protocols - which is what is written into the app. To communicate via BLE requires a bit of a re-write.
The adapter I got was S2B5232E - as listed on RS-AJP site. This turns out to be a BLE device and while it obviously works using bluetooth (GATT) protocols, I can't communicate using old serial port protocols - which is what is written into the app. To communicate via BLE requires a bit of a re-write.
Luckyone said:
I'm guessing that should be x32.msi on your links there rather than x86.msi?
Luckyone - Don't start on the illogical naming conventions of Microsoft , however - x86 refers to the processor architecture of the time. More info here . . .https://you.com/search?q=%20%20%20%20%20why%20is%2...
Glad you're finding the app useful.
camel_landy - I'm not explicitly encrypting anything - just uploading to the cloud (OneDrive). I can only assume if you're having problems that it's something built into Microsoft OneDrive. More on their encryption here - but I'm not actively encrypting files or folders.
https://you.com/search?q=onedrive%20download%20enc...
G.
Ah. Ok. Got you. Additional security check.
Hash values generated from the local build copies:
Algorithm : SHA256
Hash : 926FB7D17F38BFEF5E3D54AE86268E746EA02AA81280A2FDC8419D9954AA2C3B
Path : T:\AJP Diagnostics\builds\32bit\AJPDiagnostics_x86.msi
Algorithm : SHA256
Hash : 80DE5EE132A0632AF29A08882F6CE53035068E8F025724EA5B3D2A3091F47D02
Path : T:\AJP Diagnostics\builds\64bit\AJPDiagnostics_x64.msi
Hash values generated from the local build copies:
Algorithm : SHA256
Hash : 926FB7D17F38BFEF5E3D54AE86268E746EA02AA81280A2FDC8419D9954AA2C3B
Path : T:\AJP Diagnostics\builds\32bit\AJPDiagnostics_x86.msi
Algorithm : SHA256
Hash : 80DE5EE132A0632AF29A08882F6CE53035068E8F025724EA5B3D2A3091F47D02
Path : T:\AJP Diagnostics\builds\64bit\AJPDiagnostics_x64.msi
Rufus - Great! Another happy user (so far). The red backgrounds - you've probably worked out - are logged faults. You can clear them from the menu screen. I wouldn't worry about them on first start. Only if they appear after a run.
I winterize my car every year and like you my adaptive values disappear over time. I replaced the Dallas chip a couple of years ago, but the same thing still happens. I wouldn't worry about it. So long as the values build up when you start using the car, and remain over summer. I usually reset them every spring in any case when it's serviced before summer use.
I've also started taking the tablet with me on all long runs and logging the trips. There's more than enough memory, the only consideration is battery life. I'm currently trying to fabricate a mount for it to fit under the radio.
Cheers. G.
I winterize my car every year and like you my adaptive values disappear over time. I replaced the Dallas chip a couple of years ago, but the same thing still happens. I wouldn't worry about it. So long as the values build up when you start using the car, and remain over summer. I usually reset them every spring in any case when it's serviced before summer use.
I've also started taking the tablet with me on all long runs and logging the trips. There's more than enough memory, the only consideration is battery life. I'm currently trying to fabricate a mount for it to fit under the radio.
Cheers. G.
Gassing Station | Cerbera | Top of Page | What's New | My Stuff