Bridging the Yard: Point-to-Point Wi-Fi for Stables and Cameras

The stable block next to the house needed network access for cameras and local connectivity. It is approximately 420 metres away with clear line of sight and only about five feet of elevation difference between the two ends. That is close enough to see but far beyond the range where the house Wi-Fi signal would be a useful solution.

Running fibre would have been the cleanest physical design, but it would also have meant groundworks. Copper between buildings brings its own questions about distance, weather and electrical potential. I chose a dedicated outdoor point-to-point wireless bridge.

A bridge, not a larger hotspot

The important design decision was to treat the gap between the buildings as a network link. I used a pair of TP-Link outdoor radios. One is mounted at the apex/eaves of the garage and faces the stable block; the other faces back from the stable. Once aligned and associated, the pair behaves much like a cable between two switches.

EE router / home LAN
        │
   house radio  ))))))  stable radio
                              │
                      stable network
                        ├── cameras
                        └── local Wi-Fi

This is different from turning the transmit power up on a general-purpose access point. Directional radios concentrate energy along the path, reduce irrelevant coverage and give both ends of the link equipment designed for the same job.

The physical layer mattered first

Before touching IP addresses, I considered the 420-metre path. Point-to-point wireless wants clear line of sight, but the surrounding Fresnel zone matters too: roofs, foliage and other objects close to the path can weaken a link that looks clear by eye. The five-foot difference between the endpoints is modest, so mounting height and clearance around the path matter more than the raw elevation change.

Mounting also had to survive wind and weather without slowly drifting out of alignment. Outdoor-rated cable, sensible drip loops and protected cable entry were part of the network design, not cosmetic finishing touches. Power over Ethernet kept mains power indoors while one cable carried power and data to each radio.

Alignment was iterative. Signal strength alone was not enough; I wanted a stable modulation rate, low retransmission and consistent latency. A slightly lower peak signal with a cleaner, more stable link is preferable to a number that looks good only while standing beside the radio.

What the link originally carried

The original use case was a set of Amazon Blink cameras at the stable. That worked until the Blink Sync Module failed. The bridge itself remained useful, but the application on top of it had disappeared—a good illustration of why link availability and camera-platform availability are different things.

The Wi-Fi access point at the stable is also an ageing TP-Link unit and is now the weakest part of the design. It needs replacing. A strong point-to-point backhaul cannot compensate for an unreliable access point at the final hop.

The replacement needs to be outdoor-suitable, stable under continuous use and capable of serving the camera locations without turning the stable network into an unrestricted extension of every trusted home device.

Moving towards Reolink and Frigate

The current proof of concept uses a Reolink camera with Frigate running on the GMKtec Docker host. Frigate and its MQTT service are both running as containers on gmktec-docker; the deployment is being tested before the camera design is approved and expanded.

This changes the architecture. Blink placed much of the system behind a vendor-specific camera and sync module. Frigate provides a recorder and analysis layer that I operate myself, making camera streams, retention, detection and host capacity my responsibility.

That is more work, but it is also more observable. I can test the Reolink stream across the bridge, measure how the GMKtec host behaves, inspect Frigate logs and decide whether the proof of concept is reliable enough before buying the rest of the equipment.

The cameras still should not need unrestricted access to everything in the home lab. At minimum, management interfaces should be reachable only from trusted devices, default credentials should be replaced and unnecessary internet access should be removed. A separate VLAN and explicit firewall rules are part of the desired next design, subject to what the home router and switching equipment can support.

Measuring the result

A single proof-of-concept stream can hide a marginal link until weather changes or several cameras transmit at once. The useful question is not “what is the headline link rate?” but “will the worst ordinary day still carry the planned camera traffic with room to spare?”

The next test should capture latency, packet loss, actual camera bitrate and bridge signal over time. Interface counters, signal strength and device reachability can expose a deteriorating cable, a shifted radio or growing vegetation before the cameras disappear completely.

What I would preserve in the next version

The best part of the project remains the separation of concerns: a dedicated bridge crosses the gap, an access point serves the stable and Frigate handles recording and analysis. The failed Blink module and poor access point have made those failure domains unusually visible.

The lesson is broader than this particular outbuilding. When connecting two places, build and monitor a link between them. Do not ask a general-purpose access point to solve a physical-layer problem by accident.