BLDC Motor Control Development Board for a 2 Wheeler Hub Motor

Hi Anil,

Anil Sudhakaran said:

This is for  a 350W, 48V  and 60V BLDC Hub motor for 2 Wheeler application.

Motor has Hall sensor feedback..

Can we go for a simple 6 Step control Algorithm ?

Jerk free and noise free performance especially during starting is important.

So the wheel hub motors are direct drive and no additional gear down added for higher torque? 

Both driver chips DRV835x or the DRV8300 that Anthony suggested have the input de-glitch noise filter, and this causes the output signals to dither even when inputs are not changing. The dithering output waveform cause the audible noise.

Brian

Thanks Anthony for the details...

DRV8300 should be OK for us.

No need to conform to automotive standards as of now.

Could you please suggest TI development boards (both micro controller and driver boards)  using which I can  quickly start my development.

Please suggest both 6 step and FOC development boards

Regards,

Anil

Hi Brian,

Hub Motors are direct drive.   No additional  Gear added.

See one in the link below

https://www.amazon.com/Kee-nso-Electric-Bicycles-Scooter/dp/B083M49KRB/ref=sr_1_8?keywords=Electric+Hub+Motor&qid=1672832267&sr=8-8

Audible noise will not be acceptable. Is there a way to bypass this feature ?

Regards,

Anil

Hi Anthony,

Anthony Lodi said:

Regarding the input deglitch filter for the inputs, I am not aware of this filter causing dithering on the output waveform. The input deglitch filter is simply to avoid the outputs changing due to noise on the inputs. There is a deglitch time so that the input needs to change state for a particular length of time before the output will change. The input deglitch should actually prevent dithering, since the outputs don't change due to high frequency noise on the inputs. This is a feature that you want to have.

I used the DRV8701 with the input deglitch feature, and it caused me more headache than help to drive the motor better. Here is the thread if you're interested. Keep in mind that the measured jitter on the gate driving signals were done with keeping the PWM inputs constant. 

https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1161554/drv8701-h-bridge-driver

Brian

Anil Sudhakaran said:

Audible noise will not be acceptable. Is there a way to bypass this feature ?

No, according to TI engineers and my experience. The engineers screwed up, or they thought the noise was ok for some application, like noisy drones or fans.

Edit: I looked at the motor listed on Amaz, it is an inside-out BLDC. The said dithering on the gate signal causes a humming noise but I don't think the scooter user would notice it, unless he is 007 agent on a super silent mission. In my case, the motor humming is on a movie lens and the user and the audio recorder is very close.

Brian

Thanks Anthony.

Can you also please recommend a FOC  control solution (for PMSM - Sinusoidal motor) - Microcontroller  Board + Driver board?.

Any driver IC is OK. Need to support 48V  battery , 350W+ PMSM motor.

Could you see one MSP430 based solution ? Is that the cheapest solution ?

Regards,

Anil

Thanks a lot Brian for the information. Plan is to test with Development board. Will definitely look at the points you mentioned and see whether it is an issue for our application.

Regards,

Anil

Hi Brian,

Thanks for the explanation, now I understand what you meant by dithering. I will keep that in mind. The mismatch between the MCU clock and the DRV clock will effect the duration of the jitter. Additionally, the frequency of the DRV sampling the outputs (which would be dependent on the device clock frequency) would effect the duration of the jitter. I haven't seen this being a major issue in the past with customers, but I can see that there could be certain applications where this could be more important. I will keep that in mind.

Regards,

Anthony Lodi

Hi Anthony,

Anthony Lodi said:

The mismatch between the MCU clock and the DRV clock will effect the duration of the jitter.

The pwm inputs are asynchronous to the DVR internal clock, but this should not cause the jittering outputs if these pwm input are driving the internal FETs directly to generate the gate driving signals. TI engineers re-sampled the pwm input in the De-glitch circuit, and this created the jitter - because the internal clock frequency is not high enough is my guess (temporal quantization). 

Brian

Hi Anthony,

I purchased DRV8353RS-EVM (with the F28027F MCU daughter card). Realized TI is not supporting firmware with HALL sensor  for this EVM. Could run motor in sensorless FOC algorithm with the default code provided.

As mentioned in the beginning of this thread, ours is a 2W application with Hall sensor. Need low speed performance and good starting torque.

Please suggest how to go about on this...

Regards,

Anil

Hi Anil,

Anil Sudhakaran said:

Realized TI is not supporting firmware with HALL sensor  for this EVM. Could run motor in sensorless FOC algorithm with the default code provided.

For your Wheel Hub motor application, which is a stop and go, then running the motor with sensorless will not work for you. You need to use sensor mode in this case.

Brian

Hi Anthony,

I need to order below item? . This will  fit into the existing DRV8353-RS EVM driver board , right ?  Looking at the picture of this board, it has 4 sets of  interfacing connectors. DRV8353 driver board - EVM has only 2.  Hope only 2 are used.    Please cofirm.

I will look  more into the Universal Motor Control project and get back with clarifications if any.

Thanks & Regards,

Anil

Thanks Anthony.

Regards,

Anil

Hi Anthony,

I just received my Launchxl-   25C board. While trying to connect , I see both DRV8353 EVM and 25C board have female connectors ...

How are these 2 plugged ?

Regards,

Anil

Hi Anthoy,

As mentioned in previous message , both boards have female headers.   User guide or Board Assembly is wrong. 

See board picture below... Connector is highlighted ...in red line

I have lost so much time

1.  By ordering wrong  daughter card - 27C

2. DRV8353RS board was faulty / failed. I see many people reporting GDF failure in forum

3. Ordered 25C board . Now I can not use this board also..

Please suggest  how to proceed ...

Regards,

Anil

Hi Anthony,

Arranged male to male header.  Plese include this information  in  Figure 2-8 of the User's guide. 

I will start testing on Motor once I receive my new DRV8353RS-EVM that I have ordered. 

Btw, I never changed drive setting when tested previous board  with F28027F MCU.  Used orginal formware and GUI default values.  I assume lowest IDRIVE setting is the default one. Is that true ?  If yes,   how  I would have  got GDF fault. ?

Also, I changed both DRV IC and  one of the Mosfets (which was showing Gate to Source short) .  Now I dont get GDF fault. Motor does not rotate. I dont see any PWM pulses from DRV, though it gets PWM pulses from Microcontroller.  Any suggestions  how to make it work ?

Regards,

Anil

Hi Anil,

I would need to check the default GUI value is for the IDRIVE setting to verify what the default value is. Keep in mind that an undervoltage event could reset the DRV registers, and the SPI device register default is max IDRIVE. 

In the case where you are getting PWMs from the microcontroller but not from the output of the DRV, could you confirm that the enable pin is high and that the fault pin is high? Also you want to make sure that the MCU is not commanding both high side and low side MOSFETs of the same phase to be on at the same time. If this happens then the DRV will not allow the outputs to go high. 

Regards,

Anthony Lodi

Hi Anthony, 

As you mentioned, might be an under voltage on DRV board side made the IDRIVE setting to reset to max IDRIVE and that caused the MOSFET to fail.

I have a doubt regarding the connections in Fig 2-8 of User guide.

As per this,  3.3V generated on F280025C board and 3.3V generated on  DRV board gets shorted through Booster pack header J1/pin1 , since we are shorting jumpers JP1, JP2 and JP3 using short link.  Is this allowed ?  Two 3.3V  Regulator outputs getting shorted .

Pls comment.

Regards,

Anil

Hi Anthony,

Sorry for  getting back  late on this. I started testing without shorting 3.3V from both sides..

Configured for Level 1 , Hall sensor based  algorithm. Was really struggling to get the 50 % offset values and 50% duty cycle PWM  outputs with this. 

 CCS is showing programming error from yesterday. It was working for a week before that. 

Error is 

 I used  command based debug tools of xds110.. Updated boot loader and firmware. I get below details with xdsdfu - e

Device manager in my PC shows ...

CCS Debug configuration shows...XDS100 

Please help to sort out this issue so that I can continue my  Lab project..

Please note that CCS shows it as XDS100 where as everywhere else it XDS110.

Thanks & Regards,

Anil

Hi Anthony.

Agree with you. Have done that...

Regards,

Anil

Thanks Anil!

Regards,

Anthony Lodi