rotor/stator angular position sensing in AF PM BLDC motor

Hello Ken,

Magnetic field from the rotor will not be of issue.

Let me ask a few questions, as the answers are very important for successful system design.

1) What is the speed of rotation?

2) What is the required accuracy for the angle detection?

The coil diameter will be comparable to the rotor radius, unless you have any mechanical constrains.

Target can be made of any conductive media, but in this case I would suggest magnetic metal for increased sensitivity.

The rotation speed is from zero to 3000RPM (50RPS).  I need to be able to resolve 512 positions (9-bit) for each 360 degrees (one revolution).  This is really no different from linear detection, except the linear strip is swirled.  As far as conductive material, I would then use grain oriented steel 0.35mm in thickness, same as the laminations for the subcoils.  This means that I would like to see about 20K readouts per second (something less than 50x512).  I can tell when the motor is not rotating because the readout will be within a particular error bandwidth location.  When the rotor is rotating, then I will use an offset to actual position due to the delay in resolving position.  This is simply a function of speed.  I do not care if the position readout is not linear.  I will do a lookup table if needed.

Finally, I can rotate with a electric drill to find out any rotor stator offsets.  With the AM256, I have a 20-pin microcontroller that has an 8-bit dip switch so I can set the rotor/stator offset..  I may choose to place a microcontroller (slave device) with the LDC part to simply remove any overhead,  this way, the position sensing absolute zero give me perfect alignment of one phase (stator subcoil centerline with a rotor PM centerline).

any other questions?

Ken Kadrmas

For your information, the working diameter dimensions to place the swirl are 75 to 100mm.  The motor diameter is 125mm and the rotor diameter is 114mm.  There is a hollow shaft on the rear of the motor where all the wiring comes out..

Ken Kadrmas

I have attached a possible swirl pattern to place on the rotor back side.  You have my email address in the TI subscriber file so you can contact me that way if necessary.

Ken Kadrmas

Hello Ken,

The shape will have to stand off from the aluminum back plate by at least the same distance as the distance from the coil to the shape.

Ideally, you would want it to stand off by half of the coil diameter, to eliminate plate influence on the sensor, increase contrast and precision of the measurement. Please let me know if it's an option.

Also, let me add one more thing - to resolve uncertainty around the position where the thin part terminates, and becomes thick again, second coil will be required.

I just sketched the spiral to see what I could fit in..  Some of your last message text is missing.  I can put some type of spacer underneath the GO steel spiral.  I suppose that this could be tried on a variable speed lathe.  I can get the GO steel laser cut in Warrior, AL.  This should fit the coil on the EV PCB.  I do not understand the dimensions in Fig 4-2 of the EV.  I think the 600 means 0.600 inches or about 15.5mm dia for the coil.  I would then assume that the max width of the spiral should be not more than 20mm down to 2mm.  I would need some help in matching the physical size of the swirl pattern to the EV coil and then I will position it on the existing rotor plate.  I cannot see that the length of the spiral (placed on some plate diameter centerline) should be an influencing factor.

So there is no misunderstanding, I work with graduate students on special thesis projects.  I am retired and do this as a mentoring process.  This is for a new type of multi three-phase AF PM BLDC motor concept to be used in future single passenger urban commuting vehicle designs.  We have been working on this for three years already.  This sensor would sure may life easier in this design.

I would probably try this as a comparison to the AM256 magnetic rotation sensor.  Any help TI can provide should be worthwhile for all of the user community and any comparison should be interesting. 

Ken Kadrmas

You are replying faster than I can.  I did wonder about that and though that if what you are saying is necessary, then Fig 23 in the datasheet should have shown that to be the case.  The figure should label the vertical grey areas as 'indeterminent'.  You are saying that I really need to have two coils essentially 180 degrees apart.  New ball game.

Ken Kadrmas

Thinking this over, I would need two microcontrollers or one with dual SPI.  Depends on how quickly I can resolve a positional reading so the AF PM BLDC master microcontroller can get fast enough positional information to control the slave three-phase bridge drivers, etc.

I will have to think that through carefully.  like i said, new ball game.

Ken Kadrmas

I see from one of the other threads that there will be a multi channel  (multi coil) part in the near future.  Will getting reading then be slower?

Ken Kadrmas

Hi Ken,

Dual SPI is not necessary if the polling rate is at least 4x that of your maximum rotational speed, which results in 200 samples per second, 100 samples per coil per second.  However, with the resolution that you desire it will be safer to go 10x nyquist, which is around 1ksps, 500 samples per coil per second.  You can have two chip select lines with a shared SPI bus.  The MSP430 series is sufficient for aggregating such data at a recommended 8mhz+  clock.

Thanks

Charles,

The sampling rate you are quoting is way to low for our application.  I said earlier that I would need sampling rates of 20KHz.  When I look at the LDC data sheet, page 21, using DRDYB mode, what is the INTB pin assertion rate or in other words, the time between INTB pulses.  I understand that is is also a function of the coil, but what is it for the coil shown (used) in the EV kit?  That is why in this motor controller design we are doing, the angular positioning has a microcontroller of its own, simply to get angular position constantly updated at the max rate possible with the position sensor being used.  With the AM256 I mentioned earlier, I do not have to do a byte write to do a data read from the sensor.  Here, I have to write 0x21 to access the low byte read register and 0x22 to access the high byte read register.

Timing wise, it seems that the LDC could be data read (both bytes) at least at a 50KHz rate.  Is this a wrong assumption?  I would be doing the data read in the interrupt service routine of the microcontroller so the INTB pulsing while reading data is a do not care issue.  When the data is read, the INTB pin is reset so when I exit the interrupt service, interrupt servicing is again active until the next INTB pulse.  Can anyone provide the time between INTB pulses for the coil in the EV kit?

Ken Kadrmas

The INTB assertion rate is roughly the same as the LDC1000 internal sampling rate, which is a function of the sensor frequency and the time delay setting as described in the datasheet.  To access proximity data, you would only have to write the register address 0x21 once and read twice.  The address is automatically incremented for multibyte reads.

Due to the uncertainty in INTB assertion times, I would recommend polling.

Thanks

Charles,

To help others on this forum, can you please be more specific about INTB.  So page 5 of the datasheet says Ts_min and Ts_max.  So if my Fsensor is 5MHz, then the min response time would be about 38 microseconds and the max response time would be about (6144/192)x38 or 1.216 milliseconds.  Is this information correct?

How is this uncertainty reduced and why does it have such a wide range?  Is this a function of the coil or spiral layout (in my case) or both.  It seems that the characterization of this part is uncertain.  How does a designer know for sure that he can use it in an application or not?  I understand your suggestion of polling, but, then you are suggesting that IF the positional value was unchanging, that there is absolutely no changing of position.

For example, lets say the BLDC motor is stopped,  so I energize the three-phase drive based on the current positional reading.  Now, I expect the rotor/stator positioning to change.  I have to time this out and maybe increase the three-phase drive current, or whatever to get motion.  If there is a large uncertainty in INTB, I can easily overdrive the coils, cause heating, and other issues.  I do expect the LDC to tell me position regardless if any motion did occur.  I may be more concerned than I should be, but I do not like uncertainty in any control design.

Ken Kadrmas

Hi Ken,

Let me clarify: the INTB response is not synchronized to a specific time-base.  So for multi-coil applications, polling is a better methodology.  The data ready frequency is the output data rate shown on page 12:

Output data rate=( fsensor)/(Response Time/3), Sample per second(SPS)

INTB will respond even if the data is unchanged.  

Thanks

Hello Ken,

Let me chime in for a sec here.

Two coils will need to be at 90 deg. from each other.

All your calculations regarding the response time are correct. But the timing is not changing, it is set by the register value. So if you have set it to 192, you will have lag time of 38usec for 5MHz oscillator (with the sampling rate 3 times faster)

One more thing to notice is that as the coil gets covered by more and more metal, its frequency will reduce slightly, increasing the response time.

To TI:

In another thread, a TI person said that there would be a detailed App Note on how to design the target and also a online sim to determine the required dimensions for the desired accuracy.  When are the dates for this to occur and will we be notified by email when this happens.

I will accept your word that I will be able to sample at 50K samples/second.  Whether I use polling or INTB I will decide after i can test that aspect.  I thought about getting an EV kit, but since i would simply end up trying target shapes that i have no way to realistically evaluate, I will wait.  In any case, the EV kits are shown to be on backorder on your website.

Ken Kadrmas

Hello Ken,

The schedule for the target design app note has not been finalized yet.

Please check back with us at a later time.