EEHack 2019 update

[kur4o]

they're set to read lambda at 0.454v

I completely agree with this statement. Maybe we are using different terminology for the same thing.

Was the signal stable over the serial output or was the modulation only present on the analog output?

i didn`t compare it with the gauge serial datastream. I guess there will be no variation on the serial output. It Affects only the 0-5 output.

Which reminds for a past eehack addition request.

Steveo, can you add a wideband stream through a second serial port. Most of the wideband gauges have a serial output. That way we eliminate all the havock related with setting accurate reading through a 0-5v input.

Quick question while I'm thinking about it - is it safe to use steveo's version with the v4 patches?

The v4 patch is backwards compatible with all previous version of eehack. The stock mode4 message structure is intact. I added new stuff to some unused bits and extended the message on request. So is it pretty safe to use and all controls will work as expected.

[spfautsch]

Maybe we are using different terminology for the same thing.

No, you're just assuming I'm burning iso-octane when in fact it's a blend of ethanol, gasoline, and other stuff.

Steveo, can you add a wideband stream through a second serial port. Most of the wideband gauges have a serial output.

This is where I was heading. The problem is that we would have to reverse engineer the serial datastream for each vendor.

The v4 patch is backwards compatible with all previous version of eehack. The stock mode4 message structure is intact. I added new stuff to some unused bits and extended the message on request. So is it pretty safe to use and all controls will work as expected.

Thank you - I thought this was the case but didn't want to find out I was wrong at 75mph.

[steveo]

i can't imagine i'll have the time to implement and test supporting another serial port wideband input, the way eehack is written that'd be an entirely different datastream, it wasn't written with this kind of stuff in mind so it'd either be really hacky or a lot of work.

i know there's lots of stuff it'd be nice to have guys but i'm still focusing on bug fixes, i have other stuff to work on too

[spfautsch]

i can't imagine i'll have the time to implement and test supporting another serial port wideband input

Sorry, I wasn't implying you should do the work.

the way eehack is written that'd be an entirely different datastream, it wasn't written with this kind of stuff in mind so it'd either be really hacky or a lot of work.

I'm pretty good at "hacky". ;-)

I may attempt this for the Innovate controllers once you're finished with the bugfix release (as a fork). Offhand, how much work do you think it would entail to define an input that derives it's data from something other than the ALDL data? I'm guessing a bunch... This will probably be a good project for next winter, if at all.

Edit: hmmm, splicing another datastream into the .eedata would be really useful with my ignition controller.

In the mean time I'll have to play around with narrowing the output range of the LC2 and see how much it improves the nonlinearity.

i have other stuff to work on too

What nerve? You mean you have a life outside of writing software for us freeloading bums? ;-)

[steveo]

if you do want to do it

eehack's log format is obviously designed to differentiate between data packets based on a pair of 8 bit values, the device and the message number

so one approach is perhaps use a false device like 0xFF that'd never be used, but then make an exception in the datalogger so when device $FF is requested the request never happens, and another function is used to fill that array with data from your separate port. at least this approach would allow use of the already working timecoding, request rates, etc.

the other approach would be to maximize data rate by using interrupts from the second serial port then insert that data into the log, bypassing the existing request/response functions, conversion with the definition file, etc.. maybe even in a separate thread would be a good idea.

the ui and the datalogging are separate enough in current versions, where if you had a thread grabbing serial data, and you formed a proper log 'packet' or whatever i called it, you just have to generate a QT signal to tell the rest of the program that new data has arrived and it'll probably handle the rest of displaying, realtime graph updating, etc. without complaining

there's a bit more involved to doing it properly, such as another serial port selection area in the settings dialog (and related back end in the settings storage)

[kur4o]

Some of the innovate documents I have gathered regarding serial datastream. If the interest arise I will make some serial logs of actual communication between gauge and innovate`s Logworks3.

[spfautsch]

Unless you're willing to tackle it I wouldn't spend much time on it right now kur4o. As mentioned I probably won't have time to work on anything like this for 5-6 months.

steveo I think your first approach with the dummy device ID might be the smart way to go. I'm envisioning parsing the UEGO controller stream in a separate thread and handing the data off to the datalogger.

This is all conjecture because I've got my plate full. This week aside from trying to get my yard work done in between rain showers, I'm pulling my engine back out because the shaft mount rockers work so well that I think I've bent an intake valve.