Nistune Forums

different internals. looks like a prolific knock off. no part numbers unlike in that ebay post

http://www.ebay.com.au/itm/RS-232-SERIA ... 41503ea6f5

Matt wrote:different internals. looks like a prolific knock off. no part numbers unlike in that ebay post

http://www.ebay.com.au/itm/RS-232-SERIA ... 41503ea6f5

You have the same internals than me except the part # is visible on my Prolific chipset: it's PL2303HX
The RS232 converter is ADM211 from Analog DEvices. This is a good chip.

0.10.5, another nasty behaviour regarding cursor and navigation in log player (file playback):
_when dragging the cursor with the mouse to a given location, the graph is not updated ==> agrhhhh
_if you mouse click on the scale (not on the cursor), the cursor is moved forward or backward and the graph is updated by portion ==> that's ok
_selecting Fit, positionning the red bar to a given location, unselecting Fit ==> agrhhhh the graph is not zoomed back to the wanted location but shows the beginning again
_fast playback doesn't start when Fit is selected.

Saying all that means you should test all the features of the log player carefully.

1) Nistune running, log player recording
2) switch ignition off ==> not trouble here, log player stops after a while asking "keep the file ..."
3) unplugging the 2 USB cables ..... unhandled exception

Cant repeat this one. My testing:
1. HCR32 ECU connect consult (Prolific converter 2.0.0.26 COM 3 +PLMS serial cable)
2. LC-1 connect with Prolific converter (2.0.0.26 COM 4)
3. Start log player and hit record
4. Disconnect power to HCR32 ECU and LC-1 simulatenously
5. Get Nistune pause (MTS attempts retries about 1-2 seconds freezing the software) then disconnect of consult/wideband
6. Get message in logger
7. Tried disconnecting both prolific devices before 'yes' to save and after 'yes' to save but no crashing

Anything I did differently here?

<edit>
I think this one is very timing dependent. From what I can see since MTS holds up the software, our waiting time for consult to shutdown properly times out. Then when this occurs it causes a crash because a thread is still running when we attempt to complete the shutdown regardless. I'll increase the consult wait thread timer to longer to compensate for the MTS delay introduced

_when dragging the cursor with the mouse to a given location, the graph is not updated

Are you talking the slider bar at the top? Agreed its the last navigation problem I have remaining with the logger from what I can see

_selecting Fit, positionning the red bar to a given location, unselecting Fit ==> agrhhhh the graph is not zoomed back to the wanted location but shows the beginning again

This is because the graph view is totally reset. Fit view is just reloading the whole lot and fitting to the screen. Any previous log position information is not kept. I've updated the code tonight to record the current log position and red line position and then put it back when 'fit' is unticked

_fast playback doesn't start when Fit is selected.

This is because there is nothing to 'play' fast as such. You will notice that you cannot 'play' either when in this mode since that has not been implemented this way. It moves the graph whilst playing and that updates the parameters. When the play button is used, it runs through the log on the screen. When in fit mode, everything is fit on the screen. Too difficult to implement at this time, when you can unfit, and then do fast playback. I've greyed out the play and fast play buttons to indicate this now

Matt wrote:

_when dragging the cursor with the mouse to a given location, the graph is not updated

Are you talking the slider bar at the top? Agreed its the last navigation problem I have remaining with the logger from what I can see

Yes.

You told you cannot achieve the same level of features in Fit mode (I would call it zoom-out) compared to normal mode.
The underlying problem is everybody has some reflexes regarding PC software use and waited behaviour, then wanted behaviour
_Zooming out, start fast playback at any location ==> this allows to have an overview of full throttle areas in one look, and checking filling of wideband input tracer in parallel ...
_Fast playback, once running, cannot be stopped ==> you cannot quickly fill in wideband input tracer and stop to check the AFRs on the selected portion ... (remember the boundary limit to 50 in wideband input tracer ..)
_not having the graph updated when fast playing is disturbing

This is why I consider the current log player behaviour is erratic ...

Matt wrote:

1) Nistune running, log player recording
2) switch ignition off ==> not trouble here, log player stops after a while asking "keep the file ..."
3) unplugging the 2 USB cables ..... unhandled exception

Cant repeat this one. My testing:
1. HCR32 ECU connect consult (Prolific converter 2.0.0.26 COM 3 +PLMS serial cable)
2. LC-1 connect with Prolific converter (2.0.0.26 COM 4)
3. Start log player and hit record
4. Disconnect power to HCR32 ECU and LC-1 simulatenously
5. Get Nistune pause (MTS attempts retries about 1-2 seconds freezing the software) then disconnect of consult/wideband
6. Get message in logger
7. Tried disconnecting both prolific devices before 'yes' to save and after 'yes' to save but no crashing

Anything I did differently here?

<edit>
I think this one is very timing dependent. From what I can see since MTS holds up the software, our waiting time for consult to shutdown properly times out. Then when this occurs it causes a crash because a thread is still running when we attempt to complete the shutdown regardless. I'll increase the consult wait thread timer to longer to compensate for the MTS delay introduced

Yes, it's random behaviour.
Tonight, I gave it another try and I got it when re-plugging both cables after step 7.
Later, I also got it when closing Nistune after step 7, without disconnecting the cables.
This should be robust because I often forget Nistune logging is ongoing when I switch off ignition .... then, I save the file, quit Nistune, unplug and standby laptop ....

FYI, I just changed my 2 cables for FTDI ones
http://cgi.ebay.fr/ws/eBayISAPI.dll?Vie ... OC:FR:1123

Hi Matt,

Please see my thread here: viewtopic.php?f=18&t=1969

Bug with DLP IO8 G reading "9.00" constantly for AFR. Downgraded to 0.9.14.22 and it seems to work.


Cheers!
-Shaun

Shaun - DLP issue found and now fixed. Will be in next version

You told you cannot achieve the same level of features in Fit mode (I would call it zoom-out) compared to normal mode. The underlying problem is everybody has some reflexes regarding PC software use and waited behaviour, then wanted behaviour

The issue here is that originally there wasnt even a fit mode (btw It was called fit since it fits the log to the screen). I had a user request last year to add a tickbox so they could see the whole graph on one screen - that was the request. I added it and they were happy. There was no request to specifically add logging playback whilst in Fit mode. If people are using it to zoom in/out whilst using the log then I can add that to my enhancement list and code that in later. In the meantime I've added code to return user to the previous location and working on this also when zooming in/out that the same location is kept

There will be significant coding work to do a 'playback' and run the line through this log so I can put it on my list if required. Obviously resolving issues such as crashing is higher priority at this time.

_Fast playback, once running, cannot be stopped ==> you cannot quickly fill in wideband input tracer and stop to check the AFRs on the selected portion ...

Agreed. Saw this issue last night. There are too many windows display updates when playing in fast mode that the window refuses to accept user input due to this. I'm thinking about what can be done to allow the buttons (such as stop button to cancel fast playback) to be functional again

remember the boundary limit to 50 in wideband input tracer

yes still on the list

_not having the graph updated when fast playing is disturbing

How come? The intention of fast playback is to fill the AFR playback view. If I start updating all the graphs then it will slow down the machine too much since there is too much data for it to process especially for long log files. I had to intentionally remove graph updates on fast playback to stop Nistune freezing up.

We already are having issues with fast playback freezing up the rest of the software due to too many UI updates which I'm having to work with. Updating all the graphs for each update will only make it worse, unless I only update say 1 in 10 log entries to the screen during the update to simulate graph updates (but not all of them)

Tonight, I gave it another try and I got it when re-plugging both cables after step 7.
Later, I also got it when closing Nistune after step 7, without disconnecting the cables.
This should be robust because I often forget Nistune logging is ongoing when I switch off ignition

I'm thinking the increase of the thread close wait should resolve this issue. We will see and I will continue to test the same scenario here. Crash issues are my main priority in regards to fixes

gonna be real technical and say the red flashy adress type things are nice in the new version

must admit i never have any issues with any of the updates... xp FTW and i use consult via serial...

Matt,

The lookup table are wrong again for Innovate. You said you had changed them a couple of revisions ago, but it looks like you accidentally changed it back?

It should be:
0 7.35
1023 22.39

It is currently:
0 8
1023 32

Okay I've updated the ones used by the installer to use those values again

0.10.6
Updates to logger fit mode, and moving to ends of log files
AEM UEGO and DLP A/D converter AFR reporting fix
Type 1 number of parameters incorrect affecting gauge reporting
Prevent window resize on cascade/tiling of windows
Add RPM/TP safe parameters for supporting HCR32
Fix for intermittent missing display mapview
Clear gauges when disconnect for Type 1
Change map highlighting from pink to green
+ Increased timeout with consult also for crash issues on simultaneous MTS/consult disconnect
+ Correct Fahrenheit reporting for temperature

Still to fix:
- Innovate logging files (next version)
- Freeze on fast playback (also see if I can update gauges periodically too and allow stopping)
- Increase samples in input tracer and improve algorithm for averaging over samples when limit reached
- Logging when connecting/disconnecting sensor handling (noted does not always disconnect when extra sensor added in midlde of logging). Also continue navigation improvements when zooming and investigating problems with blank log files (multiple log requests when saving)
- AFR vs RPM tracer

maglito wrote:Matt,

The lookup table are wrong again for Innovate. You said you had changed them a couple of revisions ago, but it looks like you accidentally changed it back?

It should be:
0 7.35
1023 22.39

It is currently:
0 8
1023 32

AHA. This maybe why im having issues with differing AFR to my dyno.
I just changed this.
Is it correct to have it as above or is it supposed to have comma's
0, 7.35
1023, 22.39
?