How can i use the Monitor & Tune function at high Frequency?

9 次查看（过去 30 天）
Virag
Virag 2025-6-16
回答： Adit Kirtani 2025-7-1
Hi!
I hope someone can help me with this issue.
I'm trying to monitor a real-time signal on a Nucleo board (STM32F446RE). I have a 20 kHz control system (modeling an FOC algorithm). When I set the solver to 100 Hz and use the Monitor & Tune function, the signal shapes look correct. However, when I increase the solver rate to 20,000 Hz, the XCP serial communication starts losing a lot of data points, and the signals appear distorted or garbled.
I've already checked the baud rate—it's set to 115200, which I believe should be sufficient.
Is the Monitor & Tune feature not suitable for such high update rates, or am I missing something?
I've already tried every recommendation I could find on forums.
If you have any ideas or suggestions, please let me know.
Thank you in advance!

请先登录，再回答此问题。

采纳的回答

Adit Kirtani
Adit Kirtani 2025-7-1
Hi Virag,
As mentioned in other answers, using Monitor & Tune can result in poor signal shape logged from the target hardware due to the high overhead.
When performing Monitor & Tune, the target hardware has to log data, capture timestamps for the logged data, pack everything and transmit it. The framing and transmission of data is performed in a background task when the controller is not actively running any algorithm related task. Combined with the nature of the motor control models which have a control loop running at a high rate, the target is unable to keep up, resulting in a poor logged signal.
While increasing the baud rate can help, the ideal workflow to log signals would be to use a two-model approach. The target model is deployed onto the hardware where it simply transmits logged signals. A host model runs on the host system, reading the incoming serial data and plotting it. This allows for improved performance. Kindly refer to this example to understand how to monitor data using a two model approach.
Regards,
Adit Kirtani.

更多回答（2 个）

Ayush
Ayush 2025-6-18
Hi Vizag,
You are absolutely right to suspect that you're hitting limitations with the XCP over serial (UART) when increasing your solver rate to 20 kHz. At 20kHz, even sending just one byte per sample would require 20,000 bytes/sec, which is almost 2x the bandwidth you have.
At 100 Hz, you're sampling only 100 times per second, which is negligible in terms of data rate, so even large payloads per sample don’t overload the UART. That’s why signals look clean and works at 100 Hz.
You can try the following suggestions:
  1. You can try increasing the Baud rate: You could increase UART to 921600 or 1.5 Mbps, if both your PC and Nucleo support it.
  2. You can use XCP over CAN, SPI, USB: USB (CDC or Virtual COM): Offers much higher bandwidth than UART or you can use XCP over Ethernet (if hardware allows) which is ideal for high-speed streaming.
  3. You can try downsampling the monitored signal to 1kHz or less before sending it via XCP.
  4. For high-resolution debugging, try to log the full signal in RAM or external memory, then dump it via UART/USB after the experiment ends.
  5. You can use STM32CubeMonitor or STLink Virtual COM as these tools offer higher-speed alternatives and better integration for STM32 MCUs.
Hope these suggestions works!
Darshak
Darshak 2025-6-18
Hi @Virag,
This kind of issue tends to come up when using External Mode with fast control loops, especially with FOC running at high frequencies. It’s good that things look fine at 100 Hz — that confirms the setup is working. The problem at 20 kHz is likely due to the communication limits rather than anything wrong with the control algorithm itself.
  • The key limitation here is UART bandwidth. At 115200 bps, the practical data rate is around 10,000–11,000 bytes/sec. Logging just one float (4 bytes) at 20,000 samples/sec already requires 80,000 bytes/sec, which overwhelms the interface. This causes dropped or distorted data during signal streaming.
  • The control execution is not affected, but real-time signal monitoring becomes unreliable because the system can’t push that much data through UART fast enough.
Here are a few suggestions that typically help in this situation:
  • Use signal decimation Reduces how often data is sent, without affecting the control loop. For example:
set_param('yourModelName', 'Decimation', '200')
This brings logging down to 100 Hz.
  • Limit number and type of logged signals Monitor only key variables. Avoid Dashboard blocks and prefer Scopes or workspace logging with decimation.
  • Use a faster interface like USB or CAN if available Switching from UART to a higher-bandwidth protocol can make real-time streaming feasible at higher rates.
Refer to the following MathWorks documentation to know more about the relevant functions:

类别

在 Help Center 和 File Exchange 中查找有关 Embedded Coder Supported Hardware 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by