ad936x-filter-wizard
ad936x-filter-wizard copied to clipboard
analogdevicesinc
Filters with leading and ending zeros
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 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.
The filter taps are configurable in groups of 16 between a minimum of 16 and a maximum of 128 taps.
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.