Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

acars: reset MSK state properly #32

Closed
wants to merge 1 commit into from
Closed

Conversation

dev-zzo
Copy link

@dev-zzo dev-zzo commented Jan 18, 2018

Fixes a case where multiple channels go deaf after 20+ hours or reception. The root cause appears to be the ch->Mska not being reset when clearing up the decoder state.

Fixes a case where multiple channels go deaf after 20+ hours or reception
@TLeconte
Copy link
Owner

OK to add a reset resetAcars function but :
MskDf and Mska are PLL variables.
They must not be reseted during waiting for sync detection ....
What could happen is : when receiving noise the PLL goes mad and so the demod goes deaf .
Perhaps I could set limit to the values of Mskf and Mska.
So I not accept this change, I will try to find a better one .

@dev-zzo
Copy link
Author

dev-zzo commented Jan 19, 2018

The issue is, at least as I see it, that Mska is never reset to zero after the initialization in initMsk(); at the same time, its value is accumulated constantly in demodMsk(). So I can imagine a case where, given that noise conditions are sufficiently poor, the value goes out into the sky and can't be brought back into the sane range.

The original intention of the patch was to reset Mska together with MskDf wherever this is done in the original code, thereby bringing those to their initial values together. But now that you pointed it out, the changeset appears incorrect regarding the handling of the WSYN state. :-/ Or, at least, it changes the initial intention of the code.

@TLeconte
Copy link
Owner

TLeconte commented Jan 19, 2018

Yes it's exactly that.
What I will do, is to limit the abs value of Mska and Mskdf . I hope it will be sufficient to solve your problem.
(and I keep the idea of a reseting function. It's largely nicer).

@TLeconte TLeconte closed this Jan 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants