Borbin the 🐱

Warum 50 Ohm? Die Physik hinter dem HF-Standard

Wer zum ersten Mal ein Koaxialkabel in der Hand hält und auf dem Aufdruck "50 Ω" liest, fragt sich unweigerlich: Warum ausgerechnet 50? Die Antwort liegt in einem eleganten Kompromiss zwischen zwei physikalischen Optima und etwas Militärgeschichte.

Das Ergebnis vorweg

Für ein Koaxialkabel mit Luft als Dielektrikum gibt es zwei physikalisch optimale Wellenwiderstände, je nach Ziel:

Das geometrische Mittel liegt bei:

$$Z_0 = \sqrt{77\,\Omega \times 30\,\Omega} \approx 48\,\Omega$$

Das geometrische Mittel ist hier sinnvoller als das arithmetische, weil Impedanzen auf einer logarithmischen Skala natürlich sind. Das geometrische Mittel minimiert den maximalen relativen Abstand zu beiden Optima gleichzeitig. Das Ergebnis wurde auf 50 Ω gerundet und Anfang der 1930er Jahre als militärischer Standard etabliert (MIL-SPEC, später von IEC und IEEE übernommen).

Grundlagen: Wellenwiderstand einer Leitung

Die Telegrafengleichungen

Eine reale Leitung lässt sich nicht als einfacher Draht beschreiben, denn Spannung und Strom ändern sich entlang der Leitung. Das Modell: jedes infinitesimale Stück $dx$ verhält sich wie ein kleines LC-Glied:

───L'dx───┬───
          C'dx
          │
──────────┴───

$L'$ = Induktivitätsbelag, $C'$ = Kapazitätsbelag (jeweils pro Längeneinheit). Aus den Kirchhoffschen Regeln auf diesem verteilten Netzwerk folgen die Telegrafengleichungen:

$$-\frac{\partial u}{\partial x} = L' \frac{\partial i}{\partial t}, \qquad -\frac{\partial i}{\partial x} = C' \frac{\partial u}{\partial t}$$

Von den Telegrafengleichungen zur Wellengleichung

Differenziert man die erste Gleichung nach $x$ und setzt die zweite ein:

$$\frac{\partial^2 u}{\partial x^2} = L' \frac{\partial}{\partial t}\left(-\frac{\partial i}{\partial x}\right) = L' C' \frac{\partial^2 u}{\partial t^2}$$

Das ist die Wellengleichung mit Phasengeschwindigkeit $v = 1/\sqrt{L'C'}$.

Wellenwiderstand $Z_0 = \sqrt{L'/C'}$

Für eine harmonische Welle $\sim e^{j(\omega t - kx)}$ gilt $\partial/\partial x \to -jk$ und $\partial/\partial t \to j\omega$. Einsetzen in die erste Telegrafengleichung:

$$jk \cdot U = j\omega L' \cdot I \quad \Rightarrow \quad Z_0 = \frac{U}{I} = \frac{\omega L'}{k}$$

Mit der Dispersionsrelation $k = \omega/v = \omega\sqrt{L'C'}$:

$$\boxed{Z_0 = \frac{\omega L'}{\omega\sqrt{L'C'}} = \sqrt{\frac{L'}{C'}}}$$

$Z_0$ ist also das Verhältnis von Spannung zu Strom einer laufenden Welle, eine reine Geometrieeigenschaft, keine Last. Eine reflexionsfreie Terminierung mit $Z_\text{Last} = Z_0$ lässt die Leitung „unendlich lang" erscheinen.

$L'$ und $C'$ für das Koaxialkabel

Innenleiter-Radius $a$, Außenleiter-Radius $b$. Beide Felder sind rotationssymmetrisch und exakt berechenbar:

Induktivitätsbelag (aus dem Ampèreschen Gesetz: Magnetfeld $B(r) = \mu_0 I / 2\pi r$, Integration von $a$ bis $b$):

$$L' = \frac{\mu_0}{2\pi} \ln\!\left(\frac{b}{a}\right)$$

Kapazitätsbelag (aus dem Gaußschen Gesetz: elektrisches Feld $E(r) = \lambda / 2\pi\varepsilon_0 r$, Spannung durch Integration):

$$C' = \frac{2\pi\varepsilon_0}{\ln(b/a)}$$

Einsetzen in $Z_0 = \sqrt{L'/C'}$:

$$Z_0 = \sqrt{\frac{\mu_0}{2\pi}\ln\!\left(\frac{b}{a}\right) \cdot \frac{\ln(b/a)}{2\pi\varepsilon_0}} = \frac{\ln(b/a)}{2\pi}\sqrt{\frac{\mu_0}{\varepsilon_0}}$$

Wellenwiderstand des Vakuums

$$Z_\text{Vak} = \sqrt{\frac{\mu_0}{\varepsilon_0}} \approx 376{,}73\,\Omega$$

Mit $x = b/a$:

$$Z_0 = \frac{376{,}73}{2\pi} \cdot \ln(x) \approx 59{,}95 \cdot \ln(x) \approx \boxed{60 \cdot \ln(x) \quad [\Omega]}$$

Mit Dielektrikum ($\varepsilon_r > 1$) ersetzt $\varepsilon_0 \to \varepsilon_0\varepsilon_r$:

$$Z_0 = \frac{60}{\sqrt{\varepsilon_r}} \cdot \ln(x)$$

Für Luft ($\varepsilon_r \approx 1$) entfällt der Faktor.

Herleitung der optimalen Impedanzen

1. Minimale Dämpfung

Die Dämpfungskonstante $\alpha$ beschreibt, wie stark die Amplitude pro Längeneinheit abnimmt:

$$U(z) = U_0 \cdot e^{-\alpha z}$$

Die Dämpfung entsteht durch den ohmschen Widerstand beider Leiter. Wegen des Skin-Effekts fließt der Strom nur in einer dünnen Schicht der Tiefe $\delta = \sqrt{2/(\omega\mu\sigma)}$ an der Oberfläche. Der Widerstandsbelag ist damit:

$$R' = \frac{1}{2\pi\sigma\delta}\left(\frac{1}{a}+\frac{1}{b}\right)$$

Mit $\alpha = R'/(2Z_0)$ und nach Kürzen aller Konstanten hängt $\alpha$ nur noch von der Geometrie ab:

$$\alpha \propto \frac{1/a + 1/b}{\ln(b/a)} = \frac{x+1}{\ln(x)}, \quad x = \frac{b}{a}$$

(Außenleiter $b$ fest, $a = b/x$ variabel, Faktor $1/b$ kürzt sich heraus.)

Minimum durch Nullsetzen der Ableitung:

$$\frac{d}{dx}\left[\frac{x+1}{\ln x}\right] = \frac{\ln x - \dfrac{x+1}{x}}{\ln^2 x} = 0 \quad \Rightarrow \quad \ln x = 1 + \frac{1}{x}$$

Numerisch: $x \approx 3{,}6$ → $Z_0 = 60 \cdot \ln(3{,}6) \approx \mathbf{77\,\Omega}$

2. Maximale Leistung

Die maximale übertragbare Leistung wird durch die Durchschlagsfeldstärke am Innenleiter begrenzt. Das elektrische Feld im Koaxialkabel folgt aus dem Gaußschen Gesetz (Zylindersymmetrie):

$$E(r) = \frac{V}{r \cdot \ln(b/a)}$$

Da $E(r) \propto 1/r$, ist das Feld am Innenleiter ($r = a$) am stärksten, dort tritt zuerst Durchschlag auf:

$$E_\text{max} = \frac{V}{a \cdot \ln(b/a)} \quad \Rightarrow \quad V = E_\text{max} \cdot a \cdot \ln x$$

Die übertragbare Leistung bei gegebenem $E_\text{max}$:

$$P = \frac{V^2}{2Z_0} \propto \frac{(a \cdot \ln x)^2}{\ln x} = a^2 \cdot \ln x$$

Mit $a = b/x$ (Außenleiter $b$ fest):

$$P \propto \frac{\ln x}{x^2}$$

Maximum durch Nullsetzen der Ableitung:

$$\frac{d}{dx}\left[\frac{\ln x}{x^2}\right] = \frac{1 - 2\ln x}{x^3} = 0 \quad \Rightarrow \quad \ln x = \frac{1}{2} \quad \Rightarrow \quad x = \sqrt{e} \approx 1{,}65$$

$$Z_0 = 60 \cdot \ln(\sqrt{e}) = 60 \cdot \frac{1}{2} = \mathbf{30\,\Omega}$$

Zusammenfassung der Optima

Warum dennoch nicht 30 Ω für Hochleistungssender?

1. Standardisierung dominiert Die gesamte HF-Infrastruktur (Koaxkabel, Stecker, Messgeräte, Verstärker) ist auf 50 Ω ausgelegt. Ein Sender mit 30 Ω bräuchte überall Transformatoren → Verluste und Kosten.

2. Das Optimum ist sehr flach Bei $x = \sqrt{e} \approx 1{,}65$ (30 Ω) ist das Maximum, aber bei $x \approx 2{,}3$ (50 Ω) ist die Leistungsfähigkeit nur wenige Prozent schlechter, also kein wirtschaftlicher Vorteil.

3. Mechanische Grenzen $D/d \approx 1{,}65$ bedeutet: der Innenleiter ist fast so dick wie der Außenleiter. Das ergibt wenig Isolationsabstand und ist schwer zu fertigen.

4. Hochleistungssender verwenden Hohlleiter Bei echten Hochleistungsanlagen (MW, kW-Bereich) verwendet man Hohlleiter statt Koaxkabel. Dort gelten völlig andere Optimierungskriterien.

Stattdessen haben sich je nach Anwendung zwei Standards etabliert:

75 Ω ist höherohmig als 50 Ω und näher am Dämpfungsoptimum und sinnvoll dort, wo nur kleine Empfangssignale übertragen werden und jeder Verlust zählt.

In 1776, the paperwork started. Two hundred and fifty years later, the celebration was still loud enough to be photographed.

3,0s f/13 ISO 100/21° 50-250mm f/4,5-6,3 VR f=175mm/262mm

1,3s 4s, 4s, 5s f/13 ISO 100/21° 50-250mm f/4,5-6,3 VR f=175mm/262mm

5s 3s 4s 1,6s f/13 ISO 100/21° 50-250mm f/4,5-6,3 VR f=175mm/262m

I have watched over twenty of them. Was only supposed to be here for one.

Actually, it all started with Internet Explorer. That was the reason for the trip. One year, a browser, and then back.

Internet Explorer 4. Internal build. Not available in stores.¹
The reason the one-year plan did not end on schedule.

And remember America Online? 100 free hours. At 28.8k, that was about 1.2 GB of theoretical ambition.

Eventually, there were ship parties.²

Major releases. Major parties.

The world kept changing around me. So did the work. The browser became Windows, the one you are probably running right now.

Windows Millennium Edition, Beta 2. The version before the version. Space Needle included.

Still waiting for first boot.

With the credits booklet. One highlight.

The foundation came first. The thank you came later.

And then AI arrived, and suddenly even the tools had tools. Maybe you asked one something today. That answer has a longer history than it looks.

The sky eventually reclaimed the agenda.

3,0s f/13 ISO 100/21° 50-250mm f/4,5-6,3 VR f=175mm/262mm

Photographing fireworks is practice in letting go of the plan. The light does what it wants. The camera catches what it can.³

The horizon always narrows, keeping your outlook undimmed. Rarely a moment ends entirely still.

June 21st, 2026, 19:19⁴. Summer solstice: the Sun reached its northern limit, the day stretched as far as it could, and the Moon was already visible in the blue evening sky.

The day was clearly not finished. The sky was still blue, the trees were still in sunlight, and the Moon had already arrived.

Not bright enough to take over, not faint enough to ignore. Just early.

Another moon sighting. No agents on duty this time, but the sky was clearly being monitored: Zunehmender Halbmond 🌓🌛.

Taken handheld with my Z50 and the NIKKOR Z DX 50-250 mm 1:4,5-6,3 VR. The tripod stayed inside.

1/500s f/6,3 ISO 250/25° 50-250mm f/4,5-6,3 VR f=250mm/375mm

The second image is a crop from the original 5568 × 3712 photo. The crop is 1015 × 677 pixels.

The lens was at 250 mm on a Nikon Z50. With the 1.5× APS-C crop factor, the EXIF reports this as 375 mm in 35 mm equivalent terms.

The additional digital crop factor can be calculated from the diagonal ratio:

$$ c_\text{digital} = \frac{\sqrt{5568^2 + 3712^2}} {\sqrt{1015^2 + 677^2}} $$

$$ c_\text{digital} = \frac{6692}{1220} \approx 5.49 $$

So the cropped image has an effective 35mm-equivalent focal length of:

$$ f_\text{eq,crop} = 250\,\text{mm} \times 1.5 \times 5.49 $$

$$ f_\text{eq,crop} \approx 2057\,\text{mm} $$

Or, starting from the EXIF equivalent focal length:

$$ 375\,\text{mm} \times 5.49 \approx 2057\,\text{mm} $$

In framing terms, the result is about 2050 mm full-frame equivalent.

It started as 250 mm and ended up at 2050 mm. With one more zero and some cropping, the Z50 became a small handheld observatory for one evening.

Piloti is an ultra-thin, self-supported aluminum rotunda by Marc Fornes / THEVERYMANY, commissioned by the City of Bellevue. It stands at the edge of Downtown Park, close to the towers but clearly not designed to think in straight lines. The trees help. So does the sunshine.

It is one of those places where I stop longer than planned.

1/1000s ISO 100/21° f=7,5mm

The sun was bright enough to make every shadow look like it had been organized in advance.

1/1000s ISO 100/21° f=7,5mm

The theme for The World Wide Panorama was "Exception", and this was the view that made the whole series happen. Bellevue around Piloti is all glass, clean edges, and corporate geometry. Downtown edges met one deliberate anomaly, yet the city kept its face straight. Then this thing stands there, soft and strange, like it grew overnight and nobody wanted to ask too many questions.

That was the exception I wanted: not a spectacle, but something that quietly refuses to behave like the city around it.

Interactive Panorama Piloti-Skulptur 1 360x180

1/1000s f/5,6 ISO 100/21° f=7,5mm

The Panorama Supervision Unit also made a brief appearance.⁵

From this side, Piloti feels less like a landmark and more like something the park quietly kept for itself.

Interactive Panorama Piloti-Skulptur 2 360x180

1/1000s f/5,6 ISO 100/21° f=7,5mm

The little planet version gives the park a suspicious amount of authority.

Inside, it feels less like looking at the sculpture and more like standing under its idea.

Interactive Panorama Piloti-Skulptur 3 360x180

1/640s f/5,6 ISO 100/21° f=7,5mm

These are the original NEF frames; with the hard contrast under the sculpture, the RAW data was useful for recovering highlight and shadow detail and building a more natural HDR-like result.

The last little planet makes a tiny roofed world out of it. No permit required.

Most MCP examples start with tools.

That makes sense. Tools are easy to demonstrate: the model asks, the server does something, and a result comes back.

Resources are quieter. They do not run an action. They expose named read access to state.

That distinction is the point.

The screenshots show MCP Tool Explorer connected to the MCP SDK example server @modelcontextprotocol/server-budget-allocator.

Tools Are Commands

A tool is a command exposed by an MCP server.

It might calculate something, start a build, create an issue, query a database, send a message, rotate an image, or trigger a deployment. A tool has input, behavior, and a result. Sometimes it also has side effects.

That is why tool calls are the easy part of MCP to explain. They look familiar. The model asks for an operation, the host calls the server, the server replies.

tools/call run_tests
  input:  { "suite": "unit" }
  output: { "passed": 128, "failed": 0 }

Good tools should be explicit. They should have clear names, clear schemas, and clear errors. If a tool changes the world, that should not be hidden behind a vague description.

So far, so normal.

Resources Are Named Reads

A resource is different.

A resource is not a command. It is a URI the client can read from the server.

resources/list
  build://latest/log
  build://latest/summary
  config://current
  trace://last-run
  device://temperature

The server owns those names. It decides what exists, what each URI means, and what content is returned when the client calls resources/read.

That content may come from a file. It may come from memory. It may be assembled from an API call, a database row, a device sensor, a log tail, or a generated summary. The important part is not where the bytes come from. The important part is that the operation is a read.

Client -> Server: resources/read build://latest/log
Server -> Client: text/plain content

A resource can be dynamic and still be a resource. metrics://now might be different every time it is read. build://latest/log might point to whatever the latest build produced. device://temperature might be sampled live.

Dynamic does not mean action. It means the read is resolved at request time.

For example, a test server might expose a live-status resource. Reading it can return the server's current uptime, request counters, active configuration, or last activity. The values may change every few seconds, but the protocol shape stays the same: the client reads named state from the server.

Another good example is MCP Apps. In that case, a tool can point at a ui:// resource. The client reads that resource, receives an HTML document, and renders it as the app UI. The resource is not just metadata around the tool; it is the thing that implements the interactive surface.

That still follows the same rule: the app HTML is fetched through resources/read. The tool may trigger the experience, but the UI itself is loaded as a named read from the server.

I wrote about the full app mechanism, sandboxing, protocol flow, and host implementation in MCP Tool Explorer Supports MCP Apps: Protocol, Code, and the Fine Print.

The Model Does Not See Resources Automatically

This is the part that is easy to get subtly wrong.

Resources are not hidden context that the model magically knows about. They are server-side readable state with names.

The client can list resources and read them from the server. It does not need to know where the data lives or how it is collected. For a log resource, the client does not know the logs. The server does. The client only knows that a named read is available.

After reading a resource, the client can show the returned content to the user, cache it, use it internally, or include selected contents in a model request. But the model only sees the resource if the client deliberately includes that returned content.

Until then, the resource is available to the client, not present in the model context.

That is why the resource boundary matters. The server exposes knowledge the client does not otherwise have: logs, status, snapshots, generated reports, files, device state, or app HTML. A resource has an owner, a URI, a MIME type, a lifecycle, and a read boundary. The server says what can be read; the client asks for it by name.

That explicit boundary is what makes the system easier to inspect and reason about.

A Small Example

A server could expose a build system like this:

resources/list
  build://latest/summary
  build://latest/log
  build://latest/artifacts

tools/list
  run_build
  run_tests
  deploy_preview

The resources describe current state. The tools perform operations.

A client might first read build://latest/summary and show it to the user. If the model needs more detail, the client can read build://latest/log and pass only the relevant part into the next request. If the user asks for a new build, the client calls run_build.

After that, the server may update what build://latest/summary returns. It may also notify the client that the resource list or resource contents changed, depending on the server and host behavior.

The important thing is that reading the log and starting the build are separate protocol concepts.

One observes state. The other asks for work.

Resource Design Is API Design

The hard part is not implementing resources/read. The hard part is deciding what deserves a URI.

A good resource should be specific enough to be useful, but not so tiny that the client has to stitch together a hundred fragments. It should be stable enough to reference, but not so broad that every read becomes a data dump.

There are practical questions:

• How current does the data need to be?
• Can the client cache it?
• Who is allowed to read it?
• Does it contain secrets?
• Should large content be summarized or paged?
• Is this really a read, or is it a tool pretending to be harmless?

That last one matters.

Reading build://latest/log is a resource. Starting a build is a tool.

Reading config://current is a resource. Changing the config is a tool.

Reading device://temperature is a resource. Turning on a relay is a tool.

The names are not decoration. They define where the read boundary is.

Why This Matters

MCP is often described as a way to give models tools. That is true, but incomplete.

Tools expose commands. Resources expose readable state.

That separation gives MCP clients a cleaner way to work with systems that have more going on than one request and one response. Logs can be read without starting anything. Current configuration can be inspected without changing it. A server can expose status without turning every status check into a tool call.

It also helps humans. A resource list is inspectable. A resource URI can be logged. A resource read can be replayed. Permissions can be reasoned about at the boundary between "may read this" and "may do this".

That is less spectacular than a flashy agent demo.

It is also closer to how real software survives contact with Tuesday.

The Short Version

A tool is a command.

A resource is a named read.

The model does not automatically have either one. The MCP client connects to the server, discovers what the server exposes, and can then call tools or read resources by name.

That may sound like a small protocol detail. It is not.

It is the difference between assuming the client already knows the state and giving it a clean way to ask the server what the server knows.