CAN Messages

The IGNIS application uses three CAN messages: one control message from the host, one system status message for the host, and one internal peer status message between the controllers of a multi-master pair. All frames are standard data frames; multi-byte fields are little-endian.

ID	Direction	Period	Description
0x560	host → controllers	host defined	Control command — engine start, charging limitation
0x568	leader → host	31 ms	System status — the whole system in one frame
0x540 + addr	controller → bus	7 ms	Peer status — internal pair synchronization

The host integration in one paragraph

Broadcast 0x560 periodically (faster than the configured timeout, 1 s by default) with the start flag and the charging limit, and read 0x568 back. The 0x568 message is the only message the host needs to parse — it reports the same content regardless of whether one or two controllers are installed and which one currently leads.

0x560 — Control command (host → controllers)

Command from an external host (for example a vehicle supervisor). Every controller listens to this message independently — one broadcast commands the whole system; there is no per-controller addressing.

Byte	Type	Name	Unit	Description
0	uint8	flags		Bit 0 — request engine start/run
1–2	uint16	cmd		Charging limitation, relative: 0–65535 = 0–100 %

Behavior:

• The message is always received and latched. The start flag takes effect only when CAN is a selected start source (start_sel — see Enabling); the charging limitation cmd applies always, even in a GPIO-started installation.
• Every received frame reloads the timeout /can/can_ctrl_tim (default 1000 ms, 0 disables it). On timeout, the default behavior (/can/can_ctrl_stop = 1) clears the start flag — the engine stops if CAN is a start source. With /can/can_ctrl_stop = 0 the last command stays latched and the system keeps running (high availability); the timeout is then only observable in the /can/can_tmo state.
• cmd = 0 with the start flag set runs the engine idling without generation — see Loading.

0x568 — System status (leader → host)

The whole system in one frame, on a fixed ID. It is transmitted every 31 ms — fast enough for an ECU to follow the capability with the throttle — by the controller currently in charge of the generation: the leader of a pair, or a standalone controller. The host sees one consistent report regardless of the internal pairing or a failover.

Byte	Type	Name	Unit	Description
0	uint8	app_mode		System phase — see State Machine
1	uint8	app_flags		Application flags — see Status Word
2–3	int16	current	0.1 A	Total generated current of the system, negative = generating
4–5	uint16	voltage	0.1 V	DC bus voltage
6–7	uint16	capability		Torque capability: 0–65535 = 0–100 % of nominal, see below

current is the total generated current — the sum of what all the generators feed into the DC bus. Note that it splits into the battery charging and the host system's own draw: it is not the battery current alone.

capability tells the host what fraction of the nominal torque the system is capable and ready to sink at the given moment to fulfill the generation demand — a readiness scale, not a measurement of the torque currently applied. It uses the same scale as the cmd request, so requested and available are directly comparable. It is 0 whenever the system is not ready to load (stopped, starting, warmup, idle), rises with the load ramp, descends gradually during a rampdown, and drops when the electrical machines derate (thermal or voltage limits). It is intended as feedback for the ICE throttle: a host that wires the throttle to it always feeds the engine exactly as much power as the generators are ready to absorb. System power needs no field of its own — it is current × voltage.

app_flags are the global application flags — fundamental system state, not a CAN detail; the bit reference lives in Status Word.

Failover gap

During a controller failover, 0x568 can pause for up to ~1 second before the surviving controller takes the reporting over. It is advisable to treat a system status older than a few periods (~100 ms) as stale, and to hold or reduce the engine throttle until it resumes.

0x540 + addr — Peer status (controller → bus)

Per-controller status used by the pair for mutual monitoring and starting-sequence synchronization — part of the control loop, so it runs fast. The sender address is encoded in the CAN ID (0x540–0x546 for controller addresses 0–6). Broadcast every 7 ms and immediately on every mode change.

The host does not need to parse this message — everything system-relevant is in 0x568. The layout is documented for diagnostics:

Byte	Type	Name	Unit	Description
0	uint8	app_mode		Mode of this controller — see State Machine
1	uint8	stat		Driver protection flags (/driver/stat, low 8 bits)
2–3	uint16	limit		Driver limiter word (/driver/limit, low 16 bits) — why the total limit is below 100 %, 0 = no limiter active
4–5	uint16	total_limit		Total driver limit: 0–65535 = 0–100 %, 65535 = no derating
6–7	int16	current	0.1 A	Generated current of this controller, negative = generating

The status word is not part of this frame — it travels only in the system status 0x568; each controller's own word is readable in its /app_flags state.

info

The battery current used by the DC regulation is received on a customer-specific message that is compiled in — the public firmware contains no battery current input and limits the summed current measured by the controllers themselves.

tip

Need specific information sent via CAN? Please send your request to support@silixcon.com.