Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=5Z9cBKU1wBQ

Two grey ticks. Still two grey ticks. The message has been "delivered" for a day and a half, and you're drafting theories. Before you settle on one, it helps to know exactly what each tick is actually reporting, because each one comes from a different machine.

What do the WhatsApp ticks mean?

Each tick is an acknowledgement that came back along the path your message took. Three different things can acknowledge it.

• Clock icon: your phone hasn't managed to send it yet. You're offline, or the app is still connecting.
• One grey tick: WhatsApp's server has your message. It's left your phone. Nothing is known about the recipient's phone.
• Two grey ticks: the recipient's phone has received it. Not the person: the device. The app on their phone fetched the message and sent a receipt back up to the server, which passed it to you.
• Two blue ticks: the recipient's app has shown it on screen in an open chat, and sent a read receipt back the same way.

That's it. Three machines reporting in: server, their phone, their chat window.

Why does WhatsApp only show one tick?

Because the message is sitting on the server waiting for their phone to collect it. WhatsApp can't push a message to a phone that isn't connected. One tick means: their phone has had no internet since you sent it, or it's off, or the battery's dead, or they've blocked you (a blocked sender's messages never get delivered, so they stay on one tick forever).

Delivery is the phone's job, not the server's. The server simply holds the message, encrypted, and hands it over the next time the phone checks in. If that never happens, after about 30 days the undelivered message is deleted.

Why two grey ticks but not blue?

Because delivery and reading are two different events, and only the first one is automatic.

Two grey ticks fire as soon as the app on their phone receives the message, which happens in the background, with the screen off, while they're asleep. It doesn't mean they looked at the phone. It means their phone was online. Hence "delivered at 03:14".

Blue requires the chat to be opened. Not the notification, not the chat list: the actual conversation, on screen, with the message visible. Until that happens, the receipt isn't generated, and it can't be, because the phone doesn't know they've read it.

Can someone read a message without the ticks turning blue?

Yes, in several ways, and this is the part the theories miss.

• Read receipts off. In settings, anyone can turn off read receipts. Their ticks stay grey forever, and in exchange they don't see yours either. (Group chats ignore this setting: in a group, the ticks go blue when every member has read it, which is why group ticks are so slow.)
• The notification. The whole message is visible in the notification shade and on the lock screen. No chat opened, no receipt sent.
• The widget / preview. Same thing: WhatsApp's home-screen widget shows messages without opening the chat.
• Airplane mode. Open the chat offline, read, close the chat, then force-quit the app before reconnecting. The read receipt never gets sent. It's a well-known trick precisely because it works.

So two grey ticks means "their phone has it". It does not mean "they haven't seen it".

Why can't the server just tell me when they read it?

Because the server can't read anything. WhatsApp is end-to-end encrypted: the message leaves your phone as ciphertext that only the recipient's phone can decrypt. The server shuffles sealed envelopes. It knows an envelope was accepted by a phone (delivery) only because that phone sent back a tiny signed receipt. It knows it was read only because the phone sent another one. The ticks are the phone volunteering information, which is exactly why the phone can also decline to.

Does WhatsApp notify screenshots or show who's online?

Screenshots: no, except for "view once" photos, where a screenshot is blocked rather than reported. Online status: yes, by default, "online" and "last seen" are visible, but both can be hidden in privacy settings, and hiding them doesn't affect the ticks.

The ticks are honest about what they know and silent about what they don't. One tick: the server has it. Two: a phone has it. Blue: a chat window had it open. Everything beyond that is you, not the app.

Quick reference: Clock = still on your phone · 1 grey = on the server · 2 grey = on their phone · 2 blue = chat opened. Grey for days = phone offline, or blocked. Delivered but never blue = read receipts off, or read from the notification.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=OtMpt9uBURs

You scroll, you refresh, you tap a bit too enthusiastically, and the app stops: "You are being rate limited." Or "Rate limit exceeded." Or nothing loads for a minute and then everything is fine again. You weren't banned. You weren't hacked. You hit a counter.

What does "rate limited" mean?

Rate limiting means a service has a cap on how many requests it will accept from you in a given window of time, and you went over it. Every time your phone asks the server for something (a feed refresh, a message send, a search) that's one request. The server keeps a tally per user, per account, per IP address, or per app. Cross the line and the next requests are refused until the window rolls over. Usually that's seconds; sometimes it's minutes; in Twitter's July 2023 "rate limit exceeded" episode, it was a hard daily cap on how many posts you could read at all.

On the web, the refusal has a name: HTTP status 429 Too Many Requests. Well-behaved servers send it with a Retry-After header saying how long to wait, and well-behaved apps read that header and wait.

Why do apps rate limit on purpose?

Four reasons, and they're all about the server, not about you.

Capacity. A server can handle a finite number of requests per second. If one user, one bot or one buggy script can send ten thousand a second, everyone else's experience depends on that one client's manners. A limit converts "first come, first served" into "everyone gets a fair share".

Cost. Each request costs CPU, bandwidth and sometimes a paid downstream call. A limit is a budget.

Abuse. Password guessing, scraping, spam, buying up every ticket. All of them look like one account doing something normal, far too fast. A limit of five login attempts a minute makes brute-forcing a password take years instead of hours.

Protection from mistakes. The most common thing that gets rate limited isn't an attacker; it's a developer's script stuck in a loop. A limit turns an outage into a 429.

How does the server count?

A few standard algorithms, from simplest to most common.

Fixed window. Count requests per minute. At the top of each minute, reset to zero. Simple, but it has an edge problem: 100 requests at 11:59:59 and another 100 at 12:00:00 is 200 requests in two seconds, all allowed.

Sliding window. Count requests in the last 60 seconds from right now. Fixes the edge problem at the cost of remembering timestamps.

Token bucket. The one most big services use. Imagine a bucket that holds, say, 100 tokens. Tokens drip into it at a fixed rate, 10 per second. Each request takes one token; if the bucket is empty, the request is refused. The beauty is that it allows bursts (you can spend all 100 at once if you've been quiet) while still enforcing an average (10 per second over the long run). Tapping refresh twenty times in a row is fine; doing it for a solid minute is not.

Leaky bucket. The mirror image: requests pour in, and they're let out at a steady rate. Smooths traffic instead of allowing bursts.

In practice the counters live in a fast in-memory store like Redis. The pattern for a fixed window is two commands: increment the key user:123:minute:1699999980 and set it to expire in 60 seconds. One round trip, a few microseconds, and every server in the fleet shares the same count.

Why does Discord rate limit me for sending messages?

Because sending messages is the thing bots abuse most. Discord's limits are per channel and per action: send too many messages, reactions or edits in a few seconds and the client tells you to slow down. It's the same reason a game won't let you spam chat. The limit is tuned so that typing like a human never trips it and pasting a loop does.

How do I avoid being rate limited?

If you're a user: stop tapping, wait the time it tells you, and if you're on a shared network (an office, a university, a VPN) remember that everyone behind that one IP address may be sharing a bucket.

If you're writing code against an API:

1. Read the limits in the docs before you write the loop.
2. Check for 429 and honour Retry-After.
3. Back off exponentially: wait 1 s, then 2, then 4, then 8, with a little random jitter so a thousand clients don't all retry at the same instant.
4. Cache. The fastest request is the one you don't make.

Rate limiting isn't the service being difficult. It's the service staying up, for you and for everyone sharing it, by making the one rule that scales: nobody gets to go faster than their share.

Quick reference: 429 = too many requests, try later · 403 = you're not allowed at all · 503 = the server itself is overloaded. Only the first one is about your rate.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=27VT0bMY5Zw

Blink is the first program everyone runs. Two lines: set pin 13 HIGH, wait, set it LOW, wait. An LED blinks and you move on. Which is a shame, because between digitalWrite(13, HIGH) and the LED lighting up there is an entire computer doing something you can actually follow, bit by bit, all the way down.

What is a microcontroller, in an easy way?

A microcontroller is a complete computer on one chip: processor, program memory, RAM and the input/output pins, all in one package, with no operating system. The Arduino Uno's chip is the ATmega328P, a 28-pin part with 32 KB of flash for your program, 2 KB of RAM, and an 8-bit CPU ticking at 16 MHz.

That's the whole difference between a microcontroller and a microprocessor. A Raspberry Pi's chip is a microprocessor: it needs external RAM, an SD card for storage, and Linux to boot, and it runs your program as one of hundreds. The ATmega runs one program, yours, starting the instant power arrives, with nothing in between. That's why an Arduino can toggle a pin in a few nanoseconds of certainty and a Pi can't promise anything about timing at all.

Is Arduino just C++?

Yes. The "Arduino language" is C++ with a library and a small amount of pre-processing. When you click Upload, the IDE takes your sketch, adds #include <Arduino.h> at the top, generates prototypes for your functions, and hands the result to avr-gcc, the standard GNU C++ compiler built for AVR chips. Your setup() and loop() are ordinary functions. The library supplies the main() you never see:

int main() {
  init();      // start the timers that millis() and PWM use
  setup();     // yours, once
  for (;;) {
    loop();    // yours, forever
  }
}

loop() repeats because it's called inside an infinite for. There's no scheduler, no operating system. When loop() returns, main() calls it again. Forever.

How does the code get onto the chip?

The compiler produces a .hex file: the raw bytes of machine code. Now it has to reach the chip's flash memory, and the chip is in the middle of running whatever was there before.

The IDE runs avrdude, which talks over the USB cable. On an Uno, USB doesn't go to the ATmega328P directly; it goes to a second, smaller chip (an ATmega16U2) that pretends to be a serial port. avrdude first toggles the serial port's DTR line, which, through a 100 nF capacitor, yanks the 328P's reset pin low for a moment. The chip reboots.

The first thing it runs after reset isn't your program. It's the bootloader (Optiboot), half a kilobyte of code living at the top of flash, which listens on the serial pins for about a second. If avrdude shows up speaking the STK500 protocol, the bootloader accepts the new program page by page, writes it into flash, and jumps to it. If nobody shows up, it jumps to whatever program is already there. That one-second pause after you press reset is the bootloader waiting to be told what to do.

What does digitalWrite actually do?

Now the LED. Your program is running. It calls digitalWrite(13, HIGH).

The 328P doesn't know about "pin 13". It has three ports, B, C and D, each a group of up to eight pins, and each port is controlled by a handful of memory-mapped registers. Pin 13 on the Uno board is wired to PB5: port B, bit 5. The Arduino library keeps lookup tables in flash that translate 13 into "port B, bit 5", and then does, in effect:

PORTB |= (1 << 5);   // set bit 5 of the PORTB register

PORTB is a byte at a fixed address in the chip's memory. Writing a 1 to its bit 5 is the entire operation. On the far side of that register, a pair of transistors connects the physical pin to 5 V (for a 1) or to ground (for a 0). Those transistors can source or sink about 40 mA at most, which is why you put a resistor in series with the LED: the pin is a switch, not a battery.

The lookup, the port read-modify-write and the checks inside digitalWrite() take around 4 microseconds on an Uno. Write to the register directly and it takes one clock cycle, 62.5 nanoseconds. Same bit, same transistors; the library just takes the scenic route so that "13" means the same thing on every board.

How does delay() work if there's no operating system?

Because the chip has hardware timers. init() set up Timer 0 to overflow every 1.024 ms and fire an interrupt: a hardware event that pauses your code, runs a tiny function that adds one to a counter, and resumes. That counter is millis(). delay(1000) just spins in a loop reading millis() until it has grown by 1000. The CPU is doing nothing useful during that second, which is why delay() is the thing you outgrow first.

What are the 28 pins of the ATmega328P?

Twenty-three are I/O: port B (8), port C (7, of which six double as the analogue inputs A0 to A5), and port D (8, including the two serial pins). The other five are power and ground, the analogue reference, and two for the 16 MHz crystal. Every "digital pin 7" or "A3" on the board is just one of those 23, given a friendlier name by the silkscreen and a lookup table.

That's the whole trip. C++ to machine code, serial cable to bootloader, bootloader to flash, digitalWrite to PORTB, bit 5 to two transistors, transistors to 5 V, 5 V through a resistor to an LED. Nothing in it is magic, and all of it is yours to touch.

Try it: Replace digitalWrite(13, HIGH); digitalWrite(13, LOW); in a loop with PORTB |= (1 << 5); PORTB &= ~(1 << 5); and watch pin 13 on a scope. The square wave goes from roughly 100 kHz to several MHz. That's the library's overhead, made visible.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=PJZhHA_2pz8

A logic gate has no memory. Change its inputs and the output changes; put the inputs back and it forgets anything happened. Yet every computer is built from logic gates, and computers remember things. The trick that makes it possible is one of the oldest ideas in digital electronics: take two gates and feed each one's output into the other.

What is a flip-flop circuit?

A flip-flop is a circuit that stores one bit. It has two stable states, 0 and 1, and it stays in whichever state it was last put into until something tells it to change. That's it. Registers, counters, RAM caches, the program counter in a CPU: they're all rows of flip-flops.

The simplest version is the SR latch (set-reset), and you can build it with two NOR gates.

How does an SR latch remember?

Wire two NOR gates so the output of each one goes to an input of the other. The remaining input on the first gate is S (set); the remaining input on the second is R (reset). Call the outputs Q and Q-bar.

• Pulse S high: Q goes to 1, Q-bar goes to 0. Release S. Q-bar is 0, which is one of the first gate's inputs, so the first gate keeps Q at 1. The gates are now holding each other in place.
• Pulse R high: the mirror image happens. Q goes to 0 and stays there.
• Both low: nothing changes. This is the "hold" state, and it's where the memory lives.
• Both high at the same time: both outputs go to 0, which breaks the rule that Q and Q-bar are opposites. This is the forbidden state. Release both inputs together and the latch lands on whichever gate happens to be a picosecond faster. Unpredictable, so you design around it.

The loop is the memory. Neither gate is doing anything clever; each one is just holding the other in a grip.

What does the clock add?

An SR latch responds the instant S or R changes. In a real system with thousands of these, you want them all to update at the same moment, not whenever their inputs happen to wobble. So you add a clock input and gate S and R through AND gates with it. Now the latch only listens while the clock is high.

Go one step further and make it respond only to the clock's rising edge, the instant it goes from 0 to 1, and you have a proper flip-flop. The classic way to do that is master-slave: two latches back to back, one that captures while the clock is low and one that passes the value on when the clock goes high. The result is a device that samples its input once per clock tick and ignores it the rest of the time. That's what lets a CPU run millions of operations in lockstep.

What are the different types of flip-flops for?

They all store one bit. They differ in how you tell them what to store.

D flip-flop (data). One input, D. On the clock edge, Q becomes whatever D was. No forbidden state, because there's only one input. This is the workhorse: a register is just eight D flip-flops sharing a clock. The 7474 (two per chip) and the CD4013 are the standard parts.

JK flip-flop. Two inputs like SR, but the forbidden state is given a job: J and K both high means toggle. Q flips to the opposite of whatever it was. The name is often credited to Jack Kilby, co-inventor of the integrated circuit, though the story is disputed.

T flip-flop (toggle). One input, T. If T is high on the clock edge, Q flips; if low, it holds. It's a JK with J and K tied together. Its superpower is that a toggling output runs at exactly half the clock frequency. Chain four of them, each clocked by the previous one's output, and you've built a 4-bit binary counter that counts to 15.

Why do real flip-flops have setup and hold times?

Because the input has to be steady for a few nanoseconds before and after the clock edge. Change D at the exact moment the clock rises and the master latch can be caught half-way between states, a condition called metastability, where Q hovers at a voltage that's neither 0 nor 1 for an unpredictable time before falling one way or the other. It's the same ambiguity as the SR forbidden state, and it's why a noisy button fed straight into a clock input gives you chaos: the bounce lands on edges at random.

Where will I meet one?

Everywhere you need to remember a single thing. A push-on, push-off light switch is a T flip-flop. The "seen" flag on a notification is a D flip-flop. A frequency divider is a chain of them. And the 2 KB of SRAM in an Arduino is sixteen thousand of them, each one two gates holding each other in a grip.

Try it: Breadboard an SR latch from one 74HC02 (four NOR gates; you need two). Put an LED on Q, pull-down resistors on S and R, and two buttons to 5 V. Tap S: the LED stays on after you let go. Tap R: it stays off. Press both and release: now you've seen the forbidden state decide for itself.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=1zLRvDnvohw

The circuit works on the breadboard. Then you move it to a proper board, make the wires tidy, and the microcontroller starts resetting itself every few seconds. Nothing in the code changed. What changed is that the chip lost the small, unglamorous capacitor that was sitting next to it by accident.

What is a decoupling capacitor?

A decoupling capacitor is a small capacitor wired between a chip's power pin and ground, as close to the pin as you can get it. Its job is to be a local reservoir of charge. When the chip suddenly needs current, the capacitor supplies it from a few millimetres away, instead of the chip having to pull it through the whole length of the power trace from the regulator.

That's the entire idea. The reason it matters is time.

Why can't the power supply just keep up?

A digital chip doesn't draw a steady current. Every time its clock ticks, thousands of transistors switch at once, and for a few nanoseconds the chip wants a sharp spike of current, then almost none, then another spike. A microcontroller running at 16 MHz does this 16 million times a second.

The copper trace between the regulator and the chip isn't a perfect wire. Every centimetre of trace has a little inductance, and inductance resists changes in current. Ask it for a spike that rises in a nanosecond and it simply can't deliver in time. For that nanosecond the voltage at the chip's pin sags. If it sags far enough, the chip's brown-out detector decides the power has failed and resets. Or an ADC reading comes back noisy. Or a bit flips in RAM and nothing makes sense.

A capacitor right at the pin doesn't care about the trace. The charge is already there. The spike is served locally, the trace tops the capacitor back up at its leisure, and the pin never sees the dip.

Decoupling capacitor vs bypass capacitor: is there a difference?

In practice they're the same part doing the same job described from two directions. "Decoupling" describes it from the chip's side: the chip is decoupled from the supply's slowness. "Bypass" describes it from the noise's side: high-frequency noise on the supply rail is given a low-impedance path to ground, bypassing the chip. One capacitor, both effects. Don't lose sleep over the terminology.

What value should a decoupling capacitor be?

The near-universal answer is 100 nF (0.1 µF) ceramic, one per power pin. It isn't a magic number; it's a good compromise. A ceramic capacitor in a small package has very little inductance of its own, so it can respond at the tens-of-MHz speeds where the spikes live. Larger values in bigger packages respond more slowly, which is exactly the wrong trade.

For chips that draw bigger gulps (motor drivers, radio modules, anything with a USB port) you add a bulk capacitor of 10 µF or more alongside, not instead. The 10 µF handles the slower, larger demands in the microsecond range; the 100 nF handles the nanosecond edges. Datasheets will tell you when the chip wants something specific. Most of the time: 100 nF ceramic, and a 10 µF nearby if the chip is hungry.

Where should decoupling capacitors be placed?

As close to the power pin as physically possible, with the shortest possible path to ground. This is the rule people break most, and it's the one that matters most. A 100 nF capacitor three centimetres away has three centimetres of trace inductance between it and the pin, which defeats the purpose. On a PCB that means the capacitor sits next to the pin, with a via to the ground plane right at its ground pad. On a breadboard it means the capacitor's legs go into the same row as the VCC pin and the nearest ground.

If a chip has several VCC pins, each one gets its own capacitor. They're not sharing one tank; each pin has its own trace inductance to defeat.

Which side of the capacitor goes to ground?

For the ceramic capacitors used for decoupling: it doesn't matter. They're not polarised; either leg can go to ground. The question comes from electrolytic capacitors, the cylindrical ones used for bulk decoupling. Those are polarised: the leg marked with a stripe (and usually the shorter leg) is negative and goes to ground. Fit one backwards and it will heat up, and in the worst case vent with a pop.

Are decoupling capacitors necessary?

Yes. The reason beginners doubt it is that circuits often work without them, for a while, on a breadboard, on a lucky day. The failures are intermittent: a reset every few minutes, a sensor reading that jitters, a crash that only happens when the motor starts. Those are the signature of a chip starved for a nanosecond at a time. Adding a 100 nF capacitor next to the VCC pin is the cheapest fix in electronics, and it's cheaper still to put it there before you need it.

Try it: Take any working Arduino project with a motor or a buzzer. Hook a scope (or a cheap USB one) to the 5 V pin and ground, then watch the trace when the motor starts. Now add a 100 nF ceramic across the same pins, as close as you can. The spikes shrink. That's the whole lesson, live.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=2x65kJwLQ5g

Every microwave, alarm clock and petrol pump counts with the same part: seven bars and a dot. Open it up and there's nothing clever inside. It's eight LEDs that happen to share one leg.

What is a 7-segment display made of?

Eight light-emitting diodes arranged in a figure-8: segments a to g around the outside and through the middle, plus dp, the decimal point. Each LED has its own pin on one side. On the other side, all eight are tied together to a single common pin. That sharing is the whole trick: it turns 16 wires into 9, and it's why the part comes in two flavours.

Common anode vs common cathode: what's the difference?

Electrically they're identical; only the direction is flipped. Mix them up and every segment appears inverted: you'll get a "0" when you asked for an "8". If you don't know which you have, put a 1 kΩ resistor in series with a 5 V supply, touch the common pin to one rail and a segment pin to the other, then swap. Whichever way lights it tells you.

Which segments make which digit?

With segments ordered a b c d e f g:

"8" uses all seven; "1" uses two. That table is literally what a BCD-to-7-segment decoder chip like the 7447 (for CA) or 4511 (for CC) has burned into it: four input bits in, seven segment lines out. If you watched the decoders Short, this is the same idea.

Do I need a resistor for each segment?

Yes, one per segment, not one on the common pin. A single resistor on the common leg is shared by however many segments are on, so "1" (two segments) is bright and "8" (seven segments) is dim, because the same current is being split seven ways.

Typical values: for a red display at 5 V with a ~2 V forward drop and 10 mA per segment, R = (5 − 2) / 0.010 = 300 Ω, so 330 Ω is the usual pick. Blue and white displays drop about 3 V, so 220 Ω.

Driving it from an Arduino

Wire a–g to pins 2–8 through 330 Ω each, common to GND (for CC). Then:

const byte SEG[7] = {2,3,4,5,6,7,8};        // a..g
const byte DIGIT[10] = {                     // bit 0 = a ... bit 6 = g
  0b0111111, 0b0000110, 0b1011011, 0b1001111, 0b1100110,
  0b1101101, 0b1111101, 0b0000111, 0b1111111, 0b1101111 };

void show(int n) {
  for (int s = 0; s < 7; s++)
    digitalWrite(SEG[s], bitRead(DIGIT[n], s));   // invert for common anode
}

For a common-anode part write !bitRead(...) instead.

How do multi-digit displays work with so few pins?

A 4-digit clock display doesn't have 32 segment pins; it has 8 segment pins and 4 common pins. The microcontroller lights digit 1's segments, turns on only digit 1's common, waits a millisecond, then does digit 2, and so on, cycling faster than your eye can follow. That's multiplexing, and the 1 ms flicker is why phone cameras sometimes catch clocks with missing digits.

Try it: Count 0–9 with a one-second delay. Then remove the resistor from segment a and watch it burn brighter than the rest: that's the current-sharing problem in one LED.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=zN1rbiRQHAI

The 555 is the chip in a million blinking-LED kits, and it is called 555 for a boring reason: the three 5 kΩ resistors inside it. Understand those three resistors and the whole chip stops being magic.

What's inside a 555?

Four things:

1. A voltage divider of three equal resistors across the supply. That creates two reference voltages: ⅓ Vcc and ⅔ Vcc.
2. Two comparators. One watches the threshold pin (pin 6) against ⅔ Vcc. The other watches the trigger pin (pin 2) against ⅓ Vcc.
3. A flip-flop (a 1-bit memory) that the comparators set and reset.
4. A discharge transistor (pin 7) that the flip-flop switches on and off, plus an output driver (pin 3) that can source or sink around 200 mA.

That's it. Everything the 555 does is: a capacitor voltage crosses ⅓ or ⅔ of the supply, a comparator flips the memory, the memory changes the output and the discharge transistor.

Astable mode: why it blinks

Wire a capacitor C from pin 6/2 to ground, charge it through R1 + R2 from Vcc, and let the discharge pin (7) empty it through R2 alone.

• Capacitor charges up through R1 + R2. When it reaches ⅔ Vcc, the threshold comparator resets the flip-flop: output goes LOW, discharge transistor turns on.
• Capacitor now drains through R2 into pin 7. When it falls to ⅓ Vcc, the trigger comparator sets the flip-flop: output goes HIGH, discharge turns off.
• Repeat forever.

The capacitor just bounces between one third and two thirds of the supply, and the output is a square-ish wave that follows it.

f  = 1.44 / ((R1 + 2·R2) · C)
t_high = 0.693 · (R1 + R2) · C
t_low  = 0.693 · R2 · C

Example: R1 = 1 kΩ, R2 = 100 kΩ, C = 10 µF → f ≈ 0.72 Hz, a lazy blink roughly once a second, with the LED on slightly longer than off. Because the capacitor charges through R1 + R2 but discharges through R2 only, the high time is always longer than the low time; put a diode across R2 if you need a true 50 % duty cycle.

Monostable mode: one press, one timed pulse

Tie pin 2 high through a resistor and pull it low briefly with a button. The trigger comparator sets the flip-flop, the output goes HIGH, and the capacitor starts charging through a single resistor R. When it reaches ⅔ Vcc the output drops. One press gives one clean pulse of:

t = 1.1 · R · C

R = 100 kΩ, C = 10 µF → 1.1 s. This is the "stay on for a while" circuit: stairwell lights, a hardware debounce, a timed relay. Notice the ⅓-Vcc trigger threshold means a bouncing button is ignored once the timer is running: the 555 is a debouncer by construction.

Why doesn't the supply voltage change the timing?

Because the thresholds are fractions of Vcc, not fixed volts. Run it at 5 V and the capacitor swings 1.67 → 3.33 V; run it at 12 V and it swings 4 → 8 V. The RC curve to go from ⅓ to ⅔ of any target takes the same time, so the frequency stays put from 4.5 V to 16 V. That's the clever part of the design.

Common mistakes

• Pin 5 (control) left floating. Add a 10 nF capacitor to ground or the thresholds pick up noise.
• Electrolytic capacitor backwards. The stripe goes to ground.
• Expecting a perfect square wave. The standard astable can't go below ~50 % duty cycle without the diode trick.
• Using a bipolar NE555 on a 3.3 V board. Use the CMOS version (LMC555 / TLC555), which runs from 2 V and draws far less current.

Try it: Build the astable with R1 = 1 kΩ, R2 = 100 kΩ, C = 10 µF and an LED (with a 330 Ω resistor) on pin 3. Then swap C for 1 µF. The blink gets ten times faster and nothing else changes: that's the formula in your hands.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=nt6GSc6CDhA

Your counter sketch should add one for every press. Instead it jumps by two, sometimes three, and occasionally one. The code is right. The problem is physics: a push button is two pieces of metal slamming together, and they bounce.

What is switch bounce?

When the contacts meet, they don't close once and stay closed. They hit, spring apart a tiny bit, hit again, and settle, all within roughly 1 to 20 milliseconds depending on the switch. On an oscilloscope the pin doesn't go cleanly from HIGH to LOW; it looks like a short burst of noise before it settles.

A microcontroller reads its pins millions of times a second, so to it that burst is several clean presses in a row. Your counter faithfully counts every one.

The release bounces too, which is why an "on release" handler can misfire as well.

Fix 1: the delay (quick, blocking)

The simplest fix: when you see the first edge, wait longer than the bounce could last, then read again.

if (digitalRead(BTN) == LOW) {   // pressed (pull-up wiring)
  delay(30);                     // let it settle
  if (digitalRead(BTN) == LOW) count++;
  while (digitalRead(BTN) == LOW) {}  // wait for release
}

It works, and it's fine for a demo. The cost is that delay() freezes everything else: no LED animation, no sensor reads, nothing, for 30 ms per press. In anything real that matters.

Fix 2: millis() (non-blocking, the usual answer)

Instead of stopping, remember when the pin last changed, and only accept a new state once it has been stable for a while:

const unsigned long DEBOUNCE = 30;  // ms
int stable = HIGH, lastRaw = HIGH;
unsigned long lastChange = 0;

void loop() {
  int raw = digitalRead(BTN);
  if (raw != lastRaw) { lastChange = millis(); lastRaw = raw; }
  if (millis() - lastChange > DEBOUNCE && raw != stable) {
    stable = raw;
    if (stable == LOW) count++;     // one clean press
  }
  // everything else keeps running
}

Every bounce resets the timer, so the state only updates after the contacts have been quiet for 30 ms. The loop never blocks. This is the pattern inside every "Bounce" library.

Fix 3: a capacitor (hardware debounce)

If you'd rather not debounce in code, or the signal feeds something with no code (a 555, a flip-flop, a clock pin), slow the edge down in hardware. With a pull-up in place, add a capacitor from the pin to ground:

• 10 kΩ pull-up + 100 nF capacitor → time constant RC = 1 ms
• The capacitor charges and discharges through the resistor, so the bounces get smoothed into one slow curve.

The catch is that a slow curve through the input threshold can itself trigger multiple times on a plain logic input. Pair it with a Schmitt trigger input (a 74HC14, or a microcontroller pin with hysteresis) and the ramp becomes one clean edge. That's the textbook hardware debounce: RC plus Schmitt.

How long should the debounce time be?

Longer is safer but caps how fast a human can press: 50 ms allows 20 presses a second, which is more than anyone's thumb manages.

The two bugs beginners mix up: Random readings while nobody is pressing = a floating input (fix: pull-up resistor). Several readings from one press = bounce (fix: this guide). Different problems, both cheap to fix.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.

Watch the one-minute version first, then read on for the numbers.

https://www.youtube.com/watch?v=GGGjqbI5YEM

You wire a push button to an Arduino pin, write a sketch that prints the pin, and the serial monitor shows 1 0 0 1 1 0 1 while nobody is touching anything. The button isn't broken. The pin is floating, and a pull-up resistor is the two-cent fix.

What is a floating input?

A digital input pin is a very high-impedance probe. It draws almost no current, which is great for measuring, but it means the pin has no opinion of its own. If nothing is connected to it, or the only thing connected is an open switch, the pin's voltage is whatever stray charge, nearby wires and your finger's electric field make it. The chip still has to decide "HIGH or LOW?" every time you read it, so it rounds that noise to a 1 or a 0, and you get random values.

A floating pin is not "zero". It is undefined.

What does a pull-up resistor actually do?

A pull-up is a resistor from the input pin to the supply voltage (5 V on an Uno, 3.3 V on an ESP32). With the switch open, no current flows, so there is no voltage drop across the resistor and the pin sits at the supply voltage: a clean, definite HIGH.

Press the button and the switch connects the pin straight to ground. Now the pin reads LOW, and the resistor's only job is to limit the current flowing from the supply to ground through the closed switch. With 10 kΩ and 5 V that is 0.5 mA, which is nothing.

So the resistor "pulls the pin up" to HIGH by default, and the button overrides it by pulling the pin down to LOW. Pressed reads 0, released reads 1. That inverted logic surprises beginners, but it's the normal convention.

What value should a pull-up resistor be?

Anything from about 1 kΩ to 100 kΩ works; 10 kΩ is the default for good reasons:

A stronger pull-up (lower resistance) holds the pin HIGH more firmly against noise and charges the wire's capacitance faster. A weaker one (higher resistance) saves power. For a button on a short wire, 10 kΩ is the answer.

Can I use the built-in pull-up instead?

Yes. Most microcontrollers have internal pull-ups you can switch on in software. On Arduino:

pinMode(2, INPUT_PULLUP);   // internal ~20–50 kΩ pull-up on pin 2
int pressed = digitalRead(2) == LOW;

The internal pull-up is weak (20–50 kΩ on the ATmega328P), so it is fine for a button on the board but less reliable on a long cable in a noisy environment. For I²C lines, which need a specific pull-up to meet timing, use external resistors (typically 4.7 kΩ).

Pull-up or pull-down: which should I use?

A pull-down is the mirror image: resistor to ground, button to the supply, pressed reads HIGH. It reads "naturally" but is less common because:

• Built-in pull-ups are everywhere; built-in pull-downs are rarer.
• Open-drain devices (I²C, many sensors, reset lines) can only pull down, so the resting state must be pulled up.
• Active-low conventions (RESET, CS) are the industry default.

Use a pull-down when the logic genuinely reads better that way and you're wiring the resistor yourself. Otherwise, pull-up.

Try it: Read a pin with nothing connected and print it 20 times a second. Then touch the pin with your finger. Then add a 10 kΩ pull-up. You'll see random → wandering → steady 1.

Why the button still glitches when you press it

Once the pin is pulled up you'll notice a second problem: one press sometimes registers as two or three. That isn't floating any more; it's the metal contacts bouncing for a few milliseconds. That's the next guide: button debouncing.

DigiCirq makes short animated explainers on electronics, Arduino and the systems behind everyday apps. New guides every week: youtube.com/@digicirq.