I have been struggling with the occasional lockup problem of the OBDLink device. To be fair the device is probably not designed for continuous high speed operation as we do in PriiDash. I am copying info from this original thread: https://www.scantool.net/forum/index.php?topic=5027.90 The symptom of the lockup issue is that the device stops responding to commands and keeps sending the same message to the PC. At this point the only cure is to disconnect both the USB and the OBD cables. Then reconnect them. There is another, much less frequent issue, but I nevertheless noted it in the post below, that the device would reset itself. The reset undoes some of the initialization steps of PriiDash. In this case one has to click the Go/Stop button twice to stop and re-initialize the device.
Record of lockup events My car is almost exclusively used for daily commute, about 40 ~ 60 minutes each way. Here is a (partial) list of the lockup events that I have experienced: Locked up again this morning 2011-07-27. Update: happened again this morning 2011-07-28. Update: and again the same day afternoon 2011-07-28. Update: Updated the FTDI drivers to the most recent version yesterday 2011-08-02. It went well for two trips yesterday but this morning it got stuck again 2011-08-03. Today 2011-08-04 OBDLink decided to reset itself again during a trip. Very frustrating. Update: got stuck again this morning 2011-08-05. And again this afternoon 2011-08-05. And again this morning 2011-08-08. Yet again this afternoon 2011-08-10. This is after removing one of the multi-frame queries from the program. And again the next afternoon 2011-08-11. Yet again afternoon 2011-08-16. 2011-08-17 afternoon. 2011-08-22 afternoon. 2011-08-24 afternoon. 2011-08-30 morning and afternoon. 2011-08-31 afternoon. Just had two lockup in a row this afternoon 2011-09-15. I have changed the FTDI driver parameters packet size from default 4096 to 2048 and latency from default 16 ms to 2 ms since 2011-09-01 afternoon and haven't had a lockup event until today. I am changing to 1024 and 2 ms. Crossing my fingers ... Update: This afternoon 2011-09-20 OBDLink decided to reset itself again. At least in this case no cable disconnect/reconnect is needed. This morning 2011-09-21 OBDLink locked up again. 2011-09-22 lockup again (512, 1ms) 2011-09-27 lockup again (1024, 1ms) 2011-09-30 lockup again (2048, 1ms) At this point I have exhausted the parameter space. Still no solution. 2011-10-03 lock up again. 2011-10-04 lock up again. 2011-10-06 lock up again. (1024, 1 ms) I will let it lock up three times before moving to the next setting to see if at least there is some combination of parameters that at least lock up less frequently. 2011-10-06 lock up 2nd time. 2011-10-07 lock up again. 3 strikes in 3 consecutive trips. This is the most frequent seen so far. 2011-10-11 lock up after 3 good trips. (512, 1 ms) 2011-10-13 lock up after 3 good trips (and a 4th very short one). 2011-10-14 lock up after 1 good trip. This ends the 512, 1ms combo. 2011-10-17 lock up after a few good trips. (256, 1 ms) 2011-10-24 lock up 2X in the same trip after quite a few good trips. 2011-10-27 lock up after 4 good trips. 2011-10-27 lock up again at a new setting. (384, 1 ms) 2011-11-01 lock up again after a few good trips. 2011-11-02 lock up. 2011-11-03 lock up. 2011-11-04 lock up. (192, 1ms) 2011-11-09 lock up in the morning after 4 good trips in previous days. 2011-11-09 lock up again in the afternoon. 2011-11-29 lock up when the weather got warmer after a period of cold weather and no lock ups. I start to suspect temperature again. 2011-12-02 lock up. 2011-12-05 lock up. 2011-12-05 lock up in another trip soon after changing to (256, 1ms). 2011-12-08 lock up. 2011-12-14 lock up. 2011-12-15 OBDLink resets itself. 2011-12-20 lock up. 2012-01-03 lock up. 2012-01-04 lock up. 2012-01-05 lock up. 2012-01-06 lock up. Hmmm... It's getting more frequent now. Don't know why. 2012-01-07 lock up. 2012-01-10 lock up. 2012-01-11 two lockups in one trip.
What has been tried to solve the issue Fellow PriusChatter ccdisce kindly spent a lot of time debugging and modifying the device without much luck. I am truly grateful for his effort and generosity. I have tried Swapping the device and cables Removing ScanGauge and Y cable Changing serial port timing settings without any luck either. The only clue I have is that the lockup seems to happen less frequently if I remove some multi-frame request(s).
Re: What has been tried to solve the issue Scangauge also has some issues when it started to support multi-frame msg. I have not read this multi-frame issue with Torque, so I don't think it is because of that.The only difference I think is Torque did not support passive requests, both SG and PriiDash uses them. Perhaps you can try to use purely solicited commands? Leave out those passive commands for the moment to see if the problem is still there. Vincent
Re: What has been tried to solve the issue The folks at ScanTool just put out a firmware update for the OBDLink SX, and hopefully have fixed this issue. ScanTool.net, LLC - Firmware Updates for OBDLink SX
I received a couple e-mails from them this past Monday and have been evaluating the fix in the STN1110 chips that I bought from them. I have also updated the FW in the OBDLink_SX device but not yet run it on a daily commute. I have since made 8 1hr runs with the Priidash20120419 load and my interpretation of their reference design and they were satable with no lockups or resets. Logs were clean.
The new firmware fixed the most frequent lockup issue but there are still less frequent issues such as the SX self-reset or keeps saying "OK" or "STOPPED".
IMHO From what I have read the "OK" is an aknowledgement that the interpreter understood the command/specific request sent to it... maybe it can be supressed I do not know, apart from ocupying bandwidth not that important. The datasheet for the ELM says "STOPPED" is an indication the the OBD Process Loop was interrupted by either by receipt of a UART char, a low on the RTS or Timer timeout. If it is the Sleep Timer or some timer expiring and generating an interrupt which puts out the stopped message before it tests where the interrupt came from well we could be OK but we may want to get the FW fixed. As there is no RTS on the STN part, glitches on the UART lines or Interrupt masking may be in order.
2009Prius. I did some further checking and the STOPPED messages are valid and is a response to the specific requests that are being sent every 200mS when Pridash is run in the NORMAL mode. The eCAN engine is interupted on receipt of a char by the UART and the char itself is probably trashed. If Pridash is run in the ATMA only mode i.e Priidash is not requesting by sending chars to the UART port no 'STOPPED' messages show up in the Log. If additonal STOPPED messages show up then they could be due to noise on the UART_RX pin of the STN111xx
Thanks for helping with this issue. For others who didn't know ccdisce has been spending a lot of time helping with this issue from the hardware side. I hope this "STOPPED" issue can be fixed by firmware like the lockup did.
Does the "STOPPED" issue occur with any baud rate or only 2M? I'm trying to decide between purchasing the OBDLink SX or the cheaper ElmScan 5, which is limited to 500k. I'd rather get the SX if it's stable at 500k and if it's possible future firmware updates may fix stability issues at 2M. If stability is a problem at any baud rate, I'll go with the ElmScan.
I am testing beta firmware for OBDLink SX at 2M baud rate and so far it looks like they may have finally fixed the various issues I was experiencing. Give me a week or two to be sure of the result, but so far it looks very promising (no problem yet).
Ran the STN3.1.0 Load and the Priidash2 0622 Load and Lockup Problem seems to be fixed. There could be other issues tho as I see readings that are obviously in error recorded on the screen in the max/min history nos and probably in the Logs.
http://thumb19.webshots.net/t/90/90/1/78/21/2643178210070670239hTgOeI_th.jpg A HOT run in HOTLanta. No more Lockups with STN1100/r3.1.0 and Priidash2_20120622
Could you repost that screenshot with good resolution? It's only a thumbnail from that link. Thanks, curious to see your temps.
Some of the max/min nos are in error. Try this link for a larger image. http://image90.webshots.com/90/1/78/21/2643178210070670239hTgOeI_fs.jpg
Yow! The car seems to be doing OK with MPG. Was the A/C on? I see those kind of temps for MG1 and MG2 due to steep hills. But with mid 80's F outside temps, my inverter and battery temps are rather lower.
OBDLink guys fixed a few bugs in the firmware (including the lockup issue) and they should come up with an official release soon.
