July 17, 2014 at 14:47Installing a car radar with SAE J1939 interface on a car without a CAN bus
About how to connect the smartphone to the car, on Habré already wrote . Non-trivial, however, is the task of connecting sensors with a CAN interface to a car without a CAN interface. About 3 years ago, a radar sensor for adaptive cruise control fell into our hands, like this
(about sensors for collision avoidance systems, for example, here ). Such sensors work in the range of 77 GHz allocated especially for auto radars, the range is within 200-250 meters, the viewing angle of space in modern models is up to ± 30 degrees. On the structural diagrams of collision avoidance systems and autopilots, they are designated as LRR (Long Range Radar) and they are usually placed on the front bumper. These sensors are now quite common, BOSCH, for example, recently releasedmillionth sensor , and are relatively inexpensive (<$ 1000). However, then it was still some kind of exotic. At that time, we were engaged in the development of a sensor similar in purpose, but for 100% of domestic components, we had a sample and wanted to conduct comparative tests. The testing machine was also domestic, GAZ-66, in the driver's jargon “shishiga”. Great car, four-wheel drive, comfortable kung with climate control, but not fully adapted to connect imported radar sensors.
In the accompanying documentation for the sensor, the standard of the protocol for exchanging data with vehicle systems was indicated: SAE J1939. The problem was that this protocol was interactive, and messaging was required for the sensor to work properly.
The sensor was connected to the laptop via a USB / CAN adapter; messaging was initially carried out using the CANView program. After switching on, the sensor issued several messages to the bus, one or two of which were subsequently repeated periodically. The desired message with information about the distance to the obstacle was not issued. The nature of the initial messages was understandable, the sensor tried to “register” in the system, told everything about itself, and where it was produced, and what it was intended for, and even described the types of vehicles on which it could be installed, but in response received nothing and sent requests again and again. The response of the vehicle to its request was simulated, after which there was some change in the packages (the sensor was surprised), but it was not possible to get the necessary information anyway. After an additional partial study of the standard (by the way, paid - about 650 bucks a year was requested by SAE), it was possible to decrypt periodic messages from the sensor, it turned out that it constantly reports the absence of a car. It became clear that for the sensor to work, information from vehicle systems is needed, such as, for example, speed or direction of movement. Everything that could concern him was given to him - but this was not enough for him. He still “didn’t see the car”. He still needed some information. Then the idea arose to simulate a car completely. After considering the approximate composition of messages of the required standard from sensors and systems of modern western cars, the idea seemed not the most successful. For instance, The description of diagnostic messages for a truck of one of the western companies occupied about 1000 pages in pdf format. I had to pay attention to the products of the Chinese comrades. As a result of not too long searches, a document was found on the Internet that looked very much like a list of commands according to the J1939 standard for some Chinese truck. The document contained a table of messages according to the standard with explanations in English, and everything else was in hieroglyphs. The table was not very large, only about two dozen messages, and it was not difficult to simulate them. Then the sensor has earned. very similar to the list of commands according to the J1939 standard for some Chinese truck. The document contained a table of messages according to the standard with explanations in English, and everything else was in hieroglyphs. The table was not very large, only about two dozen messages, and it was not difficult to simulate them. Then the sensor has earned. very similar to the list of commands according to the J1939 standard for some Chinese truck. The document contained a table of messages according to the standard with explanations in English, and everything else was in hieroglyphs. The table was not very large, only about two dozen messages, and it was not difficult to simulate them. Then the sensor has earned.
By successively eliminating the messages, it was found out what, in the end, he needed. The remaining minimum at which the radar is working together with them at the same time issued by messaging, as follows:
.
It turned out that in addition to the speed information, etc., given to him at the very beginning, the sensor for some reason needed a message from the 2nd controller of the vehicle. Most likely, he was pleased with the fact of the presence of such a controller, because he did not seem to be completely interested in the content of the message.
Further preparation of the sensor for operation was reduced to its installation on a durable (10 mm iron) bumper by drilling the bumper and screwing it with bolts, laying cables and connecting to the laptop through an adapter. Like that:
A program was written that displayed information from this sensor in parallel with information from a sensor of its own design. To control the traffic situation, a USB camera was installed in the cab, an image from which was shown in a window next to the program window. Test Video
(about sensors for collision avoidance systems, for example, here ). Such sensors work in the range of 77 GHz allocated especially for auto radars, the range is within 200-250 meters, the viewing angle of space in modern models is up to ± 30 degrees. On the structural diagrams of collision avoidance systems and autopilots, they are designated as LRR (Long Range Radar) and they are usually placed on the front bumper. These sensors are now quite common, BOSCH, for example, recently releasedmillionth sensor , and are relatively inexpensive (<$ 1000). However, then it was still some kind of exotic. At that time, we were engaged in the development of a sensor similar in purpose, but for 100% of domestic components, we had a sample and wanted to conduct comparative tests. The testing machine was also domestic, GAZ-66, in the driver's jargon “shishiga”. Great car, four-wheel drive, comfortable kung with climate control, but not fully adapted to connect imported radar sensors.
In the accompanying documentation for the sensor, the standard of the protocol for exchanging data with vehicle systems was indicated: SAE J1939. The problem was that this protocol was interactive, and messaging was required for the sensor to work properly.
The sensor was connected to the laptop via a USB / CAN adapter; messaging was initially carried out using the CANView program. After switching on, the sensor issued several messages to the bus, one or two of which were subsequently repeated periodically. The desired message with information about the distance to the obstacle was not issued. The nature of the initial messages was understandable, the sensor tried to “register” in the system, told everything about itself, and where it was produced, and what it was intended for, and even described the types of vehicles on which it could be installed, but in response received nothing and sent requests again and again. The response of the vehicle to its request was simulated, after which there was some change in the packages (the sensor was surprised), but it was not possible to get the necessary information anyway. After an additional partial study of the standard (by the way, paid - about 650 bucks a year was requested by SAE), it was possible to decrypt periodic messages from the sensor, it turned out that it constantly reports the absence of a car. It became clear that for the sensor to work, information from vehicle systems is needed, such as, for example, speed or direction of movement. Everything that could concern him was given to him - but this was not enough for him. He still “didn’t see the car”. He still needed some information. Then the idea arose to simulate a car completely. After considering the approximate composition of messages of the required standard from sensors and systems of modern western cars, the idea seemed not the most successful. For instance, The description of diagnostic messages for a truck of one of the western companies occupied about 1000 pages in pdf format. I had to pay attention to the products of the Chinese comrades. As a result of not too long searches, a document was found on the Internet that looked very much like a list of commands according to the J1939 standard for some Chinese truck. The document contained a table of messages according to the standard with explanations in English, and everything else was in hieroglyphs. The table was not very large, only about two dozen messages, and it was not difficult to simulate them. Then the sensor has earned. very similar to the list of commands according to the J1939 standard for some Chinese truck. The document contained a table of messages according to the standard with explanations in English, and everything else was in hieroglyphs. The table was not very large, only about two dozen messages, and it was not difficult to simulate them. Then the sensor has earned. very similar to the list of commands according to the J1939 standard for some Chinese truck. The document contained a table of messages according to the standard with explanations in English, and everything else was in hieroglyphs. The table was not very large, only about two dozen messages, and it was not difficult to simulate them. Then the sensor has earned.
By successively eliminating the messages, it was found out what, in the end, he needed. The remaining minimum at which the radar is working together with them at the same time issued by messaging, as follows:
. It turned out that in addition to the speed information, etc., given to him at the very beginning, the sensor for some reason needed a message from the 2nd controller of the vehicle. Most likely, he was pleased with the fact of the presence of such a controller, because he did not seem to be completely interested in the content of the message.
Further preparation of the sensor for operation was reduced to its installation on a durable (10 mm iron) bumper by drilling the bumper and screwing it with bolts, laying cables and connecting to the laptop through an adapter. Like that:
A program was written that displayed information from this sensor in parallel with information from a sensor of its own design. To control the traffic situation, a USB camera was installed in the cab, an image from which was shown in a window next to the program window. Test Video
