Mystery led flashing after upgrade to ver 2.3.11 [Bug]:

[Ccz119]

Category

Other

Hardware

Heltec V3

Firmware Version

2.3.11

Description

Occusionally the heartbeat led flashes one sec on, one sec off. Then goes away after some minutes. Is some kind of error? It was not there on 2.3.9.
logs do not show something odd.

Relevant log output

No response

[todd-herbert]

Do you have a battery connected? Without a battery, the voltage read at the battery detected "wanders around". Sometimes it wanders high enough to appear that there is a battery present which is charging. It can wander a little bit even when a battery is connected.

When the battery voltage appears high enough, the device believes that the battery is being charged, which causes the heartbeat to change. Normally, it does a very short flick on and off, but when charging, it does a solid "1 second on, 1 second off" blink.

In a recent version of the firmware, the code for reading Heltec's battery voltage was adjusted here by a Heltec staff member. Possibly this new adjustment is causing this new behaviour on your device? If there's a specific behaviour you want, you can probably cheat it by manually adjusting the ADC multiplier

[todd-herbert]

Now that I think about it though, I should add that if you're only seeing a single long blink, then back to normal, this could also be some part of the code blocking execution for 1 second while something is running. That wouldn't be ideal, but it's another possible explanation.

[clwgh]

I have a Heltec 32 V3.1 and I am also seeing this same behaviour. With previous firmware the orange LED is on and the white LED blinks faintly as a heartbeat. Occasionally there will be a single bright flash of the white LED and it will resume blinking faintly.

Since moving to firmware 2.3.11 (via web flasher with full erase), the LED behaviour is the same as above, except now there are periods where the white LED goes on full for one second then off for one second. It will do this for a minute or longer, then resume the normal heartbeat blinking for a minute or so, and then the cycle repeats.

My Heltec is powered from a USB power socket, there is no battery attached.

I ended up temporarily setting --set device.led_heartbeat_disabled true to turn the white LED off, because it lights the room up at night with this new behaviour.

[todd-herbert]

I'm reasonably sure it's a result of #3955. This PR does give more accurate readings of the battery voltage, but it sounds like it has bumped the readings up just enough for the floating voltages, which are reported when no battery is connected, to occasionally convince the device that it is "charging"

My Heltec is powered from a USB power socket, there is no battery attached.

In my opinion, this is a bit of a design flaw in some of Heltec's boards. The battery charger IC is not connected directly to the microcontroller. Instead, it just drives that orange LED. The microcontroller is only guessing whether the battery is charging by looking at the voltage readings from the battery connector. When no battery is connected, the battery charger causes these readings to float, wandering between roughly 3.8V and 4.1V (I forget exactly).

I did work on some code attempting to find new ways to determine whether Heltec V3-style boards are externally powered or not, but I couldn't make it work reliably. As you say, disabling the heartbeat LED entirely might be the best way to go.

Alternatively, if you manually override the changes from #3955 by changing your "ADC Multiplier Override setting" to 4.9, you should get the older behavior back.

[clwgh]

Thanks for the info, that all makes sense. I wonder if there is a simple circuit hack to clamp that input, without needing to add a battery, so that at least it's not drifting and should avoid triggering the effect. A couple of resistors and a diode or something that's not going to try and charge and cause problems on that side.

Regarding the tweak to the variant.h file, would I be right to say this isn't something we can do to an existing firmware image, and instead requires a suitable build environment to compile a custom firmware with the tweak? I've not modded these firmwares before so would need to delve into what's required.

Since the Heltec is very reliable and accessed by me using the app anyway, I'm not really missing the heartbeat LED, but it will be nice to get it back if it can be tamed.

[todd-herbert]

requires a suitable build environment to compile a custom firmware with the tweak?

Hopefully it's something you can just set in the app:

I wonder if there is a simple circuit hack to clamp that input, without needing to add a battery, so that at least it's not drifting and should avoid triggering the effect. A couple of resistors and a diode

I bet something like that would work too!

[clwgh]

Excellent, thankyou, I didn't realise it was a setting. I'm using the iOS app and it's in there, for reference it's in the app Settings > Power > ADC Override. Enable and enter the desired value, which will be 4.9 to return to the previous firmware's value.

It's also available in the CLI as power.adc_multiplier_override and presumably the desired value of 4.9.

I will re-enable the LED, observe the return of the flashing behaviour and then set the ADC override to 4.9 and see what happens. I'll report the results here and in the Discord.

[clwgh]

You were correct, @todd-herbert, many thanks, the ADC override has fixed it.

I re-enabled the heartbeat LED and within the space of five minutes the long flashing sequence had happened twice, each for a minute or so.

I used the CLI to set the override:

meshtastic --set power.adc_multiplier_override 4.9

The long flashing did not happen over the next five minutes.

I then set it to 5.1205 which is the value in the 2.3.11 firmware (4.9 * 1.045). The long flashing sequences resumed and happened a couple of times over the next five minutes.

I set it back to 4.9 and left it there, and it has not happened since.

I also checked in the iOS app after setting it, and it correctly reads the updated value and shows the feature as enabled with a value of 4.9. Therefore it could have also been set directly in the app, which is probably how most people will do so.

Android app

screenshot above

iOS app

Python CLI

meshtastic --set power.adc_multiplier_override 4.9

[clwgh]

Hello @Ccz119, I didn't mean to take over your bug report. Looks like the ADC Override fixes it, and you can set it in the app or via the CLI. Does it fix it for you too? I'm running the Heltec off USB without a battery, presumably you are too.

[todd-herbert]

It's a shame there isn't a nicer compromise here, but I'm glad you've got back the behavior you were after 👍

[Ccz119]

Hi all, thank you for your contrubutions. It happens only after upgrading to 2.3.11 with battery. It flashes for about a minute. Same to another board 2.3.12 and no battery. So, on version 2.3.9 the value of ADC was not zero?

[clwgh]

It was previously #define ADC_MULTIPLIER 4.9. Now it's #define ADC_MULTIPLIER 4.9*1.045 which is 5.1205. Using override to set it explicitly back to 4.9 has fixed it for me.

[todd-herbert]

So, on version 2.3.9 the value of ADC was not zero?

Ah it's not immediately obvious, but a value of zero in the settings usually means "use the default value" (which has changed between 2.3.9 and 2.3.11). I think this is a space-saving quirk of the system Meshtastic uses to store info and transfer it between devices.

It happens only after upgrading to 2.3.11 with battery. It flashes for about a minute.

I've watched the output of the Heltec's battery charger IC before, and it does seem to peak at quite a high voltage for a brief time, before settling down. I'm guessing that's what's causing what you're seeing. Not wanting to dismiss any concerns, just giving some info on what might be going on.

[Ccz119]

So, we need to enter a value manually. But what is the cirrect one? 4.9 is not a bit high? Thanks to all for your replies

…

On Sat, Jun 15, 2024, 7:30 AM todd-herbert ***@***.***> wrote: So, on version 2.3.9 the value of ADC was not zero? Ah it's not immediately obvious, but a value of zero in the settings usually means "use the default value" (which has changed between 2.3.9 and 2.3.11). I think this is a space-saving quirk of the system Meshtastic uses to store info and transfer it between devices. — Reply to this email directly, view it on GitHub <#4063 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJB5JUH2IH43IJP4JGIYMJ3ZHO7OPAVCNFSM6AAAAABJBGPDBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZGEZDAOJQGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[todd-herbert]

If the "ADC multiplier override" is set to zero, the default value will be used.
On v2.3.9, this default value was 4.9. On v2.3.11, this default value is 5.1205

Supposedly, 5.1205 gives more accurate voltage readings, but these higher reported voltages are telling the Meshtastic firmware to change the blink pattern. The original intention of the "solid" blink pattern is to indicate that the device is charging the battery, but this has never worked correctly with some devices due to hardware limitations. It is possible that this "solid blink" behavior could be eliminated or changed, if the developers are on-board with the idea.

If you change the "ADC multiplier override" value to 4.9, you will get the old behavior from 2.3.9 back: no bright blinking, but slightly less accurate voltage readings.

4.9 is not a bit high?

Don't worry, this number is not "4.9V". Because the battery voltage is too high to be measured directly, the hardware lowers this for us. The 4.9 value in a "multiplier", which we use to translate this lowered value back to the correct voltage.

(Technically: if you look at the schematic, the ratio of the voltage divider hardware itself is less than 4.9, but the MCU also attenuates the reading for us. There's some documentation on the website about fine-tuning the ADC multiplier for your hardware, if that's something you'd be interested in.)

[Ccz119]

Well, 4.9 setting has fixed that for me. Thank you.

[chichimus]

Just updated my V3 from 2.3.9 to 2.4.0.46d7b82 and this bright LED nonsense started. Nice to find a simple fix. Now it is back to the much dimmer heartbeat.