El sistema a prueba de bombas es como está ahora y vá bien a pesar de las colisiones, me costaría un h... cambiarlo ahora.
La idea inicial es que el primer aparato vaya preguntando a todos por sus datos, incluso que pudiera programar la potencia RF para ajustar consumos. El protocolo de errores se complicó muchísimo pues había que avisar de los errores en un sentido y en otro y tener en cuenta toda la casuística de errores. Logré que funcionara pues el primer trasmisor mandaba un "trencito de datos" donde cada vagón era el sitio donde iba los datos de cada terminal e incluso lo integré con labview con la consola de errores donde podía ver odos ellos e incluso simular errores (casi me quedo calvo), pero al depurar todas las infinitas variantes de error, posibles colisiones, etc, opté por simplificarlo drásticamente. Ahora uso el mismo código para repetidores y sensores, es unidireccional y me dá la potencia rf de cada receptor y nivel de batería de cada uno cada cierto tiempo :), el problema es un exceso de colisiones pues en este caso necesito una alta tasa de trasmisión, además para ajustar la potencia RF de cada bicho hay que ir donde está instalado y programarlo a mano, pero me ahorro tal cantidad de problemas que lo prefiero de sobra.
Cada emisor/repetidor trasmite cada cierto tiempo que es distinto para cada uno de ellos, por lo que es imposible que coincidan dos de ellos entre sí.
El protocolo simplemente rechaza todos los paquetes erróneos.
Un pequeño problema es que los repetidores y los sensores más cercanos al puesto central están más "privilegiados" que los que pasan por nodos intermedios, es como en un restaurante donde los clientes más cercanos al lugar donde salen los camareros están mejor atendidos

Si no puedes cambiar el protocolo es complicado.

Podrías hacer un slot de tiempos, en que cada sensor tiene un tiempo fijado para enviar los paquetes que tenga acumulados, la sincronización la lleva el 1 y todos se sincronizan con él (si no ves el 1 sincronizas con el que ves que se supone que esta sincronizado con el 1).

Si tienes sensores que no se ven se complica un poco ya que cada paquete debería llevar un número de secuencia y un número de reintentos. Los intermedios reenviarían la info y restarían un reintento el número de secuencia sirve para no reenviar 2 veces el mismo paquete. Cuando el número de reintentos máximo se supera el paquete se elimina.

Ejemplo:
Sensores A, B, C, D, E, todos ven a A excepto B; C y D se ven entre ellos, E y B se ven respecto a ellos.

-> A envía a B

Slot1: A envía el paquete 238 a B con 0 reintentos --> lo reciben C, D, E
Slot2: B no tiene nada que enviar por lo que no hace nada.
Slot3: C envia sus paquetes y el paquete 238 (hacia B) con reintento 1 --> lo recibe D y A
Slot4: D envia sus paquetes y el paquete 238 (hacia B) con reintento 2 --> lo recibe C y A
Slot5: E envia sus paquetes y el paquete 238 (hacia B) con reintento 2 --> lo recibe B y A
Slot6: A no hace nada
Slot7: B ha recibido el paquete 238 y reenvia la respuesta hacia A.

Si en algún momento el paquete llega a 3 reintentos no se envia (máx 3 reintentos).

S2

Ranganok Schahzaman

En mi caso se simplifica pues no hay reintentos, no importa si pierdo una telemetría, pues tengo la siguiente muy poco tiempo después y que no debe ser muy distinta.
El problema que yo tenía es que a cada repetidor le llegaban paquetes que venía de la central por un lado y por el otro le llegan de otros repetidores y/o sensores, había que combinar los errores en ambos sentidos y mandarlos a la central, con posibilidades multiples ¿y si no llegan datos en alguno de los sentidos? ¿como pongo varios sensores mandando a un único repetidor? ¿y si quiero poner dos repetidores redundantes porque tengo problemas de hubicación?
Una de las veces pensé en "aislar" los dos sentidos: un micro recibía por un lado y emitía por el otro (desde la central a los sensores) y en el otro snetido había otro micro mandando desde los sensores hacia la central. Lo que me decidió al cambio drástico de estrategia (eliminar DEL TODO el tráfico desde la central hacia los sensores) fué al comprar las antenas yagui pues ví en las especificaciones que habían lóbulos laterales, o sea, que si un repetidor manda un paquete en un sentido "machaca" a ambos receptores del mismo repetidor, total que habría que poner los sensores trasmitiendo a una frecuencia y cada "nivel" de repetidor a otra frecuencia. Esto no quise hacerlo por dos motivos:
1. Pueden haber solapamientos
2. A lo mejor tengo que pedir autorización, mejor pedirla para una frecuencia que para dos o tres.

Me he dado cuenta que la forma de obtener el checksum puede mejorarse. Normalmente el checksum de un vector v se halla empleando la función exclusive or de la siguiente forma:

typedef unsigned char byte;
void ponechecksum(byte *u)
{
byte checksum=0;
int i;
for (i=0;i<LON1;i++)
{
checksum=checksum^u;
}
u[LON1]=checksum;
}