The v1.0 will likely do better in your stress testing. I’ve added PNP transistors to the gates of the MOSFETSs to provide a Miller clamp. Helps keeps the MOSFET off when it’s supposed to be off and prevent MOSFET shoot through (can easily kill MOSFETs)
I’ve also added a shottky diode to prevent large negative voltage stress on the DRV and also dialed in the gate resistors and capacitor values to be more effective as well.
These improvements have made a significant impact when putting the CFOC2 through high stress situations.
Mostly with 5.01, but have tried 3.62 and 4.02. Having seen that other people are able to get it working is encouraging, going to revisit my wiring and see if anything is off there. I also tried to use usb-serial converter to connnect to vesc-tool it didn’t work which is odd, but I need to double check the baud rates etc.
New question: the OG davega supports 5.xx FW? Or is that’s what your code alterations add support for? (I didn’t see anything that popped out immediately)
No. Up to v3.60 is supported by the OS DAVEGA. The DAVEGA X supports VESC FW 5.1 since v2.0.4. Let’s not derail this thread though. If you have any more DAVEGA questions please ask in one of these threads:
So I was stress testing the Little FOCer in a similar fashion to what you were doing. Unloaded motor. 5uH (killer) at 72V. Was going full throttle with keyboard at 60A and switching directions at max rpm. Got some interesting results.
Nothing died. Most of the time the Little FOCer was fine with it. As I went up in max motor current, I would start to get over-voltage faults. The bus was exceeding 95V. Seems like the back EMF at from the motor at high rpm was coming into play and dumping a bunch of energy into the bus when I suddenly switched directions. My gate drive solution is robust enough to handle it and the MCU alerts on it like it should.
The same thing is probably happening to you with the CFOC2 but the DRV isn’t surviving when it gets the >60V from the back EMF of the motor. I wonder if you lower the battery to 10s if you would stop blowing DRVs.
You’ll also have to use the DRV8301.h and .c files from my code. There’s some unique functions in there that’s not in the vanilla VESC code. Only applicable to CFOC2 v0.9 btw.
Damn I also planned to use Davega (open source) for an escooter project. Didn’t know it won’t work. I mean firmare 3.6 was already working good for me but it’s a pity that the newer version are not compatible.
It sounds plausible. I actually had a TVS diode on that focer but perhaps it wasn’t enough to keep the voltage down.
10S is not an option since it is a hub motor. I need the speed… would get late to work… at least until we have field weakening in the software
I thought this issue was related to the DRV reseting the registers. After every such such event, the motor would cog violently. When it happend it was always just after the direction change from reverse to forward.
Perhaps too many of these events with the wrong gate drive setting will break down the DRV eventually and that is what could have happened when the drv decided to fart
The pin PVDD1 burnt off completely. (power supply pin for gate driver, current shunt amplifier, and SPI communication)
I will do my first road tests tomorrow with the focer in the scooter. Should be fine as long as I keep myself from going full reverse 60kph to full forward
we need to get this number
to be more like this number.
