[Bug]: T-Echo - blue LED between GPS and LoRa module stays on when powered off

[ajorg]

Category

Other

Hardware

T-Echo

Firmware Version

1.2.65.0adc5ce

Description

When powered off (deep sleep) the blue LED between the LoRa module and the GPS module sometimes stays on.

Pictured below with a blue arrow drawn to point to it:

Relevant log output

No response

[garthvh]

Likely has an AXP power management chip like the tbeam, which also has this issue

[garthvh]

Same issue likely #1272

[caveman99]

the LED is controlled directly from the MCU. No AXP on that board. Fix pending...

[surlyhacker]

This issue still happens to me using a T-Echo with v1.3.24.dff6915. After shutting down (sleeping) by holding the bottom button, the internal blue LED is still illuminated seemingly indefinitely. Display says "Sleeping" in upper left.

[kokroo]

the LED is controlled directly from the MCU. No AXP on that board. Fix pending...
@caveman99
I downloaded the latest v1.3.25.85f46d3, but it's still not fixed for the T-Echo. Am I doing something wrong here?

[garthvh]

Are these the right pins for a techo? https://github.com/meshtastic/Meshtastic-device/blob/master/variants/t-echo/variant.h

[surlyhacker]

@garthvh

Are these the right pins for a techo? https://github.com/meshtastic/Meshtastic-device/blob/master/variants/t-echo/variant.h

#define PIN_LED1 (0 + 14) // 13 red (confirmed on 1.0 board)
#define PIN_LED2 (0 + 15) // 14 blue 
#define PIN_LED3 (0 + 13) // 15 green 

Well their own image shows:

So wouldn't those be:
Red -> (32 + 3)
Green -> (32 + 1)
Blue -> (0 + 14)

Or am I confused about something?
And I'm not sure why the numbers in comments in variant.h don't match the numbers in the actual code on those lines.

Edit: Side note: And are there really only 3 single-color LEDs in this thing (on the front)? I see two holes/spots on the front and I swear that each can show more than one color. (for example the left hole has emitted both blue and red light at times) Plus, how do those 2 spots map to 3 LEDs? Light pipes? But I asked Lilygo and they told me that there are really only 3 single color LEDs. Don't quite get it. Also this side note is totally unrelated to the internal blue LED that we're talking about, I guess. And I don't know if their pinout diagram "Blue" is referring to the external one or internal one. There are definitely 2 separate LEDs in this thing that can be blue and one is internal and one external, so clearly one is missing from their pinout.

[ajorg]

I think that image is about the tri-color LED, which is not the one I (at least) am seeing on here.

[surlyhacker]

I think that image is about the tri-color LED, which is not the one I (at least) am seeing on here.

Ya see my added note at the end above about that. But is there only one tri-color LED? So confused.

[surlyhacker]

The schematic shows an LED6 connected to the 1PPS pin of the GPS chip (L76K):

Could that be the one?

Chip datasheet says: "The 1PPS output generates one pulse per second periodic signal synchronized with a GNSS time grid
with intervals configurable over a wide range of frequencies"

When the device is on, the left front LED flashes blue once per second. But I assume that's a separate LED than LED6, since it can also be steady blue, and I've seen it be red, and the front LED being on does not (always) coincide with the internal LED in question being on.

Almost seems that when the GPS chip goes into standby/backup (low power) mode, that pin (1PPS) goes into an indeterminate state that ends up giving a bit of power to that LED6. The datasheet (Table 5) says the pin is not operational during those modes.

[surlyhacker]

LilyGo has now confirmed (although they changed their response a few times) that the blue LED that we are referring to here (inside the case) is the LED6 from the schematic in my earlier comment and they say it is not programmable (which makes sense given how it is wired). They claim that if PWR_EN is disabled, then this light will go off. PWR_EN is pin AD8 on the NRF8420, tied to GPIO P0.13. And the schematic shows it connected to the EN (Enable) pin of the AP2112K-3.3V(RT9013) regulator. So I take it that PWR_EN basically controls 3.3V power to the L76K through this regulator.

But I don't quite follow the Meshtastic code that is relevant to this pin (PWR_EN aka P0.13) since I don't see it ever being used except where it appears to be referred to in variant.h as PIN_LED3 and LED_RED and then only used in initVariant() where it is turned off. It may just be that Meshtastic is only using the L76K standby mode via the WAKE_UP pin (GPIO P1.02 and PIN_GPS_WAKE in variant.h) and never explicitly controls PWR_EN, but in that case I don't fully understand why this LED would be on (but seems a bit dim) during standby and off during regular (aka "Continuous") mode GPS operation. It should blink once per second during Continuous mode, but the front blue LED is the one that seems to may do that. Confused.

[caveman99]

we enable PIN_EINK_PWR_ON (0.12) early, which is misnamed as it provides power to quite a few more things than the EINK. Apart from that i never saw a need in thise device to switch things on. The GPS chip will work without that.

[caveman99]

there's code in ButtonThread.h and shutdown.h that essentially does the following:

                ledOff(PIN_LED1);
                ledOff(PIN_LED2);

Maybe it's just as easy as add the OFF command for LED3 there?

[surlyhacker]

@caveman99 Thanks for the reply. Can you re-open this issue?
I haven't fully figured out the relationship between PIN_EINK_PWR_ON and the internal blue led yet (still looking at schematic). Maybe you were saying that PIN_EINK_PWR_ON seems to be sufficient to activate the GPS even without explicitly enabling PWR_EN (aka P0.13)?

I think for this internal blue LED, yes perhaps adding a call when shutting down to disable PWR_EN aka P0.13 aka PIN_LED3 and thus cut power to the GPS, it will go off. But, I would say:

1. The variable in code should probably be called something other than PIN_LED3, since it's really a pin controlling power, not directly controlling an LED
2. Would code need to be added when starting back up to enable this pin? Or will that happen automatically (indirectly) by other means? (and is that what you meant in your comment on PIN_EINK_PWR_ON?)
3. Something (see my earlier comment) still seems weird about the GPIO numbering (and variable names) the code uses for the LEDs vs what the schematic says, and I don't know enough about which of those (front panel) LEDs we actually intend to directly control in Meshtastic to know if that is an issue or not. For example, I guess we never use the green LED so it doesn't matter that we have no variable with its GPIO number. But I see the red LED on sometimes yet there is no variable matching its GPIO number. And we have PIN_LED2 as P0.15, which the schematic says is connected to an NC pin of the LORA chip. Are there multiple revisions of the board/schematic with different GPIO numbering or something? Confused.

[mc-hamster]

Reopening per @surlyhacker

[caveman99]

The LED's shifted between GPIO pins through the 3 hardware iterations. Probably that's why the strange labelling comes from. I'm hesitant to correct ths because it was way before i joined the project. As of now, the 0.13 pin is still associated with an LED in Lilygo's Documentation so iam inclined to stick to that name, so to easily find it in a cross reference.

[surlyhacker]

Ah! I see. So is there somewhere in the code where it determines which hardware iteration is in use and sets the LED GPIO numbering accordingly? Oh which documentation of theirs has 0.13 linked to an LED?

[garthvh]

Right now it would require a extra firmware build, which is kind of a pain since the revision can't be determined by users easily.

[surlyhacker]

Does that mean that the T-Echo variant in the Meshtastic code is designed to only work with the most recent board hardware, then, I assume? And older hardware would require a custom build with I guess a forked or old version of the variant-specific files?
Does the T-Echo provide some way to query the board revision via firmware, even if the revision cannot be determined by looking at the device?

[surlyhacker]

LilyGo tells me that the T-Echo has only ever had one hardware version. They did some updates to the plastic case design but not the board, so they say.

Looks like the variant-specific code for the T-Echo was once associated with a "TTGO E-Ink" board in the commit history. I wonder what that was and if it was some prototype that existed before the T-Echo or if it's just referring to one of their add-on E-Ink displays for other products of theirs, in which case the LED GPIO numbering would certainly be different if the code was originally meant for something other than the T-Echo, I assume.

Edit:
Ah yes there is some code comment added in a related commit that says "First prototype eink/nrf52840/sx1262 device (removed from build because didn't ship in quantity)"

Edit 2:
this is probably it:
https://meshtastic.discourse.group/t/exciting-new-ttgo-board-prototype/1399
Wow apparently the T-Echo was named by someone (Linar) in that thread. Ha.
https://www.youtube.com/watch?v=a6tHFAe3BOg

[mc-hamster]

"TTGO E-Ink" board in the commit history

They gave us two to play with. :)

[surlyhacker]

And did they give you a schematic with the LED pinouts? ;)

[mc-hamster]

The schematic came with NDA. :(

[kokroo]

If we don't know what revision the hardware is, can we just turn on/off all LEDs on all suspected pins?

[mc-hamster]

If we don't know what revision the hardware is, can we just turn on/off all LEDs on all suspected pins?

If we don't know what's there, we shouldn't do something that could break what we don't know is there... but of course, if you come up with a solution that works, we'll accept the PR. :)

[caveman99]

Just to add to the confusion, from our last telco with Kevin i noted of the 3 HW revisions that are associated with the T-Echo (and are mentioned in the SoftRF sourcecode) only the 3rd and last was sold to consumers. the two earlier revisions were solely developer boards produced in very low quantity. Meshtastic Firmware assumes the retail version. Main differences are some pinouts and the choice of GNSS module. So again, the weird names for our LED pins come from that. I'll send a PR in a few to check if switching off the 3rd GPIO fixes the issue or/and has side effects.

[kokroo]

... Nobody? :-)

I will try to do it today, don't have my T-Echos at the moment.

[ajorg]

try this link instead: https://github.com/meshtastic/artifacts/blob/device/pr/pr1572-firmware-1.3.27.dcc6a4b.zip?raw=true

I tried this tonight. After displaying the "Sleeping..." page the other blue LED (from the tri-color set) stays on and occasionally blinks off, then eventually goes dark, but the tiny blue LED this issue is about is still on.

[caveman99]

@lewisxhe the blue LED on the front panel, to the right of the epaper (next to 'RTC' in this picture) is the issue here. I think in the older cases this is only translucent and its not easy to tell the difference between the two blue indicators, but on the newer ABS cases there is a 'lightguide' that tunnels it to the front bezel. This blue front LED does not switch off when we power down the device.

[caveman99]

N.B. it's switching off now for me on master firmware, seems to be a side effect of the filesystem fix i pushed this morning.

[caveman99]

The fix will be included in the next firmware version 1.3.30 - if the problem is not fixed with that release, please re-open this issue.

[lewisxhe]

Let me add some clarifications:

1. The first indicator next to the picture (RTC) is RGB tri-color light, it is not three separate indicator lights, it is controlled by NRF52840, they are RED(P1.03) GREEN(P1.01), BLUE (P0.14), and the blue indicator on the back of the T-Echo is connected to the 1PPS output of the GPS module. When the GPS is valid, it will flash in the form of pulses (about 1 second flash). Currently, the GPS 1PPS is temporarily The output cannot be stopped, that is, it cannot be turned off
2. At present, LilyGo only provides one T-Echo to mass customers, and there is no problem of multiple versions.
3. PIN_EINK_PWR_ON (P0.12) It is the main power switch of all peripherals (GPS + LoRa + Sensor), and all peripherals will be powered off when it is turned off.As a result of USB connection, if the external power supply is not available, the IO entry is restricted, so the direct communication is not legal.
   GPIO progress control due to the current battery.
4. Regarding the blue 1PPS indicator on the back, if you are bothered by it, you can remove it, if you can

[ajorg]

I'm not sure why this issue was closed.

The fix will be included in the next firmware version 1.3.30 - if the problem is not fixed with that release, please re-open this issue.

For me this does not appear fixed. The tiny blue LED on the back of the device still stays on in 1.3.30.

I don't seem to have permission to re-open the issue.

[kokroo]

Let me add some clarifications:

1. The first indicator next to the picture (RTC) is RGB tri-color light, it is not three separate indicator lights, it is controlled by NRF52840, they are RED(P1.03) GREEN(P1.01), BLUE (P0.14), and the blue indicator on the back of the T-Echo is connected to the 1PPS output of the GPS module. When the GPS is valid, it will flash in the form of pulses (about 1 second flash). Currently, the GPS 1PPS is temporarily The output cannot be stopped, that is, it cannot be turned off
2. At present, LilyGo only provides one T-Echo to mass customers, and there is no problem of multiple versions.
3. PIN_EINK_PWR_ON (P0.12) It is the main power switch of all peripherals (GPS + LoRa + Sensor), and all peripherals will be powered off when it is turned off.

Am I correct in assuming that you are an engineer working at Lilygo? 😃

[lewisxhe]

@kokroo Yes, I work for LilyGo.

[garthvh]

I'm not sure why this issue was closed.

The fix will be included in the next firmware version 1.3.30 - if the problem is not fixed with that release, please re-open this issue.

For me this does not appear fixed. The tiny blue LED on the back of the device still stays on in 1.3.30.

Per lewis from lilygo above we can not control this led, it is the GPS 1PPS and not addressable by meshtastic.

[ajorg]

That makes sense, but I wondered if it means the firmware is leaving the GPS on.

[kokroo]

Let me add some clarifications:

1. The first indicator next to the picture (RTC) is RGB tri-color light, it is not three separate indicator lights, it is controlled by NRF52840, they are RED(P1.03) GREEN(P1.01), BLUE (P0.14), and the blue indicator on the back of the T-Echo is connected to the 1PPS output of the GPS module. When the GPS is valid, it will flash in the form of pulses (about 1 second flash). Currently, the GPS 1PPS is temporarily The output cannot be stopped, that is, it cannot be turned off
2. At present, LilyGo only provides one T-Echo to mass customers, and there is no problem of multiple versions.
3. PIN_EINK_PWR_ON (P0.12) It is the main power switch of all peripherals (GPS + LoRa + Sensor), and all peripherals will be powered off when it is turned off.
4. Regarding the blue 1PPS indicator on the back, if you are bothered by it, you can remove it, if you can

So, what you are saying is, that the blue 1PPS indicator in point 4, cannot be turned off at all? Not even if we power off the GPS module?

If I am not wrong, I have seen all the LEDs off, whenever I reconnect the battery, or at least that blue one isn't turned on then.

The problem is that this blue LED drains the battery over a few days, and it becomes impossible to store a T-Echo with a charged battery, ready to be used in an emergency.

[mc-hamster]

@kokroo What is the measured actual average current draw of the led?

Alternatively, what is the value of the resistor on the led and what duty cycle does the led flash?

Another option to what @lewisxhe suggested is to change the value of resistor to reduce the current.

[lewisxhe]

@kokroo No, it can be turned off by PIN_EINK_PWR_ON (P0.12), but GPS cannot be used after turning it off, LORA

Or take the advice of @mc-hamster and increase the current limiting resistor.

[lyusupov]

1. The blue LED (P0.14) from tri-color (RGB) group is driven by Adafruit Bluetooth library
   It is hard-coded here:
   https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Bluefruit52Lib/src/bluefruit.cpp#L956
   and there: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/variants/pca10056/variant.h#L55

2. Mass production T-Echo (PCB design date: 2021-3-26) has the following tri-color RGB LEDs mapping:

#define SOC_GPIO_LED_TECHO_GREEN  _PINNUM(1,  1) // P1.01 (Green)
#define SOC_GPIO_LED_TECHO_RED    _PINNUM(1,  3) // P1.03 (Red)
#define SOC_GPIO_LED_TECHO_BLUE   _PINNUM(0, 14) // P0.14 (Blue)

See that blue LED (P0.14) matches to the definition in the Adafruit header file mentioned above.

The schematic came with NDA. :(

T-Echo schematic @ LilyGO GitHub

3. There is a separate blue LED located near L76K GNSS module.
   To explicitly turn it off - one need to DISCONNECT USB POWER SUPPLY first, then execute:

/* Power switch for: EINK, RGB, CN1 (, RF), FLASH, GNSS, SENSOR */
#define SOC_GPIO_PIN_IO_PWR   _PINNUM(0, 12) // P0.12

pinMode(SOC_GPIO_PIN_IO_PWR,    INPUT);

Be aware that when USB power supply is active - this blue (GNSS) LED may still stay illuminated (or flashing) which indicates that the GNSS module is still operating in active mode.

[richteel]

Still seeing this issue with firmware-t-echo-2.1.15.cd78723.uf2. I went on vacation for 2 weeks and came back to the batteries being discharged in my T-Echo devices. The easy fix may be to remove the LED as it is not used but that may still not solve the issue. I believe it is quite likely that the L76K is not being properly shutdown so it is still full on rather than being in standby.

https://docs.rs-online.com/4a92/0900766b8147dbea.pdf (Page 17 of 43)
Using STANDBY pin: Pulling STANDBY low will make the GNSS module to enter into standby mode and releasing STANDBY which has been pulled high internally will make the module back to full on mode. Note that pulling down STANDBY pin to ground will cause the extra current consumption which makes the typical standby current reach to about 600uA @VCC=3.3V.

Using PMTK command: Sending PMTK command “$PMTK161,0*28” will enter into standby mode. Sending any data via UART1 will make the module exiting from standby mode as UART1 is still accessible in standby mode. When the module exit from standby mode, it will use all internal aiding information like GPS time, Ephemeris, Last Position etc., resulting to a fastest possible TTFF in either Hot or Warm start. The typical current consumption in this way is about 500uA @VCC=3.3V in standby mode.

I see there is mention that "the GPS 1PPS is temporarily The output cannot be stopped, that is, it cannot be turned off", but that is only half true. If the L76K is properly shutdown then the LED will be off, therefore, it can be controlled through the firmware. The reason I stated it is half true is, at least in the documentation that I referenced, it makes no mention of the state of this pin when the L76K is is standby. If, when the L76K is put in standby, the pin is high, then the behavior is correct and the statement is true, but it would then be likely that the LED should be connected to VCC rather than ground with the polarity flipped. Someone with a better source with more information about the 1PPS pin would be able to shed some light on this.

If my first thought is true, then the following code in firmware\src\GPS\GPS.cpp needs to be modified to shutdown the L76K properly.
void GPS::sleep()
{
#ifdef PIN_GPS_WAKE
digitalWrite(PIN_GPS_WAKE, GPS_WAKE_ACTIVE ? 0 : 1);
pinMode(PIN_GPS_WAKE, OUTPUT);
#endif
}

firmware\variants\t-echo\variant.h defines PIN_GPS_WAKE
#define PIN_GPS_WAKE (32 + 2) // An output to wake GPS, low means allow sleep, high means force wake

Looking into this a bit more, it appears that P1.02 from the NRF8420 is connected to the WAKE_UP pin on the L76K, so on the surface, it looks like the code does not need to be modified after all. If that is the case, then really need to get to the bottom of the 1PPS pin to determine the best fix. Is the L76K really in standby? If it is, why is 1PPS held high? Is 1PPS really active low and should have the LED polarity flipped and connected to VCC rather than GND? Is it best to simply remove LED6?

[garthvh]

@richteel this is the recommendation from lilygo #1493 (comment) this is hardware related and can not be fixed in software.

[richteel]

@garthvh, I actually refer to that comment but did not link it. It may be true, but the questions that I ask at the end of my post need to be addressed before this issue is truly addressed so it may be closed. (I know it was prematurely/incompletely closed. I'm not asking for it to be reopened but I would like to see a proper analysis done. I took it about 75% of the way and thus far, it supports the conclusion of the response that you had linked. It just needs a little more rigor.)

The questions that need to be answered to close this out for good.

• Is the L76K really in standby?
• If it is, why is 1PPS held high?
• Is 1PPS really active low and should have the LED polarity flipped and connected to VCC rather than GND?
• Is it best to simply remove LED6? (Most likely this is the correct answer but I do not like to jump to conclusions. The previous questions need to be answered first.)

I may attempt to figure a way to tap into the TX and RX lines without ruining my T-Echo but I would rather someone from LilyGo run some of those tests as they have the resources to do so. It is also in their best interests as there may be a flaw with the hardware therefore a reversion of the T-Echo may be called for.

[garthvh]

@garthvh, I actually refer to that comment but did not link it. It may be true, but the questions that I ask at the end of my post need to be addressed before this issue is truly addressed so it may be closed. (I know it was prematurely/incompletely closed. I'm not asking for it to be reopened but I would like to see a proper analysis done. I took it about 75% of the way and thus far, it supports the conclusion of the response that you had linked. It just needs a little more rigor.)

The questions that need to be answered to close this out for good.

• Is the L76K really in standby?
• If it is, why is 1PPS held high?
• Is 1PPS really active low and should have the LED polarity flipped and connected to VCC rather than GND?
• Is it best to simply remove LED6? (Most likely this is the correct answer but I do not like to jump to conclusions. The previous questions need to be answered first.)

I may attempt to figure a way to tap into the TX and RX lines without ruining my T-Echo but I would rather someone from LilyGo run some of those tests as they have the resources to do so. It is also in their best interests as there may be a flaw with the hardware therefore a reversion of the T-Echo may be called for.

You are free to open an issue with them https://github.com/Xinyuan-LilyGO/T-Echo

[lewisxhe]

@richteel Please check the battery used, if it is connected to USB, it will control the IO input due to the lack of external power supply, so it is legally legal.

GPIO progress control due to the current battery.

[richteel]

@lewisxhe, Sorry, but I do not understand your comment. The unit is off and not connected to USB so not certain how to check the battery level or how or what the IO control has to do with it. Also not certain what legality as to do with anything here.

Perhaps you are asking to connect a volt meter to the battery and monitor the voltage. I can do that but it will take me a few days to do so as I'm in the middle of a few other things at the moment. (At least, I believe I will be able to if I have the proper connectors for the battery.)

[garthvh]

This issue is locked, please continue discussion in the techo repository.

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/lilygo-t-echo-fw-2-2-11-10265aa-issue/8331/4