AOG UDP Message Format Documentation?

Q: Is there a document that describes all the UDP message types that AOG sinks/sources? I’m looking for a pdf with packet identification, CRC algorithm, message parameter types and allowed values, endian, etc. and expected responses.

Backstory : newer AOG user here…
I’m looking to interface my custom hardware to AOG via UDP only (no CAN). This would be something like an operator button console for section control, autosteer engage, etc. I see there are a lot of great projects out there for this, but there doesn’t seem to be a source of UDP information. Clearly, we could reverse engineer the structure from hacking source code, but source isn’t documentation.

Is there some secret source of developer knowledge separate from the user-facing documentation?

Thanks all!

There’s an xls file in the support files but it’s usually not completely up to date

As said check for the “PGN 5.6.xlsx” in @SK21 s link.

Best is to “reverse engineer” from the inos.

You should be able to do this only by writing an .ino, no need to change AOG source code.

A lot of stuff on this forum. If you are lucky you will find something trough the search bar.

Thanks all!

The 5.6 version of the PGN file is a bit more clear than the 5.1 “stable” I was working with.
Observations:

  1. all the PGN’s in UDP are <8 bytes of data payload? I assume this is because of the history or choice to be compatible with CAN?
  2. All the UPD participants have to have a fixed IP address, or are the addresses in columns B, D, & E just examples?
  3. to get type data, limits, etc. the best definition is in the Arduino INO files.
  4. I’m guessing that “switch”, (byte 11) in PGN xFD would be the remote enable switch? If we wanted to send that switch state from a device other than the autosteering controller, how would that happen without having to send the other data elements and confusing AOG?

Thanks again, sorry for learning the AOG system while trying to solve this off-beat question! I’ll pick through source and comment back here to keep a running log. Maybe someone will find it useful in the future.