AmperROSE Week 3: Architecting AmpeROSE

Hello, everyone!

In this third week of the project, while part of the team focused on researching ways to measure small currents precisely, the rest (Michel, Bilal and me) focused on defining the overall architecture for the digital part of the device, in particular the method used to communicate with the user interface. This is a post explaining our results in this front:

A general view

Our project is divided in two parts:

  • An analog part responsible for the measuring the current being drawn by the Device Under Test (DUT)
  • A digital part responsible for

The interface between the two parts will be, naturally, an Analog-to-Digital Converter (ADC). Here is a general view of the architecture for the digital part of AmpeROSE, in image form:

Below is a couple of comments on the role that some of these components will play in AmpeROSE’s operation:

SD card

We envision two modes of operation for AmpeROSE:

Online mode

In this mode, AmpeROSE is directly connected to a third party (where the user interface program is running) through Ethernet. In this mode, the measurements will be streamed directly to the user interface as they are collected.

Offline mode

Alternately, it will be possible to use AmpeROSE without a connection . In this mode, the measurements will be stored in a SD card, from which they may be recovered later.


AmpeROSE is intended as a tool to aid in the profiling and optimization of the energy consumption of iot devices. Thus, it should provide a way to associate meaningful information about the state of the computation with the current measurements.

The solution we have adopted is to add six input pins to AmpeROSE, to which GPIO pins from the DUT may be connected. The user user will then be able to instrument the code running on the DUT to change the state of said GPIO pins in order to reflect the state of the program. For instance, a pin could be toggled depending on whether the device’s WiFi module is on of off.  These inputs will be sampled at the same rate as the current, and their will be associated with the corresponding current measurement when it’s streamed the user interface or saved in the sd card.


Three measurement ranges will be provided by AmpeROSE:

  • 1 nA      –   1 uA
  • 1 uA      –   1 mA
  • 1 mA     –   1A

One of the main jobs of the processor will be to automatically calibrate the measurement stage to the adequate range as the current being drawn from the battery changes. For the moment, a preliminary calculation indicates that we will not need more than 24 bits (a more detailed calculation is planned very soon). Therefore, we plan to use a 24 bit ADC. Each measurement will then be a 32 bit word consisting of: 24 bits of measurement + 2 bits to indicate the range + 6 bits with the sampled states of the 6 inputs from the DUT.


USB2.0 is a widespread interface supported by a multitude of systems,  from computers to embedded devices. Theoretically, it can transfer data up to 60MB/s. However, due to bus access constraints, the effective throughput of the High Speed signaling rate is limited to 35 MB/s.

Transferring a word at 10 MHZ would give a maximum rate of 32 * 1000000 = 40MB per second > 35 MB/s, therefore, USB2.0 is not well suited for our purpose.

Of course, we could choose USB3.0 that provides an effective data signaling rate of 400 MB/s, however, it is not supported by all devices, and the use of it would add strong constraints in order to use AmpeRose as a precision device to measure low current.

In conclusion, USB will only be used as power supply to charge the battery.

Fast Ethernet

Fast Ethernet is a standard network interface also supported by many systems. It can transmit data up to 100MB/s, so it supports our maximum throughput of 40MB/s at 10 MHZ. In addition, it supports full duplex mode, which means that, while transmitting data to the third party, AmpeROSE will be able to receive commands from it.

4 comments to AmperROSE Week 3: Architecting AmpeROSE

  • Alexis

    Why 10Mhz for sampling resolution ?
    Is Ethernet 100 really 100MB/s or rather 100Mb/s ?

    • ian

      It’s indeed 100 Mb/s. Thus, the considerations regarding data rate in the “Fast Ethernet” section are incorrect.

      Under the orientation of professor AP, we have reviewed the design criteria for choosing the sampling frequency.
      AmpeROSE should be able to capture the smallest period during which the types of device we are targetting may be expected to activate their communication technology (LoRa, BLE, Wifi) to send or receive data. Researching this parameter for different low-power communication technologies, we have settled on 100KHz as our target sampling frequency.

      We also will review the measurement ranges.

      Would the preferable way to account for these changes in the project be to edit this post, or dedicate a further post in the end of the week to presenting the project parameters we have updated, and our reasons for doing so?

  • phh

    What is the expected switch time between ranges?
    Wouldn’t it better to have some overlap between ranges?

    • ian

      Hello phh,

      We do not have discussed the switching mechanism too deeply yet. Taking into account that we will reduce our sampling frequency to 100KHz, do you think the switch time could affect us significantly?

      Having the ranges overlap would indeed be desirable, as peforming the switches in range within these overlapping regions would help us avoid loss of data. We will review the measurement ranges, to express them more properly (as an interval 0-max. current value, with an associated precision) and to have overlapping regions.

      Thank you for your comment!

Leave a Reply to Alexis Cancel reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>




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