Perfecto, bue, en alguna que otra cosita le pegué bien, je.
Confirmado lo del scan 1/2 en el módulo que a mí me interesa.
Ahora, en cada gabinete hay 25 módulos que deben ser manejados desde el gabinete central. Si son 25 módulos sería como tener una matriz de 2 filas por 384*25=9600 LED. Si hay tres señales de datos (una para los led rojos, otra para los verdes y otra para los azules) cada "cable" debe conducir 9600/3 = 3200 "datos" para llenar un gabinete completo. Si cada "dato" está compuesto por 14bits (en las características dice "Color processing: 14bit, Display color: 4.4 trillion" estaríamos hablando de 3200*14 = 44800 bits para cada frame. En las características del panel dice: Refresh frequency: ≥ 2000Hz, Frame rate: ≥ 60Hz. El Refresh frequency sería la frecuencia del PWM de cada led?
Sí. Esa sería la frecuencia de trabajo del PWM de los LEDs.
en el caso del frame rate de 60Hz nos daría que debemos enviarle 44800bits * 60 1/seg = 2,68Mbps desde la central hacia cada gabinete? o en realidad el doble, ya que primero irían los 44800 bits de una fila y luego los de la otra fila lo que nos daría 5,37Mbps....
Por fila, por color sí 2,68Mbps.
Saqué bien las cuentas? El hecho de que dividan las señales una para cada color aumenta el cableado, pero baja muchísimo el ancho de banda requerido...
Sí. Todos los LEDs sean R,G o B necesitan del mísmo ancho de banda. Entonces asumamos que un panel de 25 módulos de 16 x 16 pixeles R1G1B1 c/u nos da un total de 19200 LEDs por panel. Si ahora sabemos que cada LED tiene 14 bits de resolución de PWM y nos garantizan un mínimo de 60Hz de refresco de imágen, tenemos: 19200 x 14 x 60 bps = 16,128 Mbps total por panel. Si querés saber el tráfico por color, dividimos por 3 = 5,376 Mbps.
El cableado se incrementa levemente, siempre y cuando el controlador que llene los datos este relativamente cerca de las cascadas de drivers de los LEDs. Ese ancho de banda es válido siempre y cuando los drivers puedan generar el PWM por sí mísmos. Sino el ancho de banda requerido se eleva de manera descomunal. Viendo la frecuencia de refresco superior a 2000Hz y los 14bits de profundidad de color que promocionan, debemos asumir que estamos ante drivers que poseen generación propia de grises.
Este diseño requeriría de 3 buses independientes de datos para llenar los módulos. Esto hace que si pensás usar un uC para controlar cada panel, necesites un uC con 3 módulos SPI al menos, ya que hacerlo por software no sé si sería potable debido a la alta frecuencia requerida de cada bus( > 5Mhz). Si usás FPGA claro que cualquier FPGA hasta los más pequeños seguramente puedan cumplir con la tarea sin problema.
Tené en cuenta que si pensás usar LPC1114 como controlador principal, y enviarle los datos mediante un sólo par diferencial, el LPC1114 tiene un baudrate máximo de la UART de 3,125 Mbps. Por lo que estarías muy lejos de lo que necesitás para un panel de este tipo. Los PIC32 aceptan baudrates de hasta 20Mbps si no me equivoco. Todo depende de cómo pienses diseñar el hardware y la división de tareas.
Con respecto a que se ven varias fuentes de alimentación por gabinete, haciendo cuentas rápidas y asumiendo que cada LED consume 20mA máximo, pero trabaja 1/2 del tiempo total, tenemos que el RMS es de 10mA por LED. Si en cada gabinete dijimos que teníamos 16 x 16 x 3 x 25 LEDs = 19200 LEDs, nos da un consumo por gabinete de 192 Amperes. Esto sin tener en cuenta el consumo adicional de los drivers y resto de la electrónica.
Saludos.
