I should be able to do that. The only annoying thing will be removing the glue 
Do you have any link with authentic/ quality one for the US market?
@mmaner here are the BLDC screenshots. Havent tested it with load yet, but using my hand it would seem that it will be the same… I’ll assemble it now
Get screen shots of the General tab and take it off Hybrid mode, put it in BLDC mode. Once you get it running in BLDC you can experiment with FOC, but always get a board up and running in BLDC to rule out amperage and voltage issues.
IOt is already in BLDC, and same story, I can easily stop motor wuth my hand, and brakes suck. Here are the general screenshots… Ima take Hybrid off now, should I go sensorless?
Yeah, sensorless to start.
I did that, is very weak. Doesnt even take off and keeps coggin… if I push it starts moving and keeps on
I don’t see anything wrong with your setting but I’m looking on my phone. My feeling is that you have a sensor issue. Set it to sensorless and disconnect them then try bldc detection.
1 Like
Setting done, still the same… Here is a video. As a reference I am not able to hold the wheel like that on a Wowgo 2s.
I realized it is just a startup problem… is there a way to push more current in startup?
You can increase the startup boost. Have you tried a different motor?
Nope, don’t have another motor. How to increase startup boost?
I’ll have to look at the VESC tool, don’t remember if the top of my head. I’ll get back with you in an hour or so.
1 Like
When you do the Motor detection you can increase Duty at start ect to make the cogging go away. It should a do a smooth start up and clear smooth stop.
1 Like
Ouch, I’m sorry to hear that The cut-outs during braking will be problematic. I was able to prevent cut-outs on mine using longer positive ramping time and experimenting with the settings, but they ended up being less than ideal for stopping on a dime.
@DAddYE These look like they’ll meet the necessary specifications: 750uF, 31 mohm ESR; two of them will be more than enough.
$3 each is not that bad, (except for shipping, argh). Aside from being twice as long, they should have the same form factor as the existing electrolytic capacitors on the FSESC 4.20. I don’t think the ceramic caps need to be replaced; if there were a problem with them, the ESC would cog on most motors in FOC. Looking at the some of the larger ceramic bypass caps, it’s hard to tell at first, but they are REALLY tall, and really big.
2 Likes
then you clearly didnt read this thread.
SOME INSIGHT ON DRV FAULTS
Ok, so I switched out the stock MOSFETs (NTMFS5C628NL) with TPW1R306PL,L1Q. https://www.digikey.com/product-detail/en/toshiba-semiconductor-and-storage/TPW1R306PLL1Q/TPW1R306PLL1QCT-ND/6188444 It has half the RDSon and twice the gate charge; it is basically equivalent to two NTMFS5C628NL in one package with an exposed topside source pad.
I was wrong, faults are still occurring; HOWEVER, the nature of the faults did change. The current the VESC measures during a fault doubled from 40 filtered, 60 abs to 75-80 filtered, 120 abs. I tested with an unloaded (and damaged) 6374 TorqueBoards motor from DIYElectric Skateboard. I could not get the ESC to throw a fault in “current no reverse with brake” but I could get it to throw fault in “current” control mode and instantly going full forward to full reverse.
Pausing for a second in the center would avoid a fault altogether.
ALSO! before, it would fault on my hoverboard hub motors in the same way; with the new MOSFETS, I can’t get the thing to throw a fault.
± 60A motor and batt current, although the most it would pull in unloaded condition was 20A motor.
Here’s a picture of the dodgy rework.
I also doubled checked, the OC_ADJ pin is indeed tied to DVDD, but the change in measured current at fault tells me the DRV8302 is throwing its overcurrent protection fault… I doubt it’s the DC decoupling capacitors, the VESC reports nominal voltage during fault condition. I also can’t find the GVDD caps, but there appears to be a 47uf ceramic cap on the 3.3v rail. But it can’t be gate undervoltage since those faults would be throw at random times or all the time; these seem to happen when current changes extremely quickly.
DRV8302 throws faults in three conditions, gate undervoltage/overvoltage, overtemperature, and overcurrent. Overcurrent protection is done by measure Vds across all actively driven transistors. I wish I had a digital oscilloscope, because then I would jerry-rig some probe points and plot the nFAULT signal against GVDD, phase A, and other relevant signals.
At this point, the significance differences between the FSESC 4.20 and 6.6 is the 6.6 uses discrete highside current sense amplifiers and an SPI enabled DRV8301 instead of the DRV8302.
Since the embedded lowside current sense amps in the DRV8302 are essentially independent of the main gate driver IC, the only significant difference that would cause the 4.20 to throw DRV faults and not the 6.6 is the DRV chip.
I might try swapping out the DRV8302 for a different one from Arrow or Digikey, but that will be a real pain in the ass since I don’t have a hot air station and only a heat gun. The ground plane in the 4.20 is absolutely huge and I would have to heat gun the thing to both remove and solder in a new one, without any thermal reliefs on the exposed ground pad. Chances are if I try this I’m going to lose passive components or possibly even ruin the STM32 chip.
I’ll see if I can ask Flipsky from which electronics distributor they get their DRV8302 from.
EDIT: on second thought, I read on the TI forums that long gate drive traces can cause fault conditions, I need to reexamine the traces to see if this is a possibility.
4 Likes
I apologize for the double post, but I discovered something interesting and would like to share it with you guys.
I now have two FSESC 4.20, one with stock MOSFETs, one with TPW1R306PL,L1Q.
The stock ESC I can get to fault everytime regardless of what VESC settings I try with my TB 6374 motor on the bench.
However, the ESC with the new MOSFETs, I couldn’t get it to fault at all on the bench using these settings
± 40A on everything.
50khz switching frequency (don’t try this on a VESC with phase shunts, you’ll brick it because the algorithm isn’t fast enough).
ALSO, on the FSESC 4.20 with the new MOSFETs, I couldn’t get it to fault at all in sensorless mode on the bench; however, low speed startup and braking where much slower.
Testing was done at 6S with lipos that can supply 200A.
Looks like some hot air rework and a little crazy VESC settings is what will get the FSESC 4.20 to stop throwing faults xD. (at least, on the bench)
I noticed the faults generally occur at around 20% duty cycle, or right around when senorless mode is supposed to kick in.
My best guess as to what is happening, is during transitions into sensorless mode, the phase angle that the observer calculates is significantly different than the phase angle the VESC was previously using prior to the transition, this happens in both open loop and sensored mode, with the difference being larger at higher RPMs. The result (and because of some quirks in the FOC algorithm) results in a very large (and very brief) current spike in one or more of the phases. This, in combination with the the very high slew rate (and lower saturation current) of the MOSFETs, I’m guessing is causing a glitch on the phases and triggering the DRV8302 fault. And this is why you don’t see this on 4.12 hardware, since the IRFS7530 has a slew rate ten times slower than the NTMFS5C628NL
4 Likes
This is great troubleshooting. @BarbaraZ
They’ve got a new model on the way and hopefully they’ve managed to isolate these issues
1 Like
Hey @BarbaraZ I bought a FSESC6.6 during the buy one get one free promotional period, but when the package arrived there was no second unit. Facebook customer service have been unhelpful
Message them on Facebook. Make your first message as clear as possible.
Name, address, order number, order date. Then the issue as simple and clear as possible.
Just make it really easy for them to help you.