SerialPlugin does not respond (to Serial2 pins) when device screen goes to sleep

[ry-w]

Describe the bug SerialPlugin does not respond when UI screen goes to sleep / device goes into lower power mode.

To Reproduce Found on TBeam v1.1 RX/TX pins:

define RXD2 35

define TXD2 15

1. Have a setup to talk with the mesh device using the serial pins
2. Enable SerialPlugin
3. Mesh device on battery power (not USB)
4. Set mesh device to low power mode
5. ex.: meshtastic --set-router --port /dev/ttyUSB#
6. Wait until mesh device goes into a lower power mode and turns the display screen off
7. Attempt to send a message through the SerialPlugin

The device will not respond to the serial commands sent to it.

8. To validate, push the middle IO38 button on the mesh device to turn the screen back on
9. Send a serial command again The device responds this time.

Expected behavior SerialPlugin is expected to respond even when the device is in a low-power mode and with the screen off.

As a workaround, a wake-up pin could be assigned to enable the device to read the Serial2 pins.

Device info:

• Device model: TBEAM
• Software Version: 1.1.42

[mc-hamster]

This looks like expected behavior. When the device turns off the display, it goes into light sleep which turns off the CPU.

Work around would be, on the tbeam, to pull GPIO13 low for a moment to wake up the CPU and then access the serial interface.

@ry-w Will try this out tomorrow.

[mc-hamster]

Leaving this open until I get confirmation from @ry-w that the workaround is successful.

[geeksville]

hmm - I wonder if we should just never go to light sleep state (for !is_low_power nodes) when we have USB power connected. Under the theory that: with USB power the current draw of keeping the CPU alive is not a big issue. And in the 'remote serial api' case it is likely the user would have the device hooked to USB power.

On Wed, Feb 10, 2021 at 10:59 AM Jm Casler notifications@github.com wrote:

Leaving this open until I get confirmation from @ry-w https://github.com/ry-w that the workaround is successful.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-device/issues/683#issuecomment-776403864, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2IWL6KM3JKZHEFE7HTS6HZBFANCNFSM4XLUYOGQ .

[mc-hamster]

In his use case, he needs to keep his entire power budget down to a minimum since his solution will run on a (large) battery for an extended period of time.

Other than the display being left on, is what you described the current implementation?

[geeksville]

good point! it is!

On Wed, Feb 10, 2021 at 12:53 PM Jm Casler notifications@github.com wrote:

In his use case, he needs to keep his entire power budget down to a minimum since his solution will run on a (large) battery for an extended period of time.

Other than the display being left on, is what you described the current implementation?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-device/issues/683#issuecomment-776440981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2I5U4OWKHS4S2NSMELS6IGN7ANCNFSM4XLUYOGQ .

[geeksville]

btw: the esp32 has support for "wake on sleep if serial rx is configured that way" - but I think it needs the 32kz crystal that virtually no one installs.

On Wed, Feb 10, 2021 at 1:59 PM Kevin Hester kevinh@geeksville.com wrote:

good point! it is!

On Wed, Feb 10, 2021 at 12:53 PM Jm Casler notifications@github.com wrote:

In his use case, he needs to keep his entire power budget down to a minimum since his solution will run on a (large) battery for an extended period of time.

Other than the display being left on, is what you described the current implementation?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-device/issues/683#issuecomment-776440981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2I5U4OWKHS4S2NSMELS6IGN7ANCNFSM4XLUYOGQ .

[mc-hamster]

I saw that in the docs. My read is it's pretty messy and not reliable for deterministic transmission. It requires sending a number of pulses over the rx pin but doesn't specify the number of pulses. I think internally, it just hopes that toggling the bit a lot will eventually wake up the device by brute forcing the ISR.

I think an elegant solution would be to, eventually, implement CTS/RTS flow control.

Connected device: I am Ready To Send you something. Meshtastic Device: I'll let you know when you're Clear To Send.

I think the logic levels may be inverted based on the edge detection of the Interrupt gates, but that shouldn't be difficult to work around.

[ry-w]

As discussed with @mc-hamster, I've tested using pin 13 (on TBeam) to wake the device. I give a 50ms low pulse, and then wait a bit for the ESP32 to wake. This is adequate for getting things to work, though i'd need another pin from the mesh node to tell if it is really ready to receive over serial. Definitely something like CTS/RTS (or the wake-on-sleep that @geeksville mentioned) would be ideal, but that also complicates the serial usage and pins used on the control side.

I suppose this can be closed noting "adequate workaround found."

[mc-hamster]

@ry-w With that information, I'm going to close this ticket and will update the plugin documentation soonish.

Knowing the timeline for your project, if you're working on a local fork of our main code, another short term solution for you would be to add a line above:

return (10);

... at line 121.

Maybe something like (please excuse the pseudo code):

read state of specified GPIO

if GPIO is on, turn it off

if GPIO is off, turn it On

On your atmega, you would then monitor that GPIO. If the GPIO has a PWM output, the CPU is active. If the expected PWM output is stalled, the CPU is in a sleep mode.