Axiom: a 100kW+ motor controller

[marcos]

On a side note, I've been working on improving parameter detection for this board. In order to measure the motor flux linkage the controller needs to spin up the motor, release it and then measure BEMF+rpm and with that it calculates the flux linkage.
The problem is, how does a controller spin a motor without knowing any parameter? This required the user to input 3 values for the spinning attempts (current, duty, rpm) and when I first started with this it took me days to converge to a usable tuning. It didn't spin, what should I do? Increase current? lower rpm? lower duty? Moving in a 3D space with no feedback if you are doing better was time consuming. Vesc code does 4 tries in trapezoidal mode with very different parameters (based on the parameters you input) and usually one of those random tries gets the motor to spin.




What I do now is just sending an open loop 3 phase sine to the motor that ramps up from 0 erpm to a user-defined erpm, it also ramps up the current. The whole point of making the motor spin is to make it reach a duty cycle of ~50% to make the measurement, so if your base speed is 10000erpm, you should input >5000erpm. This spinning-up process is set to take 15 seconds to ensure the motor is slowly accelerated and it doesn't go out of sync, because it is running completely openloop and some motors have large inertia. BTW there are abort mechanisms in place to detect if the motor is not spinning as it should.

Here's how it looks like. Green is the motor speed, increasing until it reaches my commanded 40% duty cycle. Orange is the voltage at one of the motor phases. Yellow is the motor position as measured by the FOC observer.

View attachment 4


The detection results are always very consistent.




I need to double check if 22mWb is a sound value for this motor based on the kV and pole number, but I can tell after the parameter detection the motor works much better than my manual tuning.

After the parameter detection you can do a sensorless full speed reversal




View attachment 1

Same color coding as the first screenshot, zooming in the yellow (phase angle) being reversed. Speed and phase angle are calculated in the FOC loop and sent to 12bit dac's.

In the GUI it looks like this



This works for me at <25Amps. Higher than that it gets confused at 0 rpm, I think higher currents should help the observer keep track of motor position, but too fast position changes+no BEMF can make the output be distorted by the PI filters. I need a proper testbench to test that.

In any case, a high power motor should have a position sensor anyways so I'm not spending more time in zero-rpm sensorless operation. At least not with this no-saliency observer.

Another quick change I made was in the phase resistance measurement so it always measure with a fixed amount of Amps, it used to perform some dynamic sorcery that with this hardware wasn't consistent. I still need to compensate for the IGBT's Vce that is not a problem when you use mosfets, but its <0.5% error when you use this at the rated 400V.

Firmware changes were sent to benjamin for merging into the codebase, he's busy putting together other parts of the project but these features will be merged someday.

 

[lizardmech]

Looks similar to how Ti instaspin foc motor detection works, you give it a target current and ERPM combined with a ramp up period to slowly build ERPM in open loop sinusoidal mode. The only difference is they have 0.1uf filter caps on voltage phase sense, they seem to be able to track the rotor position via BEMF using this despite being sinusoidal. I suspect they use it to enhance their current based FOC observer as well.

Did you ever contemplate moving the VESC code to a FPGA with an arm core instead of having them separate? I always wish there was a more portable version of the VESC software with just FOC and VESC tool support.

 

[marcos]

Looks similar to how Ti instaspin foc motor detection works, you give it a target current and ERPM combined with a ramp up period to slowly build ERPM in open loop sinusoidal mode

I should give instaspin a try. I used C2000's for other power applications, but not motot control. I think I saw Lmax and Lmin in their motor parameters which led me to think they use a saliency-based observer. 0.1uF sounds like a very agressive filter with lots of phase lag at high speed. I wonder what are they doing.

Did you ever contemplate moving the VESC code to a FPGA with an arm core instead of having them separate? I always wish there was a more portable version of the VESC software with just FOC and VESC tool support.

Oh I contemplate lots of things. Vesc codebase is too large to be fully ported to an fpga. Most of the code is for communication and config support which doesnt really need an fpga. If you want an arm core you would be constrained to xilinx IIRC.
A doable approach IMO is migrating only the FOC algorithm to the fpga, and keep the stm32 as an application processor to manage comms and configuration. This way I save a ton of analog filtering and tolerance errors and get an extremely fast control loop to support high frequency applications (SiC?). I think right now the transforms, filters and observer math take 14us. An fpga could have x10 the throughput.
So far only I have the delta sigma code and a LA running inside the fpga. I would need to make a good pwm block and the FOC loop.
When we get some units out the door maybe some university could make this improvement, its a great platform for academia. A paying customer would also work for pushing this forward

 

[marcos]

I always wish there was a more portable version of the VESC software with just FOC and VESC tool support.

Someone very familiar with this code can port the very basic FOC, SVM PWM, a single comm interface and a minimal set of config management (no bootloader, fancy virtual pages) even to another mcu brand. The problem is that vesc project won't keep supporting your platform, you are getting a one-way ticket to the endless endeavor of being behind a software migration. It would be difficult to do it with more powerful F7, but trying to migrate vesc to a cheap architecture without FPU support (stm32f1) I don't think it will work, the control loop will just take too long, and attempting a fixed point vesc branch is just not worth it atm.

If we reach a linux-like critical mass of user and developer base everything is possible: hardware agnostic architecture, fpga coprocessors, fixed point, automotive qualification. We are a long way from that, maybe some day. I hope vescproject can find its way to hire developers soon, that would be a first step towards fast growing. gcc crushed the compiler market, the internet stands on linux, kicad is the future of hardware development, and vesc has the right set of strengths to be a major player in the motor drive world.

I think we need some serious builds to improve the desirability of a vesc drive, those will draw in cash to fund the improvements we need to make this relevant. Thats in part what this thread is about.

 

[lizardmech]

I should give instaspin a try. I used C2000's for other power applications, but not motot control. I think I saw Lmax and Lmin in their motor parameters which led me to think they use a saliency-based observer. 0.1uF sounds like a very agressive filter with lots of phase lag at high speed. I wonder what are they doing.

Yeah it has a variable that has to be set which I assume compensates for the lag, it drove me crazy for a while, since they don't explain how their observer works I initially missed the phase voltage filters on my boards not knowing they were critical and that instaspin can't function without them. I'm still unsure what it actually uses them for, interestingly I made a VESC with the same filters and it allows you to see the BEMF even in FOC mode, without them you just get a flat line.

Did you ever contemplate moving the VESC code to a FPGA with an arm core instead of having them separate? I always wish there was a more portable version of the VESC software with just FOC and VESC tool support.

Oh I contemplate lots of things. Vesc codebase is too large to be fully ported to an fpga. Most of the code is for communication and config support which doesnt really need an fpga. If you want an arm core you would be constrained to xilinx IIRC.
A doable approach IMO is migrating only the FOC algorithm to the fpga, and keep the stm32 as an application processor to manage comms and configuration. This way I save a ton of analog filtering and tolerance errors and get an extremely fast control loop to support high frequency applications (SiC?). I think right now the transforms, filters and observer math take 14us. An fpga could have x10 the throughput.
So far only I have the delta sigma code and a LA running inside the fpga. I would need to make a good pwm block and the FOC loop.
When we get some units out the door maybe some university could make this improvement, its a great platform for academia. A paying customer would also work for pushing this forward

I'm not sure if FPGA is still worth it these days, on the 200mhz C2000 MCUs they got a FOC loop down to 1us and they have hardware delta sigma filters + high res PWM, the tesla model 3 inverter appears to use this MCU. There's also 400mhz and 600mhz M7 MCUs not sure if they can 10x the stm32f407 performance, must be pretty close though.

If we reach a linux-like critical mass of user and developer base everything is possible: hardware agnostic architecture, fpga coprocessors, fixed point, automotive qualification. We are a long way from that, maybe some day. I hope vescproject can find its way to hire developers soon, that would be a first step towards fast growing. gcc crushed the compiler market, the internet stands on linux, kicad is the future of hardware development, and vesc has the right set of strengths to be a major player in the motor drive world.

This is actually the biggest headache I have with the VESC for 2 or 3 years I tried to get a small control app made that used a IMU to control the throttle for balancing vehicles, I hired devs a few times and had all the drivers done but we couldn't figure out how to integrate it into a custom app but after years of asking on the forums and in emailing Benjamin I was unable to get any information at all. I had people who wanted to buy them and I could have used the money to pay for devs to work on more things for the VESC but I was forced to abandon it due to the lack of documentation or anyone to ask. Probably if there were a simple version without chibiOS and all the code associated with brushed motor + BLDC in the way it might have been more feasible to build on top of.

 

[marcos]

interestingly I made a VESC with the same filters and it allows you to see the BEMF even in FOC mode, without them you just get a flat line.

I wonder if I plot a digitally filtered signal I can obtain a reasonable BEMF.

I'm not sure if FPGA is still worth it these days, on the 200mhz C2000 MCUs they got a FOC loop down to 1us and they have hardware delta sigma filters + high res PWM, the tesla model 3 inverter appears to use this MCU. There's also 400mhz and 600mhz M7 MCUs not sure if they can 10x the stm32f407 performance, must be pretty close though.

The fpga on board is mostly there to replace the discrete protection logic, but it happens to be powerful enough for protection, a proper wdt, and some extra oomph for only $3.
Its all a trade off, if I get a request for an automotive grade solution my first choice would be that $20 delfino (even if it doesnt come with instaspin) or the new-ish fpu-enabled c2000 and I wouldnt spend time making it compatible with vesc because I'm sure the customer wouldn't care. But automotive grade specs demand automotive-grade budget, its a very different landscape.
F7 MCUs are tempting, but again your cash flow will need to pay for the firmware development, I'm thinking at thousands of boards to get back what you spent in firmware development, so I'm trying to get as far as I can with a limited budget.
In the numbers, delfino and F7 are clear winners until you consider development cost and the complexities of multicore processors.

This is actually the biggest headache I have with the VESC for 2 or 3 years I tried to get a small control app made that used a IMU to control the throttle for balancing vehicles, I hired devs a few times and had all the drivers done but we couldn't figure out how to integrate it into a custom app but after years of asking on the forums and in emailing Benjamin I was unable to get any information at all. I had people who wanted to buy them and I could have used the money to pay for devs to work on more things for the VESC but I was forced to abandon it due to the lack of documentation or anyone to ask. Probably if there were a simple version without chibiOS and all the code associated with brushed motor + BLDC in the way it might have been more feasible to build on top of.

I hear you there, its not easy to find embedded firmware developers that work comfortably with power electronics. Until recently I would have rejected a job like that because I wasn't confident enough with the codebase. You need proper instruments to peek inside this kind of non-debuggable code, and every RTOS is different so they all need some time to get used to. In my company we have a couple of seniors power electronics devs, but from my experience most firmware developers are used to 5V products, maybe a transceiver, but give them a system that you can't halt for debugging, -O2 enabled, smokes when you screwup and makes scary noises and suddenly they arent as productive as they thought they were.
Projects need developers, they need people writing documentation, people need to be either very involved or get paid. I read this as growing pains, afaik vesc project is a 2 person osh company, needs at least a staff of 4+ to keep up with the demand.

 

[tecnologic]

I hear you there, its not easy to find embedded firmware developers that work comfortably with power electronics. Until recently I would have rejected a job like that because I wasn't confident enough with the codebase. You need proper instruments to peek inside this kind of non-debuggable code, and every RTOS is different so they all need some time to get used to. In my company we have a couple of seniors power electronics devs, but from my experience most firmware developers are used to 5V products, maybe a transceiver, but give them a system that you can't halt for debugging, -O2 enabled, smokes when you screwup and makes scary noises and suddenly they arent as productive as they thought they were.
Projects need developers, they need people writing documentation, people need to be either very involved or get paid. I read this as growing pains, afaik vesc project is a 2 person osh company, needs at least a staff of 4+ to keep up with the demand.

This huge demand of totally different applications is why benjamin does not communicate everything to the public. When u think of peaple all over the world with any state of knowledge are having requirements is not easy to handle.

from my experience most firmware developers are used to 5V products

then u are searching in the wrong area. For sure some wearables iot sw dev will not be familiar with extra functions provided in ides like ccs for tracing realtime applications, but all the guys from the solar inverter branch maybe there are some guys available.

 

[albertocesare]

Hi Marcos, I've been studying for a while Vesc and your project because I need high power logic board controller, now I'm ready to start.
Gate driver will be Huebner ones.
I just wanted to ask you if repository is updated to last available design (logic and adapter to gate driver). If not, can you please share new ones?

Thank you!

P.s. when I'll order boards from manifacturer I'll get some board more than I need. If someone wants...

 

[marcos]

Hi Alberto,
Repo is not updated yet, but I'll have a few boards soon, the assembly house sent me pictures of the assembled boards and I hand-assembled a couple so I can test them sooner, and so far its going great.

What power level are you aiming at? Your gate drivers should have desaturation protection and undervoltage lockout like arlo's build or my igbt driver thread

 

[albertocesare]

Marcos, quickest response ever! Thanks a lot for your support.

I’m working to convert my car (400.000km, I don’t trust engine anymore ). Power will be around 45kw in the first release (when I’ll have more money for battery, I’ll upgrade to full power of motor, 130kw).
Two hub motor, one per real wheel means two controllers.
The project is very important because is part of my engineering graduation project.

I’m choosing between Huebner gate drivers (he uses them for very high power application including ev) and a design from power integration. Second one is for sure better but more expensive, first one is also isolated, with uvlo protection, negative drived and cheaper (si8261).

I found very interesting the possibility to solder myself the board, to keep price lower.
I’m not interested to steal and resell the design so every option is interesting
Please, keep the possibility to make me a beta tester

Edit: correct info about gate driver

 

[marcos]

Okay, PM sent. For the people following along, the economics of a desat-protected drive makes it worth it.

Imagine such drivers costs $85 each and cover top+bottom switches. x3 = $255.
How much would it cost 3 gate drivers without protection? Can I guess $30 each? x3 = $90

You saved $165. Thats almost exactly how much a new IGBT module costs so a single failure will get you even in $ but prone to more failures (you probably didnt have time to debug why it blew in the first place)

Now, how can a module blow? Your DIY gate driver will need tuning, chosing lower gate resistors for example to achieve higher efficiency. If during tuning you switch too fast, mister Miller can turn ON a switch that should be OFF and you lost the module in the shoot-through (and hopefully not the while drive)

Also likely, a poor solder joint on the PWM signal path could leave a pwm pin floating, prone to be induced by the large EMI going on in the drive. Such joint might look OK at 25°C, but could fail at 60°C. Granted, I've put pulldowns on every trace, and fpga tries to block and report things like that, but after the fpga you still have buffers, *wiring*, an isolation barrier, everything can fail.

And not to mention a software bug, for example setting a wrong deadtime or the other bazillion ways software can destroy a drive.

So if I were in that protection-less scenario I would live in terror of blowing up my drive over and over. Especially given I trip my protections on a daily basis during implementation of new of core algorithms.

 

[albertocesare]

Surely I’ll follow your suggestion about gate driver.

I’ll pm you about the board

 

[marcos]

So I've been working in a private git repository and now its about time to push RevD board firmware branch to the public repo.

https://github.com/paltatech/bldc/commits/powerdesigns-dev

Firmware changes are meaningful but not earth-shattering:
* Straightforward parameter detection
* Better watchdog coverage
* FPGA integration
* More fault types are logged
* Continuous Integration
* PeriphLib assertions are back
* Fixed all compiler warnings
* Limit control loop (ADC ISR) frequency to avoid hogging the RTOS

FPGA bitstream will remain closed for a while, mostly so people order these boards through me, for development I dynamically load the bitstream but my plan is to flash the bitstream into the fpga -I'm aware mcu code is GPL-. I will post the hardware files as pdf like VESC6 does, but because I don't want to be told that the boards are expensive I'll provide the option to order bare PCBs for the crazy DIY crowd, together with assembly drawings and stencil gerber.

I set up a Continuous Integration service for the firmware code, so every time a commit is pushed towards this repo, a bot starts building the code to raise notifications when someone pushes commits that don't compile. The branch is there waiting to be merged into the mainstream vesc project, right now it only builds the VESC6 binary but soon enough it will check that every hardware version builds OK.

README.md



I'm considering adding code coverage and some (basic) degree of unit testing, I have working here a simple stm32 project that runs code coverage tests, profiling and unit testing over semihosting (SWD debug connector), but I'm not sure how far I can get in this large motor control firmware because semihosting will slow down everything, no chance of running a motor, or even the USB driver but I guess I have to give it a try. The other problem is that code coverage is not trivial to automate without some serious test jig, I'm open to suggestions here. This involves a server sending all the types of commands through all the interfaces (usb, uart, CAN) and somehow simulating a motor sweeping across all operating points... for every commit.

Anyway, with the parameter detection improved (flux linkage in particular) I have speed reversals with more consistent toque across the rpm sweep. Not sure exactly where the improvement happened, I think it better estimates the flux angle and hence torque command has improved.




And this is the 8MHz crystal in case you need to know how it should look like.




And the 12MHz clock that MCU generates for the FPGA

View attachment 1

Still working on the hardware release!

 

[lizardmech]

Did you decouple the ADC ISR from the PWM freq so PWM can be set to multiples of the ADC ISR?

 

[marcos]

Did you decouple the ADC ISR from the PWM freq so PWM can be set to multiples of the ADC ISR?

No, it limits the max pwm frequency in the same way a hardware version can set hardcoded limits for current. If you enter 60kHz when you store the config that field will be truncated to 30kHz and a window will popup notifying you that a hardware limit was applied.

Why do you want to decouple ? To run PWM higher than 60kHz? Or to oversample?

 

[lizardmech]

Yeah, I looked at doing 100khz GaN VESCs a few times, at those frequencies you can eliminate the electrolytic caps and only have ceramic or ceramic + polymer caps. Those electrolytic caps contribute quite a bit to size and heat, you should also get some minor motor efficiency gains and possibly better performance on very low inductance motors. On Ti instaspin and NXP FOC solutions I have seen they typically 3 different frequencies for various functions, usually they have the current or speed control at 1khz, FOC and sensorless observer at 10khz and then the PWM as any multiple of that. That way you could detach PWM freq from CPU use or adjust bandwidth for the controllers without interfering with switching.

 

[marcos]

Yeah, I looked at doing 100khz GaN VESCs a few times, at those frequencies you can eliminate the electrolytic caps and only have ceramic or ceramic + polymer caps. Those electrolytic caps contribute quite a bit to size and heat, you should also get some minor motor efficiency gains and possibly better performance on very low inductance motors. On Ti instaspin and NXP FOC solutions I have seen they typically 3 different frequencies for various functions, usually they have the current or speed control at 1khz, FOC and sensorless observer at 10khz and then the PWM as any multiple of that. That way you could detach PWM freq from CPU use or adjust bandwidth for the controllers without interfering with switching.

I see. Right now we have the current/speed control in the same ISR of the high speed FOC. We could detach the slow-moving stuff (torque-speed control loop) from the FOC loop to (slightly) increase FOC bandwidth. I want to profile the code exactly for this reason: to know what is worth optimizing and what is not. In this case I would be only removing 1 PI filter from the ISR, no big difference I think.
I also want the FOC to run much faster, thats why I want to optimize, and while getting into that I found VESC does sin/cos with a math that I've never seen before, converges to a result in like 4 float multiplications. When I saw that I wanted to unit test those pieces of code to know how accurate they are and compare them to using lookup tables.

Now, allowing the FOC to run every X PWM periods is easy for one particular case that you already know (X=1 or X=0.5). If you enable "sample in v0 and v7" you are executing the FOC loop twice per SVM (and your FOC bandwidth halves), if you disable that you only sample once per SVM.

View attachment 4


Running the FOC loop every 3 PWM periods for example is not that trivial because there is no cpu intervention, everything is configured on init so its the hardware calling the ISR (PWM triggers ADC, ADC triggers DMA, DMA triggers FOC), I'm not aware of a hardware setting to skip any trigger of that chain, maybe there is.
If it can't be done in hardware for sure it can be done in firmware, it will just have a bit of performance penalty. In the software driven approach DMA would set a flag or an RTOS event every 2 or 3 triggers and return. Not sure if its benjamin's roadmap but it is mine, at least testing the concept because there is a limit on how useful it is, your sampling needs to resemble the actual current/voltages in the motor! You can switch faster and decrease DC link capacitance as long as the motor doesn't spin too fast, otherwise the undersampling distortion will make impossible to properly control the motor. These simulations of actual vesc code shows this better.

What we want to control:



What we actually see when sampling every third ADC conversion



This results in the SVM looking really bad at high speeds

SVM should look like this

View attachment 1

But will look like this



If you beat me to implementing that let me know! The code is good up to 35KHz pwm frequency if you disable v0_v7. You can reach 40kHz if you remove some code in the ISR like fault management (that sounds like fun!).
I tried enabling -O3 and LTO but code won't run, making it work properly under different optimization levels is a major task.

 

[marcos]

Running the FOC loop every 3 PWM periods for example is not that trivial because there is no cpu intervention, everything is configured on init so its the hardware calling the ISR (PWM triggers ADC, ADC triggers DMA, DMA triggers FOC), I'm not aware of a hardware setting to skip any trigger of that chain, maybe there is.
If it can't be done in hardware for sure it can be done in firmware, it will just have a bit of performance penalty. In the software driven approach DMA would set a flag or an RTOS event every 2 or 3 triggers and return.

Actually, there is an easy high performance way to do it. You can execute the full ISR once every N interrupts with 5 lines of code.

void mcpwm_foc_adc_int_handler(void *p, uint32_t flags) {
	(void)p;
	(void)flags;

	static int skip = 0;
	if (++skip == 3)	// only perform FOC every 3rd ISR call
		skip = 0;
	else
		return;		//skip FOC loop execution

	TIM12->CNT = 0;

	bool is_v7 = !(TIM1->CR1 & TIM_CR1_DIR);

The NVIC will make sure the interrupts triggered while the ISR is being executed will be queued. That's a hardware feature.

I tried the code and configured a "switching frequency" of 150kHz and apparently it works. My hardware won't like switching that fast so I didn't drive a motor, but everything else seems to work (USB, CAN, flash operations) so the RTOS is not collapsed. Without those lines the board would be bricked as soon as I configure it at 45kHz.

I find the term "switching frequency" confusing, I think he means that in 1 pwm cycle there are 2 switching events (ON and OFF), hence when you configure 150kHz, you actually see in the scope 75kHz (because it triggers only on rising edges for example). GUI doesn't allow you to go higher than 150kHz but it should be easy to locate where that limit is defined, it doesn't have to do with the firmware.

Now go make a GaN drive

 

[bigdaveakers]

Hi Marcos, first of all - awesome work!

I have a question!

Given that there are an abundance of used commercial motor controllers on the market is it possible that your board can interface with the power electronics?

As an example I picked up a Mitsubishi Outlander PHEV controller for £200 with the hope of hacking it, unfortunately it contains proprietary code that no one has managed to crack at the moment. It sits on an EV dedicated CAN bus in the vehicle and I suspect the number of CAN messages to actually get it working prohibits easy integration.

However, the brains sit on a separate board to the gate drivers and IGBTs so I suspect it could be possible to drop your control board in and have a working controller fairly easily.

What do you think? Is this something that you have considered or even done?

 

[marcos]

Given that there are an abundance of used commercial motor controllers on the market is it possible that your board can interface with the power electronics?

Yes, you need to connect it to the DC link capacitor to know the input voltage, connect it to the motor phases to get phase voltages, and connect the current sensors (or add you own) to measure each motor phase. You would need to know the the transfer function of the current sensors (Amp/Volt). Then connect all 6 PWM and fault signals to the control board.
You would need to figure out where are those 6 PWM signals (and which is which) and find the fault(s) signal. Its not trivial, but easier than reverse engineer a CAN protocol.

There is one caveat though, its likely that you have an IPM motor, and currently VESC code only supports SPM, your motor will spin, but will lose something like 40% IIRC of the available torque because it doesn't make use of the reluctance torque of an IPM machine. As soon as I get my hands on an IPM motor I will implement that control mode, its called Max Torque Per Amp.

 

[bigdaveakers]

As soon as I get my hands on an IPM motor I will implement that control mode, its called Max Torque Per Amp.

I very nearly bought one a couple of weeks ago for £400......again, lots available for not a lot of money (in relative terms!)

 

[marcos]

As soon as I get my hands on an IPM motor I will implement that control mode, its called Max Torque Per Amp.

I very nearly bought one a couple of weeks ago for £400......again, lots available for not a lot of money (in relative terms!)

Not so easy in Argentina. There are like 15 EV's in the country, and besides the shipping costs importing any automotive part is illegal, importing any used machinery is illegal, and importing any electrical machinery for >50V is illegal, so you need to be creative.

 

[bigdaveakers]

Not so easy in Argentina. There are like 15 EV's in the country, and besides the shipping costs importing any automotive part is illegal, importing any used machinery is illegal, and importing any electrical machinery for >50V is illegal, so you need to be creative.

How on earth have you done what you have done?!

Sounds like a remote lab would be good for you! VPN in to a location that has the hardware and run it from your base...…...

 

[lizardmech]

The NVIC will make sure the interrupts triggered while the ISR is being executed will be queued. That's a hardware feature.

I tried the code and configured a "switching frequency" of 150kHz and apparently it works. My hardware won't like switching that fast so I didn't drive a motor, but everything else seems to work (USB, CAN, flash operations) so the RTOS is not collapsed. Without those lines the board would be bricked as soon as I configure it at 45kHz.

I find the term "switching frequency" confusing, I think he means that in 1 pwm cycle there are 2 switching events (ON and OFF), hence when you configure 150kHz, you actually see in the scope 75kHz (because it triggers only on rising edges for example). GUI doesn't allow you to go higher than 150kHz but it should be easy to locate where that limit is defined, it doesn't have to do with the firmware.

Now go make a GaN drive

Nice, the VESC SVM scheme makes it look a little unusual. If you only sample v0 the FOC loop is effectively PWM/2, both v0 and v7 give you 1:1 with selected frequency. With this SVM scheme the low side only switches half as often, apparently it has slightly more torque ripple but 50% less switching losses on the low side.

 

[marcos]

Not so easy in Argentina. There are like 15 EV's in the country, and besides the shipping costs importing any automotive part is illegal, importing any used machinery is illegal, and importing any electrical machinery for >50V is illegal, so you need to be creative.

How on earth have you done what you have done?!

Sounds like a remote lab would be good for you! VPN in to a location that has the hardware and run it from your base...…...

Well, you can't import as an individual, but if you are a company and do the extra -and expensive- paperwork you can get your hands on some reasonable gear. There are a couple of local motor manufacturers as well but they all make SPM. Governent needs that labs like mine thrive, energy minister was in touch with us and even came to visit the lab (its a 700km trip), so did the state production minister, and they come to see our batteries but end amazed with our few military products and services.

So thats how we got to this point, and its why beta testers have been so valuable, we have already been giving support remotely and travelling if needed for engineering services. Fortunately this year things will change for the better

Lizardmech, I have a commit prepared that implements FOC-PWM decoupling, queued into a batch of tests that I should do tomorrow.