Tuning software features

Post Reply
User avatar
kb1gtt
contributor
contributor
Posts: 3407
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Tuning software features

Post by kb1gtt » Sat May 25, 2019 11:11 am

There has been talk in Slack about tuning software features. I figured I'd put a bit of a list here. I would say it's kind of a wish list or dream list. I wonder how many if any of these can be built into TS.
-- Save the TS config file inside the Frankenso / ECU. This would allow you to find the proper tune file when you need it, or if you have a professional tuner do your work, it would create a common place where someone new to your ECU could find the files and start working from there.
-- I think it would be handy to have three layers of TS configuration ability. I could see three modes being Common, Expert, and Developer. I picture that once the key features have been setup, there are Common features that people want to focus on. AKA you change your intake or exhaust, and you want to re-run your tables, or you simply want gauges that are wireless transmitted to someone in the pits who is monitoring the car remotely. I think it would be handy for those features to be the default when you open TS or similar tuning software. Then if you are making more significant changes, you change the mode to Expert. This would allow you to change sensor curves, or core things like wasted spark, sequential fuel, etc. Basically I see Expert as what you currently see in TS. Then I could see Developer as the mode which allows you to do all sorts of crazy stuff, perhaps even violate safety limits, etc.
-- Perhaps user profiles, like "driver" or "remote pits" or "hardware PC" I could see how a driver profile might have gauges or features that are handy for the driver. Perhaps driver would allow some logging or self diagnostics while it's on a drive. Then "remote pits" might be stripped down perhaps even compressed to get data over an intermittent or slower data-stream. I could see this mode even having an acknowledge such that if you only get a connection when you pass the pits, it dumps what ever data it could during that brief time. Then when there is no connection, it saves that data on the ECU. Then I could see a PC connection as useful. Basically one that sends data as fast as possible to a PC.
-- A share data button. I've seen it a hundred times and I'm sure I'll see it many more times. A request to share your logs and tune files. For some reason people keep posting "I have a problem, fix it" type messages. For some reason they don't post any data. I think they often forget to put themselves in other people shoes, and they forget how much information they have access to that others do not. I also think that developers often forget how hard it can be to post that data. Dealing with firewalls, antivirus issues, etc. Simply getting the files posted on a forum or passed in e-mail can be a bugger that many gear heads struggle with. I think a button in the tuning software which would post the tune files, would be useful. Perhaps a help request button. It posts it some where on the web, and then it's easier for remote persons to have a log file.
-- I think the PCB should have some hard coded serial number. It could be a resistor divider connected to an ADC, or perhaps a serial memory device. Basically some way that the rusEFI software could identify what hardware it is connected to.
-- Some kind of capture event option. Basically if you have some kind of intermittent problem, you could have a switch, or perhaps you could have an automatic signal like a knock or similar automatic signal. This signal could trigger some kind of signal in your log files to help flag when a particular problem happens. Then the tuning software could jumper from event to event making it much easier to find intermittent issues.
-- Flow graphs for things like fuel injector times. I could see how a flow diagram for an injector, might show it's driven by the schedule, then by IAT, TPS, table, fuel modifier table, etc. When a fuel pulse is wrong, it can be handy to track through the flow diagram to figure out what made the output signal wrong.

Any how, that's my brief list of features which I think would make a tuning software extra great. Of course the core features already in TS are a minimum.
Welcome to the friendlier side of internet crazy :)

mck1117
running engine in first post
running engine in first post
Posts: 226
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish
Soldering skill: yes
Coding skill?: yes

Re: Tuning software features

Post by mck1117 » Wed May 29, 2019 4:45 am

kb1gtt wrote:
Sat May 25, 2019 11:11 am

-- I think the PCB should have some hard coded serial number. It could be a resistor divider connected to an ADC, or perhaps a serial memory device. Basically some way that the rusEFI software could identify what hardware it is connected to.
This one is already here, the STM32 has a unique ID burned in from the factory. It's some combination of wafer sequence number, X/Y position of that die in the wafer, and some random number at the end.

User avatar
kb1gtt
contributor
contributor
Posts: 3407
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: Tuning software features

Post by kb1gtt » Wed May 29, 2019 9:30 am

We do not have a list of serial numbers vs the board they were installed on. I guess we could have an EEPROM, then when it's programmed for the first time, we could have a button where we program a number into the external EEPROM that determines what the hardware is. Then if you re-flash the STM32, this number in the EEPROM survives. I swear I recall reading an article about a monitor chip which included both a unique number, then allowed you to pin a non-unique number. I can't seem to find it now, so I guess an EEPROM with a software step is an easy-ish to implement solution.

This one is $0.19 and provides 1-Kbit (128 x 8)
https://octopart.com/search?q=AT21CS01

For $0.84, you get 256K
https://octopart.com/search?q=24AA256UID

For $2.20, you get 2M
https://octopart.com/search?q=AT24CM02

Any how, if we embedded a number in the EEPROM, than the log files could embedded the hardware information. Then when logs are shared that would be one less piece of missing information.
Welcome to the friendlier side of internet crazy :)

mck1117
running engine in first post
running engine in first post
Posts: 226
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish
Soldering skill: yes
Coding skill?: yes

Re: Tuning software features

Post by mck1117 » Wed Jun 26, 2019 7:38 am

kb1gtt wrote:
Sat May 25, 2019 11:11 am
-- A share data button. I've seen it a hundred times and I'm sure I'll see it many more times. A request to share your logs and tune files. For some reason people keep posting "I have a problem, fix it" type messages. For some reason they don't post any data. I think they often forget to put themselves in other people shoes, and they forget how much information they have access to that others do not. I also think that developers often forget how hard it can be to post that data. Dealing with firewalls, antivirus issues, etc. Simply getting the files posted on a forum or passed in e-mail can be a bugger that many gear heads struggle with. I think a button in the tuning software which would post the tune files, would be useful. Perhaps a help request button. It posts it some where on the web, and then it's easier for remote persons to have a log file.
TS actually has this one. Go to Help -> Create Tunerstudio Debug Package. It zips up the TS logs, current tune, .ini file, etc.
kb1gtt wrote:
Sat May 25, 2019 11:11 am
-- Some kind of capture event option. Basically if you have some kind of intermittent problem, you could have a switch, or perhaps you could have an automatic signal like a knock or similar automatic signal. This signal could trigger some kind of signal in your log files to help flag when a particular problem happens. Then the tuning software could jumper from event to event making it much easier to find intermittent issues.
TS sort of has this already. If you go to data logging -> triggered logging, you can set up conditions under which you should log. For example you could add a button wired to the ECU, then when it's pressed, log for the next 60 seconds. Or if sometimes some sensor does something whacky, trigger on the whacky value.

Post Reply