Jordan Burgess

I’m developing and bench-testing a four-channel embedded controller that switches and dims 12 V DC loads over an RV-C network.

The work covers STM32 firmware bring-up, RV-C command and status handling, timer-based PWM and fades, SPI configuration and watchdog servicing for the smart high-side switch, fault decoding and recovery, dual-bank (A/B) firmware updates over CAN, and automated host, hardware-in-the-loop, and manufacturing tests. The goal is to test the complete path: send a command over the network, route it to the correct instance, generate the expected output, and confirm that the attached load actually responds.

Some of the most useful failures happen when the CAN traffic and timer state look correct, but the physical output does not. Finding the cause means checking protocol timing, peripheral configuration, switch diagnostics, power rails, assembly differences, and the load itself as parts of the same system.

Most of the systems I work on combine battery management, charging, power conversion, DC distribution, monitoring, supervisory control, and human-machine interfaces from different manufacturers. My role is to make those products operate as one system and then work out why they do not.

That work moves between system architecture, device configuration, CAN and RV-C traffic, reproduction of intermittent faults, and validation of firmware or configuration changes. It also requires coordinating with manufacturers, installers, customers, and internal engineering teams, since each group usually has a different view of the same failure.

The difficult problems are often not contained within any one device. They appear when two products make different assumptions about command timing, reported state, control authority, initialization, or recovery. Each device can be behaving as designed while the system still produces the wrong result.

I help define and validate the configuration model used to describe connected devices, electrical loads, I/O assignments, control relationships, interface behavior, and network parameters in configurable embedded systems.

Much of my role is translation: turning embedded-system constraints into software requirements, representing physical relationships in the schema, and making sure the generated deployment files still describe the intended system. I reproduce configuration and export failures, test deployments against physical hardware, and help installers and software developers work from the same understanding of how the system is wired and expected to behave.

Once a configuration controls real hardware, it becomes more than a collection of settings. A stale schema, invalid assignment, missing relationship, or failed export can change how the deployed system behaves and become a physical system fault.

I set up and use remote diagnostic access to mobile and off-grid power systems through device telemetry, network connectivity, status reporting, configuration inspection, and structured testing in the field.

The work includes troubleshooting diagnostic paths, interpreting telemetry, investigating missing devices, and comparing reported behavior with the state of the system. An important part of that process is separating a problem with remote access from a problem involving control, configuration, firmware, power, or the application itself.

Being online is useful, but it is not enough to make a system diagnosable. A useful investigation requires knowing which device produced an observation, when it happened, what configuration and software were present, what commands had been sent, and what state the system reported afterward. Without that context, remote data can show that something happened without explaining why.

During integration testing, I found that a single On action in a supervisory interface could intermittently leave an inverter/charger in Inverter only. The interface presented one control to the user, but issued separate charger-enable and inverter-enable commands back-to-back. The receiving driver then had to combine those two requests into one device mode.

I documented the expected and observed state transitions, narrowed the failure to the interaction between the commands, and worked with the manufacturer’s engineering team to test the race-condition hypothesis. They reproduced the behavior on physical hardware, confirmed the race, and developed an automated sequence test. A revised driver is now on the test bench, where final validation remains pending.

Neither RV-C command was invalid. The failure came from how the driver composed them. When separate asynchronous controls change one underlying operating mode, the receiving implementation has to define which state each handler reads, how nearly simultaneous updates are ordered, and when the combined mode is written to the device.

I’m developing an independent research project on timing, coordination, and state consistency in CAN-based distributed control systems. The broader scope includes networks used in mobile, industrial, marine, robotic, agricultural, and energy applications.

The project is still in its research-design phase. I’m reviewing prior work, narrowing the questions, and defining the experiments, firmware, software, data collection, and analysis needed to study these systems in a repeatable way.

There are no experimental findings to report yet. The first milestone is a dedicated test platform where I can control bus utilization and message timing, measure arbitration delay by identifier priority, and record endpoint response latency. That platform will provide the basis for measuring when commanded, reported, and observed state diverge, how long the divergence persists, and how those failures appear on the network.

At a remote McMinnville Water & Light catchment site, I worked on the engineering and integration of a fully off-grid 48 V Victron power system that supports the monitoring and hydraulic controls used to release water to the municipal treatment plant.

The system separates continuous and intermittent loads. A dedicated MultiPlus 2000 supplies monitoring equipment around the clock, while two MultiPlus 5000 units provide split-phase power for the nitrogen accumulation pump and charge the 80 kWh battery system from a generator. The higher-power inverter path is enabled by the existing Allen-Bradley PLC only when hydraulic operation is needed, and Node-RED plus generator-start logic coordinates charging when the generator runs.

Reliability had to be designed into both the physical and control architecture. The battery system uses dual Lynx BMS NG units, solar charging is divided across three independent MPPT and array paths, the array includes module-level rapid shutdown, and the battery equipment is housed in seismically rated enclosures. Those independent paths limit the effect of maintenance or a single charging-path fault while keeping the system understandable and serviceable in a remote location.

I develop Garmin-based control interfaces that bring Victron power data, RV-C devices, and vehicle subsystems into one operating surface. The work includes programming customer-specific systems, mapping device state and commands, and translating the electrical architecture into controls that are usable without requiring the operator to understand every component behind them.

On the Noovo Next platform, that meant supporting a move from 12 V to 48 V power while building a fully branded Garmin interface for lighting, climate, power, connectivity, and system monitoring. We extended the available Garmin framework with an embedded HTML interface so the product could be developed more like a modern web application without separating the user experience from the underlying vehicle controls.

The harder part is not displaying the data; it is defining how the systems cooperate. Shore-power availability, battery state, temperature, and user intent can change which loads should run and which energy source is appropriate. I test those rules against real hardware and firmware updates so the single-screen interface remains consistent with the state of the power system and the physical vehicle.

I’m building a custom Venus OS control and HMI system for an Echodyne on-the-move radar truck. The system manages 14 electrical loads through a Victron Ekrano GX, combining vehicle-running state, shore power, battery state of charge, operator requests, and timers into one guarded operating model.

The control boundary is deliberate. QML presents current state and sends requests; it never has authority to energize a load. A Node-RED runtime owns the state machine, validates every global and per-load request, publishes status through a project D-Bus service, and sends commands to Ethernet-connected switching hardware only when the operating conditions and output gates agree. Commanded and observed relay state remain separate so an accepted request is not treated as confirmed output state until device feedback arrives.

Development has moved from mock data and offline tests into staged commissioning on the truck. The 14-load interface and baseline runtime are deployed, output channels are brought live one at a time, and the current validation work treats network interruptions, device identity, stale feedback, low-battery lockout, and restart behavior as explicit system conditions. That process keeps the control logic testable without letting development or presentation code bypass the hardware safety boundary.