Problems with 1 ESC about esc-configurator HOT 12 CLOSED

Hm, could it be that it tries to read too quickly before the ESC has entered bootloader mode?

from esc-configurator.

Yes, that is most probably the case. I have a one second delay after enabling the 4 way interface to wait for the ESCs to boot up before talking to them. In my tests this seems to work reliably. I now disabled the retries. We will see how it behaves now.

from esc-configurator.

The 4way interface advertises n ESCs. n being the amount coresponding to BF settings, so if a quadcopter layout is set, it will always return 4. 3 when tricopter is set and so on. This does not reflect the actual amount of ESCs connected. Now when reading the ESCs I have to ask the 4way interface to read all ESCs that it "thinks" are there.

If BF is set to 4 and only one is attached, then I am reading 3 times "nothing" the command will simply not return anything. Commands have a timeout to return something. Per default this is 1 second. This can result in "long" waiting times when reading the ESC.

I think I can safely decrease this timeout to 250ms.

from esc-configurator.

This might have been solved in the latest master. Decreased the amounts of retries on reading the ESC's. MSP will always reported the count of motors according to the selected Layout in Betaflight. If not all motors are present, we were running into problems with long time-outs, since we were waiting for all motors to come on.

The amount of retries has now been decreased to 3 and the error handling of missing motors has been improved.

from esc-configurator.

@mathiasvr could you maybe check if this is still an issue with your one ESC setup?

from esc-configurator.

@stylesuxx This works much better but still a bit slow if you insist on having just 1 ESC connected/powered. I think it will be fine, but I'm not sure the retries are really necessary since I never had any problems but maybe that's just me.

from esc-configurator.

OK, great - thank you. I have had issues with reading in the original configurator from time to time, where it would only show a subset of the available ESC's, and I would need to disconnect/re-connect multiple times for all ESC's to show up. That's what I was trying to resolve with the re-tries.

But I will disable the re-tries and see if it actually is a problem with my implementation.

from esc-configurator.

I now released the version that has the retries disabled and a 1.5 second wait before reading. This seems to be a good middle ground that also seems to work fine on AM32.

@mathiasvr If you could give it another try, I would really appreciate it.

from esc-configurator.

Seems to work, but you are always delaying read by 1.5s right? I think it's only necessary to ensure that it has been x amount of time since enabling the bootloader signal until read begins - but not sure?

from esc-configurator.

No, I am only delaying the first read after clicking connect. But if you only have 1ESC attached and it is the last one, then it will time out 3 times before reading the last one, resulting in a 3 second delay. Technically I could remember that after the first read there were only n ESCs and then not try to read them again. Alternatively I could also decrease the timeout.

from esc-configurator.

Maybe I don't quite understand how it works, will try to look into it later. But I think it works fine now.

from esc-configurator.

Makes no sense to wait here at all, since it depends on length of the startup tune when the user might actually be able to connect to the ESC's.

Instead the user should be informed why he is not seeing all his ESCs #90

from esc-configurator.