How to Choose the Right Cellular Module for Raspberry Pi: 4G LTE, Cat 1, Cat 1 bis, Cat 4, LTE-M, NB-IoT, 5G RedCap, or 5G

Choosing a cellular module for Raspberry Pi is not about buying the fastest modem. The right choice depends on how much data your device sends, whether it moves, how much power it can spare, what cellular networks exist where it will run, and how it will be deployed.

This guide compares NB-IoT, LTE-M, LTE Cat 1/Cat 1 bis, LTE Cat 4, 5G RedCap, and 5G, explains the difference between a cellular module, modem, HAT and router, and shows how to pick the right cellular connectivity for a Raspberry Pi project.

Quick answer: which cellular technology should you choose?

Start with the workload, not the modem. Choose NB-IoT primarily for infrequent messages where mobility requirements are limited. Choose LTE-M when the device moves or communicates more often but still needs to be power-efficient. Choose LTE Cat 1 or Cat 1 bis for general-purpose LTE at moderate data rates. Choose LTE Cat 4 when you need substantially more 4G throughput. Choose 5G only when the application has a sustained need for high bandwidth, low latency or high network capacity.

These are starting points, not rules. Real performance depends on the module, network, band, signal conditions, antenna, configuration, host interface and application traffic.

What is a cellular module for Raspberry Pi?

A cellular module is a hardware component that provides cellular connectivity to a host computer such as a Raspberry Pi. Depending on the module, it communicates with the host over an interface such as USB or UART.

A standalone cellular module typically requires:

• A compatible host system and, where required, a carrier or adapter board
• An appropriate power supply
• Suitable cellular antennas
• A SIM or eSIM
• Compatible drivers, protocols and software
• A cellular network technology support at the device’s location

Cellular module vs HAT vs router

• Cellular module is the hardware component that provides cellular connectivity to a host system.
• Cellular HAT is an expansion board that gives a module the physical mounting, power and SIM interface it needs for a host device. The Sixfab Base HAT, for example, bridges compatible mini PCIe cellular modules to a Raspberry Pi and other 40-pin-compatible boards.
• Cellular router is a complete networking device that shares one cellular connection with many devices and adds routing, LAN, firewall and VPN functions.

If the Raspberry Pi itself needs to connect directly to the cellular network, you typically use a cellular module with a compatible HAT or carrier board and a SIM card. A cellular router is an alternative when you want the Pi to connect through a separate networking device.

LTE-M vs NB-IoT vs Cat 1, Cat 1 bis vs Cat 4 vs 5G RedCap vs 5G: what’s the difference?

Compare on data, mobility, power, coverage, network availability and hardware compatibility together – not on headline speed.

The three kinds of number you will see quoted

This is the single most common source of confusion when buying a cellular module. There are three different types of figure, and they are routinely mixed together:

• Category limit — the maximum defined by 3GPP for a device category (e.g. LTE Cat 4 = 150 Mbps downlink). Not every category reduces to one headline figure: most LTE device categories do, but NB-IoT categories (Cat NB1, Cat NB2) and 5G RedCap do not.
• Module specification — the maximum the specific modem you are buying is rated for. Often well below the category limit.
• Real-world throughput — what you actually get, which depends on network, band, signal, antenna, load and host interface.

Here is the same comparison with both of the first two, side by side:

NB-IoT: when should you use it?

NB-IoT is a strong starting point for devices that send small amounts of data, spend most of their time idle and do not need continuous mobility — environmental sensors, smart meters, remote monitoring, simple infrastructure sensors and periodic telemetry.

NB-IoT uses a narrow-band design intended for low-data IoT. The low data rate is a feature, not a limitation, when the device only needs to send small payloads rather than hold a high-throughput connection open.

Does NB-IoT support mobility?

NB-IoT was originally designed with more limited mobility behaviour than LTE-M: Cat NB1 does not provide the same connected-mode handover, so a moving device reselects cells rather than handing over seamlessly.

Later 3GPP work added mobility enhancements for NB-IoT — Release 14 included a dedicated Enhancements of NB-IoT work item — so “NB-IoT does not do mobility” overstates the case. What you actually get depends on the device, the network implementation and operator support, so verify rather than assume. For applications that need reliable connectivity while continuously moving, LTE-M remains the safer starting point.

It is not accurate to describe NB-IoT as “LTE-M but slower.” They are different device categories built for different requirements. Published measurement studies comparing the two show that traffic pattern, radio conditions, latency and throughput all affect which one fits better.

Does NB-IoT have better coverage?

NB-IoT is designed to operate in challenging radio conditions, but coverage is never determined by the technology alone. It depends on the operator’s deployment.

So the useful question is not “does NB-IoT always have better coverage?” but “is NB-IoT available on the network and bands my deployment will actually use?” This is not a formality — see the availability note above. Coverage you cannot reach is not coverage: NB-IoT’s design advantages in difficult radio conditions only matter if your operator has actually deployed it on bands your module supports and in the location where your device will be deployed.

How much battery life can NB-IoT provide?

There is no universal number. Battery life depends on capacity of battery, transmission frequency, payload size, network and signal conditions, retransmissions, sleep configuration and how often the device wakes.

NB-IoT supports Power Saving Mode (PSM) and extended Discontinuous Reception (eDRX), which let a device spend long periods in a low-power state between transmissions. PSM was introduced in 3GPP Release 12 and eDRX in Release 13, and the ME910C1-WW supports both.

The same applies to LTE-M. Neither technology should be described as automatically delivering a fixed number of years of battery life; measurement studies show relative energy performance changes with the workload and operating conditions.

LTE-M: when should you use it?

LTE-M is the better starting point when a device needs mobility, low-power operation and more communication flexibility than a stationary, low-data application requires.

LTE-M — also called LTE Cat M1 — suits asset tracking, fleet telemetry, mobile monitoring, industrial IoT, remote equipment and portable devices. It handles mobility more naturally than NB-IoT and offers more data flexibility for applications that transmit more often or in larger chunks.

How fast is LTE-M really?

The Cat M1 category limit is 1 Mbps. Module specifications can be lower: many Cat M1 modules operate in half-duplex FDD, which limits their rated peak rates to a few hundred kbps. (Check the specification of the exact module.)

For example, the Telit ME910C1-WW used in Sixfab’s LTE-M Cellular IoT Kit is specified at 300 kbps downlink / 375 kbps uplink for LTE Cat M1 and 21 kbps downlink / 62.5 kbps uplink for Cat NB1. It is a single-Rx, single-antenna module, which keeps the antenna design simple.

The module also supports 2G/EGPRS fallback at 296 kbps downlink / 236 kbps uplink, though whether that is useful depends entirely on whether compatible 2G networks are still running in your deployment region.

LTE-M vs NB-IoT: Which One Fits Your Use Case?

Neither is universally better.

• Choose NB-IoT for small payloads, infrequent communication, long idle periods and stationary or low-mobility operation.
• Choose LTE-M for mobility, more frequent communication, greater data flexibility and lower latency than a typical NB-IoT workload.

Energy performance is workload-dependent: published measurements indicate NB-IoT can be advantageous for long idle periods, while LTE-M can suit more active devices or larger transmissions.

Is LTE-M fast enough for a sensor?

For many sensors, yes — but define “fast enough” from the application, not the technology. If your sensor sends a few measurements periodically, LTE-M may already be more capable than you need. If it moves, transmits more often, or needs flexible IP-based communication, LTE-M is a strong fit — and if it also needs more than a few hundred kbps, look at Cat 1 instead.

LTE Cat 1, Cat 1 bis and LTE-M: when do they make sense?

LTE Cat 1 is a general-purpose LTE option for applications that need conventional LTE connectivity and moderate data rates rather than an LPWA-optimised link — industrial equipment, telematics, payment terminals, remote monitoring and gateways.

Cat 1 and LTE-M are not two speed grades of the same technology. They are different device categories designed around different combinations of throughput, mobility, power and device complexity. Cat 1’s practical advantages over LTE-M are higher throughput — 10 Mbps versus a few hundred kbps on typical LTE-M modules — and broad, mature LTE network coverage.

What is Cat 1 bis?

Cat 1 bis is a Release 14 LTE UE category: the Cat 1 performance class with a single receive path. Removing the second receive path simplifies the RF front-end and antenna design and can shrink the board, which may in turn reduce module and device cost. Whether it actually does depends on the design: Cat 1 bis hardware can still cost more than an LTE-M or NB-IoT module, so treat it as a design-complexity advantage first and a cost advantage only if your own bill of materials confirms it.

Quectel’s EG800Q series is a current example: based on 3GPP Rel-14 LTE technology and supporting Cat 1 bis, it is specified at up to 10 Mbps downlink and 5 Mbps uplink. Note that the EG800Q is an LGA design-in module, not a mini PCIe card — it illustrates the Cat 1 bis capability class rather than being a drop-in option for a Raspberry Pi carrier board.

For a Raspberry Pi build using Sixfab’s mini PCIe ecosystem, the directly relevant Cat 1 options are the Telit LE910C1 and Quectel EC21, both supported with the Base HAT and both specified at 10 Mbps downlink / 5 Mbps uplink.

Is Cat 1 better than LTE-M?

Not universally. LTE-M is the stronger candidate when low power and mobility are the central requirements. Cat 1 or Cat 1 bis is the better fit when you need general-purpose LTE connectivity and moderate data rates. Decide on workload, power budget, mobility and network availability.

LTE Cat 4: when do you need more 4G bandwidth?

LTE Cat 4 makes sense when a Raspberry Pi needs more throughput than LTE-M, NB-IoT or Cat 1 can provide. Potential applications include industrial gateways, cloud synchronisation, large file transfers, vehicle connectivity and video backhaul. The deciding factor is the application’s actual data requirement.

LTE Cat 4 supports theoretical peak rates of up to 150 Mbps downlink and 50 Mbps uplink. The Quectel EG25-G and Telit LE910C4-NF are specified for these maximum rates in LTE-FDD operation. For the EG25-G, the specified LTE-TDD maximum rates are 130 Mbps downlink and 30 Mbps uplink. These are peak specifications, not guaranteed application speeds.

For these modules, achieving the 150 Mbps LTE-FDD downlink peak requires a 20 MHz carrier, two downlink spatial streams using 2×2 MIMO, and suitable radio conditions. Actual application throughput also depends on network load, signal quality, antenna setup, operator restrictions, the host interface and protocol overhead. The network backhaul and remote server can introduce further limits.

For video backhaul, size the connection around the combined bitrate of your streams and the sustained uplink speed available at the deployment site, with headroom for overhead and changing network conditions.

If your Pi sends only a few kilobytes of sensor data every few minutes, Cat 4’s extra throughput is unlikely to offer much benefit for that traffic alone.

Do you need 5G for Raspberry Pi?

5G becomes compelling when the application has a genuine, sustained need for high bandwidth, low latency or high traffic capacity. A Raspberry Pi reading a temperature sensor does not become a better product because its modem supports 5G.

5G makes more sense for high-resolution video backhaul, multi-camera systems, large and frequent transfers, demanding industrial connectivity, high-bandwidth edge computing, and applications with real latency or capacity requirements.

Will a Raspberry Pi get the headline 5G speeds?

Headline 5G peak figures are theoretical maxima defined under ideal evaluation conditions with all radio resources assigned to a single device. They are not a forecast for one Raspberry Pi in the field.

Judge a Raspberry Pi 5G modem on the specification of the exact module and the networks available in your region. For reference, Quectel’s RM520N-GL is a 3GPP Release 16 Sub-6 GHz module supporting both 5G NSA and SA modes — a very different device class from the RedCap modules described below.

What is 5G RedCap?

5G RedCap (Reduced Capability) was introduced in 3GPP Release 17 for devices that need more than LPWA technologies but not the cost, power draw and complexity of full 5G NR. Quectel positions RedCap between LTE Cat 4/6 and full 5G, targeting industrial IoT, video surveillance and wearables. Its Release 17 RedCap module RM255C-GL is an M.2 module quoted at theoretical peak rates of up to 223 Mbps downlink and 123 Mbps uplink, with LTE Cat 4 fallback. As with every peak figure in this guide, that is a ceiling under favourable conditions, not an expected field throughput. RedCap requires a 5G standalone (SA) network with RedCap support enabled; where that is unavailable, the RM255C-GL falls back to LTE Cat 4. Check that your target operator offers 5G SA and supports RedCap devices before choosing it.

The practical takeaway for a Raspberry Pi designer is that the landscape is not simply 4G → 5G. It is a capability spectrum:

NB-IoT → LTE-M → Cat 1 / Cat 1 bis → Cat 4 → 5G RedCap → higher-capability 5G NR

Nothing obliges you to move to the next step. Pick the point that matches the workload.

mini PCIe vs M.2: which form factor should you choose?

Once you have chosen the technology, you still have to choose the module’s physical and electrical interface.

mini PCIe

Mini PCIe has long been the workhorse for embedded cellular and remains practical for LTE projects. The Sixfab Base HAT accepts compatible mini PCIe modules including the Telit and Quectel modules used across Sixfab’s kits, and the connection guides in Sixfab Docs cover the ECM and QMI setup paths.

M.2 — and why keying matters more than people expect

M.2 is widely used for modern cellular modules, including most 5G modules. Two distinctions are worth stating plainly:

• 5G does not inherently require M.2. M.2 is a hardware form factor and interface configuration; 5G is a cellular technology. And in reverse: a module’s form factor tells you nothing about whether it is LTE-M, Cat 1, Cat 4 or 5G.
• M.2 keying is mechanical, not cosmetic. Cellular M.2 modules are typically Key B or Key B+M. Raspberry Pi’s official M.2 HAT+ exposes an M key edge connector intended for PCIe peripherals such as NVMe drives, in 2230 and 2242 form factors. A Key-B-only cellular module will not seat in an M key socket at all. A Key B+M module may fit physically but still requires the electrical interface — often USB — that a PCIe-oriented adapter is not designed to provide.

So before choosing a carrier board, verify all of: keying, electrical interface, power requirements, antenna connectors, module dimensions, host compatibility, and driver and operating-system support. The technical details for Sixfab’s 5G platform list the M.2 pin assignment and tested modules for exactly this reason.

How to choose a cellular module for Raspberry Pi: 5 things to check

1. Does the device move?

Mobility narrows the field immediately. Primarily stationary, low-data devices point toward NB-IoT. Asset trackers and fleet systems point toward LTE-M or conventional LTE.

2. Which cellular networks are available where it will run?

A modem is only useful if its technologies and bands match the networks at the deployment site. Verify LTE-M, NB-IoT, 4G and 5G availability, supported bands, operator coverage and roaming requirements for the actual deployment countries, not just where you prototype.

3. Does the modem support the required bands?

A module can support LTE or 5G without supporting every band every operator uses. Check the exact variant.

For example, the Telit ME910C1-WW is specified for LTE bands B1, B2, B3, B4, B5, B8, B12, B13, B18, B19, B20, B26 and B28, plus 2G bands B2, B3, B5 and B8. That is broad — but “global” never means “every band in every country.”

4. Does the SIM and connectivity plan match the deployment?

The modem and the SIM solve different halves of the problem. The modem must support the technology and bands. The SIM or connectivity plan must provide access to the required network, technology and roaming.

5. What will the prototype become in production?

A kit that works on a bench is not automatically production-ready. Evaluate certification and carrier requirements, band compatibility, thermal design, power budget, antenna design, enclosure constraints, module availability and long-term supply, and driver support.

Treat a list like that as a starting point rather than a guarantee. Module-level approvals can reduce or simplify the work, but many operators still apply their own end-device requirements, and what is needed varies by module, carrier and region. Check the module’s approval list against your target operators early, and confirm the remaining steps with the operator rather than assuming the module’s certificates carry the finished product. Sixfab publishes technical documents and compliance files per module.

Match your project to a technology

What about an edge-AI camera?

Do not default to 5G. If the Pi runs inference locally and only uploads detection metadata, alerts, small images or periodic results, Cat 4 is often enough. If it continuously streams high-resolution video or large datasets to a remote server, 5G RedCap or 5G becomes compelling.

Mapping that to Sixfab hardware

Each kit below opens with the condition that should send you to it. If none of the conditions fit, the 5-point checklist is the better place to go next.

Frequently asked questions

Can Raspberry Pi 5 use a 4G or 5G modem?

Yes, with compatible hardware. The modem, carrier board, interface, power supply, drivers and OS support all have to match. Sixfab documents Raspberry Pi 5 compatibility for its 4G/LTE and 5G kits.

Does a Raspberry Pi cellular modem need a SIM card?

Yes. It needs either a physical SIM or an eSIM (if the modem supports it), with an active plan that covers the technology and bands it will use.

What is the difference between a cellular modem and a HAT?

The modem is the radio. The HAT is the carrier board that connects it to the Pi and supplies the electrical, mechanical and SIM interfaces.

Why is my modem slower than the category maximum?

Because the data speeds in a module’s datasheet are theoretical maximums. Real-world throughput depends on the network, signal conditions, network load and your operator’s configuration.

Do LTE-M and NB-IoT have the same battery life?

No fixed number applies to either. Both support PSM and eDRX, but real battery life depends on the battery, traffic pattern, payload, signal conditions and modem configuration. Published measurements show NB-IoT tends to suit long idle periods and LTE-M more active workloads.

Sources

Vendor documentation

• Sixfab — Telit ME910C1-WW Mini PCIe LTE-M & NB-IoT Module: data rates, bands, approvals, PSM/eDRX release levels
• Sixfab — Raspberry Pi Cellular IoT Kit (LTE-M) and Kit Technical Details
• Sixfab — Raspberry Pi 4G/LTE Cellular Modem Kit and Cellular Internet Connection Guide: supported modules and ECM/QMI setup
• Sixfab — Raspberry Pi 5G Development Kit Technical Details: M.2 pin assignment, tested modules
• Telit Cinterion — ME910C1 Series product brief
• Quectel — LTE Cat 1 bis EG800Q series
• Quectel — Release 17 5G RedCap modules RM255C-GL and RG255C-NA
• Raspberry Pi — M.2 HAT+ documentation: M key support, 2230/2242 form factors

Standards

• 3GPP Release 8 — LTE UE categories including Cat 1 and Cat 4
• 3GPP Release 13 — LTE Cat M1 and Cat NB1
• 3GPP Release 14 — LTE Cat NB2, NB-IoT enhancements (NB_IOTenh), and LTE Cat 1 bis via work item LTE_UE_cat_1RX (ID 730085)
• 3GPP Release 17 — 5G Reduced Capability (RedCap)
• 3GPP work-item register for TS 36.306 — https://www.3gpp.org/dynareport?code=SpecVsWi–36306.htm

Peer-reviewed and preprint research

• Sørensen, A. et al., Modelling and Experimental Validation for Battery Lifetime Estimation in NB-IoT and LTE-M (2021) — arXiv:2106.13286
• Martinez, B. et al., Exploring the Performance Boundaries of NB-IoT (2018) — arXiv:1810.00847
• Wang, Y.-P. E. et al., A Primer on 3GPP Narrowband Internet of Things (NB-IoT) (2016) — arXiv:1606.04171
• Kadan Veedu, S. N. et al., Toward Smaller and Lower-Cost 5G Devices with Longer Battery Life: An Overview of 3GPP Release 17 RedCap (2022) — arXiv:2203.05634