DEV Community: Erol

Reverse engineering the Agilent ChemStation .ch and .uv file formats

Erol — Fri, 28 Aug 2026 13:18:24 +0000

Agilent ChemStation writes chromatography data into a .D directory of binary files. The vendor has never published the layout. Nothing in the files is encrypted and there is no licence check anywhere in the format, so they can be read offline, but you have to work the layout out first.

What follows is what is in them, from writing a reader and checking it against real files from six instruments.

File structure

A .D is a directory, not a file. The signal data is in files inside it:

.ch: one detector channel over time. A single column of numbers.
.uv: diode array data. A full spectrum at every time point.

Both start with a number identifying the layout. Read it first and branch on it. Do not branch on the extension, since the same extension covers layouts with almost nothing in common.

Type	Ext	Header	Body
30	`.ch`	`0x400`, one byte per char	deltas, big endian
130	`.ch`	`0x1800`, UTF-16	deltas, big endian
179	`.ch`	`0x1800`, UTF-16	float64, little endian
31	`.uv`	`0x200`, one byte per char	deltas, little endian
131	`.uv`	`0x1000`, UTF-16	deltas, or float64. Both occur.

An unrecognised type should be rejected by number, not routed to the nearest matching path. A wrong chromatogram looks plausible on inspection and will get used.

Delta encoding

Types 30, 130, 31 and 131 store changes rather than values. Each segment begins with a count, followed by that many signed 16-bit values, each added to a running total. A value of -0x8000 is an escape: the next four bytes are a new absolute total.

let acc = 0;
for (let i = 0; i < count; i++) {
  const d = view.getInt16(p, false); // big endian for .ch
  p += 2;
  if (d === -0x8000) {
    acc = view.getInt32(p, false);   // escape: new absolute total
    p += 4;
  } else {
    acc += d;
  }
  out.push(acc * scale);
}

Cost is 16 bits per point, and 32 only where the signal jumps. The file above uses the escape 22 times across 2,100 points.

Byte order

.ch stores these values big endian. .uv stores them little endian.

The wrong byte order does not throw. The segment walk loses alignment, reaches a byte pair that reads as the escape, and terminates:

The result is hard to distinguish from a run where acquisition stopped early.

Undocumented offsets

Four values are not in any published description. The rainbow project published the notes this work started from, and two of its values do not match files in the wild.

The .uv scaling factor is at 0xC0D, not 0x127C. The .uv header ends at 0x1000, so the documented address falls inside the data body:

This one can be ruled out without a sample file. The correct value sits at 0xC0D, immediately before the units string that the same document places correctly at 0xC15.

Legacy string layout. Types 30 and 31 are not a truncated modern header. Strings sit at unrelated offsets and use one byte per character: acquisition date at 0xB2, units at 0x244.

Legacy scaling factors. 0x284 for .ch type 30, 0x13E for .uv type 31.

OpenLab .uv segments. Label 70 with a plain little endian float64 body, rather than the documented label 67 with a delta encoded body. Both occur and both have to be handled.

Verification

A parser cannot be tested against the author's own reading of the format, since that reading is what is under test. The check has to be external.

Every decoded value is compared against rainbow's output across 11 files from six instruments, covering every supported type: 1,487,470 values. All match, at a maximum difference of zero rather than inside a tolerance.

A second test re-derives each reported offset independently, so a claim about where a field lives holds up without sharing a constant with the parser. Together these catch the usual failure in this kind of work, which is an offset that is correct only for the sample set in hand.

Known gaps

Type 181 is implemented from the layout it shares with 179 and has never been checked against a real file, because no public sample exists.

.ch retention times are reconstructed, not read. The header carries a first time, a last time and a point count, and times are an even ramp between them, which is all the format provides. A non-uniform sample rate would be reported wrongly by any reader. Every file examined so far is uniform.

.uv carries a timestamp per time point, so those are read rather than inferred.

How I Sync Real-Time Multiplayer Game State with Socket.io and Node.js

Erol — Wed, 01 Apr 2026 13:46:23 +0000

I built a multiplayer board game that runs in the browser. Keeping everyone's screen in sync was the hardest part by far.

Here's how I did it in TileLord.

Server owns everything

Never trust the client. The client sends what the player wants to do. The server checks if it's valid, updates the game, and tells everyone what happened.

// Client
socket.emit("placeTile", { x: 3, y: -1, rotation: 2 });

// Server
socket.on("placeTile", (data) => {
  const result = game.tryPlaceTile(player, data);
  if (result.valid) {
    io.to(roomId).emit("tilePlaced", result.state);
  } else {
    socket.emit("actionRejected", { reason: result.error });
  }
});

Even for a chill board game, people will try to mess with the payloads.

One room per game

Each game gets its own Socket.io room. Players join when they enter, and updates only go to that room.

socket.join(`game:${roomId}`);
io.to(`game:${roomId}`).emit("gameStateUpdate", sanitizedState);

Don't send everything though. If your game has hidden info (like a tile deck), strip that out before sending. Each player should only see what they're allowed to see.

Log every action

I store every move as an event instead of just keeping the current state:

actionLog.push({
  type: "TILE_PLACED",
  playerId,
  position: { x, y },
  rotation,
  timestamp: Date.now(),
});

You get a lot from this:

Replays - play the log forward
Reconnects - rebuild what a player missed while offline
Debugging - replay the exact sequence that caused a bug

The replay feature took about a day to build and players use it all the time. Worth it.

Disconnects are normal

People lose wifi. Their phone locks. Their laptop sleeps. Handle this from day one.

Turn timeouts: if someone doesn't move in time, a bot takes their turn so the game keeps going.

const turnTimer = setTimeout(() => {
  botPlayer.takeTurn(game);
  io.to(roomId).emit("botMove", game.getState());
}, TURN_TIMEOUT_MS);

Reconnects: when they come back, send them the current state.

socket.on("rejoinGame", ({ roomId, playerId }) => {
  const room = rooms.get(roomId);
  if (room) {
    socket.join(`game:${roomId}`);
    socket.emit("fullState", room.game.getStateForPlayer(playerId));
  }
});

Spectators are free

Once you have rooms, spectators just join without being able to send game actions. They get the same updates as players.

TL/DR

Server decides everything. Clients just ask.
Socket.io rooms, one per game.
Log every action. Replays and debugging come for free.
Handle disconnects early. They will happen constantly.

Get the sync layer right first. The rest falls into place after that.

I'm building TileLord at tilelord.com, a free Carcassonne alternative you can play with friends or bots online.

Why Letting Piscina Spin Up Workers Dynamically Broke My Game Server

Erol — Sun, 08 Feb 2026 08:07:30 +0000

First, the background: I'm running a Carcassonne alternative web game called TileLord. It also supports singleplayer mode, so you play against bots.

Bots are CPU-heavy, as they calculate heuristics for each possible move the bot could make, so an obvious way is to use threads on the server side, otherwise, your whole server will "lag" each time a bot is calculating a move (which happened when I first launched the game).

Worker threads and Piscina

As mentioned, it was obvious to add threads, and chatgpt suggested that I use Piscina. On Github, this is their repo description:

A fast, efficient Node.js Worker Thread Pool implementation

So it makes total sense to use it. Gpt suggested using this configuration, based on the VPS I was running my server on (8 cores):

const minThreads = 2;
const maxThreads = 6;

I rebooted the server, and.. the lag was gone! It worked perfectly. Until... my game got more users, and bots started getting slow-ish again. 3 seconds for a bot move instead of 1.5s.

I ran htop on my server, and saw random spikes of 800% cpu utilization (all 8 cores at 100%) for a few seconds, then back to 0%.

Which doesn't make any sense. There should be max 6 worker threads, and nothing else should consume much cpu, right?

Wrong! Spawning a worker in very heavy in Nodejs, as it needs to:

Create a new v8 isolate
Parse + execute your worker's js bundle
Run module initialization (require/import)
JIT-compile hot code paths
Maybe it triggers garbage collector activity

And these operations are parallelized internally, so when Piscina is spawning a new worker it can hit all cpu cores at once, causing the whole server to lag for a second or two.

After hard-coding both min/max threads to 6 (so the other 2 cpu cores are available to the server), my cpu consumption didn't go above 200% (I added the fix 4.2):

Lesson learned

Worker creation can be far more expensive than actual worker execution (bot move compute, which atm is 50-500ms). In such case, it might make sense to pre-allocate threads:)

Sometimes the bug isn’t in your algorithm, it’s in how your workers come into existence.

I also wrote about how How I Built a Free Online Carcassonne Game Alt You Can Play in the Browser

How I Built a Free Online Carcassonne Game Alt You Can Play in the Browser

Erol — Thu, 09 Oct 2025 10:44:41 +0000

I’ve always liked the board game Carcassonne — simple mechanics, but surprisingly deep strategy.
A while back I started tinkering with the idea of building something similar that could be played easily in a browser with friends. That side project eventually turned into TileLord — a small web game where you can play Carcassonne online free with bots or friends, no installs needed.

Why I wanted to build it

There aren't many online versions, it's either old Desktop apps or pay-up-front official apps. So I started building an open, Carcassonne game alternative that follows the same core rules

It’s not the official game (and isn’t affiliated with it), but it scratches the same strategic itch.

Under the hood

Frontend: React + PixiJS for tile rendering and UI
Backend: Node.js + Socket.io for multiplayer state sync
Hosting: Cloudflare, curretnly still on free tier:)

Hard things

Extending game engine

The base rules are simple, but once you start adding expansions (like Inns & Cathedrals, River, Abbots, Farmers, etc.), the logic tree gets messy.

Each feature can affect multiple parts of the scoring or tile-placement rules. I ended up refactoring the entire engine 3 times to add abstraction layers one on top of each other (eg. multi-tile buildings instead of per-tile features).

AI Bot heuristics

Deciding where to place a tile, and where to place a follower, isn't as simple as eg. tic-tac-toe solver. You have to account for how many followers you still have, how many open edges of a building, defensibility of your buildings, trying to merge (attack) with other larger buildings, trying to "trap" enemies so they can't complete their cities, calculate what's the chance required tile will be drawn, etc. Many rules/weights that need to be tuned, and additional complexity arises when you add expansions into the base game.

Bot optimizations

At first it just brute-forced every legal move, deep-copying the full board to estimate the diff in value (which can be score, trapped follower, etc) for each move. But after >50 placed tiles, such algo takes quite some time, up to a point where you are waiting 20+ seconds for a bot move.

By adding just a state diff and rollbacks (placing/removing followers or tiles), bots required an order of magnitude less compute time.

Current state & whats next

Right now, TileLord supports all the base rules plus several expansions. Multiplayer, Replay mode, AI bots, and mobile browser play are all working.

I plan to add additional expansions (major and mini ones), beginner tutorials, game/turn analysis, better difficulty tuning for AI, and more!

PS. We're hiring!

Looking for Senior Fullstack Developer

Erol — Fri, 26 Sep 2025 10:04:07 +0000

About Us
At TileLord we’re building a free, web-based alternative to Carcassonne. We’re a small startup with a fast-paced culture and ambitious goals.

Role
We’re looking for a Senior Fullstack Developer (remote, CET timezone) with 5+ years of experience. You’ll work across frontend, backend, and database, with a big focus on PIXI.js for gameplay. Game dev experience is a plus.

Requirements
• 5+ years fullstack experience
• Strong FE/BE/DB skills
• Proficiency in TypeScript
• PIXI.js or similar rendering/game framework experience
• Remote-friendly, CET working hours

Why Join
• Startup culture with real ownership
• Fully remote
• Competitive pay + possible equity
• Build something fun and free for the gaming community

Apply
Send your CV + GitHub link to erol@tilelord.com.