Bringing a Dead Takuma Cruiser V1 Back to Life

[Jb69]

I bought an old Takuma Cruiser V1 knowing the original remote had been drowned and was dead. That left a fairly obvious question: was it just the remote, or was there more wrong with it?

The board itself was complete. Battery, mast, foil, motor, gearbox and electronics enclosure were all there, and most of it looked too good to throw away. I wasn’t interested in turning it into something it was never designed to be. I just wanted to get the thing working so I could go efoiling.

Getting control of the original ESC

The first useful clue came from posts here on FOIL.zone.

Other people had already worked out that the original Takuma ESC could be driven from a Flipsky VX3 receiver using the PWM connections on the Takuma interface board. Credit where it’s due — that saved me a lot of unnecessary reverse engineering.

The Takuma board even makes life fairly easy because the connections are labelled PWMOUT, PWMVCC and PWMGND.

I wired the VX3 receiver into those connections and got throttle control back.

Unfortunately, pulling the trigger didn’t result in a happily spinning motor.

It stuttered badly.

With the gearbox connected it sounded like something mechanical was destroying itself, but once I removed the gearbox the noise disappeared while the motor still stuttered. The gearbox was really just amplifying the repeated kicks from a motor that wasn’t commutating properly.

The three phase resistances all looked similar on a multimeter and there wasn’t anything obviously open-circuit in the motor.

The original ESC heatsink was warming up as well, so it was definitely switching current.

At that stage the ESC was looking suspicious, but I still didn’t know whether the motor itself had a problem.

A cheap way to answer the question

Rather than keep guessing, I bought a Flipsky Mini FSESC 6.8 60V/100A.

The ESC itself was about US$76, so it was a fairly inexpensive way of finding out what was actually broken.

If the motor still stuttered on the Flipsky, I would keep looking at the motor and wiring.

If it ran properly, the answer was pretty obvious.

I also bought the Flipsky BLE module. Initially that was simply because VESC Tool would let me see what the controller was actually doing rather than diagnosing everything by sound, smell and touching things to see whether they were getting hot.

There was still one unknown before any of this was useful: the original Takuma battery.

The original battery works

The Cruiser V1 battery is a 12S lithium-ion pack, 43.2V nominal, 35Ah and about 1.5kWh, with a 50.4V maximum charge voltage.

There are several small connections between the battery and the original Takuma electronics, so I wasn’t sure whether the BMS expected to see the factory ESC before it would allow normal discharge.

Apparently it doesn’t.

The battery powers the Flipsky normally and remains enabled under load.

That was a fairly important result because it meant I didn’t need to replace a perfectly serviceable battery simply because the original controller had failed.

The motor just worked

I connected the original Takuma motor to the Flipsky and ran motor detection in VESC Tool.

Detection succeeded immediately.

Then I ran the motor.

Smooth.

No stuttering.

I refitted the planetary gearbox and tried again.

Still smooth.

That pretty much answered the original question. The Takuma battery was fine, the motor was fine and the gearbox was fine.

The original ESC was the failed part.

That little US$76 controller had gone from being a diagnostic tool to being the repair.

The size difference is ridiculous

One of the more interesting things about this job is simply putting the old and new electronics next to each other.

The original Takuma power section is substantial. Large FET board, big capacitor bank, heavy phase wiring and a proper thermal arrangement built into the enclosure.

The Flipsky Mini looks tiny sitting in the same space.

That doesn’t mean Takuma did a bad job. It shows how far motor-control electronics have moved on. Modern MOSFETs, gate drivers, PCB integration and VESC firmware put a surprising amount of capability into a very small package.

And unlike the original controller, I now have sensorless FOC, adjustable current limits, live voltage and current information, temperature monitoring, fault reporting and proper logging.

That visibility has probably been one of the biggest improvements.

Keeping the good Takuma engineering

I’ve deliberately kept as much of the original Takuma hardware as possible.

The original waterproof connectors are still being used. So is the contactor, the enclosure and its thermal hardware.

The Takuma electronics enclosure is plastic, but the original ESC used a large copper-looking heat spreader inside it. That plate appears to be electrically floating and was obviously intended to take heat away from the power electronics.

The Flipsky comes with its own small finned aluminium heatsink. I originally considered removing it and coupling the FETs directly to the Takuma heat spreader.

Then I had a closer look.

The Flipsky heatsink appears to be bonded directly to the FETs with thermal adhesive. Trying to remove it seemed like a very good way of turning a working ESC into a broken one.

So I left it alone.

Instead, the Flipsky heatsink is being thermally coupled to the original Takuma heat spreader.

I designed a simple 3D-printed clamp that uses the existing Takuma mounting points to hold the controller firmly against the plate. The first PLA prototype worked surprisingly well. A couple of mounting holes need moving slightly, but mechanically the idea is sound.

The important part is that the clamp bosses sit beside the wiring and clear the components rather than putting pressure directly onto capacitors, connectors or solder joints.

Once the dimensions are final I’ll print it in something more appropriate for long-term use, probably ASA or PETG.

The thermal tests look promising

I’ve already run the controller with the new thermal arrangement while logging the ESC through VESC Tool.

In the latest bench test the MOSFET temperature peaked at only about 35°C.

More interestingly, the log also captured the cool-down after the motor stopped. The controller dropped from roughly 35°C to around 31°C in about half a minute.

That at least shows that heat is moving away from the controller rather than simply being trapped in the little Flipsky heatsink.

The proper test will obviously be with the enclosure closed and the foil in the water, but so far there’s nothing suggesting the thermal arrangement is going to be a problem.

VX3 for throttle, Bluetooth for everything else

The VX3 receiver can communicate with a VESC over UART, and I tried that.

The problem is that the BLE module also wants the UART connection.

During development, Bluetooth is much more useful to me.

So the VX3 is connected using PPM and the BLE module gets UART.

The remote still does the important job — throttle.

The phone gives me the interesting stuff: voltage, battery current, motor current, duty cycle, eRPM, temperatures, faults and logging.

That also lets me work on the throttle response properly. I’m currently adjusting the PPM response and throttle curve so there is more usable trigger movement in the higher-power part of the range rather than wasting lots of travel at very low throttle.

That’s tuning rather than troubleshooting, which is a nice place to finally be.

The Bluetooth module may not even be permanent

One of the useful things about VESC is that the configuration can be exported.

Once I’ve finished the wet testing and have a setup I’m happy with for the original Takuma motor, gearbox, battery and the Flipsky Mini, I can save that profile.

That means another Cruiser V1 owner could potentially load a known working configuration into VESC Tool rather than starting from scratch.

At that point Bluetooth becomes optional. You could install the configuration, verify everything behaves properly and then remove the BLE module if you don’t want it permanently fitted…

What actually needed replacing?

Very little.

The board is still a Takuma Cruiser V1.

It still has its original battery, motor, planetary gearbox, mast, foil, connectors, contactor, enclosure and thermal hardware.

The drowned remote was replaced by the VX3 and the failed ESC was replaced by the Flipsky.

That’s it.

The aim was never to reinvent it.

I just wanted to fix it.

Now I’m running out of excuses not to put it in the water.

Photo caption: The Flipsky Mini FSESC installed in the original Takuma Cruiser V1 electronics enclosure. The size difference from the original power electronics is dramatic, while the original battery, motor, gearbox, connectors and thermal hardware all remain in service.

[Jb69]

Update: first water testing, VESC tuning and the next round of changes

I finally got the Takuma Cruiser V1 back in the water with the original Takuma prop and shroud.

This was the first test where the replacement VESC was seeing a real hydrodynamic load rather than just spinning the drivetrain on the bench, and it answered a lot of questions very quickly.

The good news is that the basic conversion works.

The original Takuma battery, motor and planetary gearbox all run properly from the Flipsky controller, the original prop produces plenty of static thrust, and the board is now genuinely usable again.

The first proper water test also showed where the next improvements need to be.

Current VESC setup

After experimenting with higher current limits, I’ve settled on the following setup for the original drivetrain:

• FOC sensorless
• Current, No Reverse
• 80A maximum motor current
• 60A maximum battery current
• 98% maximum duty cycle
• 100,000 maximum eRPM
• VX3 remote over PPM
• Flipsky BLE module over UART

The original Takuma battery is a 12S pack, 43.2V nominal and 50.4V fully charged, so a 60A battery-current limit gives roughly 3kW of available electrical input.

That lines up reasonably well with the commonly quoted 3kW rating of the original Takuma motor.

The 80A motor-current limit is separate from the battery-current limit. It allows the VESC to provide plenty of phase current and torque at lower motor speed without requiring the battery to continuously supply 80A.

Why I stayed with current control

I experimented with the idea of using PID speed control, but I’ve gone back to Current, No Reverse.

That makes more sense for an efoil.

The throttle effectively requests torque rather than RPM.

While the board is still pushing through the water, the propeller is heavily loaded and the motor needs substantial torque.

Once the board gets onto the foil, drag should fall dramatically, the propeller should unload and motor RPM should naturally increase.

I don’t really want the controller trying to hold a particular prop RPM.

I want it to provide the requested torque and let the motor spin as fast as the available voltage and hydrodynamic load allow.

Finding an artificial top-speed limit

During the bench testing I kept seeing the motor stop accelerating at around 65,000 eRPM.

Every time it happened, the VESC was sitting almost exactly at 95% duty cycle.

The configured maximum duty was also 95%.

I increased that to 98% and repeated the test.

The motor then reached approximately 66,500 eRPM.

So the previous top end wasn’t caused by the configured eRPM limit. That is set at 100,000 eRPM and isn’t currently relevant.

The 95% duty setting really was acting as an artificial voltage/RPM ceiling.

I’m leaving maximum duty at 98% rather than going all the way to 100%. That recovers most of the available top end while still leaving a little PWM/control margin.

Working out the actual prop RPM

One thing that had been annoying me was that VESC Tool reports electrical RPM, not actual propeller RPM.

So I did a bit more work to establish the relationship.

The Takuma uses a 4:1 planetary gearbox.

I also recorded the output shaft with a single tape marker at 240fps while logging VESC eRPM.

At around 8,800–9,000 eRPM, the measured shaft speed was around 700rpm.

That fits very closely with the motor being 6-pole, or 3 pole pairs.

That gives:

Motor RPM = eRPM / 3

and after the 4:1 gearbox:

Prop RPM = eRPM / 12

That makes the VESC logs much easier to understand.

Some useful examples are:

• 42,000 eRPM = ~3,500 prop RPM
• 50,000 eRPM = ~4,167 prop RPM
• 58,354 eRPM = ~4,863 prop RPM
• 60,000 eRPM = 5,000 prop RPM
• 66,542 eRPM = ~5,545 prop RPM

So we now have a fairly good picture of the real operating range of the original Takuma propeller rather than just looking at abstract eRPM numbers.

First real water test

The first water test was done with the original Takuma prop and shroud.

Conditions weren’t ideal. There was quite a bit of chop and I could really only get useful acceleration running downwind.

The complete session recorded approximately:

• 78.5A peak battery current
• 96.3A peak motor current
• 81.2°C peak MOSFET temperature
• 58,354 eRPM maximum under water load
• 10.8km/h peak GPS speed

The motor therefore reached about:

58,354 / 12 = ~4,863 prop RPM

under the heaviest useful water test.

One of the cleaner moving runs was roughly:

• 76A motor current
• 52A battery current
• ~50,000 eRPM
• ~4,170 prop RPM
• 10.8km/h peak GPS speed

The important thing is that the motor was nowhere near its unloaded ~5,500rpm prop speed.

The propeller was genuinely loaded.

Static thrust isn’t the problem

I also did several tests standing in front of the board and holding it stationary while applying throttle.

These show up very clearly in the logs because there is high motor current and high RPM but essentially zero GPS speed.

At full throttle I couldn’t actually hold the board stationary.

It pushed me backwards through the sand.

So the system has plenty of static thrust.

The problem seems to be that the board spends too long in the high-drag transition phase without quite getting enough forward speed to break free and foil.

That is also the worst possible condition for the ESC.

The motor is heavily loaded, phase current is high, battery power is high and the board hasn’t yet reached the point where hydrodynamic drag falls away.

The thermal problem showed up immediately

The bench testing made the cooling look almost trivial.

The water testing didn’t.

During longer high-power runs, MOSFET temperature climbed into the low 80s Celsius.

At one point I was experimenting with motor-current limits around 120A, and the controller heated very quickly and produced over-current cut-outs.

Dropping back to 80A motor / 60A battery made the system much happier and gave me some decent sustained runs.

That showed me two things.

First, I don’t need enormous current limits to make the original Takuma drivetrain work.

Second, the 100A Mini VESC was being pushed closer to its thermal limits than I really wanted for a sealed marine installation.

Moving to the 150A Flipsky Mini

For the final installation I’ve decided to upgrade the controller to the:

Flipsky Mini V6.8 PLUS 60V 150A, VESC-based

This isn’t because I suddenly want to put 150A through the Takuma motor.

The operating limits will still initially stay around:

• 100A motor current
• 80A battery current
• 95% maximum duty
• Current, No Reverse

The reason for the larger controller is headroom.

I want the controller operating comfortably within its electrical and thermal capability rather than sitting near its limits every time the board spends 30 or 40 seconds trying to get onto foil.

The original 100A Mini was excellent for proving the whole conversion.

It showed that the Takuma battery, motor and gearbox were all healthy and that the original drivetrain could be run properly from a modern VESC.

The 150A Mini PLUS is intended to be the more permanent installation.

Using the original Takuma heatsink properly

I’m also changing the thermal installation.

The original Takuma enclosure already has a substantial heat-spreader plate that was designed to cool the factory ESC.

With the first Flipsky Mini I kept its own finned aluminium heatsink intact and thermally coupled that to the Takuma plate.

That worked, but the first water test showed that the thermal resistance between the VESC and the Takuma heat spreader was still too high for sustained high-current operation.

With the 150A Mini PLUS I’m going to do it properly.

The plan is to remove the Flipsky aluminium case/heatsink assembly and mount the controller so that the MOSFET thermal surface is coupled directly to the original Takuma heat spreader.

The intended thermal path becomes:

MOSFETs → electrically appropriate thermal interface → Takuma heat spreader

That removes an entire intermediate heatsink/interface from the thermal path.

Before doing that I’ll obviously verify exactly what is electrically exposed on the MOSFET thermal side and use an electrically insulating thermal interface if required.

But mechanically and thermally, using the large Takuma plate directly should be a much better solution than putting a small finned heatsink inside a sealed enclosure.

Next test: more propeller blade area

Before changing the ESC and cooling arrangement, I’m doing one more useful A/B test.

I’ve printed a propeller with substantially more blade area.

The VESC settings will stay the same:

• 80A motor
• 60A battery
• 98% duty
• Current, No Reverse

That means the propeller is the main variable.

The idea is not necessarily to chase a higher maximum prop RPM.

What I really want is more useful thrust at lower board speed.

At the moment the board is spending too long wallowing at high power without quite reaching the point where the foil starts carrying the load.

If the larger-area prop can accelerate the board harder at lower speed, it may get through that transition sooner.

Once the foil starts flying, drag should fall significantly.

At that point the propeller should unload, motor RPM should rise and the amount of time the ESC spends at 70–80A phase current should drop.

So the next test isn’t really about maximum speed.

I’ll be comparing:

• acceleration
• GPS speed
• motor current
• battery current
• eRPM
• calculated prop RPM
• duty cycle
• MOSFET temperature
• time spent at high current

If the larger prop gives me a short, hard acceleration followed by lower current and higher RPM once the board is moving, that will be a much better result than simply seeing a bigger unloaded RPM number.

The Cruiser is definitely alive again.

At this point I’m no longer trying to diagnose a dead efoil.

I’m tuning the original drivetrain so it gets onto the foil cleanly and making sure the electronics can comfortably survive doing it.

[Jb69]

Update: the 150A ESC, and three traps on the way to a running motor

Last time I said the 100A Flipsky Mini was the wrong size for this drive and that a Mini V6.8 Plus 150A was on the way. It arrived, and setting it up took a full day on the bench, because almost nothing about it behaved like the 100A one until I understood why. The reasons are worth writing down: they’re not specific to this board, and any of them would have cost a day on the water instead.

Short version: the ESC now runs the Takuma drive properly, starts cleanly from the trigger at any current, is limited to 170A motor and 100A battery with a gearbox rev guard, and logs to my watch without a phone on the water. Here’s how it got there.

Trap 1: the firmware you flash decides what the ESC can measure

The Plus reports itself to VESC Tool as hardware “60”, the generic VESC 6. Flipsky’s own upgrade guide tells you to flash the standard “60” firmware, so I did (7.00). Two things then happened.

First, VESC Tool refused anything above 120A motor / 160A absolute: the generic 60 build carries those as hardware limits, and it clips a 150A/200A board to them. The 60_no_limits build in VESC Tool’s own archive (tick “show non-default firmwares”) removes that.

Second, and worse: motor detection measured the winding at 21 to 31mΩ, where the 100A Mini had measured 12.2mΩ on the same motor two weeks earlier. The generic 60 firmware assumes 0.5mΩ current shunts. The Plus, like the VESC 6 HP, has 0.3mΩ shunts, which makes sense for a 150A board (0.5mΩ would dissipate 11W per shunt at 150A). So every current the ESC reported was 60% of the truth: a “120A” limit was 200A at the motor, the absolute trip was 267A, and the FOC gains computed from the wrong resistance made the current loop ring. In current control the motor just ground and ticked and tripped the over-current guard every start; under speed control it limped.

The check that nailed it needed no instrument: the 100A Mini’s bench log had the unloaded drive at 46,000 eRPM drawing 1.85A of motor current. The Plus at the same revs and the same 68% duty read 1.07A. The ratio is 0.58, and the resistance ratio was 1.76, the same number upside down. No-load power at a given speed doesn’t change with the ESC.

The fix was a custom build: the 7.00 source for hardware 60 with CURRENT_SHUNT_RES set to 0.0003 and the limits off. One header file and make. Detection then read 13.5mΩ, 4.2µH, 3.49mWb, and the flux linkage was unchanged from before, exactly as it should be since it doesn’t depend on the current scale. The build and the headers are in my repo if anyone has the same board; I’d check your own detection numbers against a known motor before trusting them on any Flipsky board on the generic 60 image.

the detection result on the stock 60 build next to the one on the 0.3mΩ build, same motor

Trap 2: on 7.00 a gentle start never starts

With the currents right, current-mode starts still cycled: lock, a twitch, lock again, forever. Speed control worked. The reason is a setting that is new, or newly default, in 7.x: Openloop ERPM at Min Current, which scales the open-loop forced rotation by the current you’re asking for as a fraction of Motor Current Max. At the shipped 0%, a 10A start against a 170A limit spun the field at a few hundred eRPM, the rotor never got going, the observer was handed a stalled rotor and the sequence restarted. On the water a hard squeeze would hide this completely; on the bench nothing started. 100% fixed it. VESC Tool’s Sampled Data page, saved as CSV and read in Python with a Clarke/Park transform, is what showed the open loop rotating properly and the handover failing; worth knowing that page exports.

Two more things this motor wanted, both visible in the same captures. Its back-EMF isn’t sinusoidal, and at 4µH the fifth harmonic drives 20 to 50A of ripple through the phases at any speed; a current loop at twice the detection’s bandwidth (KP 0.014, KI 45 here) cut that by a third. And the Ortega observer with a higher gain held the rotor through the handover where the default didn’t. Starts are now 5 of 5 at 10A and at 20A on the play button.

Trap 3: the PPM mapping in Current No Reverse

The trigger did nothing at all for an hour, with the Mapping tab happily showing the pulse moving from 1.495ms to 1.987ms. In Current No Reverse, the PPM app maps the whole Start-to-End range onto 0 to 100% and ignores Center. With the usual 1.0/1.5/2.0 mapping, the remote’s rest pulse of 1.495ms is 49.5% throttle, which the Mapping tab actually prints next to it, and Safe Start waits for zero throttle before it will ever allow current. It never comes. Mapping Start 1.45 / Center 1.45 / End 1.99 with a 15% deadband puts rest at 8%, inside the deadband, full trigger at 100%, and the brake trigger clamps to zero. One more: the app takes a “brake current” branch whenever the observer’s standstill speed estimate reads a few eRPM negative, and with Motor Current Max Brake at 0A that branch commands nothing, so it’s set to −20A even though the brake trigger isn’t used.

Smaller things

• The motor has only three phase wires, no sensor leads. The “motor temperature” the 100A Mini logged (78°C idle, 43°C whenever current flowed) was an open ADC input picking up the switching. Sensor type Disabled, or the ESC limits the motor at idle.
• Max ERPM 54,000: the Neugart PLE040 is rated 18,000rpm input and three pole pairs make that 54,000 eRPM. The unloaded spin-ups in the old logs were 20,700rpm into the box. The limit is soft, the current winds down from 95% of it.
• The thermal breaker in the base is a 150A (E9 150 on its face), not the 100A I wrote earlier; the 100A tag is on the cable lug.
• Battery regen 0 and brake current clamped, so nothing goes back through the BMS.
• The VX5’s three gears are percentages of the ESC’s live limit, so with the limit at 170A they’re set 71 / 88 / 100% = 120 / 150 / 170A at full trigger, which is how I’ll choose the boost for an attempt on the water.

The boost script

The motor is labelled 35A continuous and 3kW peak, and it held a flat 76A for 15 minutes on the old ESC without complaint, so I’m treating 80A as the level it can hold and anything above as a burst. The ESC’s own limits are a ceiling, not a timer: set 170A and it will hold 170A for as long as the trigger is squeezed, into a winding rated for a third of that. And the temperature cutoff can’t help, because the motor has no sensor.

So the ESC runs a small Lisp script that keeps an I²t budget above 80A: every tenth of a second it adds (I² − 80²), so the budget fills fast at 170A and drains whenever the current is below 80A. One budget is 8 seconds at a full 170A (a guess at the winding’s thermal capacity until a sensor is fitted). The script steps the motor current limit as the budget fills: 170A while less than half is spent, 150A until it’s all spent, then a floor of 113A, and back up with a little hysteresis as it drains.

The refill rule is the part a rider needs to know: anything below 80A refills it, and never slower than a 60A cruise would, so from a fully spent budget the 150A tier is back within 6 seconds of cruising and the full 170A within 40, whatever the cruise current turns out to be (at a light 30A cruise it’s 20). The budget is also capped at 1.5, so a long stall at the floor can’t push the refill out beyond about a minute. The twin says cruise on this board is around 30A at the motor; I think it’ll be more like 40 to 60, and the first logged flight will say.

the script through a failed 12 s attempt, a 60 A cruise, two more attempts; top, the current drawn against the limit the script allows; bottom, the budget with the two tier lines and the cap

What the graph shows: a take-off that works takes one or two seconds and never meets a step. A failed one held on the trigger meets 150A at 4s and the floor at 10s, which is the script ending the attempt rather than the winding doing it. Cruising brings it back: 150A within seconds, the full 170A inside a minute. And the 113A floor is there because the gears are percentages: at 113A, Low gear is still the 80A the motor is known to hold, so a tired motor in Low gear is never pushed past what’s proven.

One more trick, since the motor has no temperature sensor: with the sensor type set to Disabled, the VESC firmware reports as motor temperature whatever a Lisp script writes into it. So the script writes the budget in percent there. Every log now carries the boost state in the motor-temperature column, 100 meaning one budget spent, and the remote will show it as motor temperature once it’s on UART. The motor temperature cutoff is moved to 200/220 so the ESC never acts on the number; it’s a gauge, not a sensor.

The gears choose how hard an attempt is; the script decides how long it can go on. Both tested on the bench, the script in the LispBM interpreter first and then on the ESC with the motor running through a forced tier change.

the ESC bare on the Takuma’s copper spreader pad; the receiver and the BLE module are off-frame, a photo with them in place would be better

Logging without a phone

The last thing I checked was the logger. I’ve been writing a watch app for foiling sessions as a side project, and one of its jobs is to talk to the ESC over the Flipsky BLE module and log the VESC values. Tonight I logged one squeeze with the watch and with VESC Tool over USB at the same time: 17Hz on the watch with no gap over 0.36s, and the two logs agree on revs, currents, duty, voltage and temperature to the sampling jitter, watt-hours identical to four decimals. So the phone stays on shore, the VESC Express I’d planned isn’t needed, and the remote stays on PPM with the BLE module keeping the UART.

Next

The ESC goes into the Takuma box bare on an adapter plate, MOSFETs against the copper spreader. I measured the box’s bosses and the PCB holes from a top-down photo with a printed tag card and a steel rule, scaled to calipers, which got the hole map to about a millimetre; that’s the plate. Then a static pull on the printed prop, logged, then the hump.

If anyone else is running a Flipsky V6-family board on the generic 60 firmware, I’d be curious what your detection resistance says against the motor’s datasheet.

[sat_be]

If you get a proper vesc with matching firmware, you can skip most of the extra work. Each vesc has a hw definition file in the source code that matches the HW. If you use a cheap China crap vesc, they use the sw for a different hw that matches more or less. Shunt resistance, max current and other parameters should match the hw. VESC fw is open source and Flypsky could provide the matching FW, they could even get into Vedders repo if they weren’t to lazy to do so.

For some HW there is a no limmit FW but you have to be carefull, if you set the phase current too high, you can burn the FETs.

[Jb69]

Fair point, and you’re right on all of it. A proper VESC with its own hardware file would have saved me the day, and Flipsky could fix this for everyone by shipping the right build or getting the board into Vedder’s repo.

For me it came down to dollars. This is a second-hand board whose maker no longer supports it, and I didn’t want to put more into it than it’s worth. What budget I have goes on tools and AI credits more than hardware, and that’s what found the shunt problem in an evening: an old log, a ratio, and one line in a header.

And I think that’s the useful part for anyone else. Plenty of people have a cheap Flipsky board, or will buy one, and now there’s a mapped-out path: the right firmware build, how to check the detection against a known motor, the start-up settings, the PPM mapping. It’s cheap to follow and it’s written down.

On the FETs, agreed, and that’s why the limits stay inside the board’s own rating, 150 A continuous and 200 A for an instant, with the absolute trip at that 200 and the script holding the 170 A burst to a few seconds. With the shunt value right those limits are now the real currents rather than 60 % of them. Before the fix, the stock firmware’s “120 A” was about 200 A at the motor without anyone knowing.