Looking forward to having this feature. I was disappointed to see that triple power cycle wasn't disable-able in 3.4. This will be great for my multi receiver systems on independent power sources.

I'd love to have this feature as there are situations where plenty of folks might be power cycling in a hurry when they're troubleshooting under a time constraint for example.

The triple power cycle bind method of binding can cause serious problems when the ELRS is used in an environment when/where power is not stable. If the power is somehow cut and re-established 3 times in very short pulses, the ELRS receiver can be put into a binding state and not recover the original intended connection to the transmitter.

This pull request adds a user-configurable option to disable this binding method. There is a checkbox added to the Wi-Fi configuration screen (underneath lock-on-first-connection). It's been added to the user_defines.txt and also all of the build related python scripts.

Anyone running into this problem has bigger issues too address. A bad power supply is just going to lead to further troubles. I don't feel this is a good fix for dodgy hardware!

The triple power cycle bind method of binding can cause serious problems when the ELRS is used in an environment when/where power is not stable. If the power is somehow cut and re-established 3 times in very short pulses, the ELRS receiver can be put into a binding state and not recover the original intended connection to the transmitter.
This pull request adds a user-configurable option to disable this binding method. There is a checkbox added to the Wi-Fi configuration screen (underneath lock-on-first-connection). It's been added to the user_defines.txt and also all of the build related python scripts.

Anyone running into this problem has bigger issues too address. A bad power supply is just going to lead to further troubles. I don't feel this is a good fix for dodgy hardware!

There are plenty of situations where this could be caused by not having a power supply problem. Such as rapid power cycles when troubleshooting. I don't really see why there is any real opposition to this considering the entire robot combat community does not like the triple power cycle method.

@frank26080115 @wtjstanley @RNewDeal @Camo55 Where are you guys hanging out and discussing this? To me this looks like Frank and 3 5 alt accounts.

The 3x power cycle, each power cycle must happen within 2 seconds. After 2 seconds the counter is reset. After a connection to the TX, the counter is reset.
If you have setup you system so that the RX starts it's cycling on the TX configured packet rate then the RX will connect almost instantaneously so the counter will be reset. This means that in a situation where the TX is on, the RX will need to reset in < ~200ms. If you have a craft that is resetting the receiver in less than that time then your craft has serious issues with it's power system. If this is the case then perhaps the receiver should have it's own power supply that is immune to this brownout behaviour.

@frank26080115 @wtjstanley @RNewDeal @Camo55 Where are you guys hanging out and discussing this? To me this looks like Frank and 3 5 alt accounts.

These are all separate accounts and separate people we just know each other from robot combat and like the ELRS platform.

The 3x power cycle, each power cycle must happen within 2 seconds. After 2 seconds the counter is reset. After a connection to the TX, the counter is reset. If you have setup you system so that the RX starts it's cycling on the TX configured packet rate then the RX will connect almost instantaneously so the counter will be reset. This means that in a situation where the TX is on, the RX will need to reset in < ~200ms. If you have a craft that is resetting the receiver in less than that time then your craft has serious issues with it's power system. If this is the case then perhaps the receiver should have it's own power supply that is immune to this brownout behaviour.

If the packet rate is not set properly it could easily happen. Yes brownouts shouldn't happen but there are plenty of situations where a separate power supply is not viable.

If the packet rate is not set properly it could easily happen. Yes brownouts shouldn't happen but there are plenty of situations where a separate power supply is not viable.

If the receiver is not setup to connect at the rate the TX is on then it will cycle around the packet rates and could take some time connect, you will not have any control of the craft during that time and it could be for 20 seconds or more!

So here is a situation where disabling this feature could be very beneficial, and where I personally had to drop out of a tournament because It happened:

At tournament, preparing my bot for combat: Plugging in the power connector at a bad angle, accidentally somehow managed to tap the contacts 3 times in rapid succession (likely due to adrenaline) and causing the receiver to go into bind mode. I was able to spend the minute it took to go through my controller's settings and hit bind to the receiver, but this receiver also had the PWM mod added to it at some point, and defaulted to PWM controls instead of the CRSF control I needed for my setup. I did not have 20 minutes to diagnose this problem and had to drop out.

If the receiver hadn't gone into bind mode, it wouldn't have also reset its other settings and caused me to drop out of the tournament.
Also, we don't always remember to turn our radios on before powering up our bots; and in the case where the radio is turned on mere moments before power is added to the bot, the radio still takes 10-15 seconds to initialize.

In a similar instance, during combat, brownouts are common either from large electrical loads on the system, or the large shock loads briefly disconnecting power, which in some cases will intermittently reconnect within the bind window.

I've tried to set up my receiver with a bind phrase and even adjusted the baudrate and refresh rates of the connection to make sure the rx knows what to look for on startup, but it still takes 2-3 seconds for it to connect to my radio. (frsky x-lite pro with jumper ELRS nano backpack to betafpv elrs lite or foxeer elrs lite rx)

I see absolutely no reason why this feature can't be added to the elrs list.
I can link the several discord channels of robotics builders if you'd like to see proof.

Fuzzhao is a valuable member of the bot community and we trust many of his projects in our bots.

Also note that many of these systems are hard soldered, epoxied, or otherwise embedded and very hard to get to.

If you have a craft that is resetting the receiver in less than that time then your craft has serious issues with it's power system.

Or the motor driver is in a phase, a FET is conducting, and the robot gets hit with a force equivalent to a head on car collision. The wheel is now driven in reverse from the collision and the regenerated motor voltage spike manage to trip your voltage regulator's overvoltage protection with a massive ringing effect that causes 3 pulses about 200ms.

This is all despite your best efforts in cramming as many capacitors as you can within the robot's competition weight limit, spend any more weight on capacitors and filtering and transient diodes, you start losing weapon mass to actually hit other robots with. You try to engineer the perfect power supply immune to all conditions and you just lose because that money and mass could've been spent elsewhere.

@frank26080115 @wtjstanley @RNewDeal @Camo55 Where are you guys hanging out and discussing this? To me this looks like Frank and 3 5 alt accounts.

Also here from the robot combat community. I can understand the request to change how this flag is implemented, but is there any specific reason not to make it a user-configurable option? In our specific use case, we regularly have unstable connections to power, and the ability to disable disconnecting from your transmitter due to that is useful. I'm not sure I see a case where this would cause an issue with other uses of ELRS, especially if the triple power cycle bind is on by default.

(Not trying to start a "+1 me too!" train, but just wanted to clarify that there is other interest from the community in this option.)

At tournament, preparing my bot for combat: Plugging in the power connector at a bad angle, accidentally somehow managed to tap the contacts 3 times in rapid succession (likely due to adrenaline) and causing the receiver to go into bind mode. I was able to spend the minute it took to go through my controller's settings and hit bind to the receiver, but this receiver also had the PWM mod added to it at some point, and defaulted to PWM controls instead of the CRSF control I needed for my setup. I did not have 20 minutes to diagnose this problem and had to drop out.

There was a bug that caused the older style 8285 receivers to corrupt their config when rapidly powering on/off the receiver. When it rebooted it would then reset to defaults. This bug was fixed in 3.4.3. #2755

I'm just trying to understand why everybody thinks the 3x power cycle to bind is not for the combat robot community.
The new binding method has different modes, so rather than adding a new checkbox to just disable the 3x power cycle bind mode; I'd prefer to extend that feature which has "Persistent", "Volatile" and "Returnable" to add a new "Permanent" which can only be changed via flashing or the web-UI.

User configurable options just make things more complex for new users as they don't know whether or not to use the option.

At tournament, preparing my bot for combat: Plugging in the power connector at a bad angle, accidentally somehow managed to tap the contacts 3 times in rapid succession (likely due to adrenaline) and causing the receiver to go into bind mode. I was able to spend the minute it took to go through my controller's settings and hit bind to the receiver, but this receiver also had the PWM mod added to it at some point, and defaulted to PWM controls instead of the CRSF control I needed for my setup. I did not have 20 minutes to diagnose this problem and had to drop out.

There was a bug that caused the older style 8285 receivers to corrupt their config when rapidly powering on/off the receiver. When it rebooted it would then reset to defaults. This bug was fixed in 3.4.3. #2755

I'm just trying to understand why everybody thinks the 3x power cycle to bind is not for the combat robot community. The new binding method has different modes, so rather than adding a new checkbox to just disable the 3x power cycle bind mode; I'd prefer to extend that feature which has "Persistent", "Volatile" and "Returnable" to add a new "Permanent" which can only be changed via flashing or the web-UI.

User configurable options just make things more complex for new users as they don't know whether or not to use the option.

Adding it to the firmware step or hiding it in the hardware.html page would work.

Adding it to the firmware step or hiding it in the hardware.html page would work.

That is completely the wrong place to put it. That page is only for configuring the hardware layout JSON file.

I'm just trying to understand why everybody thinks the 3x power cycle to bind is not for the combat robot community.

Having it on as default is perfectly viable. Sometimes the bind phrase is corrupted or doesn't work for some reason, or maybe I set the receiver to wait 2 hours before going into wifi mode.

I would say that this checkbox is equivalent to the 'Program by TX" button in BLheli software. (I disable that too, for similar reasons)

The new binding method has different modes, so rather than adding a new checkbox to just disable the 3x power cycle bind mode; I'd prefer to extend that feature which has "Persistent", "Volatile" and "Returnable" to add a new "Permanent" which can only be changed via flashing or the web-UI.

Are you saying there are other options besides 3-power cycle or bind phrase to bind to receivers?
I am new to this ELRS system myself, and I only know of these two options to bind to the receiver.

User configurable options just make things more complex for new users as they don't know whether or not to use the option.

As a new user myself, I would much rather have the option and not need it, than not have the option and want it/wish it was one.
I thought I would have been forced to give the person my remote to drive my bot thats connected to it
because of all the custom setup I did with the inputs and mixes
It wouldn't make sense to let it bind to another controller

Are you saying there are other options besides 3-power cycle or bind phrase to bind to receivers?

There are many ways to enter binding mode and there are many ways to bind to a receiver.

• Flashing a bind-phrase to auto bind
• WiFi enter bind-phrase to auto bind
• 3x power cycle to enter bind-mode
• holding the button on the receiver for 3 seconds to enter binding mode
• Send a CRSF command from the flight controller to enter bind mode

Once in bind mode you "bind" from the handset.

In 3.4 there is extra binding configuration

• Persistent binding will keep the bind across power cycles, but can be reset by all the methods above.
• Volatile binding forgets it's binding after each power cycle (this is useful for groups that share drones).
• Returnable binding, the user can release their hold on receiver and it will enter binding mode when re-powered.

I am suggesting adding a Permanent mode, which is like persistent above, but can only be reset by flashing or the web-UI.

I actually like the "Permanent" storage mode idea so I submitted #2862 just now

Closing this one in favour of #2862