Anonymous | Login | Signup for a new account | 2021-01-16 12:34 UTC | ![]() |
Main | My View | View Issues | Roadmap | Repositories |
View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000499 | Firmware | Scheduler (Inj/Ign) | public | 2012-01-11 12:23 | 2012-03-26 15:13 | ||||
Reporter | Fred | ||||||||
Assigned To | Fred | ||||||||
Priority | urgent | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 0.2.0-SNAPSHOT | ||||||||
Target Version | 0.2.0 | Fixed in Version | 0.2.0 | ||||||
Summary | 0000499: Find Source Of 0.109ms timing error | ||||||||
Description | Static bench test with 1250RPM 5000 tick per event 12-1 bench test hack Dwell of 1000 ticks/0.8ms or 10000 ticks/8ms behaves the same. Timing is correct with different decoder offsets and different timing values, however it always has 0.109ms error in it. Dwell end is slightly late. This doesn't change with RPM or dwell or timing, it's always there. | ||||||||
Tags | No tags attached. | ||||||||
FirmwareVersion | |||||||||
Issue Type | Bug | ||||||||
Risk of Breakage | high | ||||||||
Attached Files | |||||||||
![]() |
|
![]() Fred (administrator) 2012-03-25 03:40 |
This needs to be fixed too! The firmware should do what it claims to. Bugs should be closed out quickly in priority over features, most of the time. |
![]() Fred (administrator) 2012-03-25 15:47 |
OK, this is on both fuel and ignition channels, so it's definitely something to do with the schedule and/or output code, not some random ign timing calculation error. Dwell is absolutely perfect as set in the code. Timing is off by a cat's whisker. |
![]() Fred (administrator) 2012-03-25 16:12 |
0.1095833 * 1250 = 136.979125 = 137 ticks, exactly, sampled at 24MHz. There is a clue in that, somewhere. |
![]() Fred (administrator) 2012-03-25 16:17 |
Verified with N+1 decoder to be the same, and irrespective of RPM as in the original report. |
![]() Fred (administrator) 2012-03-26 14:42 |
Set up the priming pulse stuff to use specific values and marked the schedule point with a bit bang and it performs perfectly there. Will hard code the schedule now and see what it does. |
![]() Fred (administrator) 2012-03-26 14:50 |
Hard proved that it's in the output stage by hard coding the scheduling! This is good news, getting closer :-) Will try another mode of output now and see if that is affected too. |
![]() Fred (administrator) 2012-03-26 14:55 |
Both methods are equally affected. |
![]() Fred (administrator) 2012-03-26 15:13 |
I was chasing ghosts! I was sampling the inputs on the FredStim and the outputs on the DUT and there is an RC constant effect in the MAX9924 circuit. This requires some hardware investigation. http://forum.diyefi.org/viewtopic.php?f=9&t=1675 [^] |
Copyright © 2000 - 2011 MantisBT Group |