| Anonymous | Login | Signup for a new account | 2020-10-29 23:30 UTC |  |
| Main | My View | View Issues | Roadmap | Repositories |
| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
| 0000272 | Firmware | Calculations (Inj/Ign) | public | 2011-09-24 19:45 | 2014-02-18 23:05 | ||||||
| Reporter | Fred | ||||||||||
| Assigned To | Fred | ||||||||||
| Priority | high | Severity | minor | Reproducibility | always | ||||||
| Status | assigned | Resolution | open | ||||||||
| Platform | OS | OS Version | |||||||||
| Product Version | 0.2.0-SNAPSHOT | ||||||||||
| Target Version | 0.2.1 | Fixed in Version | |||||||||
| Summary | 0000272: Improve RPM Accuracy & Granularity At All Scales | ||||||||||
| Description | Currently 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. | ||||||||||
| Tags | No tags attached. | ||||||||||
| FirmwareVersion | |||||||||||
| Issue Type | Improvement | ||||||||||
| Risk of Breakage | low | ||||||||||
| Attached Files | |||||||||||
 Relationships |
 Notes |
|
 (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. |
|
(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. |
|
Notes |
| Copyright © 2000 - 2011 MantisBT Group |
 |
