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)
Regarding bug 10330 (TE WBo2 disconects)
Moderator: Matt
Regarding bug 10330 (TE WBo2 disconects)
- Attachments
-
- Logs.rar
- (777.91 KiB) Downloaded 84 times
* Got CA18DET Love
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
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
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.
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.
* Got CA18DET Love
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!
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!