How to interpret ESC-Err in the logs?

Earthchill · July 19, 2024, 7:26pm

I noticed that I got ESC-Err up to 40 when changing the throttle rapidly. What does that mean and how serious is it? How do I debug it?

I’m attaching a log at the bench without props.

ESC Err.zip (355.6 KB)

Oli1 · July 19, 2024, 9:51pm

Pretty sure it’s the percentage of bad telemetry packets. Regular serial ESC telemetry doesn’t have a dedicated error bit like EDTv2 does.

As for how serious it is, I would keep it in the back of the head, but if it goes away once props are attached I wouldn’t worry. Without props you’re basically running ESCs and motors off-spec.

Earthchill · July 20, 2024, 2:59pm

I tried with props but the error rates look the same. My guess is that it is the signal cable running in parallell with the power cables to the ESCs.

But if it’s just the telemetry the plane won’t crash if it misses some RPM readings. Throttle response is good enough. Since it is a plane a couple of milli-seconds of delay doesn’t really matter (if the error rate is the same for the signal in the other direction). The airframe is cheap and light (foam board) so I’ll try flying it tomorrow unless anyone sees any other risks.

with props.zip (499.6 KB)

Oli1 · July 20, 2024, 5:40pm

If your ESCs and FC support it you can try flashing a BDShot firmware and configure EDTv2 telemetry. That way you get info about actual ESC errors, e.g. desync, demag events.

But yeah, I’d just send it too. No need to obsess over something that likely isn’t an issue.

Earthchill · July 20, 2024, 8:07pm

I’ve updated the ESC firmware and did a quick test without props but did not get the extended telemetry (from the pull request I understand it as it would have the name EDT2?).

Do I need to enable any additional setting in the configuration? I’m running Arduplane 4.5.4, MatekF405-Wing-bdshot.

I’ve long since I admitted that I like looking at logs and telemetry even though I just get more ancious by doing so . The weather forecast still looks good for tomorrow so I’ll fly then.

Oli1 · July 20, 2024, 9:42pm

Yep, should be under EDT2 in the logs.

SERVO_DSHOT_ESC,3, but not all ESCs support it, you’ll have to try and find out. Also, BLHeli32 needs to be version 32.7+. If it isn’t you’re out of luck because of a certain closed source software company…

Earthchill · July 21, 2024, 12:13pm

I set SERVO_DSHOT_ESC=3 this morning. I had multiple sucessfull flights. I did not get any EDT2 logs. I’m using Bluejay 0.21 on two EMAX D-Shot Bullet series ESCs and as previously mentioned the FC is running Arduplane 4.5.4 with the MatekF405-Wing-bdshot firmware. Is there anything else I can do to determine why I don’t get the EDT2-logs?

On the last flight the auto-take-off decided to level out at 2-3 meters and turn into a hawthorn bush at full throttle. Looking at the logs the RPM, current and airspeed was the same as on other flights. So it wasn’t a ESC issue. I will start another thread trying to determine the root cause of that accident since it is unrelated.

Oli1 · July 21, 2024, 1:15pm

Sorry pal, I just assumed you were using BLHeli32. For Bluejay SERVO_DSHOT_ESC,4 might work.

Earthchill · July 21, 2024, 2:29pm

It used to have a value of 1 and work so I assumed that 3 would be correct. If I had 2 previously, I would have tried 4. That hardest part is finding the right parameter to change. I guess it worked with 1 since I didn’t use any commands that were different between BLHeli_S and 32.

Once I got the plane patched up, I will try the with 4 instead.

Here’s the thread where I describe the crash at take-off.

Earthchill · July 25, 2024, 1:15pm

I flew again and ran autotune a couple of times. While doing that I had SERVO_DSHOT_ESC,4. Still no EDT2 in the logs.

Power felt completely fine so I do not think I’ll pursue this more. I get RPM and the filtering works perfectly. That’s the important part and what I could expect from the cheapest ESC I could find that supported BDSHOT. Thanks for the help!

MaxBuzz · July 25, 2024, 2:04pm

The EDTv2 support is I believe not yet available in the 4.5 branch. It’s merged into master and should likely appear in 4.6.

It’s most useful with Bluejay, but AM32 has plans to support it too (source: Discord messages).

Earthchill · July 25, 2024, 2:06pm

Thanks, I’ll check again once there is a RC of 4.6 then.

dkemxr · July 25, 2024, 2:50pm

It was working as of 4.5-DEV so it should work in current Stable.

MaxBuzz · July 25, 2024, 2:54pm

I don’t see this in the Copter-4.5 branch, in particular, here:

github.com

ArduPilot/ardupilot/blob/847a2f5629bab641dff08d3a7da9c039824c4a9d/libraries/AP_ESC_Telem/AP_ESC_Telem.cpp#L560


      
                              voltage     : _telem_data[i].voltage,
                              current     : _telem_data[i].current,
                              esc_temp    : _telem_data[i].temperature_cdeg,
                              current_tot : _telem_data[i].consumption_mah,
                              motor_temp  : _telem_data[i].motor_temp_cdeg,
                              error_rate  : _rpm_data[i].error_rate
                          };
                          AP::logger().WriteBlock(&pkt, sizeof(pkt));
                          _last_telem_log_ms[i] = _telem_data[i].last_update_ms;
                          _last_rpm_log_us[i] = _rpm_data[i].last_update_us;
                      }
                  }
          #endif  // HAL_LOGGING_ENABLED
          
                  if ((now_us - _rpm_data[i].last_update_us) > ESC_RPM_DATA_TIMEOUT_US) {
                      _rpm_data[i].data_valid = false;
                  }
              }
          }
          
          bool AP_ESC_Telem::rpm_data_within_timeout (const volatile AP_ESC_Telem_Backend::RpmData &instance, const uint32_t now_us, const uint32_t timeout_us)

which should be roughly like this for EDTv2 to work:

github.com

ArduPilot/ardupilot/blob/f849187333b02a898b7cb9e07117eada751f2045/libraries/AP_ESC_Telem/AP_ESC_Telem.cpp#L639


      
                              current_tot : telemdata.consumption_mah,
                              motor_temp  : telemdata.motor_temp_cdeg,
                              error_rate  : rpmdata.error_rate
                          };
                          AP::logger().WriteBlock(&pkt, sizeof(pkt));
                          _last_telem_log_ms[i] = telemdata.last_update_ms;
                          _last_rpm_log_us[i] = rpmdata.last_update_us;
                      }
          
          #if AP_EXTENDED_DSHOT_TELEM_V2_ENABLED
                      // Write an EDTv2 message, if there is any update
                      uint16_t edt2_status = telemdata.edt2_status;
                      uint16_t edt2_stress = telemdata.edt2_stress;
                      if (EDT2_HAS_NEW_DATA(edt2_status | edt2_stress)) {
                          // Could probably be faster/smaller with bitmasking, but not sure
                          uint8_t status = 0;
                          if (EDT2_HAS_NEW_DATA(edt2_stress)) {
                              status |= uint8_t(log_Edt2_Status::HAS_STRESS_DATA);
                          }
                          if (EDT2_HAS_NEW_DATA(edt2_status)) {
                              status |= uint8_t(log_Edt2_Status::HAS_STATUS_DATA);

The basic EDT with RPMs and error percentages has of course been available for quite a while.

dkemxr · July 25, 2024, 2:59pm

I’m getting it on V4.5.4 with a BLHeli_32 ESC V32.10. RPM, Voltage and Temperature.

MaxBuzz · July 25, 2024, 3:01pm

That’s EDT but not EDTv2. The latter offers bits about desyncs, demag and stall events, as well as commutation stress. BlHeli32 does not report that, although it sends some frames when not armed that get parsed by this logic.

dkemxr · July 25, 2024, 3:03pm

Yes, you are right. I missed the v2 part.