I’ve got some new APD 80F3[X] ESCs on my hex build and I am trying to implement Dshot. Each time I power cycle there is a different set of 4 arms that will work. This applies to ESC telemetry and motor spin. When I try to connect using the passthrough software that comes with these ESCs it detects all six connected so I think the connections are okay.
However, the ones that are not connected for that power cycle give out the Invalid Signal Detected Tone documented here. I have:
– Cube Orange
– APD 80F3[X] ESCs
How long are your lead lengths (signal wire) on that aircraft, and what is the gauge? Given you’re seeing varying behaviour in the signal detection within the ESC, it would suggest you’re right on the limit of what the ESC considers a valid signal. Try shortening the leads, and make sure they’re a twisted ground pair, and try again.
Another note worth considering, officially Ardupilot supports up to 4 Bi-Directional DShot outputs (see documentation here).
There is roughly 2 feet of signal wire, then a PDB, and then 6 more inches until it gets to the flight controller. Usually, it is arms 1, 4, and 6 in some combination of two that don’t work. If I disconnect, say, 2 and 3 then I get the other four working. I suspect it simply works for the first four that boot up.
I was told that Dshot inputs to the FC only work for 4 channels so you only get RPM-filtering based on 4 inputs but it should be able to spin all 6 motors anyway.
On a related note, the APD Configurator has a Diagnostics option which I presume is for sending SCPI commands to the ESC. Where is the documentation for that? Can I check noise levels that way?
I ran a quick test of your params, and took some traces to demonstrate what you’re seeing. The following is a DShot pulse train with similar wire lengths to what you’re running, measured at the ESC. It will occasionally accept this as a valid signal, but I wouldn’t fly with it:
Shortening the leads (to around 10 cm) and running the same measurement results in the following pulses, which are accepted:
You may see better performance on your end if you run the wires in a twisted pair configuration (if you haven’t already).
I’m not sure what the implication is, just following the Ardupilot documentation. One of the devs might be better suited to jump in here.
Diagnostics are for our debugging units during this Beta phase. It won’t return any status data.
Thanks, Vanja. You were spot on about the signal leads picking up noise. Thank you for the scope tests as well. When I shortened the length to about 4-6 inches (10 - 15 cm) all six ESCs were blinking normally. 50 cm of flat signal leads showed normally blinking LEDs as well. I think it will “accept” up to 60 cm of signal wire length flat but I don’t know what the quality of the signal will be. This begs a few questions:
How does one build this with anything that is not a small racing quad? My drone isn’t that big – 960 mm drivetrain. I can’t get the ESCs too close to the flight controller because they need to be cooled by the props + motors. Besides, there will then be long wires going to the motors which can also pick up noise?
Let’s say I get it to “accept” with 60 cm of length but there is noise pickup mid-flight. Will that be catastrophic?
I asked about that here. There is also someone who seemingly got it to work on a hex here.
Good to hear. Make sure they’re a twisted ground pair to keep the inductance as low as possible. Both good questions:
Lower loop rates and baud rates are usually recommended for anything outside racing. You can utilise additional inline hardware (such as Schmitt trigger buffers, etc) to supplement the drive output limitations of the Cube hardware. This one gets complex with bi-directional signalling such as required with RPM filtering. From an ESC point of view, we prefer shorter inputs when compared to outputs. This leaves your bus wires shorter too, and requires less capacitance. You are correct though, 3-phase motor wires generate a fair amount of EMC depending on power outputs. There is also the balance of cooling to consider.
You will need to lose 500ms worth of packets for the ESC to shut down the drive (lots of consecutive when running DShot). We do have a reporting system for signal quality since power up (see here). The criteria for ‘bad’ signal is the detection of a greater number of failed pulse trains vs passed trains at any given time. Keep in mind DShot throttle commands are checksum protected, so it is unlikely noise will make it from the signal line to motor drive output.
Great answer, Vanja. Thanks again. I suppose I’ll have to test it out on a scope like you did. Can you help me interpret your scope plots? What indicates a “bad” signal line exactly? The amplitude is < 3.3V in the first plot. What else am I looking for?
While having a 3.3 V signal is important, in this case, it’s the pulses themselves that are the source of the issue. A closer look at the first capture from my reply above can be found below, where you can see ringing occurring during rising/falling edges.
DShot is very timing critical, and such ringing will trigger false readings, which the ESC is treating as noisy/failing packets. What we want to see in the above are well defined, ‘square’ pulses within the pulse train.
Here is what I have with some scope tests of my own. I tested with a 150 cm signal line and a 15 cm long signal line to an oscilloscope. In both cases I see very little difference in noise but it is enough to make the ESC stop working. Some plots attached below.
All wires were flat and untwisted. I am just trying to characterize the ESC behavior wrt wire length. Did I do this right? Do you have a spec on how much noise the ESC can tolerate? I am concerned that even with twisting wires, adding ferrite beads, or metal shielding there could be some noise pickup mid-flight which would cause them to shut down. What do you think?
How have you wired the above? The voltage is quite low (remembering the cube outputs >3 V).
The units are most sensitive to noise during the initial phase of signal acquisition, as all the filtering is turned down to allow detection of high speed pulse trains (DSHOT1200, etc).
Once the signal is acquired, the appropriate filtering is applied for that rate. A cause for concern would be once the signal is acquired, the detection/rejection of a vast number of incoming packets is still occurring (this tone is played). Remember that for the units to shut down, there needs to be 500ms of no signal at all.
I was seeing 3-3.3V for the most part. The screenshots above show the amplitude for the window that it is currently set at (I have zoomed in to see the ripples).
The noise profile seems pink in nature but when I look at it in Fourier space I can barely resolve the difference between the 150 cm and 15 cm case. What type of filters do they have? High pass?
Hmph. Wonder why I am seeing less noise on the scope. What baud rate have you set it at?
I think I am just going to twist the cables, add some metal shielding and some ferrite beads for good measure. This is probably overkill but my drone can take the additional weight and I would rather err on the side of caution.
It’s worth noting that for racing quads they often use 4-in-1 ESCs in a stack with the FC. It’s better electrically to have long wires from the ESC to the motor than long wires from the battery (and FC) to the ESC.
I’ve had some 10-15 gentle hover tests with the drone and new APD ESCs for tuning my PIDs. However, off late I am noticing this:
This happens when I am throttling up for an Alt Hold test. Sometimes this happens and I just throttle up and it flies okay but off late it is happening a lot and I am concerned it is indicative of a more serious underlying problem. I checked the motors with my old PWM ESCs on the bench and they spun just fine so it’s not the motors. I am going to try spinning them up with the APD ESCs but I was wondering if you have seen something like this before.
I also tried changing from Dshot600 to Dshot150 but that didn’t fix this issue.
Definitely a cause for concern. If you move that ESC around, does the issue remain with the channel (indicating a wiring/motor issue), or follow the ESC (indicating an ESC hardware issue)?
Does increasing MOT_SPIN_ARM,0.07 a bit change the behaviour?
In the video it actually looks like a connection problem between motor and ESC.
Have you tried the ordinary Cube firmware instead of BiDir-DShot ? I could be wrong but I thought the bi-dir DSHOT was only tested with quads, but it might be OK for a hex or octo, unsure…
You would need to have the telem wires joined and connected to a RX pin of a serial port, and a couple of suitable params for that to work.
I would DEFINITELY be setting the BATT_FS_ params.
