new $EE tuning thing!

[steveo]

i guess the definition was worth it, since with the new api, this configures the dashboard:

  dash_add_field(ui->display_lblm,"LBLM");
  dash_add_field(ui->display_rblm,"RBLM");
  dash_add_field(ui->display_rint,"RINT");
  dash_add_field(ui->display_lint,"LINT");
  dash_add_field(ui->display_lblm,"LBLM");
  dash_add_field(ui->display_rblm,"RBLM");
  dash_add_field(ui->display_rint,"RINT");
  dash_add_field(ui->display_lint,"LINT");
  dash_add_field(ui->display_lpw,"LBPW");
  dash_add_field(ui->display_rpw,"RBPW");
  dash_add_field(ui->display_lo2,"LO2");
  dash_add_field(ui->display_ro2,"RO2");
  dash_add_field(ui->display_blmcell,"BLMCELL");

this draws the entire dashboard:

dashboard->draw_all(p);

[steveo]

this is a big undertaking. eehack does a lot of little things with datastream messages and api changes like this are bad news. I'll get there eventually though

kur4o do you have eside mode 1 yet?

the definition file format allows for patch version splits in the definitions so we can easily add new variables to later versions without breaking stuff

[kur4o]

Here is my latest patch for eside aldl mode1. It is tested fully working. It has 0 to 6 messages and are repeated from 7 to d. Total 14 messages.
The lenght and structure of the messages is the same as tside mode1.
First apply patch, save bin than modify the message table and populate with ram addresses from eside.

On the other side I see great progres on the new interface. I hope you get it finished soon. It has enormous hacking potential. I suggest to make patches mandatory for proper use with the program [and drop support for stock bins], anybody who is affraid of it point to some of the older versions. That way more of the awesome stuff it offers won`t be hindered by providing support for stock and modified.
I think you can always compile some stock version at this stage and leave it as is.

[steveo]

Here is my latest patch for eside aldl mode1. It is tested fully working. It has 0 to 6 messages and are repeated from 7 to d. Total 14 messages.
The lenght and structure of the messages is the same as tside mode1.
First apply patch, save bin than modify the message table and populate with ram addresses from eside.

awesome, i'll try it! i think i'll just have one really good e-side message patched in, which can improve with each version.

I suggest to make patches mandatory for proper use with the program [and drop support for stock bins], anybody who is affraid of it point to some of the older versions. That way more of the awesome stuff it offers won`t be hindered by providing support for stock and modified.
I think you can always compile some stock version at this stage and leave it as is.

i probably won't do that, ensuring the program works with both patched and unpatched bins isn't that hard. i just enable all the advanced stuff once the patch version is retrieved. also keep in mind my definition format allows for different datastreams with different patch versions.

[steveo]

so I'm testing that patch so far so good

do you have any suggestions for what kind of data is on the eside that would be a good idea to add? I see some maf stuff but what else is there?

[kur4o]

I have made some list for testing long time ago but It needs updating.
Here is the latest version of dissasembly to look for something interesting.
I will make new list with more details and accurate descriptions.

The most interesting stuff will be maf freq and maf airflow calc from maf and ve,
Spark and retard breakdown with different components and some fuel and ve stuff.

[kur4o]

Here is some quick v1 compilation with the more interesting stuff.

[steveo]

awesome!

im almost there, just working on log playback. it's hard having variable rate aquisition for different packets and have playback work properly but it will display/graph/ analyze very well when I'm done.

The hard part with playback is if you start polling a message partway through the log. When you play it back, no problem. But if you jump back in the log, you can enter a dead space where theres no data for that message. so you could be displaying data from 5 minutes in the future. thats bad. so you have to jump back to the closest data event *in the past*, and if the past has no such event, you have to display a question mark or something to notate that theres no data.

there will be both variable rate polling and a "request once" button for messages that you just want a snapshot of.

[babywag]

Just wanted to say THANK YOU!

Bought an LT1 equipped Caprice wagon last week, and needed to see the why the check engine light was on.
Already had a homemade USB-ALDL cable, and your program worked awesome.
The cylinder balance test, and the datalog/capture allowed me to make sure the thing ran decent on the test drive before buying it.

Turns out the o2 sensor on the passenger side was simply unplugged, but without the program wouldn't have know where to look.
Also allowed me to haggle asking price with the owner.
He was impressed, his "buddy" @ a repair shop with a multi-thousand dollar scanner couldn't read the code, or even connect to the computer LOL.

[steveo]

glad you like it, and that the cylinder drop test worked for you. It's only recently that it's become effective. it uses the differential between map and rpm (map moves inverse to rpm when a strong cylinder is disabled)

[steveo]

I abstracted it a bit more and itll probably do abs/sir codes too. definitely getting close.

also will have a parameter selection module as drop down menus dont play nice with diverse parameters and filtered lists

thinking of allowing one custom analysis. it will be a chart of anything vs anything. you could select low high or average, and select from a few filters (cl only, wot only, rpm/map/tps threshold). I could do custom filters but it might be too much work.

[steveo]

alright it's about time i release something, so here's a new beta. multiple message support with external definition means it reads all available error codes and transmission data, better graphing which can graph those parameters, re-enabled blm cell memory retrieval, and tons of other stuff.

http://fbodytech.com/eehack-2/beta/

please please please help me test it. there were literally thousands of changes necessary to support multiple logs, and im sure i broke a few things. im not driving my car much right now so i've mostly bench tested this stuff.

edit: this completely breaks support for old logs....

[steveo]

to be included with future versions:

The defintion format is fairly simple...
...but is best loaded into your favorite spreadsheet or CSV editing software.
Just use a comma seperator and no quotations on text fields.

Lines starting with # are ignored completely.

The first type of definition record is the message header. It indicates when a new message is being defined.

Field 1: The NEW keyword
Field 2: the device address
Field 3: the message number
Field 4: a short text comment describing the contents of the message.
Example: NEW,0xF4,0x00,Main

The second type is the record itself:

Field 1: The byte offset (starting from 0 in the data section)
Field 2: The "short name" aka lookup name. This is a critical field as eehack will use it to
identify and search for common parameters with logical names such as RPM and MAP. Don't use
common names for your own parameters. It is generally hidden from the user.
Field 3: The "long name". The full description to be displayed with the data.
Field 4: The unit of measure string, such as Degrees. It can be blank.
Field 5: The view level, must be one of BASIC, EXTENDED, HACKER, ERROR, or VERROR. Parameters
other than BASIC are generally hidden from the user unless asked for. VERROR is for corvette
specific transitional OBD-II errors
Field 6: The size in bits. This must be 1, 8, or 16. 1 denotes a binary parameter.
Field 7: The output precision (for 8-16 bit values) or the bit field (for 1 bit values).
0 specifies an integer, 1 or more specifies a floating point value.
Field 8-9: The multiplier and adder comprising the linear equation that converts this data to
a human-readable value.
Field 10-11: The minimum and maximum patch versions that this data appears in.
Field 12: The 'special' field. Specifying CELCIUS, MPH, or KPA will allow metric/imperial
conversion on the field. Specifying SIGNED will use signed input. RESEARCH will display
the data both as hex and binary on output. Various other special fields may be added later.
Field 13-14: Low and high warning levels, if left blank, no warning threshold.

[fbody_Brian]

alright it's about time i release something, so here's a new beta. multiple message support with external definition means it reads all available error codes and transmission data, better graphing which can graph those parameters, re-enabled blm cell memory retrieval, and tons of other stuff.

http://fbodytech.com/eehack-2/beta/

please please please help me test it. there were literally thousands of changes necessary to support multiple logs, and im sure i broke a few things. im not driving my car much right now so i've mostly bench tested this stuff.

edit: this completely breaks support for old logs....

I log my commute every day and flash quite often, so I'll be doing some testing with it. Is it on github?

I'll keep an older version for the time being to work with the logs I currently have, and that's no issue at all.

[steveo]

yeah github is up to date.

probably on linux since you aren't using my installer, it'll ask for the definition the first time. it's in the source tree.

i'll be doing a FAQ on it before i release it officially, but the main 'dashboard' is now just a secondary display for message zero, and each message has its own tab. you can either use the 'stream' button so it constantly grabs data, or the 'snapshot' button to grab a single (ideal for messages mostly containing errors or diagnostic info). obviously streaming more messages decreases resolution.

the 'speed logging' patch isn't working yet

i'd love it if you'd take a log or two and send them to me with various different messages enabled, since i don't have:

- any real driving logs with it yet
- any automatic transmission data to test with
- enough testing of the new log format
- real testing of the analyzer

just beware im only 99% sure i wont change the log format again during this beta.