Coding Period completed
This was our first time participating in Google’s Summer of Code program and it came to an end with our student’s final evaluation period across late August to mid-September 2017. As you may or may not remember we received around 30 applications/proposals (many of which were very good), narrowed this selection down to around 5, and gratefully received 3 slots from Google in the end. After some preliminary work the students got to grips with the camera’s operating processes and all three began the course enthusiastically. Unfortunately, however, one student failed his first evaluation and another failed his second evaluation, but one student completed the program successfully, his name is
Vlad Niculescu and a summary of his paper follows.
Vlad's website Introduction
The main goal of the task was to design an adjustable voltage converter for the apertus° AXIOM Beta camera system. One specific PCB (the power board) in the camera is responsible for providing power to all other boards (circuits to monitor currents and power consumption are what regulate voltages). This version of the power board uses manual trimmers to define reference voltages and so a solution for dynamically re-configuring these voltages via software needed to be developed. Multiple instances of this converter will be utilized in the Beta, each working with identical hardware components but at different output voltages. The aim was to replace the current linear regulators with switching regulators as linear ones turn a significant amount of energy into heat. Furthermore, the switching regulators will have an accuracy and output ripple closer to that of an LDO (Low-Dropout Regulator). The whole converter will constitute an individual block, this will communicate with the central processing controller through I2C (input supply voltage is 5V).
Figure 1. The Block Schematic
The synchronous configuration was preferred because of efficiency considerations. The chosen driver is controlled by a single PWM signal and this driver processes the signal in order to properly drive the two transistors – it generates two complementary signals and produces the proper dead-time between their transitions. The output voltage is kept constant due to the feedback mechanism - this consists of a hysteresis comparator indicating whether or not the voltage is above or below a reference voltage.
The control algorithm runs on an FPGA and controls the converter in accordance with the information being received from the comparator. Its main purpose is to maintain the output voltage level as closely to the reference voltage as possible (generated by a 12-bit DAC). The output voltage follows the reference voltage regardless of the drawn current. Both the DAC (Digital analogue converter) and the control algorithm act as I2C slaves which allows the I2C master to modify essential parameters. While the DAC’s I2C allows for a reference change, the converter’s I2C gives control over the converter’s parameters, eg. switching frequency or speed of the feedback loop. Both slaves will be connected to the global I2C bus of the AXIOM system.
Designing the Converter
The first step in completing the solution was to design the schematic for a test setup as well as building a prototype to test with. A rendering of the designed prototype board can be seen in figure 2.
Based on the design files, the PCB was fabricated at OSH Park and manually populated. The board was soldered using a hot plate as this was a good way to solder QFN package components.
After the board was assembled I started testing each module individually. The converter was tested by applying a fixed duty cycle PWM signal at input and measuring if the output value equals the expected value.
The DAC converter that uses an I2C interface was the next tested module. Using a USB to I2C Master board from Microchip Technology Inc I sent the configuration bytes that should have produced 2.05 at the DAC output - the measured output value was as expected.
Testing the comparator was the next stage of ensuring that the board functioned correctly. The hysteresis comparator acts like a feedback mechanism which provides the input for the control algorithm. The hysteresis was introduced to reduce the switching frequency of comparators output and it was set to 80mV. A higher value would have generated a higher ripple, too.
Figure 2. The PCB
To test if this value is also obtained in practice, a triangle wave signal was applied to the non-inverting input of the comparator while a fixed voltage was applied at the inverting input. Figure 3 (below) illustrates the triangular signal and also the comparator output where the two thresholds are obvious. To test if this value is also obtained in practice, a triangle wave signal was applied to the non-inverting input of the comparator while a fixed voltage was applied at the inverting input. Figure 3 (below) illustrates the triangular signal and also the comparator output where the two thresholds are visible.
Figure 3. The comparator output
UART to I2C Bridge
To simplify the hardware, testing a UART (Universal Asynchronous Receiver-Transmitter) to I2C bridge was designed to control the system from a PC via serial port. This bridge allows real-time communication between computer and converter which means that the converters parameters and the DAC output voltage can be adjusted via computer. The FPGA (Field Programmable Gate Array) development board used for this purpose was a ‘Digilent Nexys Video’, populated with a ‘Xilinx Artix 7’.
The first step was to establish communication between computer and FPGA. The Nexys Video board uses an USB to UART bridge chip to connect the FPGA to a computer via USB.
The UART to I2C bridge was split into two components:
- The UART control interface: This half is used to adjust the converter settings
- The I2C Master: In order to configure the DAC, this component is also required
Therefore, the first developed component was a UART module. The second step was to develop a I2C Master module. This takes the information received from the UART receiver module and sends it through I2C to the DAC to configure it. The received command is decoded and sent to the I2C bus (controlling the DAC). Both UART and I2C Master are implemented as Verilog modules. The DAC I2C package structure consists of 9 bytes for each transmission - The first one is the DAC address and the other four pairs of bytes are output values for four channels. These numbers are set by the user from the serial console and the bridge makes sure they arrive in the DAC registers. The communication protocol of the bridge consists of a string of characters that represent hexadecimal numbers. The I2C Master sends 8-bit packages and the command string consists of pairs of two bytes followed by a read/write flag. I used a discrete slave-I2C device to figure out if the Master works properly. I sent a sequence like “S49W71W00Rs”, which reads the value in register 0x71 for a device with an address 0x24 (by converting 0x24 in binary format and concatenating it with the read bit - which is 1, it leads to a number that converted back to hexadecimals will equal 49). “S” denotes that a command for the DAC is going to be sent and “s” marks the final character in this command. More information about the bridge protocol can be found
here (page 7, close). After I was sure that both the UART module and I2C Master worked, I integrated these two modules to obtain the desired bridge. Finally, I sent a string from the serial console to configure the DAC.
I wanted to obtain 2.05V at all of the four outputs of the DAC.
Figure 4. The command package
Table 1. The Package Structure for the DAC configuration
Table 1 shows the structure of the package that has to be sent in order to configure the DAC.
Packages are named Ch1-Ch4 in order of significance with Ch1 being the most significant. There are four channels because the DAC is a 12-bit four-channel type. The ChX_MSbyte is a 4-bit number and ChX_LSbyte is an 8 bit one. Concatenating those two, the 12-bit value is obtained for each channel. So, returning to the example, “SC0W07WFFW07WFFW07WFFW07WFFWs” is sent from the serial console where ‘S’ represents the start command, ‘C0’ the device address, and ‘W’ written after each two-number group. This denotes that the number has to be written (R is for read) - The numbers are sent in hexadecimal format. Concatenating 07 and FF for each channel, 2047 is obtained. This is 2.05V for a 4.096V reference.
The Bridge can also adjust converter parameters. The structure of the command is very similar but this time the first letter of the string command can have a value other than “S”.
Table 2. The commands of the BridgeTable 2 shows the adjustments that can be made using the Bridge. Those adjustments are executed from the serial console. The “X” and “T” characters signal that a command intended for the converter is going to be made. In order to adjust the converter parameters (using the last two commands from Table 2) only the UART module is necessary (not the I2C module).
The switching frequency is variable and can be adjusted between 0 and 780kHz with 16-bit resolution. In order to modify it, a command like “Xxxxxs” should be sent from the serial console, where “xxxx” represents a 16-bit number in hexadecimal format. Consequently, “XFFFFs” will set the frequency to its maximum value. The same mechanism works for setting the loop responsiveness with the “T” command.
The Bridge is designed as a state machine. A detailed description of states can be found here (page 9, close).
This I2C Master module was designed for development purposes. Because it allowed me to control the converter and DAC in real time I didn’t need to re-synthesize the project at every parameter change. When the converter is integrated into the AXIOM System this won’t be necessary because it will be controlled by this one through the I2C Slave module. So the next step I took was to implement the Slave I2C for converter. Its structure and functionality are described
here (page 10, paragraph 2).
The Control Algorithm
The control algorithm uses a fixed switching frequency and varies only in response to the duty cycle of the PWM control signal. The parameters of this algorithm are the interval at which the duty-cycle and switching frequency are updated - Through experimenting the switching frequency was determined to be 780kHz. A counter is incremented whenever the output voltage is higher than, and decremented when smaller than the reference. When the update time comes the counter is evaluated, and the duty-cycle is increased or decreased by 1, according to the value of this counter.
Tuning the algorithm:
Finding a way to control the transistor was by far the most challenging stage of this project’s task (In the beginning I didn’t think to pursue a variable that sets the feedback loop responsiveness). Despite the fact that a high efficiency (over 85%) was obtained even from the first iterations of the algorithm, the biggest challenge was reducing the output ripple. I used an oscilloscope to measure this ripple by evaluating the peak-to-peak amplitude of the AC component. It basically has a high frequency component stemming from switching, and a lower frequency component generated by the action of the control loop (this is usually between 1 and 30 kHz). If the feedback loop actions is too slow the ripple will be higher because a low frequency component won’t be rejected by the LC filter.
Figure 5. The output ripple for a slow feedback loopFigure 5 highlights the output signal when such a situation occurs. The transitions between levels look like a square form - which indicates a poor filtering effect. In this case, the feedback loop responsiveness should be increased because a low-pass filter does not have any effect on a very low frequency signal. Unfortunately this may have been due to an error made on my part but I neglected to determine one way or the other whether this had been the case.
Figure 6. The output ripple for a fast feedback loop
However, if the speed of the feedback loop responsiveness is set to a high value, its effect will be harmful too. Because the algorithm uses only a proportional component, and if this proportional component is too aggressive, it will determine an increase in the output voltage at every iteration - In the end an equilibrium was found and I determined that the best value of the interval variable is 96. This means that the feedback loop is read every 96 cycles. Figure 6 highlights the improvement in ripple value. Finally, adjusting the switching frequency to 780kHz for the speed of the feedback loop, I was able to obtain the waveform in Figure 7.
Figure 7. The output signal – 110mV rippleThe obtained ripple reading is around 110mV. This value is still poor when considering the requirements of this project (that the value of ripple does not exceed 50mV). In order to reduce this ripple an additional hardware filter was introduced which consists of a ferrite bead and an 1uF capacitor. Figure 8 (below) presents the output ripple after this additional circuit was added. The ripple was reduced to 30mV.
Figure 8. The output ripple after the second filter was added
Figure 9. The output voltage measured with an oscilloscope
Figure 9 displays the same waveform exported from a Rigol DS1102E oscilloscope set to 50mV/div.
Measuring the efficiency
After I managed to achieve the most important objective (obtaining a low ripple), I went on to determine the efficiency. The efficiency was measured as being the ratio between the output-power and the input power. All the efficiency measurements were done for a 2V output voltage. The efficiency was calculated with the formula:
Figure 10: Variation of efficiency with current
What is important to notice in Figure 10 is that for load currents over 100mA, the efficiency goes over 70%. Moreover, for output currents higher than 250mA the efficiency exceeds 90%.
Measuring Accuracy
Table 3. Reference Voltage vs Output VoltageFuture improvements
There are still improvements to be made here, especially in terms of ripple and efficiency:
Replacing the comparator with an ADC might bring some advantages, and, basically, the comparator is a 1-bit ADC and the information provided by it is very poor. Consequently the complexity of the control algorithm is limited due to poor feedback information from the comparator output. By knowing the precise value of the output voltage a more accurate control could be achieved, however, some research should be done here as any advantages might not justify the additional outlay and, in addition, the space occupied by an ADC.
Integrating a current measurement circuit: The output ripple and efficiency are power-dependent on the load current, by knowing the value of the instantaneous current the algorithm parameters can be adapted, even during running. A lookup table could be developed inside the FPGA so that the algorithm will know what parameters to use depending on the load current.
Note: The project building steps can be found at
https://github.com/vladniculescu/GSOC/blob/master/Documentation.pdf (page 18, chapter 10).
Further Links
Want to participate?
Want to provide feedback or suggest improvements? Want to try your own approach and need help?
Get in touch via IRC or email.
Add new comment