Page 1 of 2

Datalogger I'm working on

PostPosted: Thu Jun 01, 2006 11:32 am
by LGT-3-6
Just in case anyone is interested, I have come a long way with my datalogger. I originally started this as a way to dig in to the ECU and just as a homework project to learn C#. The focus is on correctness and ease of implementation, I knew I defininately was not going to use c or c++, now that I think about it perhaps python would have been better.

However here is what I have implemented:
1. XML based definitions for all items, you can add and remove items at will.
2. Object oriented abstraction of all lower levels functions, protocol structure, etc.
2. Multithreaded model that moves each function into a prioritized thread with queing functionality. The focus is on communicating with the ECU as fast as the serial port will allow (and as accurately timed as possible), and offloading processing to lower priority threads. Data is que-able to the limits of system ram, so in effect all other processing is infinitely deferrable.
3. Virtual register implementation, information such as current gear, acceleration, torque, horsepower, etc are calculated. (This is waaay harder than one might think)
4. Virtual gauge display. I designed a GDI+ gauge control that looks almost indestinguishable from the 05 LGT gauges, full vector graphics, anti-aliased, etc, quite trick.

I still have a few things I want to do like cleaning up some of the classes, some things are kind of hacks since the proper way to do things isn't always clear. Also I need to implement high performance counters, currently it is only really accurate to 1 ms resolution. Ideally new functionality is just lines of code away because of abstraction. i.e. if I ever get my hands on a SSM :D Also interpolated gauges would be nice 60fps > 10-20fps, heh :)

I still haven't decided what I want to do with it :/ *shrug*

PostPosted: Thu Jun 01, 2006 12:22 pm
by galvitron
sounds very well designed! Is this for Scoobies specifically or are your classes abstracted enough for use with all vehicle (provided there is hardware support)?

PostPosted: Thu Jun 01, 2006 12:41 pm
by cboles
sounds sweet!

PostPosted: Thu Jun 08, 2006 3:10 am
by wetwilly
That looks great. When will we be able to test this out? :)

PostPosted: Thu Jun 08, 2006 6:02 am
by LGT-3-6
galvitron wrote:sounds very well designed! Is this for Scoobies specifically or are your classes abstracted enough for use with all vehicle (provided there is hardware support)?
I dont see why not. I made a lot of assumptions and have been fixing things as I learn more about how things are really done. Also I apparently seem to be datalogging faster that 4800bps seems to allow?? So I'm looking for an explanation as to what's happening.. I get about 20-22 samples/sec with one register but the efficiency seems to improve more than it should with more registers and I end up getting a value like 5600bps with lots and lots of regs.. :O

What I see is:
1. send query
2. recieve query back (Now is this an ACK or just reflection off the half-duplex interface?)
3. get answer

Add up bytes/time = wtf!? :shock:

PostPosted: Thu Jun 08, 2006 9:10 am
by galvitron
Are you using the Tactrix cable? It's hard for me to tell from here...

PostPosted: Thu Jun 08, 2006 10:25 am
by LGT-3-6
galvitron wrote:Are you using the Tactrix cable? It's hard for me to tell from here...
Nope. Does the tactrix cable do this?

PostPosted: Thu Jun 08, 2006 10:27 am
by galvitron
I guess my question is: What is your interface from the ECU to the PC?

PostPosted: Thu Jun 08, 2006 10:57 am
by LGT-3-6
Cobb

PostPosted: Thu Jun 08, 2006 10:59 am
by galvitron
Sorry, no experience with that...

I'm sure lots of people on this forum do, though.

PostPosted: Thu Jun 08, 2006 11:06 am
by cboles
what you are receiving back in (2) is due to the half duplex interface. i don't see how you could be doing better than 4800 baud at 4800 baud. you shouldn't see more than 480 bytes/sec on the average.

LGT-3-6 wrote:
What I see is:
1. send query
2. recieve query back (Now is this an ACK or just reflection off the half-duplex interface?)
3. get answer

Add up bytes/time = wtf!? :shock:

PostPosted: Thu Jun 08, 2006 12:43 pm
by LGT-3-6
cboles wrote:what you are receiving back in (2) is due to the half duplex interface. i don't see how you could be doing better than 4800 baud at 4800 baud. you shouldn't see more than 480 bytes/sec on the average.

Does the tractrix cable avoid this? Even if so I think I will try an employ some com-port trickery to get rid of this. I want the widest possible audience including the cobb cable. That should make datalogging even at 4800 _much_ faster.

PostPosted: Thu Jun 08, 2006 1:12 pm
by cboles
The Tactrix cable gets the echoes too - it is functionally the same. The echoes are verified in a layer of my communication stack so that I know it is transmitting correctly. Higher levels in the code don't see the echoes...

PostPosted: Fri Jun 09, 2006 7:41 am
by Jon [in CT]
You might also examine the communications routines from an existing Subaru data logger for guidance. The source for one such program which works with both the Cobb and Tactrix cables is at:
http://www.tari.co.za/cgi-bin/yabb2/YaB ... lorerabout

PostPosted: Fri Jun 09, 2006 9:21 am
by bluesubaru
This look great. What might be usefull is a max reading marker. A mark on the gauge that show what the max reading has been. You could add a variable so that it will only stay for a certain period of time; 5 secs, 5 min etc.