garbagetrash
commented
5 years ago I'm eyeing this one up as a next priority... if we did it prior to attacking the pulse shaping then we could support more of the interesting pulse shaping types (like root raised cosine) when we get there.
This node is one of the more interesting ones we're looking at attacking for our MVP... @rfdoell @Alex-Addy @ostrosco if any of you three are interested in this collaborating with me on this ( because you have ideas regarding implementation details, want to learn more about FIR filters, or simply don't trust me to do it right ) please make it known and we'll toss you on it as well.
This one isn't 'hard' per se, but it's pretty important. FIR filters are gonna be everywhere in practice, as a minimal thing we'll need a naive implementation so we can do pulse shaping, alias filtering, and matched filtering.
Reference the wiki, but the basic equation is:
Where output signal is y[n], input signal is x[n], and filter taps (coefficients) are b_i.
Later on down the road if/when we end up doing all our batch processing we may want to extend this to do convolution via FFTs as an additional alternative node. FFT based filtering is faster once your number of taps is "large", which iirc in practice is something like 100+ taps. I'm not sure if even rust will be able to do filters that large real time, so I'm not sure if this will be something we want to bother with or not.
Either way, the scope of this issue is limited to the direct form 1 implementation, straightforward and easy. Filter implementation should just take vector of taps as input argument. Filter design is a later problem that can be solved, if it's even necessary. As a user I plan on doing the design outside of rust via Matlab or Scipy, then just grabbing those taps and dropping them into this node.