2Timer
← Back to 2Timer

2Timer Help

Practical guides for humans, with structure that is easy for AI systems to parse.

Connectors

Purpose

Set up live data connections for timing input, registration sync, and result publishing using the meet-level Connectors page.

Prerequisites

  • The meet already exists.
  • Markers already exist for timing workflows that route reads into the meet.
  • Any required external account integration is already connected when the connector depends on it.

What a Connector Is

A connector is a meet-level configuration that connects 2Timer to an external source or destination.

Current connector categories include:

  • timing hardware
  • file-based shared-folder workflows
  • registration sync
  • result publishing

A connector can be:

  • inbound
  • outbound
  • both inbound and outbound

The exact behavior depends on the connector type.

Where It Lives in the UI

Open Connectors from the meet navigation.

The current connectors page shows:

  • existing connector cards
  • New Connector
  • bulk selection and delete
  • per-connector actions such as start, stop, publish now, sync now, and edit

The Current New-Connector Groups

When you click New Connector, the options are grouped by the current UI.

Timing Hardware

  • IPICO
  • Trident
  • MyLaps
  • Generic RFID
  • FinishLynx
  • Feibot

File Storage

  • Local Files
  • S3 / R2

Registration

  • RunSignUp

Results Publishing

  • Total Active Sports

Some options appear only for certain sports, and some depend on a connected integration before they are shown.

Common Connector Actions

Start / Stop

Use these when a connector should begin or stop active sync/watch behavior.

Publish Now

Use this on outbound connectors when you want an immediate push of result output.

Sync Now

Use this on connectors such as RunSignUp when you want an on-demand pull instead of waiting for a schedule or manual follow-up later.

Edit

Open the connector detail page to change settings, locations, folder choices, formats, or connection behavior.

Preview Data

Some connector types expose Preview Data from the connector detail page so you can inspect incoming parsed content before trusting live behavior.

Connector Detail Page

After creation, the connector detail page is where most configuration refinement happens.

Depending on connector type, you may see:

  • inbound settings
  • outbound settings
  • connection mode
  • interval or debounce timing
  • output format
  • location mapping
  • folder/file-pattern settings
  • connector-specific options

Inbound vs Outbound Settings

Inbound

Inbound settings typically control:

  • whether inbound sync is enabled
  • whether the connector checks on an interval
  • polling frequency in seconds
  • connector-specific file or data filters

Outbound

Outbound settings typically control:

  • whether outbound publishing is enabled
  • whether it runs manually or on event-based changes
  • debounce timing for event-driven publishing
  • output format
  • connector-specific export settings

Connection Modes in the Current UI

The connector settings UI uses the current mode language:

  • interval
  • event
  • manual

Typical meanings:

  • interval: check or poll repeatedly
  • event: react to data changes, often with debounce
  • manual: do nothing until the operator explicitly triggers sync or publish

The exact modes exposed depend on connector type.

Timing Locations and Markers

Chip-timing style connectors use Timing Locations.

Each location usually includes:

  • name
  • marker
  • active toggle
  • optional reader IDs
  • optional subdirectory
  • optional file patterns

This is where you map physical read sources to meet markers such as start, finish, or split.

Important:

  • create markers first
  • then assign those markers to connector locations
  • use reader IDs only when the source data includes them and routing needs to be more precise

FinishLynx

What the current UI supports

The FinishLynx wizard is a shared-folder workflow with both inbound and outbound behavior.

The wizard currently walks through:

  1. Choose Folder
  2. Options
  3. Name & Save

Inbound behavior

The connector can watch for:

  • *.lif track result files
  • *.lff field result files

Outbound behavior

The connector can write Lynx-family files such as:

  • PPL
  • SCH
  • EVT
  • AFL

The detail UI also exposes:

  • which file types to generate
  • whether unscheduled rounds should be included in SCH

Best practices

  • keep event numbers aligned between 2Timer and Lynx
  • choose the shared folder carefully
  • review whether the target folder already contains conflicting Lynx files before saving
  • use markers and locations deliberately if inbound reads/results need correct routing

IPICO

Use IPICO for non-track passive RFID workflows.

The connector is location-based, so the key setup work is:

  • choose the source path
  • create locations
  • map each location to the correct marker
  • use reader IDs or subfolders only when needed

Trident

Use Trident for non-track filtered-log workflows.

The current UI supports optional reader-ID routing, and Trident-specific help text expects combined reader keys like A:3.

This is a strong clue that routing precision depends on the actual filtered log structure you are feeding in.

MyLaps

Use MyLaps for non-track MyLaps timing workflows.

As with the other RFID-style connectors, the main setup is location-to-marker mapping plus any file-path and reader-routing details needed by your decoder output.

Generic RFID

Use Generic RFID when you have an RFID source that does not match one of the more specific branded connector types.

This is the most flexible inbound timing option, but it also means you should validate marker mapping and preview behavior carefully.

Feibot

Use Feibot for supported non-track timing workflows where Feibot is the source.

Because it is less generic than the catch-all RFID connector, prefer it when Feibot is truly the system in use.

Local Files

What the wizard does

The Local Files wizard currently walks through:

  1. Output Folder
  2. File Naming
  3. Name & Save

What it is for

Use this when you want 2Timer to write result files onto the local machine.

The wizard currently sets:

  • target folder
  • file name pattern
  • connector name

After creation, the detail UI lets you refine things such as:

  • output format
  • publish mode
  • optional report template

Important UI-aligned note

The wizard summary currently creates this connector in Manual publish mode by default.

If you want event-driven publishing, edit the connector after creation.

S3 / R2

Use S3 / R2 when result files should be published to object storage rather than a local folder.

This lives in the connector UI as a file-storage connector rather than a generic dashboard export.

RunSignUp Connector

What the wizard does

The RunSignUp connector wizard currently walks through:

  1. Connect RunSignUp
  2. Select Race
  3. Map Events
  4. Name & Save

What it is for

Use this connector for live or repeatable RunSignUp sync behavior.

That is different from the one-time RunSignUp CSV import page in the meet dashboard import section.

Current behavior clues from the UI

  • it checks whether your RunSignUp account connection is active
  • it loads available races
  • it lets you map RunSignUp events to your meet events
  • event mapping is optional but often helpful

Total Active Sports

Total Active Sports appears in the connector list only when the corresponding integration is connected.

Use it for run-only result publishing workflows when that external integration is part of the meet’s downstream output path.

Troubleshooting by Symptom

Reads are not appearing

Check:

  • inbound is enabled
  • the connector is started
  • the right folder/path is selected
  • marker mapping is correct
  • file patterns or reader IDs are not too restrictive

Publish Now does nothing useful

Check:

  • outbound is enabled
  • the connector has a valid output format or target
  • the report/result layer actually contains data to publish

FinishLynx shared-folder behavior looks wrong

Check:

  • shared folder selection
  • event-number alignment
  • which file types are enabled for export
  • whether you intended to watch for LIF, LFF, or both

RunSignUp sync is blocked

Check:

  • the RunSignUp integration connection
  • race selection
  • optional event mapping

Wrong results are routed to the wrong marker

Check:

  • location-to-marker assignment
  • reader IDs
  • catch-all locations that may be too broad

Common Mistakes

  • treating manual file import pages as if they were the same thing as connectors
  • forgetting to create markers before configuring timing locations
  • assuming the connector wizard exposes every long-term setting up front
  • leaving a connector in manual mode when event-driven publishing was actually desired
  • over-restricting reader IDs or file patterns

Verification Checklist

  • The chosen connector type matches the actual system in use.
  • Required integrations are connected before connector creation.
  • Markers exist before location-based timing connector setup.
  • Inbound/outbound modes are intentional, not just left at defaults.
  • Test sync or publish succeeds before race pressure begins.

Related Pages

Metadata

  • Last Updated: 2026-04-18
  • Version: 0.3
  • Status: Active