Skip to main content
Visitor II
October 8, 2024
Question

The monitored data with "spike"

  • October 8, 2024
  • 4 replies
  • 1620 views

Dear Sir,

When I monitor the data, sometimes the value often accompanied by spikes, such as followed figure.

yang2_1-1728383267255.png

 

In my case, I monitor 3 variables that update from ADC registers.

yang2_7-1728384270751.pngyang2_8-1728384290569.png

Normally, their values would be around 0.

The signals of ADCvalue[0] and ADC Value[1] appear to be normal.

yang2_2-1728383529394.pngyang2_3-1728383540988.png

However ADCValue[2] has some spikes.

yang2_1-1728383267255.png

 

When I verify the variables byIDE, the variable does not show these spikes. It always remains around 0.

yang2_4-1728384076630.png

And I also used a conditional statement to check: if the value is greater than 50 (the maximum spike value is around 260), a counter would increment. However, the counter has always remained at 0, so I believe the actual variable does not have these spikes.

yang2_5-1728384188082.pngyang2_6-1728384212024.png

 

What could be the possible reasons for this?

Best Regards,

 

 

 

 

 

 

 

 

    This topic has been closed for replies.

    4 replies

    October 8, 2024

    Additionally, if I add monitoring of other values, there is a chance that the data will return to normal.

    yang2_1-1728385808947.png

    For example, as shown in the image, I added two more monitoring variables, offset[0] and offset[1].

    At this point, ADCvalue[2] returned to normal.

     

    Super User
    October 8, 2024

    The spikes are about 256 off of the real value. It's a int16_t value which is sometimes positive, sometimes negative.

    I would guess that whatever is reading the value is doing so one byte at a time rather than both bytes at once, which causes the issue. For example, if you read the first byte when the value is -1, and the second byte when it changes to 1, the reading will be around -256.

    How to fix? Not sure. Perhaps change the acquisition mode or add a trigger such that it doesn't probe the value when they're being updated.

    October 9, 2024

    Hello TDK, 

    I think what you said makes a lot of sense. It might really be caused by the fact that it's transmitted as two separate bytes. Thank you for sharing your opinion.

    ST Employee
    October 8, 2024

    Hi @yang2 

     

    This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

     

    Regards,

    Billy

    Visitor II
    January 7, 2025

    I have the same issue and it's really anoing, when you are monitoring low range signals

    Technical Moderator
    January 30, 2025

    Hello

    As stated by @TDK, changing the acquisition mode to avoid reading the value when it is being updated may solve the issue. 
    What is the acquisition frequency? Could be also a good idea to tune it according to the variable update frequency.

    STM32CubeMonitor adapts the reading size to the type of the variable to monitor, i.e reads 2 bytes at a time for a int16, 4 for a int32, etc... When your read 3 int16 type adjacent variables, as in you example, cubemonitor reads 8 bytes at a time. The read procedure is not the same as the one used for a int16 variable reading, that may explain why it works in that case as the reading delay is longer, the ADCvalue[2] update occurs in between each read process.