PCE-T 394 Thermometer Control (USB)

What this tool is

The PCE-T 394 is a four-channel K-type thermocouple thermometer with a built-in data logger. It ships with a Windows application called Smart Logger 2, which is the only software that knows how to talk to it. This page is a second option: it speaks the same protocol from a browser tab, with no installation, and it works on any desktop operating system a Chromium browser runs on.

The protocol below was recovered by capturing the USB traffic between Smart Logger 2 and a real instrument, and then verified against the hardware — serial 240302110375, through 2026. Nothing here is inferred from documentation, because there is no published documentation. Where a field is still unidentified, it says so rather than guessing.

How the device is reached from a browser

The meter is a USB CDC device — a Holtek USB-to-UART bridge presenting a virtual COM port at 0x04D9/0x8008. That makes it reachable through the Web Serial API, which lets a page open a serial port the user has explicitly picked from a browser dialog. The permission is granted per site and per device; the page cannot enumerate your ports, cannot open one you did not choose, and cannot reach anything else on the bus.

Because the bridge is a CDC device, the line settings barely matter — the tool opens at 115200 8N1 because that is what the vendor software uses, but the baud rate is not carried to the instrument in any meaningful way. What does matter is exclusivity: only one program can hold the port, so Smart Logger 2 must be closed before connecting here.

Framing

Every message in both directions has the same shape, delimited by ASCII braces and quotes:

7B 22 | cmd | len | data[len] | checksum | 22 7D

The start delimiter 7B 22 is the characters {"and the end delimiter 22 7D is "}. The checksum is the low byte of the arithmetic sum of the command byte, the length byte and every data byte.

That last point is the first trap in this protocol. The checksum is a sum, not an XOR — and the two coincide exactly when the payload is empty, which is precisely the case you will test first. Three of the four commands take no payload, so an XOR implementation appears to work perfectly right up to the moment you send the one command that erases the memory.

Because the length is a single byte, one frame carries at most 255 data bytes, so a memory transfer is split across many frames.

The four commands

The device never sends anything on its own. It does not stream readings, and it does not answer the 0x41 command used by the related CENTER 309 and Voltcraft K204 family. It responds to these four requests and nothing else.

Note that 0x4A breaks the otherwise consistent "reply = command + 2" pattern: it is answered by an ordinary status frame, not by a 0x4C. The reply's record count reads zero, which is how you confirm the erase actually happened.

The identification payload is eight ASCII characters of model identifier followed by six BCD bytes of serial number — LD812518followed by 24 03 02 11 03 75 for the unit this was developed against, whose serial matches the number printed on the case. It is worth asking for: the USB vendor and product ids belong to a generic bridge chip and say nothing about which instrument is on the other end.

Reading temperatures

There is no "read the current value" command. The device answers a request for its memory, and it answers it while a recording is in progress— which is what makes near-live monitoring possible at all. Ask for the memory once a second and the newest record is the current temperature.

The cost is that the entire memory comes back every time. There is no offset or range parameter, so the transfer grows with everything stored: about 0.3 seconds for 63 records, around a second once roughly two thousand have accumulated, at a fairly steady 20 kB/s. The device never clears itself, so old sessions keep piling up and every read gets slower. This is the real reason to erase before a long measurement, and it is why the live panel above adapts its polling period to about twice the measured read time rather than using a fixed rate.

One consequence is worth designing around. Between two polls you only know the last value you fetched, so anything logged in real time is a staircase with steps as long as the polling period. But each download contains the complete history with the device's own timestamps — so if you are logging alongside another instrument, take one final read when you finish and re-align your records against those timestamps. You then get the logger's full resolution instead of your polling rate.

How a measurement is encoded

The memory image is a flat array of eight-byte groups. A measurement record is four channels, each a big-endian signed 16-bit integer:

temperature (°C) = (raw − 5000) / 10

So the group 14 ED 14 86 14 82 00 00 decodes as 35.7 °C, 25.4 °C, 25.0 °C, and then a channel reading exactly −500.0 °C. That last value is not a temperature: a raw zero is the sentinel for a probe that is not plugged in, and anything at or below −500 °C should be dropped rather than charted.

Blocks, timestamps and padding

Records carry no timestamp of their own. Time comes from block markers — groups whose first byte is 0xFE, 0xFD or0xFC, carrying a 32-bit big-endian Unix timestamp in bytes 1 to 4. The time of record n inside a block is:

timestamp = block start + n × logging interval

Markers usually arrive in pairs carrying the same timestamp, so a new block begins only when that timestamp actually changes — treat a pair as one marker or you will split every block in two. None of0xFC–0xFE can be the high byte of a real reading (they would mean about −580 °C), so testing the first byte is a safe way to spot a marker.

Blocks appear repeatedly through the memory: the device closes one and opens another periodically, not only when the user presses REC. Consecutive blocks are contiguous in time, so for a continuous history you can simply concatenate them.

The group FF FF FF FF FF FF FF FF is unused memory. Here is the second serious trap: padding appears between blocks, not only after the last record. Stopping at the first one decodes only the first block, and the symptom is insidious — you get plausible data, but always the oldest records, so the reading looks frozen while the instrument is working perfectly. Skip padding and keep going.

Page headers, the nastiest trap

The memory is organised in 256-byte pages, and the first group of a page is sometimes a header rather than a record. Headers look like14 00 10 80 00 00 00 00 — where channel 1 decodes as 12.0 °C, which is an entirely believable room temperature. Range checks will not catch that.

They are told apart by continuity. Measured over a three-and-a-half-hour recording, genuine records at a page start differed from the previous sample by at most 0.2 K across 353 cases, while the 26 page headers differed by 102 to 124 K. A 20 K threshold separates the two populations with a factor of 500 to spare.

The tempting shortcut — skip every group at a page boundary — is wrong: in that same recording 353 of 379 page starts were real records, so a blanket rule throws away most of your data. If you skip the continuity test instead, the symptom is isolated readings of −77 °C or 1138 °C scattered through a long log. The groups rejected figure in the download panel above is this test doing its work.

Configuring the recorder, and the alarm encoding

The setup command is a 29-byte payload which is, in essence, the status payload with two timestamps written into it. The safe way to build it is to read the status immediately beforehand and echo everything you are not deliberately changing — that way the device keeps its logging interval and the handful of fields nobody has identified yet.

The status payload carries the same fields at the same offsets, so reading the status tells you the point limit, interval, start mode and alarm thresholds the device is currently holding.

And now the third trap. Alarm thresholds do not use the record encoding. Records put their zero at −500 °C; alarms put theirs at −50 °C:

alarm raw = °C × 10 + 500    °C = (raw − 500) / 10

This was verified against four values across two captures: 10 °C encodes as 600, 100 °C as 1500, 23 °C as 730, and 234 °C as 2840. Reusing the record offset would put every threshold 450 °C off — in a field the device never reads back to you at runtime, so nothing would ever tell you.

One field is conspicuously absent: the instrument name. Renaming the device in the vendor wizard changes nothing in the frame but the two timestamps, and the string appears nowhere in the USB traffic in ASCII or UTF-16. The name lives in Smart Logger 2, labelling its files. The device does not know it.

Start modes, and the fifteen-second lag

The start mode byte decides whether the device records after the erase, and getting it wrong is the difference between an instrument that keeps measuring and one sitting idle until somebody walks over to it. The device stores the mode and echoes it back in the status payload, so a program that never sets one inherits whatever the last setup left behind.

When you do start it immediately, expect the counter to lag. Measured after an immediate-start setup, the record count stayed at zero for 15.6 seconds and then advanced one per second exactly as configured. Do not read that first quiet stretch as a failure to start — wait at least thirty seconds before concluding anything is wrong.

Failure modes worth handling

Two of them will bite anyone who runs this for hours rather than minutes.

The device re-enumerates. Over a long session it drops off the USB bus and comes back, often on a different port — observed after about eighty minutes of once-a-second polling. Every write to the old handle then fails and the handle never recovers, so the only correct response is to close it and find the device again by its USB identity. This page reports it and asks you to reconnect.

Never repeat the last value when a read fails. It writes a plausible-looking constant temperature into your log, and any alarm you have set silently compares against a frozen number. Report the value as unknown instead, after a short grace period so a single hiccup does not blank the display. The live panel above blanks a stale channel for exactly this reason.

Two more are easy to mistake for faults. A transfer that is short by tens of percent was truncated, and because memory is sent oldest-first, truncation costs you exactly the newest records — compare the decoded total against the status count, allowing a small shortfall because the counter runs slightly ahead of what has been committed. And the memory only fills while the recorder is armed, so if the count never grows, the first thing to check is whether the device is recording at all.

Related pages

If you are working with the sensors rather than the instrument, thethermocouple calculator converts between temperature and EMF for type K and the other base-metal types and shows the cold-junction step explicitly. For the front-end electronics, see the sensor conditioningpage, and for the alternative sensor technology thePT100 and PT1000 calculator.