Skip to content

Cut log noise: duplicate UDP warnings, global-destination RTS, non-section clients - #98

Open
gunicsba wants to merge 2 commits into
developfrom
fix/log-noise-and-non-section-clients
Open

gunicsba wants to merge 2 commits into
developfrom
fix/log-noise-and-non-section-clients

Conversation

@gunicsba

Copy link
Copy Markdown
Contributor

Refs #97

Problem

Logs from a John Deere 6R (#97) were dominated by three messages that either repeat or point at a problem that isn't there:

  • Unknown start of message: 0x.... printed twice per packet, with nothing to identify the sender.
  • [TP]: Received a Request to Send (RTS) message with a global destination, ignoring printed as a warning for every frame, with no source address. Some devices on the tractor send these continuously.
  • WARNING: No supported section control method detected! printed for the tractor's own TECU, whose DDOP only describes hitch/GNSS geometry and has no sections at all.

Cause

  • Both UDP sockets listen on port 8888, one bound to the AOG subnet address and one to all interfaces, so every broadcast is received and parsed twice.
  • The RTS message comes from AgIsoStack++ (can_transport_protocol.cpp), which doesn't include the sender.
  • The section control method check ran for every client, including ones with zero section elements.

Fix

  • UDP: UdpConnections::log_unknown_start() logs the sender IP:port and up to 16 bytes in hex. It skips an identical report (same sender and bytes) within 50 ms, so the second socket's copy is dropped while genuinely repeated packets (AOG sends at ~10 Hz) are still logged.
  • RTS: the CAN stack log sink (logging.cpp) treats that exact message as Debug. The application counts global-destination RTS frames (TP.CM, PF 0xEC, destination 0xFF, control byte 16) per source address from CANHardwareInterface's frame-received event, and once a minute logs one summary line when there were any, e.g. Ignored 120 Request to Send message(s) with a global destination in the last minute, from source address(es) 0x26 (120).
  • Non-section clients: in MyTCServer::activate_object_pool(), a DDOP with zero sections now logs Non-section client: the DDOP has no section elements, section control not applicable. at info level. DDOPs that do have sections but no supported method still get the warning.

No behaviour changes beyond logging.

Testing

Built with MSVC (Windows) against the current AgIsoStack++ pin; all 6 ctest tests pass. Not yet run on the tractor. The same changes are part of the 2.0.0-beta.2 test build going on the 6R on 29 Sep.

🤖 Generated with Claude Code

gunicsba and others added 2 commits September 28, 2026 23:01
"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>
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