Genlocking a DeckLink Duo 2 at 1080p50, and pulling the reference: 27 September 2026

What we set out to learn

For two months the claims register on our front page, which says what would earn each claim, declined this one. We could tell you “the box runs correctly free”, but not what it does locked, “or what the first second after a reference failure looks like”. This is the test it asked for, run on 27 September 2026. Genlock locks a device’s video timing to a house reference (analogue blackburst or HD tri-level sync), so that every output in a facility runs at one rate and phase. Our design does not depend on it. Syke, the clock inside our playout engine Rytmi, takes its time from TAI (International Atomic Time) and measures how far the DeckLink card’s crystal runs from it, in parts per million (ppm). The difference is absorbed by discarding an occasional surplus frame from the handoff queue between engine and card. We call that a shed.

The first unit had never been genlocked, including through the 339-hour run of August 2026. From June until 17 August 2026, four of our own internal documents said it had. One record’s error was copied outward without being re-derived, and it stood until someone read the instrument. Until the lock described below, the card’s genlock state had read unlocked in every one of 78,132 samples on the first unit since it began publishing on 2 Aug 2026.

We wrote the test down on 14 September 2026, the day the sync generator was ordered. We froze it before any data existed (a pre-registration): “Nothing below may be edited after the first reading is taken.” It set four pass criteria, which we called gates:

• The flag: the card reports locked. This is necessary and explicitly not sufficient, so a pass means only “the card claims a lock”.
• The result: drift under 0.5 ppm for two hours.
• The consequence: no shed for six hours.
• The inverse intervention: pull the reference and watch drift and sheds come back, because “Without this the whole test is a coincidence.”

A card that locks but refuses the output mode, “e.g. a 1080i50 reference against a 1080p50 output”, was named in advance as inconclusive.

On 16 September, still before any hardware or data, we found that the second gate would fail a perfect lock. Our drift figure measured the card against Syke’s clock, not against the reference. A card locked flawlessly to a generator 2.5 ppm off TAI would therefore read 2.5 ppm. The gate became a convergence test instead: two units on one reference must agree within 0.5 ppm for two hours, since the generator’s own error is common to both and cancels. The generator’s absolute error became a description, not a gate: as of 16 Sep 2026 Blackmagic’s tech-spec page for it gives no ppm figure, and a threshold taken from the measurement it judges would be fitted to the result. The shed gate kept its wording, but continuing sheds would now refute genlock only at a cadence inconsistent with the measured locked drift. We expected fewer of them, having assumed a reference closer to TAI than the card.

The generator cannot emit 1080p50, the format of every channel, so the plan was to try 1080i50 first and then 720p50. The card’s detected-reference-mode reading would separate “the card cannot see the reference” from “the card sees it and refuses the mode”. The alarm on reference loss (a push notification to the operator’s phone) trips only on a transition out of locked. Because both units had only ever read unlocked, it could not be tested until a first lock existed. The acceptable behaviour on loss was written down first: “output continues, no frame is lost, the transition is reported, and the engine keeps running. A device that drops frames on reference loss is worse than one that never locked.”

What happened on 27 September

Both machines were development benches running a test schedule, not a production fleet: the first unit (i7-12700) and a second unit (i7-14700). Each had a Blackmagic DeckLink Duo 2 on driver 15.3.1a4, with one reference input for its four SDI outputs. One Blackmagic Mini Converter Sync Generator fed both units over separate cables. Its outputs carry blackburst or tri-level sync, not SDI, so the cards’ reference inputs were our only detector. The genlock-source setting in our configuration is still read by nothing, as of 27 Sep 2026: the cards locked without any instruction from our software.

1080i50: seen, not locked. We set the switches for 1080i50: 4 OFF, 3 OFF, 2 ON, 1 ON, per Blackmagic’s Converters manual. Every sub-device on both cards reported the detected reference as Hi50, the DeckLink SDK’s code for 1080i50. In 4.5 minutes of watching, neither unit locked, and drift stayed free-running. We read that as the card declining to lock a 1080p50 output to a reference it could see, and that reading rests on those 4.5 minutes. The flag, the drift and the detected mode all agreed, so this was no cosmetic lock. 1080i50 carries 25 frames a second as 50 fields; 720p50 carries 50 frames a second, like the output. Whether that is why this card declined is untested.

720p50: locked. We changed one switch (3 to ON) and no software. Both cards locked from 13:59 UTC, the first lock in the project’s history. That was five running outputs between them, one on the first unit and four on the second, every one at 1080p50. We then restarted both engines with the reference connected. Our drift figure was a run-cumulative mean, and a window straddling the lock would have blended two states. Both cards locked again at start-up.

Two crystals, one rate. Free-running, the two cards sat more than 4 ppm apart. Locked, their medians over 3.57 hours agreed to within 0.038 ppm (38 parts per billion), against the 0.5 ppm line. The only thing they now shared was the generator, which ran about 11.8 ppm slow against TAI. Blackmagic published no figure to compare it with. Ours comes from one generator on one afternoon, seen by two cards. Each card was measured against its host’s kernel TAI clock, which NTP disciplines. The figure describes this generator, not the product line.

Locking made shedding more frequent. At 14:08:38 UTC, before any locked shed, we wrote down what the locked cards’ early drift implied. It predicted one slipped 20 ms frame about every 28 minutes, roughly four times as often as the first unit’s own crystal would slip, so the frozen gate of no shed for six hours could not pass and its failure would not refute genlock. Over the whole window the drift medians give 0.020 s ÷ 11.81×10⁻⁶ = 28.2 minutes. The gaps were 24, 33 and 18 minutes on the first unit and 39, 29 and 28 on the second: one about every 29 minutes (median interval, both units) against 28.2 predicted, nearly four times as often as the first unit shed free-running, where the median interval was 110 minutes over 9–14 Sep 2026. While locked, neither the engine nor the card counted a late frame (the engine’s count records its clock thread waking more than half a millisecond late).

Pulling the reference. At 17:42:34 UTC we wrote our predictions down and read them back. At about 17:44 we cut the generator’s 12 V supply, with every channel on both units locked and playing out a test schedule. Both units read unlocked between the 17:44 and 17:45 samples. The alarm fired for the first time since we built it thirteen days earlier: at 17:46:02 UTC on the first unit and 17:49:55 on the second. Both notifications reached the operator’s phone. Our service log records only that the alert ran, so the phone was the only witness to that last hop. At one-minute resolution no engine counter moved on the first unit, and its worst clock-tick timing error of the run stayed at 1,297 ns. The second unit’s engine counted no late frame.

Drift came back at once, beneath a figure that did not. The published mean crawled from −11.72 to −11.49 ppm over six minutes, as we had said beforehand it would. Undoing the mean recovers the rate: mean × elapsed time is the card’s integrated offset from TAI, and its minute-to-minute difference is the rate. By 17:46 the first unit was at −2.77 ppm, against −2.927 free-running. The second unit was between −7.3 and −7.5, against −7.180. The first unit went 101 minutes from its last locked shed, at 17:33 UTC, before shedding again at 19:14. The second unit’s intervals between discards went back to a median of 47 minutes across its four outputs that evening, against 46 predicted for its crystal. The lever moved drift and sheds in both directions.

The numbers

What it cost, and what went wrong

The cost is the shed rate. As our results record puts it, “that is not a defect in either the generator or the engine — it is the two of them disagreeing about what time it is.” Syke keeps to TAI, the locked card keeps to its reference, and the difference goes into the queue. The cadence belongs to this generator; another reference would give another. A house reference makes the output coherent with a facility and, with a reference like this one, makes it drift faster against absolute time.

The step nobody was watching for. At the moment of lock, the first unit’s integrated card-versus-TAI offset, as the card reports it, went from −1.550 ms to −28.842 ms in one minute. The second unit’s moved 35.6 ms. Both exceed a 20 ms frame. The loss edge shows no step. That is physically sensible: acquiring a reference pulls the card’s phase into line, while losing one leaves the crystal free-running from wherever it was. No engine counter moved at the step. Nothing watched the wire either: the second unit’s SDI outputs had no cables attached, and nothing recorded the first unit’s.

Our own errors, in writing. We expected locking to reduce sheds, and they came nearly four times as often. Our hardware notes had called locking a 50p output to an i50 reference ordinary broadcast practice, and this card did not lock in 4.5 minutes of watching. The frozen shed gate failed as worded, for the reason we gave at 14:08:38. It was right to fail, but it did not pass, and we do not say it did. The first unit’s shed after the pull fell between our two predictions: 19:27, written before the pull as a full free-running cycle from its last locked shed, and 18:55, written at 18:47 to count the eleven minutes already spent at the locked rate, with a scatter of ten minutes or more that we did not state.

Our front page was wrong that afternoon. Fifteen updates of the data behind it, from 14:06 to 17:36 UTC, called the first unit free-running while its card read locked, because that description was a fixed string. The register row on holdover said no reference had been on the bench until we rewrote it that night. And under lock its drift label, “Card crystal error vs TAI”, would have put the generator’s error under the card’s name; that did not happen only because the page was showing a dated record, not live figures, that day.

What it changed

On 27 Sep 2026, with this generator, a 720p50 reference locked 1080p50 outputs on this card where 1080i50 did not. PAL blackburst was not tried. Two cards on that one reference converged to within 0.038 ppm over 3.57 hours. Across one pull, as far as the card and the engine can tell, the output kept running, no late frame was counted, the loss was reported and the alarm reached a phone. “No frame is lost” is an engine-side statement, because nothing watched the wire.

Our shed model predicts one slipped frame every 0.020 s divided by the drift. It had been checked only on free-running cards near 3 ppm; the time-to-slip row of our front page’s evidence table has those figures and their caveats. Here, at a drift near 12 ppm, it predicted the locked cadence before any locked shed. That night we changed our front page to derive the first unit’s description from the reference state the card reports. We also made it label a locked card’s drift as the reference’s, and withhold a drift mean that spans a change of lock.

There is no threshold to tune. With a reference present, the facility’s rate is the card’s rate. The engine runs on Syke and Syke keeps to TAI, so the queue absorbs the difference. One direction the record names is production that follows the reference’s rate. On 27 Sep 2026 it was not built, and how it would sit with events scheduled to air at a TAI instant was open. By mechanism rather than measurement, genlock should not touch the rare late wakes of our clock thread. Those are timed against the host’s own clock, upstream of the card, and one afternoon locked could not show it either way.