Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000499FirmwareScheduler (Inj/Ign)public2012-01-11 12:232012-03-26 15:13
ReporterFred 
Assigned ToFred 
PriorityurgentSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.2.0Fixed in Version0.2.0 
Summary0000499: Find Source Of 0.109ms timing error
DescriptionStatic 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.
TagsNo tags attached.
FirmwareVersion
Issue TypeBug
Risk of Breakagehigh
Attached Files

- Relationships

-  Notes
User avatar (0001308)
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.
User avatar (0001328)
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.
User avatar (0001329)
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.
User avatar (0001330)
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.
User avatar (0001337)
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.
User avatar (0001338)
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.
User avatar (0001339)
Fred (administrator)
2012-03-26 14:55

Both methods are equally affected.
User avatar (0001340)
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
Powered by Mantis Bugtracker