Option for BLUE power LED

[bob01]

Is there an existing issue for this feature request?

• I have searched the existing issues

Is your feature request related to a problem?

2.10 changed the power LED color on the TX16S from BLUE to GREEN - I understand the reason given but that said I really prefer (as do most guys I fly with) prefer the BLUE.

GREEN makes the radio feel old.

Describe the solution you'd like

Revert to BLUE for power / transmitting or provide an option for power LED color.

Describe alternatives you've considered

No response

Additional context

No response

[pfeerick]

That is a bit of a problem, actually, as the TX16S is one of the radios that should not have changed colour... both it and the LR3PRO are supposed to be blue after startup (i.e. those two are reversed, per manufacturer request), so need to see why that changed. However, ideally there would be a option to set the warning, startup and operational colours, as everyone has different preferences, as well as helping if color blind, etc.

[Model-Man]

The blue led was so much better and I asked the very same question on Discord. Now the power led is green, it's also the same colour as the charging led which is a little confusing. If a simple colour change slider could be added in the TX settings so the user could pick and choose, it would be so much better.

[MRC3742]

Also effects the Jumper T16 transmitter.
Upon startup, Power LED is Blue, after splash screen delay the LED shuts off completely.
v2.10.0 Release

Rich

[3djc]

The current sequence is blue during boot up, red on errors, and green when everything is ready

While the last color can be changed by setting, the initial green cannot as settings are not available at that time. So in an errorless start, there would be no color change when ready, while one with error would be green red green

[Model-Man]

If this was the case why was blue the fully loaded up colour in 2.9.4 ?

[3djc]

Because no real standardisation was done initially, it was more or less was just random (just red was enforced) Then the manufacturers asked for all their radios to behave the same. Since the most universal color to say 'all is ok' is green, that was chosen

[MRC3742]

According to the Jumper T16 schematic, I don't believe the green LED is connected to the MCU.
So I get BLUE on Startup, RED on Error, and OFF after everything is ready.

Rich

[Camo55]

Would the Power switch LED be able to be a separate RGB color selector similar to how the MT12 does it?

[3djc]

No, and the green led turns on long before the radio is started enough to have rgb pulse ready

[Model-Man]

So although this is effectively an open source software, the manufactures who I assume have several Edge TX programmers on the payroll, are now enforcing the format they want on the radios?

[3djc]

So although this is effectively an open source software, the manufactures who I assume have several Edge TX programmers on the payroll, are now enforcing the format they want on the radios?

First of all, I find it an amazing tribute to our work that the main issue you have with our software is the color of a led on the radio.

If manufacturers had any of us on their payroll, they would do exactly what frsky did once they managed to hire one of the otx devs: stop open source and do their own. Why would they pay anyone to have their work published as open source ????

Manufacturers do support the project financially, as many of you do too, you can find the details of their contribution, and how they are used here: https://opencollective.com/edgetx

Can you really argue that harmonising the color of power led across radio is a bad thing ? You seem to have a preference for blue, nothing wrong with that, but it's just that, a preference, while there is a rationale to have it green.

That said, the door is opened for a setting, I was merely stating that the first two led color cannot be changed based on user preference, simply because technically, the user settings cannot be read until sd is mounted and ready, and that happens very late in the boot process.

[pfeerick]

Also effects the Jumper T16 transmitter. Upon startup, Power LED is Blue, after splash screen delay the LED shuts off completely.

Yeah, need to check what LEDs that radio has which are MCU controlled, green could be charge only. On the TX16S I think it is both MCU and charger controlled, but if it's charging we can't turn the green one off, which is one reason blue I think blue was the preferred operational colour for that radio.

Then the manufacturers asked for all their radios to behave the same. Since the most universal color to say 'all is ok' is green, that was chosen.

No, that is not correct. We as a project chose to standardise the colours, as they were somewhat standardised already, but new radios were being added with different colours, or GPIO definitions wrong because of colour swaps in the code (e.g. #2249, #2346, #3201). Then manufacturers were asked if they had a preference for pre-existing radios - i.e. RM for TX16S, BetaFPV for LR3Pro, in those cases they both requested it be left Blue once operational. Then there are some radios such as the X9D+ and Commando8 which only have blue or green, etc. Even a comment in the code that hints at this:

edgetx/radio/src/opentx.h

Lines 598 to 611 in c2e7d91

	#if defined(STATUS_LEDS)
	#define LED_ERROR_BEGIN() ledRed()
	// Green is preferred "ready to use" color for these radios
	#if defined(MANUFACTURER_RADIOMASTER) || defined(MANUFACTURER_JUMPER) || defined(RADIO_COMMANDO8)
	#define LED_ERROR_END() ledGreen()
	#define LED_BIND() ledBlue()
	#else
	// Either green is not an option, or blue is preferred "ready to use" color
	#define LED_ERROR_END() ledBlue()
	#endif
	#else
	#define LED_ERROR_BEGIN()
	#define LED_ERROR_END()
	#endif

However, it looks like #3715 undid part of this. So it looks like the todo from #2346 is probably needed now... "Future todo - have each radio raise a flag for blue over green status color". Was a chore I'd identified to work on for 2.9 (#2249 (comment)), as well as getting rid of the radio specific defines in that area and instead have it as part of the target options... but obviously didn't get there...

So although this is effectively an open source software, the manufactures who I assume have several Edge TX programmers on the payroll, are now enforcing the format they want on the radios?

Just because this is an open source project, doesn't not mean you just get what you want. But it does mean you can download/modify the code, compile it yourself. We'll even help you by telling you what code to adjust if you ask nicely, and you don't even need to download the compile environment since we went to the trouble of making it possible to build it using a cloud IDE. It is the Project Steering Committee (PSC) that determine what happens generally, and we are all private individuals who are donating our time and expertise to the project. I raised the concern that stuff was all over the place, and that it should be standardised for consistency and there was consensus on this point, with it coming mostly (if not completely) into effect in 2.8.

[philmoz]

On the TX16S I think it is both MCU and charger controlled, but if it's charging we can't turn the green one off, which is one reason blue I think blue was the preferred operational colour for that radio.

My understanding is that the TX16S was supposed to be green for operational; but due to a bug in the code it only changed the color if there was a throttle check on startup. This was fixed in 2.10.

[Model-Man]

Many thanks for the detailed reply. I have only admiration for the work everyone does with Edge. I guess it must be hard to please everyone, as well as trying to standardize code across a multitude of different TX models.

[pfeerick]

My understanding is that the TX16S was supposed to be green for operational; but due to a bug in the code it only changed the color if there was a throttle check on startup. This was fixed in 2.10.

No, the RM TX16S was specifically requested to remain blue, and was configured that way. Are you sure it was that, and that it wasn't that it was stuck green, and never changed to blue? Because the define line was changed in #3715 from being radio specific, to using the manufacturer defines, it undid the radio specific configuration.

[philmoz]

On 2.9 if you start with a throttle check warning the LED is changed to green after you clear the warning - the call to set the led was only being done if there was an error. B&W radios alway set the led color regardless.
When I queried this the consensus was it was an error and should always set the color - the defined color for TX16S when error is cleared is green.

[pfeerick]

I think you are talking about something different... yes, there was an issue with the led colour not actually being set on colorlcd when clearing or not clearing a warning. However, this is nothing to do the underlying define which determines those colors, which was changed in #3715 ... changing the TX16S (and other radios) from blue/blue to blue/green.

[mhk1058]

Because no real standardisation was done initially, it was more or less was just random (just red was enforced) Then the manufacturers asked for all their radios to behave the same. Since the most universal color to say 'all is ok' is green, that was chosen

Ironically my quads' (using iNav)LEDs show green when disarmed (safe) and blue when armed. Another thumbs up from me to at least have an option to have blue.

[GeneralPancakeMSTR]

Another vote for Option for Blue, or better yet, be able to turn off the LED entirely.

[eXeCy]

I personally prefer the blue color too.. Green is getting me crazy and is really ugly.
If you please compile a FW with always blue it will be much appreciated.

[mhk1058]

I think it's the manufacturers working group that you need to appeal to, they set the standards for what colour means what across the hardware, not the EdgeTX guys and gals. The blue colour was always a glitch in the matrix.

…

On Fri, 8 Nov 2024 at 10:00, eXeCy ***@***.***> wrote: I personally prefer the blue color too.. Green is getting me crazy and is really ugly. If you please compile a FW with always blue it will be much appreciated. — Reply to this email directly, view it on GitHub <#5010 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM4Y6NOLUAE6NUZY3RYX45LZ7SDTNAVCNFSM6AAAAABHXFSWMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRUGI4DOMBTG4> . You are receiving this because you commented.Message ID: ***@***.***>

[gagarinlg]

As far as I know there is no manufacturers working group.

[3djc]

The manufacturers did ask to standardise color across their range, which only makes sense. Red was chosen for error as it is widely used this way. Green for 'ok' for the same reason, that left blue for initialisation in progress

[gagarinlg]

When people complain about LED colors, everything else must be almost perfect 😉

[mhk1058]

👍😂

[etocii]

Option for color please!

[JClaudeB7500]

I guys,
I also prefer that the LED stay blue during normal usage.
Thanks.

[ElectricRoxy]

Green, Blue or any color is fine, but can we dim it down? We can reduce the backlight intensity, but not the power led, and doing crawling with the MT12 in the dark it is quite distracting