Schedules¶

A schedule is a named TDOA timing plan: it tells the synchronization network which anchor talks in which slot, at which dimension, with which margin. Schedules are stored on the server and the project's active schedule is selected via LSB settings.

Quick reference¶

Method	What it does
`client.schedules.list()`	All schedules in scope.
`client.schedules.get(uid)`	Fetch a single schedule.
`client.schedules.create(name, , content=None, default=False, tdoa_version=2, *fields)`	Create a schedule.
`client.schedules.update(uid, **fields)`	Update fields.
`client.schedules.delete(uid)`	Delete.

Reading and writing¶

schedules = client.schedules.list()
sched = client.schedules.create("Default plan", content="<serialized table>")
client.schedules.update(sched.uid, name="Default plan v2")
client.schedules.delete(sched.uid)

Schedule content is opaque¶

The per-slot table (source / destination anchor, slot number, slot section, dimension, margin) is carried inside the content field as a serialized blob. The wire format varies by tdoa_version (1 or 2), so the SDK keeps content as str | None instead of forcing a typed sub-model. Use Schedule.raw if you need to inspect server-side fields the SDK doesn't surface yet.

Pointing LSB at a schedule¶

A schedule becomes active when LSB settings reference it via values["active_schedule_uid"]. Creating a schedule does not change the active one.

sched = client.schedules.create("Replacement plan", content=blob)
lsb = client.lsb.get()
lsb.active_schedule_uid = sched.uid
client.lsb.save(lsb)

Configuring active_schedule_uid is only one of three steps to bring up sync from zero. See LSB — End-to-end for the full create-schedule → upsert-settings → start-LSB recipe.

Model — `Schedule`¶

Field	Type	Notes
`uid`	`str`	Server-assigned.
`name`	`str \\| None`	Display name.
`content`	`str \\| None`	Serialized per-slot table (format depends on `tdoa_version`).
`default`	`bool`	Mark as the project default.
`tdoa_version`	`int \\| None`	1 or 2.