Skip to main content
yang2
Associate III
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,

 

 

 

 

 

 

 

 

    4 replies

    yang2
    yang2Author
    Associate III
    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.

     

    TDK
    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.

    "If you feel a post has answered your question, please click ""Accept as Solution""."
    yang2
    yang2Author
    Associate III
    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.

    Billy OWEN
    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

    Associate
    January 7, 2025

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

    Richard.Chvr
    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.

    To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.