Editing Apuntes sobre enrutamiento con nrf24l01

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 125: Line 125:
 
** los CH están en escucha todo el tiempo, pero se reservan un slot de tiempo para agregar todos los datos recibidos y enviarlos a la base (o a un super-CH)
 
** los CH están en escucha todo el tiempo, pero se reservan un slot de tiempo para agregar todos los datos recibidos y enviarlos a la base (o a un super-CH)
 
** durante el agregación de los datos se puede eliminar redudancia (es decir comprimir la información)
 
** durante el agregación de los datos se puede eliminar redudancia (es decir comprimir la información)
 +
 +
Adaptaciones posibles para el nrf24l01:
 +
* todos los mensajes de broadcast se pueden enviar a una pipe con dirección común (quitando los ACKs)
 +
* los nodos tendran que identificarse para saber quien es quien. La base podria tener una direccion especial
 +
* si estamos en el escenarios con pipes fijos, cada cluster head no podrá aceptar mas que 5 nodos: o sea a la petición de join de los nodos hojas tiene que seguir una confirmación. Si el CH rechaza la petición del nodo hoja, este nodo tendrá que seguir proponiéndose a otros CH hasta que no encuentre un CH que le acepte. Si no encuentra ninguno disponible y si tiene acceso a la base puede hacerse CH el mismo
 +
* al enviar la confirmacion, el CH puede adjuntar el numero de pipe al cual el nodo puede conectarse
 +
* en este caso de pipes fijos habrá que asociar pipes distintos por cada CH para que no haya interferencia entre nodos
 +
* el TDMA y el CDMA pueden ser opcionales, dependiendo de la cantidad de datos que uno se espera, o se puede implementar uno solo de los dos mecanismos
 +
* una alternativa para el control de acceso múltiple es utilizar distintos canales radio, por ejemplo cada cluster head puede escoger un canal radio que resulte estar mas libre y comunicarlo a los nodos hojas para que lo utilicen (pero el canal de broadcast seguirá siendo el mismo para todos)
 +
* si se asegura que cada nodo hoja se conecte con una cierta frecuencia, aunque no tenga nada que decir, se asegura también la bi-direccionalidad y que se pueda regenerar la red en cualquier momento (por ejemplo si algún nodo se añade de repente o si un CH muere)
 +
 +
Modificaciones necesarias para el caso cluster jerarquico:
 +
* Cada cluster head tiene que estar conectado a otro cluster head, a parte la base.
 +
* Entonces cada cluster head se comporta como nodo hoja a su vez escogiendo su CH con mayor potencia de transmisión.
 +
* Para evitar que los CH se conecten en malla (en el cual caso generarían un loop que no sale nunca a la base) en el mensaje de join al CH habrá que añadir la cadena de nodos que se llevan conectados. Por ejemplo tengo 3 nodos conectados en cadena: n1->n2->n3, cuando n3 se quiere conectar a n4 le envía toda la cadena, n4 acepta pero antes de conectarse a otro CH averigua que no este en la lista, o sea que no sea ni n1, ni n2, n3.
 +
* Un nodo CH siempre aceptara primero los nodos hoja y luego se conectara a otro CH.
 +
* Puede haberse el caso que un nodo CH no encuentra otro CH que le acepte, porque los otros CH estan todos llenos o porque están en una cadena de nodos conectados a el. Es un caso un poco complejo (y poco probable) que se puede resolver de distintas maneras:
 +
** se deshace todo y se empieza desde cero, a través de un mensaje para ello. Dado que las probabilidades de ser CH cambiaran es de esperarse que cambie la topologia.
 +
** el nodo huérfano puede pedir a otro nodo en zona que no sea CH que le haga de CH. Para ello es necesario crear un paquete apósito para que invitar a todos los nodos hoja en la zona a mostrarse. El nodo huérfano podría pedir a la hoja que tenga mas potencia recibida de convertirse en CH. La hoja, recién convertida a CH, seguiria conectada a su CH. En el caso desafortunadisimo en que ninguna hoja quede disponible habrá que rehacerlo todo desde cero.

Please note that all contributions to Wiki Makespace Madrid may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Wiki Makespace Madrid:Copyrights for details). Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to type the two words you see in the box below:

Cancel | Editing help (opens in new window)