Skip to content

Test build: upcoming changes for field testing (do not merge) - #124

Draft
gunicsba wants to merge 40 commits into
developfrom
test/upcoming-integration
Draft

gunicsba wants to merge 40 commits into
developfrom
test/upcoming-integration

Conversation

@gunicsba

@gunicsba gunicsba commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

Do not merge. This is a test build that combines the changes waiting to go into develop, so they can be tried together on a real tractor. Please leave what you find as comments here.

Getting the build

Open the Checks tab of this PR, then the Build workflow run. The Windows Installer and the Linux tarballs are under Artifacts at the bottom of the run page (you need to be signed in to GitHub). Each new push here produces a new build.

Please attach the log to your comment. When AgIO starts the TC, logging is already on; if you start it yourself, add --log2file. On Windows the logs are in %APPDATA%\AOG-TaskController\logs.

What to try

PR Change What to check
#118 Second TECU: fills the gaps next to the tractor's own TECU See below.
#122 Time/Date answered on request, never sent unprompted A device requesting PGN 65254 gets UTC plus the correct local offset, unless the tractor's TECU provides it.
#102 Section control switches on by itself Connect an implement, and open a field in AOG. It should go to automatic without pressing AOG's SC button. Settings: sectionControlOnConnect, sectionControlOnFieldOpen (both default to on).
#105 Reconnect after a TC restart Restart the TC while an implement is connected. The implement should reconnect and accept section commands again.
#107, #98 UDP parsing and less log noise Sections and speed keep working. The log has fewer repeated "Unknown start of message" lines.
#82 Tractor Facilities (PGN 65033) Implements that ask what the tractor provides get an answer. Look for [TractorFacilities] in the log.
#84, #85 Guidance track data and track control levels With a TRACK-capable implement: track number and deviation arrive, and level negotiation completes. Needs an AgOpenGPS change, see below.
#120 AgIsoStack++ update General regression check, especially the VT connecting and reconnecting, and implements uploading their object pool.
#121 candleLight/gs_usb adapters on Windows Only if you have one. Needs an AgOpenGPS change to pick it from AgIO, see below.
#123 TC number setting Only if the tractor has its own TC: set tcNumber to 2 in settings.json, then restart the TC.

Second TECU (#118). The tecuEnabled setting now picks the role:

  • Off, for a tractor with its own TECU: the TC runs as a second TECU and adds only what the tractor's TECU doesn't provide. Search the log for [TECU] to see what it decided to send. Please check that it doesn't duplicate any of the tractor's messages, including in the first seconds after start.
  • On, for a tractor without one: the TC is the main TECU at address 240. If a tractor TECU appears, the TC steps down to second TECU, and the VT shows "Tractor ECU found: AOG adds only missing data".

Changes needed in AgOpenGPS

Checked against AgOpenGPS develop (64984a3d).

Feature What AgOpenGPS needs Without it
Guidance track data (#84, #85) PGN 0xF4 from AgOpenGPS-Official/AgOpenGPS#1218 (branch tracksForTC). Still open, so test with an AgOpenGPS built from that PR. Implements get no track data (DDI 507-513). Track level negotiation and the track control state (DDI 515) don't depend on it.
GNSS quality (DDI 514, already in develop) AgOpenGPS-Official/AgOpenGPS#1231, still open: AgIO only forwards PGN 0xD6 to the TC when setUDP_isSendNMEAToUDP is on. That defaults to off and has no setting in the UI, so it has to be changed in the AgIO profile for now. The TC sends a fixed placeholder, quality 1, instead of the real fix quality.
candleLight adapters (#121) Add a candleLight entry at the end of the adapter list in FormISOBUS.Designer.cs. It has to go at the end because AgIO saves the selected position. To choose between several adapters, also add it to adapterChannels in FormISOBUS.cs. It can't be picked in AgIO. Start the TC from the command line with --can_adapter=candlelight.

Nothing else needs an AgOpenGPS change. AgOpenGPS develop already sends the field name (PGN 0xF3) that #102 and #84 use. tcNumber and the sectionControlOn... settings have no screen in AgIO, so they're edited in settings.json.

Not in this build

Draft PRs #106, #111, #76 and #75.

Combined here

Merging these needed conflict resolution, so a problem could come from the combination rather than from a single PR:

Built on Windows, and all 11 unit tests pass. It has not been run on a bus yet.

🤖 Generated with Claude Code

gunicsba and others added 30 commits September 20, 2026 01:02
Parses the fix-quality byte from AOG's GPS/IMU PGN 0xD6 (source 0x7C) and
pushes it to every client whose DDOP declares DDI 514 (GNSSQuality), every
250 ms.

- AOG fix values 0-8 are forwarded unchanged (they are the NMEA 2000 GNSS Method
  values DDI 514 uses, including 6=Estimated, 7=Manual, 8=Simulated). Values
  above 8 and a stale/missing 0xD6 map to 1 (weakest real fix) rather than 0,
  since some implements gate TRACK and section control on GNSS quality being
  non-zero.
- DDI 514 is mapped to its element in request_measurement_commands() alongside
  the other DDI mappings; mapping only, no OnChange subscription, since it is
  a value the TC pushes rather than one it reads back. Only implements that
  declare DDI 514 as settable are mapped, since a non-settable DDI cannot accept
  a Value command.
- docs/PROTOCOL.md and the readme document the new PGN and DDI. The readme
  gets its own "Guidance data sent to implements" subsection so follow-up
  guidance PRs append bullets there instead of all editing the shared
  capabilities list.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Parses AOG's guidance track context (PGN 0xF4) and field name (PGN 0xF3) and
pushes the current track to every client whose DDOP declares the DDIs, every
250 ms while AOG has a valid track:

- 507 GuidanceTrackSequenceNumber: advances whenever the track number or the
  reference line changes (a line switch can land on the same track index).
- 508 UniqueGuidanceReferenceLineID: AOG's 16-bit line ID in the low 16 bits and
  a persistent per-field index in the high 16 bits, so it is unique across
  fields. The index comes from FieldRegistry (field_registry.csv next to
  settings.json).
- 509-511 actual/right/left track number, with the +1 offset field testing
  showed implements need to stay in phase with AOG's on/off state.
- 512 GuidanceLineSwathWidth: AOG's track spacing (tool width minus overlap),
  read from the optional bytes 10-11 of PGN 0xF4. Not sent when AOG omits it or
  reports 0, so older AOG builds keep working.
- 513 GuidanceLineDeviation from AOG's XTE.

The DDIs are mapped in request_measurement_commands() by extending the loop
that maps GNSS quality, so, as for DDI 514, only DDIs an implement declares as
settable are mapped. Nothing is gated on track-control negotiation: the TC
pushes these values and any implement declaring them receives them.

Adds unit tests for the PGN 0xF4 parser (sequence freshness and wrap, offset,
validity, swath width). test_guidance_track is a dependency of iop_validator so the
validation workflow, which builds only that target, builds it too.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…tate (DDI 515)

Negotiates a track control level with implements and switches their track
control on and off together with AgOpenGPS's Auto command:

1. The implement reports the levels it supports as a bitmask in DDI 505.
2. The TC writes DDI 506 (an enum, unlike 505) back. Only Level 1 is
   implemented, so it asks for Level 1 whenever the implement supports it,
   even if it also advertises Level 2 or 3.
3. The implement's DDI 506 echo completes the negotiation.

DDI 515 (TrackControlState) is written only to clients that completed the
negotiation, each time AOG's section control mode arrives. The guidance data
from the previous PR is not gated on any of this.

The DDIs are mapped with find_owning_element_number() from the guidance data
mapping, plus an OnChange subscription because the implement reports them.

Also announces functionality 27 (Task Controller TRACK server) in PGN 64654
and shows the track state and the implement's supported levels on the VT
status page.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds TractorFacilities: builds and sends the PGN 65033 facility bitmask
(ISO 11783-7 B.24.3), advertising which PGNs the TECU actually broadcasts
(ground- and wheel-based speed, distance and direction). It is sent once on
power-up and on PGN 65033 request. PGN 65032 (Required Tractor Facilities)
requests are logged at debug level without changing the response.

Also adds diagnostic logging for Request-for-Repetition-Rate (PGN 0xCC00),
both the addressed and the broadcast form, and unit tests for the facilities
bitmask encode/decode logic (tools/test_tractor_facilities.cpp, registered
via CTest).

The IOP validation workflow built only the iop_validator target and then ran
all of ctest, so it now builds test_tractor_facilities as well.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Resolve conflict in request_measurement_commands(): keep the GNSS quality
(DDI 514) mapping and switch its output, plus the two GNSS prints in
app.cpp, to log() to match the async logging from #79.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nnouncement

Resolve conflict in request_measurement_commands(): keep this branch's
generalized guidance-DDI mapping and use log() as the base branch now
does. Also switch the FieldRegistry and TRACK prints to log() to match
the async logging from #79.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…levels

Resolve conflict in request_measurement_commands(): keep the track
control DDI subscriptions and switch their output to log() to match the
async logging from #79.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
guidance_track_context.cpp now logs through log(), which needs
async_log.cpp; the standalone test target only compiled the parser, so
the IOP validation build failed to link.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…levels

Picks up the test_guidance_track link fix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"Unknown start of message" was printed twice per packet: both UDP sockets
listen on port 8888 (one on the AOG subnet address, one on all
interfaces), so every broadcast arrives on both. Log it through
UdpConnections::log_unknown_start(), which skips an identical report
(same sender, same leading bytes) within 50 ms and includes the sender
IP:port and up to 16 bytes in hex, so the source can be found.

"Received a Request to Send (RTS) message with a global destination" is
a stack warning without a source address, printed for every frame. The
CAN stack log sink now treats it as Debug. The application counts such
RTS frames per source address from the CAN frame received event and
logs one summary line per minute when there were any.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A client whose DDOP has no section elements, such as a tractor ECU that
only describes hitch or GNSS geometry, has nothing to section-control.
It was reported with "WARNING: No supported section control method
detected!", which sent people looking for a problem that is not there.
Log it as info ("Non-section client") when the DDOP has zero sections;
DDOPs that do have sections but no supported method still get the
warning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Until now an implement stayed in manual mode after connecting until the
operator pressed AOG's ISOBUS SC button, which sends PGN 241. The TC now
remembers the section control state it wants and applies it to each
client 2 s after its pool is activated: it sets the local auto flag and
writes DDI 160 when the implement declares it.

The initial state comes from the new settings.json key
"sectionControlOnConnect" (default true). Pressing AOG's button still
switches all clients and also becomes the state for implements that
connect later. The implement can still decline or go back to manual;
its DDI 160 report is followed as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…he next one

The receive loop kept unparsed bytes in a static buffer between datagrams and
never reset its read index after moving leftover bytes to the front. A packet
shorter than 8 bytes (AOG's 7-byte section control request, PGN 241) waited in
the buffer for the next datagram, and the packet after it was then read from
the wrong offset, logged as "Unknown start of message" and dropped. It also
read the 2 start bytes with two unsequenced index++ in one expression, and did
not check that a whole packet was present before handing it on.

AgIO never splits a packet across datagrams, so each datagram is now parsed
on its own by aog_packet::parse_datagram (header-only, unit tested), shared by
the AOG and address detection sockets.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An implement only reconnects when it sees no TC Status for 6 s. Restarting the
TC takes 2-3 s, and both our TC Status and the stack's (sent from
TaskControllerServer::update()) were back on the bus before that, so the
implement kept sending process data as if nothing happened. The new TC did not
know it and NACKed every message; in the field a spreader stayed cut off for
20 minutes across three restarts, until the tractor was power-cycled.

- Startup: hold TC Status, and the TC server update that sends the stack's
  copy, for 6.5 s, so clients of the previous run time out and reconnect.
- Runtime: watch for Client Task and Value messages addressed to us from a CF
  the stack has no active client for. Such a client still thinks it is
  connected; hold TC Status for 6.5 s so it starts over. A 30 s cooldown lets
  reconnecting clients finish, and after 3 attempts for the same NAME the TC
  stops and asks for a power-cycle instead of disturbing the other clients.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
New sectionControlOnFieldOpen setting (default on): when AOG opens a field,
the TC switches section control on as if AOG's SC button was pressed (the
same update_section_control_enabled(true) that PGN 241 "enabled" triggers).

AOG sends the field name (PGN 0xF3) on every field open and close, and
again when the TC reconnects. Older AOG versions do not, so PGN 229
starting after a 2 s gap (AOG sends it only while a field is open) counts
as a field opening too. Both report the same opening, so it is acted on at
most once per 5 s. Field open and close are logged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The field log showed datagrams with 2 or 4 bytes after a complete packet, and
others that are not AOG packets at all (one starts with "$P"). The log only
said how many bytes were dropped, so the sender could not be identified.

Log the sender's address and port, and up to 64 bytes as hex with a "|" where
parsing stopped, followed by the printable characters.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Field-open detection now uses lastSectionDemandMs and
SECTION_DEMAND_TIMEOUT_MS from #108 in place of its own
lastSectionStatesMs and FIELD_CLOSED_GAP_MS, which recorded the same
PGN 229 arrival with the same 2 s gap.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ISO 11783-9:2012 4.4.2.1: with several Tractor ECUs on the implement
bus, function instance 0 is the primary, and a higher instance must not
send what a lower one provides, requests PGN 65033 from it, and sets
only the facility bits it lacks.

- At startup, claim 0xF0 as the primary only if no other Tractor ECU
  answered the TC's address claim. Otherwise claim an arbitrary address
  as a secondary with the next function instance.
- The TECU NAME is now arbitrary-address-capable, its most significant
  bit, so a primary loses a contest for 0xF0 to a tractor's fixed-address
  Tractor ECU instead of taking the address from it.
- Once a second, check for other Tractor ECUs. A primary steps down when
  another instance 0 appears or it lost 0xF0, rebuilding the control
  function without blocking the main loop.
- A secondary sends nothing until the lower instances answered PGN 65033
  (2.5 s at most), then sends each of ground-based, wheel-based and
  machine selected speed, J1939 vehicle direction/speed and NMEA 2000
  COG/SOG only if none of them advertises it or sent it in the last 3 s.
  PGN 65033 advertises exactly what it sends, and is re-sent on change.
- The primary now advertises the selected speed facility (byte 5 bit 3),
  since the TECU sends machine selected speed (PGN 61474).
- TractorFacilities gets a destructor that removes its callbacks, and
  set_provided_facilities().

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tecuEnabled off is what operators set when the tractor has its own
Tractor ECU, and so far it meant no TECU at all. Now it starts our TECU
as a secondary, never at 0xF0: it listens to the tractor's Tractor ECU
and sends only what that one lacks, or everything when there is none.
tecuEnabled on still makes AOG the primary, stepping down if a tractor
TECU turns up after all.

The VT label shows who leads: "TECU: AOG" or "TECU: tractor" (pool
length 23).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Picks up the upstream fixes since 1d081d9, among them:
- #834 take a control function offline only after two missed address claim requests
- #857 ignore short TC process data frames and truncated DDOP objects
- #818 TC server: width editable flag, working set logging, version request
- #798 VT client terminate/receive safe against a restart from another thread
- #808 send a TP session's first frame once when sending from another thread
- #781 bounds-check VT Change String Value, log the VT's error response
- #724 keep a new partner's address claim credit when it replaces a CF
- #789 Windows WinUSB driver for candleLight/gs_usb adapters (not enabled here)

No TC code changes needed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AgIsoStack++ #789 added a WinUSB driver for adapters running candleLight
(gs_usb) firmware, such as CANable 2 and the WeAct USB2CANFD. Build it into
the Windows TC and select it with --can_adapter=candlelight (or gs_usb).
--can_channel picks the adapter when several are plugged in (1 = first,
empty = 1). It uses Windows' own WinUSB, so no vendor DLL ships with it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The TC number is the TC NAME's function instance + 1 (ISO 11783-10), and
was fixed at TC #1. Add a tcNumber setting (1-32, default 1) so the TC can
run as TC #2 or higher next to a tractor's own TC. Out-of-range values fall
back to 1. It is part of the NAME, so it takes effect after a restart.
The TECU keeps function instance 0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
setup_tecu_interfaces() said a secondary waits, but plan_tecu_messages() with
no knowledge of the other Tractor ECUs answers "send everything". A secondary
doubled the messages of the tractor for up to 2.5 s after claiming an address,
which ISO 11783-9 4.4.2.1 c forbids. Start from an empty plan instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ISO 11783-7 B.1 lists Time/Date as "on request", so the TECU answers requests
and never sends it unrequested. The answer is UTC from the PC clock plus the
local offset, which now includes daylight saving time.

It follows the TECU plan: the primary always answers, and a secondary only when
no lower Tractor ECU advertises or sends Time/Date (ISO 11783-9 4.4.2.1). The
facility bit in PGN 65033 follows the same state. Time/Date seen from another
Tractor ECU counts for 30 s rather than 3 s, because it may only appear on request.

The answer lives in TractorFacilities' PGN request handling rather than in
TimeDateInterface: that registers a global receive callback, which the stack
can still call once after the TECU is rebuilt.

Replaces the on-request half of #87, without its 10 s broadcast.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gunicsba and others added 10 commits November 8, 2026 20:06
…-integration

# Conflicts:
#	src/udp_connections.cpp
…ration

# Conflicts:
#	include/app.hpp
#	src/app.cpp
# Conflicts:
#	docs/PROTOCOL.md
#	include/app.hpp
#	include/task_controller.hpp
#	src/app.cpp
#	src/task_controller.cpp
Text merges kept two definitions of send_gnss_quality(), and two PGN 0xF3
branches from #102 and #84, where the second could never run. One branch now
registers the field for the guidance track code and applies section control
on field open.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PR #84 also adds a PGN 0xF3 branch to this if/else chain, between 0xF1 and
0xF2. In different places, the two merge without a conflict and the second
never runs. In the same place, Git reports the conflict. No behaviour change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…egration

# Conflicts:
#	docs/PROTOCOL.md
#	src/app.cpp
@gunicsba

gunicsba commented Nov 8, 2026

Copy link
Copy Markdown
Contributor Author

Test plan

You don't need to test everything. Start with 1. Basics, then pick the sections that match your tractor and implement. The quoted text is what appears in the log, so you can search for it.

For every test, please note: tractor and implement model, whether the tractor has its own TECU, the tecuEnabled value, the AgOpenGPS version, and roughly what time the problem happened. Attach the log. A CAN trace (PCAN-View, SavvyCAN) helps a lot if you can record one.

Reading a CAN trace: in a 29-bit ID like 0CFE49F0, the middle four digits are the message (FE49) and the last two are the sender (F0). The first two digits vary, so ignore them.

Normal, not a bug: for the first 6.5 s after the TC starts, implements can't connect. The log shows Holding TC Status for 6500 ms (startup), then Quiet period over, sending TC Status again. This is deliberate, see section 4.


1. Basics (#120 AgIsoStack update): everyone, please

This update touches address claiming, VT handling and threading, so normal use is the real test.

Do this Expect Report if
Start the TC with the implement connected It connects, uploads its object pool and appears in AgOpenGPS with the right section count Connection loops, or the pool upload never finishes
Open the VT screens All pages draw, and speed and status update Blank or garbled pages, or the VT keeps reconnecting
Turn the VT or tractor off and on, or unplug the implement and plug it back in Everything reconnects without restarting the TC. Unplugging shows Implement lost: on the VT The TC crashes or needs a restart, or an implement is reported lost while still connected
Work for an hour or more Sections and speed stay steady Crashes, freezes, sections dropping out, or the log growing very fast

2. Second TECU (#118): tractors with and without their own TECU

Changing tecuEnabled needs a TC restart.

A. Tractor has its own TECU, tecuEnabled off (the most important case)

  1. Start the TC, and look in the log for Tractor ECU already on the bus.
  2. Then Requested tractor facilities (PGN 65033), then either The other Tractor ECUs reported their facilities or Not every Tractor ECU answered PGN 65033; going by what they send.
  3. Then one Sending ...: no other Tractor ECU provides it line for each message the tractor doesn't provide. A message with no such line was left to the tractor.
  4. In a CAN trace, check that none of these come from two senders: FE48 wheel speed, FE49 ground speed, F022 machine selected speed, FEE8 vehicle direction/speed, F802 COG/SOG. Check the first few seconds after start too.

Report if: any of those comes from both the tractor and the TC, the implement's speed jumps around, or the tractor shows new errors.

B. Tractor has no TECU, tecuEnabled on: the TC takes address 240 (F0) and sends everything. No "stepping down" line should appear.

C. Tractor has no TECU, tecuEnabled off: after 1 to 2.5 s you get a Sending line for every message.

D. Stepping down (tecuEnabled on): start the TC first, then power up the tractor's TECU. Expect stepping down to a secondary Tractor ECU and "Tractor ECU found: AOG adds only missing data" on the VT. Speed at the implement shouldn't drop to zero.

E. The tractor's TECU goes away (if you can do this safely): expect The Tractor ECU at ... left the bus, then Sending lines within a few seconds.

Always report: TECU failed to claim an address.

3. Section control switches on by itself (#102)

Do this Expect in the log Report if
Connect an implement About 2 s after its pool is activated: Applying initial section control state: enabled. The implement goes to automatic without pressing the SC button It stays in manual
Close and open a field in AgOpenGPS AOG opened field '...': switching section control on It stays in manual after a field change
Press AgOpenGPS's SC button off, then on The implement follows, as before The button no longer works, or section control switches itself back on
Set the operator's switch on the implement to manual The implement stays in manual until the next connect or field open The TC fights the operator
Set sectionControlOnConnect and sectionControlOnFieldOpen to false It goes back to the old behaviour: press the button yourself It still switches on

4. Reconnect after a TC restart (#105)

  1. With the implement connected and working, restart the TC (close and start it from AgIO).
  2. Expect the 6.5 s pause, then the implement reconnects and sections work again without power-cycling it.

If an implement keeps talking without having reconnected, the log shows is talking to us as if connected and the VT shows "Reconnecting implement". This can repeat up to 3 times, 30 s apart.

Report if: the log repeats NACKing process data command, the VT shows "Implement not reconnecting: power-cycle it", or sections stay dead after a restart.

5. UDP and log noise (#107, #98)

  • Sections and speed from AgOpenGPS stay smooth, with no missed section changes.
  • Truncated AOG packet or Unknown start of message lines should be rare. The second one should appear once per packet, not twice. Please report what's after it if you see many.
  • If devices on the bus send invalid transport messages, you get one summary line a minute (Ignored N Request to Send message(s)...) instead of a warning for each one.
  • The tractor's own TECU shows Non-section client: instead of No supported section control method detected. If an implement with sections gets either of those, please report it.

6. Tractor Facilities and Time/Date (#82, #122)

  • Facilities: expect [TractorFacilities] Sent PGN 65033 (power-up). As the main TECU the bytes are 0x6 0x0 0xf8 0x0 0x4 0x0 0x0 0x0. As a second TECU they should list only what it adds.
  • Time/Date: the TC should never send FEE6 by itself, so a trace should be silent unless something asks. When something does, the log shows Answering requests for PGN 65254 once.
  • If nothing on your bus asks, you can send a global request from a CAN tool: ID 18EAFFFA, data E6 FE 00. We've only read through this path in the code, so tell us if there's no answer.
  • Checking the answer: the bytes are seconds×4, minutes, hours (UTC), month, day×4, year−1985, then minute offset+125 and hour offset+125. In Central Europe the last byte is 7E (+1 h) in winter and 7F (+2 h) in summer.
  • With a tractor TECU that provides Time/Date, the TC must stay silent.

7. Guidance track data and track control (#84, #85): TRACK-capable implement only

Needs AgOpenGPS built from AgOpenGPS-Official/AgOpenGPS#1218. Without it, the "Track state" line on the VT stays OFF.

Do this Expect Report if
Open a field Field opened: NAME (index N). Reopening the same field gives the same index The index changes for the same field
Connect the implement Mapped DDI 507 to 513 lines for what it declares. declared but not settable means that one isn't sent, which is fine Expected DDIs are missing
Select an AB line or curve The VT status page shows Track state ref:... track:... It stays OFF
Drive across passes, including a U-turn The track number follows the pass; the implement agrees on the left and right neighbours Wrong number or left and right swapped
Switch to another guidance line ref changes ref stays the same
Close the field or turn guidance off Track data stops, and Track state goes back to OFF Old track data keeps being sent
Connect, level negotiation Implement reports supported track control levels=, Wrote track control level 1, Implement confirmed track control level 1 — negotiation complete. The VT shows Track levels L1 no common level on an implement that supports Level 1
Press Auto on and off in AgOpenGPS Track control state=On / Off, and the implement follows The implement doesn't follow

An implement without TRACK should behave exactly as before.

8. Only if it applies to you

  • candleLight adapter (Add the candleLight/gs_usb adapter option on Windows #121): start the TC from the command line with --can_adapter=candlelight. The adapter has to appear in Device Manager under "Universal Serial Bus devices". Then repeat section 1. No candleLight/gs_usb WinUSB device found means the adapter wasn't found or isn't using WinUSB.
  • TC number (Make the TC number configurable, with automatic selection #123), for a tractor with its own TC: set "tcNumber": 2 in settings.json and restart. The log shows Creating Task Controller control function (TC number 2). The implement should offer or connect to TC 2, and "Identify TC" shows === TC NUMBER 2 IDENTIFIED === in the log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant