Conteo y almacenamiento de pulsos de Arduino

Una solución viable al 99% probablemente se encuentre en algún lugar entre los absolutos. Por ejemplo:

Podrías transmitir un conteo incremental. El receptor puede perder algunas transmisiones siempre y cuando reciba una posterior. Si obtiene una transmisión posterior que se reinicia desde (casi) cero, puede asumir que el transmisor ha sido ciclado y que puede agregar el conteo recibido históricamente al nuevo. Puede medir la duración del tiempo de cualquier brecha y estimar el número de cuentas faltantes durante la pérdida de potencia en función de la tasa antes de la pérdida o de un período pasado que posiblemente sea similar (es decir, a la misma hora del mismo día en las últimas semanas) , o desde hace unas semanas, hace un año, etc). Esto puede funcionar incluso mejor si realiza la corrección después del hecho para igualar el consumo durante períodos más prolongados (es decir, una interrupción del servicio de varias horas, fije el total del día para que coincida con días similares, en lugar de la hora para que coincida con horas similares). También considere que el hecho de un corte de energía puede alterar el comportamiento y, por lo tanto, el uso de gas / agua.

Puede almacenar periódicamente el valor de conteo en la EEPROM; si lo hace en números redondos, puede hacerlo utilizando relativamente pocos bits, ya que solo necesitaría los significativos. En el ciclo de alimentación, puede reiniciar el conteo en el último número guardado. El receptor vería que el conteo se reanudaría en un número ligeramente menor que antes, y podría agregar la diferencia nuevamente a los números recibidos.

Como la mayoría de los cortes de energía son breves (aparte de algunas excepciones recientes) puede usar una batería de respaldo.

Si los medidores tienen una pantalla, podría adoptar un enfoque completamente diferente, apuntar una cámara hacia ellos y usar el reconocimiento óptico de caracteres en las imágenes.

Ningún sistema es perfecto; en casos extremos, puede ser necesaria una corrección manual inteligente.

Consumo de agua en kWh ???

La frecuencia de transmisión de sus datos dependerá de la frecuencia de pulsos y de qué tan actualizada esté su información. No tiene mucho sentido enviar una actualización cada hora si obtiene en promedio solo 1 pulso por hora. En ese caso una vez todos los días lo haremos. Podría enviar cada vez que haya contado, por ejemplo, 10 pulsos, pero luego no enviará nada si está ausente durante una semana, y es posible que el receptor desee actualizaciones más frecuentes. Por lo tanto, una mejor alternativa es enviar a intervalos de tiempo fijos, como todos los días al mediodía y a la medianoche.

Para la confiabilidad de la transferencia de datos, tiene varias opciones. Los módulos de radio RFM12B son transceptores, por lo que puede dejar que el receptor envíe un acuse de recibo. No es exactamente complicado, pero puede ser aún más simple, con comunicación unidireccional. La palabra es redundancia. Montones. A menudo es una mala palabra, pero aquí nuestro volumen de datos es tan bajo que una redundancia no hará ningún daño; apenas valdría la pena encender el transmisor para enviar dos bytes, ¿verdad?

No es una buena idea enviar 5 copias de los mismos datos en la misma transmisión. La redundancia es inútil si la transmisión completa se atasca. Esto es lo que hace: la transmisión N-th envía lo siguiente:

• el valor del contador N (1 byte será suficiente) • los datos del N-4 th
• los datos del N-3 th
• los nd datos n-2
• los datos de la N-1
• los nuevos datos
• Hamming ECC

Enviaría datos acumulativos, por ejemplo, números de 16 bits. Si tiene un pulso por 0.1 m \ $ ^ 3 \ $ de agua, tendrá un desbordamiento después de un par de años, pero el receptor no debería tener ningún problema con eso.

Eso le dará una carga útil de solo unas pocas docenas de bytes, pero asegúrese de que todos los datos se reciban incluso cuando se pierden 4 transmisiones consecutivas. Si te hace dormir mejor, aún puedes combinar esto con un reconocimiento y una nueva transmisión si es necesario.

El microcontrolador no tendrá casi nada que hacer: mantener un temporizador para mantener el tiempo hasta la próxima transmisión, y contar los pulsos entrantes. Puede ejecutarlo en un cristal barato de 32.768 kHz. Incluso sin usar los modos de bajo consumo, un MSP430F1101A solo usará un par despreciable de µA; su fuente de alimentación consumirá un múltiplo de eso. Solo encienda el transmisor dos veces al día para enviar sus datos.

Su microcontrolador tendrá que funcionar continuamente durante meses, y luego tendrá que tomar en cuenta los cortes de energía. Donde vivo son raros; el último data de hace 3 años y duró 15 minutos, pero me han dicho que son más frecuentes en las áreas rurales de los EE. UU., donde hay muchas líneas eléctricas aéreas. De todos modos, desea una batería de respaldo para mantener el controlador en funcionamiento durante un apagón. Una celda CR2032 y una MSP430 son suficientes para la eternidad. O la salida de la batería con la fuente de alimentación principal (3.3V) con un par de diodos. Posponga las transmisiones cuando se ejecuta con energía de la batería.

No hay necesidad de almacenar los contadores en EEPROM, simplemente manténgalos en la RAM.