Why does my launch monitor disappear from the network when nobody is playing?

Its entry ages out of the PC's ARP table after a few minutes of silence. The unit is still powered and still connected — it simply has not spoken recently, so the PC forgets its address. Pinging it brings it straight back.

My launch monitor has a 169.254 address. Is that broken?

No. A 169.254.x.x address is normal for a launch monitor plugged directly into the PC with no router in between. Both ends assign themselves an address and talk fine. It only indicates a fault if the unit is supposed to be on the venue network.

How do I know if a launch monitor is genuinely dead?

Ping it directly. A device that fails to answer an active ping across several minutes, having previously answered from that address, is genuinely unreachable. Absence from a device list on its own proves nothing.

Launch monitor not connecting? Why "it disappeared" usually means nothing

The single most common false alarm in a simulator venue: a launch monitor that vanishes from the network while sitting there working perfectly.

Written from running three simulator venues · Updated August 2026

If you have ever looked at a list of devices on a bay's network, not seen the launch monitor, and gone out to check on it — only to find it happily powered and fine — this page is about why that happens, and how to ask a question that gets a true answer.

The device list lies when the bay is idle

Your PC keeps a short-term table of who it has recently spoken to on the local network, called the ARP table. Entries age out after a few minutes of silence.

A launch monitor between sessions is silent. It is powered, plugged in, and perfectly healthy, but it has not said anything for ten minutes, so the PC has quietly forgotten its address. Anything that reads that table — a script, a monitoring tool, arp -a — now reports it as absent.

It is not absent. It is just quiet.

How we learned this, 2026-08-04

We built monitoring that read the neighbour table and alerted when a launch monitor went missing. It fired constantly on a bay that was completely fine. The unit vanished every time the bay went idle and reappeared the moment somebody hit a ball.

The fix was not a longer timeout or a quieter alert. It was to stop trusting passive observation: ping the thing before deciding it is gone. An alert you learn to ignore is worse than no alert.

Ask properly: ping it

From the bay PC, ping the address the launch monitor normally has:

ping 169.254.12.34

Then read the result honestly:

It answers — the unit is alive and was never gone. Whatever told you otherwise was reading a stale table.
It does not answer, repeatedly, over several minutes — now you have something real. Continue below.

To find the address in the first place, hit a ball or start a session so the unit speaks, then immediately run arp -a and look for it.

A 169.254 address is normal, not a fault

Many launch monitors are wired straight into the simulator PC rather than through the venue's router. With no router to hand out addresses, both ends fall back to self-assigned 169.254.x.x addresses and talk to each other quite happily.

So a launch monitor on 169.254.x.x is usually working as designed. It only means something is wrong if that unit is meant to be on the venue network — in which case it is telling you it never got an address from the router, and your problem is a cable, a switch port, or DHCP.

When it really is unreachable, check in this order

Power. Obvious, and still the answer more often than anything else. Check the unit's own light, not the power strip's.
The cable at both ends. Ethernet in a simulator bay lives a hard life — swung clubs, rolling chairs, feet. Look for a link light at the PC's port and at the unit.
The PC's network adapter for that segment. If the launch monitor is on its own direct link, that is a second adapter, and it can be disabled independently of the one carrying the internet. The bay can be perfectly online while the launch monitor's link is down.
The vendor's software on the PC. The unit can be reachable while the software that drives it is not running. See below.
The unit itself. Power cycle it. Give it a full minute — several units take longer to come back than you would expect.

"Connected" and "working" are different questions

A launch monitor can be perfectly reachable on the network while the software that reads it has crashed. Everything looks fine from the network's point of view, and the bay still cannot take a customer.

Check that the vendor's software is actually running on the bay PC — not just installed, and not just showing a window. On the machines we run, a healthy unit means a specific set of vendor processes alive; when the camera-side processes die, the unit answers a ping and the bay is still useless.

This is worth internalising, because it is the gap most monitoring falls into: network reachability is not readiness.

The other false alarm: things that are not equipment

If you are building any kind of check on what is plugged into a bay, know that a simulator PC is full of devices that look important and are not. A wireless keyboard receiver enumerates with a vendor name that means nothing to you, sits in the same list as the wheelbase and the launch monitor, and disappears whenever the desk gets tidied.

An alert about a customer-facing launch monitor is worth waking up for. An alert about the mouse dongle is how you learn to ignore alerts. If you cannot tell them apart, you will end up ignoring both.

This is what SimCenter does

SimCenter watches each bay from the inside and actively probes the launch monitor rather than trusting a stale device list — so an idle bay does not generate a false alarm, and a genuinely dead unit is caught within two scans.

It also checks that the vendor's software is alive, not just that the unit answers, because a bay whose launch monitor is reachable but whose software has crashed cannot take a customer either. And it learns which devices actually matter at each bay, so the mouse dongle never pages anyone.

See how SimCenter works →