Correct Matt. Never updates.Matt wrote:Actually I have a S13 240SX KA24E ECU here still to get working... I'll see how that goes with the battery voltage on that. It must be getting some reading to get that figure. But it stays steady? never updates?
NIStune 0.9112 now available
Moderator: Matt
Adam -
As far as the NIStune code goes I cant seem to find anything which would affect the battery voltage not changing
I've tried Type 1 (VLT and S13 KA24E) as well as Type 2 (Z32) with IAT added to the consult table and the battery fluctuates
Can you tell me if this occurs both in tuning mode and in streaming mode?
Can you also tell me if battery voltage fluctuates with any other available consult programs or only NIStune? Perhaps if you can send a debug log through next time you see the problem. Any idea which version you last used when it did fluctuate?
Ken - Had a look at that techedge log tonight. Dont know what is going on. The log received 16 bytes of data and then after that did not receive any more data from the techedge. Are the datalights flashing on the techedge unit after the comms failure?
I'm grabing Petes techedge unit again tomorrow night and will run it again with that version of software to see if its okay still on here....
As far as the NIStune code goes I cant seem to find anything which would affect the battery voltage not changing
I've tried Type 1 (VLT and S13 KA24E) as well as Type 2 (Z32) with IAT added to the consult table and the battery fluctuates
Can you tell me if this occurs both in tuning mode and in streaming mode?
Can you also tell me if battery voltage fluctuates with any other available consult programs or only NIStune? Perhaps if you can send a debug log through next time you see the problem. Any idea which version you last used when it did fluctuate?
Ken - Had a look at that techedge log tonight. Dont know what is going on. The log received 16 bytes of data and then after that did not receive any more data from the techedge. Are the datalights flashing on the techedge unit after the comms failure?
I'm grabing Petes techedge unit again tomorrow night and will run it again with that version of software to see if its okay still on here....
Data light stays on, and i use a splitter and run a dash mounted gauge as well, readings through the gauge are normal, no drop outs. I also tried it without the splitter, just going to the laptop, was the same so its not the splitter as it works ok with older versions of nistune,Matt wrote:
Ken - Had a look at that techedge log tonight. Dont know what is going on. The log received 16 bytes of data and then after that did not receive any more data from the techedge. Are the datalights flashing on the techedge unit after the comms failure?
I'm grabing Petes techedge unit again tomorrow night and will run it again with that version of software to see if its okay still on here....
Here it is, from tonight, connected ok with this one
- Attachments
-
- nistune-1119-1916.log
- (427.77 KiB) Downloaded 236 times
Thanks. Whats the speed of your laptop out of interest?
- Attachments
-
- matt_techedge_shot.JPG
- 0.91122a version running TechEdge (PentiumM 1.8)
- (232.8 KiB) Downloaded 2990 times
Interesting. Been looking at that log
I can see why it is no longer connecting ... it is due to that bug fix I made that wasnt counting cycles correctly before disconnecting
Mainly because the data received is occuring in 'bursts' which is happens with some USB-serial adaptors
Proper RS232 serial data occurs on the fly (ie a fixed constant flow of data). However USB data is sent in packets. Good USB-Serial converters make the serial data appear as a constant 'flow'
However your USB-Serial converter is sending data in chunks with big empty gaps between each chunk. NIStune picks up that if three consecutive receives of data return zero byte then it drops out
In fact, I'm getting upto 0.5 seconds of no data from your wideband unit, before a flood of data comes through.
You can see this in the log where you get a message
Currently this data stream is is pretty bad. It means that you are probably going to get laggy wideband data compared to your consult serial data even if I make a fix...
Currently the poll rate for serial data is 30ms so I need to make it accept about 17 or more poll cycles with no data before disconnecting because of NIStune thinking there is no device connected
That is the fix I will do for now. 0.91123 will be available later tonight with this workaround
I can see why it is no longer connecting ... it is due to that bug fix I made that wasnt counting cycles correctly before disconnecting
Mainly because the data received is occuring in 'bursts' which is happens with some USB-serial adaptors
Proper RS232 serial data occurs on the fly (ie a fixed constant flow of data). However USB data is sent in packets. Good USB-Serial converters make the serial data appear as a constant 'flow'
However your USB-Serial converter is sending data in chunks with big empty gaps between each chunk. NIStune picks up that if three consecutive receives of data return zero byte then it drops out
In fact, I'm getting upto 0.5 seconds of no data from your wideband unit, before a flood of data comes through.
You can see this in the log where you get a message
....08:16:20.500 TechEdgeSerialReadLoop(1): Waiting for 28 bytes, only 0 bytes available
Are the device settings for your USB-Serial adaptor adjustable at all? The FTDI ones are... make the USB packets contain minimal bytes to make it stream better08:16:20.968 TechEdgeSerialReadLoop(1): Waiting for 28 bytes, only 0 bytes available
08:16:20.968 TechEdgeSerialReadLoop(1): Pending wait on read
08:16:20.984 TechEdgeSerialReadLoop(1): GetOverlappedResult: status=1 (EV_RXCHAR )
08:16:20.984 TechEdgeSerialReadLoop(1): (StatusOV) Buffer available bytes: 1 (Errors = 0)
Currently this data stream is is pretty bad. It means that you are probably going to get laggy wideband data compared to your consult serial data even if I make a fix...
Currently the poll rate for serial data is 30ms so I need to make it accept about 17 or more poll cycles with no data before disconnecting because of NIStune thinking there is no device connected
That is the fix I will do for now. 0.91123 will be available later tonight with this workaround
NIStune 0.91223 available tonight
10457 Techedge not working for Ken. Massive gaps in USB serial data
10458 VE Map ECUs not displaying filtered right
10459 Innovate MTS description used in log file header.
10460 Line up USB consult and techedge latency
10461 AFR trace view average same as current
10462 AFR trace description window not user defined names
I had a belkin USB-serial adaptor once and was trying to get it running with the romulator at 115200
It was consistently dropping bytes of data when looking at the hex trace. Two other types (FTDI based and Aten) both worked fine. So I took that one back for a refund
Regarding getting one... Dontronics... see below with the pain Pete has had with these regarding NissanDataScan
http://www.plmsdevelopments.com/usb_adaptors.htm
It was consistently dropping bytes of data when looking at the hex trace. Two other types (FTDI based and Aten) both worked fine. So I took that one back for a refund
Regarding getting one... Dontronics... see below with the pain Pete has had with these regarding NissanDataScan
http://www.plmsdevelopments.com/usb_adaptors.htm
Matt.
I tried the new version this morning, no drop outs and it showed Aux1 with my 3 bar map sensor ok, but A/F ratios read 20.4:1, occasionally dropping to 17, but no where near the mark. If its all to do with the serial adapter just leave it and i'll get a different one. One other thing though, the knock detection ("D") went off its head when i opened with the knock alarm, just kept beeping and the only data i could select was the data coming through the serial cable ie A/F, aux1, aux2 and so on.
I tried the new version this morning, no drop outs and it showed Aux1 with my 3 bar map sensor ok, but A/F ratios read 20.4:1, occasionally dropping to 17, but no where near the mark. If its all to do with the serial adapter just leave it and i'll get a different one. One other thing though, the knock detection ("D") went off its head when i opened with the knock alarm, just kept beeping and the only data i could select was the data coming through the serial cable ie A/F, aux1, aux2 and so on.
Are the AFRs being reported in this new version now inaccurate compared to the 0.9010 version? Or are they just laggy?
Double check your wideband directory is pointing to the TechEdge 2.0 one and attach a debug log if you are still having problems. A better USB-serial converter will help a lot though
On my bench they matched what I was feeding the sensor to the microsecond mark which is good
With the knock detection, when I had some free time, I started adding it but havent finished it off yet.
We worked out some siginificant firmware updates were required to get a proper 'knock count'. I dont have time currently to do that but plan to in the future once problems are sorted out. In the interim, disable the knock warning tickbox and all will be fine after that. The warning limits will change between green/red in this display window when they go above the entered amount
Double check your wideband directory is pointing to the TechEdge 2.0 one and attach a debug log if you are still having problems. A better USB-serial converter will help a lot though
On my bench they matched what I was feeding the sensor to the microsecond mark which is good
With the knock detection, when I had some free time, I started adding it but havent finished it off yet.
We worked out some siginificant firmware updates were required to get a proper 'knock count'. I dont have time currently to do that but plan to in the future once problems are sorted out. In the interim, disable the knock warning tickbox and all will be fine after that. The warning limits will change between green/red in this display window when they go above the entered amount
Very inaccurate. didnt really move off 20:1, i had just started car so it was running about 13:1 cold. If i gave engine a rev they went to about 17:1, still way out. Was definately set for techedge 2. I ordered the adapter from dontronics, has already been sent so i should have it by thursday. Just out of curiousity, i have attached log file from my attempt this morning. its quite large so i zipped it.
- Attachments
-
- nistune-1120-0645.rar
- (308.08 KiB) Downloaded 178 times
Okay the problem is that the wrong wideband files are being loaded for your TechEdge. Serial reading for AFR is fine... although there are gaps between data.
I can tell from the min/max values below:
Kens log:
What you need to do is
File - Configuration - Wideband Lookup Tables location
C:\Program Files\NIStune\Wideband\TechEdge2.0
This will load the correct wideband files for your unit
Might have to make this a bit more obvious after the drop list is selected for unit type, make a message appear
I can tell from the min/max values below:
Kens log:
What it should be:19:45:25.046 Entry 0: Min=800, Max=3200
19:45:25.046 Successfully loaded afr1.csv
I've updated my NIStune code tonight to record the wideband path for me10:59:52.906 Entry 0: Min=895, Max=304289
10:59:52.906 Successfully loaded C:\Program Files\NIStune\Wideband\TechEdge2.0\afr1.csv
What you need to do is
File - Configuration - Wideband Lookup Tables location
C:\Program Files\NIStune\Wideband\TechEdge2.0
This will load the correct wideband files for your unit
Might have to make this a bit more obvious after the drop list is selected for unit type, make a message appear