LectroTIC-4 — 4-Channel Pulse Timestamper

A four-channel zero-dead-time pulse timestamper with 4-nanosecond resolution. Plug it into your USB port, feed it pulses, and it streams a list of the times each pulse arrived, accurate to a few nanoseconds against your lab's reference clock.

The LectroTIC-4.

Contents

• Overview
• Connecting to a host via USB
• Basic usage
  • Pulse requirements
  • Text output format
  • Don’t parse the ASCII stream into a 64-bit float
  • If the reference clock fails
• Indicator LEDs
• Command interface
• Binary format
• tsctl: a one-file Python utility
  • Library interface
• Updating the firmware
  • Firmware versions
• Comparison to similar instruments
• Specifications
  • Channels and timing
  • Inputs
  • Reference clock and host interface
  • Physical and environmental
• Schematics, Software, and Other Sundries

Overview

The LectroTIC-4 records the precise moment a pulse arrives on any of its four inputs and sends a stream of timestamps out over USB. Resolution is 4 nanoseconds, and the absolute accuracy is whatever your reference oscillator is — a rubidium standard, a GPS-disciplined oscillator, or any other 10 MHz source you trust.

It is zero-dead-time: the timescale never stops, restarts, or loses precision while the device is running. Every pulse you capture sits on the same continuous nanosecond-resolution timeline (the timeline starts at zero at power-up and counts forward indefinitely), whether the pulse arrived a microsecond or a year after the previous one.

The four channels are also coherent: they all sample against the same clock and the same counter, so a timestamp on CH 0 and a timestamp on CH 2 can be subtracted directly to get the true time difference between the two pulses — there is no per-channel clock or counter that could drift. That makes the device suitable for long unattended runs where you need to know not just when each pulse occurred but also how each pulse relates to every other pulse seen across all four channels.

Each channel can be independently configured for rising-edge, falling-edge, or both-edge capture (use both edges to time a pulse’s width directly) and for an optional integer divider that reports only every Nth pulse — useful for downsampling busy inputs or matching a reference channel’s rate. These settings are available through a small SCPI command set on the same USB connection, and can be saved to the device so they survive a power cycle.

It is also high throughput. The on-device buffer captures pulses as little as 4 ns apart on a single channel for the first 4,096 pulses, and as little as 150 ns apart for the next 12,288 (16,384 timestamps total before the host must drain the buffer) — orders of magnitude faster than the burst rates most laboratory time-interval counters can sustain. Once the buffer is in steady state the host becomes the bottleneck: the default ASCII output streams at roughly 25,000 timestamps per second, and an optional compact binary mode (selectable with a single SCPI command) pushes that to about 100,000 per second, near the practical ceiling of a USB Full-Speed link.

It is also designed to be easy to use: the device connects over USB and enumerates as a standard virtual serial port on Linux, macOS, and Windows. On most hosts there’s nothing to install — no special driver, no companion app, no SDK — and the device emits plain ASCII text, one timestamp per line, that you can read with any terminal program or pipe directly into a script. The defaults (rising edge, divider 1, all four channels active) are sensible enough that no configuration is required for first-time use; the SCPI commands are there if and when you want them. And once you’ve dialed in a configuration you like, a single command saves it as the new power-on default, so the instrument always boots exactly the way you want it.

Connecting to a host via USB

The LectroTIC-4 enumerates as a standard USB CDC ACM (Communications Device Class) virtual serial port — the same class used by countless USB-to-serial cables, dev boards, and embedded instruments. There’s no Lectrobox-specific driver to install: every modern operating system already ships the host-side CDC driver, and the device shows up as a plain old serial port. Any program that can open one can read the timestamp stream.

The platform-specific sections below cover where the port appears, what to install (if anything), and which free, open-source terminal programs are good defaults.

• Linux

  The Linux kernel binds the built-in cdc_acm driver to the LectroTIC-4 automatically. The device appears as /dev/ttyACM0 (or /dev/ttyACM1, etc., if you have other CDC devices already attached). No driver installation needed. Useful terminal programs:

  • grabserial (pip install grabserial) — Python command-line tool that logs serial output with a host-side timestamp on each line; great for capture-to-file. Run as grabserial -d /dev/ttyACM0.
  • pyserial-miniterm /dev/ttyACM0 (comes with the pyserial package).
  • picocom — a small, friendly terminal: picocom /dev/ttyACM0.
  • minicom — older but common and capable.
  • screen /dev/ttyACM0 — built into most distros.
  • cat /dev/ttyACM0 — see the line-discipline note below first.

  Linux opens new serial ports in canonical mode, which echoes incoming characters back out to the device — fine for an interactive shell, but it can corrupt the timestamp stream. Programs designed for serial work (grabserial, pyserial-miniterm, picocom, minicom, screen, and our own tsctl.py) reconfigure the port automatically and need no setup. Simpler tools like cat do not, so before using them, run:

  stty -F /dev/ttyACM0 raw -echo
  

  To make this permanent, drop the following into /etc/udev/rules.d/60-lectrotic.rules and run sudo udevadm control --reload:

  SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="71c4", \
      RUN+="/usr/bin/stty -F /dev/%k raw -echo", \
      SYMLINK+="lectrotic-4"
  

  The SYMLINK line also gives you a stable /dev/lectrotic-4 device node so you don’t have to guess whether your LectroTIC-4 came up as /dev/ttyACM0 or /dev/ttyACM1.

• macOS

  macOS loads its built-in CDC ACM driver automatically. The device appears as /dev/cu.usbmodem* (the wildcard is a long serial-number-derived suffix). No driver installation needed. Useful terminal programs:

  • grabserial (pip3 install grabserial) — Python command-line tool that logs serial output with a host-side timestamp on each line. Run as grabserial -d /dev/cu.usbmodem*.
  • pyserial-miniterm /dev/cu.usbmodem* (pip3 install pyserial).
  • picocom and minicom via Homebrew: brew install picocom minicom.
  • screen /dev/cu.usbmodem* — built in.
  • cat /dev/cu.usbmodem* — see the line-discipline note below first.

  macOS opens new serial ports in canonical mode, which echoes incoming characters back out to the device — fine for an interactive shell, but it can corrupt the timestamp stream. The dedicated serial programs above (grabserial, pyserial-miniterm, picocom, minicom, screen, and our own tsctl.py) reconfigure the port automatically and need no setup. Simpler tools like cat do not, so before using them, run:

  stty -f /dev/cu.usbmodem* raw -echo
  

• Windows

  The LectroTIC-4 is a standard USB CDC (serial) device, and the driver Windows needs (usbser.sys) is built into every version of Windows from XP through 11 — but only newer versions of Windows bind it to the device automatically. Windows 10 (version 1607 / Anniversary Update, August 2016) and later does so on plug-in: the LectroTIC-4 appears in Device Manager under “Ports (COM & LPT)” as a new COM port and you can skip ahead to the terminal programs. Windows XP, Vista, 7, 8, and 8.1 don’t auto-bind the driver, so you have to tell Windows which built-in driver to use via a one-time INF install:

  1. Download lectrotic4.inf.
  2. Right-click the downloaded lectrotic4.inf and select Install.
  3. Accept the unsigned-driver warning if prompted (the INF routes to the OS-supplied driver; no third-party kernel code is involved).
  4. Unplug and replug the LectroTIC-4. It appears in Device Manager under “Ports (COM & LPT)”.

  Once the device shows up as a COM port (look in Device Manager under “Ports (COM & LPT)” to find the COM number — e.g. COM5), pick a terminal program:

  • PuTTY — pick “Serial,” type the COM port name (e.g. COM5), click Open.
  • Tera Term — open-source terminal with a clean serial-port dialog.
  • If you have Python installed (python.org), pip install pyserial grabserial then run pyserial-miniterm COM5 or grabserial -d COM5 from a Command Prompt or PowerShell window.

Basic usage

1. Connect a 10 MHz reference clock (rubidium, GPS-disciplined, or any other stable source) to the 10 MHz In input.
2. Plug the device into a USB port on your computer. The 10 MHz indicator LED begins flashing once the reference clock is locked. The reference clock is checked once at boot, so if you change or reconnect the source after the device is already powered, press the RESET button to make it re-lock — no need to unplug USB.
3. Open the virtual serial port the device created — /dev/ttyACM* on Linux, /dev/cu.usbmodem* on macOS, or a new COM port on Windows.
4. Connect signals to any of the four SMA inputs (CH 0 … CH 3) and timestamps will stream to your terminal program over USB.

Pulse requirements

By default each channel timestamps the rising edge of each pulse — the moment the input goes from LOW to HIGH. The polarity is selectable per channel via the SCPI command INPut<n>:SLOPe POSitive|NEGative|BOTH (see Command interface below). Falling-edge mode captures HIGH→LOW transitions instead; both-edge mode captures both, which lets you measure pulse widths directly by subtracting consecutive timestamps on the same channel. The minimum reliable pulse width is 4 ns in any mode; anything narrower may be missed. Slow edges are tolerated thanks to the input’s ~250 mV of Schmitt-trigger hysteresis, but extremely slow ramps (below a few mV/ns) may produce duplicate triggers as the signal crosses the threshold band.

The input registers as low for voltages below ~1.0 V and as high for voltages above ~2.3 V, so a standard 3.3 V or 5 V CMOS-level pulse train works directly. Each input is protected by a 220 Ω series resistor and a BAT54S clamp to the 3.3 V rail and ground, which absorbs continuous inputs up to 12 V and brief overshoots well beyond that without damage.

Text output format

The device sends a stream of plain ASCII text terminated by a single \n (LF) per line. No carriage returns. Output looks like this:

# Starting LectroTIC-4, version 0.14.0-9afaa32f
0 5293.585203496
0 5293.587201024
2 5293.601004112
0 5293.589198608
1 5293.601100008

Each timestamp line is <channel> <seconds>.<nanoseconds>. The seconds counter starts at zero when the device powers up and counts forward indefinitely (it doesn’t wrap until ~136 years). Channel numbers are 0 through 3.

Any line that starts with # is a status message rather than a timestamp:

• # Starting LectroTIC-4, version <release>-<git-hash> — printed once after USB enumeration and the reference clock locks (e.g. 0.13.0-9afaa32f). <release> is a human-assigned, monotonically increasing firmware version you can compare against (e.g. require >= 2.0); <git-hash> pins the exact build it was cut from.
• # FATAL: External oscillator failure. Connect a 10MHz source and press reset. — printed once if the reference clock fails to start at boot, or drops out mid-run. The device stops emitting timestamps until reset.
• # ch<N>: <X> overcaptures, <Y> buf overflows — printed when a channel’s pulse rate exceeded what the device could handle. The two counters are distinct failure modes. Overcaptures count pulses that arrived closer together than the minimum event interval, so a new capture stomped on the previous one before it could be recorded. Buf overflows count pulses dropped because the 16,384-timestamp internal buffer filled faster than USB could drain it. To eliminate overcaptures, space your pulses further apart; to eliminate buf overflows, reduce the average rate or split your work into bursts of ≤ 16,384 pulses with quiet periods between to let the buffer drain.

Don’t parse the ASCII stream into a 64-bit float

It’s tempting to read each line and do float(line.split()[1]). Don’t, at least not for long runs. An IEEE-754 double (float64, what Python’s float, numpy.float64, and pandas.read_csv give you by default) has a 53-bit significand, so it can represent distinct values only up to \(2^{53}\) nanoseconds. The seconds counter starts at zero at power-up, so after about 104 days (\(2^{53}\) ns \(\approx 9.0 \times 10^{15}\)) adjacent nanosecond timestamps start rounding to the same double, and the error grows from there: roughly 2 ns at 104 days, 4 ns at 208 days, doubling each time the run length doubles. On a 4 ns-resolution instrument that is silent, cumulative corruption of your data.

Three ways to avoid it:

• Use the tsctl.py library. Its iter_records() / read_for() generators hand back each timestamp as separate integer seconds and nanoseconds fields, so there is no significand to overflow no matter how long the run. This is the easiest correct option if you’re working in Python.
• Keep seconds and nanoseconds as separate integers. Split each ASCII line on the . and parse the two halves as int, then do arithmetic on the pair (or on a single arbitrary-precision Python int of total nanoseconds) rather than collapsing to a float.
• Parse into an 80-bit extended float. numpy.longdouble (exposed as numpy.float128 on x86-64) is really the x87 80-bit type, with a 64-bit significand. That pushes the precision-loss horizon out to \(2^{64}\) ns \(\approx\) 584 years, well past the 32-bit seconds counter’s own ~136-year wrap, so in practice it never drops a nanosecond. Note this is not automatic: plain float() or pandas.read_csv without an explicit dtype=np.longdouble still hand you the lossy 64-bit double.

If the reference clock fails

The reference clock is checked once at boot and continuously monitored afterward. If the 10 MHz signal disappears or drifts out of range:

1. The 10 MHz LED goes dark.
2. The device emits the # FATAL line above on USB.
3. Timestamping halts. No further timestamps appear, even if pulses are arriving on the inputs — the device refuses to operate without a trusted reference, since any timestamps it produced would be wrong.

To recover, restore the 10 MHz signal at the 10 MHz In input and press RESET. There’s no need to unplug USB.

Indicator LEDs

10 MHz

• Dark: reference clock missing or failed. The device will refuse to emit timestamps until you restore the reference and reset.
• Continuous blink: reference clock locked, device is timing.

USB

• Dark: nothing on the host has opened the device’s serial port — this is the state both when the cable is unplugged and when it’s plugged in but no program is reading
• Solid: a host program has opened the port
• Blinking: data is flowing to that host program

CH 0–CH 3 (one per channel)

• Dark: no pulses arriving
• Occasional blink: a pulse has arrived
• Continuous blink: pulses are arriving at >5 Hz

Command interface

The LectroTIC-4 accepts SCPI-style commands on the same USB CDC port it streams timestamps over. Sending commands is strictly optional: out of the box, the device starts streaming on plug-in with all four channels in rising-edge capture mode and no divider, and you never need to send anything to use it. Commands are only there for users who want to change those defaults — invert a channel’s edge polarity, set a divider, suppress streaming during a synchronous query session, or switch the output stream to a compact binary format that roughly quadruples the sustainable record rate (see FORMat:DATA below).

Send a single command line (terminated with \n); the device responds with silence for setters, one line of data for queries, or latches an error that you can read back later. Commands are case-insensitive and accept either the standard SCPI long form or the abbreviated short form (the capital letters in each keyword name).

Standard IEEE 488.2 commands:

Per-channel input configuration (channel suffix <n> is 0, 1, 2, or 3; if you omit it the command operates on channel 0):

Streaming output:

Saving configuration:

Example session:

*IDN?
Lectrobox,LectroTIC-4,LT4-0030003A3334510537303334,0.13.0-9afaa32f

INP1:SLOP NEG
INP2:DIV 100

INP1:SLOP?
NEG
INP2:DIV?
100

*RST
INP1:SLOP?
POS
INP2:DIV?
1

Commands and timestamp data share the stream, so if you send a query while pulses are flowing, the response line will appear inline with the timestamps. To get a clean back-and-forth, send OUTPut:STATe OFF first to pause the timestamp stream, run your queries, then OUTPut:STATe ON to resume; the device buffers up to 16,384 timestamps internally during the pause and drains them when streaming resumes.

Binary format

FORMat:DATA BINary switches the stream from ASCII lines to a fixed 8-byte record per event — about 4× the throughput of text (~100,000 vs ~25,000 records/s), at the cost of having to decode it. Both FORMat:DATA TEXT and *RST return the stream to text. The Python tsctl library decodes this for you; it’s documented here so you can also write a parser in another language.

Every record is exactly 8 bytes: two little-endian uint32 words, seconds then tag. There are no delimiters and no self-framing — the reader must stay 8-byte aligned. OUTPut:CLEar gives you a known re-sync point: it flushes everything and emits one OUTPUT_CLEARED record (below), so a reader that lost alignment can scan for it and resume cleanly.

The diagrams show each 32-bit word with bit 31 on the left; on the wire each word is those four bytes least-significant first. The record’s structure:

• CHN — bits 31–30: channel, 0–3.
• S — bit 29: 0 = timestamp, 1 = special message.
• R — bit 28: reserved, always 0.
• bits 27–0 — for a timestamp, a 4-ns tick count (0–249,999,999); for a special message, the low 8 bits are the message type.

Timestamp record (S = 0). The tick field counts 4 ns units within the second (0–249,999,999); nanoseconds = ticks × 4 (0–999,999,996). seconds is whole seconds since power-up (it counts forward ~136 years before wrapping). The binary equivalent of a text line <channel> <seconds>.<nanoseconds>:

Special message (S = 1). tag bits 7–0 are the message type and the seconds word is its payload. These carry the same information text mode prints as # lines, in-band so a binary reader never has to switch back to TEXT:

• OUTPUT_CLEARED — the binary equivalent of the # output cleared line: OUTPut:CLEar took effect (ring and in-flight TX dropped). The whole record is the fixed 8 bytes 00 00 00 00 00 00 00 20 (every field 0, S = 1), and doubles as the stream’s re-sync marker:

• PULSES_LOST — the binary equivalent of # ch<N>: <X> overcaptures, <Y> buf overflows. CHN is the channel that lost edges; the seconds word carries the two 16-bit counts (each saturates at 65,535):

• OSC_FAIL — the binary equivalent of the # FATAL: External oscillator failure … line: the 10 MHz reference failed and the device has halted. Channel 0, zero payload; no records follow until the device is reset:

(See Text output format for what overcaptures and buffer overflows mean and how to avoid them.) The one-time boot banner is the only # line with no binary equivalent — it is text-mode only.

tsctl: a one-file Python utility

Any terminal program is fine for casual use, but if you want a more convenient way to send SCPI commands and get the higher throughput that binary mode unlocks, tsctl.py is a small, self-contained Python script (the only dependency is pyserial) that wraps the SCPI interface and the streaming output behind a friendly command line. Save the file, chmod +x, and run.

It auto-detects the LectroTIC-4 by USB VID/PID (no --port needed unless you want to override), and provides subcommands for everything the device exposes:

• tsctl.py idn — read *IDN?
• tsctl.py reset — *RST
• tsctl.py slope <ch> [POS|NEG|BOTH] — set or query slope
• tsctl.py div <ch> [N] — set or query the divider
• tsctl.py save — save the current slope/divider so they survive a power cycle
• tsctl.py format [text|binary] — set or query the wire format (persists after tsctl.py exits)
• tsctl.py raw '<scpi>' — send any SCPI command verbatim
• tsctl.py stream — forward the timestamp stream to stdout

The stream subcommand is the most useful one for everyday use. It puts the device into binary output mode (the high-throughput 8-byte-per-timestamp wire format described above) for the duration of the stream, then decodes those records back into the same human-readable <channel> <seconds>.<nanoseconds> ASCII lines you’d see in text mode — so you get the throughput benefit of binary without changing what your downstream pipeline reads. On exit it restores whatever wire format the device was in before, so stream (like every other subcommand except format) leaves the device untouched.

Two extra niceties: tsctl.py configures the serial port for raw / no-echo operation itself (no stty needed), and on Linux it works regardless of which /dev/ttyACM* the kernel happened to assign.

Library interface

tsctl.py is also a small Python library — drop it next to your own script (or pip install directly from the URL), from tsctl import LectroTIC4, and you have an autodetecting, context-managed handle to the device with method-style access to every SCPI feature plus the high-throughput binary stream:

from tsctl import LectroTIC4, Timestamp, PulsesLost

# Autodetects by USB VID/PID; pass port="/dev/ttyACM1" to override.
with LectroTIC4() as tic:
    print(tic.idn())
    tic.reset()
    tic.set_slope(0, "BOTH")
    tic.set_divider(0, 100)                   # one stamp per 100 edges
    tic.save()                                # keep across power cycles
    tic.discard_pending()                     # see only post-config records
    for r in tic.read_for(5.0):
        if isinstance(r, Timestamp):
            print(f"channel {r.channel}: "
                  f"{r.seconds}.{r.nanoseconds:09d} s")
        elif isinstance(r, PulsesLost):
            print(f"channel {r.channel}: LOST "
                  f"{r.overcaptures} oc / {r.buf_overflows} ovf")

The library automatically pauses the timestamp stream during every query so SCPI responses come back uncontaminated. After a configuration change, call tic.discard_pending() to drop records the device has already buffered under the previous settings; it sends OUTPut:CLEar, reads through the device’s # output cleared sync marker for you, and returns only when every byte that arrives next is post-call. The next read sees only captures that occurred after the call.

read_for(duration_s) is a generator that yields one of three namedtuple types — the decoded binary format, distinguished with isinstance:

• Timestamp(channel, seconds, nanoseconds) — a captured edge. seconds and nanoseconds are integers (whole seconds since boot plus the 0–999,999,999 ns within it), kept separate on purpose so long captures never lose precision to float rounding.
• PulsesLost(channel, overcaptures, buf_overflows) — the device dropped edges on that channel.
• OutputCleared() — an OUTPut:CLEar took effect. discard_pending() consumes this internally as its sync marker, so you normally only see one if you clear the stream mid-capture yourself.

The generator exits cleanly after the given wall-clock window, even if the device is silent, so you can wrap timestamp capture in your own measurement logic without touching pyserial directly. The regression test, deadtime sweep, and sustained-rate sweep under src/app/timestamper/util/ are larger worked examples of the same library.

Updating the firmware

LectroTIC-4 firmware (0.14.0 and later) can be updated over USB with dfu-util. Pick the image to install from the version list at the end of this section.

Install dfu-util:

• Linux: apt install dfu-util (or the distro equivalent).
• macOS: brew install dfu-util.
• Windows: download the dfu-util binary from its website. The update-mode device also needs the WinUSB driver, which Zadig installs.

With the device connected and not mid-capture, run (Windows: omit sudo):

sudo dfu-util -d 1209:71c4,0483:df11 -a 0 -s 0x08000000:leave -D lectrotic4-0.14.0.bin

This switches the device into its USB bootloader, writes the image, and restarts into the new firmware. Verify the running version with tsctl.py (see tsctl above):

tsctl.py idn

which reports it in the *IDN? string. If the update is interrupted, the device remains in its bootloader and is still visible to dfu-util; re-run the same command.

Firmware versions

• 0.14.0 — initial firmware release.

Comparison to similar instruments

Most time-interval counters — from the legendary HP 5370A/B (1979, 20 ps single-shot, still the gold standard in the time-nuts community) through the modern Pendulum CNT-91 — use analog interpolation: charging a capacitor between the input edge and the next clock tick, digitising the resulting voltage, and reconstructing the sub-clock fraction of the time interval. The HP and Pendulum instruments call this a “vernier interpolator,” the SR620 calls it a time-amplitude converter, the Keysight 53230A calls it a multi-stage time interpolator, and the TAPR TICC delegates to a TI TDC7200 chip that does the same job in silicon. This technique gets ps-class single-shot resolution, but the analog stage takes finite time to charge, digitise, and reset — so those instruments trade sample rate against resolution. The higher the single-shot resolution, the lower the back-to-back capture rate the analog stage can sustain.

We chose the opposite trade-off. The LectroTIC-4 has no analog interpolator at all — it just runs a 32-bit hardware counter at 250 MHz and snapshots it on every input edge via DMA. That floors single-shot resolution at one clock tick (4 ns) but lets the device record edges as fast as they arrive, in bursts at the timer’s full hardware rate, with no per-sample dead time. If you need ps-class resolution on a single edge, one of the instruments in the table below is the right tool. If you need to capture every edge of a high-rate train, four channels at once, on a continuous coherent timeline, this is the right tool.

Two instruments above are open-source: the TAPR TICC (designed for the amateur time-and-frequency community by John Ackermann N8UR), and the LectroTIC-4. Everything else is a closed proprietary instrument. Of the proprietary instruments, the HP 5370A/B, 5335A, and 5371A/5372A are out of production but readily available on the secondary market; the SR620, 53230A, CNT-91, and CNT-104S are still in current production from their respective manufacturers.

The Pendulum CNT-104S is the only other instrument in the table with four input channels and gap-free time-stamping on all of them — and Pendulum explicitly markets it for the same use case (phase comparison of four atomic clocks) at roughly 140× the price of the LectroTIC-4. The HP 5371A/5372A are the vintage instruments most likely to come up when time-and-frequency hobbyists want fast, continuous capture at modest single-shot precision; their 10–13 MSa/s continuous mode is the closest entry in the table to the LectroTIC-4’s burst rate, but only on a single channel and only in a measurement session bounded by the instrument’s capture memory.

In short: the eight instruments above are precision laboratory tools for measuring an individual event with picosecond-class accuracy. The LectroTIC-4 is a streaming recorder for measuring every event in a continuous train across four coherent channels, at the resolution ceiling of what an STM32H523’s hardware counter can offer in pure digital silicon.

Specifications

Channels and timing

Inputs

Reference clock and host interface

Physical and environmental

Schematics, Software, and Other Sundries

The hardware design and firmware are open-source.

• Firmware: src/app/timestamper/ in the RULOS project on GitHub.
• Schematic (Rev A): PDF · KiCad source.
• Board layout (Rev A): PDF
• BOM (Rev A): CSV with reference designators, values, footprints, and LCSC part links.

Join the Conversation