Mixed Fleet Farm Telematics: Why Your As Applied Maps Never Agree

Why a mixed fleet turns telematics into a data project

It is the third week of April and six machines are moving. Two planters run on JDLink and report into John Deere Operations Center. The tractor on the air seeder is a Case IH reporting into AFS Connect. The floater is on AGCO Fuse. The sprayer is a lease unit with a Trimble display driving a rate controller from a shortline manufacturer that speaks ISOBUS on a good day. Three grain carts have scales and no telemetry at all. Your agronomist asks one question: how many acres went in with which hybrid at which population, and what did each machine burn doing it. Answering takes two web portals, a USB stick with a TASKDATA.XML file pulled off a terminal, a photo of a display screen texted by an operator, and about forty minutes. By then the planting window has moved on and nobody asks again until the crop insurance paperwork is due.

The stack around this is always the same shape. Operations Center for the green iron, FieldView for the seeding and yield layer because the agronomy service wanted it, Trimble Ag Software left over from the guidance upgrade three years ago, a fuel card statement, the dealer's service portal for each brand, and a whiteboard in the shop. Each of those tools is competent at its own job. None of them can answer a question that crosses brands, because none of them was ever built to hold a competitor's machine as a first class object. Deere will not model your Case tractor properly. Climate will not model your shortline air cart's section control. That is not a bug in their products, it is their commercial position, and it is not going to change.

The cost of that gap is specific. Across precision ag builds we have delivered, the recurring pattern is a farm manager or precision specialist spending six to twelve hours a week exporting, converting, and re-drawing data so that one season summary exists. Field boundaries drift apart until the same 80 acre field is three different polygons with three different acreages, which means every per acre number downstream is wrong by a few percent in a direction nobody can track. Fault codes sit unread in a portal until a failure becomes a teardown instead of a planned service. And when the operation is asked to prove application records, whether for a sustainability program, a retailer contract, or a claim, the proof has to be rebuilt by hand from partial sources.

Problem 1: the same field is three different fields

Nothing joins because the join key does not exist. The home quarter is Home 80 in Operations Center, HM-80 in FieldView, and a slightly different polygon in the Trimble account because someone re-drove the boundary after the ditch was moved. Legal descriptions, FSA farm and tract numbers, and the names your operators actually say on the radio are four different naming systems, and no vendor owns the mapping between them.

What a custom build does: hold your own field registry as the single source of truth, keyed to FSA farm, tract, and field number where you have it, with the operator name and every brand's internal field id stored as aliases. Boundaries are versioned with an effective date, because a field genuinely changes when you take out a fence line, and last year's yield map belongs to last year's polygon. Incoming records from any brand get matched to your registry by geometry overlap first and name similarity second, and anything below your confidence threshold lands in a review queue rather than silently creating a fourth copy of the same field. This is unglamorous and it is the foundation. Skip it and every number built on top is negotiable.

Problem 2: task data arrives as ISOXML, proprietary API, and a USB stick

ISO 11783, the ISOBUS standard, defines the ISOXML task file format, and in principle any conformant terminal can write a TASKDATA.XML that any other system can read. In practice you get partial implementations, vendor extensions, product references that point at a product database on a display that has since been wiped, and setup files that only load if the terminal firmware matches. Meanwhile the connected machines push through their own cloud APIs with their own schemas and their own definitions of what a completed operation means.

ADAPT, the open toolkit maintained through AgGateway, exists precisely to normalise this, and it is the right starting point. It is also not a finished answer: plugin coverage varies by brand and by version, and the mapping of a shortline implement's section and rate data is frequently the part that is missing. This is where a real build spends its integration budget.

What a custom build does: one canonical operation record with machine, implement, product, target rate, applied rate, section states, and time, populated by whichever ingestion path is available for that machine. Connected brands come in by API on a schedule. Unconnected iron comes in by USB or by an operator uploading from a tablet, and the system tolerates that because pretending every machine will be connected is how these projects fail. Every record keeps its raw source file, so when a number is questioned in November you can show the bytes that produced it rather than arguing about a conversion.

Problem 3: fault codes go unread until the machine is down in the window

Every connected machine emits diagnostic trouble codes, and every brand's portal shows them in its own list that somebody would have to log into daily. Nobody does, because during planting nobody is logging into anything. So a derate warning on a sprayer that appeared on Tuesday becomes a shutdown on Friday afternoon with sixty acres left and rain coming.

For a dealer group the same problem runs the other way. You can see health data on machines you sold and connected, you cannot see the ones a customer bought at auction, and your service scheduling lives in the DMS with no link to the alert that should have triggered it. The service department finds out when the phone rings.

What a custom build does: normalise codes across brands into your own severity model, which you define by what actually strands a machine rather than by the manufacturer's classification, then route them. A critical code during a planting window pages the shop and creates a service record with the machine, hours, location, and the parts most commonly consumed for that code on that model. For a dealer group, the alert lands in the branch queue nearest the machine with a suggested slot, and the technician arrives with the part staged. Nothing here is exotic. It is routing plus a decent parts history, and it is worth more than any dashboard you will ever build.

Problem 4: nobody knows the real cost per acre by machine

You know what the fleet cost in total because the accountant tells you in February. You do not know what the eight year old tractor costs per hour against the leased unit, because fuel comes off a card statement, hours come from three portals, repairs come from the shop and from three dealer invoices, and none of them share a machine identifier. So replace or repair decisions are made on feel and on which salesman called last.

What a custom build does: one machine record with the serial number as the spine, carrying purchase or lease terms, hours and fuel from telematics, fuel card transactions matched by time and location, work orders and parts from the shop, and dealer invoices captured by document extraction so somebody is not typing them. Then cost per engine hour and cost per acre by machine and by operation become real numbers. This is the report that changes decisions: it is common to discover that the machine everyone complains about is fine and the expensive one is a well liked unit whose repair spend nobody had added up.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and for this category the honest shape is as follows. A first release covering the field registry, one or two brand API integrations, ISOXML ingestion through ADAPT, and a machine hours and fuel view runs $70,000 to $150,000 in 12 to 18 weeks. That is a working system your precision specialist uses daily, not a pilot. A full platform adding as applied verification against prescriptions, fault code routing into dealer service, warranty documentation, parts and work order history, and per acre machine costing runs $180,000 to $450,000 phased across 8 to 14 months.

What drives the price up in this category specifically: the number of distinct brands, because each OEM developer program has its own onboarding, its own data agreement, and its own consent model for machine data, and the paperwork is sometimes slower than the code. Shortline implements, because their data quality is the least predictable part of the fleet. Offline behaviour, because a tablet in a field with no signal has to queue and reconcile without duplicating records. Grain cart and scale integration if you want load level yield rather than combine estimates. And dealer DMS integration, which is its own project and priced separately for good reason.

What keeps the price down: starting with the two brands that cover most of your acres and one season's worth of operations. You will learn more from one clean planting season than from a specification document.

Build versus buy, and when buying is right

Do not build if you farm one color of iron, one entity, under roughly 5,000 acres. Operations Center is genuinely good inside the Deere ecosystem, it costs you nothing extra, and a custom layer would add work without adding an answer. The same applies if your data question is agronomic rather than operational: FieldView plus a good agronomist beats anything you would commission.

Build when at least two of these are true. You run three or more brands and the cross brand question is asked more than once a month. You farm across multiple entities or landlord arrangements where per field settlement matters and the acreage has to be defensible. You are a dealer group with more than three stores wanting one view of customer machine health, including iron you did not sell. Your fleet includes leased or custom hired machines whose hours drive real money. Or you are being asked to produce application records for a program or a contract and you currently rebuild them by hand.

The tipping point is not the size of the fleet, it is the number of boundaries the data has to cross. One brand and one entity is a product problem. Three brands, two entities, and a dealer relationship is an integration problem, and integration problems do not have vendors, they have owners.

How to choose a developer for agricultural telematics work

Ask them to explain, without looking it up, what a TASKDATA.XML contains and where ADAPT plugin coverage tends to break. If they have done this work they will immediately talk about product references and section control data. If they talk about generic REST integration you are paying for their education in ISOBUS.

Ask how they would reconcile three different boundaries for the same field. The right answer involves geometry overlap, a confidence threshold, a human review queue, and boundary versioning with effective dates. A developer who says they will just import the boundaries has not been through a season.

Ask who owns the code and the OEM data agreements, and get it in writing before kickoff. You should hold the repository, the cloud accounts, and the developer credentials with each manufacturer, because those relationships are yours and not your agency's. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from anyone who wants to hold either the repo or the API keys.