Hello,

How can we go about reviewing our VOXL2 carrier board with the Modal AI team?

@Alex-Kushleyev That’s very helpful if disabling regenerative braking is working as intended, then it sounds like that addresses the primary concern on our bench-supply side.

From the flight-controller dynamics side, we’d still generally prefer to keep braking enabled in the long run, but handling the FC tuning impact is something we’re comfortable with. The main blocker for us has been finding a clean way to absorb regenerative energy on the bench supply during decel events.

Given that regen disable appears to solve that issue, we’ll plan to proceed with controlled validation on our motor/prop combination while monitoring bus voltage during transients.

A couple follow-up questions:

• list item Would you recommend exposing regenerative braking disable as a user parameter, or is this better handled as a custom firmware build for this application?
• list item Did you end up making any ESC tuning parameter changes when testing in this mode, especially for a lower-kV / larger-prop setup? If so, would you be willing to share those changes?

Can a GPS and Magnetometer be connected through the Legacy or High Speed B2B connectors? Or is J19 the only interface with the spli_proc?

@Alex-Kushleyev appreciate the assist here. I'll follow up next week!

@Alex-Kushleyev thank you, this is exactly what we were hoping to hear.

Given our power architecture, we’d strongly prefer to disable regenerative braking entirely to avoid any back-feed / bus overvoltage corner cases. We’re effectively hovering with “infinite” available source power, so we’re not trying to harvest regen energy coasting down is totally acceptable for our use case.

For the exact prop: we’re currently baselining an APC 13x5.5MRF-R(B) (13” diameter, 5.5” pitch, folding multi-rotor blades). https://www.apcprop.com/product/13x5-5mrf-rb/?v=7516fd43adaa

We can definitely focus on tuning once we’re on the bench. We did see the low-kV tuning note you linked (and it’s reassuring you’ve already used MN4006 with an even larger prop in the example).

If you’re able to expose the “regen off” option via a param or share a firmware build with regen disabled, we’d love to start with that as our default configuration. Are there any specific caveats you want us to be aware of when regen is disabled beyond the slower coast-down / mapping differences you mentioned?

Thanks again your tests and guidance are helping us de-risk the design decisions before we commit to hardware.

@Alex-Kushleyev

For context on our side: we’re looking at an MN4006 380KV motor with a 13” prop, and our system will be powered from an external DC source via a DC-DC power module (not a conventional LiPo-style source), so we’re trying to be very deliberate about regen / bus overvoltage from decel events.

We’re still in feasibility / design phase and don’t have physical hardware spun yet, so we’re leaning heavily on your recommendations to make sure we bake in the right mitigations from the start.

Based on what you shared, our intended approach is:

• Configure for no braking: brake_to_stop=0 (coast on stop/timeout).
• Treat decel as the main risk: implement slew-rate limiting / avoid hard high low RPM steps (similar to the voxl-esc-spin-step.py approach you referenced).
• Design the input protection around an external DC bus:
• Bulk capacitance at the ESC input, physically close to the ESC, and
• Additional parallel TVS near the ESC input to share transient energy/thermal load.

Since we don’t have hardware assembled, could you sanity-check a couple design-direction items?

• For a larger inertia setup (13” prop), do you have a starting point / rule-of-thumb for how much bulk capacitance you’d place at the ESC input (order of magnitude is fine)?
• When you say “parallel TVS,” is your intent more like multiple identical parts in parallel close to the ESC, or targeting a total TVS power/energy capability? Any rough guidance there would help.
• Is there anything else you’d recommend we do upstream (e.g., supply-side clamp strategy, or constraints on allowable decel) given the source may not be able to sink current?
• Really appreciate your help we’ll incorporate your guidance into the design and share what we decide / what we observe once we get to bench testing.

We’re bringing up a system using a bench power supply at ~25 VDC with the VOXL FPV Racing 4-in-1 ESC (M0138) and want to avoid any risk from regenerative braking / bus overvoltage.

Braking disable / configuration

• Can you confirm whether brake_to_stop exists and is supported on M0138, and whether setting brake_to_stop = 0 will ensure the ESC does not brake on stop/timeout (coast instead)?
• Is there any supported method on M0138 to disable regenerative braking during commanded deceleration (not just stop/timeout), or is that currently not supported in firmware?

TVS diode protection at 25 VDC bench supply
Given your regenerative braking note about power supplies not sinking current and the TVS dissipating energy during clamp, what is your recommended protection approach for M0138 when using a bench supply near 25V? Specifically:

• What are the TVS clamp voltage and power/energy limits (part number or equivalent rating)?
  * Recommended external mitigation: would you prefer
  * a 4-quadrant / sink-capable supply,
  * adding an external battery/supercap “sink” in parallel,
  * an external brake/shunt (dump resistor/regulator),
  * additional bulk capacitance (and any sizing guidance),
  * or other best practices?
• Any operational limits you recommend for bench testing (e.g., avoid step-down commands, limit max PWM / rpm, etc.)?

If you have a recommended parameter set or test procedure specifically for M0138 + bench supply bring-up, we’d appreciate it.

We ordered MDK-M0048-3-01 but we wanted to use it as the pDDL Carrier to a laptop. Essentially turn it into a MDK-M0048-2-01. We soldered on the connector for the USB to Host PC/Tablet but can't get the device to show up on the network.