El método de comunicación inalámbrica de trabajo más rápido entre dos dispositivos

Intenté hacer esta pregunta en el foro de ingeniería de redes, pero los mods allí piensan que superuser.com es un mejor lugar para eso, pero cuando publiqué allí, piensan que este es el mejor lugar para este tipo de preguntas. así que aquí va:

Estoy creando un juego en el que varios dispositivos deben comunicarse de forma inalámbrica entre sí mediante el módulo de radio HM-TRP. Las especificaciones para ese módulo se pueden encontrar aquí: http://www.hoperf.de/rf/fsk/HM-TRP.htm . Por ahora, estoy trabajando en la comunicación entre solo dos dispositivos.

Solo para estar seguro, me apegué a la velocidad predeterminada de 9600 bps y configuré ambos módulos HM-TRP para hablar con el procesador a 9600 bps y para hablar con el mundo inalámbrico a 9600 bps.

Actualmente tengo un dispositivo que transmite la secuencia correcta de caracteres a una velocidad relativamente alta con quizás un descanso de 1 microsegundo en el medio. El HM-TRP responde correctamente con una luz roja parpadeante.

Aquí es donde se pone interesante...

En el lado del receptor, cuando no quiero transmitir, parece reconocer la señal remota a través de una luz verde parpadeante; sin embargo, cuando intento recibir datos y luego, un microsegundo después de procesar el byte completo, intento transmitir datos. , noté el HM-TRP solo en modo de transmisión (la luz roja parpadea, pero la luz verde no). Una vez que dejé de transmitir, la luz verde parpadea de nuevo.

Esto me hace pensar que necesito inventar un mejor protocolo para evitar colisiones, pero al mismo tiempo no quiero que la velocidad de comunicación sea demasiado lenta o que el juego se retrase seriamente.

Mis ideas

¿Configuro el módulo HM-TRP?

Una idea con la que no he jugado es configurar el propio módulo HM-TRP para que su velocidad de E/S inalámbrica sea de 115 kbps y la velocidad de E/S de Uart sea de 9600 bps, pero no estoy seguro de si eso funcionará. o si el módulo tuviera un problema con la gestión de datos debido a dos configuraciones de velocidad diferentes dentro del mismo módulo.

¿Aumento los retrasos en valores fijos?

Podría aumentar la demora entre el momento en que se recibe un carácter y el momento en que se transmite un carácter. Si sigo esta opción, ¿cuánto tiempo mínimo debo esperar? ¿Podría esperar el tiempo que tarda un bit en transferirse a la velocidad de 9600 bps?

¿O ir al estilo round-robin?

La opción bastante cruda que podría tener que elegir es darle a cada dispositivo un número único y hacer que se ejecute un temporizador de modo que cuando el temporizador alcance el mismo número que tiene un dispositivo, ese dispositivo pueda transmitir hasta que el temporizador cambie el número.

Entonces, ¿cuál sería la mejor salida aquí en términos de velocidad y poder transmitir/recibir caracteres con éxito?

Para aquellos que preguntan sobre los factores de la señal inalámbrica, todas las pruebas se realizaron con los chips inalámbricos ubicados a menos de 6 pulgadas entre sí, por lo que las probabilidades de interferencia son inferiores al 0,01 %.

EDITAR

Para mayor claridad, agregué un diagrama de una configuración típica que tendré. Cada caja (excepto la computadora real) tendrá un AT89S52 como el corazón de todo el procesamiento. La computadora real se conectará a la estación central para descargar los datos del juego. Los datos se almacenan en la ram extendida de la estación central y se acumulan a medida que las unidades individuales envían y reciben datos desde y hacia ella, de ahí las líneas verde y roja. Sí, sé que esas líneas podrían mejorarse, pero espero ser más claro.

ACTUALIZAR

Probablemente aceptaré la sugerencia de ir por turnos, pero este es el problema. La temporización:

9600 8N1 baud
bit delay = 104.17uS
byte delay = 1041.67uS (Start bit + 8 bits + Stop bit)

Parece bien, pero al final tendré que lidiar con 40 o 50 jugadores. Para simplificar, optaré por 50. Luego, para los datos, decidí secuenciar cada paquete y estampar el número de secuencia en cada mordisco para evitar la corrupción de datos. Aquí hay un ejemplo de datos (convertidos aquí en hexadecimal) que un jugador quiere enviar y asume que el número de jugador es 35h y el jugador remoto es 46h:

30h 63h 75h 12h 94h 82h

Entonces los datos a la línea serial inalámbrica serán:

30h 51h 42h 63h 34h 05h 66h 37h 78h 59h 1Ah 2Bh 9Ch 4Dh 8Eh 2Fh

Lo que hice fue tomar los nibbles (de mayor a menor) del número de jugador local y luego remoto y luego hacer lo mismo con 6 bytes de datos. Podría hacer una suma de comprobación, pero eso significa más trabajo para el procesador y la eliminación de otro byte.

Ahora, si hiciera algunos cálculos aquí, creo que el tiempo de retraso para cada jugador sería:

byte delay = 1041.67uS times 32 bytes (16 for transmit, 16 for receive)
=33.3mS

Luego puede volverse loco por el tiempo de espera ya que cada jugador siempre transmitirá algo cuando sea su turno. Entonces, el tiempo de procesamiento para los 49 jugadores restantes es:

=1631.7mS

Lo que significa que tengo que esperar un segundo para transmitir y recibir 32 bytes de datos.

Tal vez haya un mejor protocolo de datos que pueda implementar para reducir el tiempo total de procesamiento.

En una nota al margen, tengo curiosidad. con 9600 baudios en un 8051 con cristal de 22.1184Mhz, la calculadora de tasa de baudios de Keil sugiere que use 0F4h para un valor de temporizador. pero, ¿estoy en lo cierto al suponer que se necesitan 96 ciclos de reloj para que se procese esa velocidad de micro y cristal para que se procese un byte en serie? o realmente toma 192? Si toma 192, entonces puedo hacer que mi tasa de baudios sea de 19.2K sin perder caracteres.

¿Alguna otra idea de cómo puedo mejorar esto? No quiero que los jugadores esperen 1 segundo para enviar nuevos datos.