[AmpeRose] A finger in every pie

Hello everyone,

As always this post of mine is long overdue, but to catch up on the delay, I’m gonna try to squeeze what I want to say into this one post. Here goes…

Holidays With The PCB

In the week before the holidays, and during the first week of said holidays, (Merry Christmas and happy new year, by the way!) I worked on verifying our schematics for the PCB, with the rest of my team, and I did the placement and routing of our PCB.

However, since our PCB’s design is very delicate, and very prone to being messed up by small details like distance between components, one of our professors, Alex Polti, redid the analog circuit and part of the digital circuit. So let’s give him a shout-out folks!

Minor adjustments were in order because some parts we needed for the pcb went out of stock, but this didn’t have a major impact on the circuit.


After The Holidays, The GUI Days

In the second part of the holidays, and all the way up to this week, I’ve been working with Abdelhadi on our PC software. We’ve faced many challenges, some of which were quite difficult. I’m not gonna talk a lot about this because Abdelhadi has already covered it in his post. I structured our code, and wrote some of the backend and view levels, as well as a trial for the USB and a few tests, while Abdelhadi worked the interface and the ethernet connection, along with a nice emulator. We have a basic working UI now, and are working on bettering it. We are also planning on changing the DataView level, because it’s proving to be very stiff and problematic to deal with: It isn’t allowing for easy control of the triggers, and the data retrieval functions implemented inside are very limited, and allow for so very little control.

This week, I’ve done a fast check on Bilal’s code for our microcontroller’s code. He’s done a pretty neat job of writing a simple API for us to use. Momo’s already reviewed and changed some things in this code, and I’m currently reviewing it one last time.

One more thing I’ve been doing during this time is updating our environment. This includes creating a new docker image for our CI as well as updating our CI pipelines and makefiles.


Upcoming Week, Upcoming Work

For the upcoming week, I’m planning on fully reviewing the C code, as well as the FPGA’s code. We’re planning on merging our work on our master branch to close a “few” PSSC issues.

But most of all, I’m impatiently waiting to get my hands on the PCB so that we could test it, and get it working.


We’ll keep you posted guys,


[AmpeRose] GUI Skeleton

Hello AmpeRose fans,

This post is a bit overdue… Well a lot overdue, I was supposed to write it last week :p

So, that week, in addition to working on the calibration schema, I created the class diagram for our graphic interface, which I ordered into three well wrapped levels:

  • Back-end
  • Data View
  • Graphic interface


The Back-end handles communications with AmpeRose, which includes

  • Reading Data sent by AmpeRose
  • Decoding data using a specific configuration (Translation)
  • Sending commands to AmpeRose
  • Performing special operations with the data (save to file, backup, send to database…)

N.B: Just yesterday, we decided that we might add another class that would handle error correction, using correction info sent forth by AmpeRose. (Benefits of being late :p)



The Data View does not handle the data per Se, but it handles how this data will be viewed.

For instance, it is here that we can choose to view the data as a simple continuous stream, or as lapses that obey to a certain trigger. It is also here that we can calculate the FFT of our data points, to allow the user to see the frequency spectrum of his device. The data container of the Data View will act as a moving window for the measurements, i.e. it will contain a fixed number of points (10^7 to 10^8), and as new data pours in, values will be replaced.


The graphic interface

This part of the pc software is what the user will see and use directly. It will view the data in a useful manner, and will allow for control over AmpeRose, as well as the other components of the software.


That’s all for tonight folks,

But stay tuned for the way more interesting post about the updates on our calibration circuit this week!

P.S: Some titles are links to images of the class diagrams.

[AmpeROSE] Initial Calibration

Good evening everyone!

In this long overdue post I will talk a little bit about one of the two main subjects I have worked on these past two weeks: The calibration method.

In a perfect world the whole initial calibration method would not be needed, but we live in the real world, so here goes…


We have gone to great lengths to get the components most suitable for our purposes. That said, the components of our measurement circuits are far from perfect: they present a number of errors we have to tend to.


These are the most important errors that must be corrected if we are to obtain meaningful results from AmpeROSE:

  1. Shunt errors:
    1. Precision error on Shunt resistor values
    2. Added resistance of the switch transistor with each Shunt resistor
    3. Leakage current of said transistors when blocking
    4. Input bias current of the buffers after the Shunt stage
  2. Amplification errors:
    1. Gain error of the operational amplifier in use
    2. Offset voltage of said amplifier


1.4. AKA the input bias current of the buffers is negligible. Note that we added the buffers to reduce this leak current, which was before that of the Op Amp.


Now for the calibration method. Our calibration will run as iterations of a 2-step process:

  1. Consider the Shunts perfect and calibrate the Amplification stage
  2. Consider the Amplification stage perfect and calibrate the Shunts

For step 1, we will apply a zero voltage difference on the input of the Op Amp, but we will get a non-zero output. this is a static error, the amplified input offset voltage of the Op Amp. We will measure this value, using our ADC, and save it. We will the apply very specific non-zero inputs to the amplification stage. From each output we get, we subtract the static error. in the end, we approximate the slope of the output line. (Of course we will take care not to saturate the Op Amp.) Now, also through software, we can correct values we get from the amplifier.

Now for step 2, we will use a current sink (discussed in a different post) to force a very specific, and well known current to pass through each Shunt branch. And… You guessed it… We will not measure the value we’re supposed to measure, due to the errors discussed above. Then we use these values to shift our measurement scales, in the software.

We will repeat these steps until we reach a fixed point. This calibration may also be performed when AmpeROSE heats up, because component characteristics change with heat. Also, non-linear errors are a nuisance we will have to endure.

So, to wrap this up, you might have noticed that we’re gonna need some extra components to be able to accomplish these calibrations. Thankfully those will not affect the measures themselves… We’re going to add a current sink to our circuit, as well as switches to cut it clean from the Supply of the DUT.

[AmpeRose] Protocol Definition

Good evening, everyone,
This is Michel from team AmpeRose, and this week, I had the task of defining the communication protocol between our device, AmpeRose, and the graphic interface meant to display the measurements.

We had already defined (last week) our main data structure as a 32-bit word. We had also announced that we will be using an Ethernet connection. So we have agreed on using a simple protocol defined as follows:

AmpeRose to PC:

AmpeRose will send 32-bit words to the software, using the Ethernet connection. The MSB (Most significant bit) of these words defines them as data words (0) or control words (1):


  • Data word: In the case of a data word, the bits [30:8] will be the measured value, bits [7:2] will be the context pins, and the bits [1:0] will define the caliber. This type of words will be way more common than control.


  • Control word: If the word is a control word, its value will indicate if it is an ACK, a NAK, or an error. ACK means AmpeRose has executed a command, NAK means that it has refused. There may be multiple NAK and error words, depending on the level of information we wish to have from this message.


PC -> AmpeRose:

The computer will send command words to AmpeRose, over the Ethernet connection. Each value of the 32-bit word will correspond to a specific command. There will be start and stop commands, frequency calibration commands (preset values), as well as commands to choose whether to read from the SD card or do live measures.

Note that some commands, such as switching from direct measures to SD card may only be sent while AmpeRose is in a stopped state, and will solicit a NAK response otherwise. The software may consider a command executed only after receiving an ACK response. Commands sent in a certain order will receive ACK responses in the same order.

Here is a small list of possible commands:

  • Start
  • Stop
  • SetFreq50
  • SetFreq100
  • ReadFromSD
  • Measure

This list is far from exhaustive, and is subject to change at any time. But it should give the reader an idea about how the computer will pilot AmpeRose.


Having accomplished my task for the week, I spent some time studying a few examples of measurement circuits, to catch up with my teammates who had the task of defining our own circuit, and try to assist them in this critical task. The results of this endeavor, however, are the subject of a different upcoming post!

[AmpeRose] Computer interface design and functionalities

Hello everyone!
Today, as we conclude our second week of working on the AmpeRose, we would like to show you a rough view of the interface of the computer software that will be communicating with AmpeRose.

I’ve had the pleasure of helping in designing this interface, along with Abdelhadi, and this is the end result:

Note that the main focus was on the ergonomics and how to include the functionalities, rather than choosing nice shapes on so on. These aesthetic details are easily changeable and need not be determined this early in the development of the project.

Our interface will show a continuously updated graph of the current, and will boast an auto-adjusting scale.It will also show the maximum value for the current in the window, as well as the activation and disactivation instants of the GPIO pins.

On the left side, you can notice a few statistics values, as well as buttons to control the viewing mode (Trigger or Normal mode, FFT mode), and to control AmpeRose itself(Frequency, Start, Stop, etc…).

Moreover, the user has the possibility of reading live data from the Ethernet connection with AmpeRose, or data stored on its SD card.

And finally, the user will be able to change the names of the GPIO pins, from the edit tab. These pins, connected from the DUT to AmpeRose, will provide the user with the ability to customize the pin names when performing tests.

This interface may still be changed of course (hopefully to include more functionalities). We sincerely hope you liked the interface, and welcome any suggestions!

AmpeRose: Plans for week 2

Hello world!

We are the AmpeRose Team, and we’re excited to tell you that today we embark on our noble quest of creating an affordable high precision Micro-Ammeter!

This week our work will be divided between two crucial tasks:

1-We are going to conduct an extensive research on current measurement techniques and state of the art tools to perform them. This task will be supervised by Ian.

2-Meanwhile, under Michel’s lead falls the task of specifying the architecture of our embedded system, as well as its interface with the IoT device.

In both of the aforementioned tasks, we will first focus on the functionalities, and once we have a clear image, we will choose specific components that fit our specifications.

We will be setting the overall specs and performance requirements for our project very soon, so feel free to comment with your notes, suggestions or remarks!

Keeping you posted,