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.

[Jb69]

Update: a $10 board in the box does the Bluetooth, the LED and the IMU

The ESC is sorted, so this update is about the rest of the sealed box, and it turned into a small project of its own. The rule I set myself: the box gets opened once to fit everything, and after that every change has to be possible from outside. Three things pushed me there.

• The Flipsky BLE module sits on the ESC’s COMM UART, which is the port the VX5 remote wants for telemetry. One or the other.
• The Takuma’s own case LED board has a two-colour LED with no series resistors and nothing to drive it once the factory controller is gone, and I wanted the light back as the last line of fault finding: is the box alive, is the ESC up, is the remote linked.
• The Mini 6.8 Plus has no IMU, and I want board pitch and roll in the logs.

What went in

A Seeed XIAO ESP32-C3 on the ESC’s CAN bus through an SN65HVD230 transceiver, powered from the CAN socket’s 5V. It does four jobs: Bluetooth node for the watch and VESC Tool, LED driver, IMU carrier (an LSM6DSO on its I²C), and over-the-air updates so the lid stays on. The remote then moves onto the ESC’s COMM UART with telemetry, nothing between the trigger and the ESC. The whole thing is two resistors and a handful of wires beyond the three boards.

the node pin by pin: the CAN socket through the transceiver on D0/D1, the LED board with 180 and 100 Ω from the XIAO’s 3V3, the LSM6DSO on D4/D5, a single-cell LiPo on the XIAO’s back pads so the LED answers with the pack off, and the later ride-height sensor on D10

the box as a whole: pack, breaker, ESC, motor, the VX5 receiver, the XIAO on CAN driving the case LED, the case USB socket; the BLE module shown is what the XIAO replaces

The firmware is VESC Express, Vedder’s own ESP32 firmware, which has an official target for this exact board. So VESC Tool sees it as a VESC Express, lists the ESC behind it on CAN, and everything the Express can do (Lisp, the LSM6 driver, CAN forwarding, BLE and WiFi at once, firmware updates over the air) comes for free. The LED and the box packet are a short Lisp script on top. One thing the pinout settles for anyone doing this: the Express target puts CAN on D0 and D1, not where I’d first wired it, and D0 is a strapping pin, which is fine because a CAN receiver output idles high.

The LED as a fault-finding ladder

The light answers one question per state, in the order you’d ask them when the board does nothing:

What you see	What it means
dark	the node is dead or its cell is flat
red slow blink	the node is alive, nothing from the ESC on CAN
blue slow blink	the ESC runs, no remote
blue steady	ready to ride
red steady	the ESC reports a fault
red and blue alternating	pack under the cutoff start

Red is always wrong, blue always right. The boost tiers from the last post stay off the light; the watch shows those. The ESC’s boost script puts tier, fault, remote and budget on the bus in one CAN frame, and the node reads the pack voltage from the ESC’s normal status broadcast, so the ladder needs nothing beyond what’s already on the wire.

Plan B, which turned out to be useful on its own

In case the Express fought me, I also wrote an Arduino sketch for the same hardware that does the same jobs and is the watch’s Bluetooth link itself: it advertises the Nordic UART service like the Flipsky module, answers the firmware-version request as a custom module so the watch takes its bridge path, forwards the watch’s requests to the ESC over CAN using VESC’s own short-buffer and fill-buffer frames, and sends the box packet. It also serves a little web page on the home WiFi, or its own access point, with the last two minutes of current, revs, voltage, budget and MOSFET temperature graphed. That page has already paid for itself on the bench.

the node’s own web page during a run, with the watch connected: 247-byte Bluetooth packets, 262 requests, 253 replies, 102 box packets so far

First day on the bench

The board arrived yesterday, the CAN transceiver didn’t, so the day was the two firmwares and the watch, no ESC on the bus yet.

• VESC Express flashed from the Express source in a couple of minutes once the toolchain was in. The watch connected, got the “this is a bridge” answer, and took 250 box packets in 13 seconds from a Lisp loop, 20 a second with none lost.
• Two finds along the way. The XIAO has no antenna on the board; without the little one clipped on, the watch heard it at −90dBm from across the bench and lost most packets. With it, around −55 to −60. And the watch was asking the bridge to scan the CAN bus twenty times a second while it waited for the ESC’s id. An Express scans the whole bus for each request, about four seconds on an empty bus, so that buried it. It now asks once a second. The Mac simulator I’d tested against answered instantly, which is why it never showed.
• The sketch, with a fake ESC built in that answers the watch’s forwarded requests with a replayed ride while the bus is empty, ran a full session end to end: 1,155 rows over 63 seconds at 18Hz, every VESC column, plus tier, budget and remote from the box packet on every row, and the export opening straight in VESC Tool.

what the watch logged through the XIAO: a fake one-minute ride cycle from the sketch, taxi, take-off burst, cruise, stop, with the box packet’s budget and tier on every row

Both firmwares are one flash command away from each other, and the watch needs no change between them. The Express is the one going in the box.

Next

The transceiver, then the Plus behind the XIAO for the first real log through it; the LED polarity test; the IMU. After that, a waterproof ultrasonic ride-height sensor in the hull, which the sailing crowd use for exactly this and which a laser can’t do on water, with its lead through a cable gland fitted at the one opening whether or not the sensor is proven by then. Then the lid, the static pull on the printed prop, and the hump.

If anyone has run VESC Express on a XIAO or similar, or has a cleverer answer for a ride-height sensor than ultrasonic, I’d like to hear it.

[Jb69]

A short one, because today’s result is the kind that makes the rest of the box easy.

The XIAO is running VESC Express for real now, and it joins my home WiFi on its own at power-up. VESC Tool on the laptop then finds it on the network by itself, the way it finds a USB device, and connects over TCP. No cable, and once the lid is on, no lid off either. The firmware panel shows what the watch sees too: VESC Express 7.00, hardware “Seeed ESP32-C3”, hardware type Custom Module.

VESC Tool reading the XIAO over WiFi

The CAN transceiver arrives tomorrow. With it on the bus, VESC Tool connected to the XIAO lists the Plus under CAN Devices and every page works on the ESC through it, motor settings, real-time data, the boost script’s Lisp page, firmware. That’s the same forwarding the watch uses, so the two paths into the box, laptop and watch, are one mechanism. I’ll report the first real log through it when it’s done.

One thing worth passing on to anyone running VESC Express in station mode, and I’d like to hear if others see it: with the board set to join a WiFi network, mine also advertised an open network called ESP_ plus the last bytes of its MAC, and VESC Tool’s TCP port was listening on it. The firmware runs the ESP32 in station-plus-access-point mode for its ranging feature and only configures the station side, so the access point comes up with the chip driver’s defaults, which are no name and no password. Anyone who joined it could have talked to the ESC. Since I build the firmware myself I patched the start-up so the access-point side gets the configured “VESC WiFi” name and WPA2 key in station mode too. Side effect, and a welcome one: the board now runs the home network and its own secured network at the same time, so the phone gets in at the beach and the laptop at home with no mode switching. It’s a 35-line patch and I’ll put it up if there’s interest; it probably belongs upstream.

Also learned today, cheaply: the XIAO has no antenna on the board. Without the little one clipped on, the watch heard it at −90 dBm from the other side of the bench; with it, −55.

[Jb69]

Update: the “stutter” on a gunned start was a trip, and what fixed it

On the bench the drive had a habit: gun the trigger from a standing start and it stuttered for a moment before settling to a smooth rpm. Tonight that got logged instead of described, and it turned out not to be a stutter at all.

What it was. Every gunned start tripped the ESC on absolute over-current (fault 4). The firmware forces the rotor round open-loop before the sensorless observer can see it, and in 7.00 it does that at whatever current the trigger asks for, unless you cap it. On this motor, 13.5 mΩ and 4 µH, a demand of 85 to 160 A during that phase puts the phase peaks past the 200 A absolute limit. What I felt as a stutter was the trip, the ESC’s half-second fault stop, and the restart under the still-held trigger.

Chasing it. Eight logs at 20 Hz, three gunned starts each, one change per log:

• A slower trigger ramp and a longer open-loop settling time changed nothing.
• Openloop Current Max (FOC, Sensorless; it ships at −1, no cap) set to 50 A made every open-loop phase a flat 50 A, clean. The trip moved to the hand-over itself, at 3,000 and at 5,000 erpm alike, and once the observer decided the motor had stopped and restarted the whole open-loop ramp.
• A 2 s ramp, which keeps the demand under the cap through the hand-over, made the hand-over hold. So the second half of the problem was the demand stepping from the 50 A cap to the full 170 A at the instant the observer takes over, into an angle estimate that is still settling.
• Cap 50 A, hand-over at 5,000 erpm, a 1 s trigger ramp: three clean starts in a row.

the four stages, up to three starts each, lighter lines the later ones; the red cross is a trip. Left to right: the trips at full current before the hand-over; the cap cleaning the open-loop phase and the trip moving to the hand-over; the 2 s ramp holding the hand-over; the keeper)

one gunned start before and after, prop off; the red one trips at 161 A before the 3,000 erpm hand-over, the green one runs open-loop at 50 A to the 5,000 erpm hand-over and carries on)

the keeper’s whole log, three gunned starts in a minute, no faults; unloaded, each one runs to the 54,000 erpm limit where the limiter cuts the current to 2 A)

What changed on the ESC: Openloop Current Max −1 → 50 A, Openloop ERPM 3,000 → 5,000, PPM positive ramp 0.4 → 1.0 s. Two housekeeping fixes found on the way: the motor temperature cutoff was still 85/100 while the boost script writes its budget into that channel, so at 85 % budget the ESC would have derated the motor (now 200/220), and the pole count was 14 for a 6-pole motor (speed and distance in the logs, not control).

For anyone else on a low-inductance motor and VESC 7.00: if a hard start from rest trips or stutters, look at Openloop Current Max before anything else. The default is no cap, and the open-loop phase will happily run at your full motor limit. Then keep the demand from stepping at the hand-over, with the app’s ramp or the Start Current Decrease setting on the same page.

How it was done, since it’s the part I’m most pleased with. The ESC was on USB to the laptop, and on the laptop an AI assistant was connected to it directly through a small Python script that speaks the VESC protocol: it reads any motor or app parameter by name, writes it, pulls the real-time values at 20 Hz into VESC Tool’s CSV layout, and draws the chart. So the loop was: I squeeze, it logs, it reads the rows, it proposes one change and explains why, it writes that change to the ESC, I squeeze again. Eight rounds in under an hour, each with its log, its chart and a line in a session table, so the whole investigation is reproducible from the folder. It also found the two housekeeping faults above on its own, by comparing the ESC against the commissioning notes before touching anything.

The human stays in the loop for anything that can hurt: the script carries no motor commands at all, so every start was my finger on the trigger with the prop off; firmware never gets written by it, only built; a changed value goes to RAM first so a power cycle undoes a bad one, and is only stored once it’s proven; and the one setting it can’t reach by name, the open-loop cap, I wrote in VESC Tool between logs. It built its own written procedure from this session (parameter names checked against the firmware source, the symptom table, the recording method), so the next motor on the bench starts from what this one taught it.

Once the CAN transceiver is in, the same script talks to the ESC through the XIAO over WiFi, lid on, and the laptop at the kitchen table.

The water will say whether the 1 s ramp is felt in flight; if it is, the Start Current Decrease is the gentler alternative that only acts at low speed.