As the title says I am dealing with lots of esc errors in the logs. These are am32 holybro tekko single esc’s
I am trying to figure out how to reduce them and what may cause it?
Advice needed on how to fix.
Thing I have tried with no help.
Changed ESC’s
Changed flight conroller
Lowered dhsot to 300
increased and decreased
| SERVO_DSHOT_RATE |
|---|
Changed ramp rate and min duty cycle and nothing seems to make it better.
I remember struggling similarly with pretty much the same ESC (originally flashed with BlHeli32 but reflashed to AM32 - if I remember correctly which is which; I have two but only one got flashed with AM32, around the time I was adding EDTv2 support, not realising that it’s only supported by Bluejay, likely even as of now).
The tribal knowledge seems to suggest that AM32 likes DShot600 and a higher than usual servo rate (like 2 or 4 kHz), and I believe you want to avoid connecting it to IOMCU.
But I don’t remember resolving that issue; the machine where it manifests has few other funny hardware/control problems, and I would consider myself lucky if I return to it within the current month…
For most bdshot setups, servo update rate should always be above 1KHz.
Is it?
Yes its quad loop rate, loop is 400.
You can actually enter more than 4. With the rate of 400 Hz, 5 = 2kHz, and so on. It does work (but I am not sure it will resolve your issue).
what AM32 firmware version? What AM32 bootloader? also give me the full set of AM32 parameters
Its am32 2.20, I will get the rest of the information tomorrow. The bootloader is on the configuration screen?
I have varied the timing up to 15%, ramp rate up to 9%, min duty cycle up to 2% all with no change.
We have another report here of ESC errors appear in the AP logs (e.g. ESC.Err field) but using a different type of ESC (Hargrave ESCs)
This makes me suspicious that we have an issue in AP’s DShot telemetry message parsing (see code here)
One of the first things we need to narrow down on is when this happens. For example:
For 1 (“do all DShot ESCs always produce a lot of errors?”), my experience with near-master builds tells that the answer is false: my Bluejay ESCs (at least two different machines) don’t produce errors (except for (sometimes) startup and shutdown, and only rarely fractions of % in flight), and I have at least one other AM32-based machine where it’s the same.
For 2… yes, as this happens for me on a single-copter. It’s a machine based on Pixhawk6C, so the ESC is on channel 9 (ESC[8].Err) as of now if that matters. I don’t remember why exactly I’m not feeding it via IOMCU, but possibly because I tried to solve the issue by getting to higher tiers of DShot.
For 3, yes, my single-copter also produced 50% errors with the same ESC as the topic starter, where the version reported in the logs was 4.6. This was likely one of the stable versions because I wasn’t tinkering with the frame code at that moment.
My experience is…
Blujay, blheli32, AM32 esc’s all produced errors, I havent rolled back the firmware to see just yet.
The errors seem (in my trial and error/testing) higher if the capacitors aren’t soldered directly to the esc’s or aren’t enough for the amount of current requested by the FC.
I’ve been seeing this for a while on AM32.
Some errors are normal - the lines are noisy and the CRC is not strong. Anything over 1% should be considered abnormal and is usually a hardware issue. Most ESCs should show 0% errors in the common case with some occasional spikes
Just wanted to bump this and see if any testing has been completed to see if there is a fix?
I think one thing that is needed moving forward is…
Am32 settings/template that cover all different prop sizes and flight styles. Just a broad approach, nothing specific.
I wasn’t able to figure out anything with my limited testing.
Hi @prsh8ya,
The latest info I have is that we may have an issue in AP’s logging if less than 4 ESCs are connected. I hope to verify whether this is true or not in the coming days.
I’m definitely not saying that all errors shown in the logs are caused by this issue though. This is just one situation where AP may not be reporting the errors correctly and so it’s an actionable issue that the AP dev team can do something about it.
