new $EE tuning thing!

[steveo]

i'd like to clarify that these things will probably happen; but are totally low priority right now just due to the amount of work needed to go back on the bad design decisions i've made in other places. so we're talking like this winter. my roadmap is more to package a parser re-write with an update that does SIR/ABS codes and talks to the corvette CCM, etc, and completely replaces scan9495.

[lionelhutz]

I can totally understand the way it progresses. First you throw together some code that does a bit and then expand from there. Eventually, it gets unwieldy so you go back and start improving. I used to load a database table into program variables using this godawful clunky routine that had to be updated every time I wanted to use some new data. I finally re-wrote the code to a generic routine that goes straight to the table every time I need data. ODBC calls are very fast so storing the data wasn't necessary, it was just the stupid way I first programmed it. I would like to help but starting with an unfamiliar language learning uncommented code makes it a difficult task.

On another note, could a future improvement add a way to force the "line pressure" and also monitor force current, commanded and actual, on the 4L60e? It'd be a great way to tune/confirm the force motor current tables.

[steveo]

On another note, could a future improvement add a way to force the "line pressure" and also monitor force current, commanded and actual, on the 4L60e? It'd be a great way to tune/confirm the force motor current tables.

yes. but i don't have an automatic trans at my disposal, so i'd need someone to confirm how all of that works. testing mode4 commands using the custom command interface is trivial, with the side benefit that they're auto-cleared if you just go back to the main page and move something around.

I used to load a database table into program variables using this godawful clunky routine that had to be updated every time I wanted to use some new data. I finally re-wrote the code to a generic routine that goes straight to the table every time I need data. ODBC calls are very fast so storing the data wasn't necessary, it was just the stupid way I first programmed it. I would like to help but starting with an unfamiliar language learning uncommented code makes it a difficult task.

as much as i love databases, with fairly small data sets like this, you'd spend as much time on the database api and implementation as you would making a script that spits out c++ (which is what i did, you think i typed all that crap?). generated hard-code is seriously efficient as compiler optimization can be all over it. a bit ugly for sure, though.

I can totally understand the way it progresses. First you throw together some code that does a bit and then expand from there.

i have to say, you actually screwed me over a bit by putting the parameter definition idea in my head... i had a brain storm this morning which is just too good to pass up, and will probably take a ridiculous amount of my free time.

kur4o you are going to love this. it's so overkill but so awesome.

eehack isn't going to have a definition file for the layout and configuration of the mode-1 aldl stream, ever.

no custom parameters as they relate directly to mode-1 output.

that sort of definition will be unnecessary

eehack's internal definition will instead be the layout of the ECM's ram, which im sure kur4o has pretty much nailed already.

ram layout, you say?

think about it...

we can dump any memory we want on demand with mode-2

im not suggesting getting all of our data that way.... just that the current state of the mode-1 routine's configuration can be determined with a simple series of mode-2 commands on connect, at the expense of a few seconds of extra connect time.

building the mapping between memory address and mode1 byte is trivial.

e-side mode 1, you say? if we have e-side mode-2 comms (easy to check), i'll enable a hidden tab identical to the t-side one.

this allows advanced users to change the definition of any of the mode1 datastreams and have eehack behave as normal

i will just do a simple data list for each ALDL mode, and allow a 'show all data' mode for the graphing tab

i'll use the current datalog format and api but expand it appropriately to be able to be message-selective.

it wont break my dashboard either. if a parameter doesn't exist in the current mode, it simply isn't displayed.

allowing completely arbitrary modes with zero user configuration has a great side effect of effortless interlacing of datastream elements, you can have a 'big' message with parameters that don't need high resolution, and a 'small' message that provides high resolution data like spark, rpm, whatever... you get all your data at the frequency you want.

each mode will simply have a checkbox to turn it on or off (and perhaps a frequency selector)

talk about scope creep

this is happening. might take me a bit, going from a poorly built single threaded state machine to multithreading is horrendous...but kur4o was right, since im rewriting a bunch of other crap anyway i'll just keep going

[lionelhutz]

LOL, glad I could help. I was really just suggesting an idea, not how to implement. I would agree that a database is overkill in most cases. I just use it because it centralized and it separates the data from the program.

One spring hits and I get my car out then I can test automatic transmission stuff. Possibly even help you write some info on how to tune too.

[steveo]

One spring hits and I get my car out then I can test automatic transmission stuff.

that'd be great, i have NO experience with auto trans tuning and i feel it's an area that people struggle with. i don't even know how to avoid stall walls or whatever.

[steveo]

i managed to hack it up and get it threaded. it makes a huge difference...

packet rates are 100% stable and fast even on my slow computer now

[steveo]

getting every feature working again after changing to a threaded model is proving very time consuming, but it's getting there. mode 4 and flash read/write works now, custom commands are next.

when your ui and your data acquisition are so reliant on each other, instead of just calling functions and grabbing what you need (due to a guaranteed order of operations), you need to queue, signal, and lock every damn request and piece of data.

actually requires two methods to work well. im using a signal queue for events from the aldl layer to the ui, and a switchboard from the ui to the aldl layer. the ui doesn't work well with polling switches, and the aldl layer doesn't work well with a message queue.

really wish i would have written it this way from the ground up

[steveo]

interesting discovery, FTDI devices really seem to like a low latency at low baud rates like the 8192 we play with. it gave me almost 2 extra mode1 packets per second from the tighter timing. not sure if it's due to how i have serial timing configured in eehack or what...

http://fbodytech.com/ftdi-serial-lat...readed-eehack/

[steveo]

all features now work properly in the threaded version, I'll release a beta tonight.

one nice thing is its not as bitchy about being disconnected to do most things. analysis, flash bin selection, graphing, log resetting is now all capable of running while connected, as opposed to the old version which required disabling many controls based on connection state. due to my data model for the datalog, you can save logs now even while logging and nothing will happen. This opens the door for log autosave, etc.

I reworked quite a bit of stuff while I was doing it too. im finding everything is very stable and processor usage is about the same, but sleep states are better so laptops will be able to log longer without dying.

[fbody_Brian]

Just trying to compile the latest source on linux, got some small errors compiling.

first,

g++ -o autospark.o autospark.cpp
In file included from safetypes.h:6:0,
                 from datalog.h:5,
                 from autospark.h:5,
                 from autospark.cpp:1:
config.h:29:0: warning: ignoring #pragma warning  [-Wunknown-pragmas]
 #pragma warning(disable: 4100)
 ^
In file included from datalog.h:5:0,
                 from autospark.h:5,
                 from autospark.cpp:1:
safetypes.h:21:3: error: ‘QMutex’ does not name a type
   QMutex m;
   ^
safetypes.h:32:3: error: ‘QMutex’ does not name a type
   QMutex m;
   ^
safetypes.h:43:3: error: ‘QMutex’ does not name a type
   QMutex m;
   ^
safetypes.h:55:3: error: ‘QMutex’ does not name a type
   QMutex m;
   ^
Makefile:7188: recipe for target 'autospark.o' failed
make: *** [autospark.o] Error 1

I added an include for qmutex.h in autospark.h and got past that error.
Now getting this:

linux-g++ -o flash_routine.o flash_routine.cpp
In file included from flash_routine.cpp:2:0:
config.h:29:0: warning: ignoring #pragma warning  [-Wunknown-pragmas]
 #pragma warning(disable: 4100)
 ^
flash_routine.cpp: In member function ‘void datastream::read_flash_procedure()’:
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:534:10: note:   from here
     goto FLASH_READ_CLEANUP;
          ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:529:10: note:   from here
     goto FLASH_READ_CLEANUP;
          ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:520:46: note:   from here
   if(control->flash_exit.get() == true) goto FLASH_READ_CLEANUP;
                                              ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:518:10: note:   from here
     goto FLASH_READ_CLEANUP;  // failure here means no chance of reset
          ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:514:46: note:   from here
   if(control->flash_exit.get() == true) goto FLASH_READ_CLEANUP;
                                              ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:512:10: note:   from here
     goto FLASH_READ_CLEANUP; // must reset since t-side already loaded
          ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:504:46: note:   from here
   if(control->flash_exit.get() == true) goto FLASH_READ_CLEANUP;
                                              ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:502:10: note:   from here
     goto FLASH_READ_CLEANUP;  // failure here means no chance of reset
          ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:591:3: error: jump to label ‘FLASH_READ_CLEANUP’ [-fpermissive]
   FLASH_READ_CLEANUP:
   ^
flash_routine.cpp:496:46: note:   from here
   if(control->flash_exit.get() == true) goto FLASH_READ_CLEANUP;
                                              ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:609:3: error: jump to label ‘FLASH_READ_CLEANUP_NO_RST’ [-fpermissive]
   FLASH_READ_CLEANUP_NO_RST:
   ^
flash_routine.cpp:494:10: note:   from here
     goto FLASH_READ_CLEANUP_NO_RST;
          ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
flash_routine.cpp:609:3: error: jump to label ‘FLASH_READ_CLEANUP_NO_RST’ [-fpermissive]
   FLASH_READ_CLEANUP_NO_RST:
   ^
flash_routine.cpp:486:12: note:   from here
       goto FLASH_READ_CLEANUP_NO_RST;
            ^
flash_routine.cpp:541:8: note:   crosses initialization of ‘bool ram_notify’
   bool ram_notify = false;
        ^
Makefile:9304: recipe for target 'flash_routine.o' failed
make: *** [flash_routine.o] Error 1

Can probably get it to compile with -fpermissive, but thought I'd let you know what I'm seeing. This is compiling with 5.6

[steveo]

thanks man that's very helpful. i'll initialize ram_notify way further up.

the qnotify one should actually be #include <QMutex> in safetypes.h

please do a checkout again tonight as github is behind on a few other things too..

[fbody_Brian]

Also when compiled I can't seem to get the analysis to do anything. I get no results. Don't know if this part is still in progress.

[steveo]

it should work; do another checkout.

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

[fbody_Brian]

it should work; do another checkout.

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

compiled with no errors and the analyzer is working again.

[steveo]

so......time axis....

one bug i've discovered is if you load log data, then try to log data from the ECM, new data sometimes wont record on top of it, or will be unpredictable.

it's a timestamp bug, a fairly obvious one, some new code didn't play nice with how i was doing timestamp incremental offsets for new record creation. i've solved that problem, but im wondering if i should fix something else while im at it.

eehack right now works by saying that 'the first record retrieved' is timestamp zero, with linear time afterwards relative to that event. timestamps are millisecond precision in 64 bits so they're good for many weeks of logging.

if you disconnect then reconnect or whatever, the timestamp is still relative to the first log. this has the advantage of being totally realistic, for example if a disconnect event happens for 5 minutes, your log will reflect it...

if you load a log and record it, that presents a problem. current versions of eehack provides an offset so the log's final timestamp adds onto your existing timestamp and everything stays linear, allowing you to stitch together records.

but this does allow potentially huge gaps between stuff and seems a bit odd. i think other tools avoid these problems as they're just operating in record number domain rather than time domain.

if i enforce a maximum timestamp gap during record creation, lets say i enforce 'no record can be more than 60 seconds apart', can anyone think of advantages or disadvantages for playback, graphing, analysis, etc?

what about instead of 60 seconds, how about 200 seconds? that makes the gaps obvious in a log but not ridiculous...

it would be trivial:

if(new_packet->timestamp > newest_timestamp() + MAX_TIMESTAMP_GAP) {
      qint64 reduction = new_packet->timestamp - newest_timestamp() + MAX_TIMESTAMP_GAP;
      timestamp_offset -= reduction;
      new_packet->timestamp -= reduction; // apply offset

the other possible option is to leave it fully linear but mark dropouts of more than 60 seconds on the graphs and compress them, but that's pretty bitchy to figure out....im not sure if my graphing tool will do it.