ESP32 WOR in Deep Sleep

[Federico]

Salve, è possibile con la sua libreria utilizzare il deep sleep invece che il light sleep con il modulo lora in WOR?

Ho provato ad utilizzare il deep sleep su un esp32 modificando l’esempio per il WOR della sua libreria, ma al momento non riesco a svegliare il tutto dopo che entra in deep sleep.

Grazie in anticipo.

Federico.

[Renzo Mischianti]

Ciao Federico,
ho finito di scrivere un articolo proprio sull’argomento, ho ordinato gli shield per il DOIT
ESP32 DEK KIT v1 e il LOLIN32, appena mi arrivano pubblico l’articolo con tutte le informazioni.

Allora, per prima cosa devi controllare che i pin siano RTC, ma soprattutto devi impostare la presevazione dello stato dei pin, altrimenti i flag M0 e M1 perdono lo stato come spiegato qui

ESP32 risparmio energetico pratico: preservare lo stato dei gpio, risveglio esterno e ULP – 5

Qui ti incollo una porzione del codice che ho usato con gli e22

    e22ttl.begin();

    esp_sleep_wakeup_cause_t wakeup_reason;

    wakeup_reason = esp_sleep_get_wakeup_cause();

    if (ESP_SLEEP_WAKEUP_EXT0 == wakeup_reason) {
    	Serial.println("Waked up from external GPIO!");

    	gpio_hold_dis(GPIO_NUM_21);
    	gpio_hold_dis(GPIO_NUM_19);

    	gpio_deep_sleep_hold_dis();

        e22ttl.setMode(MODE_0_NORMAL);

    	delay(1000);

        e22ttl.sendFixedMessage(0, DESTINATION_ADDL, 23, "We have waked up from message, but we can't read It!");
    }else{
		e22ttl.setMode(MODE_1_WOR);

		delay(1000);
		Serial.println();
		Serial.println("Start sleep!");
		delay(100);

		if (ESP_OK == gpio_hold_en(GPIO_NUM_21)){
			Serial.println("HOLD 21");
		}else{
			Serial.println("NO HOLD 21");
		}
		if (ESP_OK == gpio_hold_en(GPIO_NUM_19)){
				Serial.println("HOLD 19");
			}else{
				Serial.println("NO HOLD 19");
			}

		esp_sleep_enable_ext0_wakeup(GPIO_NUM_15,LOW);

		gpio_deep_sleep_hold_en();
		//Go to sleep now
		Serial.println("Going to sleep now");
		esp_deep_sleep_start();

		delay(1);

ma ricorda che puoi svegliare dal deep sleep, ma il device si riavvia e così non riesci a leggere il messaggio, perciò ti consiglio di usare un messaggio per svegliare ed uno successivo con le informazioni.

Se hai altri dubbi scrivi pure.

Ciao Renzo

[Federico]

Ciao, grazie mille per la risposta velocissima, non avevo pensato al fatto che in deep sleep lo stato dei pin non veniva preservato.

Grazie anche per la porzione di codice, molto utile.

Federico.

[Renzo Mischianti]

Heheheh.. sono problemi già affrontati con il logic analyzer e tutto il resto..
Ciao Renzo

[alexzupo]

Ciao Renzo,
ho due domande:

1) Non capisco perchè una volta che l’ESP32 viene riavviato dal pin AUX del modulo LORA , il uC ESP32 non può essere in grado di leggere il messaggio che il modulo LORA ha bufferizzato in memoria e dunque l’ESP32 ha tutto il tempo di riavviarsi , interrogare il modulo e leggere il messaggio ricevuto.

2) Nella piccola porzione di codice che hai postato non comprendo il significato della variabile “ESP_OK” …. e la relativa condizione che hai inserito.

Ti ringrazio anticipatamente.

[Renzo Mischianti]

Buondì,
in realtà avevo rilevato che al “risveglio” perde l’hold dei pin e il buffer se ne va, inoltre al begin della Serial faccio anche i vari set dello stato dell’E32, sarebbe utile fare una prova di read sulla seriale bypassando la libreria e l’inizializzazione dei pin.

La funzione torna ESP_OK se c’è fattibilità dell’hold.
Ciao Renzo

[alexzupo]

Ciao Renzo,

ho fatto in modo di impostare l’hold dei pin , con oscilloscopio alla mano , nella transizione da stato normale a deep sleep , tutti i pin collegati al modulo LoraWan non cambiano di stato. Ho anche implementato la condizione per la quale non effettuo nessuna configurazione del modulo Lorawan al risveglio del uC da deepsleep , mentre se è una condizione di reset normale effettuo regolarmente la configurazione. Ciò nonostante il buffer del modulo lora quando il uC si risveglia in seguito alla ricezione in un pacchetto in modalità WOR è vuoto.

Mi potresti spiegare come funziona la lettura del buffer lorawan?? Cioè , vorrei capire, è il modulo lorawan che memorizza in maniera autonoma il pacchetto dati ricevuto e quando viene interrogato via seriale restituisce il pacchetto che ha in pancia?? Oppure quando è attiva la modalità WOR , il modulo in automatico dopo il ritardo WOR trasmette via seriale i dati verso il uC??

Poichè nella seconda ipotesi mi spiegherei perchè il uC quando si sveglia ed interroga il buffer lora (tramite la tua libreria) ritorna 0. Perchè ipotizzando che il modulo lora trasmette subito i dati seriali , il uC ovviamente se li perde poichè sta ancora dormento.

Per maggior chiarezza ti giro il Fw.

P.S: Per far funzionare tutto correttamente ho comunque dovuto inserire l’attributo “RTC_DATA_ATTR” alle tue variabili di libreria altrimenti al riavvio dal deep sleep , quando si eseguiva l’istruzione di interrogazione del buffer lora, il uC andava in crash generando un errore al quanto bislacco “Guru Meditations error” , ho risolto dichiarando le tue variabili come segue:

RTC_DATA_ATTR Configuration configuration;
RTC_DATA_ATTR ResponseStructContainer LoraWan_Config;
RTC_DATA_ATTR ResponseStatus rs;
RTC_DATA_ATTR LoRa_E220 LoraWan(&Serial2, 13, 18, 19); // Serial AUX M0 M1

[Renzo Mischianti]

Ciao Alexzupo,
Penso che prima di tutto devi fare una wake simile a questa this example

in particolare questa parte

 esp_sleep_wakeup_cause_t wakeup_reason;
 
    wakeup_reason = esp_sleep_get_wakeup_cause();
 
    if (ESP_SLEEP_WAKEUP_EXT0 == wakeup_reason) {
        Serial.println("Waked up from external GPIO!");
 
        gpio_hold_dis(GPIO_NUM_21);
        gpio_hold_dis(GPIO_NUM_19);
 
        gpio_deep_sleep_hold_dis();
 
        e32ttl.setMode(MODE_0_NORMAL);
 
        delay(1000);
 
        e32ttl.sendFixedMessage(0, DESTINATION_ADDL, 23, "We have waked up from message, but we can't read It!");
    }else{
        e32ttl.setMode(MODE_2_POWER_SAVING);
 
        delay(1000);
        Serial.println();
        Serial.println("Start sleep!");
        delay(100);
 
        if (ESP_OK == gpio_hold_en(GPIO_NUM_21)){
            Serial.println("HOLD 21");
        }else{
            Serial.println("NO HOLD 21");
        }
        if (ESP_OK == gpio_hold_en(GPIO_NUM_19)){
                Serial.println("HOLD 19");
            }else{
                Serial.println("NO HOLD 19");
            }
 
        esp_sleep_enable_ext0_wakeup(GPIO_NUM_15,LOW);
 
        gpio_deep_sleep_hold_en();
        //Go to sleep now
        Serial.println("Going to sleep now");
        esp_deep_sleep_start();
 
        delay(1);
    }
//  e32ttl.setMode(MODE_0_NORMAL);
//  delay(1000);
    Serial.println();
    Serial.println("Wake and start listening!");

rimuovi anche e32ttl.begin(); ed inseriscilo solo sull’else

e prova a leggere il buffer nell’if

    if (ESP_SLEEP_WAKEUP_EXT0 == wakeup_reason) {
        Serial.println("Waked up from external GPIO!");
 
        gpio_hold_dis(GPIO_NUM_21);
        gpio_hold_dis(GPIO_NUM_19);
 
        gpio_deep_sleep_hold_dis();
 
        e32ttl.setMode(MODE_0_NORMAL);
 
        delay(1000);
 
        e32ttl.sendFixedMessage(0, DESTINATION_ADDL, 23, "We have waked up from message, but we can't read It!");
    }

senza I vari hold_dis, leggi il buffer dell’UART direttamente
se trovo del tempo lo testo anche io in maniera autonoma.

Bye Renzo

[alexzupo]

Ciao Renzo,
purtroppo non era un problema derivante dallo stato logico dei pin M0 e M1 al risveglio.

Il problema (molto più semplice) risiede semplicemente sul fatto che il uC dal momento che si sveglia passano 53mS prima che effettui la prima operazione.

Mentre il modulo Lorawan (in modalità WOR) alla ricezione del pacchetto , abbassa il segnale AUX e dopo 2mS invia i dati via seriale. il uC siccome non si è ancora svegliato, dunque , si perde totalmente la ricezione del pacchetto seriale.

P.S: Il tempo 53mS l’ho calcolato con oscilloscopio alla mano e con un Fw base in cui gestisco solo il deepSleep. Ho eliminato qualsiasi libreria o altro che possa concorrere a far perdere tempo all’inizializzazione.

[Renzo Mischianti]

In teoria però, fino alla lettura, il messaggio rimane all’interno del buffer dell’E32.

[alexzupo]

Eh no, in quanto il uC dopo 53 mS attiva il modulo di ricezione seriale interno. Quindi prima di quel tempo la seriale è completamente disattivata. Aggiungo che anche durante il deepsleep la seriale non accumula dati nel buffer.

[Renzo Mischianti]

Ma è l’e32 che ha un buffer di ricezione che è autonomo rispetto al microcontrollore.
Ciao Renzo

[alexzupo]

infatti, in modalità deepsleep però, purtoppo il buffer seriale è spento.

[Renzo Mischianti]

Buondì,
no no, mi sono spiegato male.
I LoRa EByte E32 hanno un buffer proprio a prescindere da quello dell’esp32, in pratica possono memorizzare 256byte di dati senza intervento del microcontrollore, per poi essere disponibili alla prima lettura, in pratica è una coda FIFO.
Secondo me può essere che quando inizializzo la seriale dell’arduino svuoto la seriale dell’e32.
Ciao RM

[alexzupo]

Non comprendo una cosa.
Quando il uc è in modalità sleep , il modulo E220 è in modalità WOR. Ho notato con l’oscilloscopio che appena arriva un pacchetto il modulo E220 , abbassa la linea di AUX e trasmette via seriale dei dati….che suppongo siano quelli che ha ricevuto. Oppure no??

[Renzo Mischianti]

Si, ma in teoria dovrebbe trasmettere e svuotare solo alla lettura.
Ma non ho fatto test mirati potrei tranquillamente sbagliarmi.
Ciao Renzo

[Autore]

Post