-
Notifications
You must be signed in to change notification settings - Fork 40
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
Filters with leading and ending zeros #43
Comments
The hardware+driver doesn't support loading arbitrary tap lengths. They need to be 16,32,64, or 128. |
Thank you for your reply. This information is contradicting UG-570 revA pg 31 and pg 34.
|
Yes you are correct. So I believe this comes from the constraint that RX and TX filters need to be the same length. |
I tried to find information about the constraints in relevant sections in UG-570 but couldn't find anything about that the Tx and Rx filter must be of same length. Maybe I missed it so my question is where can I read about this? Thanks |
With the AD9361 - there are lots of undocumented constraints that are built into the tools or drivers. |
Yesterday I read the source for the AD9361 no-os driver and I couldn't see any checks for this constraint. I could for example see checks validating number of taps (!ntaps || ntaps > 128 || ntaps % 16) and if interpolation/decimation factors are valid for chosen number of taps. Both of these are also mentioned in UG-570. Can you please show me where is the check for Tx taps == Rx taps? |
I still haven't seen any clues in the no-OS code that suggests that Rx and Tx must have same lengths. I do see the ftr parsing code however assumes they are always the same but none of the functions to program the filter to the chip does any check for it. To me it looks like it's an issue with the ftr file format where the Tx and Rx coefficients are stored in pairs and the number of lines determines the number of taps. The export to no-OS shouldn't have this issue since in that case the number of taps are stored in separate variables but then #28 breaks it instead. |
You won't find it in the driver - it's in the filter designer. |
This is apparently not documented in any public document. Please see analogdevicesinc/ad936x-filter-wizard#43. This adds check to make sure the Rx and Tx number of FIR taps matches. Signed-off-by: Alexander Vickberg <[email protected]>
This is apparently not documented in any public document. Please see analogdevicesinc/ad936x-filter-wizard#43. This adds check to make sure the Rx and Tx number of FIR taps matches. Signed-off-by: Alexander Vickberg <[email protected]>
Hi,
I generated a filter (Tx) which returned 128 taps with first and last 8 taps all zeros. I wonder if this is expected and if there's any reason it wasn't a 112 tap filter instead?
The text was updated successfully, but these errors were encountered: