This is a blog post in support of the RoadTest PicoScope 6424E Oscilloscope + Accessories . It is the seventh blog post in a series exploring the equipment in order to generate the content for the final RoadTest review.
When fitted with optional 8-channel TA369 MSO (Mixed-signal oscilloscope) pods, the PicoScope 6000E Series adds up to 16 high-performance digital channels to up to eight analog channels, enabling you to accurately time-correlate analog and digital channels. Digital channels, captured from either parallel or multiple serial buses, may be grouped and displayed as a bus, with each bus value displayed in hex, binary or decimal, or as a level (for DAC testing). You can set advanced triggers across the analog and digital channels. The digital inputs also bring extra power to the serial decoding feature. You can decode serial data on all analog and digital channels simultaneously, giving you up to 24 channels of data – for example, decoding multiple SPI, I²C, CAN bus, LIN bus and FlexRay signals all at the same time!
I confess this section is not my strong suit. Through small baby steps, I accumulated enough knowledge to perform some tests that explores the capabilities of the PicoScope using the MSO.
This blog post will provide details on:
- digital display of Pi & Arduino servo data
- exercising an TA369 8-channel MSO pod
- sample of I²C bus data
- what next
Digital Display of Pi & Arduino Servo Data
I used the TA369 MSO pod to produce digital signal from the servo outputs of the Pi and Arduino, the same as was done using the analogue probes. This will serve as a starting point to get familiar with the new equipment.
The images above are an Arduino Nano analogue and digital signals at 0 & 180 degrees.
The images below are the Raspberry Pi analogue and digital signals at 0 & 180 degrees.
The data produced by the scope forces me to reconsider my assumption about the Pi pulse width varying while under load.
The python script uses values for the duty cycle parameter to generate the desired pulse width. These values are derived using mathematics.
0 degrees = 0.5msec/20msec = 2.5%
180 degrees = 2.5msec/20msec = 12.5%
These values when used in the script do not generate the desired pulse width but come up short in the width of the pulse when it on. The scope output clearly shows this anomaly.
pwm.ChangeDutyCycle(2.5)
time.sleep(5)
pwm.ChangeDutyCycle(12.5)
time.sleep(5)
Using the digital signal viewed on the scope I adjusted the theory values for the pwm.ChangeDutyCycle to increase the on time to get the desired pulse width.
0 degrees = ChangeDutyCycle(3.2)
180 degrees = ChangeDutyCycle(18.5)
Using these values the servo motor travels the full range. I then moved the code to a different raspberry pi to confirm I would get similar results and did.
You may recall the objective in my application to RoadTest Review for this scope was to prove why the python script wasn't driving the servo's on a Raspberry Pi. I just stumbled across another reason I may have issues, while testing the second Pi. The servo uses a 5V power supply separate from the Pi's. When I failed to create a common ground between the Pi and the servo power supply the servo was erratic. Makes sense when you are not in a hurry and actually think about what you are doing. This may have also contributed to my failure along with the bad servo's and incorrect script values. A trifecta of issues causing the servo's not to work.
Exercising an TA369 8-channel MSO pod
My first test was to generate a 256bit counter signal using a GPIO outputs of the Raspberry Pi and some python code. This would give me a digital waveform to examine. 8 GPIO ports of the Pi are connected to the 8 inputs of the pod. In the image below, the analogue channel has been turned off to make the full screen available to the digital display. Shown are 8 channels with the capacity for an additional 8.
A stumbling block for me in producing the data stream was setting up the trigger. After a deep dive into the manual, I discovered the scope has the option to build a digital trigger. The scope is set to trigger when all the inputs are 0 (zero) or the beginning of the 256 bit count. Armed with my new limited knowledge and with the support of the User Guide I am going to attempt to generate I²C bus data.
Sample of I²C bus data
So you have a desire to learn how to decode I2C serial bus? Well not only does PicoScope indicate their equipment can do it, the User Guide provides a reference link to their resource page https://www.picotech.com/library/oscilloscopes/serial-protocol-decoding-i2c that walks you through the process.
To prepare for the exercise I configured a Raspberry Pi with a Real Time Clock (RTC). The RTC module uses i2c. When you haven't done an i2c setup exercise on a Pi in some time, it takes some thinking to get it right. Now that the RTC module is recognised on i2c bus, two channels DS0 & DS1 were connected to SDA1 pin 03 & SCL1 pin 5 on the Pi. Following the instructions at the link provided by PicoScope, it took a bit of figuring to finally capture a trace. Setting the triggering options was the secret sauce that got it working. I finally managed to get a reasonable display. Issuing the i2cdetect -y 1 command from the Pi command line interface triggered the scope and scrolled a pattern across the display.
Looking at the signal pattern provided at the PicoScope resource web link below
I actually captured the i2c data that is reflected in the pattern. At the start of packet a master device takes control of the bus by driving SDA low while SCL remains high. This indicates that a message will follow. Next a 7 (or 10) bit address is transmitted followed by a R/W bit to indicate whether it is a read (1) or write (0) instruction. I actually used the scope screen shot to count the data bits. Yeah, they are all there. I'm not familiar enough with i2c to start examining the bits but initial impression is that with my limited knowledge and a little help from my friends at PicoScope I got this to work.
An interesting observation. When I first opened the plastic case for the TS369 MSO pod, I assumed the collection of grabbers, leads and ground clips would soon find there way to the garbage bin. Bit and pieces like this usually kick around until they get lost or thrown out. I was presently surprised when I started actually using the components from the kit. You soon discover the pieces have practical value. The fittings are like Lego building blocks, available to create the ideal test probe. The Raspberry Pi RTC clock module occupied the GPIO i2c signal pins, leaving very little as a measuring point. No fear, the MSO grabber tucked in nicely between the pin heads sticking out and made a solid connection. I'm left with the impression that the people who designed the kit had experience and knew what they were looking for in the design.
What Next
I have been trapped in this time warp continuum called MS Windows to long, in order to evaluate the scope. I need to find some relief and sanctuary so I am going to invest some time in the Linux world next. Now that I have an understanding of some of the functionality of the software let us see what it offers in a Ubuntu environment.
