the new beta doesn't have many changes to the flash routine at all
Printable View
the new beta doesn't have many changes to the flash routine at all
Speaking of unused regions, how much available space is there left 'empty'? How much headroom did the engineers give themselves on the ROM space?
Great job between you and kur4o on the flash routine, I was blown away the first time I flashed a change. Might have to bust out an oscilloscope and figure out a way to rig it into the ALDL on the automatic car, I'm so desperate to figure out what's wrong with it LOL
there’s quite a bit of unused space definitely enough for some 3d tables but the problem i always had was most of it is on the wrong side.
wow there is definitely some kind of issue. did you notice that the warning indicators on the dashboard go crazy when your speed log is playing back?? i can't find the cause of it yet. there is a lot of ugly code in the datalog and also datalog definition parsers and handlers.
I noticed it but ignored it since this was the first time I had used the Speedlog function, so I just thought that using Speedlog altered how the Dash worked or something like that.
Best of luck. As always, if there's anything I can do to help, just lemme know and I'll get on it. Due to issues with my daily driver I've switched to daily-driving the '95, so I can log just about anytime.
the whole thing is a mess so there’s probably a single bug somewhere
the whole thing with eehack is it was designed to have different data sets for different patch versions. that way when a patch alters the datastream the program is aware of it and can conditionally load the different definitions in the datastream.
its supposed to be robust enough where logging an old patch with a new eehack will be seamless if something big came up
something is causing the “new patch version recieved” callback to not reach the modules or maybe the modules arent handling it properly
your log definitely has the patch version correct
its just odd since i haven’t changed anything related to that in the new beta
was it working with the last stable version??
I never tested it with the latest stable version. I'll test that for you on my commute tomorrow.
i've found two of the problems and the dashboard and extended log windows are now working as intended
the graph window actually does work as intended but it is multi-message aware and you need to actually select the obdii/speedlog data set to graph it. i know this is a bit inconvenient and people have asked before that the data seamlessly gets pushed into message 1's datastream but that's just how eehack is designed to work with the multiple messages, and the ability to define those things separately is invaluable for people that want to further hack the datastream (also allows people to stream the obd-ii data if they wanted to, and if the patch is not installed). if you add any 'custom parameters' selecting the correct datastream is also important.
the analyzer isn't fixed yet, not sure whats up with that, it's supposed to be like the dashboard and use data from either message automatically.
fixed the analyzer, it was some botched code...but that means it must have been broken in the last version too and nobody said anything. which leads me to another question, does anyone even use speed logging except this one guy?? i'm disapointed, it's one of my personal favorites
anyway thanks for finding those bugs. i have to work on the analyzer a bit now, the ui isn't really acting like it should with some recent changes. i'm starting to really hate ui design
I guess nobody noticed since the average guy didn`t know if it is normal behaviour or some form of limitation, including me.
One more problem is e-side playback logging doesn`t work, you get no definitions available instead of the data. Since it doesn`t work with engine running anyway I didn`t want to bother you.
I was planning to modify the speedlog message while tuning some startup issues, but never got into that. I want to remove some stuff from the message and add add some other and make it much shorter than it is, and shooting for 30-50 frames per second. I also wanted to ask you about it is realtively safe to do it and how the data is parsed into the dash window. Does it need to have in the datastream message all the dashboard fields populated and defined or I can skip some of them like idle, baro, blms.
Hi Steve,
I am new to the eehack program and apparently new to this computer. From what I see so far it looks like a master piece for LT1 owners, thank you! I have loaded the program on my computer but it will not run, the program does not recognize the USB port. The cable was recently purchased from OBD diagnosics for my application. I have a 1994 corvette so it is a unique cable with a USB port, not a seriel port connection. The program comes up but when I try to connect it gives me an error. The program does not recognize the serial port and gives none as an option in settings. I am retired and left the computer world years ago so please make it simple. What am I doing wrong?
Thank you,
Rich Harris
What kur4o said is correct. The most likely answer is that you do not have the correct driver for the cable. The cable is intended to use FTDI's VCP (Virtual COM Port) driver. If your system mistakenly installed a non-VCP driver (such as a D2XX driver), that means it's not exposing a COM Port to the system, which means $EEhack won't see it either. Please make sure you're using the latest VCP driver from FTDI, which can be found here: https://www.ftdichip.com/Drivers/VCP.htm
steveo,
I would've noticed the bug in 4.70 had either of my cars been patched, but as you recall the whole comms error thing on my '94 had me too spooked to use the flashing function in $EEhack. It was only once those problems started getting ironed out that I had enough confidence to try it on the '95, which led to finding the bug. I did go ahead and get a log for you on 4.70 regardless, and indeed, it works fine (except the analyzer, as you found out). I also noticed the message selection thing when testing graphing, but I guess I never spotted it in 4.8.2. That's my bad. I've attached the log just for completion's sake.
To be honest the only non-bug-related suggestions I could provide for features would be potentially rolling real-time analysis in, and having patches be individually selectable (for instance, if I want speedlog but not E-side comms). By real-time analysis I mean something like what tuning suites like Crome or Hondata have, where you can sit on a dyno with the laptop plugged in and work through your cells by changing throttle and load and watching the O2s. The Analyzer/Trimalyzer do this after the fact once data is collected, but I wonder if there's a way to have a realtime graphical representation so that you know when you have sufficient data collected to make cell adjustments?
Just thinking out loud. As I've said tons of times before, I love this program even as it is. :)
i could do realtime analysis but id rather you just hit the analyze button. it will work with the car running wont it? imo real tuning either happens at home sitting at a desk studying the data......or with an emulator
Sure. But for example, say you have hundreds of records for a few cells and then...less than 70 for others. Less than 10 for still others. You won’t find that out until you analyze the data, then have to go try again. Some sort of visual cue for when sufficient data has been gathered for particular cells would be helpful for doing that analysis at your desk later, at least from my perspective. Similar to the map tracing functionality in other programs, I suppose, but tailored to how the Analyzer/Trimalyzer handle data to provide VE/MAF changes. Though since wideband O2 is accepted as an input, there’s no technical reason why wideband map tracing couldn’t work too, as many other suites do.
I do think there are lots of folks with dynos who would disagree with the assertion that you need to sit at your desk or bust out an Ostrich to do “real” tuning, though. Especially since I don’t know a good way to plug my Ostrich into a ‘95 LT1 PCM. ;)