Cami Can Calders, 8 2º-2ª | 08173 Sant Cugat del Valles info@bmotes.com 932504996

WhatsBee blog

Midiendo la energía: 25 Tachannnnnnnn!!!

 

Al fin!!,  he resuelto el último problema (conocido).

En el bucle principal del firmware de la PDU vamos leyendo la información de voltajes y corrientes instantáneas para calcular los valores y sus integrales (vamos a llamar a esta parte el integrador). Tenemos que recoger entre 2000 y 3000 valores en el intervalo aproximado de un segundo, el timing de la función es crítico, si se para para hacer algo los valores calculados no serán correctos. Esto hay que hacerlo para cada puerto.

Con una periodicidad definida tenemos que enviar los paquetes con la información al gateway (vamos a llamar a esta parte el enviador).

Constantemente tenemos que monitorizar la radio, para ver si recibe algún paquete con un comando, apagar un relé por ejemplo (a esta parte le llamaremos el escuchador).

Cada una de las tres cosas se van ejecutando a periodicidades definidas en el bucle principal, eso ha generado un problema que no me esperaba. Lo que me esperaba es que si enviaba un comando para desacrivar un relé en el momento en el que estaba funcionando el integrador, este se almacenaría en la caché del puerto serie, en el momento que le tocara el turno al escuchador el paquete sería procesado, el único problema sería la espera de un segundo entre el envío de la orden y el apagado del relé, en el peor de los casos. La realidad es que el paquete se pierde. Puede parecer una «chorrada», se vuelve a enviar y ya está, pero recordemos que la función de esto es trabajar en remoto, y que habitualmente el estado del puerto se cambia en los drivers del gateway (en todos los casos que he visto), con lo que remotamente creeríamos que un puerto está apagado cuando no lo está en realidad.

Siguiendo una secuencia lógica lo que hay que utilizar es una interrupción, una interrupción dispara una función en el firmware en base a un cambio de estado en una entrada (entre otras posibilidades). El primer problema es que no he sido capaz de ver o de configurar una interrupción activada por el puerto serie en un Arduino. A grandes males grandes remedios, como si que podemos activar una interrupción por el puerto digital 2 (la interrupción cero), he conectado el pin RX de la UART al puerto 2 con una resistencia (se ve soldada en la foto) y he habilitado las interrupciones en el puerto 2.

Rework de la PDU

Esto ha sido más complicado de lo que parece, porque en el puerto digital 2 del micro tenía el primer relé, por lo que he tenido que cablearlo al puerto digital 6.

El sketch responde a la interrupción, pero por algún motivo el stack de xbee no funciona dentro de la interrupción (esas cosas pasan, lo de las interrupciones es un poco rarito). Como no lo consigo después de un par de horas de trabajo busco una alternativa.

El inegrador es sensible al tiempo, segmenta la onda senoidal y lo que no puede tener son periodos diferentes, así que añado a ese bucle una comprobación, le digo que si el pin RX se pone en estado básico que abandone inmediatamente ese bucle y se vaya a leer el puerto serie. Si se interrumpe esa lectura no se tiene en cuenta, se espera a recibir el paquete y después se vuelve a leer el mismo puerto. Tal como me imaginaba funciona!!!

Aunque ahora ya soy capaz de recibir todos los paquetes me queda una inquietud, ¿y si pasara algo que hiciera que se perdiera un paquete?, el driver cambiaría el estado y nos seguiría engañando. Traslado el control de la monitorización de los pines al micro. En el momento en el que se cambie el estado de un relé el driver va a enviar el estado «Pendiente», inmediatamente vamos a leer el puerto para confirmar el estado real del mismo. Funciona!!!!

La conclusión, funciona la PDU, sin ningún problema, está integrada con el entorno de Digi y podemos trabajar con los actuadores, la versión beta está acabada.

En el camino como veis el circuito ha sufrido varios cambios:

  • Por error cableamos la entrada de medición de tensión a una puerta digital en lugar de analógica (Solucionado).
  • El condensador electrolítico de filtro de la alimentación estaba infradimensionado (Solucionado),
  • La fuente de alimentación no aguanta una radio Xbee pro y los relés (he puesto una radio no pro y asumo que no voy a desactivar tres relés simultaneamente hasta que resuelva el problema)
  • El puerto serie para la depuración era el mismo que el de la radio (a la derecha de la foto podeis ver una ñapa que lo soluciona)
  • He cableado el puerto digital 2 al 6 para poder añadir la resistencia (No era necesario)

Y todavía quedan las mejoras que enumeramos en un post anterior, alguna mejora del firmware, alguna sencilla del driver, etc. minucias….

Arreglaré cosas un par de días, reharé la placa con un formato que quepa en una PDU de verdad y a otra cosa mariposa.  Al final estoy contento con el resultado 🙂

  • Tenemos una PDU que mide energía, no solo corrientes como algunas del mercado.
  • Tenemos feedback del estado real de los puertos, no una aproximación en el driver que nos puede engañar.
  • Tendremos hasta 8 o 12 puertos.
  • La PDU está perfectamente integrada con la red de Digi.
  • Podremos «features» avanzadas como cortar la corriente en el paso por cero.

2 Comentarios

  1. Tin

    Solo queda felicitarte!!!!

  2. Pingback: bMotes Energy meter V2: Medidor de energía Zigbee compacto con ADE7753 | Zigbee labs

Dejar un comentario