Repository navigation
Home
New here, or just want to know what to change to get a specific result (quicker off the line, better braking, more top speed, a motor that won't stutter)? Start with the Tuning Guide: What Do You Want to Achieve? — no electronics knowledge required.
https://deepwiki.com/neoxic/ESCape32
High-Kv motors (low inductance, high pole count) have very short electrical time constants. At lower PWM frequencies, the ripple current per switching cycle is large relative to the average current, causing:
- Increased winding losses and heating
- Coarser torque control
- Potential demagnetisation effects at light load
Raising the PWM frequency reduces ripple current, smoother torque delivery, and reduces audible noise. 48–96 kHz is already good for most motors up to ~10,000 Kv. For very high Kv motors (>15,000 Kv), 96–150 kHz may provide measurable benefit.
—--
The documented settings in the code are:
-
freq_min— Minimum PWM frequency (kHz), range [16..48] -
freq_max— Maximum PWM frequency (kHz), range [16..96]
A smooth transition from freq_min to freq_max occurs across the 30–60 kERPM range.
So the firmware permits up to 96 kHz at high RPM, which is quite reasonable. The more important constraints are the lower bounds — 16 kHz minimum — and the upper bound of 48 kHz for freq_min.
The AT32F421 is a Cortex-M4 running at 120 MHz. Its advanced timer (TMR1) is a 16-bit timer, giving an Auto Reset Range (ARR) range of 0–65535. The practical upper frequency limit is:
| PWM Freq | ARR value | Duty cycle resolution |
|---|---|---|
| 96 kHz | 1249 | ~10 bits |
| 128 kHz | 937 | ~10 bits |
| 200 kHz | 599 | ~9.2 bits |
| 480 kHz | 249 | ~8 bits |
Theoretical maximum: 120 MHz / 2 = 60 MHz (ARR=1), but obviously useless for motor control. A practical maximum with acceptable duty resolution (~8 bits minimum) is around 470 kHz.
However, the firmware's real ceiling is lower for a different reason:
We have provided a “clamp” circuit to prevent destroying WiFi links if a motor is attached. The schematic is in git, and we have made a very small number to sell. There is now a KiCad design to make one in git.
Do not attempt to update a Remora using the WiFi link if you have a motor attached to the board unless you have a clamp.
You'll always find the latest firmware and bootloader on our own ESCape32 release repo, which we keep in sync with upstream. Download the binary named for the Remora 1 (currently AART1-rev17.2.bin and bootloader BOOT3_PA2_FE-rev4.bin under release v17.0.1) and apply it using the WiFi Link.
We’ve experienced issues with the WiFi Link that have resulted in serious damage to the connecting cable and the WiFi link itself.
We have published a clamp circuit that will prevent the issue from happening. In the meantime ...
If you have a motor attached to the Remora board when making changes to it with the WiFi Link - BE VERY CAREFUL. To be perfectly safe - disconnect the motor from the board.
Background - in order to save parameters in the WiFi link, the motor has to be stopped. You do this by moving the slider control at the bottom of the page in the first tab to the right and then the left and then clicking on “Save”.
Stopping the motor using the slidercan cause the motor to generate a very high voltage that is too much for the skinny cable to carry. The cable becomes a filament, gets very hot the insulation burns off and it smokes and destroys the cable. It can also destroy the WiFi Link adapter and the ESP32 S2 board. You can usually tell if the ESP32 is toast by looking at the mcu, if it has a slight bubble - consider it gone.
If you can’t or don’t want to disconnect the motor and a temporary fix is to disable the complementary PWM to allow the motor to coast when it's stopped - but this is not a desirable permanent setting. There isn’t any other software solution an this issue is a bit specific to slot car racing because we power everything from power supplies not batteries. Power supplies do not like to be run backwards - batteries not so much.
Note: it might be possible to reflash the firmware with the motor attached and not cause this issue - but it’s an expensive experiment.
ESCape32 Rev 17 has been released It would be sensible to apply it. We've been using it and it works fine.
There are two types of brakes:
- Controller braking.
- Motor braking.
Motor braking has to have the mcu energized so the mcu can turn on the coils to short them. Controller braking works by the controller shorting the power circuit making the motor a generator. Brushless motors are very efficient and do not generate a lot of drag. Subjectively, 12 magnet motors brake better than 6 magnet motors, and motors with stronger magnets brake better.
If we could keep some power on to the mcu after track power goes away, we could still have brakes. Therefore we've been prototyping putting capacitors of different values in the power circuit of a Remora. Unfortunately, the people who've tried it don't like the drivability - although the jury is still out. The other downside is there is a very short period of time needed when power comes on to charge the capacitor (nothing is free). In a very competitive race this might not be worth the later gain, especially if when a car flys off the track as they did many times at the Worlds, a track call is made, negating any real advantage.
We've also tried setting ANALOG_MIN to some very low value - say 180 (1V) and setting DUTY_DRAG to say 20, the assumption here is that there is some residual power in the circuit as the power goes off, and as the voltage drops below 1V the drag brake gets invoked. Keep the ANALOG_MIN below 216 (1.2V) though so drag brake is not invoked suddenly on braking.
Some very recent motor testing - which we'll publish soon suggests that it's best to set analog_min to 0 - more to follow.
You’ll notice the Latvian Board advertises power off braking. It's implemented by hardware and firmware. The firmware operation is similar to drag brakes. Down to about 5V brakes behaves as usual - the motor is a generator. At about 5V it shorts the coils (like drag brakes) and applies motor brakes. The mcu is provided current and voltage feedback to help it determine when to apply brakes.
Power off (track calls) braking is facilitated by storing energy in a small capacitor in its power circuit. When the track power goes off some energy in this circuit continues to power the mcu which determines power is off and applies drag brakes. There’s also a very small (micro seconds) delay at startup in order to charge the capacitor, that you might notice getting off the line.
This capability may benefit you if it suits your driving style and the track. For example to get the best times on our local club track it needs to be driven hard by letting off for the corners but not applying brakes.
Stopping the car “hard" on a track call might be more of a disadvantage than not. We’ve noticed that a lot of the track calls at last year's ISRA nationals were a result of cars (literally) flying off the track. Any sort of brakes are not a benefit to them :-) The cars still on the track that have conventional braking will continue to roll forward when the track power goes off until they run out of energy. The others will attempt to brake hard. Being able to roll forward might give you a slight advantage over a hard stop ...
The 1.2 release has different fets from the 1.0 and the (unreleased design) 1.1. This replaces FETs Q4 and Q5-Q10 which were respectively an AlphaOmega AON7418 for reverse polarity protection, and the AllPower AP90N03Q for the phase FETs, with a Jiangsu JMSL0302AU.
These have a superior operating characteristics to the previously used parts while having a similar footprint at a reasonable price.
We successfully tested a Remora 1.1 with the Toshiba TPN1R603PL, which has different pads and required a subtle change to the board. This part also carries a premium price which is hard to justify. The JMSL0302AU has very similar specs to the Toshiba at a much more reasonable price.
We tested this change with .8mm boards.
| Part Number | Manufacturer | JLCPCB part number | $ Oct 2024 | Rdson max (mΩ) at VGS=10V | Rdson max (mΩ) at VGS=4.5V | Qg (10V)(nC) typ | notes |
|---|---|---|---|---|---|---|---|
| AP90N03Q | Allpower | C2828593 | 0.1849 | 4.2 | 7 | 42 | Original output mosfets |
| AON7418 | AlphaOmega | C74384 | 0.5889 | 1.7 | 2.8 | 65 | Original reverse polarity mosfet |
| TPN1R603PL | Toshiba | C141548 | 0.7715 | 1.6 | 2.5 | 41 | Remora 1.1 output & reverse polarity |
| JMSL0302AU | Jiangsu | C2890409 | 0.2789 | 1.5 | 2.9 | 39 | Remora 1.2 alternative to Toshiba |
We base our parts selection on cost/performance. You can see from the above that the original output mosfets were inexpensive - offering excellent cost/performance. We did an interim switch to the Toshiba parts for the unreleased Remora 1.1 - but you can see it's a 500% cost increase. We have settled on the Jiangsu fets as an optimal cost/performance solution and replaced the output fets and the reverse protection fet (7) with this in the design.
This board is very similar to the Remora1 we produced. It runs the same firmware that can be updated using the WiFi link. It has the same parts as the Remora1 and is fabricated from the same design files that are distributed here. It only differs in perhaps 3 ways, namely:
- The pads are gold :-).
- The board is slightly thicker. (our first Remora 1.0's were 1mm, we made the 1.2 with .8mm thick boards).
- It's red not green and has the MidAmerica logo on it not the AART/Remora1.
- The firmware is slightly out-of-date - but not enough to cause you any issues. You'll need a WiFi link to update it.
This is where you can find out everything about the Remora1 slot car brushless motor, eCom.
If you are new to this try: Getting Started
If you want to know the details ...
The best place to get information is Discord.
If you want to purchase one, you now have several options:
- Won-O-Won
- MidAmerica
- ABSlotSport
- Do-slot
- RedFox :-)
- Our site.
Copyright © 2025. All rights reserved Adrian Blakey