ESP8266/RFM95W node - How long should a send take?


(torntrousers) #1

I’ve been looking at a battery powered node using an ESP8266 and RFM95W, based on this thread. I’ve done ESP8266 IoT sensors before using WiFi and been able to get a few months out of them on a couple of AA batteries so hoped that using LoRa instead of WiFi could extend that a lot.

However it turns out that the time for the node doing a send and getting the TX_COMPLETE event back takes ages, 6 - 10 seconds, so even when using deepSleep for the rest of the time that 10 seconds of up time would drain the batteries quite quickly.

I wondered if it was something i had wrong but doing some searches i see from the logs other people have posted that theirs are slow too, eg here and here and here.

That seems odd., it shouldn’t take so long should it? Poking around in the LMIC code and the SX1276 datasheet it sounded like after a send DIO0 going high would indicate the send is complete so I’ve tried using that to trigger when to put the ESP8266 in deepSleep, and that seems to work, DIO0 goes high about 130 milliseconds after the send and putting the ESP8266 to sleep then the gateway still seems to get the transmission ok.

So great. I have WiFi disabled on the ESP so its using about 14mA when awake, and thats only for 130ms or so, and then deepSleep current is about 17uA the rest of the time, so even with the node publishing as often as once a minute a couple of AA alkalines should last over a year.

I wonder is this a bug in the LMIC code that its not doing the EV_TXCOMPLETE sooner, or perhaps is the SX1276 carrying on finishing the send after i put the ESP to sleep after 130ms? Any ideas?

(I’ve put this code i have for this ESP8266/RFM95W node here)

And here’s a pic of the node asleep:


(Arjan) #2

That doesn’t feel right. But it does depend on the packet size. Like sending a 50 byte packet on SF12 takes 2.8 seconds on SF12. I guess that implies the node starts to listen for a response after 3.8 and 4.8 seconds, but I might have that timing wrong. The TX_COMPLETE would only be triggered after both the first and second Class A receive windows have ended.