Unidad 2 · Conversores
La primera vez que medí esto pensé que había encontrado lo contrario de lo que voy a contar acá: que truncar el sinc del retardo fraccionario a más taps no mejora siempre. Estaba mal. El peor error sobre toda la banda de diseño baja las siete veces que duplico los taps, de 8 a 1024, sin una sola excepción. Lo que sí ondula -y lo que hizo que la primera medición pareciera contradecirlo- es el error en un punto fijo: entre 128 y 256 taps, ese error sube.
Las dos cosas son ciertas al mismo tiempo, sobre el mismo filtro. No hay truco: el peor caso de toda la banda pasa de a -baja a la mitad- mientras que, exactamente en el borde de esa misma banda, el error pasa de a -sube-. Lo que sigue es por qué las dos conviven, y qué hacer con eso.
El apunte plantea el problema como uno de sincronización: el receptor de un enlace digital muestrea con su propio reloj, nunca perfectamente alineado con el del transmisor, y ese desfasaje equivale a un retardo del canal. Retardar un número entero de muestras es trivial -correr los índices-, pero un desfasaje de reloj casi nunca cae justo en un entero. ¿Qué significa retrasar una fracción de muestra, si entre una muestra y la siguiente no hay señal definida?
La respuesta es honesta y no hace trampa: retrasar muestras es muestrear la señal continua subyacente segundos más tarde -la única señal de banda limitada que esas muestras podían representar-. Partiendo de la reconstrucción ideal y evaluando en el instante corrido, la cuenta se reduce a una convolución, y el filtro que hace ese trabajo es : un sinc muestreado, corrido lugares.
Con entero el sinc corrido tiene su pico exactamente en una muestra y un cero en todas las demás: , el retardo de siempre, un único coeficiente. Con fraccionario ningún entero anula el sinc, y tiene infinitos coeficientes no nulos: el filtro interpola, y cada muestra de salida combina todas las de entrada. Truncarlo a un número finito de taps -y sumarle un corrimiento entero para volverlo causal, con retardo total - es la única manera de construirlo con recursos finitos.
Esta nota mide ese truncamiento con -medio paso, el caso más parejo posible, porque no favorece a ningún lado del sinc- y . (El centro no puede elegirse en : con taps par y eso cae justo en un entero, el sinc corrido da cero en todos lados salvo un único pico, y "truncar" un impulso no trunca nada. El error saldría cero para cualquier cantidad de taps -otro resultado, y falso: se habría roto el experimento, no el filtro.)
Más taps es aproximar mejor ese sinc infinito, y la intuición dice que el error tiene que bajar parejo en todos lados. Mové el deslizador de 128 a 256 taps y mirá las dos cifras a la vez.
Sobre siete duplicaciones seguidas -8, 16, 32, 64, 128, 256, 512 y 1024 taps, con y - el peor error de toda la banda bajó las siete veces, sin un solo retroceso, partiéndose más o menos al medio en cada salto. El error en el borde exacto de la banda, en cambio, subió en dos de esos siete saltos:
| taps | error en el borde (un punto, sólo módulo) | peor error, toda la banda (módulo y fase) |
|---|---|---|
| 8 | 2,438 × 10⁻² | 1,145 × 10⁻¹ |
| 128 | 6,579 × 10⁻⁴ | 8,349 × 10⁻³ |
| 256 | 1,085 × 10⁻³ — sube | 4,175 × 10⁻³ |
| 512 | 2,109 × 10⁻⁴ | 2,105 × 10⁻³ |
| 1024 | 2,633 × 10⁻⁴ — sube | 1,057 × 10⁻³ |
Es la misma familia de fenómeno que el rizado de Gibbs de la Unidad 1: ahí, cortar de golpe deja un sobrepico que no baja con más taps -se corre, más cerca del borde en cada duplicación-. Acá el corte también es un sinc recortado con una ventana rectangular -sólo que centrado en un pico corrido , no en el origen- y el rizado que deja tiene la misma terquedad: no desaparece, se reacomoda dentro de la banda a medida que crece .
Sumar taps mejora la aproximación en casi todos lados a la vez, y eso alcanza para que el peor punto de toda la banda baje siempre -medido en los siete saltos de la tabla, sin una sola excepción-. Pero no impide que el reacomodo del rizado pase, en algún salto puntual, justo por encima de la frecuencia que a vos te importa: el borde de banda tuvo la mala suerte de estar ahí cuando el rizado se movió, en el salto de 128 a 256 taps y otra vez en el de 512 a 1024.
Hay otro lugar donde la intuición se rompe, y es más raro todavía. Agregar una ventana de Hamming reduce el rizado en todos los demás puntos de este barrido -a veces diez veces, a veces más-. Con 8 taps, y sólo con 8 taps, lo empeora: sin ventana el error en el borde de banda es y el peor caso de toda la banda es ; con Hamming, esos mismos dos números suben a y -casi un orden de magnitud, en la dirección contraria a la que cualquiera esperaría de una ventana pensada para suavizar-. Con 16 taps ya no pasa: Hamming vuelve a ganar, y gana cada vez más a medida que suben los taps. Con 8 taps hay poco filtro para repartir, y restarle peso justo a los coeficientes de los extremos -que es lo que hace cualquier ventana- sale más caro que dejarlos como estaban.
Volviendo al problema real que abre esta nota -el reloj del receptor, nunca perfectamente alineado con el del transmisor-: diseñar ese filtro no es sólo elegir "muchos taps" y confiar en que el error baja parejo. Si lo que importa es el peor caso sobre toda la banda -el peor símbolo, en cualquier condición-, más taps ayuda siempre. Si lo que importa es un punto fijo -la frecuencia exacta de una portadora, por ejemplo- más taps puede, en algún salto puntual, dejarte peor que antes.