Separate names with a comma.
Discussion in 'PriiDash (TM)' started by 2009Prius, Jun 26, 2011.
Really sorry to hear that! Let me take a look at the log again tomorrow.
could you post the log covering that period as it may be interesting to see if there is any difference.
oops should have read back a bit further
Ok this is a total stab in the dark, because the fact that 2009Prius managed to properly pars your output.
but I do notice that the working version has an atz, where as in the non working version it seems not to have made it.
Yes I can extract all the data. See attached csv file. (ODO can not be extracted since it is calculated in real time during driving and not saved in the log.txt file but it should have been saved in the log.csv file.)
It would be helpful if you upload the log file during the time when it's not working. Sorry never mind - the first upload was when it wasn't working, right?
I probably should add some delay around the ATZ command but in this case it doesn't matter since all the initialization commands (after the ATZ) returned OK in both cases.
As you pointed out all the data are there in the log file. I start to wonder maybe the problem is FLTK not updating the screen - the "event driven" GUI sometimes doesn't do anything until a mouse movement or clicking.
Yes the latest log I posted is during it working. Any thoughts? Again, thanks so much for your help. I am going to be donating you at least 50 smackers for all this.
Sorry I am really at a loss now. It looks like your computer is definitely fast enough. I have run the Cygwin version successfully on a laptop with Intel Core i5 CPU (M450 @ 2.4 GHz) and 4GB memory. More recently I have been running it on a bare-bone netbook with Intel Atom CPU (1.66GHz) and only 1GB memory without any problems. In both cases my f: drive is a SDHC card. On the other hand I am having big trouble running the Windows version even though SteveDH and others are able to run it fine.
I also don't understand why the log.txt file seems to record all the data fine but the decoding or displaying part of the program sometimes works and sometimes doesn't.
When the program only worked partially, did it crash after some time?
Could your PC be too fast? Do you have an older laptop or netbook to try?
Update: I just got the Windows version working. If it passes the real test drive tomorrow I will upload ASAP.
I was thinking it may be the pc too fast. not entirely sure how that would effect it, but I did at one time have a slow debug version working where a fast release one wouldn't.
The only differences between these logs and mine are the extra line feeds.
however these exist... although further on, in both the working and non working log files, but maybe some extra control codes are getting in that are not being recorded and effecting the real time parsing.
ok grasping at straws here
May I suggest adding an extra wait before the atz, just so that is guaranteed to execute, also is it possible to add extra debug output around the parsing of rpm, such as how many characters its being presented with, maybe its getting < 22 somehow..
However, wasn't it displaying ok, hmm.. maybe some extra debug stuff around where it gets written to the csv.
anyway sorry I have load of work to catch up on so don't have time to help at the moment.
Hi Steve you have already helped tremendously so no need to say sorry - we are all too busy to spend too much time on our hobbies - completely understandable.
Calle: I may have experienced something similar. When I tested the Windows version for real this morning in the car I saw partial activation of the gauges and then everything froze. However in my case when I looked in the log there were communication errors logged in the file. Also in the Command ("DOS") Window there were a long string of error messages. Now when you found it not working how did you stop the program? Just closing the program windows? If you did that then some logging messages could have been lost. Next time when you find it not working could you first click on the Stop/Go button? That way all messages will be saved in the log file and we can examine whether there are error messages. Thanks!
Update: on my trip home it first gave an connection error in the very beginning but then when I tried again it all worked fine the entire almost one hour trip. I uploaded the files here:
I do have log files where the ticker is counting and nothing is working. I have attached here a screenshot of what it looks like when it is ALMOST fully working. To etrapolate, I find that one of four things happens when I run either version of the program:
1. Nothing happens except the ticker counts. (Have log files for this)
2. The program works, except the RPM gauge half works, no MPG, no fuel counters, PSD doesnt show engine RMP only MG1 and 2, and a few other gauges dont work.
3. The program works as I just described, and then randomly after about 15 minutes a few other gauges start to work, including MPG, but not correctly. (have log files for this condition and this is the screenshot attached. after screenshot was taken i hit stop then start but could not get it to repeat this condition.).
4. Every gauge works perfectly (this has only happened twice) for a few minutes then reverts to only partial gauges working or the program freezes and i have to restart everything.
95% of the time #2 is the condition.
I have attached a screen shot I took when condition #3 occurred yesterday. Notice how the RPM is stuck at 2560, even though the little triangle indicator works fine and the actual rpm is not 2560, and notice how the PSD rpm is stuck at 2560rpm as well as the MPG's are factoring in that RPM. The color of the RPM gauge is also stuck. and the Eff' gauges are not working right. I let this condition exist for about ten minutes, then Stop/Started to see if it would fix it self, but it didnt-it just went back to conditon 2. Its almost as if they kicked in and started working for a milisecond and then it froze.
That's a very nice screen shot and I am still completely baffled why some data didn't decode correctly and appeared to get stuck. I think your first upload of the log file was condition #2 and the 2nd file was condition #4, right? Could you dig up files (both txt and csv) from condition #1 and #3 and upload? Also files from condition #4 but including the time period after reverting to partial gauges would be good to have. I may have to build for you a special version with extra debugging code as SteveDH suggested. Really sorry this is causing you so much trouble. Again don't get distracted from safe driving!
Calle: Please try this: go to Control Panel -> System -> Advanced System Settings -> Advanced tab -> Performance: Settings button -> Adjust for best performance radio button -> Apply button -> OK button. (I am guessing FLTK does not work well with Aero.)
I am enjoying reading my data. But, I am not sure about some of the headers. Evap, cyn. In particular dhvBV...
I am trying to analyze my hv battery and am uploading my xls file. I expected to find hvBmax-hvBmin to be significant indicating that my hv batt is showing it's age (240kMiles). But the modules seem to be within .25volts of each other at all times in the stress test I conducted.
This test was based on Art's test Predictive battery failure analysis for the Prius Hybrid.
He stressed the hv battery by flooring the gas pedal with the brake pedal sufficient to hold the car in place. In my 2005 Prius this only resulted in an additional 2 amps of current draw and would not provide the stress Art called for. So, I drove backwards around a parking lot until my soc dropped from 62 to 39. It took 116 seconds. The average draw was 17.7 amps; the min was -9 and the max was 41. Due to the small size of the lot I had to brake (generate?) occasionally. However the rundown time was similar to his, around 2 minutes.
Analyzing the data for the Art's critical factor of module voltage variance indicated no significant degradation in the battery. Unless the data under dhvBV indicates otherwise. Is this the case?
Thanks for any help,
Interesting data! I will take a look.
It seems that Prius has become smarter so if the brake is applied then the HSD won't try hard to try to move the car.
Another way to stress test the battery is just to do a lot of pulse and glide on local roads (after entering S4 so the engine would turn off during glide). I found that there is always a spike in current at the transition when the engine gets turned on or off. Also do some hard braking to get high regen current.
Of course if you have EV button then running the car in EV mode would do too.
Update: I just took a look at the data and it does look like the HV battery is in a fine shape. On the other hand the currents weren't large so the stress wasn't high. Also the length of the data is short so statistics is not enough. Again just do a lot of pulse and glide and some hard braking and collect the data. It doesn't have to be all in the same trip - a collection of csv files is OK. Once you got them please zip and upload. Thanks!
Oh, dhvBV is just the percent difference between hvBmin and hvBmax.
Could you throw a couple of bones to help with Linux compilation? I see the info in the README, but that is not enough for nondeveloper me. I have compiled a lot of Linux software over the years, but it is usually the Configure->Make->Make Install routine. Do I need to also install FLTK Fluid?
Thanks, can't wait to try this out.
Hi I am an amateur myself and haven't been compiling under Linux since the computer that I installed Ubuntu died a long time ago. IIRC I was using all GUI tools, no command line. I think I installed FLTK and Boost libraries through the package manager or something like that under one of the Ubuntu menus. Then I installed and used NetBeans IDE to edit code and compile. In the IDE you need to tell it what libraries to include: fltk and boost::thread. That's about it. Let me know if you have further questions and good luck!
OK, thanks. That sounds like a bit of a software odyssey, so I'll just use the Windows version for now. Perhaps it will work in Wine. Otherwise I'll dust off the XP in the closet. I'll keep you posted if Wine works with the program.
It is not difficult to get the Cygwin X window/shell running and then you should be able to run the executable of course is much easier to run the Windows version if you have the XP dusted off.
Re-compling after making changes in the source code with the Netbeans IDE is straight forward once you have the libraries loaded.
I think getting the XP version going will be enough of a project for now. A rainy day will be needed to try any of the compiled methods. A linux executable would be a good thing. I'll date myself and say that my programming era during university days was on Fortran and punch cards. Recent decades have swept on by.
I tried running priidash_VC2010.exe on the XP laptop from the command prompt, and got the GUI and the settings dialog, but the program crashes after hitting the GO button, regardless of what I enter for the .txt and .csv file names. I assume that priidash will create the files if they do not exist. I made a folder "c:\ODBLog\" and directed the program there. I also tried using my thumb drive. In every case, the program always exits with the same message on the terminal:
!!! Error open file "f:\ODBLog\log20111218_xxxxxx.csv" !!!
!!! Error open file "f:\ODBLog\log20111218_xxxxxx.txt" !!!
where the xxxxxx is the time stamp.
I hacked the .exe to point to e: instead of f: using a hex editor, thinking that maybe it was hardwired to require an f: present (I don't have an f:\ ). That didn't change the behavior, except to change the f: to e: in the error msg above.
This is not plugged into the car yet, just the interface plugged into the USB at com5. (The interface does work with OBDWiz, which gives some generic engine info, but nothing hybrid oriented.) Don't know if that is important at this point in the program.
Open to suggestions....
I am not sure why it is difficult to change from drive F: to drive E:.
But you should be able to change the Drive E: to Drive F: using the Administrative Tools that has an Icon when you use the Control Panel. Also be careful when you do this as programs that previously ran using Drive E: may have problems running now that the drive has moved to Drive F:
Another way around this is to leave Drive E: connected and connect a another USB Drive which should come in as Logical Drive F: ,then make sure that it has a folder OBDLog containing ODO.txt