Reading an Access Point Datasheet. TX, RX, and Spatial Streams Explained

I get one question more than almost any other. “Can you look at this datasheet and tell me what all of this means?”

Datasheets are written to sell hardware, not to inform design decisions. The numbers are accurate, but they are presented in the most flattering way possible. Here is how to read the three things clients ask about most. TX, RX, and spatial streams.

Start With the Highway Analogy

Think of a Wi-Fi channel as a highway.

• Channel width (20, 40, 80, 160, 320 MHz) is how wide the road is.
• Spatial streams are how many separate lanes of traffic the AP and client can run at the same time over that road.
• Modulation (MCS) is how densely each car is packed with passengers.

More lanes, a wider road, and fuller cars all mean more data per second. The catch is that both ends of the conversation must support the same number of lanes, and that is where most of the confusion starts.

TX and RX: The Radio Chains

You will see notation like this on a datasheet:

4x4:4

It reads as TX x RX : Spatial Streams.

A chain is a complete radio path: an antenna, an amplifier, and the electronics behind it. Think of each chain as a worker. A 4x4 radio has four workers sending and four listening.

In plain terms:

• TX (transmit) is the AP talking to the client. This is your downlink.
• RX (receive) is the AP listening to the client. This is your uplink.

You will sometimes see something like 4x4:3. That radio has four chains but only supports three streams. The extra chain is not wasted. It still helps with signal quality by combining the received signals, which improves the AP’s ability to hear weak clients, but it will not add a fourth lane of throughput.

Spatial Streams: Lanes on the Road

A spatial stream is an independent flow of data sent over the same channel at the same time. This works because radio signals bounce off walls, floors, and furniture, and the receiver can tell the separate paths apart. That bouncing, which engineers used to treat as a problem, is what MIMO uses to carry more data.

Each stream adds roughly the same amount of capacity. Here are the per-stream figures for a few common configurations at the fastest modulation:

These are PHY rates, the theoretical link speed. Real-world throughput is typically around half of that after protocol overhead, contention, and retries.

The Part Datasheets Don’t Highlight: Your Client Is the Limit

This is the single most important thing I tell clients.

An AP may be a 4x4 radio, but the connection runs at the capability of the weaker device. Most client devices are much smaller than the AP:

• Smartphones: typically 1x1 or 2x2
• Tablets and ultrabooks: typically 2x2
• Some higher-end laptops: 2x2, occasionally more
• IoT, scanners, and handhelds: often 1x1

So when a 2x2 laptop connects to a 4x4 AP, that connection is a 2-stream connection. The AP’s extra capability is not wasted, though. It gives you better receive sensitivity, and it lets the AP serve multiple clients at once with MU-MIMO, but that single laptop will not see 4-stream speeds.

Why the Headline Number Is So Big

You will see claims like “up to 10.7 Gbps.” Here is how that kind of number is usually built:

• It adds up every radio in the AP (2.4 GHz + 5 GHz + 6 GHz).
• It assumes the widest channel and the highest modulation.
• It assumes a client that supports every feature at those settings.

No single client will ever see that number. It is a sum of theoretical maximums across radios, not the speed of one connection. It is not dishonest, but it is not a performance guarantee either.

Transmit Power and Receive Sensitivity

These two specs matter more for coverage and reliability than the headline speed does.

Transmit power is how loudly the AP talks, measured in dBm. Datasheets may list it per chain or combined, and the legal limit depends on your regulatory domain. Because a higher number is not always a better design, I look at it alongside antenna gain, which together determine the effective isotropic radiated power (EIRP)

Receive sensitivity is how quietly a signal the AP can still understand. Here is the key rule: it is negative, and closer to zero is worse.An AP that can decode “-95 dBm” is hearing a much fainter signal than one that needs “-85 dBm”. You will also see sensitivity listed per data rate. Faster rates need much stronger signals, so the sensitivity at the top rate is far higher (a less negative number) than at the slowest rate.

The Mistake I See Most Often: AP Loud, Client Quiet

An AP can transmit at a much higher power than a phone or a laptop. That creates an asymmetric link:

• The client can hear the AP just fine (downlink looks great).
• The AP can barely hear the client (uplink is weak).

The signal icon on the device shows full bars, yet video calls stutter. The reason is that the client’s own, much lower transmit power is the limit. Design for the client’s capability, not the AP’s.Setting AP power lower and planning cell sizes around what a typical phone can send is often what fixes this.

A Quick Datasheet Checklist

When you evaluate an AP for a client, I’d look at these in order:

• Spatial streams per radio. Does it match what your client devices can use? Paying for 4x4 when everything is 2x2 deserves a conversation.
• Supported channel widths. Wide channels (160/320 MHz) are rarely practical in dense deployments because they consume spectrum your neighbors, and your other APs, also need.
• MU-MIMO and OFDMA support. These matter most in high-density environments with many simultaneous clients.
• Receive sensitivity. It tells you how well the AP hears weak devices.
• Transmit power and antenna gain. Look at the combination, and remember that regulations cap what you can use.
• Uplink and PoE requirements. A fast AP on an underpowered switch port or a 1 Gbps uplink will not deliver what the spec sheet promises.

The Bottom Line

The datasheet tells you what the AP can do in a lab. Your client devices, your channel plan, and your RF environment decide what it will do in your building. Before choosing hardware, find out what your clients actually are, and design the network around them.

If you would like a second set of eyes on a datasheet, a design, or a performance problem, get in touch.