Open

Energy

Profiler

Toolset

Drive innovations in the field of low-power technologies

OpenEPT Shield Board: Preliminary Analysis and Results

We are excited to announce the successful completion of the testing phase for the OpenEPT shield board. This milestone marks a significant step forward in our project and highlights the potential of the OpenEPT toolset for measuring embedded system power consumption and battery characterization. The testing results also demonstrate substantial noise reduction achieved by integrating all components into a single board and showcase improved debugging capabilities thanks to the addition of numerous useful features.

During the prototype testing of the OpenEPT board, as described here, we identified critical issues and key bottlenecks affecting the speed and reliability of our measurement concept for embedded systems. One major issue uncovered was the high noise level, primarily caused by the limited performance of the on boardADC and Nucleo board. This challenge was effectively addressed by introducing an external ADC. We selected the ADS9224R, which introduced new challenges related to interfacing it with standard STM32 interfaces. The challenges we encountered and the solutions we implemented are detailed in this blog post.

Figure 1. Prototype board

After intensive tests were conducted on the prototype board, and after issues are identified, all fixes are applied and new version that includes all these fixes is designed and send for manufacturing. After it arrives, soldering of the components is done and new testing begins. Atmosphere from testing in laboratory is presented thought this post while pure testing results will be presented in this blog post.

Figure 2. OpenEPT Complete Shield Board

The shield board allows OpenEPT hardware users to integrate it with any MCU board. The Figure 3 illustrates the pin layout of the shield board.

Figure 3. Pins layout of the OpenEPT Shield board

In our case, we utilized this shield board with the Nucleo-H755ZI-Q development board. Figure 4provides a summary of all the pins used to connect this MCU-based development board with the OpenEPT shield board.

Figure 4. NucleoH755ZIQ Pins used to interface with OpenEPT Shield board

Materials

The latest materials related to the OpenEPT shield board can be found in the Materials section of the website, under the Documentation/Hardware subsection. Currently, the available resources include:

  • BOM List
  • OpenEPT Schield board schematic
  • KiCAD Source files

Testing

As it was case in testing prototype version, within the testing of OpenEPT final shield board we also conducted two testing scenarios:

1. Battery discharge test

2. Measuring consumption of ESP32 module

Testing Scenario 1: Battery Discharge

In the first testing scenario, the focus was on battery discharge. This involved generating various current values and monitoring the battery's voltage response. The overall concept of the testing scenario is illustrated in Figure 5.

Figure 5. Battery discharge testing scenario

Similar to how a prototype board operates, this setup connected the battery to periodically generate different discharge currents. The sampling rate during testing was set to 10 us, and the resulting data was logged into corresponding files. Once the test was completed, the logged data was analyzed using the DataAnalyzer window, which is integrated into the OpenEPT GUI application. This window displays voltage, current, and consumption values obtained during the testing phase, as shown in Figure 6.

Figure 6. Voltage, Current and Consumption values during battery discharge test

Figure 6 illustrates five discharge impulses with varying amplitudes (~100 mA, 1000 mA, 2000 mA, 1500 mA, and 2500 mA) along with their corresponding voltage responses. It also highlights how consumption changes with current values: consumption rises significantly during periods of high current and remains steady when the current returns to zero. The battery discharge test confirmed the overall functionality of the OpenEPT hardware. Moreover, the test provided valuable insights into the noise levels on the current channel. Figures 5 and 6 further detail specific data segments: Figure 7 focuses on the current data at approximately 2.6 A, while Figure 8 presents the voltage data at around 4.2 V.

Figure 7. Discharge current
Figure 8. Battery voltage when discharge current is 0A

In this segment, the average current value was calculated to be 2630.04 mA, with a standard deviation of approximately 2.77 mA. The maximum noise amplitude, recorded with a sampling interval of 0.1 ms, was 13.33 mA (less than 0.5% of the average current). The current rise time was also measured to be approximately 20 µs. For the same segment, the average voltage value was 4.21 V, with a standard deviation of 0.68 mV and a maximum amplitude of 2.99 mV, representing 0.07% of the average current. These findings validate the effectiveness of integrating an external ADC and improving the filter characteristics of OpenEPT.

Testing Scenario 2: Measuring Consumption

The second testing scenario involved measuring the consumption of the ESP32 Wi-Fi module by using shield board that is powered by LiPo battery. The overall concept of the testing scenario is illustrated in Figure 7 while testing setup is illustrated on Figure 9.

Figure 9. ESP32 consumption measurement testing scenario
Figure 10. Testing setup which includes ESP32, Voltage regulator and OpenEPT hardware

The ESP32 module was selected for this testing scenario and programmed with a program which workflow diagram is outlined in the Figure 10.

Figure 10. Flow diagram of ESP32 program

The diagram can be summarized as follows: first, transmit 5 sequence of 10 relatively large data of 1KB with a 1-second delay between each transmission. Then, send 5 arrays of 10 relatively small data of 5B, also with a 1-second delay between each. Data are transmitted over UDP protocol. At the end, EPS32 go to DeepSleep mode. Code which implements this functionality is following

1#include <Arduino.h>
2#include <openept_ed.h>
3#include <ESP8266WiFi.h>
4#include <WiFiUdp.h>
5
6#define BUILTIN_LED 2
7
8const char *ssid = "Embedded";
9const char *password = "********";
10
11WiFiUDP Udp;
12unsigned int localUdpPort = 53615;
13const char *text = "DATA1";
14char big_niz[1000];
15char data_string[255];
16unsigned int cnt;
17
18
19typedef enum
20{
21	ACTION_BIG,
22	ACTION_SMALL
23}action_t;
24
25action_t currentAction;
26int iterationNo;
27
28void setup() {
29	memset(big_niz, '0', sizeof(big_niz));
30	digitalWrite(BUILTIN_LED, HIGH);
31	pinMode(BUILTIN_LED, OUTPUT);
32	WiFi.begin(ssid, password);
33    
34	//Connect to AP
35    while (WiFi.status() != WL_CONNECTED){
36		delay(500);
37		Serial.print(".");
38  	}
39	digitalWrite(BUILTIN_LED, LOW);
40    
41	//print a new line, then print WiFi connected and the IP address
42	Serial.println("");
43	Serial.println("WiFi connected");
44	WiFi.setAutoReconnect(true);
45  	WiFi.persistent(true);
46    
47	// Print the IP address assigned to ESP-12E
48	Serial.println(WiFi.localIP());
49	Serial.print("Access Point IP Address: ");
50  	Serial.println(WiFi.gatewayIP());  // This is the router's IP address
51	Udp.begin(localUdpPort);
52
53	currentAction = ACTION_BIG;
54	iterationNo = 0;
55}
56void loop() 
57{		
58	switch(currentAction)
59	{
60		case ACTION_BIG:
61		for(int i = 0; i < 10; i++)
62		{
63			Udp.beginPacket("192.168.1.100", localUdpPort);
64			Udp.write(big_niz);
65			Udp.endPacket();
66			delay(10);		
67		}
68		break;
69		case ACTION_SMALL:		
70			Udp.beginPacket("192.168.1.100", localUdpPort); 
71			Udp.write(text);
72			Udp.endPacket();
73		break;
74	}
75	if (WiFi.status() != WL_CONNECTED) {
76		digitalWrite(BUILTIN_LED, HIGH);
77	}
78	else {
79		digitalWrite(BUILTIN_LED, LOW);
80	}
81    
82	iterationNo +=1;
83	delay(1000);
84    
85	if(iterationNo % 5 == 0)
86	{
87		currentAction = currentAction == ACTION_BIG ? ACTION_SMALL : ACTION_BIG;
88	}
89    
90	if (iterationNo == 10) ESP.deepSleep(5000000);
91
92}

Once the program is downloaded to the ESP32, voltage and current acquisition begins on the OpenEPT hardware with a sampling period of 100 µs, monitoring three cycles of the previously described program. During acquisition, the data is logged to a file and later loaded into the DataAnalyzer window of the OpenEPT GUI application. The results are presented in Figure 11.

Figure 11. Voltage, Current and Consumption of ESP32 for three execution periods

A single cycle is illustrated in Figure 11. As previously explained, the program logic consists of several key stages: an initialization phase where all relevant peripherals are set up and communication with the UDP server is established, a phase where the ESP32 transmits 10 kB of data over five cycles with a one second pause between each, another phase where it transmits 5 B of data over five cycles with a one second pause between each, and finally, a phase where the ESP32 enters DeepSleep mode. These phases are depicted in Figure 12.

Figure 13. Current consumption for one execution period

As shown in the figure, there is a relatively large variation in current when the ESP32 performs different Wi-Fi-related activities, leading to an increase in the average ESP current. These variations also cause minor voltage drops in the battery, as illustrated in Figure 14.

Figure 14. Voltage drops caused by relatively large current variations.

Conclusion

The first testing scenario was valuable in assessing the limits of the OpenEPT hardware and evaluating its noise performance. It demonstrated that integrating an external ADC and consolidating all components onto a single PCB significantly reduces noise.

The second testing scenario highlighted the primary advantage of OpenEPT compared to other energy profiling platforms: its ability to capture rapid current variations while providing all the necessary features for detailed analysis.

However, despite measuring the ESP32’s power consumption for a predefined program, it remains challenging to directly correlate specific program sections with their respective consumption profiles. The upcoming Energy Points feature, which will soon be integrated into the OpenEPT system, aims to address this issue by enabling the generation of an energy footprint for each function.

Author
Pavle Lakić
Embedded Hardware Engineer
Master's-level electrical engineer with four years of experience in embedded systems and hardware design. Passionate about low-level programming and continuously exploring new advancements in technology.
© 2025 Open Energy Profiler Toolset. All Rights Reserved.