Page 67 of 72 FirstFirst ... 17576263646566676869707172 LastLast
Results 991 to 1,005 of 1070

Thread: new $EE tuning thing!

  1. #991
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Sorry didn't get these done sooner, hope I didn't hold up your work.

    Found some info on the issue I was seeing with QtPrintSupport missing, so added a second qt version check in qcustomplot.h - appears to be a bug in the toolchain.

    Code:
    #if QT_VERSION < QT_VERSION_CHECK(5, 0, 0) || QT_VERSION > QT_VERSION_CHECK(5, 7, 0)
    #  include <qnumeric.h>                    // workaround for bug in qt 5.8 and newer
    #  include <QPrinter>                      // https://bugreports.qt.io/browse/QTBUG-56321
    Attached Files Attached Files

  2. #992
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    qt is the most bloated library package ever conceived, it literally does everything. i'm not surprised that the printer library links to something else crazy. i swear i added version checking support to eehack when it kept relying on the network library and it was easier to just use the stupid library for something than diagnose it.

  3. #993
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Quote Originally Posted by kur4o View Post
    I`ve been thinking about a secret check byte for each addon so ui can be updated accordingly.
    The main patch will be v4 and the addon add a sub patch version with different check byte. That way it will be backwards compatible and there won`t be any non functional options.
    The addon patches will be strictly mode4 control enhancements.

    I have done already Individual cylinder corrections, delta VE change and end of injection control.
    Also MAF/SD switching from mode 4.

    I am still having trouble with the check box linking with the bin_file.cpp.
    in flash_launcher.cpp you'll see i actually use variables in the datastream control structure to control flashing behavior. the checkbox toggles a switch in datastream_control.

    then in flash_routine.cpp it calls bin.apply_patches() if the switch is true, such as: control->enable_patches.get() == true (see about line 117)

    you could add some more stuff to datastream.h under datastream_control, perhaps a safe_switch custom_patch_a and apply it like that, having the flash routine call more functions from bin_file

  4. #994
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i should clarify that the datastream_control structure is an intermediary control interface between the UI and the datastream, which actually operates in a separate thread. this is definitely a bizarre way to do it.

    the design of eehack is such that very few callbacks or signals are made from the ui to the datastream thread

  5. #995
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by steveo View Post
    qt is the most bloated library package ever conceived,
    Your comment leads me to believe you've evidently never worked with anything in the .NET realm.

    I can forgive a great many shortcomings when I can download a linux distro for the cost of bandwidth, install it onto a 10 year old piece of hardware from a flash drive and in a couple hours be compiling software as fantastic as eehack for zero spend and zero seconds of my life wasted on license / DRM subversion.

    Quote Originally Posted by steveo View Post
    i swear i added version checking support to eehack when it kept relying on the network library and it was easier to just use the stupid library for something than diagnose it.
    That (the update checking routine) sounds like something that (sh/c)ould be removed - lest it matches some ridiculous winblows antivirus heuristic.

  6. #996

  7. #997
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    When I add a test code to see if it works in bin_file.cpp

    Code:
    void bin_file::patch_addon_check(){
         if(control->flash_tside.get() == true) {
        return;
        } else {
            return;
        }
    
    }
    I got an error "control not declared in this scope"

  8. #998
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    bin_file just deals with the bin itself and doesn't use the datastream control structure. it should know how to apply a patch, but has no knowledge of when it should be applied. this is object orientation, it's kind of brain damaged, and the way i did it isn't realy optimal.

    in datastream.h, datastream_control class, in the public: section, add
    Code:
    public safe_switch enable_kur4o_patch_a
    in flash_launcher, your check box should (see other examples in that file)
    Code:
    control->enable_kur4o_patch_a.set(toggled);
    in bin_file.cpp, add a public function called patch_kur4o_a(), this will apply the patch (see patch_eside_comms() function for an example)

    in flash_routine, find the //patch stuff around line 117 and add something like:

    Code:
    if(control->enable_kur4o_patch_a.get() == true) {
      bin.patch_kur4o_a();
    }

  9. #999
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    That`s what I was affraid of. It would be a lot nicer to manipulate the patch inside bin_file.cpp with swiches.
    In that case it is like applying two patches during flash. I hope they don`t get in conflict. I will give it a try and if it gets too compilated will do one big patch option. I can do it very easy, user configurable by switches in the bin, but they need to be set in tunerpro before flash, so it will be too awkard to use.

    BTW do you have some hidden write to file option for debugging left on the source. It will be nice to test patch functionality before actual burning to PCM.

  10. #1000
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    there are lots of ways to pass information between disconnected classes. if you want to create a structure or class as a container of your patch configuration, it's easily passed from the interface to the control structure to the patch routine in bin_file.

    in flash_launcher, you have access to the bin_file to be written via the pointer to the control structure as control->write_bin

    so if you put a public bool patch_switch_a; in bin_file.h, you could control->write_bin.patch_switch_a = true; from a button in flash_launcher.cpp

    then in apply_patches() in bin_file:

    if(patch_switch_a == true) {
    // do stuff
    }

    you'd have to be careful to reinitialize them every time flash launcher is called or whatever too.

    usually someone writing in c++ would also insist those are private: and have functions to set them so you have a stable api with more control over them for error checking and whatever.

    here's another way which creates an isolated patch configuration class... create a new class called patch_config.

    Code:
    class patch_config {
    public:
      patch_config() {
        patch_a = false;
        patch_b = false;
      }
      bool patch_a;
      bool patch_b;
    }
    this class could contain anything you want, integers, functions, whatever.

    then maybe initialize an instance of that in datastream_control, which is practically a singleton in eehack (but doesn't have to be)

    Code:
    class datastream_control : public QObject {
    ...
    private:
       ...
      patch_config pc;
      ...
    then in flash_launcher, you can

    Code:
    control->patch_a = true
    then modify apply_patches() so it will take a pointer to your patch_config:

    Code:
    bool bin_file::apply_patches(patch_config *pc) {
      if(pc->patch_a == true) then {
        // apply patch a
      }
    }
    and in flash_routine, simply call apply_patches with a pointer...

    Code:
    apply_patches(control->pc);
    this gives bin_file direct access to the patch configuration info without breaking class isolation, you are not directly screwing around with the bin file from the flash_launcher (something i tried to avoid)

    seriously, object orientation is so awesome it makes me want to gouge my god damn eyes out with a dull screwdriver.

    BTW do you have some hidden write to file option for debugging left on the source. It will be nice to test patch functionality before actual burning to PCM.
    yeah, bin_file itself can read/write files by path, just call that function {
    ...
    // file ops
    bool load_file(QString path);
    bool save_file(QString path);

  11. #1001
    Carb and Points!
    Join Date
    Aug 2016
    Posts
    1
    Quote Originally Posted by steveo View Post
    yet another new beta

    http://fbodytech.com/download/223/

    planning to release soon, will hold off on dual channel wideband etc. until the next release.

    one thing that needs more testing is that autospark can crash when you're connected and you enable/disable it. i think this version fixes it, but i'd like to be sure.
    Did the option for dual channel wideband ever come to fruition? I have 4.7 and 4.8 but neither of them have the option for dual mode.
    If it hasn't been implemented would there be any problem created by using the d27 option in WB settings and then also logging A/C pressure voltage with a WB connected to it.
    I know I won't receive any usable data for WB on the A/C input in EEHack. I plan to convert the numbers using a formula in excel and import into Trimalyzer after the log is complete.

    While I am asking about options any chance of implementing an alarm action for values shown in the dash.
    I would find it useful to have the data cell background change colors when the value goes above or below a set value similar to the behavior of PE, Closed Loop, etc.

  12. #1002
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Quote Originally Posted by REvolution View Post
    Did the option for dual channel wideband ever come to fruition? I have 4.7 and 4.8 but neither of them have the option for dual mode.
    If it hasn't been implemented would there be any problem created by using the d27 option in WB settings and then also logging A/C pressure voltage with a WB connected to it.
    I know I won't receive any usable data for WB on the A/C input in EEHack. I plan to convert the numbers using a formula in excel and import into Trimalyzer after the log is complete.

    While I am asking about options any chance of implementing an alarm action for values shown in the dash.
    I would find it useful to have the data cell background change colors when the value goes above or below a set value similar to the behavior of PE, Closed Loop, etc.
    actually dual wideband support works fine....kinda. i used a dual wideband with eehack myself.

    add a 'user parameter' to the main datalog view, or in the graphing window, search for WIDEBAND. you will see WIDEBAND_AC and WIDEBAND_D27 are there, and both should respect your wideband settings.

    ...but what i mean by 'kinda' is only one (the one selected in settings) works with the analyzer in eehack, i never got that far.

    While I am asking about options any chance of implementing an alarm action for values shown in the dash.
    I would find it useful to have the data cell background change colors when the value goes above or below a set value similar to the behavior of PE, Closed Loop, etc.
    it does that too.....kinda. eehack uses an editable definition file called ee_definition.csv in the program folder. make a copy before you screw around with it. there's a column for WARN_LOW and WARN_HIGH.

    what i mean by kinda, is that these definitely do work in the proper parameter lists but unfortunately i never finished adding support to the dashboard. in other words you need to go to *main to see it.

    i would consider fixing that flaw if i have time

  13. #1003
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by kur4o View Post
    Since I haven`t time to test it yet, the patches were not implemented in eehack yet.
    You have to apply patch manualy, from the xdf I provided.

    Insert only patches with the following names from SD_AIRFLOW_PATCH folder:
    v2_[Tside....
    delta ve +....
    end of inject.....
    Cyltrim realtime.....

    Ignore any indeterminate data does not match error by first pressing remove patch , than apply patch.
    I'm getting the indeterminate data error after removing and applying most of these - is that normal? Unless you've made progress on patching through eehack, could you take a look at these bins? These should match except the one ending in -2 should have these patches.
    Attached Files Attached Files

  14. #1004
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    The indeterminate data is because of some base data 00 vs FF. I used a bin that have FFs on the eside empty space and that patch in the xdf is set with FFs on the base data.

    Tunerpro really don`t work well with patches. If there is indeterminate data, first you have to remove the patch, press apply, save bin. Only than you are allowed to apply the patch.

    The bin uploded is patched, if you remove the patch and save the bin you will see some FFs on eside empty space if you compare the bins.
    Attached Files Attached Files

  15. #1005
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Thanks - I haven't compared to what I did yet but I probably skipped the step of saving the bin before trying to apply the patches.

    I really need to rip the wound back open and delve into some of the machine code. I'd really like to have a better understanding of what you did here b/c there are a half dozen similar hacks I can think of that might take some of the guesswork out of tuning for headers in closed loop.

Similar Threads

  1. 1badcell and thats not the only thing
    By 1badcell in forum Introductions
    Replies: 2
    Last Post: 12-31-2013, 02:25 AM
  2. Replies: 6
    Last Post: 11-27-2012, 09:03 PM
  3. Replies: 2
    Last Post: 11-07-2012, 05:26 PM
  4. Minor thing.
    By historystamp in forum GearHead EFI Forum Support
    Replies: 7
    Last Post: 01-22-2012, 12:00 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •