Playing with MSO58

[Murayama]

Hello everybody!

That's my first contribution to this website. At least I don't remember having written
anything. Today I would like to talk about a few odd things I noticed when using
Tektronix' MSO58. There are a few demonstrations out there, but I was looking for
something more down to earth, how is the daily use. As there is apparently very
few posts talking about it, here is a first run.

Some background: I have been using Teks for ages, starding from a very old analog
465 I was given, then a TDS 460A that I was also given. Now I have a MSO3000, about
8 years old, doing fine but which can get quite slow. I'm consiering the purchase of
an MSO58 because as an encoder designer, I need 6 high resolution channels. Not an
absolute need, I can do it with my MSO3000, but it would be more convenient, and
with a few extra digital channels, it would be perfect.

Tektronix has allowed me a free ride for a week. This week. Thanks guys! (although
I'm almost sure none of them is reading this message).

My first big surprise: I wanted to use SPI. I plugged the digital probe and set the
signals to the proper pins. Until here, no surprise. But I pressed the button for bus,
set it to SPI, and here I had only 3 signals: SCLK, SS and Data Input. No data output.
I contacted Tek, and it's not a bug, it's a feature. If you want the return channel,
you have to instantiate a new bus. Isn't that silly or is it just me? Check attached picture
SpiConfig.png.

Check the result in SpiBusAlone. What a loss of space if you dont' display the waveforms.
There is a lot of space on that screen, but is it a reason to use that much?
On top of that, if you have both MISO and MOSI (therefore 2 buses) and want to display
bus and waveforms, you end up with 2 identical clocks, one in each bus window.
See picture SpiClkData. And you can notice that the contents of the bus window are not
rearrange so that everything is visible and centered. Worse with the SS signal, it doesn't
even show (picture SpiCkDataNss).
In fact, the firmware is rather brutal. It takes the total available height, divides by the number
of windows and sets the same height of each window, whatever the contents. Even if there is
a bus + 3 signal lines.

I finally chose to display bus only, rename the buses (by the way, the screen bottom stickers
don't reflect the name change. Too bad, you never know which corresponds to which).
And in order to have the waves, I opened another windows for 4-line parallel port. I renamed
the lines accordingly. See picture SpiResized.

Now from that picture, since the waveforms are not displayed in the buses, I thought
that any parameter could be changed and it would keep the layout... No!
If you change form idle to NSS, it will reset the layout as on picture SpiBusAlone.
There was absolutely no need to change the layout.

By the way, if I choose idle time for the framing, why does it systematically
remove the NSS signal? Am I the only one who wants to check the NSS in this case?

OK, temporary conclusion: if you want one SPI bus with bus and waveform display, you need:
- 1 SPI bus for MOSI
- 1 SPI bus for MISO
- 1 parallel bus for waveforms.
It takes really time to configure.

I found a bug and a feature which is not so good.
The feature: if you choose idle time, it always starts from 50 µs. Why 50, I don't know,
but as SPI is in most of the cases around 10 MHz, 50 µs seems to be a lot. I wanted 200ns.
So starting form 50 µs, reducing goes: 50, 49 ...  3, 2, 1, the next is 0!!! Who is
interested in a delay of 0 µs??? Couldn't it be like 50, 20, 10, 5, 2, 1, then 500 ns
instead of 0? It takes you 3 steps per decade and can be very quick. There are 2 buttons
A and B. Why not A for the above approximative setting and B for fine tuning?

Now the bug:
- Open the SPI config panel.
- Double click or tap on the delay value (which is currently 1µs)
- Try to enter "100"
>>> It does not work, you get 0.
It happens like this:
- Double tap the idle time : at that point the current value (which is 1) in the entry
field is highlited
- Enter the 1 : at this point, you have still 1 highlited, maybe because the value didn't change,
so entering 1 or 11, or 111 would not do anything.
- Enter the first 0: since the value was highlited, it's replaced with 0
- Enter the second 0: no change, and you get a delay value of 0.

Ok, that's it for the time being. If all MSO58 users could also speak of their own
experiences / frustrations, that might be a good source of information, and possibly
a source of ideas for Tek engineers, as I noticed there ar a few here.

By the way, there might be workarounds for the above problems, but at least not very
intuitive. And I'm a typical engineer. Play with it first, and read the docs if you don't
have any alternative.

Pascal

[nctnico]

Nice write-up  Thanks for taking the time.
If you are interested in a >4 channel oscilloscope then don't forget to look at Yokogawa.

[Murayama]

Hello!

I also forgot to mention that it's not possible to group signals. If I use 6 analog signals, then
each of them will be very small (considering I also need digital signals).
Overlay mode in this case doesn't make sense because there digital signals mix up with analog,
there is no way to separate them. At least no way I know, but again I'm new on this beast.

The signals in an encoder go by sin & cos pairs, and there are 3 pairs. So grouping them by
pairs would already result in larger curves and since sin and cos overlap only twice per period,
they wouldn't hide each other. So having groups, and naming the groups would be great.

Well, beside this, this scope is great, as said by almost everybody, so no need to add much on the
issue. Yes, one thing. Tek has added a hardware edge selector, and you don't need to dig in the menus
to choose the trigger edge, it's done by a single button. And the selection can involve both edges,
by a rotating state: rising <push> falling <push> both <push> rising...
And the same for trigger : normal / auto.

But frankly spoken, I was expecting a lot better firmware. The version (I have updated it yesterday)
is already 1.8.something, and it's 1 year old, in which case you can usually expect something more
brushed up.

So again, a call for other contributors to talk about their own observations. Post screen copies only
if you have time to spend on it, but anyway the more info we have the better. And hopefully the most
likely the bugs will be fixed.

Pascal

[Murayama]

Hello!

Today, I would like to report about one of the most attractive features of this scope (at least to me).
So among other issues: pinch zoom.
As shown in many demonstrations on the net, pinch zoom is really a great feature. For example, having
details about the oscillations of the switching effect of a laser diode can be done instantly, you just
zoom what you want to observe just as you would do with a picture on your phone. No learning
curve. Doing this on an MSO3x is a pain. You have to dig into the signal menus, go to offset, add an
offset. Then you get the oscillation detail.
The attached picture shows the detail of the config I may use in the future if I buy it. I even used
7 analog signals and one SPI bus (for which I didn't find a better solution than using 3 buses as
explained earlier). Well, in most cases I will use 6 analog channels only, but let's get to the scope
limits. As Tek provided only 2 analog probes, all the other channels are empty, but this would be
basically the setup I would get. Look at how small the sinewave is!!

Now as I was first observing the SPI signals, I had to zoom out. With pinch zoom. A side effect is
that I changed the height of the C5 window. This is unintentional, so there is a problem here, you
have risks to do unintentional settings / destroy some other time-consuming settings.

Next, I tried to zoom vertically the sine wave. No way. The window is already too small, the fingers
too near (even with my small pianist fingers).
One way to do it: expand the window you want to access (single touch and drag), tune the vertical
gain, and set the window back to its original size.
Another way, maybe easier: single touch the wave and use the gain button, but in this case, you loose
the smooth increase, you are back into the large increase steps as on the good old scopes.

I found another issue when zooming.
Suppose you want to observe the top-left corner of a laser diode switching effect (nanosecond range
or less), and that the trigger is somewhere like 1 µs earlier. Pinch zoom allows you to zoom the detail
and the detail does not escape your fingers, it stays at the center. But when the window width
corresponds to 1 µs, the trigger will bump into the left border, and the detail you observe will escape
the screen on the right.
To solve this problem, you have to switch the zoom mode (physical button on the right).
Question: would this be a problem to automatically switch the zoom when the trigger bumps into the
left border? At least, that's the behavior I would expect.

As a conclusion of this:
- Pinch zoom is very handy to observe large signals. There is an issue that would be easy to solve,
automatically switch zoom mode when the trigger reaches the left border.
But it depends on Tek's decision.

- In case of using many signals, pinch zoom is of little use. Unable to directly zoom signals
in small windows, unwanted geometry changes...

I feel somewhat uncomfortable with the fact that after a while, Tek's firmwares don't evolve
even if there are issues. The latest version fo the firmware on my MSO3x is already more than
6 years old, just about a year after I bought it.
Supposing this MSO58 is an early product series that will be upgraded soon, there is a risk
of no support shortly after the first series sales stop.

Pascal

[rsjsouza]

Pascal, this is very interesting info. Being a hobbyist-oriented forum, I suspect there are not many others that own this oscilloscope to provide such feedback, but hopefully they show up.

[Murayama]

Hello!

Thanks for your reply. That's what I was worrying about. But on a thread posted last
year about MSO5x series, I noticed that there were pros and also Tek guys out there.
Beside this, I suspect there are not many users even among the pros. The configuration
I'm looking at costs more than 50 K usd (maker list price, I hope Tek will make efforts
for me), and I don't know any owner at this time.

Pascal

[bson]

But I pressed the button for bus,
set it to SPI, and here I had only 3 signals: SCLK, SS and Data Input. No data output.
I contacted Tek, and it's not a bug, it's a feature. If you want the return channel,
you have to instantiate a new bus. Isn't that silly or is it just me?

My LeCroy does the same.  It's astonishingly silly.

[Keysight DanielBogdanoff]

There's a pretty good number of people on this forum with this range of oscilloscopes, I'd be surprised if no one steps in.

I will say that this is a new enough scope that there's no way stop firmware development, at least for bug fixes. That's one of the perks of going with a new-generation scope.

We've also been working with oscilloscope touch interfaces for a while now, and definitely have some tricks we do to make it easier to use. Not trade secrets, per se, but little things we don't talk about that make a big difference in the UX.

[nctnico]

Not trade secrets, per se, but little things we don't talk about that make a big difference in the UX.

That sounds a bit like the Emperor's new clothes because if a feature really improves things then it is a good selling point. Why keep quiet about that?

[rsjsouza]

Not trade secrets, per se, but little things we don't talk about that make a big difference in the UX.

That sounds a bit like the Emperor's new clothes because if a feature really improves things then it is a good selling point. Why keep quiet about that?

Nico, this may well be related to implementation tricks that have a greater consequence to, say,  smoothness of menus. For example, if a UI uses sprites or a specific dedicated frame buffer topology, this may not be deemed necessarily a sellable feature without heaps of pages of theory that explains it. It could easily translated to a "smooth interface".

[Murayama]

Hello!

There's a pretty good number of people on this forum with this range of oscilloscopes, I'd be surprised if no one steps in.

I'm glad you say that. I was really thinking I posted to the worst possible forum. Well, not the worst, let's
say the less adequate.
OK, so since you are in this business, what I would expect of a decently designed SPI analyzer is this:
- Configure everything in one window (CLK, MOSI, MISO, CS), and configure what you show / what you don't.
- Have standard names worldwidely used for SPI (not Data In, but MOSI, MISO)
- Having the possbility to keep showing CS even when using frame idle time. Tektronix seems to know what
    is good for me, and never shows CS if I choose idle time for framing. I would like to show it anyway,
    or at least to have the possibility to do so.
    -> In fact, having the 4 signals with a checkbox facing each of them, and allowing to choose show or not.
    would be close to perfect.
- Use a fixed decent size to show the bus. In one of the screen captures above, you can notice that each
    of the signals takes about 1 cm. This is way too much, you don't need to see the detail because these
    are digital signals. Leave display space for details for analog signals!!!
    In fact, on MSO3xxx, the pitch of the digital signal lines was fixed, quite small, but good enough.
    In case you have to show 16 digital signals, just add a small space between 7 and 8, and it will be just fine.

To summarize, my ideal SPI decoder would look like this. (look at the 2 pictures, how it is by default, and
how I would like it).
Picture current state: that's what is shown when you use the default settings. Here, 2 analog signals, and
one SPI bus. Note that at this point, there must be a bug. The MISO shoud show 00, not <NO DECODE>.
Maybe this happens because it uses 2 separate buses. If the SPI was processed as a whole, I guess there
would be a decent decoding. By the way, for a single bus, having to use 3 buses do display it is already
silly, but why having 2 different idle timeouts? This is also not very smart.
The second picture shows an "almost ideal" display.
There should be no separation between the MOSI and MISO representation, but in this case, you have 1 window
per bus and 3 buses (2 half SPI and one parallel). It could be a very narrow strip showing everything.
Next issue: The SPI decoder insists in writing Data: 00h for example. I KNOW THIS IS DATA!!! no need to write
it. Next, I know this is hexadecimal. No need to write h at the end. There is no ambiuity. If I read 00, I know
that 2-bit SPI doesn't exist. So it has to be hexa. Or at least provide an option "show format code" or something
like that. And "show Data: prefix" if it's of any use for anybody. Having just the hexa value could allow to read
longer data runs on a single screen.
I have edited the screen copy to show how it would be ideal for me. Look how it could be clear, with no
redundant info. No ambiguity when there is no "h" at the end of the data, you can see the clock above it.
Well, idle time for framing should be the same on both, I forgot to adjust the setup.

By the way, there is an issue in pinch zoom. Sometimes it simply doesn't work (horizontal pinch). I have to
exit zoom mode, and then reenable zoom mode so that it works again. But I can't reproduce the bug 100%.

OK, that's it for today, I have the scope for another 2 days, and a lot of work to finish. Sorry. Maybe something
els at coffee break.

Oops, before I forget: there is no way to directly resize for instance channel 2 (the blue trace in the attached
graphics. If you want to resize trace 2:
- Move the border between trace 1 and trace 2 (single touch) // This kills the bottom most trace
- Move the lower border of trace 2 // this restores the bottom-most track
Could be nice to do this in a single pinch.

Pascal

[Murayama]

Hello guys!

Just another small bug (or let's call it again an unoptimized feature).
I wanted to select cursors. At first I didn't notice because I was selecting cursors for the blue
signal (channel 2). And the cursor selection (when you tap a vertical bar) is blue. The same blue.
I wanted to do the same for channel 1 (yellow). In this case, the cursor labels have the right
color, but if you select the bar (I tried on both horizontal and vertical), then it's highlighted in
light blue... And I thought at a first glance that the setup was referring to chan 1.

I took a picture of it. I was expecting my finger to be on the picture, but apparently the scope
doesn't take full pictures...
Joke aside, look at the blue line with the "t = 2.741µs" label. NB: it doesn't measure anything,
just for cursor demo.

Pascal

[Murayama]

Hello!

I just found out that I cannot keep the scope for the week-end. The transporter
was OK to pick it up on Sunday afternoon and deliver it on Monday as originally planned.
Maybe Tek didn't want me to continue to write on this subject and requested it earler,
I don't know. Anyway the transporter picked it up a few hours ago.

So I would like to summarize a week of real world use of this scope. I have been using
mostly SPI which is not really a technology challenge, but I wanted a look and feel which
is not exactly the demo that Tek is showing since the last 10 years at least, but a
real daily use report.

As for the Tek demo. Yes, it's a good demo, they used the very same circuit board when
they sold me the MSO3000 8 years ago. Ok, I'm able to detect one event that shows up
once over a million time, and I'm glad I can do that. But what about the simple use,
the every day engineering life?

NB: this reflects only my opinion, it also possibly reflects the fact that I don't
know this scope well enough, there are potentially many tricks I'm not aware of.
And it's an incomplete test, I checked laser diode switching waves, and used only SPI and
parallel bus. No Ethernet, USB, etc... That's just a report of what I noticed, period.

So, my conclusion:

1. As everybody agrees about it, the hardware is brillant. The analog inputs
seem to be up to what can be expected (although I didn't do real measurements).
It's really visible if you do an FFT (of a square or anything known). With the low
resolution (not so low anyway), you have quite some noise and if you switch to high
resolution mode, then you get a very clean FFT, with the impression that you can really
do measurements, unlike the 8-bit scopes.
The case is great, they paid attention to the smallest details and were quite careful
and successful not to leave any place for the devil.
If asked to grade the hardware between 1 and 5, 1 being the best (A to E if you prefer),
I would definitely give it a 1 (or A) without any hesitation, even A+ or A++ if this
makes any sense to you.

NB: Let aside the technical choice, is it better to have a separate digital input
or only flex channels, etc, etc... This has been fully discussed in another thread
on this side. I simply like it. But I agree that at least 2 digital probes should
be included for free, otherwise it's only a PMSO (potentially mixed signal oscilloscope).

2. The GUI is fine, but as mentioned earlier, the brutal switch stack / overlay
is not sufficient in my opinion
- Stack: all signals are represented with the same height, and if you do modification
(e.g. height of the window), the scope doesn't remember the modification if you change a
parameter, even one which has no relation with the GUI. With all signals stacked, the
signals are really small.
- Overlay: all signals are displayed on the same window (digital mixed up with analog),
   which can be a big mess.
--> No intermediate view, like groups of signals. It would be so easy to implement.
    For example, you take one of the stickers on the bottom bar, and you drag and drop
    it on another sticker. Et voilà! A new group is created. The related curves merge into
    the same window.
- Too much space is given to digital signals. They don't need to be accurate, and
as long as you can make the difference between low and high level (which is already
brillantly achieved by green / blue difference), then you're done. No need to give
digital signals a 1 cm height when 2mm is enough. This implementation exists on MSO3000!!!
The parallel signals are equally spaced, and very close to each other.
- One bug, or at least an incomplete implementation of the cursors. The highlight color
should fit the color of the channel. At least I think so.

With a similar evaluation as above, I would give it a 3 (or C) Well, considering that the
concept is rather new, let's say 2.5 (or C+, B-, whatever makes sense to you). It looks
like an early firmware (although 1 year old), some kind of good beta version, but not more.
It's basically working well, but there is still a lot to do, bug fixes (when the pinch zoom doesn't
respond), etc...

3. The worst part is the SPI implementation
- SPI needs 3 different bus instantiations / configurations (2 SPI, one parallel).
   which triples the configuration time. It was easier in previous scopes (e.g. MSO3000),
   even with the menu navigation, and it's easier on a Rigol 1054Z.
   Side effect, it triples the display surface needs because all the windows have the same
   height...
- Big waste of space when stacked (default setup), especially displaying bus only
- Signals out of the window when you choose to display bus and waveforms. I know,
   you can rearrange manually, but it's in contradiction with Tek's argument for
   window stack mode: the first thing engineer do is stack their signals so that
   everything is viewed. This should apply to the SPI window. The first thing happening
        in one bus window when you choose to display the signals should be to automagically
rearrange
        everything so that it looks nice. Looks like the GUI programmers
   have never heard of object oriented programming.
- Again Tektronix assumes that if you choose idle time for the framing, then you don't
   need to watch the SS signal. Question to the users: am I the only one who thinks
   this capability would be helpful? I think the user should even have the right to
   decide which of the 4 SPI lines he wants to watch. With a checkbox facing all the
   signal definitions. So If I want to display MISO only (no clock, no NSS) it should be
        allowed.
- Bug in the idle delay setup
- Redundant display: why displaying "Data :" in any single byte of info? Write it at
   the beginning of the signal, or don't write it at all. Or better: make it a configurable
   value that anyway nobody will ever use after setting the prefix to "".

Question to readers: is there a technical reason to design a SPI decoder that has to
be spread over 3 buses? I can't think of any reason.

With that kind of implementation, I think it's better to analyze the SPI with 4 parallel
port lines. At least you need to configure only 1 parallel bus. No byte values for the
display, but you will save 1800 USD for a useless SPI.
Note that it's not Tek bashing! I'm only writing facts, except maybe when I
said "I like it". And beside this, I'm (almost) ready to buy one. As for my bad SPI
evaluation, It's not my fault if the Rigol 1054 Z I bought for my student
is better (talking about SPI decoder only, and furthermore only the way it is set, not
the functionality. I'm sure there are events detectable by the Tek and not by the Rigol).

Well, this time I couldn't write more, but it would be interesting if other users could
share their opinions on UART / Ethernet / USB / CAN, etc... analyzers. Don't review the
scope with Tek's demo board, it just doesn't make sense and it has been done zillions of
times.

Pascal

[bugi]

Not trade secrets, per se, but little things we don't talk about that make a big difference in the UX.

That sounds a bit like the Emperor's new clothes because if a feature really improves things then it is a good selling point. Why keep quiet about that?

An imaginary counter-example: "For parameter xyzzy, using adjustment rate of exactly 10 units + 8.5% per second gives about 50% reduction in handling time compared to a normal flat rate + accelerate above threshold".  Such a thing would not be a 'selling point' but can still give an edge over competition. Have enough many such tiny details in the user interface, and users just love to use it (vs. pulling hair while using competitor's product).  Fonts, font sizes, particular icons, placement of UI elements, timings, clockwise vs. counter-clockwise, etc. etc. all those little things, there is really no good way to "sell" those details other than in a generic sense. Most users would not even understand the differences (when reading about them), but they can sort of feel it when using.

Note, that was all without considering particular brands or even devices, it applies to anything from a zipper to mobile phone to airplane etc.

[Murayama]

Hello everybody!

Just an update, to be fair.
I went to a Tek presentation, and they have upgraded the firmware. It's now possible to make
signal groups. I couldn't experiment extensively, but what they have shown me seems to be
a great improvement.
BUT: adding a signal also resets all the scaling you may have done. Example: if you have 2 signals,
one occupying 1/3 of the screen and the other 2/3, then if you add one, the logical scenario would be
that 1/3 becomes 1/4, 2/3 becomes 1/2 and the last added signal also 1/4. But it doesn't work this
way, it's still an even distribution to 1/3 each.

I couldn't check that the bug I was talking about has disappeared.
But I could verify that the SPI still needs 3 buses instantiations (2 for MOSI and MISO and one
extra bit for chip select which disappeared since I choosed timeout for triggering the SPI).

I would like to reiterate my call for other reports. Did anybody use the USB analysis extension?
Ethernet? Etc...

Thanks,

Pascal

[Murayama]

Hello everybody!

Again, I have one Tek MSO58 in my lab.
I would like to report another odd thing.
This time, it's not about SPI but still about the GUI. I use it in analog, I'm working with encoder
signals (therefore sine with a limited amplitude but large offset, say 1Vpp, but 2.5V offset).
I wanted to watch the signal and tune the mechanical part to have a maximal analog signal.
Therefore I wanted to shift the signal down in order to observe the sine wave around its
offset. THIS SIMPLE OPERATION IS NOT POSSIBLE.
The scope refuses to shift the 0 out of the window, therefore you cannot observe details of
a signal at a given offset. Not directly with 2 fingers.

If you want to change the offset, then you have to double-tap the signal icon. It calls a window
in which you select offset and change it with one of the big knobs on top right.

If you look carefully at Tek's promotional video, you can notice that indeed, they show that
you can scale up the wave with 2 fingers, but they have carefully selected an example where the
0 is always in the window.

You want to observe switching oscillations? You can do it, but not directly. Not as simple as
Tek claims.

I don't think that shifting the 0 out of the window is beyond of the technology and I can't imagine
any technical reason of this limitation... Again, a poor implementation on a great hardware.

Pascal