Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Estoy haciendo una red inalámbrica de micropics para trasmisión de datos en serie (a base de repetidores) de uno a otro hasta la base. ¿Sabéis algún protocolo en C ya hecho? no vaya a ser que esté reinventando la rueda.
El alcance de uno a otro lo estoy calculando en 400m
Creo se puede hacer algo con el CAN, pero no estoy seguro
Creo que os estais haciendo un lío...
fusion no ha dicho que use paso de testigo en el protocolo, es una idea que le habeis dado, pero el no la usa.
Lo que estaba probando es el sistema para detectar COLISIONES DE PAQUETES usando un checksum y yo le he recomendado que use un CRC.
El checksum es un sistema poco fiable ya que es muy facil que haya COLISIONES (DE HASH). Con el CRC estas COLISIONES DE HASH es muy dificiles que se produzcan: http://es.wikipedia.org/wiki/Funci%C3%B3n_hash " onclick="window.open(this.href);return false;
http://blog.theliel.es/2010/02/seguridad-encriptacion-y-autentificacion-capitulo-primero-hash.html " onclick="window.open(this.href);return false;
O sea, hemos hablado de dos tipos distintos de colisiones, pero sin detallar de que tipo y eso es un poco confuso.
Usando un CRC no va a mejorar las COLISIONES DE PAQUETES pero si mejorará la fiabilidad del sistema que las detecta gracias a que habrá pocas posibilidades de COLISIONES DE HASH (que un paquete de datos emitido y el paquete recibido corrupto tengan el mismo CRC).
"Colisiones de paquetes" es un término de transmisión de datos, "colisiones de hash" es un término de criptografía.
Aclarado Heli, aunque es un poco exagerado el usar terminología criptográfica para indicar la fiabilidad de un código detector de error. En su momento hice varias asignaturas sobre el tema y no recuerdo que lo usase nadie. Además teniendo en cuanta que el problema principal son las colisiones no es conveniente usarlo, aunque por poder ...
Pero volviendo al tema, hay dos factores que interesan, fiabilidad y ancho de banda.
Escenario: Varios emisores que emiten en un mismo medio. Esto implica que se han de utilizar técnicas de multiplexado y control de acceso al medio para evitar el máximo posible las colisiones y maximizar el ancho de banda del canal.
Lo que se envía al canal es una secuencia de bits d[n] ó d[n]+c[n].
Básicamente el enviar al canal la secuencia de datos d[n]+ck[n] ó d[n]+crc[n], manteniendo el mismo escenario (canal, multiplexación, etc) tienen las siguientes ventajas o inconvenientes:
* A mismo número de colisiones, con la secuencia crc[n] se detectarán más colisiones ya que es un código detector de error más fiable.
Si en el canal tenemos por ejemplo un 30% (el autor de los test debería aportar datos, estos son de ejemplo sin validez) de colisiones real es probable que con
ck[n] solo se detecte un 25% debido a un algoritmo de detección de errores poco fiable. En cambio al utilizar crc[n] y ser más robusto se detectarán más errores, con lo que las colisiones medidas serán mayores que con ck[n], es decir se aproximará al 30% real.
* Utilizar crc[n] implica que el ancho de banda efectivo del canal será menor, ya que la secuencia crc[n] es más larga que ck[n].
Resumiendo: mayor número de colisiones detectadas (mayor fiabilidad) y menor ancho de banda efectivo.
Un dato más sobre algo que he leído en los posts anteriores. Si en el escenario simulado se tiene un número determinado de errores (colisiones) en los datos recibidos no es cierto que en el escenario real la situación sea mejor por que estén alejados, esta puede ser mejor o peor dependerá mucho del canal elegido y de la relación señal ruido que tengamos. Hay que tener en cuanta que en el canal hay una componente que es e[n] que no se si se ha incluido en la simulación, esto se debe a que en ese medio no solo están los emisores y receptor, si no que hay otros "emisores" no deseados que introducen ruido en el canal.
La opción de empleo de corrección de errores no la he considerado en primer lugar porque empleo un pic y ya vá cargado, y en segudo lugar pues según mi experiencia cuando viene un ruido afecta a todo un trozo de trama (es como un chirp de varios milisegundos), por lo cual el Hamming no podría corregirlo, eso es mi opinión, prefiero mil veces usar un buen código de detección de CRC como el de Heli (que ya he metido en el código) que solo duplica la cantidad de tiempo ha emplear que si usara el exclusive or. Hay que entender que yo uso el código para trasmitir telemetrías, otra cosa sería si mandara comandos que puedan ser críticos (Aunque se pueden mandar de 5 en 5 y que el receptor pille el primero bueno y rechaze a los otros)
En mi caso la red de sensores solo hablan y no tienen que sincronizar, los repetidores tienen un poco más de tarea
Pongo aquí el código de CRC de 8 bits y el de 16, el de 8 es el de Heli aunque lo he simplificado un poco y lo hago todo de una atacada. El de 16 bits empieza con CRC=0xFFFF para cumplir la norma 🙂 :
byte HallaCRC8_2(byte *u, byte size)
{
byte crc=0x0;
int i,j;
for(j=0; j< size; j++)
{
crc = crc ^ u[j];
for (i=0; i<8; i++)
if (crc & 0x01) crc = (crc>>1) ^ 0x8C;
else crc = crc >> 1;
}
return crc;
}
unsigned __int16 HallaCRC16(unsigned __int16 *u, unsigned __int16 size)
{
unsigned __int16 crc=0xFFFF,i,j;
for(j=0; j< size; j++)
{
crc = crc ^ u[j];
for (i=0; i<16; i++)
if (crc & 0x0001) crc = (crc>>1) ^ 0x8408;
else crc = crc >> 1;
}
return crc;
}
Juanjo dixit: Ya que la única solución (que yo conozco o me han explicado) que hay para evitarlas es utilizar técnicas de multiplexado FDMA, TDMA, CDMA/SSMA y SDMA, es decir multiplexacción en frecuencia, tiempo, código o ensanchado de espectro y espacial. A esto hay que añadir los protocolos de acceso múltiple y los mecanismos de control (que introducen múltiples variantes de las básicas descritas antes).
Joer Juanjo, que uso un transceiver HopeRF que trabaja en FSK y cuesta 25 euros y un pic, no estoy haciendo una red de telefonía inalámbrica, al menos por ahora, gracias por la información
