Previous blog posts of my MSOX3034T Road Test:
Until now we looked at the analog channels of the Keysight InfiniiVision oscilloscope. Since it is a mixed signal instrument it also has digital channels, namely 16 of them.
So, lets see what we can do with these digital channels.
The comes with 16 digital channels, which can be used independently or in combination with analog channels.
The can be used more or less like the analog ones, but at sampling the signal is compared to a threshold, and is digitized to a digital 0 or 1.
The digital signals are sampled at maximum of 1.25 GSa/s rate, with a maximum 200 MHz toggle rate.
The scope is capable of handle digital signals of different voltage levels, with a selectable threshold level:
- TTL (1.4)
- CMOS (2.5V)
- ECL (-1.3V)
- user defined (-8V to +8V).
Two independent thresholds can be set for 8 channel groups D15-D8 and D7-D0.
The digital channels can be used to inspect standard GPIO and as well as serial and parallel communication protocols.
The scope includes a hardware module that offers real-time decoding and triggering for the following serial communication protocols:
- UART / RS232
- USB Power Delivery
- user defined Machester encoding
- and some weird ones: ARINC 429, LIN, MIL-STD1553, Flex Ray, SEMT, CXPI, NRZ
These can be used both on the digital and the analog channels.
Triggering on the digital signals can be done either on edges, pulses or on all kind of serial communication related conditions.
The instrument comes with the N2756A 16 channel digital probe kit:
The probe connects the 16 digital channels to the scope through a single connector. Each channel has its own mini coaxial (?) cable with signal and ground wires. The input impedance of the probes is 100 kΩ, with a capacitance of 8 pF.
The 16 channels are grouped into four groups, which can be separated at near the end of the probe cable. Unfortunately, the groups cannot be fully detached, so we need to carry around all the cables for the 16 channels even if we using only a couple of them.
The individual cables are terminated in some custom connectors with two 2.54mm female pin ports, for signal and ground. A standard pin header is used to keep the unused channels somewhat organized.
The probes came with a set of colored labels, which helps to keep track of them when in use.
Three types of accessories can be used connect the probes to different devices:
- 18 x E-Z Hooks
- 5 x right-angle ground cables
- 5 x ground extenders
Along these, the probes can also be directly connected to 2.54 mm male pin headers.
To check out the digital functionality of the scope, I decided to do some experiments with different serial protocols.
2.1 SPI communication between an ESP32 and a Flash chip
The first experiment involves the TTGO T-Beam ESP32 board a Winbond flash storage chip. We will take at the SPI communication between the ESP32 and the flash storage,
The board is powered from a battery, and already had some program loaded in the flash.
So, I looked up the pinout of the flash chip and hooked up 6 digital channels on the data pins:
- D0 - Chip Select (CS)
- D1 - Data Out (DO) or Data I/O 1
- D2 - Write Protect (WP) or Data I/O 2
- D3 - Data In (DI) or Data I/O 0
- D4 - Clock (CLK)
- D5 - Hold, Reset or Data I/O 3
Along standard SPI, the chip also support dual and quad SPI. In these modes 2 or 4 pin (Data I/O 0-4) can be used simultaneously for data transfer.
To get started, I enabled the digital channels D0-D5 and set up triggering on the falling edge of the CLK channel. I also set up Serial decoding on the SPI signals.
Then, I started taking Single shots while powering on the device. After tweaking the time base a couple of time, I got this bird's eye view of what happening:
As we can see from the above image, at the beginning the communication between the ESP32 and the flash storage happens in small bursts. There is activity no activity on the DIO 2 and 3 channels. This mean we are looking at standard SPI.
After sine time (~30 ms), start appear some activity on the DIO 2 channel, and after that on the DIO 3 channel. This means the communication is switched over from standard SPI to dual/quad SPI.
As the supports decoding only on standard SPI, I thought to focus on the initial standard SPI bursts.
Here is what one of the bursts look like zoomed in:
As we can see, the scope was able to decode the SPI communication.
2.3 Serial Communication between a Arduino based board and a PC
Next, I wanted to see how well the scope handles standard Serial / UART communication.
For this, I used an PIC32 based Arduino board, the
The board was connected to my PC over USB. The UART signals were converted to USB by an FTDI chip.
To probe the UART signals , I hooked up two probes to the pins 0 and 1 of the boards.
The Arduino Sketch used is a very simple one:
Setting up the scope to trigger and decode our UART communication wasn't to difficult:
At this point of I though this is a good opportunity to try out the Segmented Memory functionality of the scope. The way this feature is supposed to work, is that instead of storing one continuous capture in the sample memory, the memory can be used to store multiple smaller captures for subsequent triggers. This way the dead time between events of interested are not stored.
To test this functionality, I updated the Sketch to add some variance to the messages: the letter "o" is replaced with a digit.
Then, I tried to capture 200 segments:
It worked. We captured 200 segments of about 200 us, with ~10 ms dead time between them. Navigation the segments showed how the transmitted message changed.
Next, I wanted to see if we can do Search in the captured serial data. Yes, we can. Unfortunately we can search just for 1 byte at a time, but not for multi byte segments.
But, at least we can Trigger on Serial data:
The above screenshot, show a setup in which only message containing the digit '8' are captured. Note that the delay between the captured segments is now 100 ms, instead of 10 ms.
2.2 How the Arduino I2C Scanner works?
When working with different sensors with Arduino, it is often not that straight forward to properly set them up.
For I2C based sensors, there is a cool little Sketch the , that can be used to check what I2C devices are present on the bus.
I was always interested to see how it works. It is very simple. The tool just scans through the 7-bit I2C addresses by starting an I2C transaction and checking if there is any ACK from a device.
Let's see how this works in reality!
For this experiment I used an Arduino MKRFOX 1200, and two sensors:
- an AS3935 Lightning sensor - I2C address: 0x03 (which is slightly invalid, btw)
- an UV 3 Click ultra-violet light sensor - I2C addresses: 0x38, 0x39
The SCL and SDA signal we hooked up the scope.
As I said before, the tool starts an I2C transaction for each address, by generating a START condition and sending the 7-bit address on the bus and waiting for and ACK.
If a device with the a given address is present on the bus, it is supposed to generate and ACK by pulling low SDA immediately after the address was sent.
At a closer look, we can see that there are no ACK-s for the 0x01 and 0x02 addresses, but there is an ACK present for the address 0x03:
And also for the 0x38, and 0x39 address:
Note: the delays / gaps after the detected addresses appear because in that time period the board is busy with printing messages on the Serial bus.
In the next blog post I will experiment with some RF and other high speed stuff.