No, there's only one version. arch.py selects settings based upon what kind of system your running. It already does things like select an appropriate temp directory, gnuplot program, and wxwindows version. So I just added selection of a time function. When everything works correctly, it will be seemless and everyone can download the same file.

d

 

Thats what I had figured. Keep us updated when you release the new version.

 

Consider youself updated. I just posted 0.8.

On a side note, I built a high speed logging function as per the specifications chiptorque sent me. There's some code in the 0.8 tarball, but it doesn't work yet. Either the specification has one-off error or my code does (I'm guessing the latter).

d

 

Ok gang. I've got a new version, 0.9

http://www.donour.com/cars/pyxede

Most notable (and exciting) is the new high speed data logging. It should provide a 3 fold increase in samplerate when logging more than one sensor value. It is, however, less accurate than the old data logging method (which is still available), but for most users it should be fine. I believe it's the same accuracy as xmap3's data logging facility.

I urge people to download this version and test, test, test. There are a handful of bugs remaining (that I know about), but they are minor and you probably won't even notice them. So grab the tarball and start breaking things...oh and tell me about them.

d

 

I did some more runs today (w/ the .9). The program didn't lock up so that was a good sign. I did have this error and I still can't get it to plot (top error).



Here is my datalog. I just ran it through 2 gears. Probably not that useful, but it gave me some errors (as seen in the error pic).

 

Now, for better news. I got the road dyno software to work, but I couldn't graph it w/ gnuplot. This is a 3rd gear pull from 3500rpm to 7500rpm.

 

As you can probably guess the program can't find the gnuplot executable. Did you download the gnuplot package and place it at the same directory level as the main pyxede folder (in this case C\docs+settings\jeremy)?

I haven't seen this one before. I'll try and track it down.

I wouldn't be too trustfull of this data because of the earlier errors.

d

 

Both file folders are on the desktop.

 

Hm...it still looks a little screwy to me. That run only has 3 seconds of samples. Interpolated, it looks like the attachment. Obviously it needs to be improved.


d

 

I'll be testing the new version later today

 

One thing that has become apparant with this software is that it does not like slow machines. It gets pretty finicky on my mac (which is ungodly slow) when I'm I have other things running at high priority. Most of this I chalk up to the python threading system and the wxWindows GUI toolkit. I have zero problems data logging for a long period of time from a terminal. However, the GUI does get a little unstable if left running while doing other things.

EDIT: Doh! I found a hugh, glaring, monstrous thread bug that is probably causing most of the performance problems as well confusing the event handler. I'm calling the graphics library yield() function from a bunch of different threads. That's a big no-no and makes applications blow up.


d

 

This program has worked on my 1.5ghz 256mb of Ram dell laptop. I have no problems on my 3.4ghz 1gig of Ram Alienware laptop. Locking up issues anyways, but then there are always other bugs.

 

1200HP & 900 ft-lbs are respectable for a 13 sec car right ?

BTW, I am running a GT3076 so it goes through 3rd pretty quick, but not 3 seconds quick. Probably more like 4 seconds.

 

As per earlier mesgs, those numbers are completely uncalibrated. The key should even say "power", not horsepower. So divide by 1000 and you should be closer to real numbers.

d

 

Yeah, I know the numbers mean nothing as of now, I was just trying to be funny .

Shouldn't it be divide by 100?