I asked this question in a separate thread but it got lost in all the other talk.
What are the risks of setting the wrong switching frequency in FOC? I changed mine from the default 40000Hz to 20000Hz to make the motors quieter but @Ackmaniac suggested I set it to 30000Hz for my motors (Enertion 6355 190kv R-Spec). The change also made startup smoother with hardly any cogging (sensorless).
What does F_SW do? Why would he have made that suggestion? What’s the risk of getting that number wrong?
Bump…Im interested in this as well.
I’m definitely interested.
interested as well. @Hummie might know. Was talking to devin about these settings a few days ago
I’ve never heard of it. you should ask on the vedder forum and tell us! sounds pretty fantastic.
Well @Ackmaniac is the one who originally made a comment about this setting, so I’m hoping he will chime in.
Maybe @chaka knows the answer
The way I understand it is you want to have your switching speeds as low as possible, too low and you will begin to lose control of the torque ripple and the gains from having a low switching speed will be lost.
Much of what we see in the new VESC-tool and the BLDC-tool was borrowed from TI InstaSpin. Should find more info if you include that in your search queries.
I run mine in FOC at 20khz.
Basically its the same across all brushless type drive trains. Changing the motor update rate changes the degrees per update and also efficiency and top RPMs. For example if I’m remembering right 32khz is once every 6 degrees of rotation and 48khz is every 2 degrees of rotation. There is a physical limit of how fast you can update a motor as there reaches a point where the updates per degree of rotation have little to no effect on the angle of the motor. The faster the update rate the more efficient and smoother the motor transitions will be. The slower the update the more current can be pushed with each burst which in turn lowers efficiency and increases top RPMs
Side note. Most RC escs have an input range from receiver/controller -> ESC of 400hz - 32khz+. While the ESC -> motor runs at 16khz as that is the limitations of the FETs(Slew Rate) in use.
haha, the mystery of vesc settings. Few understand them, yet 1000’s use the vesc 
@Deckoz is there a difference between what you’re talking about and erpm? can you define the terminology in numbnut terms please and walk us through what you know at snail pace with stops to reinforce and possibly visuals or references! the goal of getting the best efficiency and smoothness without sensors is alluring. And how much more efficient are sensors and are they only relevant till like 3mph and then the hybrid mode will switch to foc? especially on a slower erpm hub motor what are the options here?
One is cycles per second one is cycles per minute.
haha. you did answer the first question thank you. I’ll try the vedder forum and maybe find a guy who cant stop talking.
Can tell this from own expierence: with 20khz i got some jigglers by high rpm … it sound wired and feels like the motors start to go up and down with rpm @ackmaniac set the SF to 30khz and the jigglers where history… be carefull you have to do new detection with a “correctur factor of 0.75” or anything…
haha i´m one of the 1000´s
Cheers
Sorry I didn’t answer all of your questions
BLDC / Hybrid never switches to FOC with sensors. The point of Hybrid with sensors is to allow the BLDC timing (6 sequence timing) to be timed at a rate that will make the motor move forward without de-synchronization. Once the motor is moving fast enough it creates enough back EMF for the driver to take over and keep sync without assistance - whether sensored or emulated sensorless. No matter what way you look at it, it is BLDC Timing, with assistance of sensors for that timing. It will never be as smooth as FOC. BLDC timing applies current in bursts so a singular phase at a time to move the motor forward.
FOC is sinusoidal/trapezoidal wave forms. FOC can be done without sensors but it is very crude. With sensors, as the bell housing turns past each sensor, the readout if graphed makes a 3 phase sinusoidal wave form - this is used to calculate position, as well as creating the driving current from the fets as the sensor data can be transformed into a value to control the gates on the FET - making it more natural sinusoidal vs trapezoidal. FOC also applies current to all three phases all the time when under load. There is no timing. It is the values of sensor data transformed into a value to control the gates at various voltages to provide X percentage of current over X phase at X time. there are 3 phases the load must be divided/driven between.
asking what is best? I think is mostly user preference. or application needs. as there’s positives and cons to both.
Its not just about motor size, magnet size/types(different magnets can deform or demagnetize at different heat and emf index’s). phase resistance etc etc. which is probably to complicated for something like a skateboard…so best to just leave these things to user preference of “feel”.
my opinion for skateboards is I like FOC, and the driving hz depends on your gear ratio, voltage and RPM to create smooth transitions. Other applications I’d say I like BLDC.
is the hardware we’re using safe and designed for both? I’m not really to sure yet, I’ve been looking at the github and sources to try to determine that. Hope it answers some of your questions, lol…I don’t like talking soo…
so the sensors are used continuously, at all speeds, when in foc and they enable the esc to produce a true sine wave which would be more efficient at all these speeds? is it safe enough to mess with all those 4 settings to a certain degree and see what the results are?
Which 4 settings? If I’m not mistaken F_SW is the frequency sensor write (the kHz at which the sensor is read and written to the KI loop
DTC is the control cycle time. This is not something I would change unless you are familiar with calculating magnetic flux and torque deviation over time for permanent magnet motors.
the speed tracker and duty down ramp loops are essentially PID loops with no derivative function. Its used to compare deltas rate of change and control how reactive the loop is to the difference in change. KP ie proportional in most PID controllers, is the same as “present time”. KI ie integral is “past time”, and Kd ie derivative is “future time”. Again not values I would mess with unless you are familiar with how PID controllers work, your familiar with Vedders implementation of a PI controller, and you have reason to believe for your setup it would do better with change.
I’m not sure if the bldc tool in its current state is capable of logging (like a blackbox) the multiple PID loops while riding to see if there is improvement that could be made to the Kp and Ki values to enhance performance.
So in its current state I would probably only change the frequency of the sensor writes(F_SW) - be it as it may the PI loops may be optimized for a specific sensor cycle, but I have not looked deep enough in the code to find out due to lack of onboard logging, as changing the PI loops would be blindly done currently.
Just increased from 20KHz to 30KHz, anyone tried higher? Now it’s barely audible, but for me it’s a little still, from the pitch I guess it’s a 15 KHz harmonic from the bell or something
@Deckoz you and chaka seem to be saying opposite things here. is the motor more efficient at a faster update rate or slower?
I don’t know what 4 parameters I was talking about before but can you please tell us more about any settings which might be worthwhile for us to learn about if we’re trying to get:
best startup smoothness at lowest speeds quiet efficiency
the op says he got a smoother startup and quieter with reducing his switching frequency down to 20000 while @Pedrodemio moved his higher and got quieter. are we talking about the “speed tracker” and “Ki”?
The switching frequency is simply the frequency the MOSFET’s are operating, the higher the less audible, until a point it doesn’t make difference to increase
But as you go higher you increase the loses on the transistors since they have to switch more time per second