Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000272FirmwareCalculations (Inj/Ign)public2011-09-24 19:452014-02-18 23:05
ReporterFred 
Assigned ToFred 
PriorityhighSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.2.1Fixed in Version 
Summary0000272: Improve RPM Accuracy & Granularity At All Scales
DescriptionCurrently RPM is calculated in an acceptable way at low RPMs and degrades as RPM increase to a granularity of 125 or so at 17000. Clearly this is unacceptable, however it's usable at 8k and below for the time being.

This can be achieved by using different scaling factors depending upon the raw RPM involved. A single figure can never be correct given the range required.

This change will carry with it the added benefit of a lower minimum RPM. Maximum levels will be more usable due to 0.5 granularity or close being restored.
TagsNo tags attached.
FirmwareVersion
Issue TypeImprovement
Risk of Breakagelow
Attached Files

- Relationships
related to 0000118assignedFred Make time tolerance be speed dependent 

-  Notes
User avatar (0000363)
Fred (administrator)
2011-10-10 14:45

Added relationship to 0000118 as they both use the same math at the moment. Note, if trying to sync, need to use the LOW rpm default, as using any other could result in an over flow with a lower RPM, and we need to know what to do with this BEFORE we have an initial RPM.
User avatar (0001161)
Fred (administrator)
2012-01-29 13:11

http://stuff.fredcooke.com/6minus2.to.FreeEMS.redline.png [^]

We need to gracefully handle the possibility of roll over at the top of the scale, too. 32k RPM isn't likely, however we are likely to reduce max RPM somewhat, and when we do some mental bikes could brush up against that. We want it to cut, not schedule wrongly, so it should remove sync somehow.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker