Large photogrammetry rigs (over 60 cameras).

1. Flash the Raspberry Pi microSD cards using the new image - https://xangleapps.com/products/cameraserver/downloads
2. Connect cameras in the correct order, then click the re-number action in the camera list.
3. Pre-align cameras toward the subject. Field method: use a plastic mannequin for repeatable setup.
4. Ctrl-click Trigger to auto-focus all lenses once. Textured clothes on the mannequin improve consistency.
5. Set camera layout to 3D (that's the default value).
7. Take one synchronized picture with all cameras.
8. Optional but recommended: from Library / Align, run RealityScan alignment and inspect camera detection in 3D right away so positioning can be reused later in processing.


3D scan

A factory reset returns the app to its shipped defaults. Choose the least destructive method that matches the problem. A reset can remove settings, datasets, generated assets, queue history, and other local files, so keep a backup before continuing.

These instructions apply to both **Virtual.ink** and **Xangle Camera Server**. Replace `<app>` below with `virtualink` or `cameraserver`.

## Method 1: Reset from the app

Use this method when the app launches and you can open **Troubleshooting** from the app menu.

1. Open **Troubleshooting**.
2. Choose **Reset all settings** to delete saved JSON settings in the active working folder while keeping datasets and assets.
3. Choose **Full wipe** only when you also want to remove the local datasets and asset files.
4. Confirm the action and restart the app if it does not reload automatically.

The reset restores the current shipped defaults. It does not delete files in an external backup destination. When the default working folder is active, the reset also removes its `locations.json`; when a custom working folder is active, the global `locations.json` remains in the default app root.

## Method 2: Create a new working folder

Use this method when you want a clean workspace but want to preserve the existing workspace for reference.

1. Open the app's working-folder or location settings.
2. Add or select a new folder as the active working folder.
3. Restart the app when prompted.

A new working folder is scaffolded with `config` and `datasets` subfolders. The app then reads settings from the new folder instead of the previous one. The old folder remains on disk, so it can be restored later by selecting it again.

Working-folder choices are recorded in the app's global locations file:

- Virtual.ink: `%USERPROFILE%\\xangle\\virtualink\\locations.json`
- Xangle Camera Server: `%USERPROFILE%\\xangle\\cameraserver\\locations.json`

The active folder can also be a custom path outside these default roots. The `locations.json` file stays in the default app root even when a custom working folder is active.

## Method 3: Rename the working folder in Windows Explorer

Use this method when the app does not launch or its settings UI is unavailable. Close the app completely first.

1. Close Virtual.ink or Xangle Camera Server.
2. Open the default app folder:
   - Virtual.ink: `%USERPROFILE%\\xangle\\virtualink`
   - Xangle Camera Server: `%USERPROFILE%\\xangle\\cameraserver`
3. Rename the folder to a backup name, such as `virtualink_backup` or `cameraserver_backup`.
4. Launch the app again.

The app creates a new default folder with a `config` directory and a `datasets` directory. Keep the renamed folder until you have confirmed that the app works and that you no longer need its settings or files.

If a custom working folder is active, use the path shown in the app's location settings instead of the default path. Renaming only the default root will not reset that custom folder.

## What is and is not reset

The working folder contains the active `config` and `datasets` data. Depending on the app and modules in use, it can also contain `assets`, `archives`, and `backup` directories.

- **Reset all settings** removes JSON settings files from the active working folder and preserves datasets and assets.
- **Full wipe** removes settings, datasets, and local asset contents.
- Renaming a working folder preserves everything in that backup folder until you delete it.
- `locations.json` is stored in the default app root and tracks known working folders and the active custom folder. If a custom working folder is active, reset its location list separately by removing the relevant entries from this file; if the default working folder is active, **Reset all settings** and **Full wipe** already remove the file.

Do not delete the default app folder while the app is running. If the app still does not start after a reset, keep the renamed backup and contact support with the application logs.


Factory reset

| Shortcut | Action |
| --- | --- |
| Ctrl + Shift + H | Go to the dashboard. |
| Ctrl + 1 … 9 | Jump to Quick Nav slot 1–9 (configurable in Quick Nav settings). |
| Ctrl + Shift + O | Open the current page in an external browser. |

Quick Nav presets are configured in Settings > Quick Nav. Each preset can hold up to 9 pages mapped to Ctrl+1 through Ctrl+9.

Navigation

| Shortcut | Action |
| --- | --- |
| Ctrl + , | Toggle dashboard layout editor. |
| Ctrl + L | Cycle dashboard display mode (normal / locked / minimal). |
| Escape | Close the dashboard layout editor. |

Dashboard & layout

| Shortcut | Action |
| --- | --- |
| F11 or Alt+Enter | Toggle window fullscreen (or browser fullscreen in a web session). |
| Ctrl + Shift + F9 | Cycle demo window size presets (16:9 / 9:16 / 1:1). |
| PageUp | Toggle black screen overlay (for long-exposure photography). |
| Escape or click | Dismiss the black screen overlay. |

Window & display

| Shortcut | Action |
| --- | --- |
| Ctrl + Shift + mouse wheel | Zoom into the area under the cursor. |
| Ctrl + Shift + 0 | Reset magnification to 1x. |
| Escape | Reset magnification to 1x. |

Screen magnifier

- Open the station page on each tablet, TV, kiosk, or operator browser, then confirm it appears online in Devices.
- Give each station a practical name based on its physical location, such as Share counter, Replay TV, or Staff tablet.
- Keep the Devices page open during setup so you can see which screens are connected before guests arrive.

Register and identify screens

- Use a sharing station at the guest handoff point so staff can confirm a result, show the QR code, or send the email.
- Use a replay station on a larger screen when guests or staff should browse finished sessions.
- Use kiosk or guided mode for public-facing screens that should stay on a narrow, event-specific flow.

Choose station roles

- From Devices, send a station to the correct event page instead of walking to the screen and typing a URL by hand.
- For public screens, keep the station pinned to its event role so guests cannot wander into operator-only parts of the app.
- If a screen shows the wrong page during the event, correct it from Devices and confirm the physical display updates.

Keep stations on task

- Test every station on the real event network before doors open, especially tablets, TVs, and older browsers.
- Confirm power, screen sleep settings, fullscreen mode, Wi-Fi or Ethernet stability, and the station name shown in Devices.
- Walk the real guest flow once: capture, review, share, scan QR, open the link, and replay the result on the intended screen.

Pre-event checklist

| Shortcut | Action |
| --- | --- |
| ← / → | Previous / next dataset. |
| 0 … 5 | Clear or set star rating on the current dataset (0 = clear, 1 = one star, 5 = five stars). |
| Escape | Close settings panel, or go back. |
| Ctrl + , | Open Quickview settings. |

Rating shortcuts work on the Quickview page and on the Quickview dashboard tile.

Quickview

| Shortcut | Action |
| --- | --- |
| 0 … 5 | On the dataset detail page, clear or set the saved star rating. |
| Escape | Cancel pending transfer, dismiss bulk-action bar, or exit selection mode. |
| Ctrl + , | Open Library settings. |

Library

| Shortcut | Action |
| --- | --- |
| ← / → | Previous / next dataset. |
| ↑ / ↓ | Previous / next frame. |
| PgUp / PgDn | Previous / next iteration. |
| G | Go to frame number. |
| Scroll wheel | Zoom in / out (at cursor). |
| Click + drag | Pan (when zoomed). |
| Double-click | Toggle fit ↔ 100%. |
| + / − | Step zoom in / out. |
| 0 | Fit to screen. |
| 1 | 100% zoom (1:1). |
| F | Cycle fit mode (fit / width / height). |
| B | Cycle background (black / white / checker). |
| C | Cycle guide overlay (off / crosshair / 3×3 / 4×4). |
| ? | Show / hide shortcuts. |
| Escape | Close inspector. |

These shortcuts are active when the Frames inspector is open.

Frames inspector

| Shortcut | Action |
| --- | --- |
| F10 | Capture a JPG screenshot of the app window immediately. |
| Ctrl + F10 | Capture a JPG screenshot of the app window after a 2-second delay. |
| F7 | Start recording the app window. While recording: pause or resume. |
| F8 | Stop recording and save the clip. |

Recordings are saved in the active working folder under sessions/, each in its own folder named after its final MP4. Screenshots are saved separately under screenshots/.

Demo camera overlay shortcuts work after the overlay is configured. Camera 1, Camera 2, and Both view cycling becomes available once Camera 2 is running.

> Note: the demo-camera-overlay shortcut table from the original in-app help (camera bubble position/resize/zoom keys) is app-shell specific and was intentionally left out of this first migration pass; it can be added as its own page once its module ownership is confirmed.


Screeva

- Decide which outputs are actually needed at handoff: image, video, combined media, thumbnail, and any print-specific version.
- Keep output naming clear so operators can quickly identify what is guest-facing versus archival.
- Use Process recipes to lock branding, overlays, framing, and ratio choices before the first live capture.
- Keep the output list lean. Too many variants slow down review and increase wrong-action clicks at the station.

### Match outputs to the delivery path

- QR and direct download should point to files that are light enough for phone delivery on event Wi-Fi.
- Email delivery should use the same branded files guests expect from QR, unless you intentionally send a different variant.
- Printing should have its own prepared source strategy (input, processed, both, or auto) so print quality is predictable.
- Portal delivery is best when links must stay valid after the station powers down.

### Operator checklist before doors open

- Confirm one complete flow for each promised action: QR, email, print, and portal link when enabled.
- Confirm filenames and sorting make sense when multiple outputs are attached to the same capture.
- Confirm terms and custom fields only collect what the event actually needs.

Plan deliverables

- Use QR sharing when guests scan from the station and complete delivery on their own phone.
- Use it for single captures or multi-select batches from the Share screen.

### Configuration points that matter

- Choose QR placement for operator clarity: overlay on media preview or hidden from inline cards.
- Tune QR size and overlay position so the code stays readable on your actual sharing display.
- Keep direct download enabled when guests should save files immediately after opening the share page.
- Enable "require email before QR" only when your event needs contact collection before phone handoff.

### Live-operation checks

- Confirm Share is enabled and relay status is connected when using cloud QR mode.
- Scan from at least one Android and one iPhone device on the event network.
- Confirm both single-item and bulk QR flows if operators will share multiple captures together.

QR sharing

- Offline QR mode bypasses cloud relay delivery and serves files from the local machine.
- The share modal shows two QR codes: one for joining Wi-Fi and one for opening the local download page.
- This mode is intended for venues with unstable internet or fully offline operations.

### Setup requirements

- Configure a dedicated sharing hotspot and set the expected Wi-Fi SSID in Share Settings.
- Keep the sharing station and guest phones on that same local network segment.
- Test with real phones before doors open. Do not rely on desktop browser simulation for this mode.

### Operational cautions

- If guests cannot join Wi-Fi, the download QR will still fail even if the code scans correctly.
- If the station sleeps, reboots, or changes network, retest both QR codes immediately.
- Use portal delivery instead when links must remain reachable after the local station is gone.

Offline QR sharing

- Turn on printing in Share Settings, then enable the print action in the Share preset used at the station.
- Refresh the printer list and choose a preferred printer before the event starts.
- Set paper size and copy limits so operators cannot accidentally overload a printer line.

### Choose print source strategy

- Input: fastest path from original files.
- Processed: uses branded outputs from recipes.
- Both or auto: useful when some captures have processed files and others do not.
- Enable fallback to input when processed files might not be ready in time.

### Live print workflow checks

- Test single and bulk print flows from the actual Share station.
- Verify quantity prompts only if your team needs per-job copy overrides.
- Watch print job status (queued, printing, completed, failed) during early event traffic.

Printing

- Use email sharing when guests should receive a delivery link after operator confirmation.
- Keep templates, subject line, and reply-to aligned with the event brand before the first capture.
- Use required terms and custom fields only where compliance or follow-up needs justify the extra steps.

### Controls that affect delivery quality

- Enable multiple recipients only when operators are expected to send one capture to several contacts.
- Keep direct download available when email inbox access may be delayed on site.
- Verify SMTP sender configuration and test against real inbox providers before launch.

### Queue operations

- Monitor queue state for sent, pending, uploading, and failed jobs.
- Use queue details to inspect dataset path, attached files, subject preview, and rendered email body.
- Retry failed items from queue actions after fixing config or connectivity issues.

Email sharing

- Export from Share Settings Logs to download a CSV of email queue recipients.
- Each row includes recipient email, dataset folder, status, sent date, plus configured custom fields.
- The export reflects queue history and filters, so apply your date and state filters before exporting.

### Why teams use it

- Post-event handoff to marketing or CRM systems.
- Delivery auditing for sent versus failed batches.
- Field-level analysis when custom form data is captured during sharing.

### Good practice

- Export at least once during rehearsal to validate field mapping.
- Keep a final export snapshot at event close for reporting and recovery workflows.

Download email list

- Use portal delivery when links must remain active after the local sharing station is offline.
- Use it for events where guests often open media later, not only on-site.

### Dependencies to verify

- Confirm internet reachability and relay connection from Share Status.
- Confirm the app has a valid login session. Invalid or expired sessions can block relay startup.
- Keep offline QR mode disabled when you need cloud relay behavior, because offline mode bypasses relay delivery.

### Operational notes

- Run a full phone test from scan to final open link before guests arrive.
- Keep one operator check focused on relay and portal status after any network change.

Portal delivery

- Capture one real sample and verify all expected outputs exist.
- Run one QR share from the station screen and open it on a real phone.
- Run one email share and confirm inbox delivery, template rendering, and link behavior.
- Run one print job if printing is enabled, including copy-count behavior when quantity prompts are enabled.
- Run one portal delivery validation when cloud relay mode is expected.

### Validate details, not only success

- Confirm filenames and output variants are understandable to operators.
- Confirm terms, custom fields, and required email gates match the event policy.
- Confirm timing is acceptable under normal venue network conditions.

### Record and fix before go-live

- Log every mismatch (wrong branding, missing output, failed queue item, broken QR, print error).
- Fix settings first, then rerun the same test path until results are stable.

Run a test share

## QR and offline QR failures

- Confirm Share is enabled, then confirm whether the station is in cloud relay mode or offline QR mode.
- For cloud mode: verify internet and relay connected status before blaming QR generation.
- For offline mode: verify hotspot availability, SSID accuracy, and that guest phones join the same local network.
- Test QR from real phones, not only desktop previews.

## Email delivery failures

- Check queue state first: pending, uploading, failed, or sent.
- Open the failed queue item and inspect error message, recipients, and attached files.
- Recheck SMTP sender settings, required fields, and template placeholders after any config change.

## Print failures

- Confirm printing is enabled in both Share Settings and the active Share preset.
- Confirm the selected printer is online and paper settings match the expected format.
- If processed-source printing fails, test with input or fallback mode to isolate recipe/output timing issues.

## Portal and link persistence failures

- Confirm relay service is running and authenticated.
- If session is invalid, sign in again and rerun a full end-to-end share.
- If offline QR mode is enabled, remember that portal relay delivery is bypassed.

## Missing recipient export

- Export email CSV from Share Settings Logs after applying the intended filters.
- If export is unexpectedly empty, confirm there are queue records in the selected state/date scope.


Sharing or delivery issues

- For markerless alignment, keep the arc within ~120 degrees, centre the subject, favour textured clothing, and light evenly.
- If a camera was bumped, analyze a fresh capture and promote it as the new reference.


Alignment failed

- Default. Cloud/3D runs Xangle-hosted 3D camera registration with no local install. Use this when you want managed processing and fast setup.
- RealityScan/3D is a full desktop 3D camera registration workflow via RealityScan (Epic Games, Windows only). Use this when you want a local 3D workflow and reusable reference files for later processing.
- Track/2D is an in-app 2D alignment path. No external tool is required, but it is meant for fixed arcs and does not recover real 3D camera poses.

### Engine comparison

On clean, properly lit datasets, all three registration engines can produce the same alignment result. For the cleanest alignment, follow the capture guidelines above.

- **Cloud/3D**: Efficiency 7/10. No extra app to install. There is no warranty on result quality, but it is generally good in normal capture conditions.
- **RealityScan/3D**: Efficiency 9/10. Excellent quality in most setups, but it requires a RealityScan license from Epic Games and runs on Windows only.
- **Track/2D**: Efficiency 5/10. Fast and fully in-app. Best for fixed arcs, not full 360 rigs.

Choose the engine

- Cloud camera registration runs on Xangle workers, so no extra software installation is required.
- Images are uploaded only for the active job and are deleted after results are downloaded.
- Usage is measured with camera registration credits: one registration job costs one credit, regardless of camera count.
- Credits are consumed only when the cloud registration job completes successfully.

Cloud camera registration

RealityScan is the default 3D alignment engine in Camera Server. Epic's official install flow is:

1. RealityScan runs on Windows only. Download and install the Epic Games Launcher from the official RealityScan download page.
2. Open the launcher, create or sign in to your Epic Games account, then open the RealityScan tab under the Unreal Engine section.
3. Install the latest RealityScan build. In Camera Server, you can usually leave the RealityScan path empty so it auto-detects the install under C:\Program Files\Epic Games.
4. If RealityScan was installed somewhere else, paste the executable path manually in the Alignment settings.
5. Run one reference dataset from Camera Alignment or Library to confirm Camera Server can launch RealityScan headlessly and write the reference files.

### Cost and licensing

- Epic currently lists RealityScan as free for students, educators, educational institutions, and individuals or companies under $1 million USD in annual gross revenue.
- Above the $1 million USD revenue threshold, Epic sells yearly RealityScan seats. The public license page currently lists CA$1,697 per seat per year and also advertises a 30-day trial.
- Check the official RealityScan licensing page before budgeting or purchasing seats, because public pricing and terms can change.

### Learning and support

- Epic Developer Community provides RealityScan documentation, tutorials, sample datasets, and community forums when you need to learn the tool or troubleshoot the install.

Install RealityScan

- Frame the subject in the center so each camera sees the same central mass instead of edge clutter.
- Use even, stable lighting and avoid flicker, harsh shadows, or blown highlights.
- Keep the subject still so every camera captures the same moment in time.
- Prefer textured clothing or surfaces so the alignment engine can match the same 3D environment more reliably.

### What RealityScan writes

- Reference XMP sidecars for each registered camera.
- registration.csv for the aligned camera rig.
- A sparse point cloud for the 3D alignment preview.
- Optional: native COLMAP export for downstream processing when that setting is enabled.

Get a strong camera registration

An in-app alignment engine that straightens an arc of photos without RealityScan or any calibration markers. It works directly on the images by tracking the center subject from one camera to the next.

### When to use it

- Best for a fixed camera rig where the cameras do not move between captures. Align once, then reuse the result as the active reference for every later dataset.
- A fast, fully offline alternative to RealityScan or COLMAP that needs no external tool and no markers.
- It produces a 2D similarity transform per camera: shift, rotate, and uniform zoom. That is enough to straighten orbit or arc captures, but not enough for full 3D photogrammetry.

### Capture requirements

- **Up to 120 degrees of arc.** Beyond roughly 120 degrees, adjacent cameras stop sharing enough of the same view and the match can drift. Keep the total arc at 120 degrees or less.
- **A centered subject is required.** The engine locks onto whatever sits in the middle of the frame, so the subject must stay roughly centered in every camera.
- **Texture helps.** Dress the subject in patterned or detailed clothing when possible. Flat or single-colour surfaces give the matcher less to lock onto.
- **Light it properly.** Even, bright lighting gives crisp detail to match. Harsh shadows, blown highlights, or a dim subject reduce the number of usable features.

### How it works

- The first camera is the reference. Each following camera is matched to its neighbor, and those small steps are chained back to the reference to stay in the high-overlap region.
- Matching runs inside a centered region of interest so the subject, not a busy background, drives the alignment.
- A common interior crop is computed so every aligned frame stays inside the valid image area with no black edges.

### Tuning the settings

- **ROI width and height (%).** This is the size of the center region used for matching. Widen it if the subject fills the frame; tighten it if the background is pulling the alignment away from the subject.
- **Max ORB features.** Raise it for low-texture scenes to find more matches, but expect slower processing. Lower it when the subject is already richly textured and speed matters more.
- **Sub-pixel refinement iterations.** These are the ECC sub-pixel refinement passes. More iterations can sharpen the lock at the cost of time; the default is a good balance.

### Reusing the result

- When the alignment succeeds, the computed transforms are saved and the dataset becomes the active reference.
- Later datasets captured on the same untouched rig automatically reuse those transforms. If you physically move or re-aim any camera, run the alignment again to refresh the reference.

### Important boundary

Track/2D is purely 2D. It does not recover real 3D camera poses, so it is meant for straightening orbit or arc turntable shots, not for full photogrammetry or Gaussian-splat reconstruction.

Track/2D alignment

- When a result looks correct, promote that dataset as the active reference from the dataset menu in Library or from the Camera Alignment module itself.
- Future datasets on the same untouched rig can reuse the active reference automatically, so you do not need to align every capture again.

Set the active reference

- If any camera is bumped, re-aimed, re-focused, or moved during the event, capture a fresh alignment shot and promote it as the new reference before continuing.
- If the rig changes a lot between captures, enable auto re-align for new datasets instead of relying on one long-lived reference.

Recover from a bumped camera

Android phones can join a Camera Server rig through Xangle Remote Camera. Set up each phone once by USB, then use the local Wi-Fi network during operation.

## Supported source

- Android phones running Xangle Remote Camera on the same local network as Camera Server.

## Requirements

- Android 8.0 or later (API level 26 or later).
- A USB data cable for the first-time setup and future app updates.
- Developer options and USB debugging enabled on every phone.
- One local Wi-Fi network shared by Camera Server and all phones, without guest-network client isolation.

## First-time setup

Complete these steps for each phone before the event:

1. On the phone, open **Settings**, find **About phone**, then tap **Build number** seven times to enable Developer options. The exact menu names vary by phone manufacturer.
2. Return to **Settings**, open **Developer options**, and enable **USB debugging**.
3. Connect the phone to the computer running Camera Server with a data-capable USB cable. Avoid charge-only cables.
4. Unlock the phone and accept the **Allow USB debugging** prompt. Select **Always allow from this computer** when the phone offers it.
5. Start Camera Server. On the Camera page, open **Camera Adapters** and activate the **Android** adapter.
6. Camera Server detects connected Android phones and installs the bundled **Xangle Remote Camera** app when it is missing or outdated, grants its required permissions, and launches it.
7. Keep the app open, allow Camera and notifications permissions if the phone asks, then disconnect the USB cable after provisioning is complete.

USB is needed only to provision or update the app. Reconnect it later when Camera Server needs to reinstall the app or when troubleshooting a phone that does not appear.

## Update Xangle Remote Camera

Updates are automatic. When Camera Server includes a newer Xangle Remote Camera APK:

1. Connect the phone to the Camera Server computer by USB, unlock it, and accept the USB debugging prompt if it appears.
2. Camera Server detects the new build and installs it on the phone without any extra step.
3. Disconnect the phone once the app has relaunched. It returns to normal Wi-Fi operation when Xangle Remote Camera is open.

Tap the Xangle Remote Camera logo at the top of the phone's screen to check its installed version against Camera Server's version and host.

If a phone does not pick up an update after being connected for a while, use **Reinstall APK** in the Android camera adapter settings in Camera Server to force a fresh install on every connected phone. This is a manual fallback for troubleshooting, not a required step for routine updates.

## Uninstall Xangle Remote Camera

On the phone, open **Settings** > **Apps** > **Xangle Remote Camera** > **Uninstall**. This removes the app and its local capture data. Remove the phone from the Camera Server roster if it remains listed while offline.

For a fleet managed by a technician, the same removal can be performed over USB with Android Debug Bridge. Camera Server does not currently provide an uninstall action.

## Connect over Wi-Fi

1. Connect the computer running Camera Server and every provisioned phone to the same event Wi-Fi network. They must be able to reach each other on the local network.
2. Do not use a guest Wi-Fi network or a network with client isolation enabled. Those configurations prevent Camera Server from discovering phones.
3. Open Xangle Remote Camera on each phone and keep it in the foreground.
4. Wait for each phone to appear in the Camera control roster. A phone appears as one camera; choose its lens in the camera settings.
5. Verify live view, a trigger, and a completed download from every phone before the event starts.

## Relevant info

- Keep the app in the foreground and keep the phone awake during the event.
- Each phone appears as one camera. The selected lens is a setting on that camera, not a separate camera in the roster.
- Before the event starts, run a full trigger and download test on the exact phone model and Wi-Fi network you plan to use.

## Troubleshooting

- **The phone is not detected over USB:** unlock it, confirm USB debugging is enabled, accept the debugging authorization prompt, and try another data-capable cable or USB port.
- **The phone does not appear after moving to Wi-Fi:** confirm the app is open, the phone and Camera Server use the same local network, and neither is on guest Wi-Fi or behind client isolation.
- **The phone drops out during capture:** keep the screen awake, leave Xangle Remote Camera open in the foreground, and prevent the phone from switching to another Wi-Fi network or mobile data.


Android

- Hold the trigger to warm up before firing.
- Try shifting the sacrifice / flash slider by 1–2 ms.
- Confirm the camera is detected and online in the camera list.


Camera not triggering

Canon EOS cameras through Camera Server's Canon integration. Canon remains the most used and most tested path for multi-camera event rigs.

- Relevant info: Canon is the main event-ready path for Windows, Raspberry Pi, and Mac rigs when the body and tethering setup are tested properly.
- Camera names vary by region. Rebel, numbered, and Kiss names are shown together when known.

## Recommended camera setup

Apply these settings to each Canon body before connecting it to the rig:

- Set the main dial to **M** (manual).
- Keep the lens in **AF**. Focus with a half-press of the shutter or with the AF back button on supported models.
- On recent models, disable **Retract lens on power off** in the Custom Functions. This prevents a power cycle from changing the focus position.
- Turn on a 6x4 grid from the Shoot 5 menu. The grid helps with pre-calibration and framing checks.
- Set **AF method** to **1-point AF**.
- Do not use Servo focus on the event rig. This is especially important for the Canon R100 and may also apply to other recent EOS R bodies. Focus the shot, then leave the camera in a stable single-point focus mode.

## Canon R100 configuration

For the Canon R100, use these menu settings:

- **Settings / Other 3 / Shutter half-press button:** AE Lock (while pressed)
- **Settings / Other 3 / AE lock button:** metering and AF start
- **Settings / Shoot 4 / AF method:** 1 point AF
- **Settings / Shoot 4 / Continuous AF:** disable
- For both photo and video, set ISO manually instead of using AUTO.

## Video mode setup

Set one camera to video mode once so Camera Server can learn the settings exposed by that body. You do not need to repeat this setup for every camera of the same tested model and firmware combination, but confirm the resulting settings across the rig before an event.

Start with the same stable baseline used for photos:

- Manual exposure mode
- Manual ISO
- 1-point AF
- Continuous AF disabled where the body exposes that option
- Lens left in AF for initial focus, then held at the tested focus position

Test video recording, stopping, file download, and playback on the exact Canon model before relying on video mode in production.

## EOS R mirrorless

- Canon EOS R, RP, Ra, R1, R3, R5, R5 Mark II, R6, R6 Mark II, R6 Mark III, R7, R8, R10, R50, R50 V / R50V, R100

## EOS M mirrorless

- Canon EOS M50 / EOS Kiss M, M50 Mark II / EOS Kiss M2, M6 Mark II, M200

## EOS DSLR bodies

- Canon EOS-1D X Mark III, 1D X Mark II, 1D X, 1D C, 1D Mark IV, 1D Mark III, 1Ds Mark III, 5D Mark IV, 5D Mark III, 5D Mark II, 5DS, 5DS R, 6D Mark II, 6D, 7D Mark II, 7D, 90D, 80D, 77D / 9000D, 70D, 60D, 50D, 40D

## EOS Rebel / numbered / Kiss bodies

- Canon EOS 850D / Rebel T8i / Kiss X10i, 250D / Rebel SL3 / Kiss X10, 2000D / 1500D / Rebel T7 / Kiss X90, 4000D / 3000D / Rebel T100, 200D / Rebel SL2 / Kiss X9, 800D / Rebel T7i / Kiss X9i, 1300D / Rebel T6 / Kiss X80, 760D / Rebel T6s / EOS 8000D, 750D / Rebel T6i / Kiss X8i, 1200D / Rebel T5 / Kiss X70, 100D / Rebel SL1 / Kiss X7, 700D / Rebel T5i / Kiss X7i, 650D / Rebel T4i / Kiss X6i, 600D / Rebel T3i / Kiss X5, 1100D / Rebel T3 / Kiss X50, 550D / Rebel T2i / Kiss X4, 500D / Rebel T1i / Kiss X3, 1000D / Digital Rebel XS / Kiss F, 450D / Digital Rebel XSi / Kiss X2

## PowerShot models

- Canon PowerShot V10, ZOOM, G7 X Mark III, G5 X Mark II, SX70 HS


Canon

```youtube-video
https://www.youtube.com/watch?v=eieSLAH0x2A
```

Camera Server supports GoPro cameras over USB and wireless transports. USB is the preferred path for dependable event work. Wi-Fi/COHN is available for managed networks and should be tested on the real event network before production use.

## Supported models

- HERO11, HERO12, HERO13
- The legacy guide was tested with HERO13. Other models and firmware combinations need their own test before an event.

## USB setup

For a first setup or a smaller rig:

1. Connect the GoPro cameras to the Windows Camera Server computer with USB data cables.
2. Accept the camera's terms and keep the default setup options.
3. If the camera displays a QR-code page asking to connect to a phone, choose **Back** to bypass phone setup.
4. Open Camera Server and confirm the cameras in Camera control.
5. Reorder the cameras if the physical numbering does not match the Camera Server roster.
6. Select the required trigger mode for the group, such as single photo or video, and run a test capture.

There is no separate camera configuration step required for the basic USB workflow, but camera settings can be changed from Camera control when the adapter exposes them.

## Supported capture behavior

The current GoPro adapter supports the following capabilities where the camera model and firmware expose them:

- Photo or single capture
- Video capture
- Night mode where supported
- Camera settings changes
- Triggering
- Camera time synchronization where available below the trigger modes
- Normal Camera Server workflows such as playback, countdowns, sharing, lights, and trigger actions

Interval, JAF, and custom trigger sequences may not be available for every GoPro mode. Confirm the available trigger modes in the current Camera control UI instead of assuming that a mode from another camera adapter is supported.

## USB hubs and larger rigs

Use powered USB hubs with enough current and bandwidth for the cameras connected to them. The legacy operating pattern was four cameras per hub, spaced across ports 1, 3, 5, and 7 when the hub layout supports that arrangement. Treat this as a starting point, not a guaranteed limit.

- Avoid unpowered hubs for a multi-camera rig.
- Keep the hub topology simple and label every cable and camera position.
- Test the exact hub, cable, and port arrangement under a complete capture and download load.
- For larger arrays, distribute USB hubs across Raspberry Pi clients and connect those clients to the Camera Server computer over Ethernet.
- Confirm that every camera is visible, triggers, transfers its files, and appears in playback before scaling the rig.

![GoPro HERO13 cameras on a multi-camera rig](https://public.xangle3.com/doc/screenshots/2026-07-14/gopro-hero13-rig.png)

## Raspberry Pi scaling

Raspberry Pi clients can extend a GoPro system beyond the number of cameras that one Windows computer can reliably handle through direct USB.

1. Flash the currently supported XangleOS image for the node model.
2. Update all nodes to the compatible current client version.
3. Connect one or more powered USB hubs to each Pi, keeping within the measured power and transfer capacity of that Pi.
4. Connect the Pis and the Camera Server computer through a Gigabit Ethernet switch.
5. Open Network Nodes or the local-node settings in Camera control and confirm that every Pi is discovered.
6. Assign each camera node to the correct group and run a complete multi-camera test.

The old guide used image and client version numbers that are no longer a reliable requirement. Use the current release guidance and the node diagnostics in Camera Server.

Example layouts from the legacy guide, retained as architecture examples rather than fixed prescriptions:

- **8 cameras:** two powered USB hubs and one Windows computer.
- **24 cameras:** six camera hubs connected through a distribution hub to a Windows computer.
- **48 cameras:** distributed USB hubs on Raspberry Pi clients, one boot-server Pi where required, a 16-port network switch, and one Windows computer.

Measure each layout with the cameras, hubs, cables, network switch, and processing workflow you will actually use. More cameras increase power, bandwidth, transfer, and troubleshooting requirements.

## Wi-Fi and COHN

Wi-Fi is an additional transport for the same GoPro adapter. It is not a replacement for the dependable USB fallback.

- **Auto:** USB first, then configured Wi-Fi/COHN endpoints.
- **USB only:** ignore Wi-Fi/COHN endpoints and keep USB discovery active.
- **Wi-Fi/COHN only:** ignore USB discovery and use configured wireless endpoints.

For a managed shared-router setup:

1. Put the Camera Server computer on the rig router, preferably over wired Ethernet.
2. Provision each GoPro onto that same network through the current COHN workflow.
3. Reserve stable DHCP addresses for the cameras or configure the current static endpoint list.
4. Select the corresponding GoPro connection mode in Camera control and save the settings.
5. Confirm every camera's identity, IP address, transport, and enabled state.
6. Test photo triggering and file transfer with two cameras, then four, before expanding the rig.

Do not use a camera's private hotspot as the normal multi-camera workflow. A single laptop Wi-Fi adapter can normally join only one GoPro AP at a time, and switching to an AP can disconnect the computer from the event network. Use AP mode only as a one-camera diagnostic unless the network design explicitly supports it.

For Wi-Fi photo capture, Camera Server can send same-delay trigger commands as an adapter-level fanout. This remains software timing over HTTP or HTTPS, not hardware synchronization. Do not promise millisecond sync over ordinary Wi-Fi.

## Power and long sessions

For long sessions, test whether the camera and external power arrangement can operate without an internal battery. The camera, battery door, USB cable, hub, and power supply must all support the intended operating mode.

GoPro Labs firmware can expose QR-configured options for some camera models. The legacy guide used a QR command containing:

```text
!MTUSB=1!MWAKE=2!MBEEP=0!MuN1
```

The intended meanings were:

- `!MTUSB=1`: trust USB or allow operation from external USB power without the normal power handshake.
- `!MWAKE=2`: attempt to wake or power on the camera when USB power is present.
- `!MBEEP=0`: disable beeps.
- `!MuN1`: turn the camera off when USB power is removed.

These are GoPro Labs commands, not Camera Server settings. They depend on the camera model, Labs firmware, and the current GoPro Labs command syntax. Verify the command in the official [GoPro Labs custom QR tool](https://gopro.github.io/labs/control/custom/) before applying it. Do not scan an unverified command into production cameras.

![GoPro Labs power and wake QR code](https://public.xangle3.com/doc/screenshots/2026-07-14/gopro-labs-power-qr.png)

Use a properly rated external power supply. The legacy guide recommended at least 5 V and 2.4 A per camera path, but the correct requirement depends on the camera, cable, hub, and operating mode. Watch for heat, camera resets, missing files, and battery charging behavior during a long test.

## Hardware checklist

- GoPro cameras with compatible firmware
- Windows computer running Camera Server
- USB data cables for direct connections
- Powered USB hubs for multi-camera USB rigs
- Raspberry Pi clients and a supported XangleOS image for distributed USB
- Gigabit Ethernet switch and reliable network cables for node layouts
- Optional Bluetooth presenter for a physical trigger button
- Optional upgraded battery doors or external-power accessories appropriate to the camera

The old budget spreadsheet and shopping links are not maintained requirements. Select current hardware from measured power, bandwidth, camera compatibility, and event-support needs.

## Test before an event

Run this checklist on the exact rig:

1. Confirm every camera is numbered and physically labeled.
2. Confirm the selected GoPro connection mode: USB, Wi-Fi/COHN, or Auto.
3. Confirm every camera appears in Camera control and belongs to the expected group.
4. Set the capture mode and compatible settings.
5. Trigger several captures, including the longest or highest-load mode planned for the event.
6. Confirm every file transfers to the expected dataset and opens in playback.
7. Test camera time synchronization if the workflow depends on it.
8. Test countdowns, sharing, lights, and any external trigger action that will be used.
9. Leave the rig running long enough to expose power, heat, network, and USB problems.

If timing is important, measure the result with the [LED timer synchronization tool](/wayfinder/tools/measuring-trigger-sync-led-timer) and treat the result as a measured property of that specific rig.

![GoPro HERO13 cameras during a timer synchronization test](https://public.xangle3.com/doc/screenshots/2026-07-14/gopro-hero13-timer-test.png)


GoPro

Use this page to prepare each camera family before the first event. Camera Server can handle many day-to-day settings later, but these body-side settings should be done once per camera.

## Before you start

- If camera bodies have been used on different installs, do a factory reset first so every unit starts from the same baseline.
- Connect cameras in the same physical order as the rig before you number them in Camera Server.
- Prefer wired connections for event rigs whenever that camera family supports them.

## Canon USB cameras

Apply these settings on each Canon body before connecting it to the rig:

1. Set the main dial to M (manual).
2. Leave the lens in AF so you can focus during setup with half-press or a back-button AF control on supported bodies.
3. On recent bodies, disable Retract lens on power off so a power cycle does not shift the focus point.
4. Enable a 6x4 grid overlay to help with pre-calibration and framing checks.
5. Set AF method to 1-point AF.
6. Avoid Servo focus on the event rig. Focus the shot, then leave the camera in a stable single-point focus mode.

## Sony USB cameras

Sony bodies need a few more one-time menu changes before they are ready for Camera Server:

1. Complete every first-boot prompt, including language, date and time, timezone, and the Imaging Edge link, so the camera will not stop for onboarding again later.
2. Set the main dial, or Shooting mode, to M (manual exposure).
3. Set Focus area to Center and keep AF w/shutter enabled.
4. Turn Control with Smartphone off.
5. Turn PC Remote on.
6. Turn Long Exposure NR, High ISO NR, SteadyShot, and DRO off.
7. Turn the camera grid overlay on to make pre-calibration easier.
8. Power the camera off and back on after saving the settings, especially if you use battery couplers.

## GoPro HERO11 to HERO13

GoPro setup starts with the rig architecture, because the connection path matters more than on USB mirrorless bodies:

1. Choose the connection architecture first: direct USB to a Windows host for smaller rigs, or Raspberry Pi clients over Ethernet for larger arrays.
2. Use the wired GoPro Labs workflow for stable event rigs. GoPro over Wi-Fi remains Experimental and should be treated as a test path, not the default production path.
3. Use high-quality powered USB hubs. On Pi-based rigs, group each set of cameras on a client node instead of trying to load one computer USB bus with the whole array.
4. Power cameras on one by one in the physical order of the rig so Camera Server can assign and remember the correct numbers.
5. After the cameras appear, set the trigger mode and the rest of the capture settings from the Xangle dashboard so the whole array stays consistent.
6. Before event use, run a full trigger, download, and playback test on the exact cabling and hub layout you plan to deploy.

## Android phones

Android phones join the rig through the Xangle Remote Camera app and the local network, just like other phone cameras:

1. Install and open the Xangle Remote Camera app on the phone, or complete the one-time USB provisioning flow if that is how you deploy the app to the device.
2. Keep the app in the foreground and grant Camera and Local Network permissions the first time it runs.
3. Put the phone on the same local network as the machine running Camera Server.
4. Wait for the phone to appear in the camera grid as a single camera, then open its tile and verify live view, photo capture, video capture, and lens selection.
5. Before the event starts, run a full trigger and download test on the exact phone model and Wi-Fi network you plan to use.

### Android operating notes

- Keep the phone awake and keep the app in the foreground. A locked or backgrounded phone is not a reliable camera node.
- Each phone appears as one camera. The selected lens is a setting on that camera, not a separate camera in the roster.
- If the phone is missing from the roster, confirm the app is open, the phone is on the same network, and Local Network permission was granted.
- If the phone connects but shows no live view, reopen the app and confirm Camera permission is still allowed.

## iPhone on Mac (Experimental)

iPhone support is Experimental. Setup currently requires help from the Xangle team because the iPhone app is not publicly distributed yet. Follow these steps the first time you connect an iPhone to Camera Server running on a Mac. Once the phone is discovered, it will reconnect automatically on the same network.

1. Make sure you have a Mac running Camera Server (XCS26 or later), an iPhone running iOS 17 or later, and both devices on the same Wi-Fi network or subnet.
2. Install Xangle Remote Camera on the iPhone before the event with help from the Xangle team. The app is not on the App Store yet, so self-service installation is not supported today.
3. Launch Camera Server on the Mac, open the Cameras module, and confirm the status bar shows the server is listening (default port 8680).
4. Open the Xangle Remote Camera app on the iPhone. The app advertises itself on the local network with Bonjour and shows the phone name, IP address, and connection state.
5. Wait a few seconds for Camera Server to discover the iPhone automatically. If it does not appear, verify both devices are on the same subnet and that UDP 5353 (mDNS) and TCP 50080 are not blocked.
6. Open the iPhone tile, test photo capture, test video recording, and confirm autofocus responds before the event starts.

### iPhone operating notes

- Keep the Xangle Remote Camera app in the foreground on the iPhone at all times during an event. iOS suspends background camera access.
- Disable Auto-Lock on the iPhone (Settings → Display & Brightness → Auto-Lock → Never) so the screen does not turn off mid-capture.
- If the phone disconnects, simply reopen the app. It will re-advertise and Camera Server will reconnect within seconds.
- For multi-phone rigs, each phone needs its own unique name (Settings → General → About → Name) so the grid can distinguish them.
- USB connection is not required. iPhones connect exclusively over Wi-Fi.
- If you are using a captive-portal event network, make sure the phone has completed the portal sign-in before launching the app.


Cameras initial configuration

iPhone devices via Xangle Remote Camera. iPhones support live view, photo, video, autofocus, lens selection, and exposure settings when running the Xangle Remote Camera app on the same event Wi-Fi network.

## Supported models

- iPhone 12, 12 mini, 12 Pro, 12 Pro Max
- iPhone 13, 13 mini, 13 Pro, 13 Pro Max
- iPhone SE (3rd generation)
- iPhone 14, 14 Plus, 14 Pro, 14 Pro Max
- iPhone 15, 15 Plus, 15 Pro, 15 Pro Max
- iPhone 16, 16 Plus, 16 Pro, 16 Pro Max, 16e
- iPhone 17, 17 Pro, 17 Pro Max, iPhone Air
- Newer iPhones that ship after this list still work on iOS 17 or later; they appear under their hardware identifier until the model name is added.

## Relevant info

- The app requires iOS 17 or later and must stay in the foreground during an event.
- Disable Auto-Lock so the screen does not turn off mid-capture.
- USB is not required. iPhones connect over Wi-Fi.


iPhone

Camera numbering controls trigger participation, lane order, and frame naming. Treat numbering as part of rig setup, not as an afterthought.

## How numbering works

- Each active camera should have one unique number. Number conflicts are resolved with Swap or Kick out.
- A camera with ? is detected but not in the numbered firing order.
- Setting a camera to 0 removes its number.
- Missing cameras stay in the roster as missing rows, which helps preserve slot identity by serial.

## First-time numbering flow

1. Connect and power cameras in the same physical order as the rig.
2. Wait until the full roster is visible in Cameras.
3. Use Re-number to auto-assign numbers from discovered order.
4. Open any camera row to fine-tune numbers manually where needed.
5. Run one full trigger and confirm numbering matches your expected physical positions.

## Manual assignment and conflict handling

- Click a number cell to open Set camera number.
- If the target number is already used, choose Swap to exchange slots or Kick out to unnumber the conflicting camera.
- Use Remove from numbering when you want a camera fully out of the active numbered roster.
- Use Idle when a camera should stay connected for live view and settings sync but never trigger.
- Use Name (serial bound) for physical body identity and Name (numbering bound) for role-based slot naming.

## Numbering maintenance tools

- Compact numbering re-packs numbered cameras into a clean 1..N sequence with no gaps.
- Import / Export lets you save and restore complete numbering states between rigs or machines.
- A backup is created automatically before re-number, import, and swap operations.
- Import from backup restores a previously saved numbering snapshot.
- Import from older XangleCS supports legacy order_current.json migration when moving from older installs.

## Limits and operator notes

- License limits still apply: cameras numbered above the active limit are over-limit and will not trigger.
- Local cameras only is a view filter. It hides remote rows but is not the normal tool for editing numbering.
- Reset clears roster state and assigned numbers. Use it intentionally, then re-number from scratch.
- Before event day, lock numbering and avoid unnecessary renumber passes after alignment is validated.


Numbering cameras

Raspberry Pi MIPI CSI cameras driven by Raspberry Pi's `libcamera` stack on a Raspberry Pi camera node. These sensors connect directly to the Pi's CSI-2 ribbon port and are exposed to Camera Server through the `rpi-libcamera` adapter.

- Relevant info: the supported sensor list mirrors what Raspberry Pi's own `libcamera` implementation recognizes. A sensor listed here is recognized by the adapter; test the exact module and Pi model before event use.
- Sensor names below are the libcamera sensor IDs. The friendly Raspberry Pi product name is shown in parentheses when one exists.
- Autofocus controls (AfMode, lens position) are only available on sensors that have a focus lens, such as the IMX708 (Camera Module 3). Fixed-focus sensors expose the rest of the libcamera controls but hide AfMode.

## Official Raspberry Pi sensors

- OV5647 (Raspberry Pi Camera Module V1)
- IMX219 (Raspberry Pi Camera Module V2)
- IMX708 (Raspberry Pi Camera Module 3)
- IMX477 (Raspberry Pi HQ Camera)
- IMX500 (Raspberry Pi AI Camera)
- IMX296 (Raspberry Pi Global Shutter Camera)

## Third-party sensors

- IMX290 (Arducam IMX290 Mini Camera Board; Waveshare IMX290 Camera)
- IMX327 (Arducam IMX327 Starlight Camera; Waveshare IMX327 Camera)
- IMX378 (Arducam 12MP IMX378 Autofocus Camera)
- IMX519 (Arducam 16MP IMX519 Autofocus Camera; Waveshare IMX519 Camera)
- OV9281 (Arducam OV9281 Global Shutter Camera; Waveshare OV9281 Global Shutter Camera)

## Relevant info

- These sensors are supported by Raspberry Pi's `libcamera` implementation and are surfaced through the `rpi-libcamera` adapter on a Raspberry Pi camera node.
- Test the exact sensor, Pi model, and libcamera build before event use. Behavior can vary with the sensor revision, the Pi's camera stack version, and the cable used.
- The IMX500 (AI Camera) and IMX296 (Global Shutter Camera) have specialized modes that are outside the standard still-capture path. Confirm the capture mode you need before relying on them at an event.


Raspberry Pi

Reliable camera power is essential for a multi-camera rig. A camera that loses power during a live event can interrupt a capture, leave files incomplete, or make the rig appear to have a triggering or connection problem.

The only time batteries are usually the best option is on a portable rig, where branded Canon batteries can be more practical and last for a long time. For a permanent or event installation, use a stable external power solution so you do not have to change batteries during the event.

## What is what?

- **Coupler:** A plastic adapter with internal electronics that goes into the camera instead of the battery. It has the same shape as the specified battery.
- **Power supply:** A brick that converts regular alternating current into a continuous current source suitable for the camera.
- **Power cable:** The cable that connects the power supply to the coupler or USB adapter.

## Recommended options

Esper is a strong option for multi-camera installations. Its PowerBox is designed as a safe and reliable way to power several cameras simultaneously and can power up to six cameras.

- [Esper PowerBox](https://www.esperhq.com/product/multi-camera-power-supply-powerbox/) for powering several cameras from one unit.
- **Genuine Canon power adapters** from Canon or an authorized supplier. These are reliable but can cost around $100 USD per camera and require one adapter per camera.
- **USB adapters with a proper power supply** can be a compact and affordable option. Echpow adapters can work well when paired with a suitable charger, such as the [Anker 60W 10-Port USB Wall Charger](https://amzn.to/2xG8FyL).
- **No-name power adapters** should be treated cautiously. Some work for a single camera in a non-critical situation, but low-quality couplers or adapters can cause cameras to disappear after a shot. That is especially stressful on a bullet-time rig.

## Match the coupler to the camera

Couplers are shaped like batteries and only work with the camera models they are designed for. Check the exact camera model before ordering. Do not assume that a coupler for one Canon battery family will work with another body.

Couplers can be purchased separately from [Esper](https://www.esperhq.com/products/?show=dc_couplers) or [Tether Tools](https://tethertools.com/). For some Canon bodies, genuine Canon accessories may be the only suitable option.

![Different camera couplers for the same battery family](https://public.xangle3.com/doc/screenshots/2026-07-14/144bf904-32c6-4c8a-b516-4d33f7aedc2c.png)

Before an event, test the complete power chain with every camera connected: coupler, power supply, cable, hub or distribution point, and wall connection. Leave the rig running long enough to catch intermittent power loss before relying on it for a live capture.


Powering up your cameras

## What this is

The sacrifice camera is the camera that fires halfway through the exposure so the flash syncs on light instead of relying only on the mechanical shutter timing.

A flash trigger is mounted on top of the sacrifice camera. When that camera fires, the trigger sends one signal to all of your flashes at once. One flash trigger can drive one or multiple flashes.

## How to use it

1. Enable accuracy compensation for the group you want to shoot with flash.
2. Mount your flash trigger on the sacrifice camera.
3. Leave the sacrifice camera on the default last camera, or choose a different camera from the dropdown in the sacrifice panel.
4. Use Auto (half exposure) to start from the midpoint of the current shutter speed, then fine-tune with Shift by if needed.
5. Use Manual only when you want to enter a fixed millisecond delay yourself.

## Important

The image from the sacrifice camera is intentionally discarded. It is not downloaded and you will not see it in your dataset.

We have seen better results on Canon cameras, especially when using the popup flash, with a shift between -5 ms and -2 ms. Test to confirm what works best with your current configuration.


Sacrifice mode & flash

| Shortcut | Action |
| --- | --- |
| B (hold, then release) | Arm the trigger (warmup), then capture on release. |
| Ctrl + click trigger button | Auto-focus every lens once. |
| Ctrl + Shift + Y | Toggle two-click trigger mode on or off. |

The default trigger key is B. You can remap it from Button Mapping in the main menu. Gamepad B button mirrors the keyboard trigger by default.


Trigger

Sony cameras via USB. Sony support is newer than Canon and GoPro support. Test the exact body before event use, especially for video recording or file download.

## Supported models

- Sony RX0 II / DSC-RX0M2 (photo only, video capture is not supported on this body, see notes below)
- Sony RX1R III / DSC-RX1RM3
- Sony Alpha 1 / ILCE-1, Alpha 1 II / ILCE-1M2, Alpha 6700 / ILCE-6700, Alpha 7C / ILCE-7C, Alpha 7C II / ILCE-7CM2, Alpha 7CR / ILCE-7CR, Alpha 7 IV / ILCE-7M4, Alpha 7 V / ILCE-7M5, Alpha 7R IV / ILCE-7RM4, Alpha 7R IV A / ILCE-7RM4A, Alpha 7R V / ILCE-7RM5, Alpha 7S III / ILCE-7SM3, Alpha 9 II / ILCE-9M2, Alpha 9 III / ILCE-9M3
- ZV-E1, ZV-E10 II / ZV-E10M2, MPC-2610, PXW-Z200, PXW-Z300, PXW-Z380

## Additional notes

- Sony RX0 II / DSC-RX0M2: video capture is not supported. The body can shoot and download photos, but recorded clips stay on the camera SD card and cannot be pulled back to Camera Server over USB.
- For event work, test the exact Sony body, firmware, USB mode, and cabling before deployment.


Sony

Your guide to browsing, analysing, and downloading media from supported cameras and devices.

## What is camera storage?

This module lets you browse the media stored on connected cameras and mobile devices, verify that every trigger event was captured across the rig, and download the files as organized datasets ready for 3D processing.

## Best practices

- **Start every session with empty cards.** Format or delete all photos and videos from camera storage before shooting. Leftover files from a previous session confuse the shot-matching algorithm and produce false "incomplete" warnings.
- **Resync clocks before a long session.** Open the Network Nodes module and run "Resync clocks" if your Pis or cameras have been online for several hours. Clock drift accumulates over time and large drift can prevent the analyser from correctly matching shots across cameras.
- **Avoid accidental solo triggers.** A single camera triggered alone creates an extra shot entry. If you do fire a test shot on one camera, that is fine: the analyser marks it as a 1-camera solo and excludes it from dataset completeness counts.
- **Wait 3 to 5 seconds between shots.** The matching algorithm uses a 2-second clustering window. Firing faster than every 3 seconds may merge adjacent shots.
- **Use "Analyse All" before downloading.** This scans every camera, calibrates clock offsets, and shows you which datasets are complete or missing files before you commit to a download.

## How dataset matching works

When you click "Analyse All", the system scans every camera card and runs a calibrated timestamp clustering algorithm to determine which files across cameras belong to the same synchronized trigger event:

1. **Group files into captures.** Files with the same base name (for example IMG_0001.JPG + IMG_0001.CR2) are treated as one capture event, or one rendition set.
2. **Calibrate clock offsets.** Camera clocks drift apart over time. The analyser uses offset voting to determine the exact time difference between each camera and camera 1. This works even if clocks are minutes or hours apart.
3. **Cluster by adjusted time.** After normalizing timestamps, captures within a 2-second window that come from different cameras are grouped into a single shot. Each camera can appear at most once per shot.
4. **Classify completeness.** A dataset is complete when all cameras with cards have files for it, incomplete when some cameras are missing, and extra when only one camera fired.

## Dot colors

Each dataset row shows a dot per camera: **Present** (file found), **Missing** (no file for that camera).

## Download modes

- **New timestamp.** Downloads selected shots into your project's input folder using the current time as the dataset folder name, organized by camera. Ready for immediate 3D processing.
- **Photo dump.** Downloads raw files into a flat "Photo Dump" folder without organizing them into datasets. Useful for quick retrieval or manual sorting.

## Typical workflow

1. Format camera cards (start fresh).
2. Resync clocks from Network Nodes if needed.
3. Shoot your session.
4. Click "Analyse All" to see all matched shots and completeness status.
5. Review any incomplete datasets (check for missing cameras).
6. Select the datasets you want, choose "New timestamp" mode, and download.


Storage

Use this page to check whether a camera body belongs on the event rig. If a model is not listed, connect it and run a full test capture before relying on it at a live event.

> **Important:** As much as we would love to test every camera, there are simply too many models on the market. Please test with your own equipment so you can confirm whether this software suits your requirements. What we know for sure: Canon cameras have been, by far, the most used and most tested bodies for multi-camera setups, both with and without our software. Compatibility can vary with camera firmware, USB mode, cable quality, hub chipset, power delivery, drivers, and network conditions. If you plan to use third-party batteries or battery couplers, review the camera manufacturer's warranty terms and power guidelines before deployment.

## Details

- Listed models should be able to connect, trigger, and send files back to Camera Server when the camera is set up correctly.
- Camera names vary by region. For Canon Rebel / Kiss bodies, the European number and Japanese Kiss name are shown on the same line when known.
- Sony support is newer than Canon and GoPro support. Test the exact Sony body before the event, especially if you need video recording or file download.
- GoPro support covers HERO11, HERO12, and HERO13. GoPro over Wi-Fi is Experimental; USB is preferred for event work.
- iPhone and Android phones connect over Wi-Fi and are well supported for live view, photo, and video capture with the Xangle remote camera app.
- Webcam support is Experimental. It is still under development, but it currently works well for capturing photos or videos after testing the exact webcam and driver.

## EOS R mirrorless

- Canon EOS R, RP, Ra, R1, R3, R5, R5 Mark II, R6, R6 Mark II, R6 Mark III, R7, R8, R10, R50, R50 V / R50V, R100

## EOS M mirrorless

- Canon EOS M50 / EOS Kiss M, M50 Mark II / EOS Kiss M2, M6 Mark II, M200

## EOS DSLR bodies

- Canon EOS-1D X Mark III, 1D X Mark II, 1D X, 1D C, 1D Mark IV, 1D Mark III, 1Ds Mark III, 5D Mark IV, 5D Mark III, 5D Mark II, 5DS, 5DS R, 6D Mark II, 6D, 7D Mark II, 7D, 90D, 80D, 77D / 9000D, 70D, 60D, 50D, 40D

## EOS Rebel / numbered / Kiss bodies

- Canon EOS 850D / Rebel T8i / Kiss X10i, 250D / Rebel SL3 / Kiss X10, 2000D / 1500D / Rebel T7 / Kiss X90, 4000D / 3000D / Rebel T100, 200D / Rebel SL2 / Kiss X9, 800D / Rebel T7i / Kiss X9i, 1300D / Rebel T6 / Kiss X80, 760D / Rebel T6s / EOS 8000D, 750D / Rebel T6i / Kiss X8i, 1200D / Rebel T5 / Kiss X70, 100D / Rebel SL1 / Kiss X7, 700D / Rebel T5i / Kiss X7i, 650D / Rebel T4i / Kiss X6i, 600D / Rebel T3i / Kiss X5, 1100D / Rebel T3 / Kiss X50, 550D / Rebel T2i / Kiss X4, 500D / Rebel T1i / Kiss X3, 1000D / Digital Rebel XS / Kiss F, 450D / Digital Rebel XSi / Kiss X2

## PowerShot models

- Canon PowerShot V10, ZOOM, G7 X Mark III, G5 X Mark II, SX70 HS

## Supported Sony models

- Sony RX0 II / DSC-RX0M2 (photo only, video capture is not supported on this body, see Additional notes)
- Sony RX1R III / DSC-RX1RM3
- Sony Alpha 1 / ILCE-1, Alpha 1 II / ILCE-1M2, Alpha 6700 / ILCE-6700, Alpha 7C / ILCE-7C, Alpha 7C II / ILCE-7CM2, Alpha 7CR / ILCE-7CR, Alpha 7 IV / ILCE-7M4, Alpha 7 V / ILCE-7M5, Alpha 7R IV / ILCE-7RM4, Alpha 7R IV A / ILCE-7RM4A, Alpha 7R V / ILCE-7RM5, Alpha 7S III / ILCE-7SM3, Alpha 9 II / ILCE-9M2, Alpha 9 III / ILCE-9M3
- ZV-E1, ZV-E10 II / ZV-E10M2, MPC-2610, PXW-Z200, PXW-Z300, PXW-Z380

## Supported GoPro models

- HERO11, HERO12, HERO13
- GoPro over Wi-Fi is Experimental. USB is the preferred path for event work.

## Android phones

- Android phones running the Xangle remote camera app on the same event Wi-Fi network.
- Use Android phones when a Wi-Fi camera is useful for lightweight photo or video capture. Test the exact phone, lens, and Wi-Fi network before the event starts.

## iPhone

iPhones run the Xangle Remote Camera app on the same event Wi-Fi network and support live view, photo, video, autofocus, lens selection, and exposure settings (ISO, shutter, white balance). The app requires iOS 17 or later and must stay in the foreground during an event.

- iPhone 12, 12 mini, 12 Pro, 12 Pro Max
- iPhone 13, 13 mini, 13 Pro, 13 Pro Max
- iPhone SE (3rd generation)
- iPhone 14, 14 Plus, 14 Pro, 14 Pro Max
- iPhone 15, 15 Plus, 15 Pro, 15 Pro Max
- iPhone 16, 16 Plus, 16 Pro, 16 Pro Max, 16e
- iPhone 17, 17 Pro, 17 Pro Max, iPhone Air
- Newer iPhones that ship after this list still work on iOS 17 or later; they appear under their hardware identifier until the model name is added.

## Webcams (Experimental)

- USB webcams on Windows computers and Raspberry Pi / Linux camera nodes.
- Webcam support is Experimental, but photo capture and video capture are usable today when the exact webcam and driver have been tested.

## Raspberry Pi (libcamera)

Raspberry Pi MIPI CSI cameras driven by Raspberry Pi's `libcamera` stack on a Raspberry Pi camera node. The supported sensor list mirrors what Raspberry Pi's own `libcamera` implementation recognizes.

- Official Raspberry Pi cameras: OV5647 (V1), IMX219 (V2), IMX708 (V3), IMX477 (HQ), IMX500 (AI), IMX296 (GS).
- Third-party sensors: IMX290, IMX327, IMX378, IMX519, OV9281.
- Autofocus controls are only available on sensors that have a focus lens, such as the IMX708 (Camera Module 3). Fixed-focus sensors expose the rest of the libcamera controls but hide AfMode.
- Test the exact sensor, Pi model, and libcamera build before event use. Behavior can vary with the sensor revision, the Pi's camera stack version, and the cable used.

## Feature support by camera type and connection

### Windows

| Camera type | Connection | Photos | Video | Live view | Settings | Downloads | Storage | Operator note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Canon USB cameras | USB | Yes | Body-dependent | Yes | Yes | Yes | Yes | Main event-ready path for Canon rigs. |
| Sony USB cameras | USB | Yes | Yes | Yes | Yes | Yes | No | Test the exact body before the event. |
| GoPro HERO11-13 (USB) | USB | Yes | Yes | Yes | Yes | Yes | Yes | Preferred path for event work. |
| GoPro HERO11-13 (Wi-Fi, Experimental) | Wi-Fi | Yes | Yes | Yes | Yes | Yes | Yes | Experimental. Test on the real network before the event. |
| Android phones | Wi-Fi | Yes | Yes | Not yet | Yes | Yes | No | Use the Xangle remote camera app on the event Wi-Fi. |
| iPhone (iOS 17+) | - | No | No | No | No | No | No | Not supported on Windows. |
| USB webcams (Experimental) | USB | Yes | Yes | Yes | Basic controls | Yes | No | Experimental. Test the exact webcam and format. |

### Raspberry Pi

| Camera type | Connection | Photos | Video | Live view | Settings | Downloads | Storage | Operator note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Canon USB cameras | USB | Yes | Body-dependent | Yes | Yes | Yes | Yes | Good for distributed rigs when Canon support is enabled on the Pi. |
| Raspberry Pi (libcamera) | MIPI CSI | Yes | Yes | Yes | Yes | Yes | Yes | Sensor list mirrors Raspberry Pi's libcamera support. Test the exact sensor and Pi model. |
| Sony USB cameras | - | No | No | No | No | No | No | Not wired yet. |
| GoPro HERO11-13 (USB) | USB | Not tested | Not tested | Not tested | Not tested | Not tested | Yes | Not tested yet on Raspberry Pi. |
| GoPro HERO11-13 (Wi-Fi, Experimental) | Wi-Fi | Not tested | Not tested | Not tested | Not tested | Not tested | Yes | Not tested yet on Raspberry Pi. |
| Android phones | Wi-Fi | Not tested | Not tested | Not tested | Not tested | Not tested | No | Not tested yet on Raspberry Pi. |
| iPhone (iOS 17+) | - | No | No | No | No | No | No | Not supported on Raspberry Pi. |
| USB webcams (Experimental) | USB | Not tested | Not tested | Not tested | Not tested | Not tested | No | Not tested yet on Raspberry Pi. |

### Mac

| Camera type | Connection | Photos | Video | Live view | Settings | Downloads | Storage | Operator note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Canon USB cameras | USB | Yes | Body-dependent | Yes | Yes | Yes | Yes | Supported on Mac. Test the exact body and tethering setup before event day. |
| Sony USB cameras | USB | Yes | Yes | Yes | Yes | Yes | No | Supported on Mac. Test the exact Sony body before the event. |
| GoPro HERO11-13 | USB / Wi-Fi | Yes | Yes | Yes | Yes | Yes | Yes | USB is preferred for event work. Wi-Fi path is Experimental and should be tested on the real network. |
| Android phones | - | No | No | No | No | No | No | Not supported for event capture. |
| iPhone (iOS 17+) | Wi-Fi | Yes | Yes | Yes | Yes | Yes | No | Supported on Mac. Keep the app in the foreground during capture. |
| USB webcams (Experimental) | USB | Yes | Yes | Yes | Basic controls | Yes | No | Experimental on Mac. Test the exact webcam and format before event use. |

## Additional notes

Model-specific limitations worth knowing before an event:

- Canon EOS R5 C: not supported.
- Sony RX0 II / DSC-RX0M2: video capture is not supported. The body can shoot and download photos, but recorded clips stay on the camera SD card and cannot be pulled back to Camera Server over USB. This is a limitation of the camera itself, not of Camera Server. For video, use a different supported body.


Supported cameras

- Take one synchronized picture with all cameras from Trigger; this single shot is what alignment and outputs build on.
- If timing looks off, re-check warmup and the sacrifice / flash slider before changing the rig.


Sync & timing

- Hold the trigger button to warm up the rig before firing.
- Ctrl-click the trigger to auto-focus every lens. You normally only need to do this once per setup.


Trigger basics

USB webcams and capture devices. Webcam support is Experimental, but photo capture and video capture are already usable when the exact webcam and driver have been tested.

## Supported source

- USB webcams on Windows computers and Raspberry Pi / Linux camera nodes.

## Relevant info

- Test the exact webcam, driver, and capture format before event use.
- Experimental means it is still under active development and should not be assumed event-ready until your own test passes.


Webcam

Zones let you group your numbered cameras into named, overlapping subsets, for example "Head" and "Body" on a scan rig, so you can trigger and control part of your rig without renumbering anything.

## What is a zone?

A zone is a persistent, named list of cameras, managed from the Cameras page. Unlike camera numbering, zone membership does not change a camera's number or its licensing status, it only changes which group of cameras a zone represents.

- **Main** is a built-in, system zone. It always exists, cannot be renamed or deleted, and starts out containing every numbered camera. It is the direct equivalent of the old "Active" column. Any camera you number, import with a number, re-enable, or restore from a numbering backup is added to Main automatically, the moment it becomes roster-eligible, without you having to open Zones. On an existing install upgrading into the zones module, Main is also backfilled once from the current roster if it was left empty.
- Custom zones (such as "Head" or "Body") are created from the Cameras page and can be renamed, described, reordered, or deleted at any time.
- A single camera can belong to any number of zones at the same time. Adding a camera to "Head" does not remove it from "Main" or any other zone.

## Membership vs. the active zone

These are two different settings, and it is important not to confuse them:

- **Membership** is which zones a camera belongs to. Set with the checkboxes in each zone's column in the Cameras list.
- **The active zone** is the single zone currently selected as your default target. Set with the radio button in a zone's column header. Exactly one zone is active at any time.

Selecting a zone as active does not change any camera's membership. Removing a camera from a zone does not affect its membership in other zones.

## What the active zone controls

The active zone is used everywhere the app needs a default camera target:

- The camera count shown at the top of the Cameras page and in the app header.
- Which cameras actually fire when you trigger from Camera Control, Live View, or Sync from master, without explicitly choosing another target.
- The value of the `{zone}` naming token (see below).
- What "all cameras" resolves to in a Sequence step, unless that step explicitly targets a specific zone by name instead.

## Managing zones

Open **Zones** next to Import / Export on the Cameras page to:

- **Add** a new zone by name.
- **Edit** a custom zone's name, add a short one-line description, or change its position (this controls its column order in the camera list). Main cannot be edited.
- **Delete** a custom zone. This only removes that zone and its membership list, it never deletes or renumbers any camera. Main cannot be deleted.
- Turn on **Show selector on dashboard** to add a compact zone switcher under the trigger button on the Camera Control dashboard tile. Each row shows the zone's name, description, and camera count, and can be selected with a click or with `Ctrl+Shift+1` through `Ctrl+Shift+9`, matching the column order.
- Turn on **Remember camera settings per zone** to have the app save the current Camera Control settings (mode, ISO, aperture, white balance, and so on) each time you leave a zone, and restore that zone's own settings when you come back to it. See the next section for the details and the trade-offs.
- Click **Reset all** at the bottom of the modal to delete every custom zone, clear all saved per-zone settings profiles, and reactivate every roster-eligible camera under Main in one step. This is the fastest way back to a clean state if your zones have grown tangled, and it is also what a camera numbering reset (roster reset, or a numbering import) does automatically, since zone membership is scoped to the numbered roster. The action asks for confirmation and cannot be undone.

From the Cameras list itself, click a zone's name in its column header to **Activate all** or **Deactivate all** of its eligible cameras at once, a fast way to fill or clear a zone's membership.

## Remembering camera settings per zone

When **Remember camera settings per zone** is on, switching the active zone does two things: it snapshots the outgoing zone's current Camera Control settings into that zone's saved profile, and it restores the incoming zone's saved profile by pushing real commands to its cameras. This lets each zone carry its own mode and exposure setup, so "Head" can sit in a different drive mode or ISO than "Body" without you re-dialing it every time.

A few things worth knowing:

- **Main is a passthrough.** It never restores a saved profile. Whatever values the cameras currently hold when you switch to Main stay as they are, and whatever you change while Main is active becomes the live baseline that other zones can pull from. Switching to Main is therefore the safe way to dial in a starting point and then copy it into a zone.
- **Get settings from Main** and **Push settings to Main**, available from the dashboard selector when a non-Main zone is active, let you copy values between the live baseline and a zone's saved profile. "Get from Main" seeds the zone's profile from the current live values and applies them to that zone's cameras. "Push to Main" writes the zone's saved profile back into the live baseline (data only, no camera commands), so the next zone that does a "Get from Main" inherits it.
- **Re-push zone settings** (the small circular arrow next to the active zone name on the dashboard selector) re-sends the zone's current settings to all its cameras without changing the saved profile. Use it when a camera was offline during the last zone switch, or otherwise missed a commanded-state push, and has drifted out of line with the rest of the zone.
- Applying a zone can take a few seconds, especially for cameras shared between zones (they flip modes on every switch) or right after a capture, when a quiet window deliberately defers settings sends until transfers settle. The dashboard spinner stays up for the full push, and the display stays correct throughout via the app's commanded-state register, so you do not need to wait for the hardware to report back before trusting what the tiles show.
- A camera that belongs to a different zone than the one you have selected will not have its remembered settings pushed at launch or on reconnect, so reconnecting a camera does not silently change settings on a rig where you only meant to drive one zone.

## Using zones in Sequences

The Rules and Sequences module can target a step at:

- **Active zone**, which always resolves to whichever zone is currently selected, exactly like the default trigger behavior described above.
- A **specific zone by name**, which always resolves to that zone's membership, regardless of which zone happens to be active at the time the sequence runs.

This lets you build a sequence that always fires "Head" and "Body" in a fixed order, for example, independent of whatever zone an operator has selected for manual triggering.

## Using the {zone} naming token

The Naming module exposes a `{zone}` token for folder and file naming templates. When a trigger fires, the app records which zone was active at that moment, and uses that zone's name to resolve `{zone}` for every file produced by that capture, even if the active zone is changed again before all files finish transferring.

This is useful for keeping datasets organized by rig section, for example a folder template such as `{timestamp}-{zone}` produces folders like `260722-143000-head` and `260722-143512-body` as you switch the active zone between shots.

## Tips

- Keep zone names short. They appear as column headers in the Cameras list and as row labels in the dashboard selector.
- A camera that is temporarily disconnected keeps its zone membership. It is simply excluded from the active count and from triggering until it reconnects.
- If you delete a zone that a saved sequence step targets by name, that step will report the zone as not found instead of silently falling back to another zone.
- If a camera's settings look wrong after a switch (for example it was unplugged during the last zone change), use the re-push arrow on the dashboard selector before reaching for Reset all. Re-push is non-destructive and only re-sends the current zone's settings.
- Reset all is the clean-slate option: it wipes custom zones and saved profiles but leaves your camera numbering intact, so you can rebuild your zones without renumbering anything.


Zones

Use this guide when the default Xangle boot network conflicts with another network or when preparing a fresh boot-server card.

## Before you change anything

A boot-server network change affects three parts of the system:

- The boot server's static Ethernet address.
- DHCP, TFTP, and NFS settings on the boot server.
- The boot-server address embedded in the cardless clients' network-boot command line.

Use a dedicated Ethernet adapter for the isolated boot network. Keep the computer's normal LAN or Wi-Fi connection separate for internet access.

The subnet and server address must match. For example:

```text
Subnet: 10.72.0.0/21
Server IP: 10.72.0.211
```

Do not use `10.52.1.0` as the subnet with `/21`; a `/21` subnet must start on a multiple of eight in the third octet.

## Edit the card

1. Shut down the boot-server Pi cleanly and remove its microSD card.
2. Insert the card into Windows. The FAT boot partition may appear as `E:`. The drive letter can differ.
3. Open:

   ```text
   E:\xangle\boot-network.conf
   ```

4. Edit the values, keeping the file as plain text:

   ```ini
   MODE=boot-server
   SUBNET=10.72.0.0
   PREFIX=21
   SERVER_IP=10.72.0.211
   ```

5. Make sure the boot-server card still contains `boot-server-configured` and `configure`, and does not contain `reset`.
6. Safely eject the card and put it back in the Pi.
7. Boot the Pi. The boot-network service validates the file and updates the static address, DHCP settings, and netboot command lines.
8. Restart the Windows computer, or disable and re-enable its dedicated Ethernet adapter.
9. Leave the adapter set to obtain an IP address automatically. The boot server's DHCP service should assign it an address in `10.72.x.x`.
10. Reboot the cardless clients only after the Windows adapter has a `10.72.x.x` address and the boot server responds at `10.72.0.211`.

## If Windows does not get an address

Use this manual configuration only when the dedicated adapter remains on `169.254.x.x` or otherwise receives no DHCP lease. Run PowerShell as Administrator, and replace `Ethernet 3` with the actual adapter name:

```powershell
Set-NetIPInterface -InterfaceAlias "Ethernet 3" -Dhcp Disabled

Get-NetIPAddress -InterfaceAlias "Ethernet 3" -AddressFamily IPv4 |
   Remove-NetIPAddress -Confirm:$false

New-NetIPAddress `
   -InterfaceAlias "Ethernet 3" `
   -IPAddress 10.72.0.50 `
   -PrefixLength 21 `
   -AddressFamily IPv4
```

Leave the gateway and DNS fields empty. Do not use the boot server's address on the Windows adapter.

Check the adapter and boot server:

```powershell
Get-NetIPAddress -InterfaceAlias "Ethernet 3" -AddressFamily IPv4
Test-Connection 10.72.0.211
```

The standard default file is:

```ini
MODE=boot-server
SUBNET=10.42.0.0
PREFIX=21
SERVER_IP=10.42.0.211
```

If the file is absent, the existing boot-server configuration is left alone.

## Fresh-image requirement

The Windows file works only when the image or XNN bundle includes the boot-network helper and boot service. If `E:\xangle\boot-network.conf` is missing from a fresh card, the image does not support this workflow yet.

## Safety and recovery

Do not reboot cardless clients until the Windows adapter has a lease on the new subnet and the boot server responds.

If the boot server becomes unreachable:

1. Restore the previous values in `E:\xangle\boot-network.conf`.
2. Restore the previous static address on the dedicated Windows adapter.
3. Boot the server again.
4. Confirm the boot server responds before rebooting cardless clients.

When the previous values are the standard Xangle network, restore:

```ini
MODE=boot-server
SUBNET=10.42.0.0
PREFIX=21
SERVER_IP=10.42.0.211
```

Do not edit or remove the Pi bootloader EEPROM configuration as part of this network change. Network boot still depends on the cardless clients' boot order.


Change the boot-server network

- On a boot-server setup, keep the boot subnet isolated with no router and no second DHCP server.
- Connect the computer's Ethernet only to the boot-server switch stack, and keep internet on Wi-Fi or a second NIC.


Boot server not responding

- Brand-new Pis default to SD-card boot. Boot once from a flashed card to set the EEPROM to try network boot first, then remove the card.
- Cardless clients must be Pi 4 or newer; network boot is not supported on Pi 3.


Cardless nodes won't register

- Confirm the Pi and this computer share a subnet, and that the adapter shows a Broadcasting badge.
- Check link lights on both switch ports and confirm the cable reaches the same switch.
- An adapter showing a 169.254.x.x address is connected but never got a DHCP lease.
- Use Find my Pis to actively probe the subnet when UDP broadcast is blocked.


Node never appears

- Choose the XangleOS image for the Pi's boot arrangement. XangleOS is the operating system; XNN is the network-node software installed on top of it.
- Standalone image: the complete XangleOS on a single microSD card, one card per Pi. This is required for older boards (Pi 3B / 3B+) and is recommended when capturing larger files such as video or burst sequences. Standalone Pis live on your normal routed LAN alongside your computer, router, and switches.
- Boot server image: turns one Pi into the central operating system for all of your Pis. Only the boot-server Pi needs a card; every other Pi boots from the network (PXE/NFS). This removes batch SD flashing, avoids corrupted-card issues, and makes system-wide updates instant. The boot server needs a Pi 4 or 5 with at least 4 GB of RAM, and cardless clients must be Pi 4 or newer, since network boot is not supported on Pi 3.

Choose your image

- Standalone setup: one computer, one router, many switches, and many standalone Pis, all sharing the same normal LAN. This is the easiest layout to manage.
- Boot-server setup: one computer, many switches, one Pi boot server, and many cardless Pis on a dedicated, isolated Ethernet segment with no router and no other DHCP server on it. Keep internet on Wi-Fi or a second NIC, and connect the computer's Ethernet port only to the boot-server switch stack.

Plan the network

1. Download the desired XangleOS image (.img.gz or .img) from xangleapps.com. This installs the operating system, not XNN.
2. Install Rufus (free and portable, no installation required). balenaEtcher or the Raspberry Pi Imager also work.
3. Insert the card, then in Rufus pick it under Device, click SELECT, choose the image, leave the other settings at their defaults, and click START. This erases everything on the card.
4. Eject the card safely, insert it into the Pi, and power it on.

After the Pi boots and appears in Network Nodes, install or update XNN separately:

1. Open **Network Nodes** in Camera Server and choose **Download XNN packages...**.
2. Select the Raspberry Pi package that matches the Pi architecture and download it. Camera Server stores the package in its local network-node bundle directory.
3. Choose **Push XNN...** in the Raspberry Pi list, select the downloaded package, and push it to the target Pi or Pis.
4. Wait for the update to finish, then confirm the XNN Version and camera or light service status in the node list.

You only need to flash the XangleOS image again when preparing a new card or replacing the operating system. For a normal XNN update, download the package and use **Push XNN...**.

Flash a microSD card

Boot-server setups only.

- A brand-new Pi defaults to SD-card boot order, so boot it once from a flashed card to configure its EEPROM to try network boot first.
- After that one-time boot, remove the card. The Pi will PXE-boot from the boot server automatically on every subsequent power-on.

First boot for cardless Pis

- The Pi and this computer must share a subnet. Each network adapter with a Broadcasting badge sends beacons to its subnet, and nodes there register automatically.
- After connecting, allow up to about 10 seconds (the beacon interval) for a node to receive a beacon and register, then click Refresh.
- If a node never appears, check the link lights on both switch ports and confirm the cable reaches the same switch. An adapter showing a 169.254.x.x address is connected but never got a DHCP lease.
- Use Find my Pis to actively probe the subnet for a live XangleOS agent when UDP broadcast is blocked by a switch or router. On a boot-server setup this probes the boot subnet and finds Pis even if beacons are blocked.

Confirm discovery

- Camera Nodes carry remote capture adapters so cameras can sit far from the computer.
- XNN (Xangle Network Node) is the host software installed on a Raspberry Pi. It registers the Pi with Camera Server and provides the control path for attached camera and light services.
- Network Nodes is the inventory and host-operations view for every Pi the server can see.
- Devices covers connected browser stations (sharing, replay, kiosk) rather than capture hardware.

Camera, Network & Devices

For rigs with 24 cameras or less, the preferred setup is USB-only on one computer. This keeps topology simple and works well when power and hub layout are controlled.

## When USB-only is the right choice

- Use this path for compact bullet-time and small scan rigs where all cameras can be cabled to one host reliably.
- Keep all capture cameras on wired USB. Avoid mixing test Wi-Fi cameras into the production rig.
- Use this mode when your trigger and transfer tests are consistently clean at full camera count.

## Hardware and wiring checklist

1. Use a stable Windows host with enough USB bandwidth for your camera count and media mode.
2. Use high-quality powered USB hubs. Do not rely on unpowered hubs for event rigs.
3. Distribute cameras across multiple hubs and ports instead of overloading one branch.
4. Use short, reliable USB cables and strain-relief them so they cannot be pulled during operation.
5. Label every cable and hub port to match physical camera position.

## Setup flow (USB-only)

1. Connect hubs first, then connect cameras in rig order.
2. Power cameras on in order and wait for full discovery in Cameras.
3. Run Re-number once all expected cameras are visible.
4. Manually adjust any slot mismatches from Set camera number.
5. Run one complete trigger and download cycle before alignment work.

## Stability practices before event day

- Do a full-duration soak test at production camera count, not a short bench check.
- After numbering and alignment validation, avoid moving hubs, cables, and USB port assignments.
- Keep one spare powered hub and known-good cable set on-site for fast recovery.
- If one camera branch becomes unstable, isolate that branch and retest trigger plus download before reopening to users.


24- cameras

For rigs above 24 cameras, use Raspberry Pi camera nodes to improve stability and throughput. Ethernet-distributed nodes are more reliable than pushing all cameras through one host USB stack.

XangleOS Raspberry Pi images (Standalone and Boot-server) can be downloaded from xangleapps.com.

## When to choose Raspberry Pi nodes

- Use Pi nodes when one computer starts to show USB saturation, unstable reconnects, or inconsistent trigger-to-download timing.
- Use Pi nodes when physical camera groups are far apart and easier to aggregate per zone, then uplink by Ethernet.
- Prefer wired Ethernet for event operation. Keep Wi-Fi for setup convenience only.

## Choose the deployment model

- Standalone image: each Pi uses its own microSD card. Best for smaller distributed rigs and straightforward field swaps.
- Boot-server image: one Pi hosts the boot environment and additional Pi clients boot over network with no SD cards. Best for large rigs that need centralized control and faster node replacement.

## Preparation checklist

1. Download the correct Pi image package from xangleapps.com.
2. Prepare quality power supplies for every Pi and powered USB hubs for camera groups.
3. Label each Pi, hub, Ethernet run, and camera branch before deployment.
4. Use a dedicated switch for camera-node traffic whenever possible.
5. Keep Camera Server and all Pi nodes on the same routed network segment during setup and validation.

## Standalone image workflow

1. Flash the Standalone image to one microSD per Pi.
2. Boot each Pi, connect Ethernet, then connect its assigned camera subset over USB.
3. Wait for nodes to appear in Camera Server Network Nodes, then verify each node camera count.
4. Power cameras on in rig order and run Re-number from the Cameras module once all expected cameras are present.
5. Run a full trigger and download test with all nodes online before event day.

## Boot-server workflow

1. Flash and boot the Boot-server Pi image on the designated host Pi.
2. Bring up client Pis on Ethernet with no SD card, then confirm they receive network boot from the host.
3. Connect cameras to each client Pi using powered hubs and stable cabling.
4. In Camera Server, confirm all nodes and expected camera totals before numbering.
5. After discovery stabilizes, run one full capture cycle to validate trigger, transfer, and consistency across all clients.

## Operational best practices

- Do not mix ad-hoc USB and node topology changes right before show time.
- Keep cabling and power topology fixed after alignment and numbering are validated.
- If a node drops, recover that branch first, then re-run a complete trigger and download validation pass.
- Keep one spare pre-imaged Pi and spare hub ready for rapid replacement.


24+ cameras

This page records a 4D Gaussian Splatting pipeline built around a synchronized multi-camera capture. It is an experimental post-processing workflow rather than a built-in Camera Server process task. Tool versions, scripts, and model-training settings change quickly, so verify each external project's current instructions before starting.

## Capture and organize the source dataset

1. Use Camera Server Camera control to connect, synchronize, and trigger the cameras.
2. Capture a complete image sequence with consistent exposure, focus, and lighting.
3. Keep the original dataset intact and make a working copy for frame extraction and reconstruction.
4. Confirm that camera numbering, timestamps, filenames, and audio or trigger references are preserved.

The quality of the temporal result depends on consistent capture timing and camera registration. Fix missing or misnumbered source files before moving to training.

## Example pipeline

The legacy workflow used these stages:

1. **Camera control and trigger:** Xangle Camera Server.
2. **Sound synchronization and frame extraction:** [PeakAlign](https://github.com/xanglestudio/PeakAlign).
3. **Camera registration:** RealityScan or a compatible RealityCapture workflow.
4. **Sparse point-cloud generation per frame:** RealityScan driven by a custom script.
5. **Gaussian Splat training:** Postshot using a custom script and an MCMC-based training workflow.
6. **Floater removal:** [PointNuker](https://github.com/Dymensium/PointNuker).
7. **Compositing and review:** After Effects with a Gaussian Splat importer and a flicker-reduction tool where needed.

This list is a pipeline map, not a claim that each tool is required or supported by Camera Server. Keep the intermediate files for every stage so a failed training run does not require a new capture.

## Camera registration and frame preparation

Register the cameras using a clean reference dataset and the current RealityScan or RealityCapture workflow. Review the solved camera positions before generating per-frame point clouds.

Use PeakAlign or an equivalent tool to relate the sound or trigger event to the extracted image frames. Check the offset on a short test sequence before extracting the complete production range. Keep the source audio, frame numbering, and offset values together in the working project.

## Training and cleanup

Train the splat from the registered per-frame data using settings appropriate for the available GPU and the intended playback quality. Training time and memory use vary with camera count, frame count, resolution, and scene complexity.

After training:

- Review the motion for temporal drift and flicker.
- Remove floaters conservatively so valid moving details are not lost.
- Check the beginning, middle, and end of the sequence, not only a representative frame.
- Export an intermediate preview before committing to a long final render.

## Feed-forward 4DGS evaluation (July 2026)

The pipeline above is per-scene optimization: registration plus training per capture, measured in hours. Feed-forward 4DGS models predict the dynamic Gaussian representation in a single forward pass, which makes them candidates for a built-in Camera Server process task comparable to the Extractor. Findings below come from reviewing the feed-forward section of the [awesome-4dgs](https://github.com/awesome-4dgs/awesome-4dgs) catalog.

### Candidate models

| Model | Input | License | Fit for Xangle rigs |
|---|---|---|---|
| [NoPo4D](https://github.com/bralani/NoPo4D) | Unposed multi-view video, CLI folder-of-images inference | MIT | Best fit. Skips COLMAP and registration entirely. Camera-major frame naming matches Camera Server dataset layout. |
| [C4G](https://github.com/cvlab-kaist/C4G) | Multi-frame video, query-based Gaussian decoder | License not stated, must be confirmed before use | Strong second. Compact Gaussians are attractive for streaming output. |
| [L4GM](https://github.com/nv-tlabs/L4GM-official) | Monocular video, background-removed 256x256 crop | Apache-2.0 | Object-centric and single-view. Wrong shape for a rig. |
| [4DGT](https://github.com/facebookresearch/4DGT) | Monocular, tuned for Project Aria data | CC-BY-NC | Excluded. Non-commercial license. |

Sparse-view options (4C4D, UFO-4D, HiReFF) become relevant only if rig density drops to 2 to 4 cameras.

### Rig context

Xangle rigs are 4 to 250 cameras in fixed positions. Two consequences:

- **Calibration is reusable.** Fixed rigs mean poses are constant across captures. Even though NoPo4D runs pose-free, known intrinsics and extrinsics can be fed in or used to verify predictions, removing the biggest feed-forward failure mode.
- **Camera count is the open risk.** NoPo4D benchmarks top out at 18 to 21 cameras (Neural 3D Video dataset). At 100+ views, encoder memory and attention distribution shift are unproven. Mitigation: batch cameras into overlapping spatial groups of 8 to 16 adjacent cameras sharing anchor views, reconstruct per group, and stitch using the fixed rig geometry. Groups also parallelize across the process-task queue.

### Validation plan

1. **4-camera spike.** Run `src/inference.py --num_cameras 4` on an existing small-rig capture as-is. Confirm output quality, VRAM use, and runtime per second of capture.
2. **16-camera mid-size test.** Run a bullet-time rig subset near N3DV density. This is the threshold that shows whether quality holds at the density the model was benchmarked at.
3. **View-batching experiment.** Run a full 100+ camera capture through camera groups. Measure per-group cost and check for seams at shared anchor views.

If step 1 passes, write the process-task wrapper with a `--cameras camA,camB,...` window parameter from day one, so the same runner serves small rigs directly and large rigs through batching without a redesign.

### Integration notes

- Environment: Python 3.10+, CUDA GPU, PyTorch 2.x, xformers, gsplat backend, Depth Anything 3 as a vendored submodule. Expect roughly 16 GB VRAM as a working floor (4DGT's stated minimum; NoPo4D does not publish one).
- The Depth Anything 3 submodule license must be verified before shipping, and every vendored dependency needs a THIRD-PARTY-NOTICES entry.
- A test dataset is being prepared from a real rig capture for the spike.

## Current limitations

The original article was marked as a work in progress. There is no universal Camera Server button that completes this pipeline. Custom scripts, RealityScan, Postshot, PointNuker, and compositing tools remain external dependencies with their own licensing, hardware, and version requirements.

Document the Camera Server build, camera layout, frame rate, audio offset, registration project, scripts, training settings, and cleanup decisions with each production. That record is more useful than copying a fixed benchmark from an older rig.


4D Gaussian Splatting processing

Use this workflow when you need a textured OBJ from a RAW photo set captured with Xangle Camera Server. Camera Server handles the capture and dataset organization; the reconstruction and export happen in an external photogrammetry application such as RealityCapture or RealityScan.

## Prepare the image set

1. Import the RAW files into Lightroom Classic, Capture One, or another RAW processor.
2. Apply consistent adjustments across the complete set:
   - Enable lens correction when appropriate.
   - Set one consistent white balance.
   - Adjust exposure only when necessary.
   - Remove chromatic aberration.
   - Avoid aggressive edits that differ from camera to camera.
3. Synchronize the adjustments across all images.
4. Export full-resolution JPEGs in sRGB. Use PNG only when the downstream workflow requires it. Keep the original dimensions and choose a quality setting that preserves the detail needed for reconstruction.
5. Place the exported images in a dedicated working folder. Keep the RAW originals and processed exports separate.

For a dataset captured in Camera Server, use the completed dataset folder as the source and make a separate post-processing export. Do not edit or rename the original capture files while reconstruction is in progress.

## Create the photogrammetry project

1. Open RealityCapture or RealityScan.
2. Create a new project and save it immediately in a working folder alongside, or beside, the processed image folder.
3. Add the exported images through the application's current image-import workflow.
4. Wait until all images are loaded and confirm that the expected camera count and image set are present.

Menu names vary by application version. Use the current equivalent of **Add Images**, **Align Images**, **Reconstruction**, **Texture**, and **Export Model** rather than relying on an old menu path.

## Align the cameras

1. Run image alignment.
2. Inspect the estimated camera positions in the 3D view.
3. Confirm that the sparse point cloud covers the subject and that the cameras form the expected rig arrangement.
4. If cameras fail to align, check for missing files, blurred frames, inconsistent exposure, reflections, or insufficient overlap. Remove only clearly unusable images and run alignment again.

Do not continue to a detailed reconstruction until the alignment is complete enough for the subject and the camera arrangement you need.

## Build and clean the mesh

1. Choose a reconstruction detail level that fits the available GPU memory and the final use of the model.
2. Generate the mesh.
3. Inspect it for holes, missing areas, floating geometry, floor or background surfaces, and other reconstruction artifacts.
4. Use the selection tools in the 3D view to remove unwanted geometry.
5. Simplify the mesh only when the target application needs a lower polygon count. Keep a high-detail project or export available for later reference.

A model intended for animation, clothing simulation, or real-time viewing usually needs a lighter, cleaner mesh than a model intended for archival geometry.

## Generate textures

1. Bake a texture only when the downstream workflow needs surface color or visual reference.
2. Choose a texture resolution and texture count that fit the GPU and the target application.
3. Generate the texture and inspect seams, missing areas, and color consistency.

Large textures increase memory use and export size. Use the highest resolution that the final workflow can actually display or edit.

## Export the OBJ

1. Use the current model-export workflow and choose Wavefront OBJ.
2. Export the mesh and texture or material files when textures were generated.
3. Save the export with its `.obj`, `.mtl`, and texture files together.
4. Preserve the project file and source images so the model can be rebuilt if settings or cleanup need to change.

## Verify the export

Open the OBJ in Blender, Cinema 4D, or the target 3D application and check:

- The mesh opens without missing parts.
- Textures and materials are found and mapped correctly.
- The orientation and scale are appropriate.
- Unwanted background geometry has been removed.
- The polygon count is practical for the next stage.

If the model must match real-world dimensions, define scale in the photogrammetry project using a known measurement before export. Record the measurement and units with the project.


Build an OBJ from RAW files in RealityCapture

Small experiences (6 to 18 cameras).

1. Connect cameras in the correct order, then click the re-number action in the camera list.
2. Pre-align cameras to a center pole. Use a light stand with colored tape and the live-view grid for straight framing.
3. Ctrl-click the trigger button to auto-focus the lenses. You only need to do this once.
4. Set camera layout to Arc or 360, depending on your physical rig.
5. Place a person or object in the center of the frame, ideally wearing textured clothing, then take one synchronized picture with all cameras.
6. Open that dataset in Library, then go to Registration & Alignment.
7. Run registration with Cloud service, RealityScan or 2D markerless.
8. If the result is good, set that dataset as the reference from the dataset kebab menu in Library.
9. Configure Outputs and sharing for the deliverables guests will receive.


Bullet-time booth

This example shows how a full-body scan captured with a synchronized Xangle camera rig can become an animated character with simulated clothing. Camera Server produces the synchronized image dataset; Cinema 4D, Rokoko, AccuRig, iClone, Marvelous Designer, and the final renderer handle the rest of the workflow.

The exact camera count, scan rig, software versions, and menu names in the original example are historical. Use the rig and software available for the current production.

## Workflow overview

1. Capture a full-body scan with Camera Server.
2. Convert the source images and reconstruct an OBJ in RealityCapture or RealityScan.
3. Clean and scale the mesh in Cinema 4D or another 3D package.
4. Record motion with Rokoko or another motion-capture system.
5. Rig the mesh with AccuRig or an equivalent tool.
6. Retarget and clean the animation in iClone, Cinema 4D, or Blender.
7. Extract a garment from a second scan if needed.
8. Simulate the garment in Marvelous Designer or CLO3D.
9. Apply materials and lighting.
10. Composite and render the final animation.

## 1. Capture and reconstruct the body

Capture the subject with consistent lighting, exposure, focus, and pose. Keep the Camera Server dataset unchanged and create a working copy for RAW conversion and reconstruction.

Convert the source images to consistently processed JPEGs with Lightroom, Capture One, or an equivalent tool. Align the images in RealityCapture or RealityScan, generate a mesh, clean the background geometry, and export an OBJ with the required textures. See [Build an OBJ from RAW files in RealityCapture](/wayfinder/post-processing/building-obj-from-raw-files-realitycapture) for the detailed reconstruction path.

## 2. Clean the mesh in Cinema 4D

1. Import the OBJ and confirm its orientation, scale, materials, and texture paths.
2. Remove floor, background, and reconstruction artifacts.
3. Close holes and repair open edges that would interfere with rigging or cloth collision.
4. Retopologize when the scan topology is unsuitable for deformation.
5. Reduce the polygon count only as much as the animation and render require.
6. Set a meaningful real-world scale and place the model in a predictable scene orientation.

Keep a high-detail scan separate from the animation-ready version so later changes do not destroy the source geometry.

## 3. Record motion

1. Put on and calibrate the motion-capture suit or use another tracked motion source.
2. Record a short test performance first.
3. Review the skeleton and timing before recording the full movement.
4. Export the motion as FBX or BVH, depending on the target application.

The motion file and the character mesh must use compatible coordinate systems and frame rates. Write those settings down with the project.

## 4. Rig the avatar

1. Import the cleaned mesh into AccuRig or the rigging tool used by the production.
2. Place the joint markers on the anatomical landmarks.
3. Review the generated skeleton and skin weights.
4. Correct problem areas around shoulders, elbows, knees, hands, and hips.
5. Export a rigged FBX with a standard humanoid skeleton.

Test the rig with a simple pose before importing a long motion recording.

## 5. Retarget and clean the animation

Import the rigged character and motion file into iClone, Cinema 4D, Blender, or the chosen animation package. Retarget the motion and inspect:

- Foot sliding and contact
- Jitter in the hands or head
- Arm and body intersections
- Unnatural joint rotations
- Loops and transitions

Smooth or correct the animation, then export a cleaned version for clothing simulation.

## 6. Extract and simulate clothing

For a garment based on a second scan:

1. Import the scan of the subject wearing the garment.
2. Isolate the garment geometry.
3. Split it into a separate object.
4. Clean, repair, and simplify the garment mesh as needed.
5. Export it in the format required by Marvelous Designer or CLO3D.
6. Import the animated character and garment.
7. Match scale, orientation, and starting pose.
8. Set cloth weight, stiffness, collision, and simulation settings.
9. Run a short simulation and fix collisions before simulating the complete animation.

A clean, correctly scaled avatar and garment reduce simulation failures. Keep the original scan available for reference rather than using it directly as the simulation mesh.

## 7. Materials, lighting, and render

Bring the character and garment into Cinema 4D or the chosen render package. Apply scan textures and materials appropriate to the final look. Configure lighting, camera motion, and render settings for the intended output.

Export a short preview first. Review animation, cloth behavior, texture seams, and flicker before rendering the complete sequence. Use After Effects, DaVinci Resolve, or another compositor for grading and final assembly when needed.


Cinema 4D avatar workflow

Use this workflow to turn a photogrammetry capture into a correctly scaled OBJ avatar for Marvelous Designer or CLO3D. Camera Server supplies the synchronized image dataset. RealityCapture or RealityScan creates the mesh, and Blender is an optional cleanup and scale-check stage.

The source guide referred to a specific historical studio camera count and old menu paths. The important requirements are a clean, well-overlapped image set and a known real-world measurement, not a fixed camera count.

## Prepare the scan

1. Capture the subject in a simple pose with the arms slightly away from the body.
2. Keep lighting, exposure, focus, and subject position consistent across the dataset.
3. Export a working copy of the Camera Server dataset.
4. Convert RAW images to consistently processed JPEGs with Lightroom, Capture One, or another RAW processor.

Keep the original RAW files and the processed exports separate. Do not overwrite the captured dataset while preparing the photogrammetry input.

## Reconstruct the avatar

1. Open RealityCapture or RealityScan and create a project.
2. Add the processed image set.
3. Align the images and review the camera positions and sparse point cloud.
4. Build a mesh at a detail level appropriate for cleanup and clothing simulation.
5. Remove the floor, background, noise, and other unwanted geometry.
6. Simplify the mesh to a practical polygon count for the target application. The right count depends on the subject and simulation needs; do not treat an old fixed triangle range as universal.
7. Generate a texture only if it is useful as a visual reference. A texture is optional for a base avatar used primarily for garment fitting.

## Set real-world scale

Scale is essential because CLO3D and Marvelous Designer use real-world garment dimensions.

### Scale in RealityCapture or RealityScan

1. Complete the reconstruction and open the scale or ground-plane workflow in the current application.
2. Place control points on two locations with a known distance, such as the top of the head and the floor, or two measured body landmarks.
3. Enter the measured distance and its units.
4. Apply the scale and transformation.
5. Record the measurement and units with the project.

Use measurements taken from the subject or capture setup. A guessed height can produce a visually plausible model that still causes incorrect garment dimensions.

### Check or scale in Blender

If the photogrammetry project was not scaled:

1. Import the OBJ into Blender.
2. Open the Sidebar with `N` and use the Measure tool or a known reference object.
3. Scale the model until its dimensions match the recorded measurements.
4. Apply the scale with `Ctrl+A` and **Apply Scale**.
5. Set the origin to the geometry and verify the forward and up axes expected by the target application.
6. Export a new Wavefront OBJ with units and scale preserved.

The exact axis conversion depends on the target software and export version. Test the OBJ with a copy of the project before committing to a production workflow.

## Export the avatar

Export the cleaned, scaled mesh as Wavefront OBJ. Include the material and texture files only when they are needed for the intended use. Keep the `.obj`, `.mtl`, and texture files together in one folder.

Before import, verify:

- The mesh is at the intended centimeter scale.
- The pose is suitable for garment fitting.
- The origin and axes are predictable.
- There is no unwanted floor or background geometry.
- The polygon count is practical for simulation.

## Import into CLO3D or Marvelous Designer

Use the current application workflow to add the OBJ as an avatar or background OBJ, depending on whether garments must collide with it or only be aligned to it. Confirm the imported height and a second known measurement before creating patterns.

Use the avatar for:

- Garment draping and fit checks
- Pattern alignment
- Pose reference
- Custom mannequins

Run a short garment simulation first. Check collisions around the shoulders, arms, hips, and feet before increasing particle distance or simulating a longer animation.

## Practical scan tips

- Use a simple pose with a small gap between the arms and torso.
- Measure height, shoulder width, and another useful body dimension before reconstruction.
- Keep the scan texture separate from the simulation mesh when performance matters.
- Save the scale measurement, export settings, and software versions with the OBJ.
- If the avatar appears at the wrong size, fix units and scale before adjusting garment patterns.


Create custom avatars for Marvelous Designer and CLO3D

| # | Question | Answer |
| --- | --- | --- |
| 1.1 | Do I need an internet connection? | Only to validate your license, once at launch, and once every 24 hours. After that you can go offline. The server runs locally on your machine. |
| 1.2 | How often are new versions released? | At least one version every two months. We actively add features and improve performance. |
| 1.3 | Can I use a second monitor with the Basic version? | Yes. Basic and higher can open replay or sharing tiles on a connected second monitor from the dashboard monitor icon. Pro is required for browser pages and stations on separate devices. |
| 1.4 | Can I remove the Xangle logo? | With a Pro license you can replace the logo and app title shown in the header. Other branded elements (Windows taskbar title, footer credits) cannot be altered. Injecting substitute values in those areas violates the terms and conditions. |

1 — Software

| # | Question | Answer |
| --- | --- | --- |
| 2.1 | How can I upgrade my license? | Monthly to yearly: upgrade within the first 10 days and the monthly payment is credited. Yearly: remaining time is credited toward the new license. Contract licenses can be upgraded any time. Downgrades are not available. |
| 2.2 | Can I use the software on two computers? | One computer at a time. Log out (top-right menu) before logging in elsewhere. If your machine crashes, the session token expires automatically after 24 hours, or we can reset it manually. |
| 2.3 | Can I split a 24-camera license into two 12-camera setups? | No. One license = one computer. You can add Raspberry Pi or Windows nodes to scale transfer speed, but everything runs under a single server. |
| 2.4 | Can I get a trial license? | Yes, fill out the form on the website. The trial is limited to 4 cameras for 7 days. |
| 2.5 | What are the trial limitations? | Full Pro features for evaluation only, not for production events. The daily trigger count is limited. |
| 2.6 | Can I use the software after my license expires? | No. A valid, active license is required at all times. |
| 2.7 | Single vs Contract license? | Single: 31 or 365 days, no auto-renewal. Contract: 12-month commitment with monthly billing, not cancellable mid-term. |
| 2.8 | How do I renew? | Single licenses do not auto-renew, you get a reminder two weeks before expiry. Purchase a new license using the same email address and it appears immediately in your account. |
| 2.9 | At what exact time does my license expire? | Sign in at [xangleapps.com](https://xangleapps.com), open the Licenses page, and check the expiry date and time shown for your license. The timestamp is displayed in your browser's local time zone. |

2 — License & payments

| # | Question | Answer |
| --- | --- | --- |
| 3.1 | What is the best distance between cameras / subject? | It depends on the effect you want. Closer cameras = smoother result over a smaller arc. Wider spacing = stronger 3D effect but requires more space. Keep the subject close enough to preserve depth. |
| 3.2 | What lens or focal length should I use? | The kit 18–55 mm works great for most setups. The 24 mm pancake is popular for its compact look. In tight spaces, a 10–18 mm wide-angle helps. |
| 3.3 | Straight or curved bar? | Straight is preferred, the alignment module compensates the angle. Easier to set up and transport. Up to 12 cameras fit on a straight bar as long as they are close together. |

3 — Physical configuration

| # | Question | Answer |
| --- | --- | --- |
| 4.1 | What camera models are compatible? | See the Supported Cameras page in this guide. |
| 4.2 | Can I mix camera models? | Yes. Settings and trigger delays will differ between models, and colour/brightness shifts may need post-correction. You cannot mix PiCam and other models on the same Pi. |
| 4.3 | Do I need SD cards in my cameras? | No in most cases, files transfer straight to the computer. Exceptions: video mode on Canon requires an SD card. |

4 — Camera

| # | Question | Answer |
| --- | --- | --- |
| 5.1 | Do I need Raspberry Pis? | No. All cameras can connect to one computer. Pis let you scale well past 24 cameras by distributing USB load across nodes. |
| 5.2 | Can I mix Pis and Windows clients? | Yes, but trigger timing differences may appear. |
| 5.3 | Can I mix PiCam and other cameras on the same Pi? | No. |
| 5.4 | USB hub vs Raspberry Pi architecture? | USB hub is simpler and requires less gear. Raspberry Pis scale better, each Pi pulls its cameras in parallel over Ethernet. See the benchmark page. |
| 5.5 | Which Pi models work? | 3B+, 4B, and 5. |
| 5.6 | Can I use a mini PC instead of a Pi? | Technically yes, but Pis are far easier to deploy at scale. A Windows node needs manual install, firewall config, and update management. A Pi only needs a flashed SD card. |

5 — Raspberry Pi

| # | Question | Answer |
| --- | --- | --- |
| 6.1 | Why not plug every camera into one computer? | The bottleneck is the camera's slow USB transfer. Distributing cameras across Pis spreads that load, each Pi ships files back over Ethernet, which is far faster and more scalable than one USB bus. |
| 6.2 | How fast is the network? | Each Pi has Gigabit Ethernet. At scale, a 10 Gbps uplink between the switch and computer lets all Pis transfer concurrently. Our fastest rig: 44 Pis on a 48-port gigabit switch with a 10G uplink to the computer. |
| 6.3 | Boot-server + cardless, or standalone? | Standalone is simpler to start: flash a card and run. Boot-server is better long-term: one update point, no SD-card fleet to maintain (less corruption risk). |
| 6.4 | How do I flash a microSD card? | Download the image from xangleapps.com, write it with Rufus (free, portable), balenaEtcher, or Raspberry Pi Imager. See the Getting Started section for a full step-by-step. |
| 6.5 | How precise is triggering across hundreds of cameras? | The trigger signal reaches cameras within about 1 ms. Variation comes from camera shutter and processing latency, not the network. |
| 6.6 | Can I connect more than 4 cameras to one Pi? | Yes, but 4 on the Pi's 4 USB ports is the sweet spot. Beyond that, cameras contend for USB bandwidth. |
| 6.7 | Can I use GoPros with a Pi? | Yes, but through a powered USB hub, not directly into the Pi's USB ports. |
| 6.8 | Can I mix cardless and standalone Pis? | Yes. Both register the same way once they share a subnet with the server. |
| 6.9 | What cables should I use? | Cat6 handles gigabit Pi runs and 10G uplinks comfortably. |
| 6.10 | Can I power Pis over Ethernet (PoE)? | Some users do. We have not tested specific setups ourselves. Ensure the switch and PoE HATs can supply the required current. |
| 6.11 | Should I keep a backup boot server? | Yes. Keep it powered off and disconnected until needed, two live boot servers on the same network will fight over cardless Pis and break booting. |

6 — Network & nodes

| # | Question | Answer |
| --- | --- | --- |
| 7.1 | What kind of computer is required? | Windows 10 or 11. For 12 cameras or fewer, a Surface Pro i7 works. For larger rigs, use a gaming laptop or desktop with a fast SSD and CPU. The software works on slower hardware but processing takes longer. |
| 7.2 | Do I need a GPU? | For fast alignment, an Nvidia GPU is a big bonus. It is also required to train splats using Postshot. |

7 — Computer

| # | Question | Answer |
| --- | --- | --- |
| 8.1 | Which wireless triggers work? | Pretty much any Bluetooth PowerPoint presenter or gamepad. You can also remap keys from Button Mapping. |

8 — Other gear

## Multiple flashes out of sync

- Use only one wireless trigger for all of your flashes. Multiple triggers can introduce timing differences between units.
- Some lower-end flashes cannot synchronize reliably. They may work when the subject is stationary, but action shots can produce double exposures when the subject moves. Avoid unreliable units such as the Godox MS300 for this type of setup.
- Wireless range can be a problem. If distance or interference is affecting synchronization, try using audio cables as a wired alternative.

## Flashes firing for no reason

- Check whether someone is accidentally triggering the flashes by taking photos with a smartphone. This can happen in busy environments.
- Change the channel on all flashes and on the remote trigger. A different channel can help avoid interference from nearby electronic devices.
- Make sure the cameras' built-in pop-up flashes are disabled.
- Deactivate or cover the infrared sensor on the flashes if it is responding to nearby infrared signals.
- Check the electrical system, including power connections, extension cables, and circuit stability.


Flash

Flickering is a change in brightness or color between consecutive cameras or frames. It can come from the light source, camera exposure behavior, optics, triggering, or post-processing. Diagnose the physical capture first, then use software correction only for residual variation.

## Common causes

- Fluorescent lights and other mains-powered sources that pulse with the electrical supply.
- LED or other constant lights using a PWM dimmer or a refresh rate that interacts with the camera shutter.
- Shutter-speed differences between cameras, especially in older or heavily used bodies.
- Sticky or slow aperture blades.
- Dust, fingerprints, or smudges on either side of a lens element.
- Flare from a light aimed toward the camera or entering the lens at an angle.
- Flash duration that is too short, inconsistent, or not synchronized across the rig.
- Exposure, ISO, white balance, or lighting settings that are not consistent across cameras.

## Diagnose the source

1. Capture a short test sequence with the same Camera Server trigger path and settings used for the event.
2. Compare brightness across cameras and across consecutive frames before processing or grading.
3. Identify whether the change follows a camera, a lens, a light, or a position in the rig.
4. Repeat the test with one variable changed at a time: light source, shutter speed, aperture, lens, or flash power.
5. Use an LED timer or another controlled reference when you need to distinguish trigger timing from exposure or lighting variation. See [Measure trigger synchronization with an LED timer](/wayfinder/tools/measuring-trigger-sync-led-timer).

If one camera is consistently brighter or darker, swap its lens or camera position with a known-good unit. If the problem follows the camera, inspect or service the camera. If it follows the lens, inspect the optics and aperture mechanism.

## Prefer a stable light source

For multi-camera or bullet-time capture, use a light source that remains stable throughout the exposure and across the complete capture sequence.

- Avoid fluorescent or visibly pulsing lights.
- Disable PWM dimming when the fixture supports a true constant-output mode, or test the fixture at the selected dimming level.
- Keep all cameras at the same white balance and exposure settings.
- Block stray light and avoid pointing bright fixtures directly into lenses.
- Test the complete lighting setup at the actual frame rate, shutter speed, and capture duration.

A light that looks steady to the eye can still vary enough to produce visible frame-to-frame changes. Check the captured images rather than relying on visual inspection of the room.

## When using flashes or strobes

Flash often produces more consistent illumination than ambient or dimmed continuous light because the flash pulse, rather than the camera shutter timing alone, freezes the subject's illumination.

- Use one reliable trigger path for all flash units.
- Confirm that every flash fires on every test capture and that wireless interference or range is not introducing missed pulses.
- Choose a flash duration long enough to cover the exposure and the timing spread of the rig. A very short pulse can make cameras with small timing differences record different brightness.
- Start with a conventional shutter setting such as 1/60 s when the camera and flash system support it, then verify exposure and motion blur on the actual rig. The correct value depends on the camera, flash, sync method, and ambient light.
- Test lower flash-power settings carefully. Some high-power strobes shorten their flash duration when power is reduced, which can reveal timing differences.
- Keep ambient light low and stable if the flash is intended to be the primary exposure source.

Do not assume that a flash firing sound proves that the light covered every camera exposure. Review the captured frames and repeat the test at the intended power level.

## When using constant light

With continuous light, the camera shutter is part of the timing system. Very fast shutter speeds can expose differences between camera bodies, especially older shutters, and can interact with LED refresh or PWM behavior.

- Start with a shutter speed that the complete camera set can achieve consistently, then increase it only if motion blur requires it.
- If flickering increases as the shutter gets faster, test a slower shutter and a brighter, stable light source.
- Keep aperture and ISO consistent, and confirm that every camera reaches the requested aperture.
- Check that the selected shutter speed is compatible with the light's refresh behavior and the local electrical frequency.

A slower shutter can reduce brightness variation but may increase motion blur. Choose the setting from a test sequence, not from a fixed value copied from another camera model or rig.

## Inspect lenses and camera hardware

- Clean both sides of every lens carefully and inspect for fingerprints, haze, or flare.
- Check the aperture at the selected setting. A sticky or slow diaphragm can leave one frame brighter than the next.
- Test suspect lenses at both wide and narrow apertures. A problem that becomes more visible at a narrow aperture points toward the aperture mechanism.
- Compare older cameras with a known-good body using the same lens and light.
- Replace or service equipment that produces repeatable brightness changes after the settings and light source have been ruled out.

## Correct residual flicker in post-processing

After the physical cause is addressed, a deflicker tool in Premiere Pro, After Effects, DaVinci Resolve, or another editor can reduce small remaining variations. Apply it to a copy of the processed media and check that it does not soften motion, distort edges, or remove intentional lighting changes.

Post-processing cannot recover a frame that missed the flash, contains motion blur from an incorrect shutter, or has a hardware exposure failure. Keep the original captures and document any correction applied to the final output.


Avoid flickering

Use a high-frequency LED timer to estimate the relative trigger timing of cameras in a multi-camera rig. Camera Server triggers the cameras; the timer provides a visible time reference that can be read from each captured image.

This is a measurement tool, not a Camera Server feature or a replacement for camera-node diagnostics. It measures relative timing in the images and does not by itself prove that every camera exposes at exactly the same instant.

## Why use an LED timer?

The timing differences in a synchronized rig can be shorter than one millisecond. Ordinary clocks and displays that show milliseconds often refresh at only 30 or 60 Hz, so their visible state is not precise enough for this test.

The custom timer used in the original guide has three rows of ten LEDs. The rows can be configured from 1 Hz to 10 kHz, with frequency and duty cycle adjusted using the controls below the display.

At a 1 kHz setting:

- The first row advances every 1 ms.
- The second row advances every 10 ms.
- The third row advances every 100 ms.

The timer can therefore encode a relative timestamp across the three rows when the cameras photograph it.

![LED timer showing frequency and duty-cycle controls](https://public.xangle3.com/doc/screenshots/2026-07-14/trigger-sync-timer-reading.png)

## Prepare the capture

1. Place the LED timer where every camera can see the same display and LED rows.
2. Make sure the timer is stable, bright enough to appear in every image, and not clipped by the lens framing.
3. Choose a timer frequency appropriate to the shutter speed and precision you need. Start with 1 kHz for a one-millisecond first-row increment.
4. Set each camera to the same exposure, aperture, ISO, focus, and image format used for the test.
5. Use an exposure no longer than one first-row increment. At 1 kHz, start around 1/1000 s and confirm the result in a test image. A longer exposure can illuminate several adjacent LEDs and make the column difficult to read.
6. Adjust ISO and aperture so the illuminated LED can be distinguished without losing the row or column information.
7. Trigger the cameras from Camera Server using the same trigger path and warmup configuration used in the rig.
8. Capture enough repeated test datasets to distinguish a repeatable offset from a single missed or poorly exposed frame.

Do not change exposure, timer frequency, or trigger settings halfway through a comparison set. Record the values with the dataset.

![LED timer displaying a three-row timing reference](https://public.xangle3.com/doc/screenshots/2026-07-14/trigger-sync-timer-overview.png)

## Read the timestamp

For each camera image, identify the illuminated LED in each row. Convert the three row readings to time using the timer frequency, then add the values together.

For example, at 1 kHz:

- A first-row position of 5 represents 5 ms.
- A second-row position of 3 represents 30 ms.
- A third-row position of 5 represents 500 ms.
- The relative timer reading is therefore 535 ms.

The exact first position and counting direction depend on the timer's labels. Use the same convention for every image in the comparison set and write the convention beside your measurements.

## Calculate the synchronization spread

1. Read the timer timestamp from each camera image.
2. Record the timestamp beside the camera number and capture repetition.
3. Find the earliest and latest timestamp in the same capture.
4. Subtract the earliest value from the latest value.
5. Repeat for several captures and compare the spreads.

The result is an estimate of the relative trigger or exposure spread visible in the images. It can reveal a camera that consistently fires later, but it cannot identify the cause by itself. A difference may come from trigger delivery, camera processing, shutter behavior, rolling shutter, exposure length, timer visibility, or image-reading error.

## Make the result repeatable

- Keep the timer and all cameras fixed between runs.
- Use the same lens, focus, exposure, and lighting conditions.
- Test the complete trigger path, including Raspberry Pi or Windows nodes if they are part of the production rig.
- Check that every camera captured the same timer state and that no image was delayed by a reconnect or transfer issue.
- Repeat the test after changing one variable, such as trigger warmup or camera settings.
- Save the original images and a table of readings with the test dataset.

Use the measurement to compare configurations, not as a universal benchmark. A rig that produces a small spread with one shutter speed or timer setting may behave differently with another camera mode or exposure duration.


Measure trigger synchronization with an LED timer

********* THE CONTENT OF THIS PAGE IS OUTDATED ***********

This guide covers the hardware and current Camera Server workflow for operating addressable NeoPixel LED strips from a Raspberry Pi with an XangleBoard. Treat the electrical ratings of the strip, board, and power supply as a separate hardware responsibility from Camera Server configuration.

## Before you start

You need:

- A Raspberry Pi supported by the current XangleOS image and Camera Server network-node workflow.
- One XangleBoard per Raspberry Pi that drives a strip.
- A compatible addressable NeoPixel strip, such as a 5 V strip that accepts a single data signal.
- A suitable 5 V power supply sized for the strip's maximum pixel count and brightness.
- A separate USB-C or other supported power supply for the Raspberry Pi.
- A wired Ethernet connection or a reliable network path between the Pi and the Camera Server computer.

Do not use the old XCS16 version numbers as compatibility requirements. Check the current Camera Server release notes and the Network Nodes view for the supported Pi image and node versions before preparing a production rig.

## Hardware installation

1. Power off the Raspberry Pi and disconnect its power supply.
2. Install the XangleBoard on the Pi's GPIO header. Make sure the header is aligned correctly and fully seated.
3. Connect the strip to the board's output terminals. Match the board labels to the strip:
   - `GND` to `GND`
   - `DOUT` to the strip's data input, usually marked `DIN`
   - `5VDC` to the strip's positive 5 V input
4. If the strip provides a ground connection beside the data input, connect that ground as well. The wiring reference below shows the signal order and optional ground connection.
5. Connect the strip power cable to the correctly rated 5 V power supply. The LED power supply powers the strip, not the Raspberry Pi.
6. Power the Raspberry Pi from its own supported power supply.
7. Before connecting a long strip or turning on the full installation, verify polarity, the data direction, the voltage, and the power-supply rating.

![NeoPixel strip wiring reference](https://public.xangle3.com/doc/screenshots/2026-07-14/neopixels-led-strip-wiring.png)

The first pixel is directional. Connect the board's data output to the strip end marked `DIN`, `IN`, or with an arrow pointing toward the pixels. Connecting to `DOUT` can leave the strip dark even when the Pi and power supply are working.

## Power and pixel limits

The maximum number of pixels depends on the strip, brightness, animation, wiring length, injection points, and power supply. Do not select a pixel count from an old shopping link or assume that one board can safely power any strip length.

- Size the 5 V supply for the strip's actual maximum current, with headroom.
- Use an appropriate fuse, distribution wiring, and power injection for longer strips.
- Keep the high-current LED power path separate from the Pi's power path.
- Never exceed the voltage specified by the strip.
- Start with a short test section and low brightness before connecting the complete installation.
- If pixels become dim, change color, flicker, or reset when the animation gets brighter, stop and investigate voltage drop or insufficient power before continuing.

The Pi can be installed near cameras or other rig hardware, but the LED supply must still be sized and wired for the strip. A shared Pi location does not make the LED power connection interchangeable with the Pi power connection.

## Add the Pi in Camera Server

1. Launch the current Camera Server build.
2. Open the app's Network Nodes or node-management view and confirm that the Raspberry Pi is discovered.
3. Verify the node identity and connection state before assigning it to a production group.
4. Create or select the group that should control the light hardware, then assign the Pi to that group.
5. Open the lighting controls exposed by the current build for that group. Do not use the legacy `http://localhost:8091/lights` route as a required setup step.
6. Enter the number of active pixels and save the configuration.
7. Start with a simple color or pattern and confirm that the strip responds.

If the Pi does not appear, first check its power, Ethernet link, IP address, node image, and network visibility. A missing node is a discovery or network problem, not a strip pixel-count problem.

## Configure patterns and capture behavior

Use the current lighting controls to create and save presets for the colors or patterns needed by the event. Keep a simple static preset available as a fallback.

Before enabling lighting changes during capture:

- Test the master light state from the operator controls.
- Test each preset with the complete strip connected.
- Confirm which group and node receive the command.
- Trigger a test capture and verify the light change occurs at the intended point in the sequence.
- Use the current trigger warmup or delay setting only when the hardware needs time to settle. Measure the required delay on the actual rig instead of copying a value from the old guide.
- Confirm the lights return to the intended state after a capture, error, app restart, or node reconnect.

Keep lighting control independent from camera triggering until both systems have passed separate tests. This makes it easier to tell whether a failed capture comes from the cameras, the network node, or the LED hardware.

## Troubleshooting

### The Pi is not discovered

Confirm that the Pi and Camera Server computer are on the same reachable network, that the Pi is powered, and that the Ethernet link is active. Restart the node only after checking the cable, switch port, and node identity. If other nodes are visible but this Pi is not, compare its image, network configuration, and power supply with a working node.

### The strip stays dark

Check that the strip receives 5 V power, the grounds are connected, and the board data output goes to the strip's data input. Confirm the strip direction, pixel count, and selected group. Test a short section at low brightness to separate a wiring problem from a configuration problem.

### The first pixels work but later pixels fail

Check voltage drop, power injection, cable size, connector quality, and the supply's current capacity. Reduce brightness and test again. A longer strip may need power injected at more than one point and may need to be divided across multiple power circuits.

### The strip flickers or resets

Inspect the ground and data connections, shorten the data cable where possible, and verify that the LED power supply is not sagging under load. Do not solve repeated resets by increasing the configured pixel count beyond the physical strip.

### A preset changes at the wrong time

Confirm the active group, preset assignment, and trigger warmup or delay settings. Test the preset manually first, then test it with one controlled capture before adding it to a full event sequence.


NeoPixels LED strips

For a rig with several cameras connected to one Windows computer:

### Hardware

- Use a fast computer with a modern multi-core processor and a fast local SSD.
- Connect the computer to a high-quality USB-C or USB 3 controller or hub.
- Avoid chaining USB hubs. Keep the topology simple and distribute cameras across independent controllers when the rig is large.
- Use short, reliable USB cables and test every hub port under a real capture load.
- Keep the active working directory on a local SSD. Do not place it inside OneDrive, Google Drive, or another cloud-sync folder.

### Camera and output settings

- Use the smallest camera resolution that meets the final output requirement. Larger files increase transfer time, storage use, processing time, and output time.
- Configure only the processing tasks and output formats that the event actually needs. Disable unnecessary renders, previews, or delivery outputs while testing throughput.
- Start with a moderate output quality and a fast codec preset, then increase quality only when the visual result requires it.
- Test the complete path with a representative dataset. A small single-camera test does not reveal the transfer and processing limits of a full rig.

1. Direct camera and USB hub architecture

Raspberry Pi camera nodes can distribute capture and transfer work across the network. This can improve triggering and throughput, especially when a Windows computer would otherwise handle too many camera connections through USB.

- Use a Gigabit Ethernet switch for the nodes and the Camera Server computer.
- Avoid daisy-chaining switches. Use a simple star topology where possible.
- Confirm that the computer and each node negotiate a 1000 Mbps link, not 100 Mbps.
- Use reliable Ethernet cables and dedicated network infrastructure for the rig instead of sharing a congested event or office network.
- Add nodes when the measured transfer or capture workload requires it. More nodes also mean more power, cabling, and network dependencies, so test the complete system after each change.
- For RAW or high-resolution workflows, expect file transfer and storage to become the limiting stages even when triggering remains responsive.

2. Raspberry Pi architecture

Measure the same representative capture several times and identify where the delay appears:

1. **Capture and transfer:** cameras or nodes take too long to finish sending files.
2. **Dataset preparation:** files arrive, but analysis or organization is slow.
3. **Processing:** an enabled process task consumes most of the time.
4. **Rendering and output:** resizing, codec work, watermarking, or other output tasks are slow.
5. **Storage or delivery:** the destination drive, network, or backup path has low throughput.

Watch CPU, memory, GPU, disk activity, disk throughput, and network throughput while the job runs. High disk activity with very low throughput points to a storage bottleneck, not necessarily a CPU problem. Check [Known issues](/wayfinder/troubleshooting/progressive-system-degradation) for the SSD write-bottleneck symptoms.

Change one variable at a time, record the result, and keep the settings that improve the full event workflow rather than only one isolated stage. Always run a complete multi-camera test before relying on a faster configuration at an event.

3. Find the slow stage

## SSD write bottleneck causing random processing slowdowns

In rare cases, dataset processing speeds in Xangle Camera Server can become random, inconsistent, and progressively worse over time. Although this can look like a software problem, an SSD that is becoming unstable during write operations may be the root cause.

Typical symptoms include:

- unpredictable processing performance
- gradual degradation over time
- 100% disk activity with very low throughput
- no obvious heavy process visible in Task Manager

### Quick SSD check

To determine whether the SSD is the bottleneck rather than Xangle Camera Server, duplicate a large file, preferably 5 GB or more, onto the same drive. If the copy speed is abnormally slow, or disk activity remains saturated after the copy completes, the SSD is likely responsible.

### Recommended actions

- Run the SSD manufacturer's diagnostics, including SMART checks.
- Install any available SSD firmware updates.
- Keep at least 15 to 20% free space on the drive.
- Update the NVMe or storage controller drivers.
- Perform a clean Windows reinstall if the system shows broader signs of instability.
- Replace the SSD if the problem persists after the other checks.

Back up important datasets before running diagnostics or replacing the drive.

## Norton 360 and distributed architectures

Norton 360 is known to cause serious problems, especially in distributed architectures that use Raspberry Pis or other networked nodes. Its behavior can change depending on the throttling settings applied from Xangle, which can make connection, transfer, or processing issues appear inconsistent.

If you experience unexplained problems with a distributed setup, temporarily disable Norton 360 and test the workflow again. If the issue disappears, add the Xangle application, its working directory, and the relevant node communication traffic to the appropriate Norton exclusions instead of re-enabling unrestricted scanning during an event.

## Do not use cloud-sync folders as working directories

Never place the Xangle working directory, including app settings and datasets, inside a cloud-sync folder such as OneDrive or Google Drive. Xangle continuously reads and writes settings, capture files, thumbnails, processing outputs, and other dataset files. Cloud-sync clients can lock files while synchronizing them, upload incomplete files, restore older versions, or change availability while Xangle is still using them.

These conflicts can cause missing files, slow or inconsistent processing, corrupted datasets, sync conflicts, and unreliable application behavior. Keep the active working directory on a local SSD or another directly attached drive with sufficient free space. Configure cloud storage as a separate backup or export destination after files are closed, rather than as the live location for app settings or datasets.


Known issues

Rules and sequences work together, but they solve different problems.

## Sequence: what should happen

A sequence is a reusable workflow. It runs a list of steps in order and can coordinate cameras, lights, GPIO nodes, and timing. Use a sequence when you want to describe the actions themselves, such as warming up cameras, capturing several groups on a shared timeline, changing a camera setting between shots, running a timelapse, or playing a light and GPIO pattern.

## Rule: when should it happen

A rule listens for a Camera Server event and starts an action when that event matches. The event can be a trigger, countdown, warmup, capture, dataset, or transfer event. A rule can run a sequence, play a light preset or effect, set a light color, drive GPIO, or play a sound.

Use conditions when an action should only run for a particular camera group, zone, dataset, countdown value, or other event field. You can also set a debounce window, add a delay before the action, and choose an event that stops a running sequence.

## A practical way to build automation

1. Create or restore a sequence that performs the physical workflow.
2. Run the sequence manually and check the run log, timing, camera responses, and node outputs.
3. Create a rule for the event that should start it, then connect the event to the sequence action.
4. Add conditions if the rule applies only to one group, zone, countdown beat, or dataset state.
5. Enable the rule only after testing the complete event flow.

A sequence can be run directly from the Sequences page or started by one or more rules. A rule is not a replacement for a sequence: it is the event-to-action layer around it.


Overview

Rules connect Camera Server events to actions. A rule starts when its event node receives a matching event, then follows the connected action nodes.

## Create a rule

1. Open Rules and Sequences and switch to Rules.
2. Select New rule and give it a clear name.
3. Add an event node and choose the event that should start the rule.
4. Add an action node, then connect the event to it.
5. Save the rule and enable it after testing.

Available event types include:

- Trigger started.
- Countdown started, tick, aborted, or finished.
- Warmup started.
- Capture started, finished, or aborted.
- Dataset created or newly available.
- Transfer completed.

## Conditions and timing

An event node can have conditions. Conditions compare an event field using equals, not equals, contains, greater than, or less than. For example, a countdown tick rule can run only when `remaining` equals `3`, or a capture rule can match a particular camera zone.

Use the rule settings to control repeated events:

- **Any (OR):** start when any connected start event matches.
- **All (AND):** wait until every connected start event has matched.
- **Debounce:** ignore repeat fires during the configured time window.
- **Delay:** wait after the event before running the action.
- **Stop when:** abort a running sequence when another event occurs, optionally with its own conditions.

## Actions

A rule can connect to these actions:

- **Trigger a sequence:** run one of the saved sequence workflows.
- **Play a light preset:** start a preset from a selected light group.
- **Set a light color:** broadcast a color and optional brightness to available light nodes.
- **Run a light effect:** play a transient effect with a frame count and framerate.
- **Drive a GPIO pin:** set a pin high or low, or pulse it for a duration.
- **Play a sound:** preview an uploaded MP3 or WAV file, then play it once or in a loop.

Rules can contain comment nodes for notes about wiring, event timing, or the reason for a condition. Keep rules focused: put a longer, reusable workflow in a sequence and leave the rule responsible for deciding when it starts.

## Test before enabling

Run the target sequence directly first. Then trigger the source event under controlled conditions and watch the rule state and run log. Verify that the expected camera groups, lights, GPIO nodes, and sound assets respond before enabling the rule for an event.


Rules

Sequences are reusable JSONC workflows for coordinated camera, light, GPIO, and timing operations. Open the Sequences page to create, edit, validate, run, duplicate, or delete them.

## Start with an example

Camera Server seeds the Examples list with workflows for common setups. Restore an example to return it to its shipped content. Duplicating an example is a useful starting point because it preserves the structure while giving you a separate sequence to edit.

The shipped examples include:

- **Timelapse repeat:** warm up once, then capture a fixed number of frames at a configurable interval.
- **Burst then single photo:** switch image modes, capture a burst, switch back, and take a final single shot.
- **Staggered groups:** warm up and capture several camera groups at precise offsets on one shared timeline.
- **Two groups with delayed trigger:** warm up and capture two groups with a delay between them.
- **Setting two shots:** change image quality between two captures, with warmup and transfer pauses.
- **Light sequences:** broadcast white, blue, and off states, run an effects show, or play and pause a light preset.
- **GPIO sequences:** blink a pin or broadcast a set and pulse pattern to GPIO nodes.

The examples use placeholder camera groups, node targets, light groups, and preset IDs where your installation needs local values. Update those references before relying on an example at an event.

## Sequence structure

A sequence has an ID, name, optional description, and an ordered `steps` array. Each step has a type and parameters. The editor accepts JSONC, so comments and trailing commas are allowed.

Common step types include:

- **Trigger:** warm up, capture, or run another camera trigger phase.
- **Set setting:** change a camera setting for selected groups.
- **Shot:** place several camera actions on one shared clock using `atMs` offsets.
- **Repeat:** repeat a group of steps a chosen number of times.
- **Light:** set or animate light output, including brightness, color, and effects.
- **Light preset:** play, pause, resume, or stop a configured light preset.
- **GPIO:** set or pulse a pin on selected nodes or all available GPIO nodes.
- **Log:** write a useful marker to the run log.

A step's `duration` is the pause after that step. It defaults to 500 ms when omitted and can be set to `0` to continue immediately. In a `shot` block, use each action's `atMs` offset for precise shared timing instead of relying on step duration.

## Validate and run

Use Validate before saving a larger edit. Validation checks the document structure, supported step types, required fields, target shape, and limits. Run a sequence from the page and watch the run log. You can run an individual light step from the visual preview when checking light timing.

Bind a sequence to the main trigger from the trigger binding control when it should replace the normal capture action. For event-based automation that should start the sequence only in specific circumstances, use a rule instead.

Keep a working copy of a known-good sequence before changing camera settings or timing. Test with the actual camera groups and nodes, then confirm the resulting files and transfer timing before using the sequence during a live session.


Sequences

Use this page when preparing a fresh machine or updating before an event. Xangle app installers can be downloaded from xangleapps.com.

## Fresh install

1. Download the latest Camera Server installer from xangleapps.com on the target machine.
2. Close any running Xangle apps before launching the installer.
3. Install with standard options unless your deployment process requires a custom location.
4. Launch Camera Server once after install so required local folders and defaults are created.
5. Open Getting started and run a full camera discovery and trigger test before event day.

## Update flow

1. Export or screenshot any settings you need to preserve before updating.
2. Close Camera Server and related helper apps.
3. Run the new installer from xangleapps.com and complete the upgrade.
4. Reopen Camera Server, verify license/session status, then reconnect cameras.
5. Run one full capture, download, and output test to validate the update on your real rig.

## Operator notes

- Do not update on show day unless you need a specific fix.
- For production rigs, keep a known-good installer package available so you can roll back quickly if needed.
- When you update one station in a multi-station setup, update the others to keep behavior consistent.


Software installation / update

| Term | Meaning |
| --- | --- |
| Project | A real-world shoot or job (for example, one photo day or one event). You group its captures under a single project folder. |
| Project folder | The collection root on disk that holds many dataset folders, typically a NAS or drive folder you name for the project. Set it in Storage / Dataset folder settings. |
| Dataset | A single capture: all the camera frames produced by one trigger, stored together with their metadata (dataset.json). |
| Dataset folder | The folder on disk for one dataset. It contains that capture's frames and its dataset.json metadata file. |
| Iteration | Multiple trigger firings within a single capture, producing several frames per camera in one dataset. A 10-shot burst is 10 iterations. Step between iterations with PgUp / PgDn in the inspector. |
| Dataset reference | A dataset promoted to act as the active reference for processing tasks (image alignment, chromakey, mosaic, sequencer, and others), so its registration data can be reused across later captures. |
| Working folder | The app's own home directory (for example, ~/xangle/cameraserver). It stores configuration and app state, not your captures. Different from the project folder. |

Projects & datasets

| Term | Meaning |
| --- | --- |
| Capture | One firing of all cameras at the same moment, producing a single dataset. |
| Trigger | The action (or button) that starts a capture. |
| Camera | A connected camera body, Canon, Sony, GoPro, phone, or USB webcam. Each one is assigned a number. |
| Camera number | The position assigned to a camera. It controls ordering and how its frames are named. |
| Zone | A named, persistent subset of your numbered cameras (for example "Head" or "Body"). A camera can belong to several zones; exactly one zone is active at a time and controls default triggering, live view, and the {zone} naming token. Main is the built-in default zone. |
| Camera lane | The per-camera strip in the capture view that shows one camera's latest frame, number, and connection status. |
| Frame | A single image from one camera within a dataset. |
| Frames | The grid inspector page for reviewing individual frames across datasets and iterations. |
| Liveview | A full-screen live composite from the connected cameras. |
| Quickview | Fast single-image review of the latest capture or a chosen dataset. |
| Camera node | An adapter host (often a Raspberry Pi) that connects one or more cameras to the server. |
| Network node | A Raspberry Pi or Windows host running node services on the network. |

Capture & cameras

| Term | Meaning |
| --- | --- |
| Camera registration | Computing per-camera transforms from a capture using Cloud, RealityScan, or 2D markerless. Cloud and RealityScan recover 3D poses. 2D markerless computes 2D transforms for fixed-arc rigs. |
| Image alignment | Applying the camera registration to crop and warp images so subjects stay centered and stable across cameras. |
| Camera registration tokens | Monthly cloud usage credits for camera registration. One uploaded image costs one token, and tokens are consumed only on successful cloud completion. |
| Gaussian splat | A 3D scene trained from a dataset's aligned frames. Often shortened to "splat." |
| Queue | The background processing list, alignment, splats, and video renders run here without blocking the operator. |
| Output | A render produced from a dataset: video, image, or export, configured on the Output page. |

Processing & 3D

| Term | Meaning |
| --- | --- |
| Dashboard | Your composable operator workspace, built from movable module tiles. |
| Module / Tile | A movable panel on the dashboard that exposes one page or function. |
| Quick Nav | The Ctrl+1–9 shortcuts that jump straight to your chosen pages. |
| Naming | The rules that decide how captured files and folders are named. Configured on the Naming page. |

Workspace & UI

| Term | Meaning |
| --- | --- |
| Share | Delivering a capture to a guest, by QR code, email, or direct download. |
| Kiosk | A locked-down sharing-station mode for guest self-service. |
| Devices | The connected guest browsers you can navigate, lock, or disconnect from the server. |

| Term | Meaning |
| --- | --- |
| **Network Nodes** | The Camera Server module that lists discovered nodes and provides host operations such as updating, rebooting, restarting services, and shutting down Raspberry Pis. |
| **Network node** | A network-connected host that runs XNN and can provide camera or light services to Camera Server. In this module, the term usually refers to a Raspberry Pi host. |
| **XNN** | Xangle Network Node, the host software installed on a Raspberry Pi. It registers the Pi with Camera Server, reports its state, accepts commands, and coordinates the services running on that host. |
| **Camera Node** | The camera service attached to a network node. It runs the camera adapter and manages cameras connected to the Pi, keeping those cameras available to Camera Server over the network. |
| **Light Node** | The light-control service attached to a network node. It controls supported lights or an XangleBoard connected to the Pi. |
| **ESP32 node** | A supported light-control device based on an ESP32 board. It can appear in the Network Nodes inventory, but it is not a Raspberry Pi host and does not run XNN. |
| **XangleOS** | The operating system image installed on a Pi's microSD card, or served by a boot server to cardless Pis. XNN runs on top of XangleOS. |
| **Standalone Pi** | A Raspberry Pi with its own microSD card containing XangleOS. It runs on the normal routed LAN and does not depend on a boot server to start. |
| **Boot server** | The Pi that stores and serves XangleOS to cardless Pis over the network. It boots from its own microSD card and provides the DHCP, TFTP, and NFS services needed by the cardless clients. |
| **Cardless node** | A Pi without a microSD card. It network-boots from the boot server and cannot operate when that boot server is unavailable. |

Sharing & delivery

Latest walkthrough videos for Camera Server. This playlist refreshes whenever you open the page.

```youtube-playlist
PLE_Si0u2I2JadNFlcAcRfjhXV3wEhfyyB
```


Videos playlist

We're happy to present a fresh new version of our app, Xangle Camera Server. From now on, we'll refer to the older app as XCS16 (2016 is the year we started coding the previous version). Important to know:

- If you need to shoot in RAW, select RAW+JPG. We no longer extract JPGs from RAW files because those JPGs do not carry the EXIF data required for proper camera alignment. You can still use RAW only if you want to go fast and only need the files themselves.
- Assets / Collections is now simply Outputs. You can add as many outputs as you want from a single result. For example, you can export a 16:9 video with an overlay as well as a 9:16 poster.
- You no longer need to configure any SMTP or cloud service. We handle everything for you, so the app is ready to use right away.
- Camera calibration now lives in Registration & Alignment (from the Library) and no longer requires a calibration bar or calibration panel. Create one clean reference dataset for the rig, analyze it in Library, and promote it as the active reference. Future captures can reuse that reference until a camera is bumped, re-aimed, or moved, then you capture a fresh reference and set it as the new active one.
- Mirror lockup is now part of warmup. Hold the trigger button and the app will handle both MLU and half-press for more accurate triggering.
- Sacrifice mode has improved significantly. We have seen slightly better results by shifting the flash signal down by 1 or 2 ms, so it is worth trying the slider.

Major differences

The biggest reasons to move to the new version:

- Markerless camera alignment, with no calibration bar required.
- Automated Gaussian-splat processing.
- Offline QR code sharing.
- App customization: your logo, your colors.
- New modern Android implementation, now with WiFi support.
- Backstage camera that captures the behind-the-scenes, from the start of the countdown to after the files are ready.
- Multiple outputs from a single capture, for example a 16:9 video with an overlay and a 9:16 poster at the same time.
- No email or cloud setup. Sharing and delivery work out of the box, with no SMTP or cloud service to configure.
- Modular dashboard you compose from movable modules.
- Smarter triggering, with mirror lockup folded into warmup plus half-press for more accurate sync.
- Much faster overall.

Highlights of the new version

These features from XCS16 are not implemented:
- Sacrifice camera on a different model (has to be the same model now!)
- Older Sony cameras support (Sony doesn't support older models in their current official SDK)