# Toyota IPM Motor Controller Design Details



## jddcircuit (Mar 18, 2010)

This is a spin off thread from this thread.
http://www.diyelectriccar.com/forums/showthread.php/highlander-hybrid-and-prius-motors-86829.html

It seems that there are several of us exploring using salvaged Toyota internal permanent magnet motors and Power inverters in our EV conversions but the motors and power electronics only have value if we can get a working controller.

There is a lot of information out there. Hopefully this thread will help some of us towards getting a working controller.

The current discussion is in regards to hacking the built in resolver for the needed rotor position feedback but feel free to add any information that you have regarding the control of these types of motors.

General theory is ok but more specific examples or experiments is preferred.

Here is a quote from one of the later posts


jddcircuit said:


> I will explore multiple methods. You got me thinking about what would be needed to drive the resolver directly and decode it right along with my motor current regulation attempts.
> 
> I don't know what you mean by "truly open" but I love to have somewhere that I can bounce my ideas. I am not sure what the outcome so I do not make claims or predictions of what fruits it will bare. My signature states that my project requires a custom ECU for the Prius Inverter so yes we may have a common goal. There are others trying to use these motors but are not as vocal. I am sure they will be lurking.
> 
> ...



Jeff


----------



## jddcircuit (Mar 18, 2010)

I have gotten several private messages lately from people that are installing these motors or considering installing them.

Prius, Camry, Highlander, Lexus, etc. All pretty much the same from a control point of view.

We all seem to be in the same boat not having a robust control solution at the moment.

Please introduce yourself in this thread so we can all get an idea of how many(or few) of us are working to the same goal.

This may take several skill sets to make this thing a reality.

Best Regards
Jeff


----------



## toddshotrods (Feb 10, 2009)

I can't contribute anything meaningful to the controller development, unless you need CAD for the housing, but I am _considering_ using a Highlander motor on my e-bike. I think my needs (180-250kW) are going to be outside those of the average DIY'er, so I'm not so sure what's developed here will work for me. I am subscribed and taking notes though...


----------



## jddcircuit (Mar 18, 2010)

I just did this video of one my current regulation experiments using the Prius inverter.






I am in the process of laying out a PCB for the Arduino Due. This new shield will have the ADC chip on board so I won't need the plug in board you see in the video. I add provisions for using the built in resolver in the Prius motor for getting rotor position. I also added a CAN bus transceiver and some connectors for my BMS design. You can notice I left the 96pin connector for plugging in some of the Analog Devices EVAL boards as a fall back plan and for testing purposes. I already have a Resolver to Digital board that can plug into that 96pin connector so I can compare my angle calculations with it.









Thanks
Jeff


----------



## jddcircuit (Mar 18, 2010)

I am finding these wiring diagrams for the interconnections between all the Gen2 Prius hybrid systems very useful in my hacking efforts.

Inverter->Motor Generators->ECU


----------



## jddcircuit (Mar 18, 2010)

In my previous video the current sensor output was very noisy. Here is the same signal with respect to the analog reference coming from the inverter.

The red trace is the differential signal representing the phase current.


----------



## jddcircuit (Mar 18, 2010)

I enjoyed reading this guys Thesis on the 2004 Toyota Prius drive systems


I took some notes:

- motor to wheel gear ratio 4.113
- motor torque of 400Nm up to 1200 rpm but will overheat in short amount of time at this current
- motor speed of 1000 rpm with a 200V bus voltage and no flux weakening
- motor speed of 2500 rpm with a 500V bus voltage and no flux weakening
- 500V bus is made using a switching boost converter limited to 20kW or 100 battery amps in the Prius

- he presented a field oriented control method with V and I constraints to manage flux weakening and reluctance torque
- negative Id to counter flux generating bemf and to increase the reluctance torque
- bemf aligns with q-axis
- he mentions the pesky EMI problem with the current sensors
- i don't know what he means by over modulation region
- he estimates the continuous rating of the 50kw motor to be around 17 or 20kw with 55 degC coolant
- continuous torque to be approximately 150Nm but with additional cooling who knows


This is going to be easy

I have some ideas on how to work around some of these limitations but for now I will be happy if I can get it to work at this level first.


----------



## jddcircuit (Mar 18, 2010)

I just finished the PCB layout of my Arduino Due Prius Inverter Control shield and placed the order with ExpressPCB.

I didn't put anything on it to measure the temperature of the inverter nor the motor. I wasn't sure what type of sensors they were and I have enough to work on for now. I guess I will have to add them later.

In the meantime I will be researching some more on the control theory and programming side.

Regards
Jeff


----------



## Coulomb (Apr 22, 2009)

Great resource, JDD; thanks.



jddcircuit said:


> - i don't know what he means by over modulation region


I think it just means using square voltage waves, or trapezoid voltage waves, to drive the motors.

If you apply say 110% modulation (where 100% modulation uses all your available DC bus voltage, i.e. you are using everything from 0% to 100% PWM ratio), then the peaks of your generated sine waves will be clipped. In other words, your PWM ratio will go to 100% and 0% for a significant part of the sine wave; you'd like to go to 105% and -5%, but of course you can't.

As you increase the modulation past 100%. you "go further into the over modulation region", and the clipping gets worse and worse. Your sine waves go from correctly rounded to a little clipped to trapezoidal to (eventually) practically square waves.

Of course, IPM motors are typically designed to be driven like this. I think I read somewhere that the Prius switches from PWM modulation to actual direct square waves (in the latter, you don't bother chopping up the signal at a PWM frequency, you just switch hard on and hard off at the electrical frequency of the motor). This switch is based on motor speed; PWM below that speed, square waves above that speed.

I don't know what the shape is below that speed (it would presumably be sine waves or trapezoid waves, or maybe something that better matches the back-EMF shape.)


----------



## e*clipse (Aug 2, 2009)

Hi Jeff!

Great to see this thread is going.  Now I can post that _boring  _stuff that pertains mostly to motor controllers for the Toyota IPM synchronous motors here. 

Just to start, here are some BEMF measurements at different speeds:
(Taken from the Highlander Hybrid thread)
Quote:
Originally Posted by *PStechPaul*  
_It should be possible to add three equal resistors from each of the three phases to a common point, which can be used as a neutral reference. 

It should also be possible to do the conversion mathematically, by using vector sums and differences, or trigonometry. 

Here is explanation of the "phantom neutral" and ways to derive an effective neutral from three phase delta, or a third phase from two legs of a three phase wye source.
http://www.marcspages.co.uk/pq/4510.htm

Other possibly helpful references:
http://elect.mrt.ac.lk/EE201_3phase_sym_comp.pdf (for math whizzes)
_

The information above is extremely interesting. The paper for math whizzes (I'm definitely NOT one ) did a great job of explaining the wye vs delta thing. One thing I found VERY interesting is that industrial 3 phase systems will often have a 4th connection for the neutral. If the system is working properly, it should be balanced, and there should be no current in the neutral line. It did go into whether the SOURCE was wye or delta connected. I wonder.... Is the standard 6 switch inverter considered a wye or delta source?? 

So, I connected a "phantom neutral" using some BIG wirewound 1K resistors I have sitting around. I then replicated my back-EMF test. 

Here is the data from the phantom neutral back emf test. The numbers are all out of my 'scopes "waveform parameters" display, except for the motor rpm column. One thing I found interesting and cannot explain are the AC RMS and AC+DC RMS numbers. Note that the phase difference was the expected 120 degrees, except the first number, I don't know why. The last set of numbers, at 41.9Hz were taken by moving the probe from phaseC to phaseB.

I also included a couple of waveform examples. They have similar "bumps" within the waveform as the previous test. It may be worsened by my lousy phantom neutral connections. 
 Attached Thumbnails


----------



## e*clipse (Aug 2, 2009)

More interesting stuff! Well, I think it is....

(Stolen from the Highlander Hybrid thread)
Please note that an error in this post has been edited (bold) to the give the right information. Don't want to appear stupid 2X. 

Now that I had a phantom neutral working for the motor, I was curious how the resolver timing worked with this. It took a bunch of messing with resolver drive frequencies, etc. The tests were run with resolver frequencies that were much lower than I would run for a real motor control, But I got some cool graphs illustrating the resolver working along with the back EMF. I triggered the scope with the BEMF signal.

VERY cool: There is a definite point where the resolver's sine output zero crossing and the phase A zero crossing happen at the same time! 

The first pic is phaseA and the resolver *cos* output. Resolver frequency:1.5 kHz.
The second pic is phaseA and the resolver *sin* output. Resolver frequency: 1.5 kHz.
The third pic is phaseB and the resolver *cos* output. Resolver frequency: 1.5 kHz.
The last pis is zoomed up on phaseA and the resolver *cos* output. Resolver frequency: 5 kHz. 
Attached Thumbnails


----------



## e*clipse (Aug 2, 2009)

Here are the resolver tests I did in the other thread:

Here's what I found while testing the resolver:
1) If there is DC offset in the drive signal, it doesn't seem to affect the output.I tested this at 5kHz with a p-p amplitude of 5V. I varied the DC offset from -0.84V > 0V > 1.03V. The output was always centered around -0.14V with an amplitude of 1.08V p-p.

Of course that could change at higher offsets - I would be cautious about saturation. Saturation is what limited my tests because of my signal generator's limitations. When the offset was above the values shown above, the peaks of the output signals were clipped.

Because the input signal's DC offset doesn't seem to affect the output, it may be possible to build a driver that uses only positive power. That should make things easier. ​2) The driver frequency did not affect the input/output amplitude ratio significantly between 5kHz and 20kHz. In this frequency range, the input/output ratio was ~4.825:1 (requires higher input > output ) 
3) The driver input/output amplitude ratio decreased (higher output/input) between 20kHz and 125kHz, where this behavior peaked. At 125kHz input frequency, the ratio was 1.09:1. A 2:1 ratio happens somewhere between 50kHz and 75kHz.

I guess one could say there is an optimum at 125kHz. If an envelope filter is used and one doesn't have to catch precise peaks at such a high frequency, this could be valuable.  OTOH, the stability of the input/output amplitude ratio between 5kHz and 20kHz may prove valuable because changes in driver frequency would not affect the output amplitude. 

I keep mentioning an "envelope filter" - in reality, it's just a low pass filter.  The problem is what to do about the signal reversing sign. If a lowpass filter only looks for peaks, then one would end up with a "rectified" filtered signal. Therefore, the filter must look for peaks before a zero crossing and low points after, ect. 

Even if the signal is offset 2.5V for a 5V p-p signal, the problem doesn't change.  It must be "intelligent" enough to see the real output of the resolver. One possibility may be to perfectly trigger an "undersample" every peak (or low point) resolver cycle. Ideas, anyone?


----------



## Coulomb (Apr 22, 2009)

e*clipse said:


> One thing I found interesting and cannot explain are the AC RMS and AC+DC RMS numbers.


Well, you expect no DC component, so that's why the AC RMS and the DC RMS values are the same.

You know of course that RMS = Root Mean Square; it's like the DC equivalent of AC. If you put a 120 ohm resistor across 120 VDC, you get 1 A of current and 120 W of power. If you put the same 120 ohm resistor across 120 V AC (a sine wave with an RMS value of 120 V, but varies instantaneously from zero to +170 V back to zero, down to -170 V, and back to zero again), you also get 1 A RMS of current (varies from zero to +1.41 A to zero, down to -1.41 A and back to zero again), and importantly, you get the same 120 W of power. (Well, average power; the instantaneous power varies from zero to 240 W to zero, back up to 240 W and down to zero; you don't get "negative power" because when the current is negative, the voltage is negative too, so the product is positive).

For a square wave, the DC and the peak to zero value (half the peak to peak value) are the same. So the ratio of peak to peak voltage and RMS voltage is 2.0. For a sine wave, the ratio turns out to be twice the square root of 2, or about 2.828. For signals with narrow peaks, the ratio can be higher.

For your numbers, I see about 2.9 ratio between the peak to peak values and the RMS values. That implies that your signals are nearly sine waves, but just a little bit "peakier" than a pure sine wave. And indeed, they do look like that.



> Note that the phase difference was the expected 120 degrees, except the first number, I don't know why.


I think that's just because the amplitude is so low, and the signals are somewhat distorted, so you are seeing some jitter in where the instrument is deciding that the zero crossing is. So it gets the phase a bit wrong on the first measurement where the amplitude is less than 4 volts RMS.


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> the stability of the input/output amplitude ratio between 5kHz and 20kHz may prove valuable because changes in driver frequency would not affect the output amplitude.


I think this freq range is the way to go.




e*clipse said:


> I keep mentioning an "envelope filter" - in reality, it's just a low pass filter.  The problem is what to do about the signal reversing sign. If a lowpass filter only looks for peaks, then one would end up with a "rectified" filtered signal. Therefore, the filter must look for peaks before a zero crossing and low points after, ect.


I am a little confused with what you are trying to do exactly but it sounds like you are trying to demodulate the sine and cosine wave forms from the carrier.

What happens if you subtract the carrier and one of the returns? Try this on your scope and see if it gives you a signal that will be more compatible with your peak detector.

I am not sure of the best way to demodulate. In my approach I am going to sample the sin and cos voltages in sync with the carrier so hopefully I can catch them at their peaks.

Jeff


----------



## jddcircuit (Mar 18, 2010)

Coulomb said:


> As you increase the modulation past 100%. you "go further into the over modulation region", and the clipping gets worse and worse. Your sine waves go from correctly rounded to a little clipped to trapezoidal to (eventually) practically square waves.
> 
> Of course, IPM motors are typically designed to be driven like this. I think I read somewhere that the Prius switches from PWM modulation to actual direct square waves (in the latter, you don't bother chopping up the signal at a PWM frequency, you just switch hard on and hard off at the electrical frequency of the motor). This switch is based on motor speed; PWM below that speed, square waves above that speed.
> 
> I don't know what the shape is below that speed (it would presumably be sine waves or trapezoid waves, or maybe something that better matches the back-EMF shape.)


This is exactly the kind of stuff we will need to consider as the IPM control algorithm is evolves. I just hope we can get to that point.

Thank you very much
Jeff


----------



## jddcircuit (Mar 18, 2010)

IPM motor regen question:

I think I am getting a handle on this max torque per amp concept of an IPM motor and using Iq>0 and Id<0 for drive.

However I am not so sure about optimal regen for these types of motors.
Since there is a max torque per min amp in the drive, I would assume you would want a max amp per min torque for the regen. This way you would get the most back out of the motor for the minimum amount of speed reduction.

Perhaps in regen the reluctance torque is not helpful for putting energy back into the battery. It will most likely slow you down but will not produce energy. If this is the case then the regen alorithm will use a Iq<0 and Id=0 much like a surface mounted magnet motor in regen.

Another thing to consider may be that Id<0 may still need to be enforced even during regen if the motor is operating at very high speeds to avoid excessively high Iq as the result of very high bemf.

If very fast slow down is commanded then producing negative torque using the reluctance torque can be used but will simply consume energy to do so which is not regen. This is probably only done at low speeds when there is not enough bemf to pull from.

As I type this I am wondering if the Prius generator (MG1) has the same rotor design. Perhaps it is closer to BLDC since it's primary function is different. There is not much on this motor but it is a 30kw resource that I am planning on using.

Regards
Jeff


----------



## Coulomb (Apr 22, 2009)

jddcircuit said:


> Since there is a max torque per min amp in the drive, I would assume you would want a max amp per min torque for the regen. This way you would get the most back out of the motor for the minimum amount of speed reduction.


I don't think you can buy much with this. At a particular speed, so much torque represents so much power, so at a particular battery voltage, so much torque represents exactly so much current; getting more current than that would be violating the conservation of power (energy per interval of time). Maybe at low speeds you can do something to tweak the efficiency so that you can still get moderate current where you otherwise might have gotten very little, but it will still "cost" the same amount of torque for each ampere of regen current.



> Perhaps in regen the reluctance torque is not helpful for putting energy back into the battery.


My understanding (but I could well be wrong) is that reluctance motors have just as good regen as other AC motor types. If it wasn't for the slight additional improvement in efficiency that a permanent magnet provides, most commercial EVs would be using SR motors. In fact, if the rare earth materials for the magnets become scarce and/or expensive, EVs could switch to reluctance motors rather than induction motors. What I'm trying to say is that their performance is pretty close to PM and induction motors.



> Another thing to consider may be that Id<0 may still need to be enforced even during regen if the motor is operating at very high speeds to avoid excessively high Iq as the result of very high bemf.


If the paper I'm still reading through is correct, then flux weakening is needed for all speeds above a fairly low figure, 2500 RPM comes to mind. In that case, you would need flux weakening (Id < 0) for regen at all speeds above this threshold, because otherwise the back EMF would result in the DC bus going higher than 500 VDC (on the high side of the booster), and that would be dangerous for the electronics. I note that you would have to provide Id < 0 at *all times* that the motor is spinning above 2500 RPM, or the electronics that the motors would be connected to would cause the diodes across the IGBTs to rectify the motor output into DC bus, which may cause a dangerous overvoltage. In the Prius, with MG2 connected to the wheels (so to speak), you can't stop it spinning above 2500 RPM above a rather modest speed (around 30 MPH perhaps).

It's a little scary to think that if the processor driving the motors ever crashed at a speed above this, it would likely fry the electronics and put a short circuit across the motor, giving you way more regen than you would want (I think it would almost lock the wheels). I've never heard of this happening, although I have seen it discussed in papers defending the use of PM motors. They seemed to claim that rectifying the motor output into the battery would be a serious event (with quite strong braking and quite high currents), but the electronics and the battery are likely to survive it. I wonder though about the Prius and its boost converter; the IGBT diodes would not connect directly to the battery, and the limited power of the DC-DC converter would mean it could not all get to the battery. Without the battery to absorb the power, I think it would fry a most of the power section of the inverter.

So the cost of a software bug could be high ! Be careful guys. Start small and work up only when you are confident of the software.



> As I type this I am wondering if the Prius generator (MG1) has the same rotor design. Perhaps it is closer to BLDC since it's primary function is different. There is not much on this motor but it is a 30kw resource that I am planning on using.


Yes, it's weird that MG1, which on the 2004 Prius has about 60% of the peak power of MG2, is so neglected, and there is so little information on it. My feeling is that it's made much the same as MG2, so with similar characteristics, just scaled down for a lower power.


----------



## bLdC (Jan 21, 2013)

Hi All!

Some more bits and thoughs.
Just one more Prius 04 transmission project. 

I spun the motors(with no load), sometime ago, and i didn't see difference in the way they perform. 
Except the different base speed.
Jeff, if MG1 and MG2 have identical design, shouldn't the shape of the BEMF diagrams look alike, if scaled properly?

Here is some more info on the resolver part. The links may be usefull.
http://www.designnews.com/author.asp?section_id=1419&doc_id=259600

If we search for ready solutions and high integration,* TI* shares great amount of information on the *motor control* and have reference designes for their DSPs. Looks like they have what we need, but not everithing is open source. At least it is tested. Thoughs?


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> Hi All!
> 
> Some more bits and thoughs.
> Just one more Prius 04 transmission project.
> ...


Welcome bldc
Give us some details regarding your project. How far along are you with your control solution?

I also got the motors to spin no load but when I put it in a car under a load it was a very different experience. The motor behaves very different under a load. I was able to drive the car around at golf cart speeds with 48v.

I was not using any current regulation. I was just supplying a modulated voltage that followed the resolver.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

Coulomb said:


> My understanding (but I could well be wrong) is that reluctance motors have just as good regen as other AC motor types. If it wasn't for the slight additional improvement in efficiency that a permanent magnet provides, most commercial EVs would be using SR motors. In fact, if the rare earth materials for the magnets become scarce and/or expensive, EVs could switch to reluctance motors rather than induction motors. What I'm trying to say is that their performance is pretty close to PM and induction motors.


Perhaps you are referring to dynamic braking. I am only referring to the type of dynamic braking that can put energy back into the battery like a generator. In a SR (switched reluctance) motor the rotor does not have a magnetic source to induce a voltage onto the stator so no generator effects that I can see.

edit: I am mistaken about SR motors regen. It will take me a while to figure this part out but it is probably important for this type of combo motor.



Coulomb said:


> If the paper I'm still reading through is correct, then flux weakening is needed for all speeds above a fairly low figure, 2500 RPM comes to mind. In that case, you would need flux weakening (Id < 0) for regen at all speeds above this threshold, because otherwise the back EMF would result in the DC bus going higher than 500 VDC (on the high side of the booster), and that would be dangerous for the electronics. I note that you would have to provide Id < 0 at *all times* that the motor is spinning above 2500 RPM, or the electronics that the motors would be connected to would cause the diodes across the IGBTs to rectify the motor output into DC bus, which may cause a dangerous overvoltage. In the Prius, with MG2 connected to the wheels (so to speak), you can't stop it spinning above 2500 RPM above a rather modest speed (around 30 MPH perhaps).
> 
> It's a little scary to think that if the processor driving the motors ever crashed at a speed above this, it would likely fry the electronics and put a short circuit across the motor, giving you way more regen than you would want (I think it would almost lock the wheels). I've never heard of this happening, although I have seen it discussed in papers defending the use of PM motors. They seemed to claim that rectifying the motor output into the battery would be a serious event (with quite strong braking and quite high currents), but the electronics and the battery are likely to survive it. I wonder though about the Prius and its boost converter; the IGBT diodes would not connect directly to the battery, and the limited power of the DC-DC converter would mean it could not all get to the battery. Without the battery to absorb the power, I think it would fry a most of the power section of the inverter.


I don't think it works exactly like you present. Yes the bemf will get rectified onto the bus if the controller stops at higher speeds but the frequency of the peaks above battery voltage and the stator inductance + the boost converter inductance are what keep things manageable.

I did a simulation for a disabled controller so no switching which is what happens when the prius inverter faults for over current. I used 400Hz electrical cycles (6000 motor rpm) producing +/-800V bemf. Let this get rectified into a 200V battery pack through 5mH stator inductance and 373uH boost inductor.










The result is +/- 60A stator current and 35A going into the battery.

This doesn't seem as violent as you describe.

I am not sure my analysis is correct but that might explain why we haven't seen a Prius wreck as a result of what you describe.

Jeff


----------



## jddcircuit (Mar 18, 2010)

I tried to improve my simulation of what happens when inverter disables (fault state) at 6000rpm when bemf is higher than battery voltage using all three phases.

The bemf will rectify onto the bus and I created a path to the battery through the high side boost converter transistor.









It is showing that battery current limit outs at 60amps. So 200V*60A 12kW of regen is probably stopping pretty fast.


----------



## bLdC (Jan 21, 2013)

jddcircuit said:


> Welcome bldc
> Give us some details regarding your project. How far along are you with your control solution?
> 
> I also got the motors to spin no load but when I put it in a car under a load it was a very different experience. The motor behaves very different under a load. I was able to drive the car around at golf cart speeds with 48v.
> ...


I used a specialized controller with Space Vector Modulation in open loop mode, just to see if everithing works and to make some measurements. 
For this i had to connect directly to the optocouplers of the IGBT-drivers so i can have more control. 

The controller i use cares for the timings but has not enouth options for control. 
I will need some more computing power so i can realise FOC and current control loop. 
Probably moving to DSP controller from TI.

Under a load, with low voltage, i didn't see anything strange. Tried up to 60A current, loading it with the bracing system of the car i'm converting. 
Will try higher voltage, after i have a current feedback.

Another point - i measured the resistance of the temp sensor, it was 50K when arround 24C so we can conclude it is a 47K or 50K NTC thermistor.


Regards


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> I used a specialized controller with Space Vector Modulation in open loop mode, just to see if everithing works and to make some measurements.
> For this i had to connect directly to the optocouplers of the IGBT-drivers so i can have more control.
> 
> The controller i use cares for the timings but has not enouth options for control.
> ...


bldc,

That is good to know about the motor thermistors.
Do you have any ideas on the MIVT, GIVT, and CT signals coming from the inverter? Are these signals for the the temperature of the IGBT modules? If so do you have any ideas about how to interface with them?

I like that you are going to use a TI controller. I am going to use the Arduino Due on my first attempt at FOC but I also have a TI DRV8x Evaluation kit for spinning motors but I haven't opened it up yet. I think having parallel efforts is a good thing.

I am interested in what you mean by interfacing directly with the optocouplers of the IGBT modules. Do you mean that you did not use the MUU, MVU, MWU signals at the connector and you had to go deeper into the inverter circuit or is that the same thing?

On my first test drive I had the resolver feedback but I was only providing Vq waveform like I would for a BLDC motor. It ran like crap until I phase shifted it 30degrees. At this time I did not know anything about reluctance torque vector nor did I have any current sensors working.

Without a load it ran better (smoother and faster) when my voltage was aligned with the Vq(bemf). I guess that this is not truly open loop since I did have angular position feedback. I assume that when I am doing FOC to determine Vq and Vd voltages this load difference will take care of itself.

However eclipse was interested in running his motor open loop to see things move. Perhaps details about what you did will help him.

Maybe post a link to the other forum with some of your build details. The english translator works pretty good.

Thanks
Jeff


----------



## jddcircuit (Mar 18, 2010)

Resolver demodulation plans

One of the first things that I am planning on doing when my interface board arrives is to work on the resolver excitation and demodulation portion.
I have an AD7609 IC on my board to do the simultaneous ADC sampling.
I am going to follow this tutorial from TI using the alpha beta tracking filter approach.









It also mentions the 8 to 16kHz excitation frequency range that resembles the freq range that eclipse observed in his experiment.

I think this tracking filter gives me angular velocity form the first integrator and then angle out of the second integrator.

Jeff


----------



## e*clipse (Aug 2, 2009)

I've been using TI's app note regarding directly using the signals from a resolver for position sensing with a DSP.

The app note is TI#SPRA605 from Feb. 2000

"TMS320F240 DSP Solution for Obtaining Resolver
Angular Position and Speed"

They go into all the nitty gritty details for pulling this off, including two different methods, filtering using a DSP, etc.

The first pic is the input signal conditioning circuit they recommend.

If you look at the TI diagram, the top circuit is a driver signal, based on PWM from two outputs on the output of the DSP. This is similar to what Jddcircuit is doing.

The second two circuits (below the driver) offset the output of the resolver (one circuit for each output) and do a bit of filtering.

In my KISS philosophy, this seems a bit too complicated. Also the op-amps they recommend are a bit on the expensive side with very high frequency capability.

What we want is a nice clean signal centered at 2.5V with an amplitude of just under 5V for the AtoD converter. The second schematic (that looks like hand scribbles) is a way to accomplish this; it is a simple differential amplifier with a 2.5V bias.

I used one of Microchip's MCP602 cmos op-amps for the test and designed for a gain of 2. The DC bias was designed to be 1/2VDD.
I've tested it with these values: 
R1 = 1.2kOhm
R2 = 2.4kOhm
R3 = R4 = 4.7kOhm

It's not perfect; there certainly could be some improvement.  Nothing a bit of tuning and good construction won't fix.  There was a bit of noise due to my power supply and the fact that the circuit was put together on a breadboard. Also, the output values were just a bit off:
DC mean: input: 0V output:2.72V (it's a bit high - perhaps due to 5% resistor values. A better solution may be a 2.5V voltage reference like TI's TL2425 (referenced in the TI app-note)
Amplitude, p-p: input: 1.88V output: 3.75V
frequency: 10kHz
phase angle: less than 1 degree.

Now what I need is a good demodulator. I tried both a low pass filter (two tries with 2nd order Butterworth filters 2kHz and 200Hz cut-off frequencies) Don't bother - they don't work.  I had a bit more success with a simple AM demodulator (diode and capacitor) However, it passed a 60hz spike and had the obvious problem of rectifying the signal - reversing the negative swing of the sine wave.

Any demodulator suggestions?


----------



## jddcircuit (Mar 18, 2010)

I did an experiment with the DACC on my Arduino Due to get familiar with it. I had a little bit to learn but eventually I got it to output what I wanted. I am planning on using this DAC feature to produce the sine wave excitation for the resolver position sensor.

This simple experiment just produced a triangle wave. I just sent the pwm counter value to the DAC register in this case. In center aligned PWM mode the pwm counter goes up and then down thus the triangle. You can also notice the stair stepping. I updated the DAC value 32 times per PWM cycle in this case.









I will want my excitation signal in sync with my PWM because in my design the simultaneous ADC that I am using for motor phase currents will include the resolver sin cos signals and it needs to convert at these PWM mid points for motor control.

I think by having the resolver excitation peaks lined up with my ADC sampling will inherently remove the carrier without the need for any additional circuitry.

I am going to run everything at 8kHz for starters. Again this decision is based more on PWM reasons rather than resolver reasons. I could easily switch everything to 10kHz if I had to.

Next step is to turn the DAC output from a triangle into a sine wave using a sine look up table so when my hardware arrives I can amplify it and drive the resolver.

Jeff


----------



## bLdC (Jan 21, 2013)

jddcircuit said:


> bldc,
> 
> That is good to know about the motor thermistors.
> Do you have any ideas on the MIVT, GIVT, and CT signals coming from the inverter? Are these signals for the the temperature of the IGBT modules? If so do you have any ideas about how to interface with them?


What I know is from the descriptions of the terminals on the ECU side.
I made a list of the signals we may need. It contains the descriptions, pin numbers, wiring color etc.
Here is what I have for the MIVT, GIVT, and CT.
it's for prius-04:
P03(G) -MIVT -Motor inverter temperature -2 to 4.5V - ADC-MCU
P06(W-Y) -GIVT -Generator inverter temperature -2 to 4.5V - ADC-MCU
P03(G-R) -CT -Boost converter temperature sensor -2 to 4.5V - ADC-MCU

this 2 to 4.5V is probably the range of the signal. 
We just have to find what temperature corresponds to what voltage. 
I think this temp-sensors are integrated in the IGBTs.



jddcircuit said:


> I am interested in what you mean by interfacing directly with the optocouplers of the IGBT modules. Do you mean that you did not use the MUU, MVU, MWU signals at the connector and you had to go deeper into the inverter circuit...


Yes, but it is tricky. 
It will be better if we can use the MUU, MVU, MWU pins.



jddcircuit said:


> Maybe post a link to the other forum with some of your build details. The english translator works pretty good.


I'll post here if I have something interesting to share, or will start new thread.
google-translate is great but, I think, I can manage it better .


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> What I know is from the descriptions of the terminals on the ECU side.
> I made a list of the signals we may need. It contains the descriptions, pin numbers, wiring color etc.
> Here is what I have for the MIVT, GIVT, and CT.
> it's for prius-04:
> ...



Ok good info.
I am probably going to defer the temperature stuff for now and have this thread to come back and refresh my thinking.

I am using the U,V,W pins for both the Motor and Generator. I didn't know there was a different way. Pulling anyone of the lines low turns on the High Side IGBT for that phase in case anyone was wondering.

There is a built in deadtime. I forget what the deadtime is but I remember that it was long enough that made me want to use longer pulse widths to avoid a minimum pulse width where it would not turn on at all.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

So now I have a sinusoidal signal coming out of DAC synced up with my PWM and ADCs. Again this is for exciting the resolver position sensor built into the Toyota motors.









I hope I can filter out the stair step adequately using a low pass of my amplifying driver circuit. I am not showing the other DAC signal that is 180 degrees out of phase. These are referred to as D_EXC and D_nEXC in the schematic.









I don't really want to increase the resolution of my DAC updates much. I need to leave as much CPU as possible to do all the FOC stuff. Processing time will become an issue real quick I am sure.

Jeff


----------



## jddcircuit (Mar 18, 2010)

Resolver Developments continued










I simulated the tracking filter from the TI tutorial just to learn out it reacts.









The green line represents the real motor angle. The blue line is the tracking result clocked at 8kHz.
The cool thing is that there is also angular velocity embedded in the filter. It is shown as the red line.

I was going to try and use the measured resolver signals directly in the Park transforms without converting them to rotor angle. This looked like it would work. Then I realized I needed angular velocity for my speedometer. I couldn't figure out how to get angle/time without getting angle. It looks like this tracking filter will do both jobs just fine.

I also did some sinLUT code for my Arduino

```
int16_t sinLUT[256] = {
  0x0000, 0x00C9, 0x0192, 0x025B, 0x0324, 0x03ED, 0x04B6, 0x057F, 0x0648, 0x0711, 0x07D9, 0x08A2, 0x096B, 0x0A33, 0x0AFB, 0x0BC4, 
  0x0C8C, 0x0D54, 0x0E1C, 0x0EE4, 0x0FAB, 0x1073, 0x113A, 0x1201, 0x12C8, 0x138F, 0x1455, 0x151C, 0x15E2, 0x16A8, 0x176E, 0x1833, 
  0x18F9, 0x19BE, 0x1A83, 0x1B47, 0x1C0C, 0x1CD0, 0x1D93, 0x1E57, 0x1F1A, 0x1FDD, 0x209F, 0x2162, 0x2224, 0x22E5, 0x23A7, 0x2467, 
  0x2528, 0x25E8, 0x26A8, 0x2768, 0x2827, 0x28E5, 0x29A4, 0x2A62, 0x2B1F, 0x2BDC, 0x2C99, 0x2D55, 0x2E11, 0x2ECC, 0x2F87, 0x3042, 
  0x30FC, 0x31B5, 0x326E, 0x3327, 0x33DF, 0x3497, 0x354E, 0x3604, 0x36BA, 0x3770, 0x3825, 0x38D9, 0x398D, 0x3A40, 0x3AF3, 0x3BA5, 
  0x3C57, 0x3D08, 0x3DB8, 0x3E68, 0x3F17, 0x3FC6, 0x4074, 0x4121, 0x41CE, 0x427A, 0x4326, 0x43D1, 0x447B, 0x4524, 0x45CD, 0x4675, 
  0x471D, 0x47C4, 0x486A, 0x490F, 0x49B4, 0x4A58, 0x4AFB, 0x4B9E, 0x4C40, 0x4CE1, 0x4D81, 0x4E21, 0x4EC0, 0x4F5E, 0x4FFB, 0x5098, 
  0x5134, 0x51CF, 0x5269, 0x5303, 0x539B, 0x5433, 0x54CA, 0x5560, 0x55F6, 0x568A, 0x571E, 0x57B1, 0x5843, 0x58D4, 0x5964, 0x59F4, 
  0x5A82, 0x5B10, 0x5B9D, 0x5C29, 0x5CB4, 0x5D3E, 0x5DC8, 0x5E50, 0x5ED7, 0x5F5E, 0x5FE4, 0x6068, 0x60EC, 0x616F, 0x61F1, 0x6272, 
  0x62F2, 0x6371, 0x63EF, 0x646C, 0x64E9, 0x6564, 0x65DE, 0x6657, 0x66D0, 0x6747, 0x67BD, 0x6832, 0x68A7, 0x691A, 0x698C, 0x69FD, 
  0x6A6E, 0x6ADD, 0x6B4B, 0x6BB8, 0x6C24, 0x6C8F, 0x6CF9, 0x6D62, 0x6DCA, 0x6E31, 0x6E97, 0x6EFB, 0x6F5F, 0x6FC2, 0x7023, 0x7083, 
  0x70E3, 0x7141, 0x719E, 0x71FA, 0x7255, 0x72AF, 0x7308, 0x735F, 0x73B6, 0x740B, 0x7460, 0x74B3, 0x7505, 0x7556, 0x75A6, 0x75F4, 
  0x7642, 0x768E, 0x76D9, 0x7723, 0x776C, 0x77B4, 0x77FB, 0x7840, 0x7885, 0x78C8, 0x790A, 0x794A, 0x798A, 0x79C9, 0x7A06, 0x7A42, 
  0x7A7D, 0x7AB7, 0x7AEF, 0x7B27, 0x7B5D, 0x7B92, 0x7BC6, 0x7BF9, 0x7C2A, 0x7C5A, 0x7C89, 0x7CB7, 0x7CE4, 0x7D0F, 0x7D3A, 0x7D63, 
  0x7D8A, 0x7DB1, 0x7DD6, 0x7DFB, 0x7E1E, 0x7E3F, 0x7E60, 0x7E7F, 0x7E9D, 0x7EBA, 0x7ED6, 0x7EF0, 0x7F0A, 0x7F22, 0x7F38, 0x7F4E, 
  0x7F62, 0x7F75, 0x7F87, 0x7F98, 0x7FA7, 0x7FB5, 0x7FC2, 0x7FCE, 0x7FD9, 0x7FE2, 0x7FEA, 0x7FF1, 0x7FF6, 0x7FFA, 0x7FFE, 0x7FFF};

// 10 bit index i, 0x0100 = 90degree, 0x0200 = 180, 0x0300 = 270
// signed 16bit result s sine and c cosine
void getSinCos(uint16_t i, int16_t &s, int16_t &c)
{ 
  uint8_t indexByte;
  uint8_t indexQuad;
  indexByte = i & 0x00FF;
  indexQuad = (i >> 8) & 0x0003;
  if (indexQuad == 0)
  {    
    s = sinLUT[indexByte];
    c = sinLUT[0xFF - indexByte];
  }
  if (indexQuad == 1)
  {   
    s = sinLUT[0xFF - indexByte];
    c = 0x0000 - sinLUT[indexByte];
  }
  if (indexQuad == 2)
  {   
    s = 0x0000 - sinLUT[indexByte];
    c = 0x0000 - sinLUT[0xFF - indexByte];
  }
  if (indexQuad == 3)
  {   
    s = 0x0000 - sinLUT[0xFF - indexByte];
    c = sinLUT[indexByte];
  }
}
```
Next Arduino code to implement the Resolver Tracking filter from the above simulation.

I should be getting in my PCB this friday so maybe I will have some real world angle measurements early next week.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

For the geeks

I am not a software guru
I am always unsure when it come to signed vs unsigned arithmetic

Here is my code that I will use to get rotor angle. It is the implementation of the alpha beta tracking filter simulation.

I am not showing where I measure the Resolver sin and cos but that is not very exciting.

If there is one thing for sure is that software will change.


```
// 0 to 90 degree only
int16_t sinLUT[256] = {
  0x0000, 0x00C9, 0x0192, 0x025B, 0x0324, 0x03ED, 0x04B6, 0x057F, 0x0648, 0x0711, 0x07D9, 0x08A2, 0x096B, 0x0A33, 0x0AFB, 0x0BC4, 
  0x0C8C, 0x0D54, 0x0E1C, 0x0EE4, 0x0FAB, 0x1073, 0x113A, 0x1201, 0x12C8, 0x138F, 0x1455, 0x151C, 0x15E2, 0x16A8, 0x176E, 0x1833, 
  0x18F9, 0x19BE, 0x1A83, 0x1B47, 0x1C0C, 0x1CD0, 0x1D93, 0x1E57, 0x1F1A, 0x1FDD, 0x209F, 0x2162, 0x2224, 0x22E5, 0x23A7, 0x2467, 
  0x2528, 0x25E8, 0x26A8, 0x2768, 0x2827, 0x28E5, 0x29A4, 0x2A62, 0x2B1F, 0x2BDC, 0x2C99, 0x2D55, 0x2E11, 0x2ECC, 0x2F87, 0x3042, 
  0x30FC, 0x31B5, 0x326E, 0x3327, 0x33DF, 0x3497, 0x354E, 0x3604, 0x36BA, 0x3770, 0x3825, 0x38D9, 0x398D, 0x3A40, 0x3AF3, 0x3BA5, 
  0x3C57, 0x3D08, 0x3DB8, 0x3E68, 0x3F17, 0x3FC6, 0x4074, 0x4121, 0x41CE, 0x427A, 0x4326, 0x43D1, 0x447B, 0x4524, 0x45CD, 0x4675, 
  0x471D, 0x47C4, 0x486A, 0x490F, 0x49B4, 0x4A58, 0x4AFB, 0x4B9E, 0x4C40, 0x4CE1, 0x4D81, 0x4E21, 0x4EC0, 0x4F5E, 0x4FFB, 0x5098, 
  0x5134, 0x51CF, 0x5269, 0x5303, 0x539B, 0x5433, 0x54CA, 0x5560, 0x55F6, 0x568A, 0x571E, 0x57B1, 0x5843, 0x58D4, 0x5964, 0x59F4, 
  0x5A82, 0x5B10, 0x5B9D, 0x5C29, 0x5CB4, 0x5D3E, 0x5DC8, 0x5E50, 0x5ED7, 0x5F5E, 0x5FE4, 0x6068, 0x60EC, 0x616F, 0x61F1, 0x6272, 
  0x62F2, 0x6371, 0x63EF, 0x646C, 0x64E9, 0x6564, 0x65DE, 0x6657, 0x66D0, 0x6747, 0x67BD, 0x6832, 0x68A7, 0x691A, 0x698C, 0x69FD, 
  0x6A6E, 0x6ADD, 0x6B4B, 0x6BB8, 0x6C24, 0x6C8F, 0x6CF9, 0x6D62, 0x6DCA, 0x6E31, 0x6E97, 0x6EFB, 0x6F5F, 0x6FC2, 0x7023, 0x7083, 
  0x70E3, 0x7141, 0x719E, 0x71FA, 0x7255, 0x72AF, 0x7308, 0x735F, 0x73B6, 0x740B, 0x7460, 0x74B3, 0x7505, 0x7556, 0x75A6, 0x75F4, 
  0x7642, 0x768E, 0x76D9, 0x7723, 0x776C, 0x77B4, 0x77FB, 0x7840, 0x7885, 0x78C8, 0x790A, 0x794A, 0x798A, 0x79C9, 0x7A06, 0x7A42, 
  0x7A7D, 0x7AB7, 0x7AEF, 0x7B27, 0x7B5D, 0x7B92, 0x7BC6, 0x7BF9, 0x7C2A, 0x7C5A, 0x7C89, 0x7CB7, 0x7CE4, 0x7D0F, 0x7D3A, 0x7D63, 
  0x7D8A, 0x7DB1, 0x7DD6, 0x7DFB, 0x7E1E, 0x7E3F, 0x7E60, 0x7E7F, 0x7E9D, 0x7EBA, 0x7ED6, 0x7EF0, 0x7F0A, 0x7F22, 0x7F38, 0x7F4E, 
  0x7F62, 0x7F75, 0x7F87, 0x7F98, 0x7FA7, 0x7FB5, 0x7FC2, 0x7FCE, 0x7FD9, 0x7FE2, 0x7FEA, 0x7FF1, 0x7FF6, 0x7FFA, 0x7FFE, 0x7FFF};

// 10 bit index i, 0x0100 = 90degree, 0x0200 = 180, 0x0300 = 270
// signed 16bit result s sine and c cosine, stored in 32bit space
// change to signed 32bit values? need to do some tests to understand arithmetic
void getSinCos(int32_t &i, int32_t &s, int32_t &c)
{ 
  uint8_t indexByte;
  uint16_t indexQuad;
  indexByte = i & 0x000000FF;
  indexQuad = i & 0x00000300;
  if (indexQuad == 0x0000)
  {    
    s = sinLUT[indexByte];
    c = sinLUT[0xFF - indexByte];
  }
  if (indexQuad == 0x0100)
  {   
    s = sinLUT[0xFF - indexByte];
    c = 0x00000000 - sinLUT[indexByte];
  }
  if (indexQuad == 0x0200)
  {   
    s = 0x00000000 - sinLUT[indexByte];
    c = 0x00000000 - sinLUT[0xFF - indexByte];
  }
  if (indexQuad == 0x0300)
  {   
    s = 0x00000000 - sinLUT[0xFF - indexByte];
    c = sinLUT[indexByte];
  }
}

int32_t RotAngleIndex = 0; // must handle wrap around to keep within 10bit range
int32_t RotAngle = 0;
int32_t RotVelocity = 0;
int32_t RotSinADC;  // 15bit magnitude, 1bit sign
int32_t RotCosADC;
int32_t RotSinLUT = 0x0000; // 15bit magnitude, 1bit sign
int32_t RotCosLUT = 0x7FFF;
int32_t RotError;
int32_t RotBetaError;
int32_t RotBetaError1;
int32_t RotAlphaError;


// call getRotorAngle() after the RotSinADC and RotCosADC values have been acquired
// RotError can be used to monitor tracking effectiveness or to initiate another iteration
void getRotorAngle()
{
   RotError = (RotCosLUT * RotSinADC) - (RotSinLUT * RotCosADC);
   RotBetaError = RotError; // may need to tune
   RotAlphaError = RotError; // may need to tune
   RotBetaError1 = RotBetaError + RotBetaError1; // integrator
   RotVelocity = RotAlphaError + RotBetaError1; 
   RotAngle = RotVelocity + RotAngle; // integrator
   RotAngleIndex = RotAngle >> 22; // take it down to a 10bit value, hopefully this works with signed values
   if (RotAngleIndex < 0)
   { RotAngleIndex = 0x00000400 + RotAngleIndex;} // handle index wrap around negative direction
   RotAngleIndex = RotAngleIndex & 0x000003FF; // handle index wrap around positive direction
   getSinCos(RotAngleIndex,RotSinLUT,RotCosLUT);  // run the look up
}
```


----------



## jddcircuit (Mar 18, 2010)

After more careful study of the alpha beta tracking filter and a simulation on the Arduino Due, I realized that the getRotorAngle() function should be called getNextRotorAngle().

It actually estimates the next angle based on speed and existing angle. This function should be run after each FOC regulation in preparation for the next sample interval.

It seems to track very well using the LUT to simulate the measured resolver signals +/- a step function.

I also tuned it a bit based on it's reaction to the step function.


```
void getNextRotorAngle()
{  // this routine will estimate the next Rotor Angle based on measured angle and speed
  // call this function after the phase current regulation in preparation for the next sample
   RotError = (RotCosLUT * RotSinADC) - (RotSinLUT * RotCosADC);  // do experiment to check for overflow
   RotBetaError = RotError >> 3; // may need to tune
   RotAlphaError = RotError >> 1; // may need to tune
   RotBetaError1 = RotBetaError + RotBetaError1; // integrator
   RotVelocity = RotAlphaError + RotBetaError1; 
   RotAngle = RotVelocity + RotAngle; // integrator
   RotAngleIndex = RotAngle >> 22; // take it down to a 10bit value, hopefully this works with signed values
   getSinCos(RotAngleIndex,RotSinLUT,RotCosLUT);  // run the look up for the next cycle
   // drive led with RotAngleIndex LSB for debugging
}
```


----------



## jddcircuit (Mar 18, 2010)

The Resolver tracking works!!!! I now have angle.

I implemented 1024 resolver counts per resolver revolution. That will be 512 counts per electrical commutation revolution. I will only need to use a higher resolution SIN Look Up Table if I want higher angle resolution.

At this resolution the angle result seems to be rock solid and it should be enough for the FOC I think.

Here is a picture of my Prius Inverter Controller Shield for the Arduino.
I only populated the components I needed for the resolver as you see in the lower right corner. The QFP is the AD7609 that I am using for all my ADC. The other IC is just a quad op amp. The rest is r,c, and q's.










Here is a picture of the 2001 Prius MG1 (Generator). It is small enough for me to carry around so it is going to be my test bed for the controller for now. It also spins the fastest at lower voltages so I can test at high speeds with less power.









I noticed my resolver driver circuit was a little warm. I may need to step down the Vp-p and/or increase my frequency to reduce the load it is seeing.

The optimization begins. Decoding the resolver signals was an interesting project. Thanks to "eclipse" for getting me to consider it. I was just going to use an off the shelf Resolver to Digital board to avoid this integration.

Next step is to apply some phase modulation to make sure I am lined up with my bemf the way I think I am before starting the FOC implementation.


Regards
Jeff


----------



## e*clipse (Aug 2, 2009)

Wow! Nice work Jeff!  

You're making tons o' progress. I'm still stuck trying to do something with the resolver output...  (filters, amplifiers, etc.)

What are you using for input filtering? Same stuff as that TI app note?
What is the V P-P you're driving the resolver with?

Great job!

- E*clipse


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> Wow! Nice work Jeff!
> 
> You're making tons o' progress. I'm still stuck trying to do something with the resolver output...  (filters, amplifiers, etc.)
> 
> ...


Thanks

I have no hardware filtering on the inputs. I run the differential signals right into my ADC chip AD7609. It can handle true differential signals upto +/- 10V.

I followed the block diagram from a TI tutorial about motors that I posted for demodulating the angle using two cascading integrators. I implemented the integrators in software and posted the code. I called the function getNextRotorAngle().

My output was 10Vpp 8kHz when I felt some warmth but it was working very nicely. I switched the gain on my driver amplifier to make it 5Vpp and it still works. I didn't have time to probe around or see if it was any cooler.

There could be other problems. I just threw it together so I may have some unknown workmanship defects hidden in there.

I am also thinking a higher carrier freq may be appropriate.

Jeff


----------



## jddcircuit (Mar 18, 2010)

16khz 8vpp seems to be working well.

I also phase advanced my carrier a little. The peak wasn't lined up with my sample pulse.


----------



## jddcircuit (Mar 18, 2010)

Motor is spinning

Here is a video.





In this experiment, I am commanding Vq only with Vd set to zero. No current feedback for torque control yet. This is only to test my new resolver tracking algorithm.

It is spinning at 1500 rpm with 60volt supply.

This is very basic control. I used a reverse Clark-Park transform to calculate the phase voltages.


```
void Spin_G_VqStyle()
{ 
  int32_t Vd;
  int32_t Vq;
  int32_t Valpha;
  int32_t Vbeta;
  int32_t sqrt3Vbeta;
  int32_t RotIndex;
  int32_t RotCos;
  int32_t RotSin; 
  int32_t Period;

  Vd=0;
  Vq= (int32_t) slider; // 8 bit unsigned
  // Vq=255;
  Period = (int32_t) PWM_Period;
  
  RotIndex = ResAngleIndex << 1; // the rotor is twice the freq of resolver
  
  getSinCos(RotIndex, RotSin, RotCos);
  // invPark
  Valpha = Vd*RotCos - Vq*RotSin; // 24 bit result
  Vbeta = Vd*RotSin + Vq*RotCos;  //

  Valpha = Valpha >> 8; // 16 bit number
  Vbeta = Vbeta >> 8;

  Valpha = Valpha << 15;
  Vbeta = Vbeta * 56756;  // 56756 = sqrt(3)*2^15

// 31 bit values
  VGa = Valpha;
  VGb = (0-(Valpha >> 1)) + (Vbeta >> 1);  
  VGc = (0-(Valpha >> 1)) -(Vbeta >> 1);  

  VGa = VGa >> 15;
  VGb = VGb >> 15;
  VGc = VGc >> 15;
  
  VGa = (VGa*Period) >> 16;
  VGb = (VGb*Period) >> 16;
  VGc = (VGc*Period) >> 16;

  PWM_Y[4] = VGa + (Period >> 1); // GU
  PWM_Y[5] = VGb + (Period >> 1); // GV
  PWM_Y[6] = VGc + (Period >> 1); // GW

  PWM_update();

}
```

FOC coming next.

Jeff


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> 16khz 8vpp seems to be working well.
> 
> I also phase advanced my carrier a little. The peak wasn't lined up with my sample pulse.


That's interesting and very helpful. 
I had a "gut feeling" that somewhere around 15kHz would be a good setting.

I wonder if the lower frequencies result in higher current because of the resolver's inductance. This could be the basis of the heat issue.

The microcontroller I plan to use doesn't have a DtoA converter, so I've been working on a sine wave wave generator that uses a 50% duty cycle square wave as its source frequency. This can easily be produced at one of the u-controller's pins and be used for other timing tasks. The square wave is turned into a sine wave with a 2nd order butterworth filter and a 1st order bessel filter. (2 op-amps)

So far I've got a nice clean sine wave from 11kHz to about 25kHz. Phase angle is 179 degrees. I'm trying for about 10V p-p.


----------



## pvatanasov (Jul 17, 2013)

Is this helpful ?

http://www.scribd.com/doc/68765977/A48-Automotive-Microcontrollers-for-HEV-EV-Motor-Control-Systems


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> That's interesting and very helpful.
> I had a "gut feeling" that somewhere around 15kHz would be a good setting.
> 
> I wonder if the lower frequencies result in higher current because of the resolver's inductance. This could be the basis of the heat issue.
> ...


A sine wave generator makes sense. Post some schematics.

I may even consider the whole Resolver to Digital conversion on a single chip solution for the real world version.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

pvatanasov said:


> Is this helpful ?
> 
> http://www.scribd.com/doc/68765977/A48-Automotive-Microcontrollers-for-HEV-EV-Motor-Control-Systems


Yes, a variety of micro controllers is a good thing. 
Use whichever one you feel will work best for you. Let us know why you picked it and how it is working.

Thanks
Jeff


----------



## jddcircuit (Mar 18, 2010)

I ran a little experiment on my 2001 MG1 test motor and my 63V power supply.

With Vq = 1 and Vd = 0
Max Speed 1600 rpm @ .76Amps

With Vq = cos(-22.5 deg) and Vd = sin(-22.5 deg)
Max Speed 2100 rpm @ 1.5Amps

I wanted to get a feel for what some negative Id current would do. It looks like a little flux weakening in this case. 30% increase in speed aint bad.

cool


----------



## bLdC (Jan 21, 2013)

Nice to see it working, Jeff. 

I am about to use one of the CONTROLcards with TMS320F2806x from TI. 
My part is to lay out a PCB for the signal conditioning and stabilised power supply. The whole thing will be small enought so it can be placed in the inverter block. 
TMS320F2806x has 12-Bit ADC with Dual Sample-and-Hold (S/H). 
I think this may do the job.

e*clipse, have you tried with a precision rectifier for the signals from the resolver?


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> Nice to see it working, Jeff.
> 
> I am about to use one of the CONTROLcards with TMS320F2806x from TI.
> My part is to lay out a PCB for the signal conditioning and stabilised power supply. The whole thing will be small enought so it can be placed in the inverter block.
> ...


Very cool
I think it is going to be noisy inside the inverter casing but other controllers do it that way so go for it.

I bet TI has lots of example code for you.

We will be able to share code examples regardless of micro in my opinion.

Are you designing it for both MG1 and MG2 control?

I think I saw on your blog that you had the AD2S1210 Resolver to Digital card also. Is that correct?

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

I did some higher voltage tests.

I connected line voltage to the U and V inputs for MG2. This rectified 165 volts onto my DC bus using the anti-parallel diode of the IGBT. I also put the boost inductor in series with it to smooth the current but that may have not been necessary.

I wanted to see how fast it would spin with 165V.

Keep in mind I am only modulating voltage and only using position feedback in these tests. I want to set a baseline before add more control layer.

With Vq only and Vd=0 I could only get my motor to spin to 2500rpm before it started to vibrate and pull extra current. I was only at 150/255 duty cycle at this point so lots of modulation headroom left.

I added in -22.5 degree shift in Vq to get some negative Vd and it spun up to 4285 rpm at 100% duty cycle. I am going to try more phase shift. There still was some vibration at these higher speeds with this set up.

I may also be in the region where the over modulation that Coulomb mentioned will be applicable. I am not sure about everything that is going on but just wanted to share some of my observations.

These tests may be futile if FOC simply fixes this automatically.

Jeff


----------



## e*clipse (Aug 2, 2009)

bLdC said:


> e*clipse, have you tried with a precision rectifier for the signals from the resolver?


I've tried a few things so far. In some ways, the output from the encoder is like an old-school AM radio. The main problem is the signal is "overmodulated." What does this mean? Think of two signals that are mirror images of each other. One of these signals is the data that we want - it could be someone's voice over a radio or the position of your motor. The carrier frequency is that high frequency (5kHz to 20kHz) signal that exists between these two mirror images signals. Hense, these mirror image signals are "envelopes" of the signal carrier signal. In an old school AM radio, the two mirror image data signals never crossed. However in the resolver's case, the data signals are centered at 0 and cross every 180 degrees. Even if we offset the signal, (I've done this) we need to ignore the mirror image signal.

Why does all this matter? If one "rectifies" the signal, the rectification needs to take into account that 1/2 the signal is negative. At the same time, the rectification needs to ignore the mirror image signal. Otherwise, you end up with an output that is a bunch of only positive 1/2 sine waveforms.

So far the best I've been able to come up with is a rectifier that is triggered by the carrier frequency. 

Another option would be to sample the data for the AtoD conversion at every peak (which could also be every low point) of the the carrier signal. I think that is what Jeff is doing - correct? BTW, are you undersampling (what I just described) or are you oversampling and filtering using the DSP? 

So far, I've been able to amplify and offset the output of the resolver so that the largest P-P amplitude is 5V and the signal centers around 2.5V. I've also been able to trigger a mosfet based on the carrier frequency. It sort of works to use a schmidt trigger designed to turn the mosfet on/off right on the driving signal peaks. Right now it's all a bit rough and not very impressive...

I think it will work better to use the square wave as the trigger because it is a bit less vague when compared to a sine wave.

Jeff - I'll post circuits as soon as I have a solid performing system. Right now I'm trying to amplify the sine wave output of the filters for the resolver. Even if an op-amp is capable of putting out a 10V p-p signal, it chokes when connected to the resolver. I'm considering a high power op-amp that can put out 3 amps.

Have you been able to figure out the inductance of the resolver input? I've measured the resistance of the input: 8.3 Ohms. Both of the resolver's output channels were 14.6 Ohms. These are within 0.2 Ohms on both motors I measured. Based on resistance alone, a 10V p-p signal would result in peak current of over 1A. You mentioned earlier a heat problem with the resolver. Could it have been due to a DC offset? How much current are you supplying?


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> I did some higher voltage tests.
> 
> I connected line voltage to the U and V inputs for MG2. This rectified 165 volts onto my DC bus using the anti-parallel diode of the IGBT. I also put the boost inductor in series with it to smooth the current but that may have not been necessary.
> 
> ...


Wow! This is extremely interesting.  Thanks a bunch! All of this is valuable information/experience. I would never call if futile. 

As far as I understand w/ FOC, something has to determine the amount of phase shift between Vd and Vq. I've seen papers describing self tuning systems, OTOH it may simply be a linear function. Either way, someone needs to write the FOC and this information is very valuable for that.


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> I've tried a few things so far. In some ways, the output from the encoder is like an old-school AM radio. The main problem is the signal is "overmodulated." What does this mean? Think of two signals that are mirror images of each other. One of these signals is the data that we want - it could be someone's voice over a radio or the position of your motor. The carrier frequency is that high frequency (5kHz to 20kHz) signal that exists between these two mirror images signals. Hense, these mirror image signals are "envelopes" of the signal carrier signal. In an old school AM radio, the two mirror image data signals never crossed. However in the resolver's case, the data signals are centered at 0 and cross every 180 degrees. Even if we offset the signal, (I've done this) we need to ignore the mirror image signal.
> 
> Why does all this matter? If one "rectifies" the signal, the rectification needs to take into account that 1/2 the signal is negative. At the same time, the rectification needs to ignore the mirror image signal. Otherwise, you end up with an output that is a bunch of only positive 1/2 sine waveforms.
> 
> ...


I assumed(guessed and crossed my fingers) that the resolver was 100ohm impedance @10kHz. This number jumped out at me when I skimmed the manufacture website of the resolver selections that was posted previously. I don't know which model of resolver I actually have.

My ADC sampling (motor phase current and resolver) is setup on 16kHz intervals. When I was driving the resolver at 8kHz, I was sampling both peaks and valleys because like you said both have the same AM information. Now that I am generating a 16kHz excitation signal I am only sampling the peaks. I think this is called under sampling since I am only taking one sample per excitation cycle at a known phase angle.

I have 10ohm resistors in series with both legs of my excitation signal to help limit my current since I didn't know what I was dealing with. I will try and capture the voltage drop across them to see how much current I am supplying. My plan was to remove them eventually.

If I recall my drive signal is 8vpp 16kHz at the moment.

I am getting dangerously close with my FOC algorithm. I get confused with the integer arithmetic limitations but I will work it out.

Regards
Jeff


----------



## bLdC (Jan 21, 2013)

jddcircuit; said:


> Very cool
> I think it is going to be noisy inside the inverter casing but other controllers do it that way so go for it.


Probably not a poblem for this controlCARD. "The board design is robust and meant for operation in noisy electrical environments." 
It is designed for use in industrial applications, will see. 



> We will be able to share code examples regardless of micro in my opinion.


Surely, the code is in C++ and is object-oriented. 



> Are you designing it for both MG1 and MG2 control?


I think it has enought ADC inputs and may drive two motors if neaded.



> I think I saw on your blog that you had the AD2S1210 Resolver to Digital card also. Is that correct?


Yes, I will use it for the tests but for the complete vatiant I may integrate the RtoD on the same board.
Thanks to eclipse!


----------



## bLdC (Jan 21, 2013)

jddcircuit said:


> I added in -22.5 degree shift in Vq to get some negative Vd and it spun up to 4285 rpm at 100% duty cycle. I am going to try more phase shift. There still was some vibration at these higher speeds with this set up.


Probably from the way you modulate using the 3 control signals.
When I tested the motor, it ran smooth, even with voltages as high as 300V. I use transformer, always when I do experiments and measurements with power from the line. 

It needs a current feedback, the right algorithms and tests under load. 
We may use the fact that there are two motors and use the one for a load, 
at least for testing the smaller.


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> Probably from the way you modulate using the 3 control signals.
> When I tested the motor, it ran smooth, even with voltages as high as 300V. I use transformer, always when I do experiments and measurements with power from the line.
> 
> It needs a current feedback, the right algorithms and tests under load.
> ...


Using a transformer may be a good idea but I don't have one. I am sure my vibration is a result of my modulation. The reason I know is that I have been able to make it run smoother with some software tweaks. Rounding error, sin LUT resolution, resolver tracking filter coeffecients, etc.

I am now up to 4700 rpm at 165V. no load and less vibration now. I was only at 4285 rpm yesterday. Yes, my plan is to use one motor to load the other at some point.

I am now displaying my calculated Id and Iq as I spin the motor. With no load it is going to be hard to regulate current since there isn't much of it to regulate. In this high speed test with a fixed -22.5 degree phase shift it was still showing a positive Id. I want negative Id for flux weakening. At lower speeds it is negative. Perhaps my Resolver tracking has some phase delay that is making incorrect values. Not sure yet.

Getting closer

Jeff


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> I assumed(guessed and crossed my fingers) that the resolver was 100ohm impedance @10kHz. This number jumped out at me when I skimmed the manufacture website of the resolver selections that was posted previously. I don't know which model of resolver I actually have.
> 
> My ADC sampling (motor phase current and resolver) is setup on 16kHz intervals. When I was driving the resolver at 8kHz, I was sampling both peaks and valleys because like you said both have the same AM information. Now that I am generating a 16kHz excitation signal I am only sampling the peaks. I think this is called under sampling since I am only taking one sample per excitation cycle at a known phase angle.
> 
> ...


I did a test of resolver impedance today. It works out that your guess of 100 Ohms was pretty close.  It also seems safe enough to remove the resistors.

Here's the test procedure:
1st, I did all the tests with my signal generator set for 10V P-P sine waves. The tests varied the frequency from 50kHz to 20kHz on 1kHz increments.
For the first set of tests, I measured the voltage across the resolver input terminals through the frequency range. Values for P-P and RMS were recorded. This test was replicated for the two motors I have sitting on my desk, and the results were within 1% comparing one motor to another.

For the second set of tests, I added a 1 Ohm 5% sense resistor in series with the resolver input. This allowed me to calculate the current flowing in the circuit. The DC resistance of the resolver input is 8.5 Ohms.

Tests were run from 5kHz to 20kHz, measuring the voltage drop across the sense resistor. From that data the current flow for each frequency was calculated. The impedance for the system (including the sense resistor) was calculated based on the input voltage (both RMS and P-P) These numbers ended up averaging 3% difference.

The first pic shows the raw and calculated data from the spreadsheet. The first graph shows the voltage drop across the resolver from 5kHz to 20kHz. The last graph shows current through the sense resistor in mA and the impedance of the circuit (including the sense resistor) from 5kHz to 20kHz.

In the end, the resolver shows a very linear behavior (as expected) with impedances ranging from 130 Ohms at 10kHz to 170 Ohms at 15kHz. 

So, if the system were designed to run with 8V P-P at 15kHz, then it would need an amplifier capable of supplying 50mA. This assumes a purely AC signal and there is no DC offset to deal with...


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> I did a test of resolver impedance today. It works out that your guess of 100 Ohms was pretty close.  It also seems safe enough to remove the resistors.
> 
> Here's the test procedure:
> 1st, I did all the tests with my signal generator set for 10V P-P sine waves. The tests varied the frequency from 50kHz to 20kHz on 1kHz increments.
> ...


Thanks for the info.
Not required but I was wondering if you knew the part number and compare your results with the supplier specs.

I will remove my resistors and get a little more power transfer.

Thanks
Jeff


----------



## jddcircuit (Mar 18, 2010)

Phase current measurements:

GIVA, GIVB
GIWA, GIWA

MIVA, MIVB
MIWA, MIWB

These are the signal names coming out of my Prius Inverter.
IIRC the G signals were 1V/20A and the M signals were 1V/40A but will need to be confirmed.

I am having some difficulty measuring low currents. I am also reading a voltage bias at 0 amps which I don't like.

My question is why is there A and B????
At first look they seem to be redundant copies.

I am wondering if the pair has a purpose like for canceling out bias or increasing resolution with averaging??

Any ideas with the A B pair?

Jeff


----------



## jddcircuit (Mar 18, 2010)

Good news: 
up to 4687rpm at 165 volts. Mostly due to improving the resolver tracking function and little more negative Vd.
This motor spins the fastest of all the Toyota motors at the lower voltages. It comes in a model that does not use a boost converter for the bus voltage.

Bad news: 
I blew up my resolver driver. I found out when it was getting hot but not sure why yet. I guess I will have to design it for short circuit protection.
I also blew up my 60V power supply perhaps with some unintentional regen. It is now an unregulated 90V supply.

The resolver driver seems to get hot when I am trying to reset my Arduino and it is in process with making USB connection with my Android Tablet. Perhaps the DAC values are steady state for too long during this transition.


----------



## toddshotrods (Feb 10, 2009)

Can anyone give me the dimensions and approximate weight of the Highlander inverter?

Also, I know it's way too early to know but anyone care to hazard a guess on the size of the DIY controller?


----------



## jddcircuit (Mar 18, 2010)

I am sorry guys. I think the rpm numbers that I was claiming are wrong. I was just reviewing my code and I think I was calculating the speed incorrectly. I will fix it. I might be off by a factor of 2.

I corrected the above posting to reflect the correct rpm values. I hope.

I know it doesn't really matter because each motor is different.

Jeff


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> Good news:
> 
> Bad news:
> I blew up my resolver driver. I found out when it was getting hot but not sure why yet. I guess I will have to design it for short circuit protection.
> ...


I am running into the same problem - overheating the resolver driver circuit. Are you using the driver circuit you posted on page3? If so you may be running into a similar problem I've been seeing. Just to verify, you're using the second op-amp as a buffer/driver for the transistor part of the circuit, with the transistors set up as darlingtons? I'm not very good with individual transistor circuits and tend toward more pre-packaged solutions...  However, I would guess from your circuit that the circuit is putting out a 6V DC output with a +/- 4V AC output - correct?

I was attempting to use the National instruments LM 1875. It's basically an "op-amp on steriods" that can put out something like 3 to 4 amps with a 15V supply. Theoretically it should have no problem putting out the power required by the resolver. However, it would get blazing hot, put out a very distorted signal, then shut down for self preservation. 

My best guess is that 1) The LM 1875 is not the appropriate op-amp for the job. For one, it is more of an audio amplifier than an instrumentation amplifier. 2) The amplifier will work as a single supply amplifier, however, if it is operating with (for example) a 5V DC offset and a 0-15 V supply, the 5V DC offset is the problem because the amp is driving a 5V load through maybe 8.5 Ohms of load ( the DC resistance of the resolver's input) continuously. If there is an AC signal on top of that, then one is looking at the AC load PLUS the DC load I just described.

So, perhaps it isn't so simple to merely use a single supply driver circuit. A double supply ( +/- 5V, for example) could center at zero volts and only see an AC load - the load I documented in my post.

There may be a way around it, by using AC coupling (capacitors in line) on BOTH the input and the output. I had fairly good luck using AC coupling for the input and the spec sheet for the LM1875 showed a LARGE (2200microFarad) capacitor in series with the output for single supply operation...


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> I am running into the same problem - overheating the resolver driver circuit. Are you using the driver circuit you posted on page3? If so you may be running into a similar problem I've been seeing. Just to verify, you're using the second op-amp as a buffer/driver for the transistor part of the circuit, with the transistors set up as darlingtons? I'm not very good with individual transistor circuits and tend toward more pre-packaged solutions...  However, I would guess from your circuit that the circuit is putting out a 6V DC output with a +/- 4V AC output - correct?
> 
> I was attempting to use the National instruments LM 1875. It's basically an "op-amp on steriods" that can put out something like 3 to 4 amps with a 15V supply. Theoretically it should have no problem putting out the power required by the resolver. However, it would get blazing hot, put out a very distorted signal, then shut down for self preservation.
> 
> ...


yes, I am pretty sure I am using the circuit I posted but with some resistor value changes. I think if I can bias the transistors properly that I will be able to use them to limit the current to around 100mA to 200mA in a short circuit condition but not impede the normal operating region.

I will post what I come up with but it may take me a while to find some time.

Jeff


----------



## jddcircuit (Mar 18, 2010)

So I am only at 4687 rpm @ 165 V not 8500. What a bone head.

I also added a debug output signal that goes high when my PWM triggered interrupt routine starts and then low after my Analog conversions and FOC calculations to see how much processor time was being consumed.

My PWM is center aligned 8kHz. I have an interrupt at middle and end points so my interrupt is happening at 16kHz. This gives me 62.5 uSec time budget for FOC.

Using my end of calculation pulse it looks like I am only consuming about half of the 62.5 uSec so lots of headroom still left.

I am not doing the full FOC yet but I am doing all the calculations with the exception of a single PI step. I am doing the forward clark park on my currents to display my Iq and Id. I am doing a reverse clark park on my Vd and Vq signals that I am commanding to spin the motor.

The only thing I am missing is to connect the Iq and Id to the Vd and Vq. I may need to start making moves to get a load on this motor to get some substantial currents for regulating.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

I'm in the process of implementing this technique to see if I can get some more top end speed. I think this might be the over modulation that was referred to in earlier posts.


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> Bad news:
> I blew up my resolver driver. I found out when it was getting hot but not sure why yet. I guess I will have to design it for short circuit protection.
> 
> The resolver driver seems to get hot when I am trying to reset my Arduino and it is in process with making USB connection with my Android Tablet. Perhaps the DAC values are steady state for too long during this transition.


Ohhh boy; I'm sorry Jeff.  I think that was my fault. 

Is there a way the circuit could peg one set of op amps to the 12V rail, while letting current flow to ground in the second circuit at startup? I can see how at least one of the legs could do this. If so, then the 8.5Ohm (resolver) + 20 Ohms protection = 28.5 Ohms total would have kept the current below 1/2A. If the 20 Ohms protection were removed, the circuit could see 1.4A.

Sorry about the recommendation without a real understanding of the problem.  Maybe it was fortunate this was relatively small..


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> Ohhh boy; I'm sorry Jeff.  I think that was my fault.
> 
> Is there a way the circuit could peg one set of op amps to the 12V rail, while letting current flow to ground in the second circuit at startup? I can see how at least one of the legs could do this. If so, then the 8.5Ohm (resolver) + 20 Ohms protection = 28.5 Ohms total would have kept the current below 1/2A. If the 20 Ohms protection were removed, the circuit could see 1.4A.
> 
> Sorry about the recommendation without a real understanding of the problem.  Maybe it was fortunate this was relatively small..


Not your fault. Actually thank you for showing me the inadequacies of my design.

I was able to track down in my startup code where I was setting up my DAC incorrectly. I have been making changes so fast that bugs are bound to happen. I found out that the DAC output self dissipates after 20usec which will help protect my circuit if I didn't override it like I was in my register configuration.

I also increased the base resistor from 1k to 10k. At 10k and assuming the transistor had a gain of 100 it would limit the collector current to 120mA short circuit. The problem is that the gain may be higher and the spec sheet is open on the high end for this parameter so not a predictable design.

My circuit is working well for the moment. I am seeing 9Vpp at 16kHz and no hot moments lately.

IMO a better design approach for me is to think of designing a self limiting current source as opposed to a voltage source. For now I am good to go but I may come back to this driver design later.

Thanks
JDD


----------



## jddcircuit (Mar 18, 2010)

jddcircuit said:


> I'm in the process of implementing this technique to see if I can get some more top end speed. I think this might be the over modulation that was referred to in earlier posts.
> View attachment 16800


The 3rd Harmonic overmodulation works.
I was holding my breath at the high speed when this new code would kick in.

I am now up to a solid 5000rpm @ 165 volts, -30 degree shift in my Vq, and 12% overmodulation.

This overmodulation is definitely the square wave modulation that others were referring to. Here is a comparison of 100% vs 112%

This is not the square wave modulation that others were referring to and it is not even correct 3rd Harmonic representation. Close but not quite. I learned more as I went along.


----------



## jddcircuit (Mar 18, 2010)

Next step is to get the Boost Converter on the DC bus in play and see what 500V bus voltage can do.


----------



## jddcircuit (Mar 18, 2010)

Boost converter is working nicely

I made a mistake in my circuit so when I would reset my micro controller the converter would momentarily short my power supply through its low side IGBT. A little redesign and back in business. Safe resetting now.

I am not going to rush in to higher speeds without a better understanding of the proper modulation at these higher speeds.

However, I need to start thinking about one of the limitations of this inverter which is the boost converter rated at 20kw. I take this to mean 100 battery amps since the Gen II Prius has a 200V battery pack.

A higher voltage pack will provided more power given the same 100 battery amp limit but that might overvoltage the built in 12V DC converter.

A 500 V pack could bypass the boost converter entirely but the 12 DC converter is still a consideration.

I am also considering using the MG1 phases and a couple more inductors to parallel more boost but then I can't use MG1 as part of my drive train.

Another idea is to use a second inverter entirely for additional boost and as part of my battery charger solution. In this dual configuration I can use both MG1 and MG2 and get an onboard charger to boot. This will take some development but sounds doable.

Best Regards,
Jeff


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> The 3rd Harmonic overmodulation works.
> I was holding my breath at the high speed when this new code would kick in.
> 
> I am now up to a solid 5000rpm @ 165 volts, -30 degree shift in my Vq, and 12% overmodulation.
> ...


That is beautiful!  Congratulations!  That's a great way to "overboost" these motors for more performance.

I just got my paws on that TI app note - "Motor Control Compendium" It is definitely worth learning the stuff they have in there. It's giving a much more solid feeling for what's going on.

Regarding the resolver driver: I think I finally understand your circuit. A similar circuit was described in my electronics bible - I have this book entitled the "Art of Electronics" by Horowitz and Hill. BTW - it's an awesome book written by people who have TONs of experience with instrumentation electronics.  On top of that - it's actually fun to read.  

I'm a bit slow here... Please stop me if I have any of this incorrect:
1) It's a push-pull amplifier
2) The transistors on the input side of the circuit are basically acting like diodes because the base is shorted to the collector.
3) These transistors (or diodes) do the job of elliminating crossover distortion.
4) Circuit biasing is done with the two larger resistors ( the 1K resistors in the version you posted ) To be honest, I'm not sure what the smaller resistors' purposes are. Thermal stability?

The "Art of Electronics" details a number of "steps up" that include improvements for thermal stability and a method for stabilizing the bias network. Believe it or not, they aren't much more complicated; the last variant just uses one more npn transistor and a couple of diodes.

I'm going to try putting the output of my sine wave generator into one of these amplifiers. If I have any luck, I'll post the circuit. BTW, would a dual supply output be ok w/ you?

Take care,
E*clipse


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> That is beautiful!  Congratulations!  That's a great way to "overboost" these motors for more performance.
> 
> I just got my paws on that TI app note - "Motor Control Compendium" It is definitely worth learning the stuff they have in there. It's giving a much more solid feeling for what's going on.
> 
> ...


You sound correct on all points with your analysis of the driver circuit I posted. I copied it from someone else's design. I changed the 1k resistor to 10k. I had a purpose for the smaller resistors but I forget now. It is doing the job pretty good. It doesn't have to be that stable really. Any drift will be common mode on both the returns which will not effect my tracking filter. 

I would like to see the different biasing methods.

Dual supply may have some benefits. Don't have an opinion.

The motor control tutorial pictures that I have been posting are snap shots from that TI Motor Control Compendium document. Too much detail and I get confused so I like the overview format. It is everything I need to know about motors and control.

I am having fun changing parameters and spinning the motor. I am manually controlling Vd and Vq while monitoring Id and Iq for now. The motor hauls a$$ and sounds cool. Once I feel that things are working the way I want I will start using Id and Iq error to control the Vd and Vq in software.

Regards
Jeff


----------



## fireblade (Aug 20, 2012)

Attached is a TI document on various switching techniques. Thought it might be helpful


----------



## e*clipse (Aug 2, 2009)

> I would like to see the different biasing methods.


Ok, here are the ones Horowitz & Hill describe for the push-pull amplifier:

The first circuit is basically what you posted; nothing new here except that diodes were used instead of transistors. The diodes are used to reduce (but not necessarily elliminate) crossover distortion.

The second circuit adds the small resistors that you also show in your circuit. They are added for better thermal behavior. Apparently the transistors can go into thermal runaway; this can be reduced with the resistors and/or by thermally connecting the diodes to the transistors (through the heat sink). The bias potentiometer is there to offset the small thermal compensation resistors. Also "for variety" the transistor Q1 is shown in the circuit. The input of this stage is the collector from a previous stage. R1 now serves the dual purpose of biasing Q1 and providing current to the bias diodes.

The third circuit adds a current source and provides adjustability to the diodes. Q5 replaces the resistor R1 of the previous circuit to provide a constant current source. Q4 replaces the two diodes and is adjustable with the voltage divider at its base. the 10uF capacitor provides a bypass so that both output transistors see the same signal.

Anyway, even the third circuit with its constant current source and adjustable crossover is really not too much more difficult to make. In addition to these variants, there are a few more options using darlington transistors or one made with only npn output transistors.

I'm going to attempt a differential amplifier; It has some advantages for our purposes and actually looks simpler..


----------



## jddcircuit (Mar 18, 2010)

fireblade said:


> Attached is a TI document on various switching techniques. Thought it might be helpful


This did help
Thank you
Jeff


----------



## fireblade (Aug 20, 2012)

Is there a reason you chose to develop a resolver/digital decoder instead of using a solution like Analog's http://www.analog.com/static/imported-files/data_sheets/AD2S1210.pdf. Or TI's solution http://www.ti.com/lit/an/sbaa144/sbaa144.pdf


----------



## jddcircuit (Mar 18, 2010)

fireblade said:


> Is there a reason you chose to develop a resolver/digital decoder instead of using a solution like Analog's http://www.analog.com/static/imported-files/data_sheets/AD2S1210.pdf. Or TI's solution http://www.ti.com/lit/an/sbaa144/sbaa144.pdf


No technical reason for me.

I actually have a AD2S1210 EVAL board already and I made provisions on my controller for it to plug into if I need it.

For me it is a hobby and this seemed like an interesting challenge. I can always fall back on the resolver to digital converters if it doesn't workout.

So far it appears to be working but I don't really have a performance reference to compare to. I will probably end up comparing both tracking solutions.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

Coulomb said:


> I think I read somewhere that the Prius switches from PWM modulation to actual direct square waves (in the latter, you don't bother chopping up the signal at a PWM frequency, you just switch hard on and hard off at the electrical frequency of the motor). This switch is based on motor speed; PWM below that speed, square waves above that speed.


Back on the first page of this thread. "Coulomb" made us aware of this change in Modulation that the Prius does. Thank you Coulomb.

I think I am at that point now and I might understand why.

My goal is to spin my test motor up to 10,000 rpm I am currently at 5000 rpm and hitting a ceiling. 8kHz PWM is not going to get me where I want to go (I think). I will explain.

10,000 rpm = 166.6 rps. With this 8 pole motor that means 666.6 eps (electrical commutations per second).

666.6 eps only gives me 15 PWM updates per commutation cycle with 8kHz PWM. 15 updates may not be enough resolution and may have too much quantization noise.

So here is my plan:
I am going to use PWM up to a speed (TBD) with bemf that is at or above my pack voltage. In this experiment my supply it is 80V. If I double this voltage through the boost converter, I can spin up to 5000 rpm with this motor. 

At this TBD high speed, I am going to stop using PWM entirely and start switching on/ off following the basic 6 step Space Vector Modulation sectors. In this mode I will have to maintain phase and frequency alignment with the rotor.

I will then speed up and slow down the motor using the variable DC bus through the boost converter while staying phase locked with the rotor.

This is going to make my brain hurt.

Let me know if this makes any sense.

Jeff


----------



## e*clipse (Aug 2, 2009)

It makes sense to me. I was worrying about this very issue when I was looking at the PWM information about the DS PIC. 

The update rate they describe, even when maxing out the PIC's clock frequency seems to be pretty slow - much slower than 8kHz - for center aligned PWM. The only option I could see was to reduce the resolution.

For example, a microprocessor running at 30MHz would produce a 458Hz 16bit resolution PWM cycle, according to the manual. That would barely work for slow motors.  

However, one could significantly increase the frequency by reducing the resolution. Decreasing the resolution to 12 bits could increase the PWM frequency to 7.3kHz. Reducing it still farther to 10 bits would increase the PWM frequency to 29kHz. Now we're talking! 

Do you have that control with the Arduino?

I mean, it may be a relatively easy thing to dynamically adjust the PWM resolution, according to motor speed. This could be reduced all they way down to 2 bits, with the resulting "on-off" control you're talking about.


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> It makes sense to me. I was worrying about this very issue when I was looking at the PWM information about the DS PIC.
> 
> The update rate they describe, even when maxing out the PIC's clock frequency seems to be pretty slow - much slower than 8kHz - for center aligned PWM. The only option I could see was to reduce the resolution.
> 
> ...


I could increase my frequency but that is not what I want to do. The IGBTs only switch so fast. With the deadtime built in, higher freqs will be a problem for the inverter I think. It won't be able to keep up and switching losses will increase.

I might try 16kHz to see what happens. but I don't think it is optimal.

My Arduino is 84Mz and the PWM counter is 16bits. I have my PWM_Period set to 0x1480 for close to 8kHz center aligned. So 5250 units of duty cycle resolution at 8kHz. Smaller number = higher frequency. 84M = 1Hz.

The problem is when at high speeds, > 5000rpm, I can only get 30 or less pwm duty cycle updates. At 10,000 rpm that would only be 15 updates for the waveform and up to 7% phase error.

I am thinking that in order to reduce phase error I can run the pwm basically at 50% duty cycle at 333Hz for 5000rpm upto 666Hz for 10,000.

I will need to figure out how to vary the frequency of my PWM channels and how to sync up with the motor angle. Years ago I did a BLDC controller that used a nifty phase lock loop with the bemf zero crossing to sync up the commutation.

This is going to be tricky me. I will now have to reconfigure my resolver sampling and some other things that were running off that fixed PWM frequency.

Regards
Jeff


----------



## fireblade (Aug 20, 2012)

Question: Please help me understand the relationship between the stator/rotor mechanical revolution, the electrical revolution and the resolver revolution. 

The Prius/Camry/LS600 MG2 traction motor has 48 stator poles. 

My assumption:
This means that for a 3 phase system it has 16 groups of 3. These 16 groups will complete a mechanical revolution. Each one of these groups will complete an electrical revolution.

Also the resolver counts the mechanical revolution and not the electrical revolution. Therefore there are 16 electrical revolutions to one resolver revolution.

Please clarify, elaborate or contradict my assumption.

Thanks


----------



## jddcircuit (Mar 18, 2010)

fireblade said:


> Question: Please help me understand the relationship between the stator/rotor mechanical revolution, the electrical revolution and the resolver revolution.
> 
> The Prius/Camry/LS600 MG2 traction motor has 48 stator poles.
> 
> ...


All I know is:
The motors have 8 magnetic poles which creates 4 electrical commutation cycles per mechanical revolution.

The resolver is independent of motor interior configuration and this particular one produces 2 full cycles per mechanical revolution.


----------



## jddcircuit (Mar 18, 2010)

My next step is going to be to implement the Space Vector Modulation that is in the TI document that "fireblade" uploaded.

I am using the 3rd Harmonic modulation right now but the SVM may set me up better for FOC and for what I want to do at higher motor speeds.

Let me bounce this idea out there.

I am thinking of a Phase Locked Variable Frequency SVM. I made this name up since I am not sure if there is such a thing.

Here is a graph that shows how the pwm freq will change depending on motor speed.

The reason for this variable frequency scheme is to minimize the phase error at higher speeds when there is fewer and fewer PWM cycles.

I am going to calculate the frequency and phase that will make integer multiples of pwm cycles fall on the boundary of commutation cycles.

It should be very similar to producing the phase aligned square wave that I mentioned before but this may give me some control over wave shape and work at all speeds.


----------



## fireblade (Aug 20, 2012)

Some more reference material on resolver connectors and troubleshooting

priuschat.com/attachments/*0a3f243*-pdf.43003


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> I could increase my frequency but that is not what I want to do. The IGBTs only switch so fast. With the deadtime built in, higher freqs will be a problem for the inverter I think. It won't be able to keep up and switching losses will increase.
> 
> I might try 16kHz to see what happens. but I don't think it is optimal.
> 
> ...


Ok, so it sounds like the Arduino runs much faster than the DSPic (84Mhz vs 30Mhz) Speeding it up would probably not be best. You still have to deal w/ rise fall times of IGBT's, capacitance of gates, etc...

OTOH, how about reducing the PWM resolution? It sounds like you're running 16bit resolution, which takes lots of time. I can't even touch that w/ the Pic. However, If I reduce the PWM resolution to 10 or 12 bits, it should work ok. I'm not sure how that would affect your error issue.

I really like the idea of a phase locked loop to adjust the frequency... It's going to take a bit to wrap my head around that. I just learned about them in the context of the resolver driver. Seemed like overkill for that, but your idea may be the perfect application. 

Fireblade: Thanks for the resolver info - I'm glad to see my resolvers' resistances are in spec.

Also: I did get the differential amplifier working with the resolver. So far the output p-p voltage is low, but it works. Oddly, it works better (higher p-p voltage) at frequencies over 20kHz.  At frequencies below 15kHz, there is an odd step in the rising edge of the output when the voltage is increased above 1V p-p. This may be due to a crossover distortion issue or some misbehavior due to the resolver's inductance.


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> OTOH, how about reducing the PWM resolution? It sounds like you're running 16bit resolution, which takes lots of time. I can't even touch that w/ the Pic. However, If I reduce the PWM resolution to 10 or 12 bits, it should work ok. I'm not sure how that would affect your error issue.


Changing the PWM resolution doesn't work the way you think. In my processor I set a register with a count value. When my PWM clock which is running at 84MHz hits that value it starts over. My count value is set to a number that makes this counting happen 8000 times a second. All of the counting happens in the background without the processor involved.

The only resolution to change would be to change the PWM_clock speed. This is only done to do lower frequencies not higher ones.


----------



## jddcircuit (Mar 18, 2010)

I got the Space Vector Modulation working. The reason I changed to this from the 3rd Harmonic Modulation was that it seems more compatible with FOC.

The tutorial had a modified Clark transform that I used to get me down to the individual phase voltages.

I hope that this thing still works under a load. So far just a lot of no load testing.

Now to start with my phase aligned SVM plans for high speed operation.

Regards
Jeff


----------



## fireblade (Aug 20, 2012)

Another document on driving pmsm and clark transform. My most explainable to date.

http://www.actel.com/documents/SF_FOC_PMSM_HALL_UG.pdf

And anther site that has several docs on clark transforms and motors

http://www.gobookee.net/park-clarke-transformation/


----------



## jddcircuit (Mar 18, 2010)

fireblade said:


> Another document on driving pmsm and clark transform. My most explainable to date.
> 
> http://www.actel.com/documents/SF_FOC_PMSM_HALL_UG.pdf
> 
> ...


Very helpful. I like the way the did the 3rd Harmonic injection. I couldn't figure out how to do this elegantly on my own.



> For the SVPWM (Sine with 3rd harmonics injection) the following procedure is used:
> Voff= [min(Va, Vb, Vc)+max(Va, Vb, Vc)]/2
> Vanew = Va – Voff
> Vbnew = Vb – Voff
> Vcnew = Vc – Voff


This document does explain things well

Thanks
Jeff


----------



## jddcircuit (Mar 18, 2010)

The motor I am using for testing came out of a Prius transmission that was faulty. The transmission tech didn't know the error codes but gave it to me for free so I took it.

I am getting a slight shock from the motor casing and I don't think that is a good thing.

My guess is there is a high voltage leak unless some else has another theory.


----------



## e*clipse (Aug 2, 2009)

Here's a little bit to report. I've been working on an amplifier for the resolver output. The circuit shown below is the SPICE version of the amplifier with a few extra bits thrown in. The transformer is a quick and dirty resolver to simulate the load; not really part of the circuit.

I've built the circuit in hardware as well. There seem to be some significant differences between the simulation and reality. The two biggies are bias and output amplitude. For some reason, I can't get the simulation to bias the output around 0V. The hardware circuit always balances around 0V. Also the output (between Q2 collector and Q4 collector) is much greater in the simulation before distortion than my hardware circuit. The key issue may be that I'm using different NPN transistors.

The amp is AC coupled to the output of an op-amp that forms a 3rd order low pass filter.

The input amplitude should be low, about 0.5V p-p, centered at 1V. In my hardware tests of the circuit I got about 1V to 2V p-p when driving the resolver.

In a nutshell, here's how circuit works:
C2 and R16 form an AC couple for the input. Q1 and Q2 form a darlington transistor for one half of the amplifier with Q3 and Q4 foming the mirror darlington pair. Darlingtons were used to help reduce interaction with the input. Q5 forms a constant current source and helps reduce common-mode noise interaction.
The amp does require a dual power source, which helps reduce the overheating transistor issue when there is no input signal.

In general, the amp works ok. There was no problem with overheating, and when tuned correctly would produce a nice clean sinewave output. However, I would like to get closer to 8V p-p when driving the resolver.

Sine wave generation from a single ended square wave (1 output pin of a microcontroller, 50% duty cycle) works great from 8kHz to over 20kHz.

I'm going to try the "op amp on steroids" solution using an L165 power op amp from ST.


----------



## e*clipse (Aug 2, 2009)

So I got the new resolver circuit going  but not without loosing some hair first.

When I connected the sine wave generator to the new "op-amp on steroids" I got this crazy high frequency noise riding on the output signal. This noise would cause the amplifier to overheat quickly. The situation was made worse by not being able to see exactly what was going on because of frequent noise "glitches" on the oscilloscope.

I had been fighting a noise issue with my oscilloscope, where a 120hZ and a 100kHz signal was coming through from something. After isolating the oscilloscope with an isolation transformer, I was able to get rid of the 100kHz noise that was generated by my lab power supply.
The oscilloscope is powered by one of those cheap wall-wart power supplies, and I figured it probably had a bad output filter. So, I cut the oscilloscope's power supply and added an RC filter. YEA! a stable oscilloscope! Finally - I've been fighting that for years. 

The noise that started all this was also on the interface between the sine wave generator and the main amplifier. If I substituded a sine wave from my signal generator, it worked fine.

It turns out that the different technology op-amps are partially to blame. I'm using a CMOS op-amp to generate the sine wave and a bipolar op-amp to do the main amplification. This causes a feedback loop between the amplifiers partially because I am using a capacitive AC coupler between them. A small resistor can help reduce the problem (something like 100 Ohms for a 1 nF coupling capacitor) But..... It didn't get rid of the noise completely. I tried a bunch of different resistance and capacitance values. 

Wait! Scope probes have capacitance! I took the scope probe off the line between the sine wave generator and the amplifier and LA LA LA - It works fine. 

If I drive the main amp with a +/-5V signal I can get up to 6.5V p-p output at 10kHz. The input signal is drastically attenuated by the AC coupler. I'm not sure what to do about that, other than to tune the output amplifier's amplification to the carrier frequency. The amplifier can put out up to 3A, but that's overkill. If the resolver is directly connected to the output, the impedance at 10kHz-15kHz is enough to keep the current under control. 

The resolver's output signal is also clean, with about 1.5V p-p output. Also, there is no heating issue with the main amplifier or resolver. If the input signal is removed, it defaults to a 0 Vdc output, which elliminates the heating with no input problem.

I'll post the circuits later; I need to eat something....


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> So I got the new resolver circuit going  but not without loosing some hair first.
> 
> When I connected the sine wave generator to the new "op-amp on steroids" I got this crazy high frequency noise riding on the output signal. This noise would cause the amplifier to overheat quickly. The situation was made worse by not being able to see exactly what was going on because of frequent noise "glitches" on the oscilloscope.
> 
> ...



Keep on going.

Thankfully, my circuit has been holding up fine lately without any over heat issues.

However, I am having a very challenging time with my resolver tracking software. I am kind of shooting in the dark for these gain factors in the filter loop which is not very scientific and is a little risky.

This angle information seems to be a main ingredient for controlling these motors. All hell can break loose if the controller is not getting the correct angle information at high speeds. Ask me how I know. I have a new respect for the power of these motors now. I will have to code in some exception handling.

FYI,
I am hoping to have my inverter and a version of my control board mounted in my car this week to make the wheels spin on the jack stands in celebratory fashion.

Regards
Jeff


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> Keep on going.
> 
> Thankfully, my circuit has been holding up fine lately without any over heat issues.
> 
> ...


Cool! It always feels good to get some hardware moving after all of this. 

BTW, did you get to the bottom of the high voltage zap problem? I recently purchased a high-pot tester at an auction. Thought it might be good to use a machine rather than my body to discover these issues.. Too bad you're on the other coast...

Regarding the angle stuff, I'm noticing a lot of difference between the input phase of a square wave and the final output frequency. It's consistant, and can be adjusted for consistantly. However, there's quite a bit of phase difference between, say 10kHz and 15kHz - both in output amplitude and phase.

I'm attempting to do most of this with hardware; perhaps it would be easier to account for it with software. Either way, I find myself doing a lot of "shooting in the dark" to deal with the difference between hardware and the conceptual design.

Good luck with the motor mount stuff!


----------



## e*clipse (Aug 2, 2009)

Here's the circuit from my resolver driver.

It takes a 0V-5V square wave as an input. Duty cycle 50% frequency 10kHz. This should be a no-brainer from any microcontroller.

The frequency can be varied from about 8kHz to over 20kHz, but the output amplitude decreases with increased frequency.

At 10Khz, the output sine wave is a VERY CLEAN 10kHz 6.7V p-p. 

The peak output from the resolver is about 1.5V, again, very clean. This will be amplified, filtered, and rectified in my next circuit.

Here's how it works:

The first two op-amps form a 3rd order low-pass filter with a 3dB point of 10kHz. Really, the second op-amp is just a buffer. These two op-amps are Microchip MCP602's in a common case.

The output goes into a 100 Ohm resistor to keep capacitive loading feedback under control. The next capacitor/resistor pair are used to make an AC couple to the final Op-amp. By AC coupling the final stage, no signal condition will result in a 0Vdc output.

The final op-amp is an ST L165V, which can take up to a +/- 15V power supply, but I am using +/- 5V for simplicity. You may notice there are a lot of decoupling capacitors and small resistors. These are also to help with noise issues. Final output gain could be increased slightly for more than 6.7V p-p output, but there appears to be some clipping if that is done. The gain values will need to be altered if more than +/- 5V is used for power or if the frequency is changed from 10kHz.


----------



## jddcircuit (Mar 18, 2010)

I have switched to a 2001 MG2 (larger traction motor) for testing purposes.







This motor seems to be very different than its MG1 counter part and spinning it up to speed no load was a challenge. The difference may be due to an increase in reluctance torque perhaps but could be a number of different motor parameters that I am not aware of.

So far I have been commanding a known Vq and Vd and just monitoring the resulting rpm and Id and Iq components.

I am getting ready to get my feet wet with some field oriented control. My first experiment will be to control the V vector angle (small adjustments) while still commanding a fixed V magnitude. I will regulate the V angle in an attempt to maintain Id=0. Once I prove that I can do this throughout the speed range, I will venture into flux weakening (Id < 0).

The reason I am not jumping into complete FOC is that the currents are so low with no load on the motor, I don't feel that I have stable enough current sensors to get stable control yet.

Regards
Jeff


----------



## MCGiacobbe (Aug 13, 2013)

I have been wanting to do the same thing as you guys for a while. You did great work so far! 
But I feel like I started reading a book in the middle 

If someone can answer some simple questions for me, I would greatly appreciate it...

- I was a little confused about which Gen you guys are using, Gen 1 or Gen 2? I have the Gen 2 Hybrid Drive System, and M1/M2 assemblies. Does the work that you guys did apply to both generations?

- I want to start out small, and get used to driving the Inverter only. I was going to replace the motors with power resistors, wired up in a Delta configuration. Just so I see what the waveforms are on the W,V, and U outputs. The outputs of my controller will be connected to the MWU, MWV, and MWW inputs of the Inverter. Will the Inverter work with 60V applied to the + - High Voltage Battery inputs?

- I guess I am asking if you guys can post a simple wiring/block diagram that you are using (or at least started out with)?

- For the MWU, MWV, and MWW Inverter inputs, what does the waveforms look like? Simple square wave or PWM?

Sorry for the (hopefully) simple questions... But I am just starting out on this 

Regards,
Mark


----------



## jddcircuit (Mar 18, 2010)

MCGiacobbe said:


> I have been wanting to do the same thing as you guys for a while. You did great work so far!
> But I feel like I started reading a book in the middle
> 
> If someone can answer some simple questions for me, I would greatly appreciate it...
> ...


Very good Mark

I am using both Gen1 and Gen2 motors and inverters. They are the same in a lot of respects.

The inverter will work with 60V bus voltage. You can even boost the voltage using the Gen2 boost converter if you wish to at some time.

MU,MV,MW will turn on the high side IGBT of their respective pair when they are pulled low. They normally float high when you supply the 12V to the inverter power supply. There is also an enable signal that you assert for each motor port (high to enable i think)

You need to supply the pwm signal for MU,MV,MW or just apply any state you like for getting to know how it works turning light bulbs on and off and such.

There are some wiring diagrams for the Gen2 in page one of the thread that helped me out a lot.

edit:
I forgot to mention, that as soon as you enable the port the control signals must change state to be recognized. There is some latching that needs to be cleared.


Best regards
Jeff


----------



## MCGiacobbe (Aug 13, 2013)

Thanks Jeff.

I found this link

http://techno-fandom.org/~hobbit/ca.../04rmsour/2004/04priusf/05/21bpm/terecu40.pdf

I'm sure you guys already saw this. With your wiring diagram, coupled with the above document, and you guys work, should have a good start....

Mark


----------



## jddcircuit (Mar 18, 2010)

MCGiacobbe said:


> Thanks Jeff.
> 
> I found this link
> 
> ...


I have seen that. IIRC he did have one of the control logic explanations reversed but you will figure it out.

Have fun. Keep us updated on your experience with the inverter in this thread.

You mentioned using a delta resistive load and I wanted to mention using 3 light bulbs. At 60volts it should work well.

Jeff


----------



## e*clipse (Aug 2, 2009)

Yea! I got it working! 

This circuit takes the resolver output, amplifies and filters it, then does some "smart" rectification.

The original driving signal is a 50% square wave that is generated by a pin on a microcontroller. This signal is split and buffered with one part going to a trigger circuit, the other part to a sine wave generating circuit. 

The trigger circuit (the new stuff) delays the signal and reduces the duty cycle to ( 5% or 10% ). Both of these are adjustable, but fixed. If the driver frequency is changed from 10kHz, then the delay will need to be adjusted.

The trigger circuit triggers an analog switch that passes the resolver output. This is stored with a peak hold circuit for future analysis with the microcontroller.

The pic below shows it working. The nice sine wave is the resolver output and the more broken up signal is the driver sine wave. The driver sine wave is broken up merely due to 'scope resolution. The key point here is that the sine wave is now a value that should be easy to get an AtoD sample of, whenever the PROGRAM needs it. All the synchronization and filtering has been done in hardware.


----------



## jddcircuit (Mar 18, 2010)

e*clipse said:


> Yea! I got it working!
> 
> This circuit takes the resolver output, amplifies and filters it, then does some "smart" rectification.
> 
> ...


That's good work.
I hope you have better luck than I with your tracking software. Mine is working but not as stable as I would like. I don't trust it.

I think for my next spin of my control PCB I am going to make accommodations a Resolver to Digital IC.

Regards
Jeff


----------



## e*clipse (Aug 2, 2009)

jddcircuit said:


> That's good work.
> I hope you have better luck than I with your tracking software. Mine is working but not as stable as I would like. I don't trust it.
> 
> I think for my next spin of my control PCB I am going to make accommodations a Resolver to Digital IC.
> ...


Thanks. 

I did get the circuit working for both resolver outputs.  They track exactly 90 degrees apart, with a little difference in amplitude most likely due to component tolerance issues. Better quality parts and some adjustment capability should elliminate that. I have found some IC's that do the "sample and hold" task; hopefully they'll perform better than my DIY job with op-amps and analog switches.

So far it works as fast as I can spin the gearbox by hand. I'll probably need to get close to the speeds you're running before I (hopefully don't) see problems. 

The goal of this set-up is to elliminate the need for the tracking software to synchronize with the driver's carrier frequency. It *should* just need to take two simultaneous readings of the resolver's outputs. Their frequency is just running at 2X the rotor frequency, which is relatively slow, but variable.

Essentially I've traded coding issues for hardware issues. We'll see how that works in the long run.


----------



## bLdC (Jan 21, 2013)

Here is what I'm working on. 
It takes time but, I think, I managed to implement almost all the nessesary functions on a single board. For the resolver part I use the integrated variant. 
I want to concentrate on the other part and simplify the code. 

There is an isolated serial interface and USB JTAG simulation. 
Some of the new DSP controllers from TI have a functionality called Real-Time Mode Debug. It allows you to monitor and change application variables in real time while the CPU is executing the code, without interrupting it. That can be really helpfull! 

I implement CANbus interface too. 

What else we need?

http://www.diyelectriccar.com/forums/attachment.php?attachmentid=16900&stc=1&d=1376669314

This may be used as an universal control unit. If the controller is on a separate board, it can be changed without redesigning the other parts of the circuit. 
The controller CARD can be soldered for better mechanical stability.
Ideas?


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> Here is what I'm working on.
> It takes time but, I think, I managed to implement almost all the nessesary functions on a single board. For the resolver part I use the integrated variant.
> I want to concentrate on the other part and simplify the code.
> 
> ...


Very exciting.

It is hard for me to offer any suggestions on what else is needed. I am not sure what input/outputs you have included. Perhaps a list of the IO from the inverter, resolver, throttle, etc. A block diagram of it in system might help.

If you got the basics covered I say build it. If you forget something just get it on the next revision.

Regards
Jeff


----------



## e*clipse (Aug 2, 2009)

Nice work, bLdC! 

As Jeff requested, it would be nice to see a block diagram or schematic. Is it a 4 layer or 2 layer board?

What are the power supply details? Is it running on 3.3V or 5V? Does it need bus voltage or some intermediate control voltage?

I really like the idea of a universal control card. The various 3 phase motors have many similarities that it should be possible to make something with some modular variations.

Here's a wish list just to get the discussion going. Some ideas may be unfeasable, but it just a wish list. 

Hardware modules for I/O options. A good example of this are the zillion DCtoDC converters available. They could be SIPs or perhaps small square parts that could plug in on top of or into the side of the main board.


For example, I'm working on an analog resolver solution that can plug into exactly the same ports that the DSPic uses for a digital quadrature encoder. A plug-in board may allow the three current options as well as future options.
Current sensor options - the design I'm working on uses LEM modules. However, it would be nice to accomodate bus-mounted hall-effect sensors or sense resistors. Again, a plug-in module would allow changes.
Throttle input options. 2 wire, 3 wire potentiometers... commercial hall-effect sensors... I'm working with a hall effect sensor that has a digital output and apposing position/frequency slopes for a safety check. All these could be accomodated with plug-in modules.
Hardware fault sensing. This can easily be done with comparators and logic gates. While most things can be looked at with the microcontroller, what happens if (when... ) there's a software glitch and the controller locks up, crashes or spits out some ridiculous PWM cycle because of an odd unforeseen set of interrupt coincidences? Or perhaps it's just me who doesn't 100% trust my coding abilities? This method could check for under/over bus voltage, overtemp, overcurrent, faults from the IGBT drivers, bad control voltages, etc etc. 

Standard plugs to connect the power driver boards ( This will allow my project share the same control board as Jeff's set-up) These would need control outputs as well as temperature sensors and fault indicators for each phase.

Ok... Here's the grand probably unreasonable request: Have some way to allow different controllers.  I have a fair amount of hardware and experience with Microchip products. While C and Assembly are **kind of*** universal, there are a lot of details that different. OTOH, the controller is the heart of the system; it might just be easier to start over.

Thoughts?


----------



## fireblade (Aug 20, 2012)

Hi All:

Over the past few months I've been racking my brain at understanding the Park and Clark transforms and have finally broke the code. I've realized that many of the documents out there have in one form or another obfuscated these equations. 

Attached is a nice document that helped to illuminate the omissions in these other documents. (http://www.maccon.de/fileadmin/FTPROOT/Field-Oriented-Control.pdf)

If others are having the same issues please let me know. I would be happy to illuminate.

To jddcircuit: You mentioned that you were going to experiment with flux weakening. I could be wrong but I believe that because we are using PMSM motors and not induction motors, flux in the rotor is constant because of the magnets and flux produced by the stator should always be zero in order to maximize efficiency. Since these Prius motors are not totally PMSM and are a hybrid between PMSM and Switched Reluctance motors then my assertion may be incorrect.


----------



## jddcircuit (Mar 18, 2010)

fireblade said:


> Hi All:
> 
> Over the past few months I've been racking my brain at understanding the Park and Clark transforms and have finally broke the code. I've realized that many of the documents out there have in one form or another obfuscated these equations.
> 
> ...


Those Clark Park transforms had me confused for while but I am getting more comfortable with them.

I can get the motor to spin almost twice as fast with Id< 0 than with Id = 0 due to the flux weakening. This may be highly inefficient. The most efficient operation testing is a little ways out.

The prius motor is the Interior Permanent Magnet type which almost never has Id =0 for the most efficient operation. For example at zero speed the max torque per minimum current occurs at a 30 degree phase advance. So in this case the Iq = I*sin(90 + 30) and Id = I*cos(90 + 30) will produce the maximum torque for a given I.

Regards
Jeff


----------



## fireblade (Aug 20, 2012)

jddcircuit said:


> Those Clark Park transforms had me confused for while but I am getting more comfortable with them.
> 
> I can get the motor to spin almost twice as fast with Id< 0 than with Id = 0 due to the flux weakening. This may be highly inefficient. The most efficient operation testing is a little ways out.
> 
> ...


Interesting observations. ORNL performed a locked rotor test and surmised that the peak torque was generated between 120 and 125 depending on the input current (http://info.ornl.gov/sites/publications/Files/Pub1870.pdf) pg. 19. It looks like they make a slight error on their graph. They describe the degrees in wrt. output shaft and not electrical degrees. It looks like your observations are right on the money.

Since you have several electrical rotations per shaft rotation and two resolver rotations per shaft rotation. how did you solve making the resolver output relate the electrical rotation? Did you use a lookup table to provide an angle based on the resolver output? Or did you use a more direct way of determining the electrical angle?


----------



## Coulomb (Apr 22, 2009)

jddcircuit said:


> Those Clark Park transforms had me confused for while but I am getting more comfortable with them.


Same here. The Clarke transform assumes balanced voltages and currents (valid for you guys, not for me at my work), and turns three state variables (voltages or currents) into two. But they are still rotating vectors, so their amplitude varies. The Park transform moves the origin to one rotating with the voltages and currents, and so for steady operation (no acceleration), the D and Q quantities are DC. This is really convenient to work with.



> I can get the motor to spin almost twice as fast with Id< 0 than with Id = 0 due to the flux weakening. This may be highly inefficient.


The back EMF on these motors is such that you would be stuck at quite low (say 2600 RPM) speeds without the flux weakening. (A slightly different thing happens with induction motors, where it is called field weakening.) In both cases, you vary the direct axis current (as opposed to direct current, sigh), and this varies the field.

When you use direct axis current, you are using the stator coils as inductors. As you know, when you place an inductor across an alternating voltage, the current varies in quadrature (i.e. at 90 degrees), so the instantaneous power peaks twice per cycle, but the power peaks are equal and opposite (not quite equal because of losses), so the average power is nearly zero. Power flows into the electromagnets, is stored as magnetic energy, and is returned to the inverter (like regeneration, but happening once per electrical cycle). So the power oscillates from the DC bus capacitor to and from the stator at double the electrical frequency.

This might sound like getting something for free, but it's like the permanent magnets, they provide their field for free as well. Here, you need to oppose their field, but only at a particular part of the mechanical cycle; when the magnets are between poles, it doesn't matter that you are increasing the field.

The extra current has to be provided by the inverter, so that's why a 100 kVA inverter often can't provide 100 kW of power. But if it provides say 80 kW of real power and 100 kVA of apparent power, it might only draw say 89 kW from the battery (if it is 90% efficient). The extra current does cause more I^2R losses, but often the magnitude of the motor current doesn't change a great deal to provide direct axis current; it mostly changes phase. So the extra losses are smallish.

So if using flux weakening causes the motor to become inefficient, it's not because you are pouring in a lot of power continuously to buck the PM field. Overall efficiency is complex, especially when you have the boost converter to consider. For example, in the stock Prius, if you need a little more voltage than the hybrid battery can provide, it's not obvious whether its more efficient to operate a little boost in the boost converter, or a little flux weakening, or some proportion of both.


----------



## jddcircuit (Mar 18, 2010)

Coulomb,
Very good post. I am glad you explained some of that apparent power. It was freaking me out when my phase currents are peaking around 20 amps and my dc supply is only around one amp. It seemed like something for free.
Jeff


----------



## jddcircuit (Mar 18, 2010)

fireblade said:


> Interesting observations. ORNL performed a locked rotor test and surmised that the peak torque was generated between 120 and 125 depending on the input current (http://info.ornl.gov/sites/publications/Files/Pub1870.pdf) pg. 19. It looks like they make a slight error on their graph. They describe the degrees in wrt. output shaft and not electrical degrees. It looks like your observations are right on the money.
> 
> Since you have several electrical rotations per shaft rotation and two resolver rotations per shaft rotation. how did you solve making the resolver output relate the electrical rotation? Did you use a lookup table to provide an angle based on the resolver output? Or did you use a more direct way of determining the electrical angle?


Don't quote me on the most efficient angle. I was also referring to the ORNL report and my very limited experience.

The electrical cycle is twice each resolver cycle so whatever angle my resolver says it is I multiply it by 2 to get the electrical angle.


----------



## bLdC (Jan 21, 2013)

e*clipse said:


> As Jeff requested, it would be nice to see a block diagram or schematic. Is it a 4 layer or 2 layer board?
> 
> What are the power supply details? Is it running on 3.3V or 5V? Does it need bus voltage or some intermediate control voltage?
> 
> I really like the idea of a universal control card. The various 3 phase motors have many similarities that it should be possible to make something with some modular variations.


The controller CARD is 4 layer but I do not need to go 4 layers on the main board. I managet to place the signal lines almost entirely on the upper layer, so the ground layer is almost intact. I expect good enought noise immunity. 

The controller is 3.3V but there is a regulator on board, so it takes 5V supply. 
I use simple LDO regulators(not the simplest) for the main board, one for the digital part and another of the analogue. For the negative, a voltage invertor is used. I think there is no need for a perfectly stable -12V if the monitored signals are not going that far negative. 

I will monitor the +12V after the regulator. If power down happens, this voltage will sink first. 
http://www.diyelectriccar.com/forums/attachment.php?attachmentid=16909&stc=1&d=1376848581

For stable operation with lower than 12V voltages it needs small DC/DC convertor. 

After some little changes: 

-- on the inverter side- 8PWM outputs, 4 more outputs, 4 filtered ADC inputs for the current feedback, 3 unipolar ADC inputs
The big IC is a low side open collector driver with some diagnostinc functions and protections. 
The diagnostic functions allow me to use some of these outputs as inputs for the fault signals coming from the inverter. 

-- on the interface side is the resolver interface, CANbus and two bipolar analog inputs. 










I preffer to use CANbus for the trottle signal, regen parameters and the feedback.


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> The controller CARD is 4 layer but I do not need to go 4 layers on the main board. I managet to place the signal lines almost entirely on the upper layer, so the ground layer is almost intact. I expect good enought noise immunity.
> 
> The controller is 3.3V but there is a regulator on board, so it takes 5V supply.
> I use simple LDO regulators(not the simplest) for the main board, one for the digital part and another of the analogue. For the negative, a voltage invertor is used. I think there is no need for a perfectly stable -12V if the monitored signals are not going that far negative.
> ...


That all sounds really good to me.

I think I need to do a better job on my board as far as noise immunity goes. I put everything on a two layer board when it should have been four.

May I ask what type of filtering are you planing for the motor current sensors?

Regards
Jeff


----------



## bLdC (Jan 21, 2013)

Thanks!

I was planing to use 2-pole Sallen-Key filter, followed by a stage for scalling and shifting the signal. 
The problem is, it may be hard to condition the signal and maintain high enough resolution. It needs precision op amps, and takes space. The financial reason for choosing op-amp stages, against ADC, appears to be nonexistent. 
I am leaving just a part of this circuitry for testing, and using ADC with +-10V input capability for the signals from current sensors. 
The other analogue signals from the inverter, for the temperatures and bus voltages are in the range of about 2V to 5V. 

The filtering will be mostly in the software. Good idea is to just avoid measuring signals in the moments of power-transistors switching. That noise is really hard to filter.


----------



## Coulomb (Apr 22, 2009)

bLdC said:


> Good idea is to just avoid measuring signals in the moments of power-transistors switching. That noise is really hard to filter.


Good luck with that. I tried to do that for some time, and gave up in the end: three phases, varying modulation ratio and so timing; it seems that there is nowhere to hide from the switching noise.

However, I haven't made a real effort yet, and may soon be forced to. This is not on a motor controller, but a Uni project with multiple inverters and multiple 3-phase buses. Guess who writes the firmware for all those inverters


----------



## jk1981 (Nov 12, 2010)

Coulomb said:


> Good luck with that. I tried to do that for some time, and gave up in the end: three phases, varying modulation ratio and so timing; it seems that there is nowhere to hide from the switching noise.


There would be if you limited maximum duty to say 95%. Assuming of course you have fast multi-channel ADC/SH, good layout/snubbers and relatively modest PWM frequency.

jk


----------



## MCGiacobbe (Aug 13, 2013)

A little off topic, but you guys seem to know what you are doing....

Can anyone post a picture of your 3 phase motor control signals to the inverter? Or share a link to some info? Or another thread??

I want to use the MUU, MVU, and MWU inputs of the inverter to drive MG2.

At this point I'm not worried about position sensing or anything, just trying to get the motor to spin.

As I understand it: Let's take MUU by itself. If the signal is high on MUU, then the upper MOSFET is on. If it's low, the lower MOSFET is on (upper and lower MOSFET being in the half bridge for that channel).

Is my understanding of MUU, MVU, and MWU inputs correct?

Is there a way to turn off a 1/2 bridge (i.e. MUU)? All the app notes and datasheets I've read on BLDC and PMSM design show 2 lines to each of the 1/2 bridges (6 total inputs). That way one of the 1/2 bridges can be turned off.

Right now, I can't seem to figure out the waveforms for the inputs to the inverter with only 3 inputs.

Thanks
(confused) Mark


----------



## jddcircuit (Mar 18, 2010)

MCGiacobbe said:


> A little off topic, but you guys seem to know what you are doing....
> 
> Can anyone post a picture of your 3 phase motor control signals to the inverter? Or share a link to some info? Or another thread??
> 
> ...


MU,MV,MW pulled low will turn on the high side switch. (i think you had it reversed)

MSDN must be high (12V I think) for all the half bridges to be enabled.

There is no way to turn off a single half bridge so you cannot use a modulation that requires a floating phase like some BLDC motors.

Sinusoidal and SpaceVector modulation schemes do not use a floating phase.

It was not easy, if I recall, to get it to spin without rotor angle feedback. When I tried it I could not maintain lock between my rotating stator field and the rotor.

I hope that helps
Good Luck
Jeff


----------



## DublinDilbert (Aug 22, 2013)

New member from ireland here, just took delivery of a transaxel and inverter last week. Some great info in the thread here, thanks to everyone for their contribution. I hope in time I should also be able to contribute here too.

I'm hoping to run the motor using an stm32f4 CPU. ST have an excellent configuration tool and pmsm libraries, which allows you to generate all the required header files, then connect via a serial link. 

A few questions, has anyone found the amp/tyco part number for the 32 pin connector to mate with the inverter? I have the Toyota p/n 90980–12153 so might just get one from there.

Is there a list with good pin descriptions for the 32pin connector, showing which outputs the current sensors are on etc...

Has anyone tried powering up the main dc to dc converter? Does it just take an on/off signal?


----------



## Siwastaja (Aug 1, 2012)

MCGiacobbe said:


> A little off topic, but you guys seem to know what you are doing....
> 
> Can anyone post a picture of your 3 phase motor control signals to the inverter? Or share a link to some info? Or another thread??


Hi,

I think these will answer your question:





























So you create 0 volts by switching the high switch and low switch 50%-50%. You create -Vbus by opening the low switch for 100% of the cycle, and +Vbus by opening the high switch for 100% of the cycle. The second image shows [almost] the complete range as well as the high and low side control signals (active high).

But you must need to add some deadtime so that the switch that is going off is disabled a bit before the opening switch is opened. The third image shows that.

The first two images show the sine waves inverted but that doesn't matter.


----------



## jddcircuit (Mar 18, 2010)

DublinDilbert said:


> New member from ireland here, just took delivery of a transaxel and inverter last week. Some great info in the thread here, thanks to everyone for their contribution. I hope in time I should also be able to contribute here too.
> 
> I'm hoping to run the motor using an stm32f4 CPU. ST have an excellent configuration tool and pmsm libraries, which allows you to generate all the required header files, then connect via a serial link.
> 
> ...


Excellent

I don't know of a good description of the pinout but in the beginning of the thread there are some wiring diagrams that helped me quite a bit. You can at least pick out the pin names that you have questions with and see if someone has any experience with it.

I did power up the 12V dc to dc but it was quite a long time ago. I will be revisiting it soon as I build my car. I remember there being a sequence to the start up. For example the order in which the high voltage bus is applied and the ignition and start signals come up. I didn't get the full 12V I assume because I didn't have enough on the high voltage side at the time.

Regards
Jeff


----------



## jddcircuit (Mar 18, 2010)

Here is an observation that I made that doesn't make sense to me and perhaps someone can explain it to me.

If I short the phases together the motor is very hard to turn by hand which is expected. All high or all low steady state locks the rotor pretty hard.

If I apply 50% duty cycle to all phases the motor is easy to turn by hand. I did not expect this. I would expect that since all phase were the same as each other all the time then they would act as if they were all the same steady state.

I am a little confused. Not that this is a pressing issue but sometimes being enlightened in one area explains so many other things.

Thanks
Jeff


----------



## bLdC (Jan 21, 2013)

Here is proposal for a schematic that automates shut down function of the inverter. I'm using a D-type flip-flop to pull down one of the output lines, that will be connected to the enable pin of the inverter, in foult event. 
The driver IC I use has a diagnostic function that can detect lost connection, short to ground, overcurrent and overtemp. In any of this conditiones it trows a foult signal that is send to the DSP and the flip-flop. 

The flip-flop circuit will unlock the enable line(here named 00PWM-1A) with the next rising edge of the signal coming from the controller. At least that's the plan, it's not tested yet.









I made some other changes in the board, like a bigger connector on the inverter side 37pin instead of 25 to have more pins for the supply, ground and signals. The external ADC is 500kSPS(dual in IC) +-10V inputs and I have implemented 2'nd order lowpass filter before it. The ADC in the DSP is 3.46MSPS. 

Hopefully I will have the PCB ready in the end of this week or the beginning of the next, so I can start with the programming part.


----------



## DublinDilbert (Aug 22, 2013)

jddcircuit said:


> Excellent
> 
> I don't know of a good description of the pinout but in the beginning of the thread there are some wiring diagrams that helped me quite a bit. You can at least pick out the pin names that you have questions with and see if someone has any experience with it.
> 
> ...



I've started putting together a spreadsheet with all of the info I could find. If anyone has additional info let me know and I'll update:-

https://dl.dropboxusercontent.com/u/1326656/HV_Inverter_connector_pinout.xlsx

When I have a bit more time I could probably throw it up on google docs and let people work away on it. 

I've found some information on the measurement of the DC bus voltage and the scaling so have added a tab for that.


----------



## jddcircuit (Mar 18, 2010)

DublinDilbert said:


> I've started putting together a spreadsheet with all of the info I could find. If anyone has additional info let me know and I'll update:-
> 
> https://dl.dropboxusercontent.com/u/1326656/HV_Inverter_connector_pinout.xlsx
> 
> ...


Dilbert,
I have some input for your spread sheet.
MIVA, MIVB (1V approx 40 Amps)
MIWA, MIWB
GIVA, GIVB (1V approx 20 Amps)
GIWA, GIWB
The A and B seem to be the same signal and the V and W represent the current flowing in the V and W phase. Positive voltage towards the motor. Negative towards the inverter. I am not sure what the purpose for the AB pairs is yet.
GIMV, I think this is a typo and should be GINV for Inverter Ground Reference. This seems to be the analog reference for the current and bus voltage (VH) signals. There is a lot of switching noise on the MIVA and MIWA signals but the noise is common to GIMV so a differential filter or measurement seems appropriate here.

GCNV seems to be the analog reference for the boost converter so I use that for my VL measurement reference.

Jeff


----------



## DublinDilbert (Aug 22, 2013)

jddcircuit said:


> Dilbert,
> I have some input for your spread sheet.
> MIVA, MIVB (1V approx 40 Amps)
> MIWA, MIWB
> ...



Thanks Jeff, its updated now:- https://dl.dropboxusercontent.com/u/1326656/HV_Inverter_connector_pinout.xlsx

I've also found some good info on the DC to DC converter, I've pasted a diagram into that worksheet, it shows the main connections needed.


----------



## bLdC (Jan 21, 2013)

The PCB came in wednesday, but I was not in town, so I received it yesterday. 
Started to populate, but some of the elements will arrive tomorrow. 

I have to reinstall OS and install all the software anyway. 

The connectors are not soldered yet. The green board above is the controlCARD. 










I thought I don't need a 100pin controller but, in the end, used nearly all the available embeded serial interfaces for the implementation.


----------



## jddcircuit (Mar 18, 2010)

bLdC said:


> The PCB came in wednesday, but I was not in town, so I received it yesterday.
> Started to populate, but some of the elements will arrive tomorrow.
> 
> I have to reinstall OS and install all the software anyway.
> ...


BLDC,
How is your controller build going?
Regards
jeff


----------



## Lebowski_72 (Sep 24, 2013)

Hi,

Just a quick intro, I'm a DIY controller builder but I'm mostly active on Endless-Sphere... Someone there wants to build a controller based on my controller IC (running my own version of sensorless FOC) and a Honda Insight module. From what I understand the Honda module has the IGBT's and drivers, and the current sensors in the motor wires. Does anyone here maybe have a schematic or pug-pinout for such a module ?

Am I correct in thinking that the plug will allow to connect 5V switching signals to turn the IGBT's on/off ? What kind of PWM frequency and deadtime do these car modules use ? 

thanks !


----------



## david85 (Nov 12, 2007)

subscribing.....


----------



## bLdC (Jan 21, 2013)

jddcircuit said:


> BLDC,
> How is your controller build going?
> Regards
> jeff


I'm traying to make everithing work as good as it looks.  

Well... I had to make some small changes to the supply and the debug circuit to work properly. 
But now, I can program and test the features of the controller. 









It is a new platform for me, but there is a lot of projects and literature to learn from.

Regards


----------



## Nathan219 (May 18, 2010)

Very interesting, keep up the good work!


----------



## sumfoo1 (Mar 16, 2010)

Ok so i'm reading through this and i understand most of it. I'm not sure if i trust myself to create my own motor controller for ac (i did a dc one years ago with a mosphet bank and a huge heat sink.) Has anyone tried plugging one of these into the Reinhardt controller and seeing if it's parameters are variable enough to be able to run it? 

I'd love to use the highlander MG2 in a high performance motorcycle project but the truth of the matter is i'm just trying to save money over the equivalent REMY unit which is something between 6k and 10k new.


----------



## sumfoo1 (Mar 16, 2010)

What do you have to do to setup a regeneration setup?


----------



## Ryan800 (Apr 15, 2010)

sumfoo,

I've been trying to do just that for a while. I started with a Toyota Highlander MGR (is that what you meant? MG2 would require a new housing, though for a motorcycle any hybrid motor would). I used a Tritium controller with 410V of lithium and power was severely limited. I would say that because the motor is would for 650 volts, it's nearly unusable for DIY.

Tuning is also an issue. The easiest route would be to call Rinehart and ask what they would charge to set their controller up to the motor of your choice. It's probably expensive, but I've had trouble getting mine to run smoothly on my own. Control becomes jerky above ~40mph/4000 rpm and eventually the controller shuts down.

I now have a Ford Fusion Hybrid motor, which operates at 300V in stock form, and I actually disassembled the motor enough to allow me to make accurate measurements of the parameters needed to program the controller (which I didn't do before). I haven't put the motor back in the car to test the results, and I've been going very slow on this project so it could be a while yet before I do. I'm optimistic that it will perform better than before but I think it's a toss up as to whether or not the car will actually be drivable. Plan B is to put in an induction motor.

In short, there isn't yet a proven off-the-shelf method to drive hybrid motors, and likely won't be until someone pays a company like Rinehart or Tritium to set up their controller specifically for one.


----------



## sumfoo1 (Mar 16, 2010)

Yeah i've been looking at that motor (fusion/escape) too, as the transaxle can be had for peanuts in comparison to the remy motors. 

http://www.sae.org/events/bce/presentations/2007williamsen3.pdf

motor generator 2 out of that transmission would be the right dimensions and make AMAZING power for a motorcycle. I'm pretty good with metal fab so i don't think making a case would be terribly difficult at the very worst i could just cut the transmisson before and after the motor and weld on a flange for end plates trying to keep any water jacket etc. in place as they all say they are watercooled motors in the specifications. (although without actually having my hands on one I've never seen any evidence of water cooling in the transmissions).

i'd like to figure out how to get one of the 100kw+ hybrid motors to be reliably controlled by.... anything really.... if i have to learn motor controls and design my own i don't think that's out of the realm of possibility. I used an AC single phase fan motor in my senior design project and made my own VFD for it... i'm sure three phase permanent magnet is significantly more difficult but not completely outside the realm of understanding.


----------



## marcexec (Feb 11, 2009)

Lebowski_72 said:


> Hi,
> 
> Just a quick intro, I'm a DIY controller builder but I'm mostly active on Endless-Sphere... Someone there wants to build a controller based on my controller IC (running my own version of sensorless FOC) and a Honda Insight module. From what I understand the Honda module has the IGBT's and drivers, and the current sensors in the motor wires. Does anyone here maybe have a schematic or pug-pinout for such a module ?
> 
> ...


Guys, have a look at Lebowski's controller: http://endless-sphere.com/forums/viewtopic.php?f=30&t=57877
He's done a load of work already, and IMHO it would be awesome to make his controller "brain" work with the Toyota inverters. As I understand, they are "dumb" and are controlled by the ECU in the hybrids - as you are now replicating with your own controllers.
On a whim, I started http://endless-sphere.com/w/index.php/Prius, linking this thread and others.


----------



## jddcircuit (Mar 18, 2010)

marcexec said:


> Guys, have a look at Lebowski's controller: http://endless-sphere.com/forums/viewtopic.php?f=30&t=57877
> He's done a load of work already, and IMHO it would be awesome to make his controller "brain" work with the Toyota inverters. As I understand, they are "dumb" and are controlled by the ECU in the hybrids - as you are now replicating with your own controllers.
> On a whim, I started http://endless-sphere.com/w/index.php/Prius, linking this thread and others.


I agree.

The wiring diagram between the Toyota inverter and ECU are in the beginning of this thread. The inverter gives you access to the IGBT control states and provides the necessary phase current sensor outputs for you to apply your own motor control interface.

I think that Lebowski's approach is sensorless so it would not use the Toyota rotor angle position sensor. FOC (IdIq control) is very straight forward when you don't have the overhead of estimating the rotor/field angle like sensorless methods require.

The fact that Toyota did not use sensorless control says something to me. I haven't put the motor under a full load yet but it is spinning. It makes sense to me to optimize with sensored FOC first and then compare the performance to a sensorless control at some point if desired.

I also think that at high rpms Toyota switches from a PWM sinusoidal control to a basic 6 step BLDC type switching. I am not sure why yet but I have some theories. Having a sensored control approach will allow me to investigate this further.


----------



## DublinDilbert (Aug 22, 2013)

Yea on the resolver I've taken the approach if it's good enough for Toyota it's good enough for me. Most sensorless approaches need to align the rotor then go from there. 

I'm using an analogue devices dev kit to convert the resolver to a digital signal then reading this into the main CPU. 

I've an stm32 arm based solution and a Philips lcp1549 arm prototype almost finished. The Philips one is nice cause they give you all the foc source code, from a learning point if view it's great and allows tweeks to be made quickly...


----------



## wickedal (Jun 21, 2014)

Great discussion on these motors. So my question is "Do I hold onto my transaxle and wait for a good controller solution, or do I sell the motor/transaxle and look for another motor?

I am not a software geek, I am looking for parts I can put together that play well with each other to build my vehicles. I picked up a new hybrid transaxle not realizing how unique of a motor it was with respect to the controller.

I am looking to build a high output electric ATV/UTV from 50-100hp and the Toyota transaxle looked so promising.


----------



## kulibin (Apr 15, 2014)

this is a circuit of prius IPM module. may be you don`t see there yet.


----------



## tylerwatts (Feb 9, 2012)

Hi folks. How complicated would it be to take a Toyota EV controller and strip the control circuitry to use the power stage components with a DIY control circuit? There are loads of these about for cheap, they are great quality and rated well and have an enclosure and cooling built in already! Is this a reasonable idea? Thanks


----------



## jddcircuit (Mar 18, 2010)

kulibin said:


> this is a circuit of prius IPM module. may be you don`t see there yet.


very very helpful
Thank you

Jeff


----------



## marcexec (Feb 11, 2009)

Just stumbled across this Lexus drivetrain BMW DIY project:
https://hackaday.io/project/4649/logs

Anyone from here?


----------



## Coulomb (Apr 22, 2009)

marcexec said:


> Anyone from here?


Yes, bigmouse: 
*BMW 330ci conversion*


----------



## nafire185 (Jul 10, 2015)

Does anyone have a pinout for a 05 4wd MG ecu for the highlander? Trying to hack the pins so i can run the generator motor.


----------



## nafire185 (Jul 10, 2015)

Im interested in buying a resolver decoder from someone on here who has already done the work, its got to work with the tamagawa resolver on the motor, better if it has the microcontroller interface so i can control the phases and control the msdn and gsdn. Im building an electric gsxr, and the controller portion has been holding me back. The motor is ready to be mounted. Would be great if i can just plug in one of the electronic hall sensor throttles as well.


----------



## jackbauer (Jan 12, 2008)

At the risk of dragging up a long dead thread I'm wondering did anything ever come of this design work?


----------

