FAQs | Troubleshoot - Need help? Ask questions here.

Thanks for that. I see that it is linked to libboost_thread.so.1.46.1. The Ubuntu repositories on my two machines are only up to version 1.42. I went to Sourceforge to download the 1.46.1 source but it looks like another one of those software odysseys- 10,000 files in 285Mb, and I couldn't immediately determine how to compile it.

Hopefully you can determine how to make the static linking... <:-|

OK, I didn't know about the disk renaming tool. So I did that, and I have a f:\ODBLog folder. But no change, the program still quits with the same error message as before. For some reason on XP (SP3) the program is not seeing that folder, although it shows up just fine in Explorer.

I'll keep poking around a bit, but that's the report thus far.

 

Dang.....<headsmack>I have seen the same typo on some projects on Sourceforge</headsmack>

OK, got past that point, now will try on car.

Thanks.

 

Hi 2009, sorry, my laptop was down! But here are the log files. Part I is an example of what I experience about 1 out of 20 times that I run the program. You can see that all the way up until Line 1650 of the CSV file, I have several gauges not working, or working improperly, and then all of a sudden, the RPM column jumps to a random number in this case 16,878 RPM and gets stuck there. At that same line, several other columns suddenly get populated with data, albeit incorrect. The Part II file is the file after I pressed STOP/GO. The 16,878 RPM remains and all of the calculations and several other gauges continue functioning incorrectly. Need anything else? Also, whats your PP adress?

 

ok i hope i have the right topic here.
i installed the windows version
also i have a elmscan 5 usb its a old model ( 2008 ) only 500k baud possible

when i start the windows program and set the com port and baud rate and click in GO the program crashed

before i was thinking the elm is not set at 500k but after connecting a terminal program i got a response with version number of the elm at 500k only so thats set to 500k for sure.

when i select simulation ( i guess without a car connected? ) it also crashed.

other people with the same problem?

 

Hey just threw you some cash...Did you have a second to take a look at my logs? I decided to try the program on another laptop, and I could not even get the program to run. The ticker would start but no action. I have become accustomed to knowing how to plug and unplug and restart to get the program working, but on the other laptop it just would not work....


Also, I downloaded the newest windows version, and immediately I noticed that the same problem (half of the gauges not working) was present AND as well as the output was jittery...It would display the information in a very fast "stop and go" type way. Every second of half second, it will freeze ever so quickly, then data will show, and so on and so forth, This does not happen in the older versions I am running.

 

Excellent well at least you've found the problem! If I knew anything about code, Linux, or the OBD Protocol I'd help.

 

Hey! It works! Thanks so much! But I noticed a few things. It is very choppy, as I described the other versions earlier. Any idea why this might be? Anyway to apply this fix to the September release that is not choppy?

Also, I think you have a multiplication factor of 10x on the MG1 and MG2 KW readings....

Could you tell me exactly what the following displays are?

KW 1 and 2 (i know they are engine KW, but which is which)
KWreq
Efficiency (should eff1 always be 29-30%?)

 

Here is the csv log from a 20 minute trip today. (I renamed it to .txt) As far as I could tell from the odd glance at the readouts, priidash was giving me reasonable data as far as RPM, ICE temp, and other temps were concerned. But I am not really understanding what the log data is telling me when I import it into the spreadsheet.

I am mostly interested in inv1T, inv2T, mg1T, and mg2T. Those columns don't seem to track with what I was seeing on the screen. This drive was on a very hilly road, steep ups and downs, lots of regen braking, slow speeds, twisty turny, lots of electric only mode, and an overall mpg of about 52. (If you have been to East Maui, you know what I am talking about.)

At the end of the trip, priidash was giving high temp >50C for mg1 and mg2. The gauges were yellow. Given that the trip was pretty electric intensive but also a bit slow so not much air flow, I can believe that they might be getting hot. The car gave no indications or codes, and drove fine. So I don't know if what I was seeing was real or not, and how much to be paranoid about it.

My laptop was sitting on the back seat, so I don't know how much noise I am getting into the system. I was using my OBDLink SX at 2Meg data rate. As I say, the main gauges looked to be smoothly responding, so the GUI seems like it's working OK.

What do you think?

 

No need to envy the road. It is notorious, and hard on the equipment, human and metallic. It has advantages and disadvantages.

In reading through the CSV log, I see that a number of the columns do get stuck at one value after a while, except for mg2T, which continues to climb from 0.0 to 5.93. So that one seems to be reporting something proportional to the actual temp. Odd. What are the units? The other temps inv1T, inv2T, mg1T, seem not to be on the same page at all.

The whole log file, even zipped, is still 2.7Mb. I truncated it, leaving the first few minutes, then continuing later before the point at which most of the data seems to go static, where the .CSV line number stays at 701154. I did notice that things seemed to lock up, similar to what you are describing on the OBDLink forum, and did restart it after shutting off the car. The log file shows that no data is being read. Too bad, I hope they can figure that one out.

 

I was able to take priidash out for a longer drive, and looked at the .csv files again. I was particularly interested in the data for inv1T inv2T mg1T mg2T. During my drive I saw the data on the temp gauges moving around from 40C to over 50C, pretty much looking correct and where I would expect them to be. So it looks like priidash is getting the right data on the screen.

When I look at the columns of the data in the .csv file, the values are quite different. Here is a representative piece out of the file:

inv1T inv2T mg1T mg2T
999.9 0 6713.3 40.47
999.9 0 6713.3 40.48
999.9 0 6713.3 40.49
999.9 0 6713.3 40.5
999.9 0 6713.3 40.51
999.9 0 6713.3 40.52
999.9 0 6713.3 40.53
999.9 0 6713.3 40.54
999.9 0 6713.3 40.55
999.9 0 6713.3 40.56
999.9 0 6713.3 40.57
999.9 0 6713.3 40.58
999.9 0 6713.3 40.59
999.9 0 6713.3 40.6
999.9 0 6713.3 40.61
999.9 0 6713.3 40.62
999.9 0 6713.3 40.63
999.9 0 6713.3 40.64
999.9 0 6713.3 40.65
999.9 0 6713.3 40.66
999.9 0 6713.3 40.67

The numbers for the first three columns are obviously not right. the mg2T data is about what I would expect. There is intermittancy in the data also. Sometimes inv1T starts showing reasonable numbers, sometimes inv2T will show numbers from ~.5 - 1.5.

What could be happening to get such discrepancies between the displayed data and the logged data? Note, this is also happening in the files which I attached above, but I can also attach new files as well.