The site has 3.5 acres of rooms and outdoor paths, up to 20 guide groups moving at once (about 30 moving tags counting staff), and a command post that needs to know which room each group occupies. A detector at each room or doorway that reports which tag passed gives that answer. A continuous x,y fix from satellites or Wi-Fi signal strength does not resolve which side of a wall a tag is on. The checks below test each candidate technology against the real requirement: room-to-room occupancy, a discreet tag that is waterproof and not merely water resistant, exposure to rain and a gore cannon, and a live display on the command-post PCs and low-cost Android tablets. The last section gives the commissioning procedure for the branch that meets the requirement.
Check 1: Does the command post need a room identity or a coordinate?
Prerequisite: a floor plan listing every room, every doorway, and which zones are indoors or outdoors. Take this reading before you price any hardware.
The request as written is x,y coordinates for about 30 moving objects on a plane, to within 1 m. The operating need is different. The site already runs hidden LEDs that show occupied, cleared, and speed-up-the-storyline states. Actors also pass script keywords to coordinate. Collisions happen when two groups end up in the same space. The decision the operator makes is "is room N free, and when will group K leave it." That is a zone-occupancy problem.
| What the operator acts on | What the system must deliver | Technology class |
|---|---|---|
| Which room each group is in, and when it clears | Enter/exit events per zone, keyed by tag ID | Per-room or per-doorway detectors (zone detection) |
| Where a group is along an open outdoor path | Coordinates, accuracy smaller than the spacing between decision points | GPS or RTLS positioning, outdoors only |
| Whether a guide has left the route | Last-seen zone plus time since last event | Zone detection with timeout logic |
Mechanism: a coordinate system has to hold its error below the distance from the tag to the nearest wall. If it does not, a group standing just inside room A is drawn in room B, which is the same failure as today's botched hand-off. A zone detector has no such error budget. It either saw the tag at its doorway or it did not, so the effective resolution is the doorway itself. Coordinates streamed at a high rate also have to be reduced to room occupancy on the host anyway. That is more data than the operator uses.
Outcome: if every decision the operator makes maps to a room, go to Check 2 only to confirm GPS is excluded, then move to the detector checks. If some outdoor stretches need position along a path, keep a coordinate layer for those zones only.
Check 2: GPS scatter against wall spacing
Reading to take: leave one GPS receiver stationary for a full evening in the room with the closest neighboring walls. Log its reported positions and plot the scatter against the floor plan. Repeat while walking a guide route that crosses indoor-outdoor transitions.
Consumer GPS is accurate to a few meters outdoors, on the order of 10 m. It degrades under roofs and drifts sharply when the receiver moves between indoors and outdoors, because it loses and reacquires satellites. A phone map app that updates position about once per city block while you walk shows the same behavior: the position is filtered and slow to update. Car fleet trackers are an off-the-shelf form of this and inherit the same limit.
- Scatter larger than the room-to-room wall spacing: GPS cannot tell adjacent rooms apart. This is the expected result for buildings with small rooms.
- Scatter smaller than the spacing only on open outdoor paths: GPS is usable as a supplement for those paths. Plan it as a second data source feeding the same zone table.
Next: Check 3.
Check 3: Wi-Fi as a locator, nearest-AP proximity versus RSSI trilateration
Wi-Fi can locate a tag in two ways, and they behave very differently.
| Mode | How position is derived | Granularity | Failure mode |
|---|---|---|---|
| Nearest-AP proximity | Tag reports which access point it hears strongest | Building or large area | Signal leaks through walls, so the strongest AP is often not the one in the tag's room |
| RSSI trilateration | Signal strength from at least 3 APs converted to distance, then intersected | Better than proximity in open space | Walls, props, bodies, and electrical systems change the signal strength. Dead rooms and blind spots appear. |
Mechanism: converting RSSI to distance assumes a known transmit power and a clear propagation path. Every wall, metal prop, and human body between tag and AP adds attenuation that the model reads as extra distance. A tag in a guide's pocket is also shadowed by the guide's own body, and that loss changes each time the guide turns. Over several acres, enough APs to keep three in view of every room is a large installation, and blind spots are likely.
Reading to take: walk a tag to the center of each pair of adjacent rooms. At each point record the RSSI from every AP in range, with the tag worn as a guide would carry it. If the RSSI sets for two adjacent rooms overlap, Wi-Fi location cannot separate them. Use Wi-Fi only as the backhaul that carries detector events to the host.
One exception deserves a quote request. Aeroscout sells active tags that locate through Wi-Fi infrastructure, aimed mainly at hospitals tracking equipment. The same survey applies to its tags.
Next: Check 4.
Check 4: Passive RFID read range at the doorway
Passive RFID tags have no battery. They power up from the reader's field and reply, so read range depends on reader power and antenna size, not on the tag. That physics sets hard limits that are easy to underestimate:
| Passive option | Range or cost figure | What it means on site |
|---|---|---|
| Common passive tags and small readers | Range under about 2 in | The tag must be presented to the reader deliberately |
| Inventory / laundry-style tags | Range around 6 ft | Can cover a doorway, but this is an industrial reader class |
| Hobby RFID reader board plus the longest-range hobby reader | $25 board + $35 reader, 180 mm (7 in) maximum | Gate or badge-tap point, not room coverage |
| Race-timing style: tags in shoes, readers at floor level near doorways | Tags about $1, readers about $1,000 each | Automatic doorway detection, but reader cost times room count dominates the budget |
| Door-access style reader | About $100 per door | Guide has to badge in on purpose |
Decision path:
- Multiply the doorway count from Check 1 by the reader price for each option. If the race-timing reader cost is outside the budget, drop automatic passive detection.
- If the remaining option requires the guide to tap a badge on purpose, compare it with a hidden push button per room wired to the same controller. A button gives the same information (guide declares arrival) with no tag and no reader. It is the simpler build.
- If floor readers stay in the plan, test reads with wet shoes and wet floors. Water and bodies absorb RF energy, and passive tags have no spare power margin to overcome that loss.
A hobby build of reader board, long-range reader, and Arduino comes to about $85 per detection point. At a 7-inch maximum range it works only as a tap point. At that price and capability, a purpose-built off-the-shelf reader is roughly break-even and brings the usual off-the-shelf advantages: enclosure, support, and spares. Next: Check 5.
Check 5: Active beacons worn by guides, Bluetooth, IR, and active RFID
An active tag carries a battery and transmits on its own. That gives room-scale range from a small tag in a pocket. It is the branch that meets the requirement: each guide wears an active beacon, and each room has a detector that reports which beacon IDs it hears.
| Beacon type | Detection method | Room discrimination | Field concern |
|---|---|---|---|
| Bluetooth | Microcontroller detector scans continuously, matches each device MAC address against the guide list, reports hits to the host | Range is longer than passive RFID and passes through walls. The detector needs a signal-strength threshold, or the host must pick the strongest of neighboring detectors. | Threshold tuning per room. Body shadowing when the tag is pocketed. |
| Infrared | IR detector in each room decodes the beacon's ID | Very good, because walls block IR completely | Needs line of sight, so the beacon must be worn visible. Rain, fog effects, and bodies block it. The same beacon can mark the guide on IR-sensitive webcams. |
| Active RFID | Purpose-built reader per zone | Set by reader sensitivity and placement | Battery life. Read it from the tag datasheet and compare it with nights of operation multiplied by hours per night. |
Mechanism behind Bluetooth wall bleed: 2.4 GHz signals lose strength through walls but are not stopped by them. A detector in room A will often hear a tag in room B at a lower level. Adding a threshold turns a hearing detector into a proximity detector. Alternatively, the host can compare the same tag's readings across neighboring detectors and assign the tag to the strongest one. This scan-and-match-MAC pattern is already proven for detecting staff phones passing inspection machines on a factory floor and pushing files to them.
Reading to take: put one detector in a room and walk a pocketed tag from the room center, to the doorway, to the far side of the shared wall. Record the signal strength at each point. If there is a clear gap between the weakest in-room reading and the strongest reading through the wall, a fixed threshold works. If there is no gap, use strongest-detector arbitration on the host, or use IR in that room.
Outcome: if the gap holds for every room pair, this is the resolving branch. Carry it to Checks 7 through 10. If some rooms fail, look at the fallback layer in Check 6 for those rooms.
Check 6: Dead reckoning, cameras, push buttons, and phones as fallbacks
These options cover rooms where beacons fail, or act as a manual backstop. Each one needs a named reading before it is trusted.
- Accelerometer dead reckoning. Build: microcontroller with Wi-Fi, accelerometer, battery, and case, plus Wi-Fi APs for backhaul. Cost is about $100 per tracker. Position comes from integrating acceleration twice, so small sensor errors grow without bound. The tracker has to be reset at a known position after each lap of the route. Reading: drift at the end of one full lap. If that drift exceeds a room width, the method cannot hold room identity between resets.
- Webcams. Not automatic. Command-post operators watch the feeds and assign groups by eye. An IR beacon worn by the guide makes the guide easier to pick out on cameras that see IR.
- Push button per room. The guide presses a hidden button on arrival. It is cheap and deterministic, but depends on the guide remembering.
- Phones as tags. A phone reports location if a page that refreshes itself stays open in the browser while the phone is in a pocket. Phone operating systems can suspend background browser tabs, and the location quality is the GPS and cell accuracy from Check 2. So this gives map-level position, not room identity. Waterproof covers solve the rain problem. Tracking phones passively by their cellular signal without an app needs three software-defined radios (for example USRPs). That is expensive and outside a volunteer build.
The existing hidden LEDs and script keywords stay in service as the manual layer until the automated system has passed the parallel-run test at the end of this procedure.
Check 7: Commercial RTLS quote against a DIY per-room detector build
Commercial real-time location systems (RTLS) cover indoor and outdoor tracking, but most are marketed to hospitals and priced for that market. They are sold through quotes rather than online checkout.
| Option | Capabilities in evidence | Fit to this site |
|---|---|---|
| Precyse RTLS | Indoor and outdoor location, sensors, relay outputs, an LCD on each worn tag, a GUI, and a LabVIEW API. Used to track workers on a construction site. | Relay outputs could drive the existing room LEDs directly. The LabVIEW API matches the planned host software. |
| Aeroscout | Active tags located through Wi-Fi access points. Main market is hospital equipment tracking. | Depends on the Wi-Fi survey result from Check 3 |
| DIY Bluetooth or IR detectors | Microcontroller detector per room, with backhaul to the host | Cost per detection point is in the same range as the $85 hobby RFID build. Integration time is the real cost. |
Procedure:
- Send each vendor the same spec: number of zones, 20 simultaneous groups and about 30 tags, worn discreetly, waterproof rather than water resistant, outdoor exposure to rain and fake blood, and output to a LabVIEW host.
- Ask for the tag's environmental rating, battery life per charge or replacement, and the per-zone reader count needed to separate adjacent rooms.
- Price the DIY option as (detectors × rooms) + tags + enclosures + backhaul + volunteer integration hours. Compare against the quote.
- Confirm the season deadline before choosing DIY. A detector network has to be built, sealed, and tuned before the event opens.
Tag and detector sealing for rain and gore-cannon exposure
Prerequisite: the tag's datasheet states protection against immersion, not just splashing. "Water resistant" parts fail under direct gore-cannon hits and standing rain.
- Choose tags with no open ports. Openings for charging and battery doors are where water gets in. Prefer sealed or potted units with a replaceable sealed battery or contactless charging. Confirm there is no seam or gasket on the tag body.
- For simple DIY indicators such as LEDs, two wires sealed with heat-shrink tubing can survive continuous submersion (a submerged LED in a pet water fountain is built this way). Microcontroller boards need full potting or a sealed housing. Confirm by soaking the assembly overnight and checking current draw afterward.
- Put outdoor detectors in sealed housings with cable glands, mounted high and away from gore-cannon aim lines. Confirm by spraying the housing and reading a live tag afterward.
- Wear the tag where the guide's clothing does not block the RF path to the room detectors. For IR, wear it visible. Confirm with the wall-bleed walk from Check 5, done wearing the actual costume.
- Plan a wipe-down routine at the end of each night. Dried residue on detector windows (IR) and tag surfaces lowers read performance. Confirm by comparing the first-night read counts with the last-night read counts.
Event path from room detectors to the LabVIEW host and Android tablets
Detectors report events. The host keeps state. The displays only show state. Keeping those three roles separate keeps the tablets simple and puts all the logic in one place.
// Detector -> host message (one per detection)
event = { tag_id, zone_id, rssi_or_null, detector_time }
// Host state
zone_occupancy[zone_id] = set of tag_id
tag_location[tag_id] = { zone_id, last_seen_time }
// Host rules
on event:
if event passes dwell/threshold filter:
move tag_id from old zone to zone_id
if zone_occupancy[zone_id] has another group -> raise CONFLICT
on timer:
for each tag: if now - last_seen_time > timeout -> mark LOST
for each detector: if no heartbeat -> mark DETECTOR DOWN
- Filtering: require a minimum dwell time or several consecutive reads before moving a tag to a new zone. This stops a guide pausing in a doorway from flickering between two rooms. Set the dwell from the doorway walk test, not from a guessed default.
- Heartbeat: each detector sends a periodic alive message. A missing heartbeat shows as a dead room on the operator screen instead of silently reporting the room as empty.
- Push versus poll: a LabVIEW web service polled by Data Dashboard only updates when the tablet asks for data, so latency depends on the poll interval. Pushing state changes over WebSockets to a browser page on the tablets delivers each change as it happens and needs no app installed on the Android devices. Either works if the measured event-to-screen delay is shorter than the time a group takes to cross a room.
-
LED integration: drive the existing occupied/clear LEDs from
zone_occupancy, either through controller outputs or through vendor relay outputs. Actors then keep the cues they already know.
Commissioning the per-room beacon system, room by room
Prerequisites: zone list and floor plan from Check 1, per-room thresholds from Check 5, sealed hardware from the sealing steps above, and the host running the state logic.
-
Detector bring-up. Mount one detector per room at the entry. Confirm each detector's heartbeat appears on the host under the correct
zone_idbefore you mount the next one. - Tag enrollment. Assign each tag ID to a group label on the host. Confirm every tag is read by a bench detector and shows the correct label.
- Doorway walk test. Carry a tag worn as a guide wears it and walk in and out of each room at guest pace. Confirm one enter event in the correct zone per pass and no events in neighboring zones. Adjust the threshold or dwell and repeat until the room passes.
- Shared-wall test. Stand for a while on the far side of every shared wall. Confirm the room on the other side of the wall never takes ownership of the tag.
-
Crowded-room test. Place the largest planned number of tags in one room at once. Confirm the host lists all of them in
zone_occupancy. - Wet test. Repeat the doorway walk in the outdoor rooms with tags and detectors wet. Confirm read counts match the dry results.
-
Full-load test. Send all 20 group tags through the route at the same time. Timestamp events at the detector and at the tablet. Confirm the worst-case delay is shorter than the fastest room crossing time. Confirm every intentional same-room entry raises a
CONFLICTalert. - Parallel live night. Run the system next to the existing LED and keyword process for one operating night. Log every hand-off the actors report and compare it with the host log. Accept the system only when the log has no case where the host showed a room clear while a group was inside, and every detector heartbeat stayed present from opening to close.
FAQ
Why does GPS not show which room a group is in?
Consumer GPS is accurate to a few meters outdoors, around 10 m, and drifts further as a receiver moves between indoors and outdoors. That error is larger than the spacing between adjacent rooms, so the plotted position lands on the wrong side of walls. Use it only for open outdoor paths.
Why does Wi-Fi signal-strength triangulation leave dead rooms?
Trilateration needs at least three access points in range and assumes a clear path between tag and AP. Walls, props, bodies, and electrical systems add attenuation that the math reads as extra distance. Survey the RSSI at each room center; if adjacent rooms give overlapping readings, use Wi-Fi only as backhaul.
Why does a passive RFID tag not read from across a room?
A passive tag runs on energy from the reader's field, so range is short: under about 2 in for common tags, 180 mm for the longest hobby reader, and around 6 ft for inventory-class systems. Doorway coverage needs race-timing class readers at about $1,000 each. Otherwise use active Bluetooth or IR beacons.
How do I push live group locations from a LabVIEW host to Android tablets?
Keep the room-occupancy state on the LabVIEW host and push each change over WebSockets to a browser page on the tablets, which needs no app install. Polling a web service from Data Dashboard also works if the poll interval keeps screen delay shorter than a group's room-crossing time. Verify by timestamping events at the detector and at the tablet.