Edit2: un FPGA es una manera obvia de ir. Sin embargo, puede haber una manera relativamente barata de implementar un FFT rápido en software con hardware estándar usando una Raspberry-Pi.
ACELERANDO LOS TRANSFORMOS DE FOURIER UTILIZANDO LA GPU describe el uso de la GPU en Raspberry- Pi para hacer FFTs.
Cita:
"GPU_FFT es una biblioteca FFT para la Raspberry Pi que explota el hardware BCM2835 SoC V3D para ofrecer diez veces el rendimiento que es posible en el ARM de 700 MHz ."
Eso debería ser lo suficientemente rápido.
Cita:
"La biblioteca se ejecuta en hardware 3D dedicado en el SoC BCM2835, y la comunicación entre ARM y GPU agrega 100µs de latencia, que es mucho más larga que la transformación más corta para calcular !"
Por lo tanto, podría estar disponible, ser asequible, listo para escribir y probado, y un martillo lo suficientemente grande como para justificar la investigación. Habrá problemas con el jitter, ya que la CPU todavía ejecuta Linux, aunque ejecutar el código en la GPU (¿quizás sin cabeza?) Debería reducir mucho el problema. No sé cómo ejecutar R-Pi con un sistema operativo 'en tiempo real'.
Editar: {
Una GPGPU, programada en, por ejemplo, CUDA o OpenCL, es lo suficientemente rápido para hacer la correlación, especialmente utilizando FFT.
Editar: la latencia del host a la GPU, es decir, obtener datos dentro y fuera fue rápido, sigue siendo un problema, pero se ha mejorado significativamente. 1 ms parece ser viable, incluida la latencia de ida y vuelta. Sin embargo, se necesitarían algunos experimentos para que la GPGPU funcione. Eso no es trivial si no está familiarizado con las técnicas de programación.
Supongo que una solución alojada en una PC no está dentro de su alcance, ya que una PC de varios núcleos promedio debería poder "destruir todo esto".
} finalizar edición.
Sin embargo, una forma de obtener algo que podría hacer todo del procesamiento en software podría ser una Parallella .
Por ejemplo, RS los vende .
Tiene un tejido FPGA Xilinx Zynq y dos ARM-A9 a 800 MHz.
Lo más relevante es su Epiphany 16-core, 800MHz / core, RISC, 'Matriz de procesadores'. Los procesadores Epiphany son totalmente autónomos (no como una GPU), cada uno con su propio programa. Sin embargo, tiene un tejido de interconexión rápido que les permite comunicarse muy rápidamente, por lo que la señal podría fluir a través de ellos.
Debe haber suficiente memoria en la matriz del procesador Epiphany para resolver el problema con un buen grado de paralelismo.
La epifanía está programada en C.
Se trata de una Epifanía de menor costo con un Zynq de puerta inferior. Tiene todo su FPGA comprometido a hacer que el tablero funcione, especialmente la interfaz con Epiphany. Así que esa junta podría ser suficiente para resolver este problema específico.
Es una placa de código abierto, con una comunidad activa, por lo que puede haber habido suficiente actividad para proporcionar una manera de "verter" los datos en Epiphany utilizando el FPGA sin pirateo de VHDL.
Aunque no es relevante para su situación, la placa más cara proporciona un importante tejido FPGA no comprometido, lo que permite a los usuarios explotar el rendimiento de un FPGA, lo que puede ser importante en el caso general.
Nota al margen:
Demodulación y decodificación GPS demodula la señal del satélite utilizando códigos Gold. Tal vez haya habido chips disponibles para ayudar a hacer eso usando alguna forma de correlación, y eso es lo que estás recordando?