This is a blog post in support of the RoadTest PicoScope 6424E Oscilloscope + Accessories . It is the sixth blog post in a series exploring the equipment in order to generate the content for the final RoadTest review.
A less than ideal showing in the PicoScope 6424E Oscilloscope + Accessories: Application Objective motivated me to investigate some other capabilities of the PicoScope. Servo motor operation on the Pi has be lack lustre in comparison to that of a microcontroller like an Arduino. My goal is to examine the pulse width modulation (PWM) signals that drive servo’s to look for a better understanding of what is happening. Let see if the oscilloscope can help us understand the issue.
This blog post will provide:
- a demonstration of the scopes persistence view to reveal the raspberry Pi servo signal under load
- a demonstration of the scopes mask testing limits to find signal problems
- what next
This demonstration draws on prior knowledge found in the The Road to Raspberry Pi4B/ PoE Hat RoadTest Review (comparison Pi3B+) blog posting. The exercise is to have the Pi run a script that moves the servo from 0 to 180 degress every 5 seconds. While performing this task the Pi CPUs will be subjected to extreme loading, sufficient to cause the throttling. The objective is to use the scope capabilities to display the signals being sent to the servo while the Pi is under load.
Persistence mode superimposes multiple waveforms on the same view, with more frequent data or newer waveforms drawn in brighter colors than older ones. This is useful for spotting glitches, when you need to see a rare fault event hidden in a series of repeated normal events.
The left image shows the pulse when the servo is at 0 degrees. Not much activity going on with the CPU's using the htop display. The colors in the Picoscope screen shot indicate the frequency of the data. Red is used for the highest-frequency data, with yellow for intermediate frequencies and blue for the least frequent data. In the example above, the waveform spends most of its time in the red region, but noise causes it to wander occasionally into the blue and yellow regions. The inlay image is displayed because I used the zoom feature using the mouse that narrowed down the pulse display without having to make adjustments to the scope.
The persistence view when the Pi is under load displays more other colours than before. My understanding is the Pi is trying to execute the code while performing other tasks. This loading decreases the Pi servo performance. During the load exercise the servo did move between two points but chattered (noisy) more than when the Pi CPU was not under load. The servo position didn't extend all the way to 180 degrees. In order to achieve this, I had to adjust the values in the code to increase the pwm.ChangeDutyCycle from 12.5 to 17.5, this resulted in a pulse width going from 1.773msec to 2.422msec moving the servo 180 degrees.
The objective of the exercise is to explore the capabilities of the oscilloscope and not troubleshoot until resolution. The waveforms demonstrate the Pi will continue to produce the servo signal while under load but it does impact its performance.
Mask Limit Test
Another way to achieve similar results of looking at the deviation of the signal from the norm, is to use the Mask Limit Testing (MLT) option. MLT is a feature that tells you when a waveform or spectrum goes outside a specified area called a mask that is drawn on view. PicoScope can draw the mask automatically by tracing a captured waveform, or you can draw it manually. In this example I just created a mask with some time and voltage limits. Mask limit testing is useful for spotting intermittent errors during debugging, and for finding faulty units during production testing.
The allowed area is shown in white and the disallowed in blue. If the waveform enters the disallowed area it is highlighted in yellow and persists on the display. The deviation into the mask is tagged as a failure. Statics on the number of failures is displayed in the measurement table at the bottom of the screen.
The image on the right is the Arduino Nano running using the same mask. Unfortunately I don't have any way to generate a load. The number of failure after an hour was still rather low.
During the lead up to this RoadTest,rscasny made a post suggesting what the vendor would like to see in the reviews. They wanted both the analogue and digital capabilities of the scope presented. I indicated that I would use both to complete the testing. This concludes the analogue blog posts. Additional blog posts will explore the digital capabilities.