¿Cómo evitar que una MCU funcione constantemente cuando un receptor de radio superheterodino no recibe nada y posiblemente entre en modo de suspensión profunda?

TL; DR : ¿Cómo evitar que un ATtiny se ejecute constantemente cuando el receptor de radio no recibe nada y posiblemente ingrese en modo de suspensión profunda? Configuración:

Contexto: ahora tengo un diseño de transmisor en funcionamiento basado en un ATtiny45, un botón pulsador, un transmisor de radio superheterodino y baterías. Al usar "interrupciones de cambio de pin", puedo hacer que el ATtiny esté en "sueño profundo" hasta que se presione el botón. Cuando esto sucede, el ATtiny se despierta y se envían algunos bytes por radio con codificación Manchester (utilizando esta biblioteca Manchester ). Debido al sueño profundo, el consumo es de ~ 0,2 uA cuando no pasa nada. ¡Entonces las baterías teóricamente podrían durar años!

Ahora estoy diseñando la parte del receptor , con un código como este:

#include "Manchester.h"

void setup() {
    pinMode(3, INPUT);
    man.setupReceive(3, MAN_1200);
    man.beginReceive();
}

void loop()
{
    if (man.receiveComplete()) 
    {
        uint8_t m = man.getMessage();
        man.beginReceive();
        if (m == 222)
        { 
            // do something
        }
    }
}

Para reducir el consumo de energía, también estaba pensando en el sueño profundo y las interrupciones de cambio de pin, pero no creo que funcione aquí porque un receptor de radio tendrá ruido muy a menudo como 0100010010111010010 hasta un byte real, codificado en Manchester , llega...

Pregunta: ¿hay trucos para hacer un código de receptor de radio que use muy poca energía (y posiblemente duerma hasta que llegue un byte)?

Un receptor superhet no inventará la señal en el mismo grado, pero aún tiene el problema de la potencia consumida por el propio receptor. Los enlaces de radio que no tienen un extremo alimentado por la red generalmente necesitan esfuerzos cuidadosos para establecer un cronograma de citas de registro y sufren una latencia en la que es posible que no se pueda enviar un mensaje hasta la próxima oportunidad programada.
Espero que esté apagando todo el circuito del transmisor mientras su microcontrolador de transmisión duerme.
Verificaré esto @MarcusMüller pero IIRC la corriente estaba por debajo de 1 uA mientras dormía (lado del transmisor).
si ese 1 µA incluye el transmisor y no solo el microcontrolador, definitivamente lo hiciste.

Respuestas (1)

Un receptor superhet no inventará la señal en el mismo grado, pero aún tiene el problema de la potencia consumida por el propio receptor. Los enlaces de radio que no tienen un extremo alimentado por la red generalmente necesitan esfuerzos cuidadosos para establecer un cronograma de citas de registro y sufren una latencia en la que es posible que no se pueda enviar un mensaje hasta la próxima oportunidad programada.

Este no es un problema que tenga una solución general, sino solo una variedad de formas en que la tarea se puede reducir a algo que se pueda resolver, como la red eléctrica, los horarios o los rangos lo suficientemente cortos como para que funcionen los receptores pasivos.

Gracias por su respuesta. ¿Cuáles podrían ser las soluciones potenciales que vale la pena probar?
Lo sentimos, pero esto es realmente "demasiado amplio" para pertenecer aquí; como se explicó, no hay solución a menos que encuentre una manera de restringir el problema a uno que sea más fácil. Normalmente, en tal caso, solo comentaría, pero en un comentario ahora eliminado, solicitó que ese comentario se reformulara como una respuesta.
¿Cómo evitar que una MCU funcione constantemente cuando un receptor de radio superheterodino no recibe nada y posiblemente entre en modo de suspensión profunda?
RespuestasAquíPolítica de privacidad1y, 0v