Let’s change the topic away from gateways for a few days. Today I have deceided to finish a wireless infrared presence sensor I started a few days ago.
The sensor is a PIR of a DFRobot which costs around about 7 of your hard earned dollars. The reason for choosing this particular sensor is because it with a voltage between 3 and 5V, and has a consumption of 50µA. This consumption is very important as it will take more than 4 years to drain AAA batteries, assuming of course we’re not using the Zigbee network!
Sensor PIR de DFRobot
Other characteristics of this sensor are:
- Type: Digital
- Supply Voltage:3～5V
- Current:50μA
- Working temperature:0℃～＋70℃
- Output level(HIGH):4V
- Output level(LOW):0.4V
- Detect angle:110 Degree
- Detect distance:7 meters
- Size:28mm×36mm
- Weight:25g
Power
Sleep mode:
Solutions: Make the node send a packet every 15 or 20 seconds with the actual state, this way a detection of presence will last this period of time. However the problem es that the node will be forced to talk every X seconds to detect the presence and this will have a negetive impact on the battery life.
The other option is to wake the radio every time there is a change from either high to low or low to high, as the radio wakes up by putting a low level pin we need something which sends us a pulse when there is a change. Once again we return to the Signal Edge detector; remember the article Motes:9, a vueltas con el detector de flancos?
The fact is that using the components mentioned in this article has been difficult. After doing SW simulations and some HW tests, the design of the positive and negetive flask detectors with a working Xor port, but the capacitors we used shouldn’t be 100nF, but 10nF; with this they should run smoothly up to 50 Hz
The LTC bMotes has a magnetic sensor which should be able to wake up the radio, the bMotesRedButton and the PIR. This seams to be the most effective way to have the nodes which cause the packets to be sent after an action, and which function with a low power consumption.
Vamos a aparcar el tema del gateway por unos días, aunque nuestra hoja de ruta va un poco en otra dirección hoy he decidido tomarme un descanso y acabar un sensor de presencia por infrarrojos inalámbrico que monté hace unos días.
El sensor es un PIR de DFRobot, con un coste aproximado de 7$, el motivo de elegir este y no otro es que funciona con una tensión de 3 a 5V y tiene un consumo de 50uA, el consumo es especialmente importante, con 50uA unas pilas AAA nos durarán más de 4 años (en el caso hipotético de que no utilizáramos la red Zigbee).
Sensor PIR de DFRobot
Otras caracterísicas de este sensor son:
- Type: Digital
- Supply Voltage:3～5V
- Current:50μA
- Working temperature:0℃～＋70℃
- Output level(HIGH):4V
- Output level(LOW):0.4V
- Detect angle:110 Degree
- Detect distance:7 meters
- Size:28mm×36mm
- Weight:25g
El sensor tiene una salida digital a nivel alto, después de alimentarse escanea durante dos segundos y detecta, poniendo la señal a nivel bajo, los movimientos en su área de influencia, tiene un regulador de sensibilidad.
Hasta aquí todo es sencillo, la salida del sensor se conecta a una entrada digital del Xbee, se configura la radio y ya está, funcionando sin mayores problemas con el gateway y con e resto de HW que hemos hecho, aún así, como lo que queremos es hacer un sensor a baterías tenemos un par de retos a resolver.
Alimentación:
Realmente el sensor tiene dificultades en el momento en el que la tensión de alimentación baja de los 3V, nuestros nodos se alimentan con baterías sin ningún tipo de regulación, y funcionan hasta con una tensión de 2,1V. En el mejor de los casos (baterías completamente cargadas) se van a alimentar a 3V, pero es más que normal que la tensión esté por debajo. Podríamos poner tres pilas, pero la tensión de carga completa 4,5V estaría por encima de los límites de alimentación de la radio, poner un regulador es un problema, por una cuestión de rendimiento energético, de complejidad del circuito, etc. la solución sencilla es alimentar el nodo con tres baterías con una toma intermedia, la radio recibe la tensión de dos y el sensor de tres, resolvemos los diferentes requerimientos de tensión, no intrducimos complejidad en el circuito y todo funciona.
Modos Sleep:
Este es el segundo reto a resolver, con el nodo permanentemente despierto podríamos detectar el cambio en la entrada y enviar un paquete a la red Zigbee advirtiendo de la detección de forma inmediata, pero pretendemos que la radio duerma la mayoría del tiempo. Podemos despertar a la radio poniendo una patita a nivel bajo (conectando la pata de sleep a la salida del sensor), de esta forma cada vez que el sensor detecte algo la radio despertará y enviará un paquete a la red. Esta forma de hacerlo tiene un problema, sabemos cuando el sensor detecta presencia, pero no sabemos cuando deja de detectarla. El el momento en el que la salida del sensor se pone a nivel bajo se despierta envia el paquete y se duerme, pero cuando se vuelve a poner a nivel alto, no se despierta, el GW o el SW pueden creer que se está detectando presencia indefinidamente.
Soluciones: Hacer que el nodo mande un paquete cada 15 o 20 segundos con el estado real, de esta forma una detección de presencia durará este periodo, el problema es que el nodo se verá forzado a hablar cada X segundos detecte presencia o no con la consiguiente reducción de tiempo en la vida de la batería.
La opción alternativa es despertar a la radio siempre que haya un cambio, sea de alto a bajo o de bajo a alto, como la radio se despierta poniendo un pin a nivel bajo nos hace falta algo que nos envíe un pulso cuando haya un cambio, de nuevo volvemos al detector de flancos ¿os acordais del tema en el artículo Motes:9, a vueltas con el detector de flancos?
El caso es que utilizando los componentes del artículo he tenido dificultades, después de hacer unas simulaciones por SW y unas pruebas con HW el diseño del detector de flancos positivos y negativos con una puerta Xor funciona, pero los condensadores utilizados no deben de ser de 100nF, sino de 10nF, con esos valores funciona sin problemas a frecuencias de hasta 50 Hz.
Este es un tema absolutamente recurrente, el bMotes LTC tiene un sensor magnético que debe de ser capaz de despertar a la radio, el bMotesRedButton también, el PIR también, en definitiva, esta parece la forma más eficaz de tener nodos que tengan que provocar el envío de paquetes tras una acción y que funcionen a baterías con un consumo mínimo.