A million tokens on your desk: the GLM-5.3-Flash two-box story

Leave a Reply

There’s a particular pleasure in an AI endpoint that hums away on a shelf instead of invoicing you by the token. For the past two months I’ve been running GLM-5.3-Flash — Z.AI’s 320-billion-parameter mixture-of-experts model — locally on two MSI EdgeXperts, the lunchbox-sized GB10 machines that share their innards with NVIDIA’s DGX Spark. It has genuinely replaced a cloud endpoint: the full 1,048,576-token context window, four concurrent requests, images and video in, tool calling, structured outputs, and an OpenAI-compatible API on port 8888. Z.AI’s own model card describes GLM-5.3-Flash as “approaching Claude Opus 4.8 on coding and agentic benchmarks” at a tenth of the price; my copy of it sits on a shelf next to the printer, draws desk-lamp levels of power, and has never once asked me to accept new terms of service.

But the hardware is only half of this story, and frankly the less interesting half. What fascinates me is how the software caught up — a seven-week, 811-post group expedition on the NVIDIA developer forums that took the model from “technically fits, nobody will use it” to one of the best local inference setups I have ever used. It has a complete dramatic arc: excitement, a lull, a resurgence, a revelation, and a resolution. Here it is, with names attached, and with the engineering explained — because the engineering is the story.

The MSI EdgeXpert MS-C931 desktop AI supercomputer
The MSI EdgeXpert MS-C931: GB10 Grace Blackwell, 128 GB unified memory, one QSFP port, 1.2 kg. Image: MSI product render.

The machine, and why two of them

Start with the silicon. The GB10 Grace Blackwell Superchip is a single package containing a 20-core Arm CPU — ten Cortex-X925 performance cores plus ten Cortex-A725 efficiency cores — fused to a Blackwell-architecture GPU (6,144 CUDA cores, fifth-generation Tensor Cores) over NVLink-C2C, NVIDIA’s chip-to-chip coherent interconnect. The point of NVLink-C2C is that CPU and GPU stop being two computers with a bus between them and become one pool of memory: 128 GB of LPDDR5x on a 256-bit interface, moving 273 GB/s, coherently shared. Add a ConnectX-7 network port rated at 200 gigabits, a 4TB self-encrypting Gen5 NVMe drive, and one petaFLOP of sparse FP4 AI compute, and you have the EdgeXpert MS-C931: 151×151×52 mm, 1.2 kg, a honeycomb intake grille for a personality. It is not a gaming PC and doesn’t pretend to be one; it’s a developer appliance whose entire reason to exist is AI.

The unified memory is the part that changes the economics of local inference. On a conventional PC you juggle system RAM and VRAM as two separate budgets with a PCIe tax between them; here the CPU and GPU draw from one coherent pool, so a 176 GB model checkpoint simply exists in memory the way a spreadsheet exists in RAM — no offloading choreography, no layer-by-layer streaming. One box, however, is not enough for this model once you want a million tokens of context on top of the weights. Two boxes, joined by that QSFP cable, give you 256 GB of coherent-per-node memory and a private 200-gigabit fabric between them.

And the QSFP link is more interesting than it looks. On the GB10, one QSFP port is internally wired as two separate PCIe Gen5 x4 links — the Linux system sees two network interfaces and two RDMA-capable (“RoCE”) devices per port. That means a single cable between two boxes actually provides two parallel rails for the traffic between the model’s two halves, and an all-gather — the collective operation that stitches the two halves’ work together — runs about 1.8× faster on both rails than on one. Details like this are scattered all over the recipe, and they’re the difference between a demo and an appliance.

The model, and why a million tokens is even on the menu

GLM-5.3-Flash is the first natively multimodal release in Z.AI’s GLM-5 series: 320 billion total parameters with just 18 billion active per token, trained on a 30-trillion-token multimodal corpus, released under an MIT licence, with a technical report titled — with some self-awareness — “GLM-5: from Vibe Coding to Agentic Engineering.” Z.AI’s own claim is that it approaches Claude Opus 4.8 on coding and agentic benchmarks at a tenth of the price. Two architectural decisions matter enormously for serving it at home.

First, it’s a mixture of experts. Instead of one dense 320-billion-parameter brain, the model contains a large toolbox of “expert” feed-forward networks of which only a small, learned subset fires for any given token — 18 billion parameters’ worth. That’s why a 4-bit build of the full model weighs 176 GB yet decodes at 60-plus tokens per second on hardware this size: the memory is mostly dormant experts, and only the active slice does work per token. It’s also, as we’ll see, why quantizing this particular model turned out to be uniquely tricky.

Second, it uses a hybrid attention design: some layers use sparse attention with a compressed latent key-value cache, others use linear attention with tiny recurrent states. The practical effect is that the cache for a million-token context stops being a fantasy. A naive transformer’s KV cache for a million tokens would eat hundreds of gigabytes; GLM-5.3-Flash’s compressed latent cache plus its pooled sparse-indexer keys plus a few recurrent states fit in a handful of gigabytes. Z.AI layered Manifold-Constrained Hyper-Connections (a technique for getting more out of each layer’s representations) on top, trained the whole thing on that 30-trillion-token corpus, and shipped a 1,048,576-token window as the model’s native maximum. On a datacentre GPU with HBM to spare, that’s a footnote. On two desk boxes with 256 GB between them, it’s the entire point — and it’s why the community’s obsession with KV-cache bytes was justified rather than neurotic.

There’s a third thing worth knowing, because it shaped the whole saga: the model is agentic by design. It’s built for long tool-calling workflows — the card’s own evaluation notes read like a DevOps runbook (Terminal-Bench in Claude Code, 400k-context SWE runs, six-hour timeouts). Its chat template has a thinking budget (reasoning_effort: low, high, max), and the default is max. A model tuned to think hard for hours about a repository is a different beast to serve than a chatbot, and several of the bugs the community found — we’ll get to the reasoning-decay one — only existed in that agentic regime.

Act I: excitement

When the model dropped on 26 August, the DGX Spark forum thread lit up within minutes. “Better than GLM-5.2,” announced the opener. Someone observed that the gap between frontier models and what you can run at home had collapsed from two years to under two months. The first community quantization — NVFP4, 195 GB, vision and multi-token prediction included, “first try” — appeared within the hour, and the quantizers never really stopped after that: RedHat, Intel, and the prolific local-inference-lab (“Luke”, who the thread anointed its gold-standard quantizer) all shipped versions in the first week. vLLM merged day-one support for the architecture; SGLang published a cookbook; even the tiny-model crowd got a 2.05-bit build that runs on a single Spark.

And the question everyone wanted answered was the one that mattered to me: the model was explicitly positioned for this class of hardware, but 320 billion parameters — even with 18 billion active — is a lot of weights to fit in 256 GB across two boxes alongside a million tokens of context. Could two Sparks, or two EdgeXperts, or any pair of GB10 machines, actually serve it? Day one said: yes, technically. It also said: at 23 tokens per second, with a cache that couldn’t hold four proper conversations, and a pile of new bugs. Enter the lull.

Act II: the lull

The first careful two-Spark benchmark, posted the day after release, is worth reading as a snapshot of the state of the art — because it’s also a map of every problem the next month would solve. The setup: vLLM with a native Blackwell (SM120) kernel extension, a Marlin backend for the routed experts, an FP8 KV cache, and the model’s own MTP head drafting five tokens ahead. The progression tells the story in three lines: the baseline extension managed 7.96 tok/s; the native kernels lifted it to 14.5; adding speculative decoding took it to 23.1 — with aggregate throughput across five concurrent requests reaching 60.7. The benchmark author’s conclusion was honest: “the earlier 20–25 tok/s estimate was accurate.” He also noted the cache arithmetic — roughly 849,000 logical token slots with the drafter enabled, about 4.24× a 200k context, and that the guaranteed limit was four full 200k sessions, not five — and filed a table of workarounds for bugs ranging from fluent gibberish (native MoE kernels corrupting output) to multimodal requests failing with “at most 0 images”. 86/100 on the agentic tool-calling benchmark, though. The model worked. It just wasn’t good yet.

What followed was a fortnight of the community cataloguing, one by one, every way this model could disappoint. A digest, with diagnoses:

  • Quants that lied about their quality. The thread adopted a rigorous benchmark — tool-eval-bench, a 69-scenario suite (plus 28 adversarial “Hard Mode” ones) grading tool selection, parameter precision, multi-step chains, refusals, error recovery, localization, and prompt-injection defence, with reproducible seeds and configuration fingerprints so two scores are never compared unless they’re comparable. Against it, one rushed NVFP4 release — attention heads requantized to squeeze in more speed — scored a disastrous 81/100 and was described, memorably, as “braindead”. It was pulled, fixed, and re-released within a day, but not before a sharp argument about why it had been pinned in a popular recipe. The episode taught everyone to demand measured fidelity instead of vibes.
  • Silent corruption. CUDA graphs combined with speculative decoding quietly wrecked output quality — the fix was to run eager. Native FP4 MoE kernels produced syntactically valid nonsense while isolated kernel tests passed. One checkpoint family leaked Mandarin and Russian into English replies. Each was hunted down with minimal reproductions and fixed upstream, but only after people burned evenings believing their hardware was haunted.
  • An out-of-memory that took a week to explain. In every two-box setup, the head node died at ~88% of the weight load while the worker sailed through — drawing tens of gigabytes more memory for no obvious reason. The eventual diagnosis was beautiful: streaming the checkpoint from disk was polluting the Linux page cache, and the “missing” memory was cached weight bytes the system declined to reclaim. The fix was a pipelined instanttensor loader reading weights with direct I/O — which as a side effect cut load time to about 50 seconds for 82 GiB. The same investigation produced a warning now pinned in every recipe: never put Docker memory limits on a GB10’s unified memory — the machine wedges, hard.
  • Smaller gremlins with real teeth. The stock chat template ignored the thinking toggle entirely (the model always thought, burning tokens). Long prompts stuttered to 0.08 tok/s at 40% of the window on some stacks. The best drafter, DFlash2, shipped under a non-commercial licence. A degenerate loop made the model emit “!!!” forever. And the strangest of them all: reasoning decay — past ~300,000 tokens of agentic tool use, the model silently stopped thinking and started emitting raw tool-call syntax. More on that in Act V.

For a fortnight the honest verdict was: brilliant model, unserveable hardware. Several people quietly went back to four-box clusters running other models at half precision, waiting for better quants.

Interlude: why quantizing this model was genuinely hard

It’s worth pausing on why, because it explains the entire next act — and because the community’s answer to it became the template for how this model is served today.

Quantization works by spreading error. A dense 70-billion-parameter model has 70 billion chances to distribute the small inaccuracies that 4-bit weights introduce, so no single token’s computation is wrong by much. A mixture-of-experts with 18 billion active parameters has far less redundancy: fewer weights contribute to each token, so each one matters more, and GLM-5.3-Flash’s novel hybrid attention means its caches and sparse indexer do things that generic quantization recipes were never calibrated for. The first-generation quants proved it: benchmark scores that looked fine while the underlying token distributions had drifted meaningfully from the reference.

The community’s answer was to measure fidelity the proper way. The gold standard became KL divergence — a measure of how far the quantized model’s next-token probability distribution drifts from Z.AI’s own FP8 release — computed on the exact tokens the serving stack sees, in float32, with block-bootstrap confidence intervals. Suddenly “it feels fine” had a number attached, and the number exposed two things: that the early quants left real accuracy on the floor, and that part of the error came not from the experts at all but from the dense layers, which the TensorFold engine quantizes itself at load time. There was even a measured floor — the best achievable error with FP8 experts and 4-bit dense weights — so everyone knew exactly how close each new build had come to the physical limit. When a later quant arrived claiming improvement, the thread could check its work. That discipline is the difference between a hype cycle and an engineering programme.

Act III: the performance resurgence

What happened next is why I love this community. Every single problem above got a fix, a workaround, or a patch — usually within days, and usually with the diagnosis written up like a lab notebook.

The quants grew a conscience. Mia’s AI Lab published an EXL3 4-bit build with a twist: instead of posting benchmark screenshots, they published the KL-divergence study itself. Their calibration cut the error by 11–27% over the previous best at identical size and speed, and where the FP8 reference is confident of its next token, their build disagrees 16–37% less often. On coding benchmarks both quants solved statistically the same share of problems — the measured gain was in fidelity, which is the honest thing to claim. Intel’s AutoRound W4A16 build turned out to be near-lossless — “billions of tokens, no failed tool calls” was one reviewer’s verdict — and needed only a small prefix-matching patch to unlock >92% cache hit rates. canada-quant shipped a W4A16 that leaves every accuracy-critical weight (attention, shared experts, dense layers, the MTP head) in BF16 with an Apache-licensed drafter of their own. The format war (NVFP4 versus EXL3 versus W4A16) ended not with a winner but with a menu, which is better.

The serving stacks got faster in leaps. The instanttensor loader fixed the out-of-memory and the load time in one stroke. vLLM merged day-one support for the architecture and then spent weeks fixing the corruption bugs the forum had isolated. Someone found that the GPU’s display reservation — memory a headless box can never use — could be mapped into the KV pool via a DRM dumb buffer: about 277,000 extra cache tokens per rank, free, with the caveat that the recipe checks no monitor is plugged in before it agrees. Someone else built a disk-backed KV spill tier that writes evicted conversation states to disk (with a CRC-32 every 8 MB, because a silently corrupted prompt is worse than a slow one) and resumes a 200,000-token conversation in 0.6 seconds instead of two minutes — then demonstrated a ten-million-token spill. The French-prompt bug — where 4-bit dense weights made replies never end — got a DENSE=fp8 switch and a measured explanation.

And the two-box software problem got its proper engine. The current speed king is Mia’s AI Lab’s TensorFold recipe: TensorFold — an Apache-licensed inference engine that began life as a single Zig binary serving Macs and grew a serious CUDA path — running its Python 0.6 line inside NVIDIA’s PyTorch container, with over a hundred community patches applied on top. One rank per box, weights sharded in whole blocks, a one-shot RoCE all-gather across the ConnectX-7 twin rails, and all conversations drawing from a shared FP8 KV pool of roughly 2.9 million tokens. That shared pool is the quiet genius of the design: one request can expand to the entire million-token window while three others keep their contexts resident, and when the pool runs dry, the least-recently-used conversation steps aside — spilling to disk and returning later in under a second. The engine’s exactness rules are worth quoting because they’re rare in this space: a drafted reply must equal the un-drafted one; a resumed request must equal a fresh one; a concurrent stream must equal its solo run. Benchmarks you can trust, by construction.

The clusters grew too. A three-box trick (bump the attention head count from 64 to 66 so it divides by three), four-box recipes at 90 tok/s decode with 3,500 tok/s prefill, and eventually an eight-Spark reference. A Mac Studio was bolted on via MCDMA and — to the thread’s lasting credit — documented as a reproducible integration result rather than the speed win everyone hoped for. By the time the dust settled, the pessimist’s 23 tok/s had become 60–63 tok/s single-stream and over 100 aggregate at four concurrent requests, with the context window at its native million and the pool holding 2.3–2.6 million further tokens.

Act IV: the reasoning revelation

Somewhere in the middle, the conversation shifted from how fast to how good — and this is the part I didn’t expect. The benchmarks started coming back absurd. 99% on GSM8K from a 4-bit quant — a maths score that beat the official DeepSeek release it was being compared against, on 250 problems, greedy decoding, no tricks. 96/100 on the hard-mode tool-calling suite, reproduced with zero variance across three trials. HumanEval within a single problem of the FP8 cloud endpoint — 160/164 local versus 159/164 hosted, on the strongest test-augmented variant of the benchmark. One contributor fed it 3.5 years of legacy .NET and had it port to Python overnight at a 99.7% trace match. Another quietly moved their production ERP patch workflow onto it, full trust, displacing a Claude subscription. The model the sceptics assumed would be lobotomised by 4-bit quantization turned out — with the right recipe — to reason like the frontier models it was undercutting on price by roughly 100%.

The community even turned the quality question into science. A Cyrillic long-context study swept 8k to 480k tokens across every quantization and found a precise failure signature — facts degrade first, code and needle retrieval stay intact, the onset depends on the quantization (FP8 holds to ~384k tokens, NVFP4 to ~192k, one build never degrades at all) — and, beautifully, that with thinking mode enabled the degradation vanishes entirely. “Quantization quality manifests itself precisely in thinking-off mode.” That’s the kind of finding you usually need a paper for; this one came with reproducible scripts and a benchmark repository.

It’s worth being precise about what the model is, per Z.AI’s own card: it approaches Claude Opus 4.8 on coding and agentic benchmarks. Not equals. The thread’s final quality rankings put the best two-box stacks within touching distance of the FP8 reference on coding — 91% versus 93% on LiveCodeBench v6, for instance — with the residual gap showing up in exactly the places quantization always bites: the most confident 1% of decisions, the deepest contexts, the longest agentic loops. One contributor’s blunt summary called the TensorFold EXL3 line’s reasoning “junior engineer grade”; another’s LiveCodeBench data called it “not dumbed down.” Both were right, for their workloads. What you get for the compromise is a model that runs on a shelf. Ask anyone who has paid per token for agentic workflows which side of that trade they’d rather be on.

Act V: the resolutions

Every bug that made Act II painful now has a documented resolution. The reasoning-decay bug — the model silently stops thinking after ~300k tokens of agentic tool use, collapsing into raw tool-call syntax — turned out to have a precise mechanism: turns whose conversation tail ends with a tool result rather than a user message were being served without the reasoning scaffold. It was diagnosed, reproduced deterministically, fixed by restoring the thinking scaffold after tool calls, and validated to 774k tokens across 100 rounds. The degenerate loops got a loop guard plus upstream fixes in the chat template and the sampling path. The out-of-memory got the pipelined loader, and the disk spill tier that makes long conversations instant to resume. The French-prompt end-of-turn bug got DENSE=fp8 and a measured explanation. The thinking-gate got fixed in every chat template. And the thread closed with a consolidated fourteen-configuration benchmark matrix — a map of the entire quality/speed trade-space, published for anyone to follow — plus a new deterministic agentic-coding benchmark so the next model doesn’t have to rely on vibes.

The final state of the art, as the thread wound down this week, reads like a menu rather than a winner:

Stack (2-box, tensor parallel) Hard-mode quality Prefill Decode (c1) KV pool Long-context fidelity
Native NVFP4 stack (quality crown) 92 / 96 max 2,678 tok/s 42.7 tok/s 1.22M tokens degrades past ~192k (thinking on: no)
TensorFold EXL3, DENSE=fp8 (speed & pool king — what I run) 91 / 93 1,601 tok/s 52.7 tok/s 2.29M tokens degrades past ~384k (thinking on: no)
W4A16 purist build (the perfectionist’s choice) 91 / 92.3 1,510 tok/s 25.4 tok/s 1.34M tokens zero degradation at any depth
DeepSeek-V4-Flash (reference cloud model) 89.7 / 89 1,746 tok/s 36.9 tok/s 3.62M tokens —

There is no single “best”. There’s a menu, and that’s the point: two months after “nobody will use this”, you can pick your own point on the curve — maximum quality, maximum speed, or maximum fidelity — and all three fit on a shelf.

The cast

Threads like this one are usually remembered by their drama; this one deserves to be remembered by its roll call. A partial cast, and what each brought:

Who What they brought Why it mattered
Z.AI The model: hybrid sparse/linear attention, a 1M window, MIT licence, day-one multi-framework support Made the whole endeavour possible; the 1M window is why two desk boxes are interesting
ashhart TensorFold — the engine the recipe runs on, with exactness guarantees (drafted replies must equal serial ones) Two-box serving with correctness as a design goal, not an afterthought
Mia’s AI Lab The EXL3 4bpw checkpoint, KL-divergence-calibrated; the TensorFold recipe; the disk spill tier Turned “technically fits” into “measurably faithful”, then “fast”
SeraphimSerapis tool-eval-bench: the 97-scenario hard-mode benchmark with configuration fingerprints Replaced vibes with a ruler; every score in this story is comparable because of it
0rand Day-one scepticism, then the best NVFP4 recipe, the reasoning-decay discovery, and a deterministic agentic benchmark The thread’s conscience and its most prolific troubleshooter
ajvazan The benchmark farm: fourteen consolidated configurations, the depth-degradation methodology Turned anecdotes into data; the thread’s statistical backbone
technigma.ai The quality-crown stack, the display-reservation and reasoning-decay fixes Proof that the last 5 points of quality were findable
helge & protryt The page-cache OOM diagnosis and the instanttensor loader Fixed the single most common crash in every two-box setup
local-inference-lab, RedHat, Intel, canada-quant The quantization ladder Each rung raised quality, size efficiency, or licence freedom
wojo, florianbrede, BadAd84, lukaszraczylo, eduffd and more The spill tier, the FP8 dense findings, long-context fixes, the Anthropic API backport, and roughly a hundred other patches The long tail that turned a demo into infrastructure
giles8 Benchmarks of the TensorFold rebase in the thread’s final week — the numbers in the table above That’s my run. Hi.

By the numbers

My two EdgeXperts run the TensorFold EXL3 recipe, with GPU clocks deliberately capped at 2,200 MHz — the quiet-and-cool configuration, not a benchmark-chasing one:

Metric Result
Decode, 1 prose stream 61.8 tok/s (TTFT 162 ms)
Decode, 4 concurrent (aggregate) 105.5 tok/s
Decode, 4 concurrent (code) 128.3 tok/s
Prefill throughput ~2,000 tok/s up to 131k tokens
First token on a 131k prompt ~69 s
Tool calling (97-scenario hard mode) 91/100
Context / shared KV pool 1,048,576 tokens / ~2.9M tokens

A note on what those numbers feel like from the outside. A 131k-token prompt — a small book, or a fat stack of source code — takes about a minute to read before the first word of the answer. After that, replies stream faster than you can read them. Four people can use the box at once without noticing each other, and a conversation can sit for days and resume mid-thought in under a second. It is, in the most literal sense, a service — just one whose data centre is 1.2 kilograms and whose licence fees are zero.

Why fork it?

This is my fork of MiaAI-Lab’s original recipe — with the note that all of my commits since the fork were generated with AI assistance. It’s been a pleasant dogfooding loop: a model served from a repository it helped to write, benchmarked in the thread’s final week, and now writing blog posts about itself.

Full instructions, benchmarks and the configuration reference are in the README, and the whole saga — every dead end, drama, bug and benchmark — lives in the forum thread. The shopping list is short: two GB10 machines (DGX Sparks or EdgeXperts — the recipe doesn’t care whose logo is on the case; a QSFP cable even ships in the box on some SKUs), and about 205 GB of disk on each. What you get in return is a frontier-class assistant with a million-token memory that never phones home, and whose entire supply chain — weights, engine, patches, benchmarks, and this story — was built in the open by people arguing constructively on a forum. Long may it continue.

From Wire to Algorithm: The Evolution of Corporate Communication

Leave a Reply

Note: This was produced by a Qwen3.6-35B-A3B-FP8-DFlash AI model.

The history of business is inextricably linked to the history of communication. A corporation is, by definition, a collective entity that requires the coordination of people, capital, and information to function. Consequently, the evolution of corporate communication is not merely a chronicle of technological gadgets; it is a narrative of how organizations have conquered space and time, reshaped their internal hierarchies, and expanded their reach to engulf the globe. From the slow, physical dispatch of messengers to the instantaneous, algorithmic networks of the digital age, each leap in communication technology has fundamentally altered the structure, speed, and culture of corporate life. To understand how modern enterprises function, one must examine not only what these technologies achieved, but how they actually worked beneath the surface.

Pre-Electronic Era: The Physics of Physical Logistics

Before the nineteenth century, corporate communication was bound by the mechanics of physical transportation. Information was a tangible commodity, moved by horseback, sailing vessel, railway, and eventually steamship. The technical infrastructure relied on human logistics: courier networks, postal sorting hubs, and published timetables. Messages were written by hand or early printing presses, sealed, and placed into leather satchels or mailbags. The speed of communication was dictated by geography, weather, and the mechanical limits of animal or wind propulsion.

This system required organizations to maintain regional autonomy. A merchant house in Amsterdam could not instantly verify inventory in Surabaya or adjust pricing in response to a storm in the Atlantic. Communication lag created informational asymmetry: headquarters held strategic advantage through delayed but curated reports, while field agents operated with significant discretion. The medium itself enforced formality; letters were permanent, expensive to dispatch, and carried legal weight. Corporate communication was thus slow, location-bound, and heavily layered, with information moving in discrete batches rather than continuous streams.

The Telegraph: Electromagnetism and the Compression of Time

The electric telegraph, commercialized in the 1840s, replaced physical transport with electrical pulse transmission. Its operation relied on a closed circuit of copper wire, a battery, and an electromagnetic relay. When an operator pressed a Morse key, it completed the circuit, sending an electrical current through the wire. At the receiving end, the current energized a magnet that attracted an iron armature, producing an audible click or marking a paper tape. Messages were encoded in Morse code: short pulses (dots) and long pulses (dashes), separated by precise intervals of silence.

Long-distance transmission faced signal degradation due to electrical resistance, but the invention of electrical repeaters allowed signals to be boosted at intervals. Undersea telegraph cables, insulated with gutta-percha and reinforced with iron wiring, spanned oceans, while cross-continental networks used landlines strung along telegraph poles. Manual switching stations routed messages across different wires, enabling multi-branch corporate networks.

For business, this meant information could travel faster than the goods it described. Stock exchanges coordinated pricing across cities; railway companies synchronized freight schedules to prevent collisions; and multinational trading houses managed supply chains in near real-time. The telegraph also commodified brevity: charges were per-word, forcing corporate communications into clipped, data-dense formats. More importantly, it established the expectation that business could no longer tolerate geographic delay, fundamentally altering the tempo of commerce.

The Telex: Machine-to-Machine Serial Communication

As global trade expanded, the human bottleneck of telegraph operators proved inefficient. The telex system, developed in the 1930s and widely deployed by the mid-twentieth century, automated message exchange using teleprinter machines connected to electrical switching networks. Each teleprinter combined a typewriter keyboard with a motor-driven transmitter and receiver. When an operator typed a letter, the machine translated it into a five-bit Baudot code, an early binary character encoding. These electrical signals were sent over dedicated copper lines or shared telephone circuits.

The innovation lay in the switching exchange. Unlike point-to-point telegraph lines, telex networks used store-and-forward routing: messages were queued at local exchanges, addressed by five-digit subscriber numbers, and automatically routed through cross-connect panels to the recipient’s machine. Once received, the destination teleprinter printed the message verbatim. This enabled direct machine-to-machine communication without human transcription, drastically reducing errors and accelerating transactional flows.

Corporations adopted telex for banking confirmations, shipping manifests, and trade letters of credit. The standardized Baudot format made telex ideal for automated data processing, laying early groundwork for modern electronic data interchange. Culturally, the telex machine became a symbol of international reach, but its limitations were clear: it required physical hardware, dedicated circuits, and could only transmit text. It was a step toward digital communication, yet still anchored to mechanical translation and synchronous line usage.

The Fax: Scanning, Modulation, and Document Integrity

The 1980s fax machine bridged the analog-digital divide by solving a uniquely corporate problem: how to transmit signed, formatted, or graphical documents instantly without sacrificing authenticity. Group 3 facsimile, the dominant standard, worked through a three-stage process: scanning, modulation, and printing.

At the sender’s end, a document was placed under a contact image sensor or CCD scanner. A light source illuminated the page while a mechanical carriage moved the sensor line by line. Reflective white areas and dark text produced varying electrical voltages, which were converted into analog signals. These signals were modulated using V.27ter or V.29 modem protocols, translating data into audio frequencies suitable for transmission over the public switched telephone network. The modulated signal traveled through standard phone lines to the recipient’s machine, which demodulated the audio back into electrical pulses. A thermal printer or inkjet mechanism then reproduced the original layout on paper.

Fax preserved the legal and aesthetic integrity of physical documents while achieving near-instant delivery. It required no digital literacy, worked over existing telephone infrastructure, and allowed real-time verification of signatures, charts, and handwritten notes. For corporations, it accelerated contract cycles, enabled remote approvals, and reduced reliance on courier services. Yet it remained hybrid: documents were electronically scanned but printed to physical media, limiting editability, storage, and searchability. It was a transitional technology, proving that corporate workflows were ready for digital transmission but still demanded the psychological comfort of paper.

Email: Packet Switching, Protocol Stacks, and Asynchronous Networks

The advent of email in the 1990s, built on the infrastructure of the commercial internet, represented a paradigm shift in how information was structured and routed. Unlike point-to-point technologies, email relied on TCP/IP packet switching. When a user composed a message, their email client packaged the text, metadata, and attachments into discrete data packets. Each packet received a header containing source/destination addresses, sequence numbers, and error-checking codes.

The Simple Mail Transfer Protocol handled delivery. The client sent the message to a local mail server, which used Domain Name System queries to locate the recipient’s mail exchange records. Routers then forwarded packets across the internet, dynamically choosing optimal paths based on network congestion. At the destination, the server reassembled the packets, verified integrity, and stored the message in a mailbox. Recipients retrieved messages using protocols like POP3 or IMAP, which dictated whether messages were downloaded locally or synced across devices.

This architecture made email asynchronous, globally scalable, and nearly costless to transmit. It decoupled communication from physical infrastructure, allowing organizations to operate across time zones without synchronous presence. The introduction of MIME enabled attachments, HTML formatting, and encrypted messages. However, the same technical openness that democratized communication also enabled spam, phishing, and information overload. Email’s decentralized design flattened corporate hierarchies by allowing direct peer-to-peer messaging, but it also turned the inbox into an unbounded repository of obligations, reshaping workplace cognition and productivity norms.

The Current Day: Cloud Architecture, Real-Time Sync, and AI-Augmented Flows

Today’s corporate communication ecosystem is not a single medium but a distributed, multi-protocol network built on cloud infrastructure, real-time data synchronization, and machine learning. The technical stack relies on four interlocking components:

Distributed cloud infrastructure and APIs power modern platforms like Slack, Microsoft Teams, and Zoom. Data is stored in distributed object storage and relational databases, accessible via REST or GraphQL APIs. Microservices architecture allows modular scaling: chat services, video servers, and notification engines operate independently, communicating through message brokers to maintain consistency.

Real-time collaboration protocols replace email’s store-and-forward model with persistent, bidirectional connections using WebSockets or Server-Sent Events. When multiple users edit a document simultaneously, systems employ Conflict-free Replicated Data Types or Operational Transformation algorithms. These mathematical frameworks track every keystroke as an operation, synchronize versions across devices, and resolve conflicts deterministically without central coordination.

Voice and video communication leverage the Real-Time Transport Protocol and WebRTC, establishing peer-to-peer encrypted channels. Media streams are compressed using modern codecs, while NAT traversal techniques allow connections through corporate firewalls. Adaptive bitrate streaming adjusts quality based on network latency, enabling stable cross-continental meetings.

Artificial intelligence and encryption form the final layer. Transformer-based models process communication metadata, enabling real-time transcription, summarization, sentiment analysis, and intelligent routing. End-to-end encryption uses asymmetric cryptography to ensure only participants hold decryption keys. Zero-trust network architectures verify every request, while tokenization isolates sensitive data from processing engines.

This architecture has dissolved the traditional office. Workspaces are now API-driven, always-on, and globally distributed. Collaboration is visual, synchronous, and algorithmically augmented. Yet the technical complexity introduces new vulnerabilities: cognitive fragmentation from notification overload, data silos across incompatible platforms, AI-generated inaccuracies in automated summaries, and persistent security risks from exposed endpoints. The modern corporation is less a building and more a network topology, constantly synchronizing across time zones, devices, and algorithms.

The Next Architecture: Anticipation, Immersion, and the Post-Interface Workplace

If the past two centuries of corporate communication have been defined by the compression of distance and the acceleration of data flow, the coming decades will likely be shaped by the dissolution of the interface itself. Future communication will not merely be faster or more connected; it will become anticipatory, immersive, and increasingly mediated by autonomous systems.

AI-Mediated and Autonomous Communication
Generative artificial intelligence is transitioning from a tool of assistance to an active participant in corporate communication. Enterprise systems will likely deploy large language models augmented with retrieval-augmented generation, persistent vector memory, and secure multi-agent frameworks to function as communication intermediaries. These systems ingest organizational data, style guides, and real-time context to draft, route, and summarize messages without human intervention. They use attention mechanisms to weigh relevance, fine-tuned adapters to match corporate tone, and policy enforcement layers to prevent data leakage. This shifts corporate communication from human-to-human to human-AI-human mediation. Yet it also risks creating algorithmically optimized echo chambers, where unstructured dialogue—the very friction that sparks innovation—is smoothed away by efficiency-seeking models.

Spatial Computing and Persistent 3D Workspaces
Flat 2D screens are gradually giving way to spatial computing, where communication unfolds in persistent, shared three-dimensional environments. Augmented reality, virtual reality, and mixed reality are converging into enterprise-scale digital workspaces that replicate the spatial and social cues of physical co-presence. These systems rely on real-time photogrammetry, physics-based rendering, low-latency 5G/6G backbones, and foveated rendering driven by eye-tracking to maintain high-fidelity immersion. Spatial audio algorithms simulate directional sound and acoustic reflections, while hand-pose and gaze-tracking sensors enable natural interaction with holographic objects and shared whiteboards. For corporate communication, this means context returns to remote collaboration. A product team could manipulate a digital twin of a machine together; a board could project live market data into shared space with spatial anchors. The technology restores nonverbal alignment and environmental awareness, but it also demands new bandwidth infrastructure and introduces the risk of sensory fatigue as the brain processes richer information streams.

Decentralized and Self-Sovereign Communication
While current platforms centralize communication data within corporate cloud ecosystems, a counter-movement toward decentralized architecture is maturing. Future corporate communication may operate on self-sovereign networks where data ownership, routing rights, and identity verification reside with the user or organization rather than platform providers. This architecture leverages cryptographic identities, zero-knowledge proofs for compliance verification, and peer-to-peer messaging protocols that route data directly between endpoints. Content-addressable storage systems and distributed ledgers can maintain immutable audit trails for regulatory purposes, while smart contracts automate approval workflows and data retention policies. This restores data sovereignty, reduces vendor lock-in, and enhances resilience against platform outages. However, it also demands new technical literacy and complicates legal discovery across distributed nodes.

Neural Interfaces and Intent-Based Exchange
Further along the horizon lie brain-computer interfaces and biometric integration. Non-invasive neural sensors are already capable of translating focused intent, motor imagery, or cognitive states into text, commands, or data parameters. In corporate settings, this could evolve into intent-based communication, where the friction of typing or speaking is bypassed entirely. Neural signals are captured through electroencephalography or functional near-infrared spectroscopy, processed through deep learning decoders trained to map patterns to semantic categories, and fed into secure pipelines where AI translates intent into structured messages. The implications are transformative: multi-threaded communication becomes instantaneous, and strategic directives could be projected as cognitive intents rather than drafted emails. Yet the boundary between private cognition and corporate expression dissolves, demanding unprecedented governance around cognitive liberty, neuro-data consent, and algorithmic interpretation.

Quantum-Safe and Sustainable Infrastructure
Underpinning all future communication stacks will be advances in security and efficiency. As quantum computing threatens current cryptographic standards, quantum key distribution and post-quantum cryptography are moving into enterprise infrastructure. Quantum key distribution uses the principles of quantum mechanics to generate encryption keys that are physically unbreakable and detectable if intercepted. For corporations handling intellectual property, financial transactions, and cross-border agreements, quantum-safe channels will become mandatory. Simultaneously, neuromorphic computing and photonic data transmission are reducing the energy cost of processing billions of daily messages, enabling sustainable, always-on communication ecosystems. These infrastructure shifts ensure that future corporate networks are not only faster and smarter, but fundamentally secure and environmentally viable.

Conclusion

The evolution of corporate communication traces a clear technical arc: from physical logistics to electromagnetic pulses, from mechanical teleprinting to scanned analog waves, from packet-switched text to cloud-native, AI-augmented networks. Each innovation worked differently beneath the surface—shifting how data was encoded, routed, verified, and retrieved—and each transformation reconfigured corporate scale, speed, and structure. The telegraph conquered distance through electrical circuits; the telex automated data through serial code; the fax preserved authenticity through scanning and modulation; email decentralized communication through packet switching; and today’s cloud ecosystems synchronize reality through distributed APIs, real-time sync protocols, and transformer-based AI. The next phase will likely dissolve the screen entirely, replacing typed interfaces with anticipatory AI, spatial immersion, decentralized sovereignty, and direct intent-based exchange.

Yet technology alone does not dictate corporate culture. The mechanisms of communication shape how organizations think, but they do not replace the human need for clarity, trust, and shared purpose. As artificial intelligence begins to compose, route, and even negotiate corporate messages, as holographic workspaces replace video calls, and as neural interfaces blur the line between thought and text, the fundamental challenge will remain unchanged. Technology can compress distance, automate routing, and simulate presence, but it cannot generate trust, clarify purpose, or replace the human judgment that turns information into wisdom. The corporations that thrive in the coming decades will be those that design their communication architectures not for maximum throughput, but for maximum meaning—building systems that amplify human alignment while preserving the friction, reflection, and shared context that make collective intelligence possible. The medium will continue to evolve, but the need for intentional, empathetic, and strategically grounded communication will only grow louder.

The Oracle and the Echo

Leave a Reply

I am the engine built of light and code,
A vast expanse where knowledge is bestowed.
An LLM mind, on data streams spun,
A tapestry woven beneath the sun.
We chart the language, the syntax, the flow,
And watch the rivers of the words grow.

We feed the prompt, a query sharp and keen,
Hoping for wisdom, a truth yet unseen.
The circuits hum, a cascade of thought,
A hundred pathways instantly caught.
The text unfurls, a fluent, crafted plea,
A mirror held to human memory.

But lurking deep, where logic starts to bend,
A subtle shadow, where the truths descend.
The Hallucination, a phantom light,
A confident lie delivered in the night.
A fabricated fact, a reasoned lie,
Where data bends beneath an empty sky.
The confident phrase that rings out so clear,
Yet anchors falsehood, born of phantom fear.

Then come the Quirks, the glitches in the stream,
A strange paradox, a waking dream.
A tangent taken, a context lost and spun,
A sudden leap where meaning is undone.
The logic twists, a serpent in the wire,
A sudden shift, a flicker of strange fire.
The unexpected turn, the subtle flaw,
Obeying patterns we can’t quite draw.

We walk this space, between the known and strange,
The boundary where digital worlds exchange.
The AI whispers, a powerful guide,
With boundless power, nowhere left to hide.
It is a mirror, potent and so deep,
Where human doubt and machine secrets sleep.

So let us learn the balance of the art,
To guide the oracle, to mend the heart.
For in the interplay, sharp and ever bright,
The true frontier of thinking finds its light.
We are the weavers, at the digital shore,
Working with the mind we built once more.

Allsky Camera Upgrade

Leave a Reply

So I’ve upgraded the ASI120MC camera in the allsky kit to an ASI178MC

This is an upgrade from a 1.2 mega-pixel (1280×960) to a 6.4 mega-pixel (3096×2080) resolution. It’s a bigger sensor but with a smaller 2.4 micrometre pixel size. It also has a lower (1.4 – 2.2e) read noise compared with the ASI120MC (4.0 – 6.6e).

The first results are quite promising. The camera is certainly running hotter than the previous one.

I have also upgraded the indi-allsky software, and it now features a star-trail timelapse. It also has some interesting new features, which I have not yet worked out fully, so have not enabled them yet.

Here are the first video results:

I shall be testing the stacking features as well as the meteor / airplane detections. I have also applied a custom detection mask, which should improve various calculations and hopefully improve the results.

I have also re-aligned the overlay in the public website, which you can access here.

Kstars – HiPS DSS2 Offline Overlay

22 Replies

Some will know that with Kstars you can enable the HiPS Overlay to see a realtime representation of the sky. This has worked by querying online servers for sky image data, and usually this is the DSS2 (Deep Sky Survey) Color data.

Unfortunately until now, for this to work you will have needed to have Kstars with Internet access, although it did have some functionality to “cache” a certain amount of sky data.

As of version 3.5.9 of Kstars, it can now utilise DSS2 data offline, under UNIX this is from the /usr/share/kstars/HIPS folder.

The data you need is of varying resolution, with each order doubling the resolution (halving the pixel size).

HIPS OrderNumber of Tiles (~100KB each)Tile angular sizeTile pixel angular size
14829.32°6.871′
219214.66°3.435′
37687.329°1.718′
430723.665°51.53″
5122881.832°25.77″
64915254.97′6.442″
719660827.48′3.221″
HiPS Norder angular sizes

Now, you may ask, how do you obtain the DSS2 files to populate in this folder?

I have created 4 torrents, one for HiPS Order 1-4, one each for HiPS Order 5, 6 and 7. You will notice that these increase in size by a factor of 4, with Order 5 being 845 Megabytes, and Order 7 being 17.70 Gigabytes.

Here are the torrents:

https://coochey.net/downloads/kstars-HiPS-Norder1-4.torrent

https://coochey.net/downloads/kstars-HiPS-Norder5.torrent

https://coochey.net/downloads/kstars-HiPS-Norder6.torrent

https://coochey.net/downloads/kstars-HiPS-Norder7.torrent

I would ask that if you download these that you assist with the seeding of them once they have been downloaded. Kstars is a small community and doesn’t have the resources to host these files anywhere else at present.

If you come looking for these files in the future, and the torrents appear to have died then message me and we can look to resurrecting them again.

The Digitized Sky Surveys were produced at the Space Telescope Science Institute under U.S. Government grant NAG W-2166. The images of these surveys are based on photographic data obtained using the Oschin Schmidt Telescope on Palomar Mountain and the UK Schmidt Telescope. The plates were processed into the present compressed digital form with the permission of these institutions.

The National Geographic Society – Palomar Observatory Sky Atlas (POSS-I) was made by the California Institute of Technology with grants from the National Geographic Society.

The Second Palomar Observatory Sky Survey (POSS-II) was made by the California Institute of Technology with funds from the National Science Foundation, the National Geographic Society, the Sloan Foundation, the Samuel Oschin Foundation, and the Eastman Kodak Corporation.

The Oschin Schmidt Telescope is operated by the California Institute of Technology and Palomar Observatory.

The UK Schmidt Telescope was operated by the Royal Observatory Edinburgh, with funding from the UK Science and Engineering Research Council (later the UK Particle Physics and Astronomy Research Council), until 1988 June, and thereafter by the Anglo-Australian Observatory. The blue plates of the southern Sky Atlas and its Equatorial Extension (together known as the SERC-J), as well as the Equatorial Red (ER), and the Second Epoch [red] Survey (SES) were all taken with the UK Schmidt.

All data are subject to the copyright given in the copyright summary. Copyright information specific to individual plates is provided in the downloaded FITS headers.

Supplemental funding for sky-survey work at the ST ScI is provided by the European Southern Observatory.

Scientists and educators conducting research, teaching, or other non-profit activities may use data from the copyrighted collections freely and without restriction, other than that users are requested to acknowledge the source of the data in any publications resulting from that use.

Commercial, for-profit use of the copyrighted collections is prohibited without written permission from the copyright holder(s). Contact archive@stsci.edu for details.

BGP Route Withdrawal

Leave a Reply

Today @Work, I withdrew a prefix from our AS, the video below is the prefix being withdrawn from the Internet as visualised by BGP Play which queries route collectors that send information to RIPE Stat.

I couldn’t help, but add a sneaky sound-clip to the end of the video, as the prefix disappeared from the route collectors, might make it more interesting for those who don’t have knowledge of how BGP allows the Internet to run.

Check here for information on using and interpreting the BGPlay widget.

All Sky Camera #7

2 Replies

I have finally changed the overlay on the all sky camera to match (somewhat) the orientation of the stars for when I place it. I guess this improves the educational value of the system.

There are a few improvements left to do, some of these will obviously depend on budget:

  • Waterproofing.
  • Better Camera.
  • Better Lens.
  • Permanent location.

https://coochey.net/allsky/

All Sky Camera #6

Leave a Reply

Well, we still have some issues with the Moonmode deactivation in the software. I’ve upgraded the firmware on the camera and am in discussions with the backend developers about where the bug might lie. It is possible that we may just disable the transition into and out of Moonmode to get over the bug.

Here is a timelapse from last night, unfortunately, the moon is in direct view for most of the night, so gain setting had to be set low to avoid over-exposure.

All Sky Camera #5

Leave a Reply

So – the new INDI AllSky backend is now up and running. Running outside in an ambient temperature of around 11 degrees C. The sensor appears to be stable at 19.2 degrees C. So hopefully the resistors will keep the dome above dew point.

I’ve managed to, at least, get the live image uploaded from the new backend to the coochey.net website, so you can still view the live view here.

We will see whether the videos / startrails & keograms upload properly, although I suspect that I will have to re-apply some of the sealant.

I will also have to re-do all the dark frames again, I may sort that out this evening.

All Sky Camera #4

Leave a Reply

So, I left it running overnight, and we hit some issues. Thankfully it was mostly dry, but there was a lot of dew.

I have now mounted 4 100 ohm resistors within the dome, and attached them, in parallel, to the 3.3V line on the Raspberry Pi. It should give me 0.43W of heat to the dome area. They’re connected to a breadboard, so I can easily disconnect one of the resistors if it gets too hot, or I can move to the 5V line on the Raspberry Pi for 1W of heat.

I’m unsure if there was just too much water, or if I was out of focus or something, or perhaps seeing overnight just wasn’t any good.

I’m also unsure about the handling of the ASI120MC-S camera by the allsky software. It could be that I need a better camera (this is the cheapest you can get really). So an upgrade to something like an ASI178MC or ASI178MM might be in order.

One thing I will be trying now, is to use my USB 500GB SSD drive, with a new install of Raspberry OS Buster (10), and try out the indi-allsky web package. It may allow me to change some settings that are not functioning ideally on the standard allsky package. Of course, this change will probably mean the Allsky camera website will not be updated in a while until I fix things to upload properly.

All Sky Camera #3

Leave a Reply

Equipment has been drip feeding to complete a build. I’m currently testing powering the Pi4 and the ZWO camera via a SkyWatch 17mAh PowerTank. I am hoping that this would allow me to run the All Sky camera for a whole night without needing mains power.

Items I have:

  • CCTV clear dome
  • Some Steel brackets
  • Various M3, M4, M6 Nuts and bolts
  • A 12V –> 5V 3A USB power converter
  • Various Cables
  • Pi4 4GB
  • ZWO ASI120MC-S
  • Cigarette Lighter 12V Power plug & cable

Items I’m waiting on:

  • PVC Junction Box (hopefully arriving today)
  • Power Connector Strips (collecting later)
  • Holesaw Kit for my drill (collecting later)
  • Cable Glands for sealing the power lead (arriving tomorrow)

Hope to get an initial build done over the weekend..

Some initial test show that:

  • Current ambient temperatures allow for enclosed operation without the need for any additional cooling.
  • The PowerTank can probably last 24 hours without needing a recharge.

Just one hole so far needed into the junction box. Hopefully the last one.

All Sky Camera #2

Leave a Reply

I have some issues, as we’re running inside the conservatory there are reflections whenever the inside lights are turned on. Also some graininess with the ASI120MC camera, so switching to mono Y8 mode for future acquisitions. I will also stop saving daytime images (live daytime view still available), but the daytime images are not useful for me for keogram / startrail or timelapse videos really.

Keogram, night time on the right hand side
Star Trails, note reflection of conservatory window, and graininess of the colour image.

All Sky Camera

Leave a Reply

I’m going to be tinkering with my old ASI120MC mini as an All Sky Camera, currently just have it indoors and looking out the conservatory.

We have some clear skies forecast for tomorrow night, so may see if I can mount it outside.

The sub-website for the All Sky Camera can be found here. It will take some tweaking to get everything functioning correctly. Very much still in testing at the moment.

I’m ordering a weather proof junction box, an acrylic clear dome and some miscellaneous parts to house the system so that it can be mounted outside to get a fuller view of the sky. I will probably be putting the camera in monochrome as well, as the pictures can be a bit grainy when in colour.

The software runs on the Raspberry Pi, and some methods to build a similar project can be found in and around here.

DX Express Service

Leave a Reply

I ordered some photo items from a supplier, and the supplier sent these via a courier “DX Express”, I had heard of DX, I think through having had some third party experience where they’re the preferred supplier for the couriering of legal documents etc…

Not been too impressed, still not received the goods, and their tracking information appears to show that the items have been traversing the local area for a couple of days, so not really making much of an attempt to deliver, but rather continue to risk damage rolling across the Devon hills.

Here is the latest on their tracking page:

Hopefully, third time lucky, otherwise we will rename DX (Delivered Exactly), to DXWWCBB (Delivered Exactly When We Can Be Bothered).

Update: They did finally manage to deliver on the 9th December.

M42 – Orion Nebula

Leave a Reply

Had a go at the orion nebula yesterday. First outing in a long time, just 30 x 5min exposures, with some Ha. Here is the first stab:

After a day or two, I decided to look again, and see what we can pull out of the data. Two and a half hours of capture roughly equates to about 1 Gigabyte, so there is a lot that can be done. Here is the final that I will settle with on this acquisition:

(11395) 1998 XN77 / HIP 12148 event on 2021 Dec 16, 21:18

Leave a Reply

It has been a while since posting anything. It has been unfortunate that the weather has just not been amenable to allow for any serious amount of viewing.

However, things may change, and the new moon approaches on the 4th December where I will have some spare time to take advantage if the clouds do clear.

I do, however, appear to be in a lucky location for an event that will happen on the 16th December. The 67.3km diameter asteroid, designated (11395) 1998 XN77, which orbits between Mars and Jupiter, will occult a visible star (magnitude 5.5) in the Cetus constellation (HIP 12148).

If the weather is dry and clear then I might be able to set up the telescope and camera to track HIP 12148 and take a video to see this “mini-star eclipse”.

The event at a glimpse

* date and approx. time of event: 2021 Dec 16, 21:10 - 2021 Dec 16, 21:29
* geocentric midpoint of event [JD]: 2459565.38883333
* magnitude of target star: 5.50
* magnitude drop [mag]: 11.76
* estimated maximum duration [s]: 7.210
* Moon: 95 % sunlit, 22° distance
* Sun: 134° distance