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

Code 6.1 Pg 198: Clarification regarding decimation #12

Open
solomonbstoner opened this issue Sep 24, 2021 · 2 comments
Open

Code 6.1 Pg 198: Clarification regarding decimation #12

solomonbstoner opened this issue Sep 24, 2021 · 2 comments

Comments

@solomonbstoner
Copy link

In Code 6.1, there is a decimation of 4 in the receiver matched filter. Why is that so? Changing it to 1, I get the following animation, which looks the same to me as using decimation of 4 (except it slower). What is the purpose of the decimation?

Also, why does decimation=1 result in a slower change than decimation=4? I was expecting it to be the same since tau is a fraction of a symbol period

code6 1_decimation_1
Decimation = 1 is above ^ . Decimation = 4 is below v .
Freq =2400000000Hz, SampleRate =1000000Hz 2021-09-24 22-44-56

@tfcollins
Copy link

The Tx RRC filter always interpolates by SamplesPerSymbol but the RRC only decimates by the supplied Decimation factor. The remaining symbols (SamplesPerSymbol - Decimation) can be used to better estimate the timing error. This is likely slower since you are processing 4x the data when setting decimation to 1.

@solomonbstoner
Copy link
Author

Ah that makes sense. But just to clarify, should it be SamplesPerSymbol - Decimation or SamplesPerSymbol/Decimation?

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

No branches or pull requests

2 participants