After a year of effort, PulseView - sigrok's new logic analyzer, oscilloscope and MSO GUI - is nearly ready for its debut release: v0.1.0.

At this stage we're making a concerted effort to drive up the quality of our release candidate by giving it a thorough round of bug hunting and bug fixing. The range of features offered by PulseView at this stage is quite modest, but those features that it does offer should work well, without crashing or malfunctioning.

In order to experience the joy, or indeed pain, that our users may experience, I've started trying to use PulseView to solve a real problem. This is not the first time I've attempted this task; I've tried to do it several times before, but it hasn't been possible until now to get through this without some kind of crash or error.

The Problem

Cypress FX2 based logic analysers have been supported by our fx2lafw open firmware for some time now. Most of these devices are very simple having only a single FX2 on the board. There is a slightly more interesting device: the USBee AX, which has an ADC attached to the upper 8-bits of the FX2's data input. It is therefore a very simple mixed signal device.

I acquired a chinese clone of this device about a year ago: the EE Electronics ESLA201A.

For a while now, I've been working on a branch to add support for these MSO devices both to the fx2lafw firmware and the libsigrok driver. The results so far have been mixed (no pun intended). While the device seems to do a reasonable job of capturing signals from an NE555 board that I have, when I connect the analog input to ground, it goes crazy:

This trace was taken with the analog input grounded, and capturing at 1MHz. Pretty broken.

Yo dawg! I heard you like Logic Analysers...

So why is the capture getting corrupted? Fortunately (courtesy of Bert Vermeulen), I have just the tool to find out: The OpenBench Logic Sniffer. This device is a logic analyser capable of sampling at up to 200MHz - fast enough to trace the ESLA201A while it samples.

Here I have attached 8 probes to the 8 data output lines of the ESLA201A's TLC5510I ADC, and a probe to the ADC clock input.

I then set the ESLA201A to sample continuously with sigrok-cli. I like to use cpipe to measure that the pipe throughput is what I would expect it to be, and then dump the data in /dev/null.

$ sigrok-cli --driver=fx2lafw --device samplerate=1M --continuous -O binary | cpipe -vt > /dev/null
thru: 1854.344ms at   69.0kB/s (  69.0kB/s avg)  128.0kB
thru: 132.646ms at  965.0kB/s ( 128.8kB/s avg)  256.0kB
thru: 127.458ms at 1004.3kB/s ( 181.6kB/s avg)  384.0kB
thru: 132.681ms at  964.7kB/s ( 227.8kB/s avg)  512.0kB
thru: 127.580ms at 1003.3kB/s ( 269.5kB/s avg)  640.0kB
thru: 132.563ms at  965.6kB/s ( 306.3kB/s avg)  768.0kB
thru: 132.689ms at  964.7kB/s ( 339.4kB/s avg)  896.0kB

...then I set PulseView to capture a trace:

So far this is what I would expect to see. Channel 0 is the clock input, and channels 1-8 are the data output, where channel 8 is the MSB. Therefore the ADC is reading a value of 127, which for a 0V input is correct.

So could this be an issue of timing? The TLC5510I has a minimum high and low clock pulse duration of 25ns. To find out, we will use PulseView's cursors feature.

Putting the cursors around the trough, we can measure a low-duration of 40ns. So no problem there. There are no other constraints on the timing signal - they don't have to be symmetrical pulses.

So I kept repeatedly clicking Run to see if things would always run so smoothly. Suddenly this happened...

Lulwat?

The ADC seems to be having some kind of spaz-attack. So far I haven't been able to figure out exactly what has caused this. However, there do occasionally seem to be problems with the clock signal:

If this logic analyser is seeing what the ADC is seeing, this would explain a lot about why the ADC has gone crazy. The question to determine whether this is a problem with the fx2lafw firmware, or whether there is some signal integrity problem - and what would cause that.

By way of comparison, I decided to see how the USBee software suite would fair on the same problem. So I fired up my trusty Windows XP VM. Interestingly, it too exhibited a very similar behaviour.

I hadn't done any logic analysis with the official firmware before, so I wasn't sure if it would show some mistake I had made in the shape of my clock pulse. In the end it showed a clock signal that was almost identical - except the low-pulses were 30ns rather than 40ns.

Conclusion

I suspect even if I figure out the cause of the corruption, the device will never be a very good oscilloscope, if it has these kinds of ground bounce effects. This is the decay you can see in the analog trace above, and if there are issues with the design either on the digital or analog side, there may not be much I can do about them.

Having said that, even if the board does have digital signalling issues, attaching lots of logic analyser wires to it will make them much worse, so some of the issues we are observing here may have been self induced.

Any suggestions would be welcome.

But anyway, this is all beside the point. PulseView managed to come through this experiment without crashing and delivered some interesting insights.