adamfk / bouncy-button-data

Creative Commons Zero v1.0 Universal
3 stars 0 forks source link

434ms - push button - JUDCO 1024-2 (332nF parallel cap & scope) #17

Open adamfk opened 6 months ago

adamfk commented 6 months ago

Please note:

Experiment

Ran this experiment right after https://github.com/adamfk/bouncy-button-data/issues/16. Connected cap and oscilloscope to grab captures. I think too much use with the cap in parallel was causing damage to the switch. Very long bounces.

I also made a note that tests 119-122 should be ignored. The button kept glitching when held down. Never had this problem before. Sign of damage?

Switch Info

See https://github.com/adamfk/bouncy-button-data/issues/6



Test Session 1

Setup

Property Description
Arduino model Uno (DIP)
Pull-up resistor Arduino internal (measured 35.7k ohm)
Switch wires connection Wire leads
Measure switch's ON resistance 0.5 ohms
Anything else connected? 332nF and oscilloscope

Test Setup Photos: Same as https://github.com/adamfk/bouncy-button-data/issues/16

image

image

The scope was connected just above Arduino headers. You can see some of the jumper wires have extra insulation stripped off for this.



Results

📄 Raw Data

332nf.txt

You can graph/analyze the data here.

🖼️ Summary Image

image

image

🕵️ Your Observations (optional)

Continuing on from what we saw at the end of testing https://github.com/adamfk/bouncy-button-data/issues/16, we see release max bounces are 3x that of press max bounces.

Before adding the cap, presses would bounce more.

NOTE! Adding a cap, delays the release bounce times by about 10ms (see below image) before MCU notices. The time constant for the 332nF capacitor to charge up through 35.7k ohm resistor is around 11.85ms.

Discharge time constant calculation: 332nF (DMM measured) x 0.3 ohms (I can't measure very low on my DMM) = 99.6ns.

Below capture shows charging up time constant. Estimate at 11.98 ms for 1 tau.

image





Some Oscilloscope Captures

Zoomed in far:

These were a pretty common response: image

image

Every few times, we would get a response like this though:

image

image

20 us/div

This one was really cool. It really shows that there was a super brief contact, and then didn't contact again until around 97us. image

Here's the Arduino recorded data:

Press the button (it is currently released == logic high)
<test>
sw version: 0.3.3
<buffered_events>
pin: 1, rising_edges: 0, nsec: 0, log: 1, event: 1
pin: 1, rising_edges: 1, nsec: 687, log: 2, event: 2
pin: 0, rising_edges: 0, nsec: 69812, log: 3, event: 3
</buffered_events>
logs used: 3/350
section type: "Normal"
section count: 66
test id: 66
duration: 69 us, 812 ns
</test>

Super interesting to note (and maybe problematic) that Arduino sketch didn't record what we expected. If we go 69us back from large falling edge, we see a small noise spike. Could that have been the initial trigger recorded by the Arduino?

image

The initial noise at the moment of press just barely went below the approximate voltage required to read a low signal (2.145 vs approx 2.2v): image


The transition noise and ringing was detect on this one: image

<test>
sw version: 0.3.3
<buffered_events>
pin: 1, rising_edges: 0, nsec: 0, log: 1, event: 1
pin: 0, rising_edges: 2, nsec: 812, log: 2, event: 2
pin: 0, rising_edges: 1, nsec: 2375, log: 3, event: 3
pin: 1, rising_edges: 1, nsec: 11153437, log: 6, event: 4
pin: 0, rising_edges: 0, nsec: 29146750, log: 12, event: 5
</buffered_events>
logs used: 12/350
section type: "Normal"
section count: 68
test id: 68
duration: 29 ms, 146 us, 750 ns
</test>

Another interesting one: image

Arduino missed the first low transition. It triggers on the middle pulse.

<test>
sw version: 0.3.3
<buffered_events>
pin: 1, rising_edges: 0, nsec: 0, log: 1, event: 1
pin: 1, rising_edges: 1, nsec: 687, log: 2, event: 2
pin: 1, rising_edges: 2, nsec: 2250, log: 3, event: 3
pin: 1, rising_edges: 1, nsec: 19125, log: 4, event: 4
pin: 1, rising_edges: 1, nsec: 32437, log: 5, event: 5
pin: 0, rising_edges: 1, nsec: 40875, log: 6, event: 6
pin: 1, rising_edges: 1, nsec: 43375, log: 7, event: 7
pin: 0, rising_edges: 3, nsec: 45875, log: 8, event: 8
pin: 0, rising_edges: 1, nsec: 137562, log: 9, event: 9
</buffered_events>
logs used: 9/350
section type: "Normal"
section count: 76
test id: 76
duration: 137 us, 562 ns
</test>

image

Those all line up well except for the 19us. There's no trace of anything on the scope that explains that. Note that it was picked up by the rising edge hardware counter. The picoscope was sampling every 40ns (25 MS/s). It is only a 10 MHz scope so it is possible that it missed it.


This one the Arduino captured perfectly: image

<test>
sw version: 0.3.3
<buffered_events>
pin: 1, rising_edges: 0, nsec: 0, log: 1, event: 1
pin: 1, rising_edges: 1, nsec: 687, log: 2, event: 2
pin: 1, rising_edges: 1, nsec: 168500, log: 3, event: 3
pin: 0, rising_edges: 1, nsec: 467875, log: 4, event: 4
</buffered_events>
logs used: 4/350
section type: "Normal"
section count: 115
test id: 115
duration: 467 us, 875 ns
</test>