Issue with 12-Lead ECG Waveform Plotting and GUI Implementation on STM32

[smj-11]

Dear STMicroelectronics Support Team,

I am currently working on a project using an STM32 microcontroller where I need to display a 12-lead ECG waveform. The display layout is configured in a 3x4 grid format, along with an R-1 waveform shrink. I have implemented an RTOS for managing the GUI rendering and data handling efficiently.

For the GUI, I am using the TouchGFX framework and have integrated dynamic graphs to plot the 12-lead ECG waveforms in real-time. The ECG module communicates with the STM32 via UART using interrupts to handle data reception.

However, I am facing issues with accurately plotting the ECG waveforms on the screen. The waveform representation seems to shrink or misalign, particularly in the R-1 section. Despite configuring tasks with adequate priorities and stack sizes for the GUI and ECG data, and ensuring the refresh rate is set to 4 ms, I am unable to achieve a stable display.

Could you please provide guidance on optimizing the dynamic graph display using TouchGFX or recommend any specific configurations in the STM32 settings that could resolve this issue? Any advice on fine-tuning the integration between the RTOS, UART, and TouchGFX would also be highly appreciated.

Your support and insights would be greatly valued.

Thank you.

[MM..1]

You still ignore real math or you info isnt complete. IF all 12 points is refresh data every 4ms then on display 4x3 you heve for one point 1280/4 = 320 pixels (*4ms) filled with data over 1,28 sec . I mean only terminator can read this signal. But if only one point every 4ms, then time is *12 around 15s for fillout .

And you question 1. simply reply is no this speed dont exist. Required framerate is 250Hz. The 5 Best 240Hz Monitors - Fall 2024 - RTINGS.com

But in real TouchGFX or other GUIs , data arived quicker as lcd refresh is simply handled in packs ... one lcd refresh show for example 4 new data points = 4ms vs 16ms ...

Partial mode refreshed displays with memory can update areas on bigger framerates ...

[smj-11]

Thank you for your detailed feedback. I understand the concerns regarding the update rates and display limitations. I want to provide some additional context on how the data is handled in my implementation:

Data Handling vs. Display Refresh Rate

1. Data Update Speed: The 4 ms interval refers to how frequently I receive new ECG data points for each lead via UART. This means I receive one new data point for each of the 12 leads every 4 ms.

2. Display Rendering: The challenge lies in rendering these data points smoothly on the display. While the framebuffer shows smooth and continuous waveforms, I encounter some issues with rendering smooth curves using the Dynamic Graph Widget in TouchGFX. The graph visualization is not as fluid as expected, leading to a perceived "stuttering" effect despite the data being updated correctly.

Visualization Example

I have attached an image showing the current implementation of plotting 12-lead ECG waveforms in the framebuffer. As seen, the waveforms appear smooth and continuous in the framebuffer, but the Dynamic Graph Widget struggles to maintain the same level of visual smoothness.

Objective:

My goal is to ensure that the waveforms display smoothly in both the framebuffer and the Dynamic Graph Widget, without missing any data points or causing visual artifacts. I am seeking advice on optimizing the widget’s update rate and synchronization settings to better match the real-time data updates.

Are there any best practices or configuration settings within TouchGFX to achieve smoother dynamic graph rendering at high data update rates?

[GaetanGodart]

Hello @smj-11 ,

You have provided 2 pictures of what you expect to see correctly, but you did not show us what the issue is.
Can you share a screenshot/picture/video of the unwanted behavior?

As MM and Andrew said, the human eye cannot see the difference between a 4ms refresh rate and a 16ms refresh rate. If you keep the refresh rate of the display at 60fps, it will still look smooth.

One thing you could do to verify how smooth your display is would be to check the performances. Look at this article to see how we measure performances in TouchGFX : scenarios-measure-performance .
Simply add an output pin to measure the render time.

Maybe one option for you would be to reduce the color depth of your display to have less data to transfer.
Most setups are using RGB565 (16 bits) but you can use other formats.

Regards,

[smj-11]

I understand that the human eye might not perceive a significant difference between a 4ms and a 16ms refresh rate. However, my concern is specific to ensuring that the ECG waveform data, sampled at a 4ms interval (250 Hz), is being accurately displayed in real-time. The issue is not with display refresh rates, but with the rendering of the ECG data points themselves at the correct sampling interval.

I have attached an image highlighting the problem with the waveforms as seen on the display. This should help illustrate the difference between the expected smooth waveforms and the current behavior, where the 4ms sampled data points are not being rendered correctly.

To address your request, I will also capture and share a image of the unwanted behavior for a more comprehensive view.

[GaetanGodart]

If you choose to refresh at 16.66ms, you could just add points until the queue is empty. The dynamic graph have a "addPoint" method I think. So you don't need to refresh every 4ms to be able to properly display every data point even if the data arrives more frequently that the display refresh, you just need to add multiple points between each refresh.

Thank you for the image. So the issue is that sometimes there is no peak or that the peak doesn't go as high as the other peaks right?
You assume that the data point are not being rendered correctly but it seems weird to me because it only happens on the bottom graph, not on the 3 above.
What have you done to be certain that you get the correct data?
Could you for instance add some textArea to display the data received to make sure you are supposed to have a high peak.

I just want to make sure that the issue is related to the graph not displaying correctly as the other 3 are fine. 
If you display the values and there should indeed have a peak each time, what happens when you change the order of the graphs? What happens when you change their position (is it always the bottom one that fails)? What happens if you try to display the same dataset on 2 graphs (is one correct and the other one wrong)?

Regards,

[Andrew Neil]

---

@GaetanGodart wrote:

What have you done to be certain that you get the correct data?

---

^^^ This! ^^^

[smj-11]

Thank you for your suggestions.

I tried the method you mentioned regarding the "addPoint" functionality. However, I've noticed that the problem occurs across all dynamic graphs, and they are not displaying the ECG waveform correctly, even with the addition of the grid. The peaks are inconsistent, and the overall shape of the waveform is not as expected.

I will continue to investigate and see if there's any underlying issue with how the data is processed or rendered. If you have any further insights or suggestions on how to approach this, I would greatly appreciate it.

[Andrew Neil]

Still waiting for you to say how you are sure that you are receiving the UART data all complete & correct.

[smj-11]

To ensure that I am receiving the UART data completely and correctly, I implemented

Data Logging: I log the incoming UART data to a file or a serial monitor for comparison against expected values, ensuring that all expected data points are being received.

[Andrew Neil]

and if you plot that logged data, it doesn't have the issue you're reporting (peaks inconsistent, overall shape not as expected)?