John Deere agricultural vehicles, such as this modern tractor, utilize J1939 CAN networks for critical systems. These in-vehicle networks carry engine, transmission, hydraulic, and safety data, and are designed to be robust and reliable. John Deere’s implementation of J1939 is closed and tightly controlled, reflecting the company’s emphasis on safety, performance, and proprietary technology.
J1939 in John Deere Machinery – A Closed, Mission-Critical Network
John Deere equipment (from tractors to construction machinery) conforms to the SAE J1939 standard for its internal CAN-bus communications. J1939 defines a 29-bit extended identifier format and standard messages (PGNs) for heavy-duty vehicle data, and John Deere uses this extended CAN protocol for networking its ECUs (electronic control units). Typical J1939 networks connect numerous controllers – engine, transmission, implements, brakes, dashboards, etc. – all sharing a common bus. These networks are mission-critical, meaning they handle essential real-time control and safety functions. As one diesel industry source notes, a J1939 bus is critical for communication between various ECUs (engine, transmission, ABS, body control modules, etc.) – if the network has issues, it can lead to major malfunctions. Because of this criticality, John Deere’s J1939 networks are heavily validated during development and are not intended to be modified or extended by end users. In practice, the set of nodes (devices) on the bus is fixed to what the machine was designed with, and any “unexpected” node or message on the network is not part of the tested configuration.
John Deere’s J1939 networks are often described as closed or proprietary systems. In theory J1939 is an open standard, but John Deere (like many OEMs) uses the standard in a closed manner, by controlling the information and access. For example, while basic engine parameters might use standard J1939 PGNs and Suspect Parameter Numbers (SPNs), John Deere also utilizes proprietary PGNs (in the ranges reserved for manufacturer-specific messages) for many functions. These proprietary messages and their meanings are not publicly documented by John Deere. Only authorized service tools (like John Deere’s Service Advisor software) have full knowledge of the available data and the ability to interpret or interact with it. In fact, John Deere technicians are provided with lists of J1939 parameters and codes accessible via Service Advisor, but such information isn’t shared with third-party scan tools or the public. This “closed” approach is partly commercial (to lock repairs and analysis to Deere’s ecosystem) and partly safety-driven (to prevent unvalidated interference). It reflects a broader industry trend: manufacturers leverage J1939 for interoperability, but also increasingly employ proprietary extensions and security measures to maintain control.
Because the network is so central to machine operation, John Deere is highly protective of it. The company designs the CAN bus system such that only approved devices and messages appear. ECUs on the network expect certain data at specific intervals; missing or malformed data triggers fault codes, and extraneous data could do the same. The system may be “intolerant of unexpected nodes,” meaning if an unauthorized device starts transmitting on the bus, it can confuse or overwhelm the ECUs. For instance, adding a new node could violate the J1939 network design rules (too many nodes, long stubs, etc.) and cause communication errors. Even if the wiring is correct, a rogue device might attempt an address claim or send unintended messages. J1939 includes an address claiming protocol where each node must have a unique address (0–253). If a foreign node claims an address that conflicts with an existing ECU, it can cause an address conflict and bus disruption. Likewise, if it sends out periodic messages or requests that the John Deere controllers don’t recognize, the controllers might log diagnostic trouble codes or enter a safe state. In essence, the network’s reliability comes from knowing exactly which nodes and messages are present – any deviation is a risk. John Deere’s internal validation of the network likely assumes no unapproved nodes, so an unexpected CAN device could produce unpredictable behavior or at least nuisance fault alerts. This is why anyone attempting to interface with a John Deere J1939 bus must do so with great care (or preferably, in a strictly listen-only capacity, as discussed below).
Challenges of Unauthorized Devices on the CAN Bus
From an engineering perspective, introducing a new device onto a John Deere CAN/J1939 bus raises several challenges and risks.
Physical and Electrical Considerations: J1939 uses a two-wire differential bus (CAN-High and CAN-Low) with 120 Ω terminations at each end of the backbone. Adding a node improperly (e.g. using a long stub or adding a third termination resistor) can degrade signal integrity and cause reflection or errors. John Deere’s networks are typically built with the proper termination and up to some maximum number of nodes (often far less than the J1939 max of 30 nodes). An unauthorized tap must therefore avoid altering the electrical characteristics of the bus. In practice, this means using the existing diagnostic connector or splicing in with a high-impedance connection that does not add a termination. Modern CAN interface tools or data loggers are designed to present a high impedance when in listen-only mode, minimizing their load on the bus.
Address Claim and Network Management: If a new device actively participates on the bus, it must have an address and go through the J1939 address claim process. This is problematic on a closed OEM network. All John Deere ECU addresses are likely pre-defined; a foreign device might initially default to an address that conflicts with a John Deere module (for example, address 0 is typically the Engine #1 ECU). A conflict triggers an address negotiation per J1939-81, potentially resulting in the new device being forced to another address or causing log errors. Even without a conflict, the very presence of a new source address that the other controllers are not programmed to expect could be flagged as a fault. In some cases, ECUs might ignore messages from unknown sources, but many will still notice an unexpected address during the Network Management process (J1939/81) and could record a diagnostic code. For instance, construction and farm machines often have DTCs like “J1939 network error – unexpected device” or similar if something abnormal is detected on the CAN. This intolerance is by design: it ensures that only trusted, tested components communicate on the bus.
Data Collisions and Overload: Another concern is bus loading. The J1939 bus runs typically at 250 kbps (John Deere commonly uses 250k baud on primary vehicle networks) and carries a lot of periodic traffic (engine data, etc.). If a poorly configured device floods the bus or even increases traffic significantly, it can upset timing. J1939 operates at up to ~30% bus load in many vehicles; adding extra messages can increase latency or cause CAN errors if the bus gets too busy. The TAT Express guide notes that too many nodes or excessive messages can overwhelm a J1939 network. John Deere’s own modules are carefully scheduled to avoid this – a random device might not be. This risk is another reason John Deere doesn’t want unapproved CAN transmitters on their network.
Given these challenges, the safest way to observe or monitor a John Deere J1939 network is to avoid active participation altogether. This is where passive monitoring and silent mode come in.
Passive Monitoring via CAN “Silent Mode”
To non-invasively monitor J1939 traffic on a John Deere machine, engineers use CAN bus silent mode (listen-only mode) on their interface tool. In silent mode, the interface’s CAN controller is configured not to transmit anything on the bus – it will not send any messages, not even the usual acknowledgment (ACK) bits that CAN hardware normally injects for each frame received. Essentially, the device becomes an invisible sniffer: it can read all the data on the network, but other ECUs have no indication that it’s there.
Enabling silent mode typically means: (1) The node does not acknowledge CAN frames on the bus. (In CAN, every receiver is supposed to pull the ACK slot dominant to signal a good frame; a silent node stays recessive. As long as at least one other ECU on the bus acks – which is the case in any healthy multi-ECU network – the transmitter will never miss the silent node’s ACK.) (2) The node sends no data frames or error frames at all. It only listens. From the perspective of the John Deere vehicle, such a listener might as well not exist – it doesn’t take an address, doesn’t show up in any address claim, and doesn’t put any load on the bus except a tiny capacitive presence on the lines.
In practice, using silent mode is the standard solution for passive CAN bus monitoring. Many commercial CAN adapters and loggers support a listen-only mode explicitly because it’s needed for safe monitoring and diagnostics. For example, a development engineer or a diagnostic laptop can connect to the machine’s J1939 port in listen-only mode to record data without risking interference. On a John Deere, one would typically connect via the diagnostic connector provided. Most heavy-duty and off-road vehicles use a round Deutsch connector (6-pin or 9-pin) for J1939/CAN diagnostics. John Deere equipment often has such a port (for Service Advisor connection) located in the cab or on the machine’s harness. By plugging a CAN logger or interface into this port and setting it to silent mode, you gain access to all J1939 messages on the bus silently. Physically, the diagnostic connector is wired as a drop line to the CAN bus, with power and ground available as well. Using the connector is preferred over splicing wires, as it’s already designed not to disturb the network (the stub length and termination are accounted for in the system design).
Silent Mode in Action: Because John Deere machines have multiple ECUs active, running your interface in silent mode will still allow all normal communications to take place (other ECUs provide the ACK signals that keep CAN transmissions flowing). You can thus capture the ongoing data exchange in real time. However, if you attempted to communicate with only a single John Deere ECU on a bench in silent mode, you’d encounter a known issue: with only one active node and one silent node, the active node’s transmissions get no ACK and will fail. In a live machine, this is not a concern – there are plenty of active controllers to acknowledge each other’s messages. The key point is that the silent logger remains invisible and non-intrusive. John Deere’s ECUs will continue to talk as if nothing has changed. In fact, silent/listen-only monitoring is considered best practice whenever tapping into a CAN bus for diagnostics, especially on a mission-critical network where you cannot afford to accidentally inject anything.
Practical Setup: To monitor J1939 traffic on a Deere machine, one would configure their CAN hardware for 29-bit ID and the correct baud rate (usually 250 kbps on the primary bus). If unsure, silent mode can also help determine the baud by observing traffic (many tools can auto-detect CAN baud by listening for valid frames). Once connected, you’ll see a stream of CAN frames with 29-bit identifiers. These identifiers contain the J1939 Parameter Group Numbers (PGNs), source addresses, and priority bits. An engineer-level approach is to log all frames to a file or live decode key parameters. For example, you might capture messages like 0x0CF00400, which (when interpreted per J1939) is PGN 0xF004 from source address 0 – this is the standard Engine Speed message (Electronic Engine Controller 1 transmitting engine RPM). In fact, researchers have found John Deere engine messages often match standard J1939 definitions – e.g. the bytes in PGN 0x0CF00400 correspond to engine speed, and they line up with the expected RPM values when the tractor is at idle or throttle. Many core PGNs like engine temperature, fuel rate, etc., adhere to J1939-71 standard assignments in John Deere’s implementation, which means a knowledgeable engineer can decode them with publicly available J1939 reference material.
By passively monitoring, one can gather a wealth of data: engine performance metrics, hydraulic pressures, sensor readings, fault codes broadcast via J1939 (e.g. Diagnostic Trouble Codes come through DM1 messages), and more. Crucially, all this is obtained without altering the machine’s behavior, so it does not violate the machine’s operational integrity. In summary, using silent mode is the solution for safely tapping John Deere’s CAN network – it lets you eavesdrop on the data while remaining effectively invisible to the system.
Limitations and Practical Problems of Passive Sniffing
While passive monitoring in silent mode avoids interfering with the J1939 network, it comes with trade-offs and challenges:
-
Read-Only Access (No Commands or Requests): You are limited to observing the data that the John Deere system already puts on the bus. J1939 traffic is a mix of broadcast messages (sent periodically by ECUs without prompting) and on-request data (sent only when requested by another node). In silent mode, your tool cannot send any request messages to ask for specific info. For example, if you want to retrieve diagnostic trouble codes or certain configuration parameters, normally you would send a request PGN (e.g. DM2 for stored codes). A silent logger cannot initiate such requests, so you might miss that data unless the machine itself broadcasts it periodically. In other words, passive monitoring gives you insight into what the machine naturally communicates, but not into data that require active polling. This is a key limitation – you can log engine and transmission broadcasts (speeds, temperatures, etc.) easily, but something like forcing a regeneration cycle or querying a specific sensor’s status is off-limits without active commands.
-
Interpreting Proprietary Data: As mentioned, John Deere uses proprietary PGNs for many machine-specific functions. When you sniff the bus, you will likely see messages with PGN IDs in the proprietary range (0x00FF00 to 0x00FFFF are reserved for OEM use). The content of these messages is not defined in the public SAE standard. Decoding them requires reverse engineering or access to John Deere’s documentation. For an engineer, this can be a significant hurdle – you might have raw hex data but not know what it represents. Efforts like the Cal Poly TractorHacking project have used techniques to decipher proprietary messages (for instance, unplugging sensors and observing which messages disappear or which new fault messages appear). Over time you might build a lookup table of what certain PGNs mean. However, this reverse-engineering is time-consuming and not guaranteed to cover everything. John Deere’s own technicians rely on the Service Advisor software which has the proprietary definitions built-in, giving them an advantage. So, one downfall of unauthorized monitoring is the lack of official support to interpret all the data – you can collect it, but making sense of every parameter can be challenging.
-
Data Volume and Logging Challenges: J1939 networks can be chatty. A modern tractor or combine can easily produce dozens of messages every 20 milliseconds or so from various ECUs. Logging this high-speed data over hours can generate very large datasets. Ensuring your logging tool or laptop can keep up with the bus traffic is important – losing messages could omit critical clues. The TractorHacking team initially found that using a standard oscilloscope to capture CAN was impractical due to the sheer volume of data (their first attempt saved only 1.4 seconds of bus traffic into a 0.25 GB file!). They had to obtain a more capable logging setup to capture longer sessions. In an engineering context, one might use a dedicated CAN logger device with filtering capabilities to reduce data (e.g. log only specific PGNs of interest) or ensure real-time processing to pull out key metrics. Additionally, analyzing the data post-capture requires tools to translate raw CAN frames into human-readable values (which might involve writing custom decoding scripts or using CAN database files if available). Without John Deere’s proprietary DBC (CAN database) files, an engineer may need to create their own. This is doable for standard J1939 stuff (since SAE publishes PGN/SPN definitions), but again problematic for custom Deere messages.
-
Stealth and Detection: One theoretical concern a user might have is whether John Deere can detect that you’ve attached a logger. In silent mode, the device does not announce itself at all, so real-time detection on the bus is effectively impossible – the ECUs don’t “see” the sniffer. As long as the logger truly remains silent (no inadvertent frames transmitted), the only way it could be noticed is if someone physically spots the hardware or if it inadvertently disturbs the bus electrically (which a well-designed interface will not). Thus, the act of monitoring does not interfere with operation and should not trigger any alerts. This means from a pure operation standpoint, passive monitoring is safe. However, one should still be cautious: ensure the interface stays in silent mode (misconfiguration could accidentally send something), and be mindful of electrical safety (hot-plugging into the CAN connector could momentarily cause a voltage spike if done improperly, etc., so best practice is to power down or use proper connectors).
-
Warranty and Support Risks: Though not a technical limitation per se, using any unofficial device on the CAN bus might be viewed by John Deere as a form of tampering. Even if you only listen, if it’s discovered (say you leave the logger in place and a dealer sees it), it could affect your warranty or service relationship. John Deere has historically been strict about unauthorized access – it’s part of their business model to require that diagnostics and modifications go through official channels. So an engineer doing passive monitoring should be aware of the political risk: if data from your monitoring leads you to modify the machine or if Deere finds out you’ve been snooping on the network, they may not look kindly on it. There’s no direct CAN-bus way for them to know you listened, but any resulting changes or published findings could raise flags.
Despite these issues, passive monitoring remains incredibly useful. It allows independent engineers or researchers to gather performance data and potentially identify areas for improvement (e.g. analyzing engine load vs. fuel use to improve efficiency, or detecting suboptimal behavior in hydraulics). It’s essentially the only safe way to get insight from the machine’s nervous system without John Deere’s involvement. You just have to accept that you’re observing in the dark to some extent – you see the what, but figuring out the “what exactly does this byte mean” might require extra work.
John Deere’s Protective Stance and the Right-to-Repair Debate
John Deere’s business and security policies strongly discourage – and until recently, outright prevented – owners or third-party engineers from accessing the machine’s electronic networks. The company’s position has been that the software running on the tractor (and by extension the data on the CAN bus) is not fully owned by the equipment owner. Deere has argued that when you buy a machine, you receive an “implied license” to use the software, but you do not have the right to tamper with or access it freely. To enforce this, Deere implemented both technical and legal barriers:
-
Technical Protection Measures: John Deere employs software locks and encryption in its ECUs to prevent unauthorized changes. Many critical functions on the CAN bus (like reprogramming an ECU or calibrating a new part) are password-protected or cryptographically secured. For example, if an important controller is replaced or altered, the system requires an authorization via the Service Advisor tool to “pair” the new part to the machine on the CAN bus. Without this electronic pairing, the new component may not function or the machine may remain in a fault mode. This is a deliberate design to force repairs through authorized channels. The company also uses proprietary protocols on top of J1939 for certain diagnostics. In effect, even though you might physically connect to the bus, you can’t perform tasks like resetting a fault code or tuning the engine without the digital keys that John Deere controls. These are examples of TPMs (technological protection measures) intended to prevent unauthorized access or modification of the machine’s electronic systems.
-
Legal Measures: John Deere was a notable player in invoking the Digital Millennium Copyright Act (DMCA)to protect its software. They contended that the firmware and code on the tractor are copyrighted, and any circumvention of protections (like hacking the ECU to modify it or extract data) was illegal. Around 2015, Deere famously filed comments against proposed DMCA exemptions for vehicle software, effectively saying that owners or independent technicians should not be allowed to circumvent encryption/DRM to repair or modify tractors. They likened modifications to copyright infringement. John Deere also tied this to safety and regulatory compliance – arguing that letting people tinker could lead to malfunctioning machines or emissions cheating. This stance created a “massive resistance” to independent access: farmers and hackers who tried to access the CAN bus or modify software risked legal action. There were reports of farmers resorting to black-market Eastern European firmware hacks to bypass John Deere locks on their tractors. That practice, while prevalent, was technically illegal before 2015. However, a coalition of farmers and digital rights advocates fought back. In 2015, the U.S. Copyright Office granted a DMCA exemption allowing vehicle owners to circumvent TPMs for the purposes of lawful diagnosis and repair on land vehicles. This meant tractor owners could legally attempt to access the software to fix their equipment. In 2018, this was further extended to permit third-party technicians to do the same. Material like the TractorHacking project explicitly falls under this exemption, which protects their reverse-engineering work from DMCA lawsuits.
Despite these legal wins for the Right-to-Repair movement, John Deere remained reticent. The company did not immediately start sharing its CAN bus documentation or tools. Instead, Deere has been slowly pressured into concessions. For example, in 2023 John Deere entered into a memorandum with the American Farm Bureau, promising to make diagnostic tools and manuals more available to farmers (allowing access to codes and read-outs) – but even that agreement maintains that Deere retains ownership of the software and does not allow full unrestricted modification. In essence, John Deere is walking a line: providing some access to appease regulators and avoid new laws, but still keeping tight control over the deeper capabilities. As a result, independent engineers interested in data monitoring must often fend for themselves using generic CAN tools and their own expertise.
John Deere’s primary justifications for limiting access to the J1939 network are safety, liability, regulatory compliance, and business advantage. On the safety front, they argue that an improperly modified ECU or a rogue message on the bus could cause equipment to behave dangerously (imagine brakes not engaging or engine overspeed due to a bad command). There is truth in the critical nature of these networks – hence the importance of not injecting messages if you’re not absolutely sure what you’re doing. Legally, emissions control is a big factor too: modern Deere engines must meet EPA standards, and manufacturers are required to implement tamper-resistant design. Allowing open access could let users disable emissions systems or increase horsepower beyond legal limits, which Deere wants to prevent (both to comply with law and to protect their engines from damage). On the business side, Deere’s restrictive policies funnel owners into dealer service for anything beyond basic repairs, which is lucrative. By controlling the CAN bus and associated software, Deere monopolizes advanced diagnostics and performance tuning. An antitrust lawsuitwas even filed (and consolidated in 2022) accusing Deere of illegally monopolizing the repair market through these tactics.
For an engineer or farmer, the upside of this protectionism is hard to see – it mostly means you lack access to your machine’s full capabilities. However, mere monitoring of J1939 data is generally not prohibited by any specific law now (thanks to Right-to-Repair progress). If done passively, it doesn’t violate the machine’s integrity or safety. John Deere may not like an independent analyst snooping the network, but there’s little they can do as long as that person isn’t altering the machine or distributing Deere’s proprietary code. In fact, data logging for the purpose of analysis and improvement can be seen as an exercise of the owner’s rights under the DMCA exemption (for diagnosis) and general property ownership. Still, Deere’s “massive resistance” means you won’t get any help from them – no official data streams, no support if something goes wrong, and possibly warranty voidance if you cross the line into active tweaks.
To illustrate Deere’s attitude: in a comment to regulators, the company explicitly said owners do not really own the software and thus shouldn’t access it, and only Deere’s authorized technicians should touch the CAN-based systems. They implemented digital locks on virtually every replaceable part of the tractor, such that even swapping a part often requires dealer software to make it work. This approach essentially forbids any unauthorized engineer from plugging into the network and changing things. However, plugging in just to listen is a gray area – it doesn’t alter software, so arguably it isn’t “circumventing” in the way DMCA anti-circumvention was meant. Still, Deere’s user agreements (or at least their public stance) might say that connecting non-Deere equipment to the system is not allowed. It becomes more a contractual or policy issue than a technical one when you’re simply monitoring.
Regulatory and Legal Considerations
From a regulatory standpoint, passive monitoring is generally permissible. The DMCA exemptions explicitly allow circumvention of TPMs for diagnostics on vehicles, which covers activities like accessing the CAN bus for analysis. Additionally, right-to-repair laws emerging in some jurisdictions (e.g. a 2023 Colorado law for farm equipment) mandate manufacturers to provide diagnostic information to owners. This is pushing companies like John Deere to at least tolerate owners hooking up tools for reading data. Where one must be careful is going beyond monitoring to modification. If an engineer uses the data gleaned from J1939 to then implement a performance tune (for instance, altering fuel maps to improve power or efficiency), that crosses into active tampering. Not only would that violate Deere’s policies and likely void warranties, it could also breach environmental regulations (if it affects emissions) and safety laws. So, while monitoring itself is non-intrusive and now legally protected, any use of the data to change how the machine operates must be done with caution and probably only in jurisdictions that permit such modifications (for example, in the U.S., tampering with emissions control is illegal federally).
Another consideration is data privacy/ownership. Modern John Deere machines often have telematics – they send data back to Deere or the dealer (e.g. through JDLink). Deere’s terms might claim ownership of operational data or restrict how it’s used. If an engineer collects J1939 data to analyze machine performance, technically it’s data coming from the owner’s machine, so the owner should have rights to it. But Deere’s contracts sometimes muddy this area. It’s worth noting in a report that any engineer doing this on someone else’s Deere equipment should have that owner’s permission, and that publishing the data might raise Deere’s attention if it reveals proprietary info (like decoding a Deere proprietary PGN might be considered revealing Deere’s trade secret). These are edge cases, but part of the political landscape around who controls the data produced by the machine. The Right-to-Repair movement is actively arguing that owners should have full access to repair and usage data – and monitoring the CAN bus is a direct realization of that.
Conclusion
Monitoring the data traffic on a John Deere J1939 network is technically feasible and can be done in a completely passive way that does not interfere with machine operation. The recommended approach is to use silent mode on a CAN interface, effectively eavesdropping on the bus without introducing an active node. This allows engineers to gather valuable information on engine performance, sensor readings, and fault codes in real time. With engineering expertise, one can decode much of the standard J1939 messages (John Deere largely adheres to SAE standards for core engine/transmission data), although many manufacturer-specific messages will require reverse engineering.
However, there are important downsides and challenges to keep in mind. Passive logging means you can’t query anything new – you are limited to whatever the John Deere system is already communicating. Interpreting the data can be difficult when proprietary PGNs are involved, since John Deere does not share their full network specifications publicly. Moreover, John Deere has a history of staunchly opposing unauthorized access to their machine networks. Through software locks, legal threats, and dealership-only tools, they have made it clear that they do not welcome third-party tinkering. While simply listening to the network traffic doesn’t physically harm anything, it exists in a grey areaof John Deere’s policies. Owners and engineers must be aware that John Deere’s business politics prioritize control over the equipment’s digital ecosystem – any step towards independent analysis or modification is met with resistance, if not outright hostility, from the company’s side.
The good news for technically inclined users is that monitoring in silent mode sidesteps most of John Deere’s countermeasures. You’re not hacking the ECU firmware, not sending unauthorized commands – you’re just observing. This gives you a window into the machine’s behavior that John Deere would prefer you obtain only through their approved diagnostics. With persistence, one can use this window to make data-driven improvements (for instance, identifying inefficiencies or early warning signs of trouble). Just keep in mind that if you attempt to act on those insights by changing the machine, you’ll run up against John Deere’s locked-down architecture and possibly legal barriers.
In summary, John Deere J1939 networks are robust but closed control systems: they are engineered for reliability and safety, and thus do not tolerate unexpected nodes or messages well. Passive CAN bus monitoring (listen-only) is the safe technical method to study these networks. It avoids the pitfalls of causing errors on the mission-critical bus, letting an engineer gather data without detection. Yet, the act of monitoring exists in the shadow of John Deere’s broader fight against unauthorized access. Thanks to right-to-repair progress, simply listening is no longer illegal – but it remains unsupported and discouraged by Deere. An engineer undertaking such a project should be prepared for the technical challenges of decoding the data and the political challenge of operating outside the manufacturer’s comfort zone. With careful practice, one can navigate these challenges and tap into the rich stream of J1939 data to glean insights about John Deere machinery, all while keeping the tractor itself none the wiser.
Sources:
-
SAE J1939 standard fundamentals and John Deere’s use of 29-bit CAN IDs
-
Description of CAN bus silent (listen-only) mode for non-intrusive monitoring
-
Heavy-duty vehicle J1939 network criticality and topology (TAT Express Inc.)
-
CSS Electronics on right-to-repair vs. proprietary J1939 implementations
-
HeavyEquipmentForums: Deere tech on Service Advisor-only data access
-
Cydrill Security: John Deere’s DRM/DMCA approach to locking down tractor systems
-
Legal case filings: requirement of dealer software to authorize parts on CAN bus, Deere’s stance on software ownership
-
TractorHacking project notes on data collection and J1939 decoding in Deere tractors
Comments are closed.