Internal training material. Sign in with your SymX address and the access code you were given.
Access is limited to symx.ai addresses. This material references internal systems, customer fleets and licensed third party data, and it is not to be forwarded outside SymX.
Onboarding and training manual. The whole embedded estate, the knowledge held by the engineers who built it, and how every layer of it powers X.Fleet, X.Dispatch, X.Machines, X.Tires, X.Parts, X.EAM and X.Connect.
| Who this is for | An engineer taking ownership of part or all of the SymX embedded estate: firmware, board support, radio, connectivity or the in cab tablet. |
| Assumed knowledge | Embedded Linux, C and Java, and the command line. No prior knowledge of CAN, J1939, Yocto on this platform, or the SymX product line is assumed. |
| Time | About six hours to read, plus the companion body of knowledge on SocketCAN and J1939, which is another four. |
| Completion bar | Seven of the nine knowledge checks correct, plus the bench exercise in section 14.4. |
| Access to request on day one | Jira projects FW, TAB, HD, FS and OO4. Confluence spaces hardware and TECH, and read access to the two personal spaces noted in section 13. The symboticware GitHub organisation. Cloud console read access for the device messaging account. A briefing on the licensed SAE signal annex handling rules. |
| Companion | SocketCAN and J1939 at SymX, a body of knowledge. Read section 4 of this manual first, then that document in full, then return here at section 5. |
SymX has built a large embedded estate over several years, and most of what is known about it lives in the heads of the engineers who built each part, spread across roughly forty Confluence pages, several hundred Jira issues and six repositories. This manual is the consolidation. It carries the platform, the protocols, the field reality, the traps that have already cost the company time, and the working practices that keep the estate honest.
It is written to be learned from. Read it in order the first time. The knowledge checks are placed where a misunderstanding would be expensive, so answer them before reading on. The bar at the bottom tracks progress.
Every layer ends with the same question answered explicitly: which product does this power, and what breaks commercially if it is wrong. That thread is the point of the manual.
Read Confluence in date order. The corpus contains several explicit self corrections where a conclusion was investigated, published, then overturned. The clearest examples: a CPU profiling conclusion that was later withdrawn, a cloud topic scheme that was superseded, a tyre sensor checksum declared non existent and later cracked, and a positioning gap that turned out to be scoped differently. Reading out of order means absorbing a retracted conclusion as current, and at least one engineer has already lost days to it.
The second rule: the repositories are the record and the ticket tracker is a comment thread. Ticket status has been wrong in both directions. Nothing is done or not done without a pull request.
The SymX product surface covers eight named areas. Every one of them is fed by the same edge estate, and every embedded decision in this manual eventually shows up in one of them.
| Defect at the edge | What the customer sees |
|---|---|
| A clock that resets to 1970 | X.Dispatch cycle times are wrong. X.Machines utilisation is wrong. The device stops uploading entirely and reports no fault. |
| A clamped out of range reading | X.Machines shows a clean maximum for an unplugged sensor. X.EAM raises a work order against a component that is fine. |
| A radio frame accepted without checksum | X.Tires invents sensors that do not exist and reports pressures for tyres that are not there. |
| Product | What it does for the customer | What it needs from the edge, and what breaks without it |
|---|---|---|
| X.Fleet | Where every machine is, what it is doing, and for how long | Position and machine state on a trustworthy clock. A drifting clock makes every duration wrong and the error is invisible on the dashboard. |
| X.Dispatch | Assignment and routing of haulage, loading and support equipment | Position, payload, cycle state and low latency. A stale or duplicated assignment reaching a haul truck is an operational hazard, which is why duplicate suppression on the uplink matters. |
| X.Machines | Utilisation, availability, idling, payload, alarms and the notification centre | Faithful decode with quality flags. A clamped value is indistinguishable from a real reading, and models trained on it learn a fiction. |
| X.Tires | Pressure, temperature, slow and fast leak models, tyre life | Radio yield and frame integrity. A sensor identity corrupted by one bit becomes a phantom tyre, and a customer counts tyres they do not own. |
| X.EAM | Asset register, failure history, work orders, reliability analysis | Component identity and a component addressed fault. Without identity there is nothing to hang a failure on. See section 11. |
| X.Parts | Spares, onboarding of an asset fleet, parts against components | The same identity spine, plus serial numbers read from the machine rather than a clipboard. |
| X.Inspect | Digital inspections and the work order loop, delivered on the in cab tablet | A reliable operator interface that survives a power cycle, and a store and forward path that does not lose a completed inspection underground. Tracked in its own projects, INSPECT and XI. |
| X.Connect | The connectivity layer itself, sold as a capability | It is the edge. Mesh underground, LTE on surface, satellite on remote sites, and the routing logic that chooses. |
A device's clock resets to 1970 on every power cycle. Which products are affected?
| Element | Detail |
|---|---|
| Application processor | Qualcomm QCM2290 on a Quectel SC206E module, kernel msm 5.4 |
| Auxiliary controller | PIC18F47Q43 over UART at 230400 through a channel mux. Real and load bearing: Cat Data Link capture, hardware watchdog, SoC reset, power sequencing |
| Inertial sensing | LSM6DS3 family, accelerometer and gyroscope, both configured at 416 Hz with FIFO enabled |
| Sub GHz radio | Si446x on SPI, dual module, 433.92 MHz, every profile 2FSK |
| Vehicle bus | Two CAN interfaces through an MCP2517FD or MCP2518FD controller on SPI. The Linux driver is mcp251xfd. Note the spelling, the older form finds nothing. |
| Image | Yocto, layer meta-symbot, target image qti-robotics-med-image |
Several widely repeated facts about this platform were wrong and have been verified against the source. The inertial unit is not a 10 Hz accelerometer only part, it is 416 Hz with gyro. The tyre radio is not 868 MHz and no profile uses on off keying. The application processor is not an NXP i.MX, that was SymBot 5. Compression, batching and store and forward are already built and enabled. Machine learning is absent at the edge and present in the platform.
If you read an older document asserting any of those, it predates the correction.
The previous generation, on an i.MX8 application processor, still in significant field service. Several defects behave differently between generations, and at least one radio wedge appears to affect SymBot 6 and not SymBot 5, which is itself a diagnostic clue rather than a nuisance. Never assume a fix validated on one generation applies to the other, and never deploy a native library without confirming which generation it was built for. The pin map is the tell.
An Android tablet in the cab running three applications that talk to each other over signature level inter process communication, so all three must be signed with the same key.
| Application | Role |
|---|---|
| Manager | Device owner. Provisioning, kiosk mode, remote shell, reverse tunnel, health reporting. It cannot update itself in the field, which is the single most consequential constraint in the tablet programme. |
| EdgeService | The data plane. Uplink transport, store and forward, sensor capture, cloud messaging. |
| GUI | The operator interface. Dispatch plans, acknowledgements, inspections. |
Ports to know: the operator interface link runs on 5567, the legacy telemetry link from the SymBot on 5566, the device shell on 2222, and a reverse tunnel to a gateway host with a per device port derived from the device identifier.
Why does the Manager application constrain every tablet rollout plan?
| Repository | What it is | Feeds |
|---|---|---|
| pulse-daemon | The edge daemon. Bus decode, sensor capture, storage, compression, upload, diagnostics. Java, modular under opis/ | Every product |
| symlibs | Native C libraries and their JNI bindings. SocketCAN, si446x radio, inertial sensing, Bluetooth scanning | X.Tires, X.Machines, X.EAM |
| meta-symbot | The Yocto layer. What ships in the image, pinned to source revisions | The whole fleet |
| xtablet | The three Android applications | X.Dispatch, X.Inspect |
| SymBotSoftwareAcceptanceTest | Acceptance harness and capture fixtures | Quality of all of it |
| sight3-backend | The platform. Asset registry, fault service, sensor services, Athena queries | X.EAM, X.Machines |
This is the oldest and deepest domain in the company, and it splits three ways.
The modern standard, covered in depth in the companion body of knowledge. The short version for this manual: there are two code paths, a legacy userspace implementation that the fleet runs today and a kernel socket implementation that is being migrated to, and nearly every open defect belongs to the newer one because it has not yet run at scale.
Key reading: Symbot 6 J1939 stack, current state and integration gaps (3695673345, hardware), and the best worked decode example the company has, Kress Hauler, Glencore Smelter, J1939 CAN decode (3854860290, TECH). Epics FW-4046 and FW-4104.
Caterpillar's legacy bus, captured through the auxiliary controller. It carries no SPN, so every signal is identified by a tag name and a parsing function. The reference is CDL Tag Reference, parsing functions and range validation (3579445277, hardware): roughly 350 tags, 122 of them range protected, 148 explicitly marked do not parse.
CDL matters more than its age suggests. It is a large share of two of the most important customer fleets, and it is the reason the platform keyword taxonomy is permanent. Signal numbering never replaces the keyword layer, it augments the J1939 subset only. Anyone describing the taxonomy as becoming a lookup table is overselling it.
Supporting tooling lives in a personal Confluence space and should be known to exist: an ECU identifier translation table (3750428674) and a recording visualizer application (3743318022).
Worked examples matter more than theory here. The model for a well documented negative result is FW-5412, Sany SKT115S reverse gear and body tilt over CAN (3845455874, TECH), which records what was attempted, what was found, and what was concluded to be unavailable. Write investigations that way. A documented negative saves the next engineer a week.
Open work of this class includes a Komatsu fault code lookup of roughly 1,500 codes and a Caterpillar proprietary set of around 3,000 entries. Both are blocked behind a code size limit in the legacy agent described in the companion manual.
Everything the fleet runs arrives through a Yocto image and a package update. This domain decides whether a fix reaches a machine.
Two hand built binaries had drifted from their source. A configuration recipe shipped a radio profile built without a required compile flag and declared the same installation paths as the main package, so install order decided what the radio actually loaded. And a vendored shared library concealed a recipe defect: the build never activated the SymBot 6 profile, so compiling from source produced a library driving the wrong generation's GPIO pins entirely.
The remediation pins the source revision, deletes the vendored library, asserts the correct pins at compile time, and makes one package the sole owner of the configuration files. FW-4986.
There is a second half that is not yet closed. The native library emits radio configuration blobs into a directory that version control ignores, and a human copies them into the daemon with a case rename. One of those files has been touched once in fifteen months. Forgetting the copy yields a green build and a stale field configuration, with no signal that anything is wrong.
Reference: Symupdater algorithm and flow diagram (3846471691, hardware) and MQTT based device management, codebase assessment (3814391811, TECH).
There is an independent supervision layer whose job is to notice a device that has stopped behaving and recover it without a site visit. Read symbot-supervisor deployment and bench runbook (3702882306) and Reliability Control Plane MVP (3699900420). Both are TECH.
Related and worth knowing: a Java memory leak investigation process has been written up (3729850372) because it has been needed more than once, and a data reduction reference exists for the vehicle fleet where bandwidth is expensive (3889266691).
Two packages both declare the same configuration file path in the image. Why is that dangerous rather than merely untidy?
This domain looks like housekeeping and is not. It is currently one of the highest value problems in the estate.
On one device the daemon logged eight times that the clock must be wrong and disabled storage. Upload volume for that day fell to roughly 2 percent of normal and the published signal set collapsed from about 123 distinct tags to three. The device reported no fault. Its acknowledgement queue was empty and the daemon believed it was publishing everything.
That is the shape to remember: a silent, total data loss that looks like a healthy device.
A separate and related cluster where devices report dates in 2038, traced to satellite week rollover and stale assistance data. Two write ups carry it: RCA, 2038 clock flap on Caravan loaders, GPS week rollover and stale assistance data (3900145665) and Caravan 2038 and clock trust initiative handoff (3903160333). Both TECH.
Tickets across the family include FW-5554, FW-5511, FW-5549, FW-5542, FW-5409 and FW-5296.
One nuance already discovered and worth carrying: there are at least two distinct failure shapes. A device with no cellular time source drifting forward, and a device holding a stale past date across a cold boot. A guard written for the first case does not catch the second, and the second is the one that disabled storage.
Unlocking the hardware clock has a real downside that is stated in the analysis: it also lets a bad network supplied time value persist rather than be forgotten at power off. The counter is also shared with modem and trusted execution firmware. So the safe sequence is to fix synchronisation and add software persistence first, and treat the device tree change as bench gated.
The hardware clock refuses every write because of a device tree property. Why is adding that property not obviously the right first move?
Four sensor families reach the SymBot over a sub GHz radio: SST, TireCheck, DG and LDL. This domain is dense, it has produced the most instructive engineering in the company, and it feeds X.Tires directly.
The band is 433.92 MHz, and this needs a regional note. 433.92 MHz is a licence free industrial band in ITU Region 1, which covers Europe, Africa, the Middle East and Russia. It is not a general purpose licence free band in the United States or Canada, where tyre monitoring conventionally sits at 315 MHz and 433 MHz operation falls under restrictive duty cycle rules. SymX has North American deployments, so a radio change is a regulatory question as well as an engineering one. Confirm the regional position before any change to transmit behaviour or duty cycle.
There are two paths and only one is authoritative. A compile time fallback is baked into the native library from generated headers, and on the SymBot 6 build that fallback always resolves to a single sensor profile regardless of what the device actually ships with. The runtime path loads a binary configuration from a file at boot and caches it per module.
The consequence is specific and has been written down: falling back to the compile time configuration during a recovery would silently reprogram a chip onto the wrong sensor profile until the next daemon restart. Recovery paths must reuse the cached runtime configuration.
Reference: FW-5462, which also records a resolved question about crystal frequency, a still open mismatch between the declared part number in the generated headers and the part actually fitted, and an effective bus clock far below what the hardware allows.
One sensor family's two byte trailer was believed for a long time to be a decode artefact with no usable checksum, and a ticket was abandoned on that basis. It is a real CRC-16/CMS: polynomial 0x8005, initial value 0xFFFF, no input or output reflection, final xor 0x0000, computed over the frame body and stored big endian in the trailer. The reversal is documented in date order across three pages, which is exactly why the date order rule exists: bench findings that ruled CRC out (3823927297, superseded), the reversal (3845193748), then corruption measured and CRC cracked (3847782403).
Commercially: a phantom sensor is a tyre the customer does not own, appearing in X.Tires with a pressure and a temperature. There is no way to explain that to a tyre engineer other than admitting the data was never validated.
A three tier self heal ladder exists for a radio module that stops delivering. A third wedge mode defeats it: synchronisation counts climb steadily while the receive counter stays frozen, so an aggregate liveness check never fires and the first tier re-arms nearly two hundred times to no effect.
The middle tier recovers by sleeping and reinitialising, which skips the reset and power up sequence, and with it the image rejection, oscillator and loop calibrations that only happen at power up. The result is that strong neighbouring machines decode while the vehicle's own marginal tyres do not, the receive counter reads healthy, and the watchdog stands down.
Confirmed on a five tyre set: a daemon restart recovered two of five, a full power cycle recovered all five, with tyres reappearing between ten and thirty two minutes later. A customer can be told their tyre monitoring is working while the tyres on that machine are invisible.
Two hard won operational rules from the same investigation. Verify any native radio library with strings before deploying it, because a library cross built without the generation flag drives an invalid pin map. And do not use a machine with a failing battery as a validation target.
The most recent sensor family was brought up to roughly 100 percent capture over an eighteen hour run. The root cause of the earlier failure was sync word bit order: the radio holds each sync byte reversed relative to the air, so receiving one pattern requires writing a different one. Earlier attempts wrote the on air pattern verbatim and the packet handler never locked.
Two decoder fixes in the same work are the template for any future protocol. Unknown line code cells were being forced to zero, discarding 38 percent of all frames, and are now resolved by testing candidates against the frame checksum. Noise satisfying an eight bit checksum by chance fabricated a sensor roughly once in 610 frames, and is now gated on the line code, because a genuine burst carries at most one illegal cell while a noise lock carries about fifty.
Be precise about which mechanism is doing the work. An eight bit checksum has roughly a one in 256 false accept rate per candidate tested, so resolving several unknown cells by brute force against it is weak on its own, and the false accept probability climbs with the number of candidates. The line code gate is the real defence. Observing zero failures over a nine hour run is consistent with either outcome at that rate, so report the frame count rather than the duration when making this claim.
Reference: LDL WUS TPMS, Si4463 receiver bring up and validation (3909648387, hardware) and FW-5024. Merge order for that work is stated and mandatory: the native library first, then the daemon, because the model has nothing to call without its native entry point.
A machine's receive counter is healthy and the watchdog is quiet, and the tyres on that machine are still missing. What is the most likely explanation?
X.Connect is a product in its own right, and it is also the thing that decides whether any other product has data.
The modem has its own long running reliability story: interface inconsistency, stuck states requiring a watchdog, reboot loops caused by that watchdog, and provisioning specifics per carrier. Start with Current issues with the LTE interface and roadmap to mitigate them (3811835906, hardware) and the worked root cause at E401304 LTE data call failure with a floLIVE SIM (3788210177, TECH).
Underground there is no cellular and no satellite positioning, so a mesh is the only backhaul and it is a first class product concern. Roadmap: X.Mesh consolidated roadmap, from V1 pilot to shippable managed service (3737976840, hardware). Recent hardware evaluation work includes a Wallystech DR5018S evaluation (3887759362) and practical procedure notes such as Wi-Fi configuration using wpa_cli with example commands (3896705027).
Deeper mesh engineering on record includes asymmetry aware routing patches, persistent logging on the router platform, serial recovery procedures, and a trip count against signal strength analysis from an underground grizzly. Note that part of the mesh roadmap was closed in August, so check dates before treating a mesh page as live.
A device hotspot is used for provisioning and field work, and there is an open thread about making it persistent across reboot and shipping it as a deployable service with internet sharing on by default. FW-5491, FW-5509, FW-5510.
Where there is no backhaul at all, data is carried physically between devices. There is a design and a two device bench validation on record. See Data muling project (2860384431, TECH) and tickets FW-5301 through FW-5305.
Today every byte between the tablet and the cloud travels through the SymBot, which holds the cellular connection. When that link drops the tablet goes dark and recovery needs a physical reboot on a machine that may be underground. The programme gives the tablet its own uplink, and in doing so turns the SymBot into a bus and radio peripheral.
This is not only an engineering change. Once the tablet holds the connection, the position source and a direct cloud session, the bill of materials, the pricing, the install labour and what the sales team sells all change. It is a product line pivot and it deserves to be named as one.
Read in this order: XTablet architecture proposal, shared Manager and EdgeService, config driven per product (3855417345), then XTablet Solution Release 2.0.0 plan (3864854531), then XTablet fleet platform handoff, components and dataflow (3871375362), then XTablet provisioning runbook, certificates and gateway keys (3875405826), then Version 2 field deployment guide for technicians (3896868870).
Three of those pages live in a personal Confluence space, so browsing the team spaces will not surface them. That is a real onboarding hazard and those pages belong in hardware or TECH.
Two branches ship incompatible cloud uplinks.
The decision taken is to keep the mainline branch as trunk and port the field integration client onto it, then retire the field integration branch. The enabler is that the field client already implements every method of the transport interface, so it is renames instead of a rewrite.
Sequence and reference: FW-5531, FW-5532, FW-5533, FW-5534. An open external dependency sits on top of it: the cloud account referenced in code differs from the one used on the bench, and that has to be answered before anything ships.
The architectural inversion, where the tablet holds an access point and the SymBot pushes to it. Design: Tablet-FMS reverse role SymBot link (3893231618, TECH).
The blocker is a permission, not the hardware. Concurrency of station and access point is advertised and proven on the device. The only hotspot entry point an ordinary or device owner application can call fails on the vendor build while a station is connected, and the concurrency aware path requires a privileged permission no device owner application holds. Underground there is no cellular and no satellite positioning, so this is mandatory there. FW-5506.
The store and forward drain replays an entire pending backlog in a tight loop with no backpressure. On the bench that produced an in flight publish count above 32,000, a load average around 14, memory at 92 percent, a flapping connection, and a backlog that barely moved across a whole session. It is present in the shipped field build, and it defeats the stated acceptance bar of zero loss ordered backfill after an outage. FW-5535.
Related and instructive: an identity gotcha where the platform identifier is derived per signing key, so a policy scoped to the value read from a shell differs from the value the application actually presents, and the connection is refused with a bare transport error and no useful diagnostic.
The tablet cannot hold an access point for the SymBot while staying on the mine network. What kind of problem is this?
Underground, satellite positioning does not exist. Position comes from proximity to known beacons, resolved into zones. This feeds X.Fleet and X.Dispatch directly, because an assignment needs to know where a machine is.
Reading: Reverse tracking, technical implementation and zone detection algorithm (3579445250), BLE zone resolution, signal strength winner margin findings (3841687566), SymBot 5 BLE reverse tracking field health check (3845423106) and the programme handover (3877470210). All hardware.
Active threads include zone configuration and beacon to zone mapping, and consumption of zone identifiers on the tablet side. FW-5548, TAB-382.
This is where the edge estate turns into the most defensible thing SymX sells. The companion body of knowledge carries the full primer. What follows is the part an embedded engineer has to hold.
A mine builds its equipment register by hand and it is wrong within a month. Maximo assumes the register exists. Hexagon EAM sells a project to build one. RPMGlobal AMT models cost on top of one. None of them generates it. SymX can, from machine data, and can also detect when a component is physically replaced.
The detection mechanism is the part that depends on firmware. A machine broadcasts component identity on the bus. When a serial number changes, the old component row is closed and a new one opened, producing a dated replacement event. A swap must never update a row in place, because that erases the fact of replacement, which is the most valuable record in the register.
| Requirement | What it needs from firmware | State today |
|---|---|---|
| Manufacturer, model, serial and software per maintainable item | Component identification and software identification messages requested after address claim, published on change | Gap Identity reaches 7 devices of 291, 2.4 percent. The register cannot be sold at that number. |
| A failure record addressed to a component | Signal and failure mode numbers carried to cloud as integers rather than buried in a display string | In flight |
| Data quality | Quality flags instead of clamping, raw value preserved | In flight Every anomaly model so far has trained partly on manufactured maxima. |
| Completeness | A per message type drop counter published hourly | No work Today the coverage claim is a screenshot. It should be a metric with a histogram, which turns the next licensing decision into arithmetic. |
| Timeline | Operating hours carried with faults. It is the denominator of every reliability rate | In flight A non monotonic hour meter is an event, never a value to smooth. |
| Component replacement | Serial change raises an event, old row closed, new row opened | In flight |
| Safety critical failures | Lamp state decoded on device, faults sent on change | Gap Severity comes from lamps and never from the failure mode number. |
Read as firmware, these are small additive changes. Read as product, they are the difference between a telemetry feed and an asset management platform. The identity work in particular is commercial work wearing a firmware ticket number.
Failure mode is what the item failed to do. Failure mechanism is the physical process. Failure cause is why it happened. Maximo, SAP PM and Hexagon EAM all want all three. None of them wants a signal number. The bus can seed mode and detection method. Mechanism and cause require a work order close out by a person. Say that plainly. Implying otherwise gets the register taken apart by a reliability engineer.
And the language rule: structured to ISO 14224, never certified, because no certification scheme exists. Mobile mining equipment is also not an ISO 14224 equipment class, so SymX applies the method and not the equipment coverage.
A component's serial number changes on the bus. Why must the register open a new row instead of updating the existing one?
A large part of the estate's behaviour is only visible in the field, and the operational record is a genuine engineering input.
The counterpart is the bench. Symbot Test Bench (2256928769, hardware) documents the J1939 simulator, the OBD simulator and the CDL simulator. Symbot 6 production run interface validation record (3817504774) is the existing validation artefact and should be extended rather than duplicated.
Bench capacity is a recurring constraint. A regression gate was recently waived because every laboratory board except one was offline. Knowing which boards are healthy is a prerequisite for trusting any result.
This is a map of who holds the depth in each area, so you know whose written work to read first and where the gaps are. All of it is being consolidated into this manual and its companion. Read the named engineer's pull request descriptions as well as their Confluence pages, because in several cases the pull request carries the better reasoning.
| Domain | Where the depth is | What to read first |
|---|---|---|
| J1939 and SocketCAN, tablet architecture, clock trust, data muling, device connectivity root causes | Ajay (Ajaypal Sandhu, AjaySym607 on GitHub). The largest single body of written analysis in the estate: the J1939 stack, the tablet architecture and provisioning runbooks, the clock trust initiative, the data muling design, and most recent device root cause investigations | Confluence 3695673345, 3812491269, 3875405826, 3903160333. Pull requests on pulse-daemon and xtablet carry the reasoning in their descriptions, and they are worth reading as documents. |
| Yocto, image, board bring up, over the air update, real time clock | Hai Wang. Image release ownership, device tree and kernel level work, build provenance, staged rollout and shadow driven configuration, and the low power and battery behaviour | FW-5554, FW-4986, Confluence 3846471691 |
| XTablet release, Manager internals, reverse tunnel, store and forward ordering | Kai Wang. The 2.0.0 release end to end, transport internals, reverse tunnel and port allocation, out of order tolerant ingestion, and archive segment naming | Confluence 3855417345, 3864854531, 3896868870. Project TAB. |
| Radio internals, sensor protocols, signal strength, radio configuration, CDL schema tooling | Tom Oke. The si446x domain, interrupt behaviour, configuration discrepancies, signal strength consistency across all four sensor families, and the CDL translation tooling and recording visualizer | FW-5463, FW-5462, Confluence 3852435458, 3847782403 |
| Sensor field support, hotspot, bench hardware, battery and power | Gagandeep Singh. Sensor tuning and field debugging, hotspot provisioning and internet sharing, hardware variants, battery testing and damaged device recovery triage | FW-5024, FW-5509 |
| Bluetooth zones, mesh routing, router platform, customer mesh support | Alona Bovshever. Zone configuration and beacon to zone mapping, asymmetry aware mesh routing, router persistent logging and serial recovery, and the Komatsu fault code lookup work. Her J1939 ramp up ladder is also a good reading order for that domain | Confluence 3579445250, 3841687566, 3877470210, 3737976840 |
| Mesh hardware evaluation | Zoe Lin. Recent evaluation of router hardware for the mesh product | Confluence 3887759362 |
| Fleet and field operations | Lalit. Per customer device status, update waves, site specific issues, and hotspot persistence in the field | Project FS and the per customer tickets in FW |
| Tablet and dispatch application layer | Rahul Gupta. Operator login flows, tablet and SymBot integration testing, the management message protocol, and zone identifier consumption on the tablet | |
| Product and analytics | Mayank Mahajan. Idling factors, proximity based queuing, mine map direction, notifications, and the cloud side messaging schema the tablet depends on | |
| Platform, asset registry, alarms | Saikat Prabhakar. The alarm management console programme, the asset register and fault service on the backend, and hotspot productisation | sight3-backend, and the alarm knowledge base in the product folder |
| Level | What it is | When it is enough |
|---|---|---|
| 1. Unit, off target | Tests on a laptop, including the native libraries now that they build for a desktop architecture | Never on its own for a decode or radio change |
| 2. Capture replay | The real stack against a recorded bus or a recorded radio capture, with no hardware | This is where most defects in this manual should have been caught |
| 3. Hardware in loop | A bench board with a simulator or a replayed capture | Minimum bar before anything is reported as working |
| 4. One real machine | A field machine, full shift | Minimum bar before anything reaches a fleet |
strings before it goes anywhere.Which test level would have caught the largest share of the defects described in this manual?
Complete this before section 15. It proves access, proves the toolchain, and establishes the reporting standard expected of everything afterwards.
What good looks like: every number is attributed to a named device, and the page states a limit of what it proves. That last part is the house standard and it is what makes the written record here trustworthy.
A colleague reports that a radio fix improved capture from 60 percent to 98 percent. What is the first thing you ask?
This manual was independently reviewed before release on two axes, instructional design and embedded systems technical accuracy. Both reviews returned pass with corrections, and every required correction from both reviewers has been applied in this revision.
Instructional review. Reviewed in full against a professional technical onboarding standard for learning architecture, cognitive load, retrieval practice, transfer, reference value and HTML accessibility. Verdict pass with corrections. Required corrections applied: terms defined before first use and a glossary added, content that existed only inside a diagram restated in prose and tables, a visible summary added above the collapsed case studies, front matter added covering audience, prerequisites, time, access to request and the completion bar, a mandatory practical exercise added, superseded reference pages marked inline, contents lists reconciled with the section numbering, the knowledge ledger given the names it exists to carry, quiz placement and two weak distractors corrected, and the placeholder certification block replaced with this one.
Embedded systems review. Reviewed by a principal embedded systems engineer against CAN, SAE J1939, SocketCAN, sub GHz radio, Yocto and Android device owner domain knowledge. Verdict pass with corrections. Corrections applied: error counter thresholds and the fact that only the transmit counter causes bus off, automatic bus off recovery, the scope of the hardware CRC claim, extended frame control bit count, the eighteen bit PGN assembly and the requirement to zero the PDU specific byte for addressed messages, the two missing failure mode identifiers, diagnostic message indexing from the fault record and the existence of earlier conversion methods, the width dependence of the reserved sentinel ranges, correct attribution of the 512 entry socket filter limit to raw sockets, the origin of the 256 prefetch value, the distinction between step and slew directives in time synchronisation, the regional regulatory position of the 433.92 MHz band, the strength of an eight bit checksum used for erasure resolution, the full checksum parameters, the correct driver name, and the normative status of the equipment class annex.
Verified arithmetic. The signal number 190 read big endian yields 48,640, confirmed. 160,633 seconds is 44.62 hours, confirmed. The code size headroom of 2,677 bytes divided across roughly 59 further registrations implies an average of about 45 bytes each, which is credible for the current method body and is an average rather than a bound.