new $EE tuning thing!

[steveo]

When flashing with the newest beta. Whenever I flash I can never get rid of the flash subroutine window. Doesn't matter if it succeeds or fails It doesn't exit. It leaves fullscreen, but I can't move it or exit it. Otherwise looking pretty good, so far just that and the inability to analyze wideband cruising are the only issues I've had.

if that's all that's broken, i'm shocked!

there's now a huge signalling mess that deals with almost every inter-module function and i'd broken the signal between the flash window and main window that tells it to close, and the signal from the settings dialog to the analyzer that tells it that the wideband config has been updated.

both of those were temporary derps that are fixed now. will upload the changes soon.

edit: i committed them to git anyway, among other small fixes.

[steveo]

this is the heart of the "acquisition thread" (actually just the thread that talks to the ECM),

between the thread and the user interfaces, a qt signalling system...

  connect(acqthread,SIGNAL(new_packet_ready(packet*)),mode4controller,SLOT(recieve_new_packet(packet*)));
  connect(acqthread,SIGNAL(display_critical_error(QString)),this,SLOT(recieve_critical_error_msg(QString)));
  connect(acqthread,SIGNAL(new_packet_ready(packet*)),datalog_win,SLOT(recieve_new_packet(packet*)));
  connect(acqthread,SIGNAL(update_pktrate(float)),datalog_win,SLOT(recieve_new_pktrate(float)));
  connect(acqthread,SIGNAL(connection_state_changed(int)),datalog_win,SLOT(recieve_connection_state(int)));
  connect(acqthread,SIGNAL(updated_ecm_info()),datalog_win,SLOT(recieve_new_ecm_info()));
  connect(acqthread,SIGNAL(connection_state_changed(int)),this,SLOT(recieve_connection_state(int)));
  connect(acqthread,SIGNAL(error_occurred()),this,SLOT(add_fail_count()));
  connect(acqthread,SIGNAL(invalid_serial_port()),this,SLOT(recieve_invalid_serial_port()));
 connect(acqthread,SIGNAL(new_cylbalance_result(int,int,float)),test_window,SLOT(display_cylbalance_result(int,int,float)));
 connect(acqthread,SIGNAL(new_cylbalance_progress(QString,int)),test_window,SLOT(display_cylbalance_progress(QString,int)));
  connect(acqthread,SIGNAL(flash_write_successful()),flash_launcher_win,SLOT(remember_previous_bin_write()));
  connect(acqthread,SIGNAL(flash_read_successful()),flash_launcher_win,SLOT(save_read_bin()));
  connect(acqthread,SIGNAL(end_flashprogress()),this,SLOT(hide_flash_progress()));
  connect(acqthread,SIGNAL(start_flashprogress()),this,SLOT(show_flash_progress()));
  connect(acqthread,SIGNAL(update_tside_progress(int)),flash_progress_win,SLOT(recieve_tside_progress(int)));
  connect(acqthread,SIGNAL(update_eside_progress(int)),flash_progress_win,SLOT(recieve_eside_progress(int)));
  connect(acqthread,SIGNAL(new_flash_message(QString)),flash_progress_win,SLOT(recieve_message(QString)));
  connect(acqthread,SIGNAL(new_flash_divider(QString)),flash_progress_win,SLOT(recieve_divider(QString)));
  connect(acqthread,SIGNAL(new_flash_error(QString)),flash_progress_win,SLOT(recieve_error_message(QString)));
  connect(acqthread,SIGNAL(flash_error_occurred()),flash_progress_win,SLOT(error_occurred()));
  connect(acqthread,SIGNAL(enable_flash_exit(bool)),flash_progress_win,SLOT(recieve_cancel_enable(bool)));
  connect(acqthread,SIGNAL(update_flash_speed(float)),flash_progress_win,SLOT(recieve_flash_speed(float)));
  connect(acqthread,SIGNAL(custom_log_append(QString)),raw_command_window,SLOT(new_custom_log_entry(QString)));
  connect(acqthread,SIGNAL(connection_state_changed(int)),raw_command_window,SLOT(recieve_connection_state(int)));
  connect(acqthread,SIGNAL(acq_event_display(QString)),this,SLOT(display_acqstatus(QString)));
  connect(acqthread,SIGNAL(reset_error_count()),this,SLOT(reset_error_count()));

and between interfaces and the acqthread, a self-locking array of switches, integers, and other parameters...

class datastream_control : public QObject {
  Q_OBJECT
public:
  datastream_control();
  safe_switch connection;
  safe_switch quit;
  //-------------
  bool is_connected(); // is completely connected?
  bool is_disconnected(); // is completely disconnected?
  safe_int connection_state;
  //-----------------
  ecm_info_header info;
  //-------------
  safe_string port_name; // serial port string
  //-------------
  safe_switch mode1msg[8];
  safe_switch mode1speedhack;
  //-------------
  safe_switch cyldroptest;
  safe_switch blmcell_dump;
  safe_switch clear_dtc;
  safe_switch ecminfo;
  //-------------
  safe_switch set_vin;
  safe_switch set_calid;
  //-------------
  safe_int throttle_ms;
  //-------------
  safe_raw_command custom_a;
  safe_raw_command custom_b;
  //-----------------
  // Mode4 commands
  safe_switch mode4send;
  void m4_comm_init();                  // zero entire mode4 string (disable all hacks)
  void m4_comm_afr(byte afr);           // command an AFR
  void m4_drop_cyl(int cyl);            // drop a cyl or 0 = dont drop
  void m4_comm_idle(int rpm, int mode); // command an idle, mode 1=rpm 2=steps
  void m4_comm_spark(int advance, int absolute);  // command a spark, absolute =
  int m4_get_spark();
  void m4_force_blm(bool set, bool enable);
  void m4_force_cl(bool set, bool enable);
  void m4_reset_blm(bool set);
  void m4_clear_blm_reset();  // this doesn't do an m4 update request for event loop use
  void m4_force_gear(int gear);         // commanded gear or 0=disable
  void m4_fan(int n, bool set, bool enable);         // mode::0=auto,1=on,2=off n::1=fan1 2=fan2
  void m4_ccp(bool set, bool enable);
  void m4_air(bool set, bool enable);
  void m4_ac(bool set, bool enable);
  void m4_tcc(bool set, bool enable);
  void m4_actuator(int enable_byte, int enable_bit, int actuator_byte, int actuator_bit, bool set, bool enable);
  QString m4_getpkt();
  void m4_get_raw(byte *buf);
  void m4_set_raw(byte *buf);
  //-----------------
  void reset();
  safe_switch start_flash_write;
  safe_switch start_flash_read;
  safe_switch flash_exit;
  safe_switch flash_tside;
  safe_switch flash_eside;
  safe_switch skip_unused_regions;
  safe_switch enable_patches;
  safe_switch dump_ram;
  //-----------------
  bin_file write_bin;
  bin_file prev_bin;
  bin_file read_bin;

private:
  //-----------------
  byte cylnum_to_m4ref(int cyl);
  byte m4_process_afr(int afr);
  //-----------------
  QMutex m4_lock;
  byte construct_mode4[16]; // mode4 buffer
};

[jthompson122183]

try this.......... i inserted a crapload of debug strings and it opens the debug window on load. hopefully it finds something.

copied over and now i get this error

Attachment 10237

its asking for these files qt5cored.dll , qt5widgetsd.dll , qt5guid.dll , qt5serialportd.dll then abruptly exits

[steveo]

oops my bad. that was a debugging symbol build.. try this one.

[jthompson122183]

oops my bad. that was a debugging symbol build.. try this one.

its working now
weird thing though the debug window showed no errors just whats in the screenshot.

Thanks for fixing this for me!

Attachment 10239

[steveo]

.. i didn't fix anything, that i know of..

can you post a copy of the whole debug log?

[jthompson122183]

eehack didnt ask to save the log when i exited. another weird one, i just uninstalled eehack and reinstalled 4.4b2 just for the heck of it and it works now! i think something wonky going on with windows, cant win for losing with windows. Hopefully i didnt burn up to much of your time on a wild goose chase. i dont know whats up with my machine, its damn near bare bones.

[steveo]

eehack doesn't save debug logs, it has a 'copy to clipboard' button instead

i think the line of code in question is the loop delay when it's idling waiting for the ui to request a connection.

i used the mysterious 'serial speed' slider on the settings dialog to set the loop delay as a base for the length of the delay

each loop iteration also updates the status to 'idle' which requires a queued signal

i think somehow yours got set to zero (meaning a 0*3=0 delay), even though that should be impossible, which caused millions of loops per second rather than tens of loops per second, and overran the signal queue, hence our memory leak and eventual crash.

the reason the 'fix' worked is i introduced an extra delay for our 'testing' version just so the debug log would be readable

im just going to use a fixed delay there instead, in fact i might get rid of that serial speed slider, i think it's obselete now anyway.

[steveo]

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

things still broken that i need to fix before i release a stable version, but can't be bothered:

blm cell memory dump does the query but doesn't display
opening log files via windows or via command line doesn't work (when i fix it, it'll be capable of opening multiple log files in one shot..)
raw commands when disconnected work, but have additional delay time added to them

anything else to add to the list?

any opinions on whether the new user interface design is useable for the time being?

[fbody_Brian]

Still having issues with timestamps. I logged a 60 minute drive, and then saved it, as soon as it finished saving the corrupt timestamp message came up. I opened it with an older version of $EEhack, prior to the timestamp check to analyze it. Works fine there. Don't know what's going on with that. I did turn the car off several times, but never stopped logging.

Log file attached.

[steveo]

weird, i'll look into it?

timestamps are done much differently now, the new record is stamped relative to the last record (before it was relative to the first record)

it should also enforce a minimum and maximum timestamp difference since the last record.

that logic was supposed to fix these issues, especially in the event of a disconnect..

the corrupt timestamp means its just not sequential so something broke

[fbody_Brian]

It appears that PE AFR analysis is rounding to the nearest whole number in the display.

[steveo]

i'll check that out.

one interesting thing for me to consider is you're the only one running a 64 bit build of this thing, it might be an issue with the size of the timestamp variable that i didn't anticipate. i'll look at that tonight.

[steveo]

fixed PE AFR and a few other analyzer oversights. i just noticed that the idle afr wasn't cleared properly on refresh, so subsequent analysis threw off the idle AFR. PE afr now uses the wideband if it exists at all, not just if it's selected in the other AFR tab, which was my intention in the first place. logically if there's a wideband, you should get wideband PE results even if you're analyzing closed loop, narrowband PE voltage is only a fallback if there's no other data to display.

timestamps?

wellll.. i fixed some type issues...

but turns out eehack's beer fund button can be counterintuitive to good development.

i think i was plastered drunk when i wrote the timestamp restriction code.

so when you stopped your car, the timestamp raised past the maximum threshold.. but my botched code ended up lowering the timestamp instead of just raising it to the limit. i tried to do something dumb with offsets instead of just hitting the limit..

i'll commit the changes in a sec after i test them a bit more

edit: new beta is out on github and fbodytech, try 'er out

[fbody_Brian]

cool, all the fixes appear to have worked for me, but somehow display percentages isn't working now under wideband.
Also, could you possibly have it remember the narrowband/wideband selection on cruise analysis? every time I restart the program I have to reselect it.
experiencing some strangeness when using control to try to dial in my idle, messing around with idle speed, timing, afr. sometimes the car starts "doing it's own thing" and I have to disconnect $EEhack to get it to settle back down. I'll do some more testing in this area.