fix: reset proto scan software timer to MULTI_PROTOLIST_START_TIMEOUT #3763
Conversation
reset proto scan software timer to MULTI_PROTOLIST_START_TIMEOUT if timer already exists (from previous scan)
|
There's no need for the 2.8 / 2.9 ports unless there is an actual change needed for the different branches... git will cleanly cherrypick them regardless of line changes. This also has the benefit of cross-referencing a commit across different branches. |
|
Yes, I know, but wanted to have 2.8.4+ built to ask the problem finder(s) to give it a go before messing up 2.8.5 |
Plus, it is easier to track if everything is linked back to the same original PR. |
|
problem finder responded, ok. I'll close the 2.8 and 2.9 ports, cherry-picking main will work |
|
Sorry, I should have commented further on this... I realised what Michael was up to later, as the issue was easiest reproduced on 2.8, as the MPM list is incomplete there. Plus, since no settings were changed, so it also let the original reporter test the fix without worrying about model/radio settings. So all good there. |
|
It shouldn't be color specific. Just depends on MPM internal or external. |
|
By "colorlcd specific bug" I'm referring to the fact that even though it is common code, you can't reproduce the bug on B&W ;) |
|
Yeah, I can't quite see the stepping code (eyes glazing over), but I thought B&W was still steered by the MPM. Anyway, it works 🤪 ... and you've not complained yet 😁 |
|
@pfeerick @raphaelcoeffic you are right. stdlcd retrieves protocols by the MPM status (protocol prev, current, next) or if the status is invalid (e.g. MPM missing) by the builtin fallback list. The fallback list is up to date now (= MPM 1.3.3.20) but needs to be synced with upcoming MPM releases. This issue really is a colorlcd specific one because only colorlcd is scanning and collecting protocols. |
…#3763) reset proto scan software timer to MULTI_PROTOLIST_START_TIMEOUT if timer already exists (from previous scan)
…#3763) reset proto scan software timer to MULTI_PROTOLIST_START_TIMEOUT if timer already exists (from previous scan)
... if timer already exists (from previous scan)
fixes #3084
changes:
Protocol scans use software timers to fetch the MPM protocol list at 100ms rate but with an initial rate of MULTI_PROTOLIST_START_TIMEOUT (3000ms) for the first poll to allow the MPM to finish its startup sequence after power on. Switching models back and forth power cycles the MPM. As the software timer already exists it is not instantiated again but reused. but with the rate it was left, i.e. 100ms, not the required 3000ms to allow the MPM to settle. Resetting the timer rate to MULTI_PROTOLIST_START_TIMEOUT solves the problem.
Note: the current implementation will under certain circumstances (e.g. model change back and forth) poll the MPM at 100ms with every poll failing and rebuilding the fallback list because the MPM missed the initial handshake. This goes on for the entire radio power life cycle. This is why I'd strongly advise to cherry pick the fix also into 2.8.5 and 2.9.