UDCF(4)

💖 udcf 💖

okay bestie, welcome to section 4 of the Kernel Interfaces Manual — this one's all about udcf, the Gude ADS Expert mouseCLOCK USB timedelta sensor ✨

---

🌸 NAME 🌸

udcf — Gude ADS Expert mouseCLOCK USB timedelta sensor 🕰️

---

🦋 SYNOPSIS 🦋

udcf* at uhub?

---

🎀 DESCRIPTION 🎀

so the udcf driver is the little matchmaker between your machine and the Gude ADS Expert mouseCLOCK USB and the Expert mouseCLOCK USB II — receivers for the German DCF77 🇩🇪. and like, yes, receivers for the British MSF time signal station also exist, but udcf does not support them, and that's just how it is 🙈.

udcf implements a timedelta sensor, and the delta (in nanoseconds, bb) between the received time info and the local time can be accessed through the sysctl(8) interface. the clock type shows up in the sensor description:

• DCF77 — German DCF77 time signal station (77.5 kHz longwave transmitter located in Mainflingen near Frankfurt).

the quality of the timedelta gets reported as the sensor status, and here's the vibe check on each one:

• UNKNOWN — no valid time information has been received yet. it's giving "we just met" 💀
• OK — the time information is valid and the timedelta is safe to use for applications like ntpd(8). slay, icon behavior 👑
• WARN — the time information is still valid, but no new time information has been decoded for at least 5 minutes due to a reception or parity error. the timedelta should be used with care 😬
• CRITICAL — no valid time information has been received for more than 15 minutes since the sensor state degraded from OK to WARN. this is an indication that the hardware should be checked to see if it's still functional. and heads up: the timedelta will eventually degrade to a lie, because all computer internal clocks have a drift 😭

---

🔥 SEE ALSO 🔥

intro(4), uhub(4), usb(4), ntpd(8), sysctl(8)

---

⭐ HISTORY ⭐

the udcf driver first appeared in OpenBSD 4.0. vintage ✨

---

💜 AUTHORS 💜

the udcf driver was written by Marc Balmer <mbalmer@openbsd.org>. thank u king 🫶

---

🌈 CAVEATS 🌈

okay so this part matters, pay attention bestie:

DCF77 uses a 77.5 kHz long wave radio signal transmitted from near Frankfurt, Germany. up to about 900 km, the radio signal can travel directly to the receiver, providing a linearly increasing time offset based on distance 📏.

but — due to the curvature of the Earth — beyond this distance the signal must bounce off the lower ionosphere (residing at approximately 70 km elevation during the day, and 90 km at night), thus causing a non-linearly increasing time offset which can only be roughly calculated using trigonometry 📐.

since the distance and transmission geometry is not known, the clock receivers and the udcf driver currently make no effort to calculate this offset. we simply assume that the offset is small 🤷‍♀️ (iconic of them, honestly).

and one more, because it's my favorite: in Germany, the train system uses DCF77 clocks. as the distance from Frankfurt increases, trains can be expected to run later 🚂💀 no cap.

fr fr, that's the whole manpage — every flag, every status, every caveat, all of it. don't come for me, I kept the facts 💅

---

and that's the wrap, bestie 🎀 this beauty is from the Debian edition, dated June 7, 2015, page UDCF(4) — stan a classic 💖✨🌸🦋