Switch chattering and low voltage MCUs

[pomk]

Hi!

I posted this too gh already, but thought that I should post here as well, as no one there seems too have anything to say.

I have started to experience some strange behavior with my bluetooth board. As the batteries gradually run out of juice, the switches start to chatter more and more. At first I thought that the doubled letters were because of the voltage dropping too much and the MCU not finding the 'ack' packet on the first try, but that was confirmed not to be the case as modifying the matrix scan rate seems to mitigate the problem for the time being.

Has anyone here run low voltage & low current chattering tests on gateron switches? Cherry MX is rated to work with 2V, but what about gateron?

Does someone have good ideas on how to solve the problem without having a 30ms software debounce? One thing that came to mind was to switch from column-switch-diode-row detect high scheme to row-diode-switch-column detect low scheme and thus win some voltage margin from the diode (0,5V forward voltage).

I'm now at 5 months of daily usage using 2xAAA batteries, which now read about 1,15V. First 4 months were completely problem free. The batteries should still give me about 6 to 10 months more if they function according to duracell spec.

[Phenix]

Which board?

[pomk]

Custom, using nrf51 from nordic semi.

[monkeyplusplus]

Daaaaaamn, cool board! A couple questions, and a pre-apology that I'm not knowledgeable about this stuff:
What is your current debounce time? 5ms? All the Bluetooth boards I've seen use lipo batteries. Would those work better? Can a different approach to power management help? What firmware are you running? I'm just getting into designing PCBs (here's mine: http://i.imgur.com/HbyNkj7.jpg), and I would love to find more information about integrating bluetooth with something like this nrf51.

[Phenix]

That pcb looks good. did you published the files? (I am interested in getting an Bluetooth board one day, but I can't design sonething..)

[HuBandiT]

These are far from short-term solutions, but:

Any reason you don't do away with the diodes and do a 1×N "matrix"? Your MCU would not have to continuously scan, but could spend most time in very low-power sleep, only to be woken up when a change on a pin (key) happens, run debounce filtering to register the key, then go back to sleep.

Also, incorporate a solar panel into the design; either to trickle-charge the (rechargeable) batteries so that you (almost) never need to recharge them; or if you can tolerate a bigger solar panel, then do away with batteries and have solar as the main source backed by a supercapacitor (EDLC) for rainy days. Linear seems to have some nice MPPT and energy-harvesting chips that could be useful in a design like this.

[pomk]

The power consumption I have when no keys are pressed is already pretty low at 10uA. I use interrupts set on the rows and set all columns high, that way when any key is pressed the MCU wakes up and sweeps the matrix normally. Then when all keys are up again the interrupt scheme is resumed automatically.

I plan to do a group buy soon-ish using this PCB and a wooden monoblock case, but I wish to fix all of these random bugs first.

An easy fix to this problem would be to just put a low q high efficiency buck-boost chip in the power line, but that would negatively impact the battery life quite a bit.

[pomk]

Daaaaaamn, cool board! A couple questions, and a pre-apology that I'm not knowledgeable about this stuff:
What is your current debounce time? 5ms? All the Bluetooth boards I've seen use lipo batteries. Would those work better? Can a different approach to power management help? What firmware are you running? I'm just getting into designing PCBs (here's mine: http://i.imgur.com/HbyNkj7.jpg), and I would love to find more information about integrating bluetooth with something like this nrf51.

your board looks clean, well done! I use a custom firmware for now, but plan on maybe porting kiibohd on the chip. It is a cortex m0 chip, so the porting process should be quite straightforward. I currently have no debounce, as the scan interval is 10ms, which is the best BT4.0 can offer anyway. Lipo would need a lot more components and the battery life could not be as good, the voltage would be nice and solve this problem however.

[pomk]

I tried the reverse sensing scheme, but it does not work at all as the logical high is very close to the forward voltage of the diodes (0,7V vs 0,5V).
Right now the best options I see are a buck-boost setup or trying to find diodes with a very low forward voltage. Some glass diodes have as low as 0,3V forward voltage at low currents, which would get me about 0,2 V of more time to play around using the batteries.

[beltet]

I'm not certain this is appliable to your project but almost read all in this document:
https://www.google.se/url?sa=t&source=w ... 39HrbBf4SQ

And what they said there that some switches(not likely on gaterons is my opinion) they can have a denouncing effect for quite long(150ms). Maybe try cherries instead?
And what I understood is that at low voltages the MCU can trigger high a little bit easier. But this was just my interpretation.
There are hardware tips on debouncing, and software tips aswell, seems like increase the read time is a solution. But I have not read the last pages.
Do you have a oscilloscope that you can check the debouncing effect with?

If you you think I'm talking shit, just ignore me. I'm a really NOOB at this and have very little practical experience on the subject.

[hasu]

pomk, great work! and interesting problem.
Running at 1.15V is already out of spec but it can seem to still run somehow, nice. In that situation diodes forward voltage could be higher than MCU V[sub]IL[/sub] max(0.3VDD), this is root of the problem, right?

I think you can use power fail comparator to detect low voltage of battery and alert user, stop controller or etc..
https://devzone.nordicsemi.com/question ... ly-is-18v/

[DMA]

Those.. diodes.. so.. HUGE..
What are those?

Schottky diodes to the rescue! You can find ones with forward voltage of 0.28V.

[pomk]

pomk, great work! and interesting problem.
Running at 1.15V is already out of spec but it can seem to still run somehow, nice. In that situation diodes forward voltage could be higher than MCU V[sub]IL[/sub] max(0.3VDD), this is root of the problem, right?

I think you can use power fail comparator to detect low voltage of battery and alert user, stop controller or etc..
https://devzone.nordicsemi.com/question ... ly-is-18v/

I am running two batteries, and they both read 1,15V, making the total voltage 2,3, which is well within MCU spec. I guess I should have been more explicit in the description. The MCU runs just fine, no problems there, the only thing that does not work reliably at these sub 2,5V levels is the matrix scanning. Because the matrix scanning problems are key specific, and can be fixed by swapping the switches, I'm thinking that it has to be just extended chattering and or oxidation on some switches which just becomes a more pronounced problem at low voltages.

I'm not certain this is appliable to your project but almost read all in this document:
https://www.google.se/url?sa=t&source=w ... 39HrbBf4SQ

And what they said there that some switches(not likely on gaterons is my opinion) they can have a denouncing effect for quite long(150ms). Maybe try cherries instead?
And what I understood is that at low voltages the MCU can trigger high a little bit easier. But this was just my interpretation.
There are hardware tips on debouncing, and software tips aswell, seems like increase the read time is a solution. But I have not read the last pages.
Do you have a oscilloscope that you can check the debouncing effect with?

If you you think I'm talking shit, just ignore me. I'm a really NOOB at this and have very little practical experience on the subject.

You are correct that the logical high is at 0,7 VDD, which means that it scales with the input voltage of the chip. This also means that if the forward voltage of the diode is higher than 0,3 VDD, there wont be any signals to see, ever. This might have also been a slight mistake in the design I have, although at 1,8 VDD level I would still be (barely) over this limit when using the diodes I have on the board.

Those.. diodes.. so.. HUGE..
What are those?

Schottky diodes to the rescue! You can find ones with forward voltage of 0.28V.

They are just general purpose diodes in a SMA package, forward voltage is 0,5 at low currents and they are easy to solder. If we think that the chattering is just noise, and that by switching the diodes the noise floor would be higher, it might work better as the closed switch would more often be interpreted as a logical high. It would not however fix the underlying problem of the switches chattering like crazy in the first place. Maybe I should try with cherries as they are rated to work within spec even at 2 volts.

I should just run some oscilloscope tests with the switches I have swapped out in order to see how they actually perform at given voltage levels and at 0,5 mA current.

[DMA]

It would not however fix the underlying problem of the switches chattering like crazy in the first place.

What does the scope see? This may just be an artifact on the MCU side - because, for example, supply's internal resistance increased so much those extra couple milliamps from the closed switch drop battery voltage too much.

Also you have radio in there - which adds to the picture, because once key is pressed transmitter wakes up and sucks quite a lot of juice.

[pomk]

It would not however fix the underlying problem of the switches chattering like crazy in the first place.

What does the scope see? This may just be an artifact on the MCU side - because, for example, supply's internal resistance increased so much those extra couple milliamps from the closed switch drop battery voltage too much.

Also you have radio in there - which adds to the picture, because once key is pressed transmitter wakes up and sucks quite a lot of juice.

I have yet to scope this. I try to make time next week at work so I can justify spending time measuring hobby projects using company tools.
The radio and matrix scanning are never active at the same time, and the voltage level should be pretty stable as I have a 220uF ceramic cap near the power input. Initially I thought that this was related to the supply voltage dropping due to load, but I could not detect any difference in behavior when I changed 1uF cap to 220uF cap. Also if this was transmit related (of which I'm pretty sure it is not), the problem would be random between all the keys, and would not be fixed/changed by soldering a better functioning replacement switch. The batteries can still output over 0,5 A of current.

[DMA]

It's nice to have a scope at work..

But yeah, if replacing a switch solves the problem - it's definitely not that.

..since you already have a truckload of diodes in there - may be it would be easier to just add small capacitors in parallel to the switches? Hardware debouncing!

[pomk]

Debouncing is what you do when you use shitty switches or need to have a very high timing accuracy. The switches are bouncing around as much as 30ms, which would make the HW debouncing circuit quite difficult to implement by using just a capacitor. Also, where would the capacitors go in the matrix without introducing ghosting?

[DMA]

parallel to the switch. The idea is that that closing switch discharges the cap, and when it bounces open - cap's charging maintains the current.
So no matter how long it bounces in total - only time between individual bounces matters. Because the next switch close discharges the cap again.

Ghosting is prevented by diodes, same as before.

[pomk]

I'm not sure I follow. There is not enough time to load the cap in the first place while scanning (about 72ns per column). And if the cap is large, would it not effectively cause ghosting when the next column is read if there is some lingering charge left?

[DMA]

The whole idea is that it's not enough time to charge the cap between bounces.

As for ghosting - you have a diode in series with every key. Shouldn't it prevent the charge flowing back to the scan line? And if it does - it shouldn't matter how much charge there is, because there wouldn't be any current with no return path?

Anyway, it's quite easy to test - you have the bouncing switch, put, dunno, 0.1uF across it and see? I would say 1uF - but I'm worrying about your GPIO's health.

[pomk]

My matrix is set up as column-switch-diode[->]-row. Now if a capacitor is added in parallel to the switch, it will not charge unless it is open, as if it is closed both of its legs would be in the same potential. If the switch is open, then it will take some charge as one of its legs is on gpio-out-high, while the other one is in gpio-in-pulldown. This charge will escape through the first key on that column which is pressed after the column has been scanned, no?
Looking at some scope tests by hasu (https://geekhack.org/index.php?topic=42385.0), the switch is more than likely to be either on or off for the entire 72ns duration, instead of switching between the two multiple times in that period. (72ns is a very short time, but still an order of magnitude longer than what it takes to fill the capacitance of the trace. I have also tried to add a considerable delay between the column being set and the rows being read with no visible effect).

[DMA]

Bouncing is when on pass 1 you have open switch, on pass 2 it's closes, [then on pass 3 it's open again, on pass 4 closed again] times N, and then you have a "closed switch" steady state. You want to skip those repetitions and go straight to the steady state. The cap pins the switch closed from the MCU standpoint while bouncing happens.

It doesn't matter if switch toggles while you're reading it - _something_ will be read anyway, 1 or 0, doesn't matter. You'll figure out where it landed on the next pass anyway.

You are right though - the net effect in your case will be that the column will stay energized and this will screw up the measurements on other columns. If the diode was on the column side - it would make the difference, because cap would be topped up by the strobe, but wouldn't be able to discharge thru the neighboring switch.

Strobe the rows? As a side-effect you'll scan faster. Will require resoldering all those diodes though, I'm afraid.

[pomk]

The diode being after the switch gives me more voltage over the switch, which is probably the underlying problem here.

[DMA]

They're in series. The voltage across the switch is the same no matter where diode is.
Or I'm missing something again?

[pomk]

I'm no electrical engineer, but I was under the impression that a diode drops voltage based on what the forward voltage of the diode is? I thought that it drops as it passes through the diode, but I'm quite possibly wrong here.

Edit: I am an idiot, but I still dont get how the capacitor would work as a debouncer when used parallel to the switch.

[DMA]

Nah, it's still 0.6v for your standard silicone diode. It varies by current, but not much.

I'm also not an electrical engineer - though I've got some experience recently trying to make a capacitive keyboard controller.

Anyway, you're measuring voltage at the end of [+]-GPIO pin - Rtrace (column) - switch -[>]- Rtrace(row). It's the same as [+]-GPIO pin - Rtrace (column) -[>]- Rtrace(row).
And this voltage is a voltage drop on the resistor consisting of the internal pin circuitry.

And if you're not pulling down the row lines between strobes you can see some pretty strange stuff, btw - because the whole row line is a capacitor. It is not a problem when something drives your input up _and_ down - that capacitor is charged/discharged by the driver - but with diodes you only drive the line up, and the main discharge path is thru the pin.

Analog is a bitch. And if you dig a bit - even digital circuits are analog. And the larger they are - the more analog they are

[pomk]

Each pin used by the matrix is either a pulldown input or forced output of high / low. High for the column being strobed and low for others. The capacitance of a single column-diode-row set is about 35pF.

[vvp]

I would rather try to find some schottky diodes with lower forward voltage (at the current corresponding to your pull ups/downs) before increasing capacity. Increasing capacity will increase power consumption of the matrix scanning and you probably do not want that.

[pomk]

Even at best that would give me 0,2 volts more space, which translates to around 20% more capacity out of the batteries. I think I'll just add a third battery to the next prototype, a high efficiency low q DC/DC converter to drop the voltage to a stable ~3 volts and forget about the problem.
As for the two I have already built, I'll just swap batteries more often or add a LTC3106 high efficiency low q buck/boost.

[vvp]

Yeah, if the better diodes are not enough then I would try to improve the power source too.