Skip to content

Agriculture

Introduction to the SAE J1939 Standard

In the early days of controller area networks (CAN), every device manufacturer interpreted CAN frames in its own proprietary way. When you changed the engine of a harvester from Volvo to MAN, you would have to reimplement the communication with the engine from scratch. Fendt tractors wouldn’t be able to communicate with John Deere implements and vice versa. The J1939 standard brought order into this Babylonian chaos and reduced the development efforts significantly.

Read More »Introduction to the SAE J1939 Standard

Detecting Overdraw in QML HMIs with GammaRay

Overdraw happens when one QML item fully eclipses another QML item. The QML renderer always draws both items, although there is no need to draw the eclipsed item. You must help out the renderer by explicitly setting visible: false on the eclipsed item.

On embedded systems, heavy overdraw makes animations or flicking jerky. In the worst case, it freezes your HMI. Fortunately, the Qt experts at KDAB developed a tool, GammaRay, which makes detecting overdraw a piece of cake. I’ll show you how to build GammaRay, how to detect overdraw in the home screen of a harvester HMI, and how to fix the overdraw.

Read More »Detecting Overdraw in QML HMIs with GammaRay

Speaking CAN: Write Buffer Overflow

In the first post of the Speaking CAN series, we learned how the terminal sends a read-parameter request to the ECU and how the ECU sends a response with the value of the parameter back to the terminal. This works fine, as long as the terminal does not send too many requests too fast.

We set the size txqueuelen of the write or TX buffer to 10, which is the default for many Yocto-based Linux systems. If the terminal writes, say, 50 requests to the CAN bus without any pause, we’ll see several error messages No buffer space available in the log window of the terminal. The terminal caused an overflow of the write buffer in the CAN controller.

If we have a request-and-response scenario, the terminal can wait for the response, before it sends the next request. If the response does not arrive within a certain time, the terminal flags an error.

Avoiding a write buffer overflow becomes more difficult, if the terminal sends out messages without expecting a response or if the terminal expects a response only every, say, 200 messages (e.g., an acknowledgement how many messages the ECU has received). The solution is to configure the CAN controller of the terminal to receive its own messages.

Read More »Speaking CAN: Write Buffer Overflow

Speaking CAN: Request and Response

Controller Area Networks (CANs, for short) are used for the communication between electronic control units (ECUs) in cars, trucks, tractors, harvesters, construction machines, packaging lines and e-bikes. Qt provides the Qt CAN Bus API as part of its QtSerialBus module. Qt CAN Bus provides a clean and simple API to connect to a CAN bus, to send and receive CAN frames over the CAN bus.

When we build an HMI application to control a machine, we need a lot more functionality than the Qt CAN Bus API should offer. The HMI application must not send CAN frames too fast to avoid buffer overflows in the CAN controller. When the HMI application receives, say, more than 200 CAN frames per second and tries to display the changes, it will freeze. The HMI application must be able to recover from CAN bus errors. We do not want to write the code for serialising and deserialising thousands of CAN messages manually, but want to generate this code automatically.

I’ll show solutions to these problems in a loose series of blog posts called Speaking CAN. In this first post, I’ll explain how an HMI application running on a display computer retrieves the value of a parameter from an ECU. The terminal sends a request to the ECU over CAN and receives a response from the ECU over CAN.

Read More »Speaking CAN: Request and Response

High-Speed-Data (HSD) Connectors in Heavy-Duty Vehicles

In a recent blog post, I suggested to replace multiple display computers in a driver cabin by one computer in a silver box with multiple displays. I didn’t specify which connectors and cables to use between computer and displays. I found the answer at Electronica 2018 last week: High-Speed-Data or HSD connectors. You can use HSD connectors for LVDS (including Display Port), APIX, CAN, USB 2.0, USB 3.0, Ethernet and Firewire.
Read More »High-Speed-Data (HSD) Connectors in Heavy-Duty Vehicles

What’s Wrong with Multiple Display Computers in Driver Cabins?

Three cabins with 2-4 display computers each.

Figure 1. Top left: Claas cabin with three terminals. Top right: Agco cabin with two terminals. Bottom: Continental concept cabin with four terminals.

The top row shows the status quo. Two or three display computers (a.k.a. terminals) are normal. Even four display computers are not unusual. The bottom row shows the cabin of the future with four display computers. The display computers at the left and right beam show the videos from the wing mirror cameras. The display computer in the middle is the instrument cluster. The small display computer on the right-hand side shows additional information. It would be bigger in a harvester.

Let us assume for simplicity that the cabin is equipped with two display computers, which have identical hardware and nearly identical software – except for the main application. When sourced from low-volume, high-customisation electronics manufacturing services (LVHC-EMS), the two display computers, the telematics unit and a switch will cost roughly 2750 Euros for 200 machines.

We will bring down the costs to 2350 Euros, if we replace the two display computers by one computer with two displays. The computer doesn’t have a display and the displays don’t have a computer inside. The telematics unit is folded into an M.2 or PCIe card, which is plugged into a slot of the computer.

We will reduce the costs by another 200 Euros to 2150 Euros, if we source the components from a value-added reseller (VAR) instead of an LVHC-EMS. VARs buy standard components from high-volume low-customisation EMSs (HVLC-EMS). They charge lower prices because of the higher volumes, but they allow only minimal customisations.

For 200 machines, the solution with one computer and two displays saves us 80,000 Euros and 120,000 Euros per year, respectively, when sourced from an LVHC-EMS and from a VAR. We save even more, if we replace more display computers by one computer with displays and if the display computers are more expensive like ISOBUS terminals. We do not only save costs on hardware but also on software, because we consolidate multiple diverse systems into one system.

A clever change of the system architecture leads to sizeable cost savings. It also leads to a system that can easily be extended in many directions – a competitive advantage.

Read More »What’s Wrong with Multiple Display Computers in Driver Cabins?

Connectivity Solutions Will Not Help with Autonomous Farming

Over the last two years, agricultural OEMs have been in a rush to get data from their machines to their cloud servers. Claas uses Proemion’s connectivity solution. Agco, Grimme, Krone and a few others bet on AgriRouter running on SAP’s cloud servers. Holmer seems to favour Bosch’s IoT suite. All these solutions have one thing in common: They transfer little data, typically less than 50 data points per second. They top out at 100 data points. They are good for task or order management, asset tracking, fleet management, monitoring of machine health and remote diagnosis.

At least some of these companies seem to think that these connectivity solutions will help them with driver-less or autonomous farming like harvesting, seeding, spraying or fertilising. The wishful thinking would go like this.

The farm machines transfer data to the cloud. The data is used to train machine learning algorithms on extremely powerful compute servers. The model, the result of the learning process, automagically detects whether grains are dirty, maize leaves are dry or the heads of sugar beets are chopped off. Typically, this model runs in the cloud as well, because it requires more compute power than is available on the farm machine or because it adapts to new conditions and self-optimises by continuous learning. This is the way how voice assistants like Alexa and Siri understand spoken language or how medical software recognises cancer cells in MRT scans.

This approach does not work for farm machines. Here is why and what we can do about it.
Read More »Connectivity Solutions Will Not Help with Autonomous Farming

Agritechnica 2017: What’s New for Terminals?

Agritechnica 2017 was my third visit after 2013 and 2015. My focus was on terminals (display computers) as usual.

The standard terminal of 2017 is powered by a quad-core NXP i.MX6 processor (32-bit ARM Cortex-A9 with ARMv7a architecture) and has an HD 12-inch multi-touch display (resolution: 1280×800, format: 16:10). The new ISOBUS terminal CCI 1200 manufactured by CrossControl is the prime example.

In 2013, there were only terminals with single-core Cortex-A8 processors (NXP i.MX53). In 2015, there was only the odd prototype terminal with a quad-core i.MX6 in 2015 (from Grammer Belgium) but no production-quality ones. In 2017, most terminals sport a quad-core i.MX6 (Cortex-A9) processor. The processing power of terminals increases very, very slowly.

Compare this to a typical processor used in today’s in-vehicle infotainment systems. For example, the Renesas R-Car M3 sports two Cortex-A57 and four Cortex-A53 cores (all 64-bit), which has the performance of low-end to mid-range desktop PCs. Agricultural terminals need this procesing power as well, if the agricultural industry is serious about autonomous seeding, spraying and harvesting.

CLAAS demonstrated a first step into this direction. A camera is trained on the crop flow. An image recognition software (most likely using machine learning) detects whether the grains are too dirty and whether there are foreign particles between the grains. The future will see more and more such software to deduce actions from sensor data.

These expensive computations must be performed onboard the machine, because the Internet connection is not good enough on the field to send the data to powerful servers and to perform the computations there. The most powerful computer on the machine is typically the terminal. Current terminals are not powerful enough for these computations.

One terminal stands out from the uniform, slightly boring bulk of 12-inch, 1280×800 and quad-core i.MX6 terminals: the PowerView 1200 from Murphy by Enovation Controls. It is powered by a dual-core Cortex-A15 and has a 12.3-inch multi-touch display with a resolution of 1280×480 (format: 8:3). The PowerView 1200 is well-suited for dashboards and can double up as a rearview mirror.

I’ll take a more detailed look at some terminals in the rest of this post. I will ignore quite a few terminals, because they don’t stand out in any way from the rest or I simply overlooked them.
Read More »Agritechnica 2017: What’s New for Terminals?