# [AmpeROSE] Recalibrating our Architecture

Hello, everyone!

In this post, I’d like to discuss a final significant change that our architecture for AmpeROSE underwent in the end of December.

### The calibration problem

As you may recall, a fundamental task for AmpeROSE is to perform “automatic calibration”, controlling in real time the value of its shunt resistance, which is used to convert the current drawn by the device under test (DUT) into a tension that is amplified and measured by an ADC. Each possible value for the shunt corresponds to a range of current values that may be effectively measured with it. Having an inadequate shunt value at a given time can cause the following negative consequences:

1. If the current is too small for the shunt (there’s a larger available value for the shunt that we should be using), we lose precision.
2. If the current is too big for the shunt (there’s a smaller available value for the shunt that we should be using), we lose measurements, as the reading will just be stuck at the maximum value for the measurement range corresponding to the current shunt. More importantly, we risk having a brownout on the DUT if the burden voltage becomes large and the situation persists for longer than the DUT’s power supply circuit can handle.

You may consult these two previous posts (1, 2) to review our process for arriving at the automatic calibration scheme we initially based our schematics and PCB design on. Here is a high-level view of it, with the calibration circuit in the center:

In this configuration, hardware comparators are used to generate signals that indicate whenever the amplified shunt voltage has surpassed the upper limit for the current measurement range (VIN>VON), or gone below its lower limit (VIN<VOFF). A third comparator determines whether the burden voltage (voltage on the shunts) has surpassed its maximum allowable value, its output being ALERT. These outputs are fed into a circuit composed of discrete ICS (NAND and NOT gates, SR latches and delay blocks) that implements the calibration logic and generated two outputs (SW1 and SW2) which contror transistor switches which may be used to connect and disconnect resistor in parallel with the shunt, thus changing its value.

In this configuration, it is the microcontoller’s job to read each mesurement from the ADC when it’s ready, through SPI, and sample values of the calibration outputs and of the context bits to associate with the measurement. It also determines the reference voltages for the comparators using its digital to analog converters and controlling a potentiometer.

In the course of the elaboration of our printed circuit board (PCB), this approach for the calibration circuit proved to be problematic, in particular the placing and routing of the different ICs, some of them containing several logic gates that would , not to mention the difficulty of reasoning about the timing of the logic signals. More importantly, the calibration logic would be locked into what is determined by the discrete ICs placed on the PCB, and would be impossible to correct if tests with the finished PCB revealed that corrections would be in order.

In view of these issues, our supervisors encouraged us to consider two alternative approaches that would grant us more flexibility and could be implemented more expediently:

### Calibrate using a FPGA

This approach uses a small field-programmable gate array – FPGA (small in terms of package size/pin numbers, and in terms of number of interal logic cells) to implement the calibration logic and generate the SWx outputs. The calibration circuit would be described using a hardware description language such as SystemVerilog, which we have employed often in our embedded systems education, and could be corrected by reprogramming the FPGA through JTAG.

Additionally, we envision using the fpga to read the ADC measurement and the context bits, and prepare and transmit the complete measurement word to the microcontroller though SPI.

### Calibrate using the microcontroller

In this approach the outputs of the comparators would be connected to microcontroller pins and would generate fast interrupts, whose service routines would implement the calibration logic and update the shunt control signals.

This design has the advantage of simplifying even more the PCB, and would take advantage of the relatively powerful microcontroller we’re using in our design. On the other hand, performing the calibration does represents a significant burden on microntroller if compared with the circuit with the FPGA, especially because it will also be managing an Ethernet connection.

### And the winner is…

Neither! I mean, both! Our PCB will contain a MAX3000A fpga with 44 pins and 64 macrocells, but the components have been placed and routed in such a way that it will be possible to implement either of the designs present above in the PCB, just by reprogramming the microcontroller and the FPGA. The calibration using the FPGA will work essentially as described previously, while for the calibration using the microcontroller, the FPGA will be programmed to simply transmit signals transperantly between the microcontroller and other components in the board.

This strategy will allow us to evaluate the feasibility of both strategies, with the goal of determining which would be more interesting for a more mature version of AmpeROSE. I’m currently working on the SystemVerilog code for the calibration using FPGA, which should then be simulated and tested so we can be confident it’s likely to work when we receive our PCB.

### 1 comment to [AmpeROSE] Recalibrating our Architecture

• […] [AmpeROSE] Recalibrating our Architecture : ROSE 2018 on [AmpeROSE] A Tale of Two Calibration Methods […]

This site uses Akismet to reduce spam. Learn how your comment data is processed.