Regarding bug 10330 (TE WBo2 disconects)

ByReaL · Post by **ByReaL** » Fri Apr 20, 2007 6:17 am

I'll attach to this bug some nistune logs, that where get when the TE WBo2 was connected (and from time to time it it has been disconecting).

i have noticed that if you switch focus from nistune to other software or if i open any program (winamp, IE, any software) the chances that the nistune loose conectivity eith the TE WBo2 are incresed (i could not reproduce the problem all the time by opening a software, still serching a way that will reproduce the problem always)

system:
windows xp sp2 (all updates done)
laptop with USB 1.1port
serial to usb convertor
TE WBo2 2A0 unit
(must mention that when using in same setup the TEWBLOG software never had connection problems)

Matt · Post by **Matt** » Fri Apr 20, 2007 2:48 pm

That happens is that when NIStune is out of focus... windows allocates less processor time to the software

Whilst that is happening the wideband data is still streaming in at 9600bps

When NIStune gets its allocated portion of processing time... it is likely that the buffer has been quite filled up and then starts having problems finding the next frame and disconnects

I'll have a look at the logs and try this out on a slower laptop so see if I can reproduce easily

ByReaL · Post by **ByReaL** » Mon Apr 23, 2007 6:27 pm

is this posible to be solved, by introducing an automatic retry to reconect?

you are conected, and instead of giving you an error message that you have lost conection, maybe the software could try to reconect, if fails try again, and again, and if it is failing 3 times in a row only then give you the error message (and maybe give the user the posibility to set the time betwen retryes), this way i belive the disconect from the moment when the engine is started wil lbe fixed also,

the only problem with this aproach is that there will be some data lost during that disconect and retry to reconect.

Matt · Post by **Matt** » Wed Jun 06, 2007 9:39 pm

CR10330

Matt · Post by **Matt** » Sun Jul 08, 2007 1:27 am

finally looking into this one...

17:32:37.056 TechEdgeSerialReadLoop(): GetOverlappedResult: status=1 (EV_RXCHAR )
17:32:37.056 (StatusOV) Buffer available bytes: 0 (Errors = 0)
17:32:37.056 TechEdgeSerialReadLoop(): Reset status event
17:32:37.056 TechEdgeSerialReadLoop(): Status Buffer available bytes: 0 (Errors = 0)
17:32:37.056 TechEdgeSerialReadLoop(): Pending wait on status
17:32:37.437 TechEdgeSerialReadLoop: GetOverlappedResult: bytes=0

this is the log area of interest. the EV_RXCHAR indicates the serial-USB converter is reporting it received data, however the actual data bytes returned is 0. we normally would disconnect on this situation

this should not happen on a 'real' serial device since when you get a receive indication, you should have data

anyway we had the same problems with USB-Serial converter with Nissan Consult. What I have done to get around this (such as blazt consult devices) is introduce some tolerance for these issues. It will accept zero bytes of data several times in a row, before it actually does a disconnect.

This stops the disconnect in the event this occurs, however if the USB-Serial device keeps reporting 0 bytes for every following EV_RXCHAR received, then we will get no more useful data.... so then we disconnect

Some USB-Serial devices just dont implement the protocol properly it appears. I've seen this a few times

So I have added this tolerance code for all serial wideband units in the next 0.9105 version to be released tonight. It should get around your disconnect issues

However I still will keep problem report open for automatic reconnect plus retries when disconnect occurs. This needs to happen for all wideband devices. I've experienced the annoyance of having to reconnect wideband after starting ignition since my wideband is powered from accessories and loses power temporarily when starting car!