What new MJLJ firmware feature would you like to see?
Moderators: JeffC, rdoherty, stieg, brentp
What new MJLJ firmware feature would you like to see?
If there was one feature you'd like to see added to the controller firmware, what would you like to see?
I'll go first: Configurable traction control. Upon detection of 'wheel slippage' (i.e. unrealistically high engine acceleration) the ignition would be automatically retarded, reducing power and hopefully bringing the wheels under control.
Any other ideas?
I'll go first: Configurable traction control. Upon detection of 'wheel slippage' (i.e. unrealistically high engine acceleration) the ignition would be automatically retarded, reducing power and hopefully bringing the wheels under control.
Any other ideas?
-
- Posts: 43
- Joined: Mon Jul 23, 2007 8:19 pm
-
- Posts: 204
- Joined: Tue Feb 14, 2006 2:14 pm
- Contact:
Ok, just to clarify When I mean firmware upgrade I'm talking about features that can be implemented with minimal to no hardware changes.Supercharged Nat wrote:your guna hate me for saying it, but for me it has to be the retard upon sensing detonation.. i like the traction control idea too, just with my car, id prefer not to have it. It would need to be ablt to turn it off though, as sometimes people like to 'light them up'
For the traction control feature it would be more like 'launch control' that can be enabled or disabled from the cockpit. Seems like the many disproportionately high powered cars (turbo/supercharged) running MJLJ could benefit from this.
Keep the ideas coming!
-
- Posts: 204
- Joined: Tue Feb 14, 2006 2:14 pm
- Contact:
-
- Posts: 204
- Joined: Tue Feb 14, 2006 2:14 pm
- Contact:
I had a thought as I was out driving my car this morning... how about some form of 'map coverage' function?
I can picture the following scenario:
Car running, with the laptop plugged into the MJ unit.
Press a function key to start 'map coverage'.
Drive the car briskly, including acceleration, braking and cruising at various speeds.
At the end of the run, look at the map grid to see which cells have been used during the run.
The 'visited cells' could be a different colour while this function was working, to return to normal once the test was finished.
I think it would be useful to see whether the whole map is being used - if there are areas where the map hasn't been used then the X/Y scales can be adjusted. It would also be useful where there isn't a passenger to watch the grid while driving!
This functionality is likely to be just a configurator change - I can't see why the firmware would need modification.
What do you think, Brent?
cheers,
David
I can picture the following scenario:
Car running, with the laptop plugged into the MJ unit.
Press a function key to start 'map coverage'.
Drive the car briskly, including acceleration, braking and cruising at various speeds.
At the end of the run, look at the map grid to see which cells have been used during the run.
The 'visited cells' could be a different colour while this function was working, to return to normal once the test was finished.
I think it would be useful to see whether the whole map is being used - if there are areas where the map hasn't been used then the X/Y scales can be adjusted. It would also be useful where there isn't a passenger to watch the grid while driving!
This functionality is likely to be just a configurator change - I can't see why the firmware would need modification.
What do you think, Brent?
cheers,
David
-
- Posts: 204
- Joined: Tue Feb 14, 2006 2:14 pm
- Contact:
Not sure what you mean by a 'histogram view' Brent! I was thinking along simpler lines - just colour the cells on the set-up grid (not the run-time display) that get used in a run (including the ones that are used in interpolations).brentp wrote:That is an excellent idea. I would imaging a histogram view of used load and RPM cells, based on the current data logging history.
Thanks!
David
Why keep it simple?
Some sort of indication of how much time is spent in which cells would be excellent as just colouring them in if they've been "visited" (ie used in interpolation) doesn't give you an idea of which parts of the map are being used most/least and could potentially benefit from finer/coarser tuning by adjusting the rpm and load axes...
Just my $0.02....
Martin
Some sort of indication of how much time is spent in which cells would be excellent as just colouring them in if they've been "visited" (ie used in interpolation) doesn't give you an idea of which parts of the map are being used most/least and could potentially benefit from finer/coarser tuning by adjusting the rpm and load axes...
Just my $0.02....
Martin
-
- Posts: 204
- Joined: Tue Feb 14, 2006 2:14 pm
- Contact:
Why keep it simple? So simple beggars like me can understand it!
Whatever route is taken, it should be easy to understand the results. If anyone here has ever looked at the MegaSquirt documentation you will see that it is a total nightmare, and very hard to make a start into it. MJLT is a delight by comparison!
David
Whatever route is taken, it should be easy to understand the results. If anyone here has ever looked at the MegaSquirt documentation you will see that it is a total nightmare, and very hard to make a start into it. MJLT is a delight by comparison!
David
That's why I suggested the histogram view.MartinM wrote:Why keep it simple?
Some sort of indication of how much time is spent in which cells would be excellent as just colouring them in if they've been "visited" (ie used in interpolation) doesn't give you an idea of which parts of the map are being used most/least and could potentially benefit from finer/coarser tuning by adjusting the rpm and load axes...
Just my $0.02....
Martin
http://en.wikipedia.org/wiki/Histogram
The data that feeds this view would be sourced from the datalogging stream. When considering the examples in the link above, think of a 3-D version of this chart representing the dataset we're working with.
Cool stuff.
David: Thanks!
-
- Posts: 204
- Joined: Tue Feb 14, 2006 2:14 pm
- Contact:
-
- Posts: 9
- Joined: Wed Feb 09, 2005 5:33 pm