RushFPV Rush_blade_sport_v21 Rev32.8

[Linuxbarista]

Ok pretty new to the GitHub thing so go easy if I'm in the wrong place. I e searched so this shouldn't be a double post

Target: Rush_blade_sport_v21

So I'm having issues with specifically ESC#3 becoming unrecognizable shortly after booting. I don't think it's hardware related because I have a few brand new out of the box ESCs/stacks all behaving the exact same way. I've contacted the mfg but have not gotten a response yet though they have been notified for days now.

I do have a couple of YouTube videos posted going through the exact way of reproduction.

Fresh lipo boot from cold. Connect USB and read ESCs shows all 4 ESCs read correctly. After a few moments ESC#3 becomes unknown. This is reproducible every time. Strangely sometimes booting will yield other ESCs randomly unreadable but 3 is fine. Then a reverify will render all readable but #3.

Here is a link to a playlist showing my findings. The last two videos are the ones to note.

https://youtube.com/playlist?list=PL-SXnNmzVbIFL7qBbpFXj9TFBYDNralYp

Edit: One of the errors consistently coming up is

Serial interface "m4wFCIntf" connected successfully Connection to ESC #3 failed. Check power and data connections etc ...

FC: Rush F722 Analog BF 4.2.9 (stock) and latest. Used target BladeF7. ESC: Rush blade sport Motors: Ethix silk v3 2450

[4712]

@Linuxbarista Really very strange. It is normal for ESC's sometimes not to connect, if they have had too little time without an input signal (between "Connect" and "Read Setup"). But once they are connected, the connection should remain absolute stable. To me this looks like a thermal problem. When the ESC is cold, the connection seems OK, but when the ESC warms up, the connection is lost. Just an idea... Are the engines running smoothly all the time?

[Linuxbarista]

@4712 so if you check the last video in that playlist it's just on the bench with nothing soldered to it at all. Literally brand new unsoldered hooked to bench power supply alligator clips. When I checked the ESC isn't even warm so thermally I don't think it's hardware related per say. I'm wondering if the FC could be part of the problem. I'm gonna try some more testing when I get off work today. Do you think disabling bi directional dshot would help, or possibly taking dshot down to 300 maybe? I'm still learning how FC and ESCs communication work.

[4712]

@Linuxbarista I see: no motors at all. Sure, the FC can be a part of the problem. But once the BLHeliSuite32 establishes a connection to the FC interface part of the FC ("Connect"), all FC motor outputs should stay constantly high, independent of the motor output protocol. Saying that, there are situations possible, which break the rules. Perhaps you could change the input wire of ESC3 connect to another FC output and test again.

[Linuxbarista]

@4712 Yep! My thoughts exactly! I was going to depin that longer connecter and repin the esc#3 to different motor I/o on the FC. I'm also going to try another FC to see if it would stabilize as well. If I do get a stabile connection Iay try and reflash #3 or all depending to see if that helps. In blheli I see master and slave escs. Does the master control the slaves or is everything independent and that's just a naming scheme? Could there possibly be an issue with the "master" needing to be refreshed and causing the slaves to drop/malfunction?

[4712]

@Linuxbarista The master is simply the first selected ESC with settings shown in the foreground. If you "Write Setup", by default the most parameters (beside of motor direction, LED and others... see "Options"), which should be common for all ESC, are written to the "master" and "copied" to all other selected ESCs. So: no, this is not the reason for the issue we see here.

[Linuxbarista]

I did some extensive testing yesterday.

To recap. Two brand new Rush Blade Sport Stacks. Esc #3 hangs on both ESCs.

The ESCs act up at random when a lipo is first plugged in from a cold start. Sometimes random ESCs will fail to read when first checked. Then after a unplug replug of the battery all ESCs will check but fail to read #3.

I was able to flash ESC#3 on both 4 in 1 ESCs from a cold boot and they verify against code flashed as OK. I have tried 32.8 as well as the test code base. Both ESCs still act the same. I have also reflashed and verified all ESCs on both and all verified as OK.

I have tried multiple flight controllers connected to these. Holybro kakute mini f7 v3 Holybro kakute mini F4 Mamba Mini F4 MKii Both Rush f722 FC that came in the stack.

I have tried multiple DSHOT BF options. I have tried with and without bi-direction enabled. I have tried just hooking up ESC#3 to multiple motor I/O ports. I did this for each flight controller and a couple of harnesses I pinned to rule out those being the issue. I also tried multiple version of BF regressing from 4.2.11 down to 4.2.9.

I believe there is something funky going on with the hardware of theses ESCs, or something wrong within the code for the rush_blade_sport_v21. I don't see anyone posting about these issues in any searching I've done. I don't think there's a lot of the v21 out there. All the "tube" reviewers seem to have gotten the older rush_blade_sport_v2 not v21.

I reached out to Rush and their only response has been to "try reflashing firmware.." The chips markers have been etched off all chips so it's not an easy tell if they have swapped to a different mpu or what's going on.

I'd like to leave this open so anyone with Rush hardware can chime in and maybe help out.