Nistune Forums

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?

Correct Matt. Never updates.

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....

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....

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.

Still playing this end, i did a complete uninstal and reinstal, same thing. I still have to go back to version 0.9110.

Looking into it tonight since I've got the TechEdge here again

If you happen to be running 0.9110 with your wideband can you get me a debug log from that also?

I only have one difference now which is a bug I fixed to do with not disconnecting when no data received

Here it is, from tonight, connected ok with this one

Thanks. Whats the speed of your laptop out of interest?

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

08:16:20.500 TechEdgeSerialReadLoop(1): Waiting for 28 bytes, only 0 bytes available

....

08: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)

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 better

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

thanks matt, i appreciate your time and effort. Laptop is a 1.6 ghz running xp SP2. I'm using a belkin serial to USB adaptor. I'll look at getting a FTDI adaptor. Any recommendations?

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

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.

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

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.

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:

19:45:25.046 Entry 0: Min=800, Max=3200
19:45:25.046 Successfully loaded afr1.csv

What it should be:

10:59:52.906 Entry 0: Min=895, Max=304289
10:59:52.906 Successfully loaded C:\Program Files\NIStune\Wideband\TechEdge2.0\afr1.csv

I've updated my NIStune code tonight to record the wideband path for me

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