Now the feasibility studies are done, the goal of the synchronous torque controller can be pursued.
So the stepper code has been improved with a pre-emptive stepper algorithm.
This means we can include other pre-emptive code or drop this algorithm into the other code easily.
The motor control works fine at low speeds when using an external supply control (like a variable voltage switch mode PSU),
but when using the synchronous torque algorithm to start and at low RPMs the behaviour is chaotic.
So the solution may be to include a low frequency PWM algorithm (say 50Hz) to control the power delivered during the synchronous "mark".
This way the high power "kicks" the motor gets at low speeds are controlled by reducing the power of the pulses.
It would work, but it is moving away from the pure synchronous torque strategy which is key to reducing loss in the controller.
What needs to be achieved is the control of the motor should not be based on the sensors but an internal model of the rotation using the sensors to adjust the model.
This is sort of what the dq0 (clarke and park) model is doing, but dq0 requires ratiometric sensors, ADCs and complex maths algorithms, all of which cause delays in the processing.
The synchronous torque model is very fast partly because it uses digital sense information which requires no conversion.
This means the mechanics are a bit more complicated and the electronics also takes a hit too,
but the extra time and cost of this is offset by needing a faster CPU and ADCs to handle the analogue signals and authoring and debugging complex code.
There's also the issue of noise which means the ratiometric hall sensors cost quite alot more than digital ones and there is a compromise in accuracy.
All this is moving away from the strategy of using the simplest system as faster CPU, more complex code,
high speed ADCs and high accuracy ratiometric sensors are all effectively part of a hack to work around new problems introduced by going down this route.
This brings new problems which end up being a compromise, when a simple, accurate, well tested solution is already available.
The need for PWM proportional control will help in starting the motor from stationary and means the full power of the battery
will not be fed into the motor inductors to get the motor (and the car) moving, which was an issue.
This is where we have a PWM tick timer which is running at 50kHz (period 20uS).
The PWM is timed by counting the number of 20uS ticks for each state (mark and space).
The sensor algorithm resets the state to space when the shaft moves to the next position.
This works better as there is no setting up and resetting of timer interrupts, which causes instability.
Also this means we can have a zero mark or space without confusing the CPU with a zero time interrupt.
Finally it means we can easily meter the amount of time the controller actually spends in a PWM state.
Here we have the core algorithms with the new sampled PWM algorithms:
From this and other animations on this page the connectivity was worked out.
Also the fact that this is a DELTA motor, not a WYE as was expected.
+ + + 11
UUVVWW 01 23 45 67 89 01
- - - V W U V W U V
STEP1 010010 Ns Ns sN
STEP2 000110 Ns sN sN
STEP3 100100 Ns sN Ns
STEP4 100001 sN sN Ns
STEP5 001001 sN Ns Ns
STEP6 011000 sN Ns sN
Ns sN sN
Ns sN Ns
sN sN Ns
sN Ns Ns
sN Ns sN
Ns Ns sN
Class-D 3-Phase Controller Design
Having just read up about Class-D audio amplifiers, it appears there is the opportunity to simplify the design.
This is a radical deviation in the design philosophy and requires modification of all parts of the controller.
The Class-D amplifier is a H-bridge, or 2 x 180 degrees phases output.
This will be modified to a 3 x 120 degrees phases.
In the software, this means using a 3-output algorithm to drive to either rail instead of 6-output which control the rail switching independently.
There is a way to have Space Vector Modulation without the heavy maths using a software flywheel model.
This involves having an open loop SVM with sensor updates for the amplitude.
The open loop model rotates the stator field vector and thus the AC phase without sensor input.
The sensors interrupt and provide the position information as above.
The difference between the open loop model and the real position is calculated and this is used to adjust the scalar amplitude of the vector.
This scalar amplitude can be negative as the torque angle is 90 degrees, so less than 90 is positive and greater is negative.
This is better than DQ0 (clarke and park) since it does not rely on sensors to provide the vector.
The motor can continue to rotate even if there are no sensors.
Also there is an inherent delay in the calculation of DQ0 so there is an inaccuracy in that.
This is normally adjusted by calculating with a phase advance, but this is really just a guess as there is no way to predict the load.
Software flywheel model also can detect if there is a problem which DQ0 does not do naturally.
If the motor suddenly appears to do something impossible or dangerous (like suddenly reverse)
the comparison with the internal model will show this has happened and the controller can do something about it.
Arduino Timers and PWM
Arduino PWMs are run from the timers so they are independent of software.
There are 3 timers each operate 2 PWM outputs giving 6 PWM outputs.
All 3 timers have different ways of configuring, but the common mode is 8-bit and they share a set of prescaler divisors.
The trick is to set up the PWMs in the same mode and with the same prescaler,
then reset all the timers and you will have all PWMs operating the same (including being in phase).
The ATmega328 CPU is an 8-bit integer CPU, so for the fastest performance the algorithms need to use this.
The value 252 has common integer factors of both 3 (phases) and 4 (quadrants)
If the amplitude is -127 to +127 for full scale and the angles are calculated as 252 being a full turn this will work.
In pre-calculating a SINE table (which means fast trigonometry) only the first quadrant is needed.
all other quadrants can be calculated from this as with normal SINE,
however the values for a quarter/half/three-quarters/full turn are actually on quadrant boundaries.
This means to pre-calculate the first quadrant, values for 0 AND a quarter turn need to be included.
252 is a full turn, 252 / 4 = 63 so this means we need 64 values to include both the first (0) and last (63) values.
The SINE table above is calculated for the first quadrant, but we need to calculate 0 to 63 inclusive (63 = exactly a quarter turn, so a quadrant boundary). AllQuadrantAmplitude then will work correctly and produce accurate SINE values.
Also the angles for phase V and W need to be in the range 0 <= A < 252, which means in AngleToAmplitudes we need to allow for results which would be >252.
The waveforms for all 3-phases were output from the software to check the calculations:
There is an offset due to integerisation so the standard maths rounding needs to be applied:
output = integer (input + 0.5)
0.5 is a floating point so this is done by bitshifting again:
(((UAmplitude * PWMAmplitude) >> 6) + 1) >> 1
Adding 1 before the last shift is the same as adding 0.5 to the result.
Also the scaling is actually 0 < factor < 127 -not 128
The PWM scales down gradually from the full scale by up to 1 count at 127 (max)
This is an average of 0.5, so adding 0.5 to the scale factor cures this:
The original calculated 6uS was for the AC synthesis calculations only.
There is other code involved in the ShaftMove loop which accounts for the other 5.6uS.
This was expected.
So as you can see we are looking at 11.6uS update speeds which equates to 5,135 RPM.
This is to maintain full accuracy of the 3-phase AC waveform.
For our 6,500 RPM giving 100 MPH, 5,135 RPM equates to 79 MPH.
1.29 angle ticks is 0.51% of a full field turn.
Or there are 195 updates per field turn.
On our Prius motor with 4:1 field to shaft this is 781 updates per rev (at full speed of 6,500 RPM)
So while it's not a perfect 3-phase AC waveform at full speed, it's certainly good enough.
Limitation of PWM in AC synthesis
Since we are using PWM and not an actual analogue output for AC synthesis this causes issues of it's own.
The target PWM frequency is around 15kHz (we are actually testing at 32kHz) which is ~60uS period.
This means we can update the amplitude in 11.6uS but the PWM period is 60uS.
If the field rotation update period is 60uS we would have 252 * 60 = 15120 ~ 15mS rotation period.
1 / 0.01512 = 66.133 rotations/sec
...this is field rotations so 66 / 4 = 16.5 shaft rotations/sec.
16.5 * 60 = 990, so about 1,000 rpm.
If the designed speed is 100mph for 6,500rpm this means the vehicle will be going at 15 mph.
So to maintain precise AC synthesis the vehicle is limited to around 15mph,
which is much less than the limit due to update speed shown from testing above.
60uS / 2300uS (2.3mS per rotation) = 0.0261 rotations per PWM tick.
This means in the time it takes for a PWM output to go high then low the field has rotated over 9 degrees.
Or, put another way, this is 1/0.0261 = 38.3 PWM updates per rotation.
At these speeds the AC synthesis waveform would be inaccurate which leads to inefficiencies.
Compare that with Synchronous Torque where there is 1 update per sensor pass so:
6 sensors x 4 field rotations = 24 updates per rotation (and this is a fixed amount at all speeds).
The difference with Synchronous Torque is the updates are carefully timed to provide the most efficient torque pulse.
Whereas, with AC synthesis the updates are random in relation to the field.
The trade off between AC synthesis accuracy and PWM frequency would be true for all controllers, not just this one.
Higher frequencies would allow more accurate AC synthesis but at the cost of loss in the IGBTs.
Combined Hybrid Controller
I'm sure there are some clever phase compensating SVM algorithms for high speed AC synthesis,
but our controller cuts to the chase by using the benefits of both AC synthesis and BLDC.
This would be the first controller of it's kind to do this.
BLDC is efficient at high shaft speed, but can be unstable at very low speed
due to the extremely short pulses needed to maintain momentum.
AC synthesis is smooth at low speed, but is less efficient at high speed due to inaccuracies in the waveform.
The aim is to use AC synthesis at low shaft speeds which gives us smooth control of the motor right down to stationary,
then at higher shaft speeds switch to BLDC to give us reliable pulsing up to the full speed of the motor.
SVM for AC synthesis would be done using the software flywheel and the BLDC would be the synchronous torque algorithm.
Obviously this means the transition between AC synthesis and BLDC would need to be carefully done.
The outputs are switched between PWM mode and direct output, and the field vector and amplitude would need to be smoothly maintained
The benefits over just AC synthesis would be more efficiency and higher power at higher shaft speeds.
Also this means the IGBTs would not need to deal with high frequencies at high power
so cheaper components can be used.
Since a working AC synthesis controller using the software flywheel is now developed, a hybrid AC synthesis/BLDC controller is the next step
This is a case of switching the PWM outputs to digital pin outputs, disabling the SVM algorithms and enabling the synchronous torque BLDC algorithms.
The design is to do this around 500 RPM but it may be more efficient at high power to do this a lower RPM.
First step is to integrate the BLDC code so it can be switched by key press.
Which is now done.
So we can use the software flywheel to improve the performance of the Synchronous Torque algorithm.
So the way it works is the angle is timed between 2 sensor updates (shown blue and orange).
This is used to time the software flywheel after the last update (orange) for the new sweep.
The field (red) is applied at 90 degrees to the shaft (orange) and timed for the "mark" to be in the middle
of the sweep (pink).
Same as before the previous sensor updates will be used to assess the angular velocity and this will be use to calculate the mark position and width.
The algorithm will be much simpler as this does not have to calculate an angle fraction, just the time for the full step.
Another way to operate the outputs, now the electronics are capable, is to use the third state of the pin.
The pin can put into a open circuit (high impedance) state by setting it as an input.
This means the MCU output can be high(+), low(-) or open (blank) three distict states giving us trinary logic (also called ternary).
3-states corresponding to the states of the phases of the motor power lines.
It also mean the MCU can drive to all states without the possibility of shoot through.
Using trinary controller logic would be another industry first
Not to be confused with tri-state as that is simply using high impedance to allow multiple devices share a common bus.
This is using all 3 logic states of the MCU for actuating the output.
It is done using a binary CPU using the high impedance state of an input as the third state.
All current designs use either two separate binary outputs for the high and low side giving 4 states total,
or a single binary output, either high or low, with no off state (as with the Prius).
As it turns out the SAM3X chip used in the Arduino Due was designed with motor controllers in mind.
It's not just that the CPU has 5 times the clock speed (84MHz), but also the waveform synthesis is hardware accelerated.
These devices are capable of producing 3-phase AC synthesis at over 100kHz.
On Arduino Due PWM, ard_newbie shares some demo code for it.
There are some bugs with this persons code, but it is a good basis for using the accelerated hardware.
Here is a 1MHz PWM (500nS/div):
..and synthesising 167kHz AC 3-phase waveform (2uS/div with real-time smoothing of the above):
This is 2 orders of magnitude higher than the requirements of AC synthesis and well beyond the capabilities of all high power IGBTs,
but demonstrates the amazing capabilities of this low-cost CPU.
The communication between the controllers and the display in the car are going to be using good old ethernet.
It's much faster than CAN bus and it means a person can diagnose the problems on a PC without any special hardware, like ODB-II units.
And the USB-serial communication is quite simple and very useful, but it just doesn't cut it when you need high speeds for real time displays.
USB serial: 112kbps (up to ~1Mbps if you use a special serial module).
USB 2.0: 480Mbps.
CAN: up to 8Mbps, but that's stretching the limit. Most chips operate at 10-100kbps.
SPI: as a defacto standard effectively unlimited. Chipset with 100Mbps are not uncommon.
Ethernet: 10Gbps is currently used for server interconnects (although the W5100 chip is only capable of 25Mbps).
So as you can see, for raw transfer speed ethernet really is the daddy.
As ever this means we need to author some simple core code which will do what we need without the Arduino libraries.
The libraries are good, for what they are, but when I'm packing in all the controller functionality
and ensuring it runs smoothly without lockups this needs quite a bit of refining.
Including dealing with SPI and the SPI protocol and using external interrupts on the Arduino
The arduino ethernet shield uses a Wiznet W5100 chip (datasheet | notes)
It seems the SRAM of the Arduino was getting eaten up by constant data, which should not happen in a flash based device.
Further research shows that although 'const' is added to all the static data, it is still placed in the SRAM.
In order to leave this in flash there is a pgmspace module with macros and constants for referring to data in flash.
Part of the reason for this is the Harvard architecture, which runs program instructions from 16-bit Flash and has program data in 8-bit SRAM.
The flash and SRAM are actually connected to different busses so the CPU can fetch from both flash and SRAM at the same time.
It doesn't take a genius to see how this would make the system run much faster.
So in order to access constant data held in flash (which is not a data area) we need special instructions.
The LPM assembly instructions are 3 clock cycle instructions so there is a hit on performance,
but this means you can store large tables so reducing calculation times.
Also long text strings for debugging can be stored there giving meaningful output rather than cryptic error codes.
An ADC external multiplexer is added to the electronics so this needs the software to do this.
Also now the software is reading a pulse sensor on the motor shaft it needs to be able to use PIN interrupts
and probably a real-time clock of some description.
The real-time clock can be done in a minimal way with a timer interrupt increment a variable which is reset with each update.
Some experiments were added to this for the ethernet, but there was something unstable about the client.
There is an issue with NC not transmitting key presses (it only transmits after hitting return), so a client was built which does this.
The power train for the van is being completed making the van a usable vehicle from the electronic sense
The vehicle moving (with fixed PWM at 100Hz)
Synchronous Current Sensing
Since the current input is sampled and the sample rate depends on the ADC read time (plus other things) it is arbitrary as to whether this will read when in mark or space.
This problem is a by-product of using a low freqeuncy PWM since the mark and space are so long the current reading might well occur when in a space and be artificially low.
What is actually happening is the current reading is a modulated interference with the PWM sample.
To fix this the current is read as soon as possible after the mark starts using the interrupt from the timer which controls the PWM.
From observation and using a calibrated current meter the software sees a current value roughly half the meter, so a factor of 2 is used to compensate.