• Author Author: colporteur
  • Date Created: Date Created
  • Views 1014 views
  • Likes 4 likes
  • Comments 5 comments
Related
Recommended

PicoScope 6424E Oscilloscope + Accessories: Not Satisfied

colporteur

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

 

Persistence View

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.

imageimage

 

 

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.

 

imageimage

 

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

 

imageimage

 

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.

 

What next

During the lead up to this RoadTest, 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.

  • in reply to colporteur

    Sean,

     

    First off, on closer inspection, my statement might not be applicable. In thinking about the sampling rate (1 MS), this implies a sample taken once every uSec. In your examples (servo pulse widths), your horizontal divisions are either 0.5 or 1.0 mSec, or 500/1000 samples.  This really is not too bad.  The amount of variance in your edge timing appears to be close to 50uSec, or 50 times greater that the sampling interval, so again, the sampling rate is not really effecting the accuracy of your readings.

     

    In general, I like to keep my sampling rates up as high as possible.  There have been many times where I start becoming concerned about pulse width variance only to find out that I was sampling at a rate too close to the frequency that I was measuring (not the case here) and am observing a artifact due to poor quantization (resolution).  High sampling rates are also helpful in getting a better view of the edges of the waveform that you are measuring.  If the edges are represented as straight lines (specially if your are zooming in) it is likely that you are not sampling at a sufficient rate to capture the waveform.

     

    Again, it appears that your captured waveforms are correctly showing a real issue of unwanted timing variations in the servo signals, must likely caused by uncertain timing of the pulse generation software on your Raspberry PI.

     

    Gene

  • in reply to genebren

    image

    I have pondered your commentary for a while trying to decide how to respond. My difficulty is that it reflects on how little I know about the equipment so that the setup is appropriate to capture the signal. It can be difficult when you have to confront your own ignorance.

     

    My college lab instructor some 40 years ago insisted we explain why test equipment was set a particular way and what we were looking for in results, before putting the probe to equipment.  Of course we tried to avoid his rules and just get the meter in there to take a measurement. It has taken the 40 years to understanding why he had that rule.

     

    I confess in my test equipment setup I hoped it would work. The scope features that auto sets conditions was a god send. I would be the first to confess this is a great piece of bench gear that will not live up to its full potential because of the operator. I just don't know what I don't know. Switch clicking to find a result is not a skill I have mastered.

     

    Now that I got the self depreciation over with, I'm trying to understand what setting changes can improve the measurement. Collection time, number of samples and hardware resolution are the three settings I'm assuming you are referring to.

     

    To see the waveform I set the collection time. The signal has a pretty short duty cycle so that setting range is small. The other two leaves me bewildered. Why not keep the Hardware Resolution bits to maximum all times? The number of samples would be better if more, correct?

     

    I appreciate that the whole stew is made by balancing the settings. I'm not the best of cooks with the utensils.

  • in reply to Andrew J

    Thanks for the commentary AJ.

     

    Titles have never really been my strong suit. Writing theory suggests, you never title a piece until it is finished. Most people, me included, put the title on the paper as a starting point. There, now I have a title so I am writing. Titles are supposed to be pondered. That takes time and if not done, does reflect in a poor showing, as I have demonstrated.

     

    I don't have the knowledge or the skill level in technology that some members of the site possess. To compensate, my approach is to find discovery by thinking of ways of using the equipment in a work environment.

     

    As I confessed, the servo not working on the Pi is a failure on my part. I failed to invest time in troubleshooting. It worked before. It should work now. Unfortunately before, the knowledge was fresh. A year later not so much. The bad servo's was bit of a surprise. They have gone into the bin to avoid the same situation twice.

     

    I really enjoy exploring theory in a practical environment. I have seen numerous drawings of servo waveforms but not actual seen them scoped output. The Picoscope User Guide had a number of options and functions that I kept saying, I wish I knew about that. This post was a bit of a crap shoot. I felt it was important to cover my topic but when that went smooth, I felt I had to dig up some dirt.

  • It is difficult to tell on the zoomed in images, but it does appear that you are using a relatively low sampling speed (1 M/S) for these tests.  That leaves you with 1 usec resolution that might be skewing your results a bit.  I would suggest a much higher sampling rate (1 G/S at least).

     

    The realtime operation of the RPi makes it a relatively poor choice for  accurate pulse generation.  Even with the Arduino, a bit banging approach is going to be subject to some timing variation, like when interrupts occur (timer, serial, etc.).  PWM generation using hardware timers (available on Arduino) will generate much more accurate results.

  • Hi Sean,

     

    I’m not clear on the title of this post - it implies there is a problem with the scope/accessories but from reading the post it would seem the scope performed well in these tests.  The persistence colours look clear and the mask seems well-made.

     

    You’re making readable and useful posts: I like your approach of trying out the scope to identify and debug problems rather than just a demo of features.