Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000120FirmwareScheduler (Inj/Ign)public2011-06-15 12:122015-05-17 11:40
ReporterFred 
Assigned ToFred 
PriorityimmediateSeveritymajorReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.2.0Fixed in Version0.2.0 
Summary0000120: Make scheduler UNschedule when appropriate
DescriptionMake scheduler UNschedule when no accurate time difference number is available. The scheduler relies on this number to make its calculations and, as such, if it's wrong, the scheduling is wrong too, which is pretty serious. This is only an issue for the first schedule each time, ie, at start, or post sync loss.
TagsNo tags attached.
FirmwareVersionssssssssssssssssssssssssssssssssssssssssssssssssss
Issue TypeImprovement
Risk of Breakagemedium
Attached Files

- Relationships

-  Notes
User avatar (0002821)
Fred (administrator)
2014-06-25 10:48

I might do this by setting a invalidData cut flag pair with sync loss, and clearing it again with resync such that if the scheduler runs with the invalid data, it won't calculate anything, and will deschedule everything. Then the next time it runs without the cut flags, it'll be guaranteed to have good valid data. There might be a cleaner way, but I just wanted to record this idea.
User avatar (0002824)
Fred (administrator)
2014-06-25 11:09

Looking at this tonight because I see high-RPM spikes on sync loss on the HOTEL. I believe this is caused by bad data being written down, then processed, then potentially used (not actually in my case, but...).
User avatar (0002825)
Fred (administrator)
2014-07-05 02:15

The block of code in init.c around line 466-490 should be moved to a function and changed to a loop. It should then be called from init.c and from the sync loss function, too.
User avatar (0002838)
Fred (administrator)
2015-05-17 11:39

Fixed in 9efc524f6c67e397c5d6c770af9a6c374581db7e which is final and to be published at some point in future.
User avatar (0002839)
Fred (administrator)
2015-05-17 11:40

Tested for many many hundreds of km on the hotel.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker