Agopengps Knowledge Patch

AgOpenGPS Knowledge Patch

Use this skill when maintaining, deploying, integrating, or diagnosing AgOpenGPS, AgIO, their successor applications, or the associated GNSS and machine-control hardware.

How to use this patch

1. Identify the exact application line: classic WinForms AgOpenGPS, historical AgValoniaGPS, or AgOpenWeb.
2. Record the application tag or commit, controller source commit, PCB revision, receiver role, receiver firmware, and generated configuration.
3. Keep position input, correction transport, application framing, steering, and machine output as separate interfaces while diagnosing a system.
4. Apply only the guidance that matches the selected application line and hardware family.
5. Revalidate files, messages, ports, and firmware whenever crossing an application or board-family boundary.

Reference index

Safety boundary

Automatic control has no built-in safety boundary. Treat the software as a demonstration and simulator system, provide an independent way to stop control, and keep people clear of moving equipment.

Do not use any of these as evidence that operation is safe:

• valid GNSS reception;
• an RTK fixed solution;
• correct coverage painting;
• a responsive steering loop;
• an accessible browser or caster connection.

Verify wheel-angle sign, center, range, smoothness, and full mechanical travel before enabling steering output. See Autosteer hardware.

Breaking application changes

Recheck extensions after the 6.7 modernization

The 6.7 line retained the AgIO/application split but moved projects to SDK style, removed x86 builds, moved shared facilities to AgLibrary, and centralized logging. Review extensions that depend on 6.6.x project layout or internals. The WPF example did not replace the production WinForms direction.

Use 6.7.1 rather than 6.7.0 when a deployment must remain on the 6.7 line, because 6.7.1 corrects several initial behaviors.

Do not time section control from rendering

Section control became switch-based in 6.7, and machine nudge uses custom PGN 222. Since 6.8.1, section processing runs at a fixed 10 Hz. Render-frame rate is therefore the wrong clock for section timing or diagnosis.

Treat profile domains independently

Starting in 6.8.2, vehicle, tool, and environment settings have separate storage and lifecycles:

VehicleProfiles/{name}.xml
ToolProfiles/{name}.xml
Environment/environment.xml

Do not assume a vehicle selection also selects an implement. Profile switching saves the current profile first in 6.8.3, and nudge step size belongs to the tool. See Application evolution and profiles.

Keep Task Controller on the existing transport

The ISOBUS Task Controller introduced in 6.8.2 launches through AgIO and uses the existing UDP/custom-PGN channel to reach AgOpenGPS. Do not invent a second Task Controller transport or diagnose it as an Arduino relay path.

Preserve temporary Easy Drive semantics

Easy Drive creates no field, uses a rigid single-section tool, disables field-dependent features, writes no session data, and restores the original vehicle and tool settings on exit. Do not persist its temporary state as a normal field session.

Release and host selection

For classic WinForms deployments, use an official unprefixed release tag and prefer the maintained 6.8.5 release over a moving branch. Maintenance-only did not mean frozen: critical fixes continued after 6.8.3.

Do not numerically compare the classic 6.8.x line with AgValoniaGPS or AgOpenWeb date-like releases. Those are separate codebases with independent compatibility boundaries.

AgValoniaGPS is archived and points to AgOpenWeb. Historical nightly artifacts need an exact nightly tag and commit because an internal version may not identify one build uniquely.

For AgOpenWeb, select all three dimensions:

• stable or nightly channel;
• desktop, headless service, or mobile execution mode;
• operating system and CPU architecture.

Desktop, service, and Android bundles are not interchangeable. See Cross-platform hosts for platform and runtime prerequisites.

Layered data-path diagnosis

Diagnose the system in transport order:

1. Confirm incoming NMEA and the current position/fix state in AgIO.
2. Confirm the NTRIP request, mountpoint, GGA behavior, and received correction bytes.
3. Confirm selected serial or UDP correction outputs and module status.
4. Confirm binary application messages reach AgOpenGPS or network modules.
5. Only then investigate guidance, steering, or machine behavior.

An AgIO monitor proves only the layer it observes. A browser UI proves host reachability, and a caster socket proves connectivity, not fresh or usable corrections.

For dedicated Ethernet modules, use unique addresses on 192.168.5.0/24 and do not attach two PC adapters to that subnet. Working Wi-Fi does not validate the module network. See Desktop operation and networking.

Corrections and base stations

Keep NTRIP request controls, GGA feedback, and RTCM output routing distinct. AgIO can send corrections over serial or UDP, commonly port 2233 for All-In-One Teensy hardware, and can accept local corrections through Serial NTRIP for onward routing.

For a stationary ZED-F9P base using the documented default constellations, start with one coherent MSM family:

1005
1074 1084 1094 1124
1230

Use the same observation rate and MSM class across constellations. MSM7 replaces MSM4; it does not accompany it. Match the station ID in the reference message and observations, keep receiver ports consistent, and monitor correction age. See RTCM base and receiver profiles.

Navigation protocol boundary

An RMC-only receiver stream is insufficient for the active AgIO dispatch path. Configure a supported GGA/VTG/HDT or proprietary sentence set and confirm it in the serial monitor.

Do not collapse these three formats into one protocol:

receiver -> ASCII navigation sentences -> AgIO
caster   -> binary RTCM corrections     -> receiver
AgIO     -> binary AOG PGN 0xD6         -> application/modules

The 0xD6 frame is neither ASCII NMEA nor SAE J1939. The release-specific $KS checksum exception is compatibility behavior, not a general parser rule. See NMEA and application framing.

Hardware identity before configuration

Never treat a board nickname as a firmware version. Record the exact PCB revision and population, schematic or Gerber commit, firmware directory and source commit, receiver role and firmware, and generated Config-O-Matic file.

Current AIO designs require Teensy 4.1. Teensy 3.2 and 4.0 are not substitutes. Standard and Micro receiver modules must also match the PCB's physical socket.

Choose the output chain by steering interface: steer-ready CAN, Keya wheel, DIY motor, PWM hydraulic valve, or Danfoss integrated valve. These paths do not share generic pinouts or output modes.

Machine-control ownership

Use machine-specific custom PGNs and a protocol document matched to both the application and controller firmware. Sixty-four equal software sections do not imply 64 physical outputs.

Do not share pin mappings or configuration constants between Nano RC12-3, Teensy 4.1 RC11-2, and ESP32 RC15. Preserve the matching firmware commit with each PCB revision.

Assign every physical output one owner. If the ISOBUS Task Controller owns sections, do not enable a relay controller to command the same outputs. See Machine and rate control.