OpenFlash Tablet

[AdrianG]

With OP2 I currently log:

IAM
throttleplate_angle
MAF
engine_load
throttle_position
AFR
gear
ignition_total_timing
KC_learned_value
feedback_knock_correction
fine_knock_correction
requested_torque
load
coolant_temp
STFT
LTFT
MAP
RPM
speed_KMH
advance
IAT
fuel_pressure
lambda
O2_volt
O2_current
cat_temp
abs_load

I would like to add AVCS to this list but the memory addresses are still not known to the opensource crowd. What would you strike from this list?

[Shiv@Openflash]

Originally Posted by AdrianG

With OP2 I currently log:

IAM
throttleplate_angle
MAF
engine_load
throttle_position
AFR
gear
ignition_total_timing
KC_learned_value
feedback_knock_correction
fine_knock_correction
requested_torque
load
coolant_temp
STFT
LTFT
MAP
RPM
speed_KMH
advance
IAT
fuel_pressure
lambda
O2_volt
O2_current
cat_temp
abs_load

I would like to add AVCS to this list but the memory addresses are still not known to the opensource crowd. What would you strike from this list?

It really depends on what you are trying to accomplish. Do you just want to monitor things for general purposes (to keep an eye on things)? Or are you trying to troubleshoot something in particular? After doing this for so long, I'm a firm believer of keeping things simple. My brain seems to work better when I'm not drowned in data. But others may not have such a bandwidth limitation

Shiv

[AdrianG]

Coming from a sysadmin/network engineering background I feel it's better to collect everything you can and "grep -v" what you don't care about. Sometimes what you're looking for isn't known during the data collection phase.

I just did some testing with the OFT:

- disabled all but RPM, it works!
- re-enabled ~3 or 4 at a time, worked until I enabled STFT and LTFT.
- disabled LTFT and STFT, works again!
- enabled LTFT and enough other params to hit the 12 barrier, works!
- disabled a few params and re-enabled STFT, works!

So the params are selected the same as they were when I started and now it works. Definitely seems buggy since the same config can yield a different result...

Is there a list somewhere of the available params? Sitting in the car and scrolling on the OFT is not the best way to read what's available, I'd like to sit (outside of my car) and think a bit about what I care about most.

Do you think the limitation of 12 at a time will ever be lifted?

I'm not trying to accomplish anything, aside from keeping an eye on things and trying to learn more about this stuff.

[Cross]

I agree having the data is great but as a System/Network Admin as well think of it this way.

The more strain you put on the system the slower it responds. The same goes for the OFT it seems at its current state. You may be able to log all those minus RPM for example but the sampling rate may be 1 time a second of worse. The better the sampling rate the more data that's usable that you actually collect since things in a engine moving at 1000 to 7000 Revolutions Per Minute can happen pretty fast.

Trust me I see both sides and it has taken me a long time to dial down the inputs I use on just HP Tuners because I am not always sure just what data I might need. Same goes for here.

So I completely understanding wanting more data at once but sometimes you have to pick and choose. Then if you have a problem you cannot solve or have a hunch about select different tables.
Maybe in the future a software or hardware update will change that.

[Shiv@Openflash]

Originally Posted by AdrianG

Coming from a sysadmin/network engineering background I feel it's better to collect everything you can and "grep -v" what you don't care about. Sometimes what you're looking for isn't known during the data collection phase.

I just did some testing with the OFT:

- disabled all but RPM, it works!
- re-enabled ~3 or 4 at a time, worked until I enabled STFT and LTFT.
- disabled LTFT and STFT, works again!
- enabled LTFT and enough other params to hit the 12 barrier, works!
- disabled a few params and re-enabled STFT, works!

So the params are selected the same as they were when I started and now it works. Definitely seems buggy since the same config can yield a different result...

Is there a list somewhere of the available params? Sitting in the car and scrolling on the OFT is not the best way to read what's available, I'd like to sit (outside of my car) and think a bit about what I care about most.

Do you think the limitation of 12 at a time will ever be lifted?

I'm not trying to accomplish anything, aside from keeping an eye on things and trying to learn more about this stuff.

In some instances I think the user may have to enter the channel configuration screen before real time data viewing works. But only once right after the firmware update. This is just to initialize the datalog channels. Which you essential did by remove them and adding them back one at a time.

We can and will likely raise the 12 channel limit but I cannot give a timeframe on that. There are some more to-do items to implement before that and I know better than giving out half baked ETAs

I'll make a list of all available channels and put it on the website for reference. And when I get to a computer I'll list 12 channels that I think are good for general tuning purposes. Hint: they are the first 12 in the list of datalog channels lol

[Sonolin]

Really, I thought ecuflash was working?

Sure its probably beta, but plenty of software is always in "beta" and people use it all the time. Heck I use some on some customers' development projects all the time. Not the big players who require 100% lock down security, and VPN access into their box to just update 1 file, but it all comes down to paranoia really. Every software has "bugs" in it, whether beta or not, and a beta/alpha version can be just as stable as a final production version.

Either way, ecuflash seems like a really cool option for this and is the first I thought of.

[AdrianG]

@Cross the list I provided gives me 20 samples per second, so at this point I don't need to pick and choose.

- AdrianG

[regal]

Originally Posted by Sonolin

Really, I thought ecuflash was working?

Sure its probably beta, but plenty of software is always in "beta" and people use it all the time. Heck I use some on some customers' development projects all the time. Not the big players who require 100% lock down security, and VPN access into their box to just update 1 file, but it all comes down to paranoia really. Every software has "bugs" in it, whether beta or not, and a beta/alpha version can be just as stable as a final production version.

Either way, ecuflash seems like a really cool option for this and is the first I thought of.

If you have two or three cars yes, but if this is your only car I think its still too early/risky. Would hat to tell my boss I won't make it into work this work cause I bricked my ECU.

[nelsmar]

Originally Posted by Sonolin

Really, I thought ecuflash was working?

Sure its probably beta, but plenty of software is always in "beta" and people use it all the time. Heck I use some on some customers' development projects all the time. Not the big players who require 100% lock down security, and VPN access into their box to just update 1 file, but it all comes down to paranoia really. Every software has "bugs" in it, whether beta or not, and a beta/alpha version can be just as stable as a final production version.

Either way, ecuflash seems like a really cool option for this and is the first I thought of.

The main issue is that afaik there currently is no publicly available recovery method for failures. I cannot risk bricking an ecu and then having to order a new one or spend extended periods of time un-bricking it. Otherwise this would be just fine. Also having a company that backs their product and having someone to call when there is an issue is a big deal when working on other peoples cars. Nothing is less professional than "Well... The car won't start any more so let me post on Rom Raiders and get back to you next week".

[Sonolin]

Originally Posted by nelsmar

The main issue is that afaik there currently is no publicly available recovery method for failures. I cannot risk bricking an ecu and then having to order a new one or spend extended periods of time un-bricking it. Otherwise this would be just fine. Also having a company that backs their product and having someone to call when there is an issue is a big deal when working on other peoples cars. Nothing is less professional than "Well... The car won't start any more so let me post on Rom Raiders and get back to you next week".

Sure that makes sense. It definitely makes sense to wait for a recovery method I thought romraider was farther along than that.

Other than that issue, it looks like its making great progress though. Sure you don't get support like Ecutek, but for people who don't have an Ecutek license its the next best thing if you need faster flash time. At least that will be what I look into if the case arises.

[nelsmar]

Originally Posted by Sonolin

Sure that makes sense. It definitely makes sense to wait for a recovery method I thought romraider was farther along than that.

Other than that issue, it looks like its making great progress though. Sure you don't get support like Ecutek, but for people who don't have an Ecutek license its the next best thing if you need faster flash time. At least that will be what I look into if the case arises.

Yup once auto recovery is in there it opens some extra door ways. Originally I was going to contribute to the open source as much as possible to use it on my own build.

[Cross]

Originally Posted by AdrianG

@Cross the list I provided gives me 20 samples per second, so at this point I don't need to pick and choose.

- AdrianG

Really, now that is nice for a list like that then. But then this is OP2 not OFT and I think with OFT is where the issue of sampling would come into play. I shoud have been more specific I thought we were talking about the abilities of OFT with more channels open.

[steve99]

Originally Posted by nelsmar

The main issue is that afaik there currently is no publicly available recovery method for failures. I cannot risk bricking an ecu and then having to order a new one or spend extended periods of time un-bricking it. Otherwise this would be just fine. Also having a company that backs their product and having someone to call when there is an issue is a big deal when working on other peoples cars. Nothing is less professional than "Well... The car won't start any more so let me post on Rom Raiders and get back to you next week".

When you talking recovery method your talking about more than recovering from a interrupted flash or bad tables ect Where you could generally re-rlash with original or prevoius ROM and recover

Like missing/corrupted boot loader or somehow you have written to and area you shouldn't have ??

If so aren't you pretty snookered with any platform. Maybe ecuek might sort it of you pull ecu and send it to them.

The "problems" ecutek seem to sort out quickly phone/internet seem to be "licensing" issues rather than a properly bricked ecu.

just asking

[regal]

Originally Posted by steve99

When you talking recovery method your talking about more than recovering from a interrupted flash or bad tables ect Where you could generally re-rlash with original or prevoius ROM and recover

Like missing/corrupted boot loader or somehow you have written to and area you shouldn't have ??

If so aren't you pretty snookered with any platform. Maybe ecuek might sort it of you pull ecu and send it to them.

The "problems" ecutek seem to sort out quickly phone/internet seem to be "licensing" issues rather than a properly bricked ecu.

just asking

Sounds like your saying the software anti-piracy causes the lockups and with ECUflash this of course isn't a factor, makes I lot of since. But I'm still going to get a door on my second car before I mess with ecuflash or OFT .