Ringing GPIO in0 and in1

[inlevis]

I observe JLS GPIO inputs ringing quite often, here is example screenshot.

In most cases it is not much of a problem, since ringing lasts few usec and I can filter it out in digital post-processing. But sometimes when I’m trying to capture short pulses, like one that marked by double-circle, it becomes less obvious. If I connect digital scope to the same pins I see clean waveforms with single transitions and no ringing.
Here is zoom to ringing edges for another run, showing one rising edge on in0 and one falling edge on in1

[mliberty]

Hi @inlevis!

I have a few questions to help figure things out:

1. Are you using a Joulescope JS110 or JS220?
2. Am I right in estimating that you want to measure a pulse that only lasts for under 10 µs?

[inlevis]

1. This is JS220.
2. No, I’m not measuring short pulses. I use pulse as substitute to an edge, just as a mark on a time line. I measure time between edges which is much longer than 10us. However, if I was measuring pulse duration, then it might be difficult to do if pulse is shorter 10us.

[mliberty]

Thanks for the info. With the JS220, are you connecting both the Vref and at least one GND signal to your target board?

The JS220 uses the external Vref by default, which must be connected. Note that the Joulescope UI 0.10.x does not yet have full support for the JS220. We are working on a version that will, but it is not yet available. The different internal reference voltages only apply to the JS110, not the JS220.

[inlevis]

I connected both GND wires but did not connect Vref, my bad. With Vref wire connected to +3.3V on my board I still observe ringing, though not as bad as without Vref connected. Here is example screenshot

[mliberty]

Hi @inlevis - It does not look like connecting Vref made much difference. It tends to get very, very weakly pulled to 3.3V, so it was probably working correctly originally.

Summary

The JS220 FPGA packs bits in a little-endian order, but the host software (as of Joulescope UI 0.10.13) unpacks bits in big-endian order. We need to fix the host software.

We are currently working on the next major Joulescope UI release that also completely changes how data is processed. We will test this release to make sure the GPI edges do not have glitches.

Investigation

I took a closer look. I configured the JS220 EVK to output a 10 kHz square wave:

from machine import Pin, PWM
from evk import Pins

Pin(Pins.EXT0, Pin.OUT, value=0)
Pin(Pins.EXT1, Pin.OUT, value=0)
Pin(Pins.EXT2, Pin.OUT, value=1)

p = PWM(Pin(Pins.EXT0))
p.freq(10000)
p.duty_u16(0x8000)

Using the provided JS220 GPIO cable harness, I then connected:

• EVK.EXT0 to JS220.IN0
• EVK.GND to JS220.GND
• EVK.EXT2 to JS220.Vref

Here is what the Joulescope UI 0.10.13 displays with JS220-000415:

which seems pretty close to what you see.

I then slightly unplugged the cable harness from the JS220 GPIO connector so that I could probe the bare metal for the connector pins. I probed IN0 using my Saleae Logic Pro 16, and it shows:

I definitely have a little noise in the setup, but the edge looks clean enough. I quickly confirmed the clean edges with my Rigol DS1102E bench oscilloscope:

I then connected a bare JS220 main board PCB in the same configuration and measured the IN0 signal on the isolated side:

The edges look very clean. So it, looks like the glitches are caused by the digital processing, either on the JS220 FPGA or in interpreting the data. I inspected the USB traffic, and found edges like this:

The bits are in little-endian order. The host code unpacks them in joulescope.v1.sample_buffer, line 115 using data = np.unpackbits(data). However, this is big-endian by default. It should be data = np.unpackbits(data, bitorder='little'). Here is the fix.

[mliberty]

Hi @inlevis - This should be fixed in Joulescope UI 1.0. Please post again if you continue to see the issue!