0000499: Find Source Of 0.109ms timing error

(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.

(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.

(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.

(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.

(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.

(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.

(0001339)
Fred (administrator)
2012-03-26 14:55

Both methods are equally affected.

(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 [^]

Notes
(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.

(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.

(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.

(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.

(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.

(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.

(0001339) Fred (administrator) 2012-03-26 14:55	Both methods are equally affected.

(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 [^]

Relationships