[feat] AUX-N simulator

[gunicsba]

For our KUHN seeder I want to control the Start / Stop buttons with AOG Hydlift.

The library allows us to send CAN messages.
I need to check if the SA matters. (The target VT address definitely matters.)

Not sure if it's up to the spec to have 2 joysticks for the same purpose but maybe we could hack some systems this way.

Systems without the SC unlock could still support AUX-N section control.

[gunicsba]

ChatGPT:

ISOBUS AUX-N – Physical + Virtual/GPS Control Concept
Goal

We want to control the same ISOBUS implement function from two sources:

A physical AUX-N joystick
A virtual/GPS-controlled AUX-N input, e.g. AgOpenGPS automatically starting/stopping the implement at the headland.

Example: a sprayer exposes an AUX-N function for Spraying ON/OFF. The operator should still be able to control it manually, while the GPS can also trigger the same function automatically.

Problem

Multiple AUX-N devices can exist on the same ISOBUS network. However, relying on assigning the same implement AUX-N function to two different AUX-N inputs is problematic and may not be supported by the AUX-N assignment mechanism / VT implementation.

We also cannot modify the implement ECU, so adding a second internal control path inside the sprayer ECU is not an option.

Proposed approach: Virtual AUX-N / Gateway

Instead, our VT application could provide a learning/mapping mechanism.

The concept would be:

In our VT application, the user selects a virtual AUX-N action to configure.
The application enters a learning mode.
The user presses the desired button on the physical AUX-N joystick.
We observe the corresponding AUX-N CAN traffic and determine the input/event associated with that button.
The mapping is stored.
Later, the GPS/headland automation can reproduce the equivalent AUX-N action automatically.

This would effectively create a virtual AUX-N control layer.

For example:

Physical joystick button → Sprayer ON/OFF

and after learning:

AgOpenGPS headland event → Virtual AUX-N action → Sprayer ON/OFF

Important point to investigate

We should not assume that simply recording and replaying a raw CAN frame is sufficient.

AUX-N communication may contain device identity, input object IDs, state/counter information, assignment state, or other protocol semantics. Therefore, the preferred implementation may need to generate a protocol-correct AUX-N input status/event rather than blindly replaying captured CAN frames.

We also need to determine whether the physical AUX-N device continues transmitting usable input-state information when the relevant input is not assigned, and how the VT/AUX-N assignment state affects this.

Desired UX

Ideally the VT application would contain something like:

AUX-N Virtual Controls

Spraying ON/OFF → Learn

The operator presses Learn, then presses the corresponding physical joystick button.

The application remembers that association, and AgOpenGPS can subsequently trigger the learned action automatically—for example when entering or leaving a headland.

Next step

The main technical question is therefore:

What exact AUX-N messages and state transitions are produced when a physical AUX-N input is activated, and can our virtual AUX-N device reproduce those actions in a standards-compliant way without modifying the implement ECU?

A CAN trace together with the relevant ISO 11783-6 AUX-N documentation would be useful for determining the correct implementation.

[gunicsba]

Claude:

Feature: AUX-N virtual input — let AgOpenGPS drive an implement AUX function alongside the physical joystick

Goal

Allow the same ISOBUS implement AUX function (e.g. a sprayer's "Spraying ON/OFF") to be
controlled from two sources:

1. the operator's physical AUX-N joystick, and
2. AgOpenGPS automation (headland enter/exit, section logic).

Constraint: the implement ECU cannot be modified.

Why the obvious approaches don't work

Two inputs assigned to one function is not a thing. An Auxiliary Assignment Type 2
command binds exactly one Auxiliary Input to one Auxiliary Function. The many-to-one
direction that ISO does support is the opposite one: the Single Assignment attribute on
an Auxiliary Function controls whether other functions may share the same input.

Recording and replaying joystick CAN frames does not work either. The Auxiliary Input
Type 2 Status message carries only the input object ID, Value 1, Value 2 and an
operating-state byte — no NAME. The function unit correlates it by source address,
resolved from the NAME it received in the assignment command. A replayed frame sent from
our address is simply not that input; a frame spoofed from the joystick's address collides
with the real device. What makes the implement act is assignment state, not frame content.

Proposed design

Run two roles. Safest as two internal control functions with separate NAMEs on the same
physical device, since some VTs dislike one CF being both an input unit and a function
provider.

Role A — Auxiliary Function provider (receives the joystick)

Add an Auxiliary Function Type 2 object to our existing working-set pool, e.g.
"AOG Spray Request", with a function type matching the joystick button
(0 = boolean latching / 2 = momentary, whichever the button is).

The operator assigns the joystick button to our function in the VT's normal AUX
assignment screen. We then receive that button's state legitimately, as an assigned
function unit.

This replaces the proposed "learn mode" entirely. The VT's assignment screen is the
learn UI, with correct designator icons and no CAN sniffing.

Role B — Auxiliary Input Unit (drives the implement)

A second pool containing an Auxiliary Input Type 2 object (+ Auxiliary Control Designator Type 2) whose function type matches the implement's target function. The
operator assigns that to the sprayer's "Spraying ON/OFF".

We then transmit Auxiliary Input Type 2 Status driven by our merge logic:

virtual_input_state = f(joystick_state_from_role_A, agopengps_headland_state)

Merge policy is a product decision — OR, last-writer-wins, or manual-override-latches.
Start with: AOG drives it, any joystick press takes over and inhibits AOG until re-armed.

Net result: the implement sees exactly one assigned input, everything is
standards-compliant, the implement ECU is untouched, and both control sources work.

Implementation checklist (Role B)

• Address claim with a stable NAME and stable Model Identification Code. The
  implement stores preferred assignments as (function object ID, input object ID, model
  identification, input NAME) — if either drifts across boots, the assignment is lost.
• Auxiliary Input Type 2 Maintenance, sent periodically with model ID and
  initializing/ready status. Without it the VT won't list us in the assignment screen.
• Auxiliary Input Type 2 Status: object ID, Value 1 (state/position), Value 2
  (transition count for booleans), operating state byte — including the learn-mode-active
  and activated-in-learn-mode bits the VT uses during assignment.
• Handle Auxiliary Assignment Type 2 command + response.
• Handle Auxiliary Input Status Type 2 Enable (per-input enable/disable of status
  transmission).
• Handle Preferred Assignment so assignments survive a power cycle.
• Report actual implement state back to AgOpenGPS rather than assuming our command took.

AgIsoStack++ already implements both the input-unit and function-unit sides — this should be
mostly wiring, not protocol work. Take the exact function code values from
VirtualTerminalClient::Function in isobus_virtual_terminal_client.hpp; the AUX messages
sit in the 0x20–0x27 block of the first data byte on the VT PGNs.

Known gotchas

• Initial-state handshake. ISO 11783-6 Annex J warns that the control's state may not
  match the function's state at assignment time, and the function is responsible for
  resolving it — possibly by requiring the operator to cycle the input first. Our first
  automatic command after an assignment may be silently ignored. Design for that.
• Critical control / assignment lock. If the implement's function object has the
  critical-control attribute set, it can only be assigned to an input unit that declares
  support for it. Assignment lock restricts it to preferred assignment only. Check the
  implement's pool attributes before building.
• Function type must match between our input object and the implement's function object,
  or the VT will refuse the assignment.
• VT limits. Some commercial terminals cap the number of AUX input units or reject
  unfamiliar ones.
• Safety. A GPS-driven virtual input is unattended actuation of an operator control.
  Acceptable for spray on/off; think hard before extending this to hydraulics.

Alternative to check first

For sprayers, TC-SC is the standards-intended path for headland on/off, and we're already
building the TC side. If the target implement supports TC-SC, use that instead. The
AUX-N virtual input is the right answer only for implements that expose the function solely
via AUX.

Open questions — need a CAN trace to close

Capture one session, full power cycle, filtered to the two VT PGNs plus address claim:

1. Boot: address claims, VT status, both pools loading, any Preferred Assignment command
   from the implement.
2. Assignment: enter the VT AUX screen and assign the button — VT Status with the
   aux-learn-mode bit, joystick status messages with learn-mode bits set, then the
   Assignment Type 2 command + response.
3. Assigned steady state: press the button, record Value 1 / Value 2 and the repeat rate.
4. Unassigned: unassign and keep logging. Does the joystick still transmit status? Did an
   Input Status Type 2 Enable command appear?

Step 4 decides how much fallback design is needed. Also outstanding: exact on-change and
repeat timing requirements for the status message, and the timeout after which the implement
drops a function to "not enabled" — both in ISO 11783-6 Annex J, which we should read before
finalising the timing loop.