This bog post continues my exploration of the MSOX3034T in the realm of slow speed digital signal analysis. In the previous blog post I used I2C decode capabilities in the MSOX3034T to examine transfers of data between a PIC microcontroller and a Real Time Clock (RTC) device in a data logger. In this post I task the MSOX3034T with a challenge to acquire and decode a sequence of three slow speed digital signals each with three different protocols and three different data rates. Basically I am looking at all of the key signal transfers that occur during operation of the data logger. As in my previous post I ran the Tektronix MDO4104-3 through the same challenge. Both 'scopes emerged triumphant, but the contest went several rounds with wins and losses on both sides.
Nature of the challenge
Capture and decode multiple signal protocols at multiple data rates and search the captured data for specified events. Will the MSOX3034T deliver? Will the MDO4104-3 deliver? The system I used in this test case has three distinct low speed digital signals that move through the electronics during the data upload process. Each signal type plays an important role in system operation. The three signal types have different protocols, different data rates and there is no common clock to tie them all together. The three signal types are summarized in the table below.
| Signal Protocol | Purpose | Data rate |
|---|---|---|
| SONY SIRC Infrared | Command input to the data logger. The microcontroller platform used here does not have a keyboard. User input is primarily accepted through a low cost consumer grade IR receiver Code in the data logger can detect and decode standard SONY home entertainment remote control codes. | About 900 bits/s |
| I2C | Data communication between the PIC microcontroller and four external I2C devices: A DS1624 temperature sensor, a TSL2550 Ambient Light Sensor, a 24LC256 EEPROM, and a M41T81 RTC | 400 kbits/s |
| RS-232 | Data communication between the data logger and an external device capable of sending and receiving RS-232 serial data, typically this device is a PC. Mission logs can be stored in on board EEPROM for later upload to a PC, or sample data can be copied immediately to the RS-232 port as it is acquired. | 19,200 bits/s |
In this challenge the three signal types will appear in the system in rapid succession. The challenge for the oscilloscopes is to capture and decode as much of the activity as possible. Both 'scopes are equipped to decode I2C and RS-232 signals. Neither 'scope has built in SONY IR decode capability. The data rates are fairly slow on all three signals compared to data rates encountered on contemporary high speed buses like USB 3.0, Gigabit Ethernet, 4k UHD, et cetera. Still, this measurement challenge will push certain aspects of the 'scopes to their limits, especially acquisition memory depth. A dual trade off occurs between sample rate and memory depth. Sample rate has to be high enough to provide accurate timing for RS-232 baud rate synchronization and to properly place I2C clock and data edges, but high sample rate means the acquisition buffer gets filled faster, so the duration of the capture goes down as sample rate goes up. I tried to achieve maximum capture duration at a sample rate sufficient to provide accurate protocol decode. The two 'scopes had significantly different limits under these conditions.
There are three states of operation that play out in the signal generation and capture challenge examine here. The table below describes system activity in each state and numbers the three states. These numbers correspond to the state diagram below the table.
| Signal activity component | State | What happens in this state? |
|---|---|---|
| SONY IR signal receive | 1 | Firmware in the logger is in a loop checking all signal activity coming out of the IR detector. When a valid "PLAY" command is detected, the firmware starts looking at the RS-232 receive input, waiting for a go ahead to begin uploading sample data. If "STOP" is detected, mission data is discarded and a new mission is set up by the user. Noise, absence of IR activity, and all other key presses are ignored and the loop continues. |
| RS-232 receive | 2 | A firmware loop checks incoming RS-232 traffic for ASCII "U" or "u". Receiving either of these codes indicates the user is running a terminal program and is ready to accept sample upload. |
| Data upload | 3 | Sample upload begins with transmission of some header information. Then a sample upload loop is entered. In the sample upload loop a sample record is read out of the 24LC256 EEPROM over the I2C bus. Each sample record is composed of the ambient temperature and ambient light readings from the IR and IR + visible channels of the TSL2550 light sensor. The sample record is immediately sent to the PC over the RS-232 TX port. This process continues until an End of Samples marker is read out of the EEPROM. |
Here is a state flow diagram showing what is happening in each of the three states of operation.
The code that runs state 3 is offered below. Note, this code includes use of Goto statements. Viewer discretion is advised.
Uploaded mission data arriving in a terminal program looks like this:
Now that the operation of the system during this challenge has been explained from several perspectives, it is time to see how the MSOX3034T performed. After some experimenting I found the 'scope could acquire an upload of about 50 samples while maintaining a sample rate sufficient for bus decode and search operations. My plan was to monitor all five signals using digital channels. There was an issue using a digital channel to monitor the IR data generated by the Sharp GP1UD281YK IR receiver/decoder. Although the 'scope showed signal activity when buttons were pressed on the IR remote control, the firmware failed to respond to the signal when it was being measured with a digital input on the MSOX3034T. Vertical resolution on the digital channels is 1 bit, so loading won't be visible unless it is so severe there is no signal swing. However, the lack of response from the firmware suggested a loading issue so I checked the input impedance spec for digital channels and found they are rated at 100 kOhm +/- 2% at probe tip. Apparently the digital inputs load the output of the IR receiver to the point where the firmware can no longer detect CMOS level threshold crossings. The analog inputs on the Keysight 'scope are specified at 1 MOhm +/- 1%. I switched to an analog input and the issue was resolved. All other signals worked correctly using digital inputs.
The signal acquisition challenge begins with reception of a PLAY command on the IR data input, so trigger was set to detect a falling edge on IR data. I pressed PLAY on the remote and "u" on the laptop at essentially the same time to avoid filling the acquisition buffer with dead time. The image below from the Keysight MSOX3034T has been annotated to highlight each state in the upload process.
This acquisition captured all 50 sample uploads. The main time base is set to 100 ms/div so we are looking at about 1 second in total of signal activity. There are two sample rates shown on the right panel under "Acquisition". The 1.00 MSa/s rate applies to the analog channel (IR data). The 125 kSa/s rate applies to the digital channels (RX2, TX2, SCL, and SDA). Let's zoom in and take a look at the mission header upload. This occurs immediately after the letter "u" or "U" is received.
Looks good. The decoded RS-232 ASCII values appear toward the bottom of the screen image. You can see the letter "u" on the RX line followed immediately on the TX line with an echo, then the header text is sent starting with the word "Mission" and the mission sequence number (6199 in this case). To check the search capability I set up a search for carriage return (CR) characters. I expected the 'scope would find 6 CR characters in the mission header upload. During search set up I ran into two minor annoyances. First, when entering search parameters I selected "TX data equal to", then, seeing an option to use ASCII as a base, went to select CR from what I thought would be as ASCII table, but was surprised instead to see a decimal keypad. Apparently I need to enter ASCII codes in decimal. which meant I had to search Google for an ASCII to decimal chart.
The second annoyance occurred when the search came back showing only 2 matches. Wait, I now recall from my previous blog post that the Keysight MSOX3034T only searches the portion of the record displayed on the screen. I hadn't adjusted the time base from my previous examination. When I adjusted the time base to make the whole header upload visible I noticed two search match markers and wondered how to re-run the search to catch the other four that I knew were in there. I scrolled through the Lister view on top to discover that it had not updated with the change in time base.
Expanding the lister view to full screen then back to half screen fixed the problem. Now 6 CR characters are marked. My preference would be for the search to run automatically with changes in time base settings.
I covered I2C decode and search behavior in my previous post, so will not rehash either topic here. I will finish this post with a quick overview of how the Tektronix MDO4104-3 handled the same challenge. The digital input on the Tektronix 'scope loaded the IR receiver output just like the Keysight instrument, so I again resorted to using an analog channel to observe the IR signal. Other conditions were similar: 100 ms/div main time base, acquisition record size set to 1 MSa which provided a 1 MSa/s sample rate. Trigger was set for falling edge detection on the IR signal. Because I am well acquainted with operation of the Tektronix oscilloscope, set up went very quickly. I also configured a bus search for CR characters. The Tektronix 'scope searches the entire acquisition record regardless of what the time base setting is, and, as mentioned in the previous post, it places search markers at the end of a match event, rather than at the beginning. An unzoomed screen capture from the Tektronix 'scope and a zoomed search capture are shown below.
How did the 'scopes handle the challenge?
Both instruments achieved the goal of capturing, decoding, and searching data streams with different protocols and data rates. To keep the comparison fair, specifications for the MDO3034T were used as the reference standard. This meant the sample upload capture was limited to 50 samples given the 4 M point half channel interleaved (2 Mpts all channels) record length in the Keysight instrument. Just for comparison sake I was able to capture, decode, and search through a record containing 2000 sample uploads on the Tektronx MDO4000 series 'scope. It is capable of acquiring 20 M points per channel.
Keysight makes mighty fine test equipment. Most of my bench gear is Keysight (or Agilent) branded. I have been using a Tektronix oscilloscope for 8 years and through near daily use my brain has been trained to view signal acquisition through a Tektronix lens. Working with a Keysight oscilloscope reminds me there are other ways of viewing signal acquisition tasks. The two 'scopes have fairly different set up procedures. Switching between the two requires time to pause and think. Each vendor can boast of a few signature features that make their product stand out. So far, for me, the stand out features I've come to enjoy on the Keysight include generous use of "Push to ..." buttons on the rotary front panel knobs (I especially like the "Push for Fine" feature on the time base knob). The best feature on the MSOX3034T (again so far; there is a lot to explore on this oscilloscope) is the touch screen. Touch feels like a natural way to interact with waveforms. I wish the Tektronix MDO4104-3 had a touch screen and I wish the touch interface on the Keysight MDO3034T was a little more accommodating of my touch skills. I am learning how hard to touch, how long to pause, how fast to swipe, and how to target the sweet spots. These are lessons we all go through with any touch enabled technology. Touch enabled is generally better than non-touch enabled, however, I find all touch technology under-performs.
I have to consolidate all of my findings into an official Road Test review in the next few weeks. If I have time to post one more blog it might be about FFT or the Zone triggering feature.
All the best,
Mark A.
