RAK WisMesh Station HP: First Look at a Pi 4 Mesh Node

RAKwireless put a Raspberry Pi in a heatsink and called it a mesh node. The WisMesh Station HP is a Pi 4 Model B, a RAK6421 WisBlock HAT, a GNSS module, and a 1-watt-class RAK13302 radio, bolted into a finned aluminum case. The 32 GB card boots straight into meshtasticd. It’s $175.99 from RAK, $189.97 through Rokland. The standard RAK8622 drops to a 22 dBm radio for $169.99.

This is a first look at the hardware. RAK sent us the unit, the deal was photos and a post, they didn’t see it beforehand and set no conditions. It’s been on the bench a few days and it’s live on our mesh, but nothing here is a measurement. Performance, where this thing actually earns its spot, and a real look at the software all belong to the review, once it’s had more time on the network.

What follows is what the hardware is, plus a short tour of what it’ll run.

What’s in the Box

Unit, LoRa whip, GPS antenna, power supply, 32 GB microSD. The GPS antenna is the part worth noticing. It’s a puck on a long cable with a 3M VHB pad on the back, not a stub that screws to the case. Right call for something meant to sit on a shelf indoors. The antenna goes to a window, the node stays where the Ethernet is.

The supply is a plain wall wart. RAK’s label wants 5 V at 3 A, which is a Pi 4 number before you add a power amp to it.

The Outside

Extruded aluminum, fins top and bottom, four screws per end cap, textured black finish. It’s a heatsink that happens to be an enclosure. No fan, no vent, which is right for a sealed indoor box.

One face is pure Raspberry Pi. Two USB 2.0, two USB 3.0, gigabit Ethernet.

The other face is RF and power. LoRa connector, GPS connector with the puck cable running off to the left, USB-C for power, two status LEDs. RAK lists them as RP-SMA for LoRa and SMA for GPS, worth knowing before you order an antenna.

Those four USB ports matter more than they look. They’re how this box picks up a second radio, which is the whole story further down.

Attach the antenna before you power it. Goes for every high-power LoRa device, and RAK says it too.

What RAK Actually Shipped Us

This is where a first look earns its keep, because the unit disagreed with itself.

The case label says RAK8623, WisMesh Station HP, 5 V at 3 A. That’s the high-power SKU with the amplified radio.

The HAT said otherwise. The RAK6421 is HAT+ compliant, so its EEPROM carries RAK’s own factory inventory of the board, and the Pi hands it to you in the device tree. No screwdriver needed:

$ tr -d "\0" < /proc/device-tree/hat/product
6421 Pi Hat
$ tr -d "\0" < /proc/device-tree/hat/custom_1
io_slot1 RAK13300
$ tr -d "\0" < /proc/device-tree/hat/custom_3
sensor_slot_a RAK12501

RAK13300 is the plain 22 dBm module, not the amplified one. Two RAK records. Two different answers. Same unit.

The screwdriver settles it.

The module in IO slot 1 is marked RAK13302, FCC ID 2AF6B-13302, and the silkscreen underneath reads RAK13302_VD. It’s the amplified part. The case label was right and the EEPROM’s module field is stale. That’s the likely story rather than some deep contradiction: RAK programs the EEPROM at HAT level, and nobody updated the module field when a 13302 went in.

Flagging it for anyone else with one of these. Configure off the EEPROM alone and you’ll think you’ve got the 22 dBm part. Read the silkscreen.

The module label also carries a code of 001. RAK’s datasheet for the VD revision says it ships as two non-switchable variants, 001 for battery supply and 002 for external 5 V, and 002 is the one with the 5 V connector underneath. Ours is 001. The RAK6421 makes a VBAT rail at 4.17 V off the Pi’s 5 V, which is the obvious thing for a battery-supply part to run from, and it skips needing a separate 5 V feed in the case. We haven’t put a meter on that rail.

Inside

Same photo covers the rest. The HAT sits on the Pi’s 40-pin header, LoRa module in IO slot 1, RAK12501 GNSS (a Quectel L76K) in sensor slot A. Two IPEX pigtails run out to the bulkhead connectors. The HAT silkscreen is dense and genuinely useful: slot labels, the ADC address options from 0x48 to 0x4B, and the J8 and J9 breakout pads for VBAT, AIN1, GPIO 4 and 5, 3V3, ground, and I2C.

Underneath it all is an ordinary Pi 4 Model B, Rev 1.5 on ours, 2 GB of RAM. The camera connector and HDMI are still there, unused, and unreachable with the lid on.

The HAT is what makes this a platform instead of an appliance. Two IO slots for LoRa radios on the SPI bus with their own chip selects, so slot 1 is /dev/spidev0.0 and slot 2 is /dev/spidev0.1. Four sensor slots. A and C take a long module, and a long one in C makes D unreachable. Slot 2 ships empty.

Because it’s HAT+ compliant, the EEPROM brings its own device-tree overlay. Our card is stock Raspberry Pi OS with config.txt untouched and dtparam=spi=on still commented out, and both spidev nodes show up anyway. Worth knowing if you roll your own image and go hunting for a problem you don’t have.

About the 1 Watt

The RAK13302 is a Semtech SX1262 behind a Skyworks SKY66122 front end with a filter stage, 902 to 928 MHz. Hardware ceiling is 30 dBm.

That’s not the US operating point. The grants under FCC ID 2AF6B-13302 authorize 0.2897 W as a spread spectrum transmitter and 0.2831 W as a digital transmission system, both peak conducted. Under 290 mW either way, against hardware rated for more than three times that. Rokland says units ship with compliant settings. It’s still roughly 3x a typical 100 mW node, so it’s no bait and switch, but the 1 W on the box is a capability, not a permission. We went through the bandwidth rules behind numbers like that separately, because the power spectral density limit does more work there than the headline figure.

Power is the other half. RAK publishes a peak of 1000 mA at full output, down to 410 mA at 21 dBm. An amp of transmit peak on top of a Pi 4 that already wants 3 A is where the supply rating comes from, and it’s why this is a mains device with no battery path.

RAK’s copy also includes an unattributed story about an operator going from under 2 km on handhelds to “stable 12 km links” after moving to the high-power variant. No antenna, no terrain, no method, no operator named. Elevated 900 MHz LoRa with clean line of sight does 12 km at 100 mW, so that number is about the sites, not the amplifier. We’re quoting it as vendor copy, not repeating it as spec.

What It Runs

Only touching this here, because it’s most of the review.

Out of the box it’s a Meshtastic node. RAK publishes the image build, so you can read the contents from source instead of trusting the store copy. On a Debian bookworm arm64 lite base it installs meshtasticd from the OpenSUSE Meshtastic alpha repo, the Meshtastic Python CLI, and Docker, then drops a MeshMonitor docker-compose file in the rak user’s home without starting it. It doesn’t install Mosquitto, Node-RED, InfluxDB, or Grafana anywhere, whatever the product pages say. Those live in a separate RAK repo as an optional installer. Meshtastic itself comes up at https://<pi-ip>:9443.

We reimaged ours, because NodakMesh is a MeshCore network.

The useful bit is that the internal radio isn’t locked to Meshtastic. openHop, a Linux MeshCore implementation, drives an SX1262 straight through spidev and system GPIO, and it ships three RAK6421 board presets out of 27. One config file and the radio came up:

SX1262Radio configured: freq=910.5MHz, power=14dBm, sf=7, bw=62.5kHz
SPIdev opened: /dev/spidev0.0 @ 2000000Hz
DIO3 TCXO enabled: 1.8V, 5ms delay
DIO2 RF switch control enabled
SX1262 radio initialized successfully

No companion radio on a USB port. No hand-wired pin map. If you’re doing this yourself, here are both slots in BCM numbering, since this is the part you retype into a config file:

Those en_pins are load-bearing on this variant. An SX1262 sitting behind an unconfigured SKY66122 starts up clean and then hears almost nothing, and openHop drives those enables natively where meshtasticd has no way to.

Ours runs as a passive observer, not a repeater. It sits under an existing repeater, and a second forwarder at one set of coordinates duplicates traffic and wrecks route discovery. It captures every packet with SNR and RSSI to local disk and publishes to two community MQTT brokers. That setup, what it takes to keep it from forwarding, and the handful of ways it goes wrong are the review.

One thing a Pi buys you that an MCU node doesn’t: ours also posts NWS forecasts and severe weather alerts for Fargo and Moorhead to a channel, off the same box, in Python. That’s a capability, not a benchmark, and we’ll treat it like one.

Full Specs

How It Compares to the WisMesh 1W Booster Kit

The obvious comparison is RAK’s own WisMesh 1W Booster Starter Kit. Same RAK13302 radio, completely different computer behind it, quarter of the price.

Identical radio chain, so this isn’t an RF comparison. The Booster kit runs off a battery and a solar panel and the Station can’t, which rules it out of every hilltop and fence post. What the Station gives back is a computer. SSH into a node that’s acting up instead of driving to it. Package updates instead of reflashing. A local broker and capture file, so your telemetry lands on your own disk.

What the Review Will Cover

A first look is a hardware tour. The review comes after real time on the network, and it’s about three things.

Performance. How it behaves as a working node instead of a spec sheet, and what the capture file says about the site once there’s enough of it to say anything.

Use case. Where a mains-powered Linux node earns its spot next to the MCU nodes already on the mesh, and where it plainly doesn’t.

The software, properly. This post touches the stack. The review opens it up: the openHop config in full, the failure modes worth knowing before you hit them, the dashboards and MQTT side, and what it takes to run a node like this without it quietly turning into a second repeater.

Who It’s For

Want a fixed indoor node you can administer remotely and build on? That’s who this is for. The HAT means the radio isn’t a dead end, the second IO slot is open, the four USB ports mean another protocol is a dongle away, and the Linux host means the node is a computer instead of an appliance.

Building a solar repeater? Wrong tool, and the Booster kit is the right one. No battery input, no solar path, mains only.

On MeshCore and figured a Pi-based Meshtastic box meant hanging a companion radio off a USB port? It doesn’t. The board presets are already upstream, the pin map is published up above, and the radio inside RAK’s Meshtastic gateway will run your mesh instead.

You can find the WisMesh Station on the RAKwireless store or from Rokland in the US. New here? Start with the MeshCore getting started guide or browse compatible devices.