HTQ10A, ST13-J and R530C: Diagnosing a Build That Has No Twin

Standard field service leans on something a custom order quietly takes away. When a catalogue unit fails, whoever diagnoses it has two props: a population of identical machines that has already shown which parts go first, and a replacement that came off the same line. A build made to one customer's own specification has neither. There may be thirty of them in the world, or nine, or a single evaluation unit. The failure population is too small to rank anything, and the part that gave out is not sitting on a shelf waiting to be fitted. What remains is the unit in front of you and whatever was written down when it was configured.

Three units cover the range where this shows up. HTQ10A is a ten-inch Android tablet whose changes usually land in the system image and the optional module set. ST13-J is a 13.3-inch Windows tablet where the customer's mark goes onto the casing and into the software stack. R530C is a six-inch industrial terminal whose custom layer sits in the Android build, the preloaded applications and the regional radio settings. Each one ages differently, yet all three have to be diagnosed without a reference machine standing next to them.

✅ Why the Standard Fault List Does Not Apply

A fault list works because it is a ranking. Somebody counted a thousand failures across a thousand identical machines and wrote the order down: connector first, then the pack, then the panel. That ranking is a statistical object, and it needs a population to exist. Cut the population to a single order and the ranking collapses into anecdotes. The connector that failed on the third unit tells you nothing about the fourth, unless you also know that the third unit shared its cable routing with the fourth. Numbers stop being evidence and start being a story about one machine. Diagnosis has to fall back on something else: what this particular build was asked to be.

The Change Record Is the First Thing You Read

On a catalogue product, the first document an engineer opens is the known-issues list. On a custom order, the first document is the change record, and it functions as a suspect list rather than a history. Everything the customer altered is a place where the unit differs from anything seen before, and each is a candidate cause until cleared. The order matters. Radio settings are cleared in minutes with a test card. A preinstalled application is cleared by rolling the image back. A change to the casing is cleared only by opening the unit. Reading the record top to bottom is how the cheap eliminations get done before the expensive ones start, and it is the sequence the customisation programme is built to document.

Firmware With No Public Build to Compare Against

The HTQ10A is the clearest case of the problem, because its custom layer is invisible from the outside. The casing is the same one every buyer receives; the difference is the image inside it and the modules fitted at build. When a behaviour appears that nobody planned, there is no public release to hold the unit against. The only comparison available sits on the same order: a second unit from the same batch, running the same image. If the behaviour repeats there, it belongs to the image. If it does not, it belongs to the module set or to the individual unit. That test costs almost nothing, and it is the only controlled comparison a custom order ever gets.

Interfaces Someone Else Chose

The ST13-J carries a full set of ports on a 13.3-inch chassis, and the ports are the part of the specification most often rewritten by the buyer. A production line that needs a serial link where the standard unit carries a video output is not buying a defect; it is buying a different machine. The failure mode that follows is awkward precisely because it is not a fault. Nothing has broken and nothing is out of tolerance, yet the unit will not do the job it was ordered for. Cases like this are cleared by comparing the as-shipped configuration against the requirement, not by opening the case, and they are the reason the requirement sheet belongs in the service file.

Thermal Behaviour That Was Never Measured Twice

A R530C leaves the factory with a tested thermal profile, but that profile describes the standard configuration. The buyer then adds a radio module, two preloaded applications and a different power policy, and none of those additions were present when the profile was recorded. Heat is the result of everything running at once, so a build that runs more at once runs warmer than the figure on file. The practical reading is that the operating window quoted for a custom unit is a starting point rather than a promise. Where a deployment sits near the warm end of the range, the useful measurement is taken on site, on the actual configuration.

The last column matters most here, and it shows why the table cannot be read like a catalogue comparison. Two of the three quote an IP rating on their product pages and the third does not, so the protection class is left out rather than filled with a guess. Operating temperature is published for all three, and the three windows are not the same width: the ten-inch tablet is rated from minus twenty to sixty, the large tablet from minus twenty to fifty-five, and the handheld from minus ten to fifty. The narrowest window belongs to the smallest unit, which is also the one most likely to be carried in a pocket rather than mounted on a bracket.

When Nothing Came Off the Same Line

A catalogue unit is repaired by substitution. Pull the suspect part, fit an exchange unit, send the original away, and the machine is back on the floor the same afternoon. A custom build breaks that rhythm at the first step, because there is nothing on a shelf that matches. The substitution may not be electrically identical, may not carry the same firmware revision, and may not be permitted at all if the unit sits inside a certification boundary. The first question therefore changes. It is no longer which part to swap, but whether this fault can be cleared without removing anything. Answering that question needs only the change record and a spare hour, and it saves a return trip that would otherwise take weeks.

What Can Be Put Right Where the Unit Stands

Most of what goes wrong on a configured unit is in the configuration, and configuration can be corrected wherever the unit happens to be. Radio settings, application versions, power policies and sensor calibration are all reachable without opening anything, provided the engineer arrives with the right build to restore. The list of what cannot be corrected locally is much shorter and worth writing down: anything inside the sealed assembly, anything that needs a calibration rig, and anything where the fault lives in a part that was specified by the buyer and cannot be substituted. Sorting a call into one of those two groups before travelling is the single largest saving available in custom service work, and it takes a phone call rather than a visit.

What Belongs in the Service File From Day One

Everything described above depends on one decision made at the start of the order rather than at the first breakdown. A custom build should ship with a service file that carries the configuration it left the line with: the image revision, the module list, the radio settings, the preinstalled applications and the date each of them was applied. That file is the reference machine the unit does not have. It costs a few minutes at build time and it converts every later diagnosis from an argument about what the unit was supposed to be into a comparison against what it actually was. Orders that skip it do not save that time; they spend it later, at the worst possible moment.

Customisation is not going away, and neither is the absence of a twin unit to compare against. What can be built, deliberately, is a substitute for that twin: a written record of the configuration, kept with the unit and read before anything is opened. Handled that way, the same three devices answer a service call the way a catalogue product would — the difference is that the reference has to be created rather than looked up. The same reasoning runs through the comparison notes, where units are read against the duty they were ordered for rather than against a generic specification.