Some time ago, I said: " I personally don’t care about tying a car ... ", but "never say" never "." The stars stood up in such an order that they had to urgently change the Peugeot 307sw to a Mazda5.

The car drives, everything is fine, but some of the “buns” that were in the old car nominally, for some reason were absent in the current one.

One of these useful things - parking sensors. Installing parking sensors is not a problem, but somehow the “non-native” display of parking sensors did not suit me in the cabin. The inner perfectionist was terribly against the "alien body."

')
For some time I googled and found out that several years ago, one comrade from St. Petersburg made a special “supplement”, which was connected to the parking sensors on the one hand and to the car on the other. And at the same time information from the PDC was displayed on a regular display.

It would seem that it is necessary to buy, deliver and relax, but that project “died”, the author doesn’t come to the contact: you cannot buy it.

But this is not our method ... since it is impossible to buy, it means that you can “reinvent” (and pump up your microcontroller programming skills).

Part One: Parktronic

At first it was necessary to choose parking sensors. In the original project, Parkmaster was used (a model that was already completely unavailable - discontinued). I had to choose from what can be freely purchased. The choice fell on the Parkmaster 4-DJ-06 (the same brand - there was a hope that “someone had already picked it up, it means I can too,” but compared to the original model, “the speed of detection of obstacles was improved, stability was improved, and sensors New design with effective water drainage, etc. ").

The first thing that was done was the display disassembled and the cable connection to it was studied. It was found that the display is connected by 5 wires: GND, + 5V, DATA, CS, CLK. Those who are familiar with the SPI bus will immediately notice some similarities (for the DTC = MOSI). The connection of the display with the main unit is one-way (the main unit is the master, the display is the slave), therefore one single conductor (MISO) is missing from the “full” SPI.

Connecting an oscilloscope fully confirmed this hypothesis:

Channel A - CS, B - CLK, D - DATA.

Next - a matter of technology: it was necessary to figure out how to "remove" all the code parcels and decode what is transmitted there.

I have already spoken about reverse engineering of the protocol of another PDC, so I will not describe it like this, just give a link to the forum thread where the truth was born for my particular case (there is also a code with which the code packages were captured). My nickname on that forum is ustas).

The work was quite routine, but in order to make everything “beautiful and interesting” I used two interruptions. The first interrupt monitored CS, the second - for CLK. There was nothing more interesting in this part.

A couple of days off, a few evenings, and I had a ready-made prototype on a layout (with arduino-nano), which confidently received data from the main parking sensor unit and produced their decoding. The choice of parking sensors was justified - even the levels were not coordinated.

After that, parking sensors were installed in the car and the main development site moved there.

Part Two: Listening

At the same time, I learned a lot of new things about the fact that almost all modern machines are to a large extent “computers” on wheels, even a “network of computers”: since almost all more or less “smart” units are connected to a single CAN bus and use it to “communicate” between themselves".

In general, cars usually have two tires: HS-CAN and MS-CAN (high-speed and medium-speed tires, respectively). The first relates to the operation of the engine and adjacent systems, the second - it is also called the “comfort tire” - refers to various service functions (music system, tidy, lighting, climate, doors, etc.).

In my car, the display is just connected to the MS bus — this bus has become the “target” for my project. Of course, need more information. Manufacturers, of course, have all the necessary information, but are in no hurry to share it (although the situation is beginning to change , but not in my case).

The starting point was this page , which presents some message identifiers and what data is encoded in these messages. In the comments to this entry, too, there were useful notes.

Before sending something to the bus, I decided that first I should “listen” to my car and make sure that the information presented was true.

Since the corresponding shield with the CAN interface was not at hand, the Arduin had to be abandoned (and anyway, I decided to make the appropriate device for installation in the car) - I parted a simple board that contained a MK (atmega328p) CAN bus controller (MCP2515 / MCP2551), beeper ... and ... watch module.

What not to collect on avr, but in the end the clock still turns out
from amateur radio forums

Well, who would have thought that a car that was made in this millennium has a watch, but no calendar? Since I'm still a sclerotic, I decided that the calendar would not hurt me for sure, so DS1307 also “registered” on the device board.

The device circuit does not at all shine with some originality: the typical inclusion schemes of all components (from their datasheets) are used. Just in case, I brought almost all free I / O ports to an additional connector (what if something else comes to mind during the implementation process?). Naturally, for the programmer, I spread the ICSP.

It was decided to take the power from USB charging , so there is a miniUSB connector on the board. An additional cable was laid from the parking sensors unit (during its installation) that “duplicates” the main cable between the display and parking sensors (so that you can have both a full parking sensor display driver and my “product” at the same time). The cable took the first one ... But you will not be very surprised to learn that it turned out to be a long patchcord? Therefore, the board has a corresponding connector (black, on the left). The form of the board dictated the existing case.


At the first stage I decided (for simplicity) to connect to the diagnostic connector, the benefit of which is the MS-bus. Where exactly the connector should be looked for, peeped here .

With the hardware, I hope everything is clear ... go to the software. To work with the CAN-bus I used the finished library . Test cases helped a lot - they allowed you to start listening at once. The only thing that had to be corrected was to indicate the correct MS-bus speed (CAN_125KBPS) in the sketch.

The data on where to look for the display messages was fully confirmed (to check it, I turned on the head unit in radio mode and chose a radio station which, through RDS, only output its name and then found the corresponding parcels). There were two parcels in which this name was coded (in the first parcel - the first 7 characters, in the second - the remaining 5 characters).

Part Three: Speak

The first attempts to send messages to the display failed. The standard auto display just ignored my packages.

In order to deal with this problem (and for convenience) - on the "disassembly" acquired the display from Mazda3 (much more common spare part than the similar one from Mazda5). The most noticeable difference between displays is the color of the backlight (Mazda5 is green, Mazda3 is red). The rest is almost identical, and I hoped that the differences were only “cosmetic” (and it turned out to be right).

I gathered at home a small test stand consisting of my device and this display. Working out on a stand is much more comfortable than in a car, in winter outside.

In parallel, I found a wonderful comment:

You can send the 3 frames with the following IDs:
0x28F: 0x28f frame LCD settings.
0 × 290: 0xC0 (first byte) followed by first 5 alfanum signs
0 × 291: 0 × 85 (first byte) followed by the next 7 alfanum signs

all of them, just after you get the 0 × 291 frame id sent by the HU. Flicker at all.
0x280 and 0x291 text, it seems to simply ignore the 0x280 and 0x291.
150ms interrupt and send 3 frames described above.

...

0x28F frame content that I have used:
hex: D1 00 00 00 80 00 00 01

Thus, in order for the display to display the transmitted text, it is necessary to transmit three parcels (at the first tests I transmitted only two, and because of this, the display refused to display my text).

But for some reason at home on the stand and the correct sequence did not work out - the display remained empty. I went to the car: the same code worked perfectly. He began to understand and realized that for the test bench there was not enough a 120 Ohm resistor on the bus (between CAN-H and CAN-L). Once put this resistor - the display "came to life."

Part Four: Logic

I am very cautious about various “tuning” and I believe that if I do it, it is only in such a way that it looks like “regular functionality”.

Observing the work of the regular display prompted the logic that I wanted to implement: as soon as the display does not change the inscription for more than 5 seconds, you can display “your” information (for example, the date), but if “the car wants to say something” (new information ) - immediately remove the "abnormal" message and display information from the machine.

Naturally, when parking such a logic is impossible to observe, in this case only information from the parking sensors should be displayed).

At home I wrote the main part of the code, on the test display everything looked more or less decent. But after a visit to the car, serious ones got out ...

Part Five: Rakes

The problem was that the head unit “floods” into the bus with its messages on the display with a period of about 150 ms (even if the information on the display has not changed). This led to the fact that "non-standard" messages almost immediately "frayed" regular ones.

Then began the " arms race messages." I slightly changed the scheme of my device, used an interrupt to track messages on the display and immediately tried to send my message (in order to “grind” a regular message with my own).

The approach might have worked at a faster MK, but the speed of the atmega was not enough - regular messages “skipped” periodically and this led to a very messy “mess” of messages (especially since the text is transmitted in two portions: sometimes a situation occurred that the first part of the message is from the car, and the second is from my module).

In general, it works, but not at all as we would like.



To solve this problem, it was necessary to somehow "tear" too "talkative" radio tape recorder from the tire.

It would be possible to put a “relay” that would disconnect the radio tape recorder from the CAN bus at the moments of displaying irregular information, but this would violate the logic (for example, I would start to change the volume, while the message “VOL 7” with the corresponding level and this message would be skipped).

Those. It was necessary to solve the puzzle: listen to the CAN bus, analyze the messages and send the necessary messages to the display.

"The right question is half the answer." I came up with the need to add a second CAN interface. In this case, my device is turned on "in the cut" of the CAN bus between the car and the display. The device “listens” to what the machine says (and generally takes everything it needs from the bus), analyzes the data and only the necessary is transmitted to the display.

In order not to overhaul the board completely - I did the “shield” (the divorced additional input / output ports and the ICSP just came in handy), because the CAN bus controller is connected to the MC via the SPI bus.

It turned out such a device:


For convenience, the ICSP made it “pass-through” so that it would not be necessary to disassemble the “sandwich” each time to update the firmware.

Part Six: Tests

At home, my prototype only "removed" the data from the camera, but nothing was done to "visualize" the result. As soon as the main problems with the device are eliminated and the connection scheme has already been “fixed”, it recreated the work of the parking sensor on the standard display. It turned out like this:


The video shows that the output is almost identical, and in some cases the information appears on the Mazda display a fraction of a second earlier (which is not bad at all).

After the main parts of the firmware were debugged, I decided to install my development in the machine in order to arrange a serious test operation.

And then the following problem was revealed:


Missing information unit climate control (right side of the display). As it turned out, this is not the only loss - the trip computer also refused to show its information.

This was not a big surprise, since in the firmware I “watched” only the messages on the central part of the display (I received, analyzed and, if necessary, displayed), all other messages were simply ignored.

Obviously, it was necessary to find message identifiers that contained the “missing” information. It didn't take long.



After the rules for the live broadcast of messages with these identifiers on the display were added to the firmware code, everything worked as it should.

Part Seven: "... and jumped!"

In the process of searching for various information, I registered on the Mazda5 owners forum - shared my experience, showed how it works. It turned out that this project is interesting not only for me. The conference helped to find the necessary information, suggested possible functions.

During the discussion, it turned out that not all trim levels have a trip computer, but replacing the display with another one adds this function. This indicated that the data was in the bus, and the display function was implemented in some configurations, in others it was not (and this is realized in the display firmware).

I checked this hypothesis and made sure that it is correct. Simply enough to get the following data:

• average speed,
• instant fuel consumption
• average fuel consumption
• power reserve on the remainder of the fuel.

"Digging" a little deeper - found more and current data: speed, engine speed.


Once the data is there, you need to use it somehow.

Immediately added to his module the function of notification of unclosed doors at speeds above 10 km / h.

Yes, there is a regular indicator of unlocked doors on the dashboard, but it only signals this fact, but does not specify which particular door is not closed.

Then he remembered that Peugeot had a full-time function of automatically locking doors at speed. Obviously, the same function is also added here ... but no longer on the prototype (unfortunately, control of the central lock in Mazda is impossible via CAN-bus, although in some other machines it is quite realistic).

Thus, the list of functions has expanded somewhat:

• parking sensors
• the calendar,
• output of trip computer data,
• open door control,
• auto closing doors at speed
• autoplay music when parking (in order to better hear the PDC's “beeper”),
• control voltage on-board network.

Since the result of my work was interesting to the fellow users, I decided to completely redo the device circuit (making it “single board” and “self-sufficient”): I included all the necessary interfaces, powerful transistor switches, a DC / DC power converter. At the same time made the original size of the board:


Naturally, all the knowledge gained in the process of creating and operating a prototype came in handy (the same 120 ohm resistor on the CAN bus for display operation).

It turned out that all connections to the wiring of the machine could be made directly behind the display (there is a very large empty niche and all the necessary signal wires are present).

As a “protection”, I made additional platforms for connecting the “alternative” battery of the reserve module’s power supply (all of a sudden the CR1225 backup battery will “freeze” in winter and the clock will get stuck) and the external “tweeter”.

Part Eight: Production

The board turned out to be quite compact due to the fact that it switched to size 0603 (in the prototype was 0805), quite a lot of vias (although it has repeatedly optimized tracing), tracks / gaps - 0.2mm. In principle, it was possible to make houses with LUT, but the project already took too much of my time, I decided that it would be much easier for someone to pay so that the board was made in the right quantity and the components were soldered (there were 9 interested co-users, plus for my car instead of the prototype).

I already had a similar experience of ordering in the “Celestial” - entrusted it to “my” contractor. It turned out relatively budget (cheaper than just buying components in Moscow stores), but not too much (small batch). He paid for the production with funds collected from those who wanted (“micro-crowdfunding”).

The devices did not produce too quickly - it took almost 3 weeks. But the post has increased the waiting period by almost a month. But let's not talk about sad things, because it turned out well:



Replacing the prototype with a “factory” product took me about half an hour (and the process was also photographed - to make it easier for users). But not everything went smoothly: the auto-mute function of the music on my particular radio tape recorder did not work (the frugal Japanese, to my regret, did not unsolder the System Mute circuit). But the management of the door locks started working immediately (albeit, after a rather thorough examination of the electrical circuitry of the car and the search for the “same” wire that is responsible for locking).

Part Nine: Settings

Due to the fact that the device had to be placed in machines of different configurations (and different users), it was necessary to figure out how to implement the setup mode (enabling / disabling necessary messages, functions, setting the date / time). Of course, “for myself” I would not even think about this task - there is nothing easier than connecting a programmer, but not in this case. We need to think about the "consumers" of the device.

At the same time, according to the “Logic” part, everything should look as clean as possible and without adding additional buttons to the salon (even a hidden installation). And then I remembered successfully that one can easily obtain data on the state of the doors, parking brake, “turn signals”, moreover, the latter in the tire had a state that completely repeated the state of the lamps (the corresponding bit in the package blinked).

I entered the settings mode according to the “shamanic” sequence: on the standing car (zero current speed), you need to open the driver's door (monitor its condition) and raise and lower the handbrake for 15 seconds after opening the doors. After that, “SETUP?” Appears on the display and, for confirmation, close the driver's door. Those. “Non-random” sequence of actions (which is unlikely to be played by someone in a car’s normal operation mode).

Navigating through the “settings menu” using the direction indicator switch: left - down, right - up. Enable / disable features / messages - handbrake.

The verbal description looks very complicated, but in actual use everything is much simpler (in front of the car - polycarbonate fence, pay attention to the reflection - it can be seen when the “turn signals” are used):


In general, it was quite difficult and interesting to come up with the implementation of such a menu, when a display in one line and only 12 characters is available.

I tested the product in my car for several days - no complaints, everything works fine.

Part ten: Continuation?

To date, all fees have been sent to their new owners. As soon as they are installed, I hope I will receive additional feedback.
Before sending, I managed to connect one of the boards to the Mazda CX-7 - almost everything worked right away (some of the trip computer data were encoded a little differently), but in general, the connection was successful.
Now the device (with the current firmware) is checked for Mazda3, 5, 6 (where the displays are similar to those that I used in the development process).

After adapting the firmware, I think the device can be useful on almost any modern car, where the display is displayed (or dashboard) via MS-CAN.

Part last: Arduino?

After reading such a long record (I apologize to those who read it), the question may arise: “What does the Arduino have to do with it?”.

The answer is very simple: I did all the programming in the Arduino environment.

After that, some may start “throwing tomatoes at me,” but my personal opinion: it’s better to use the tool that is available and familiar.

Arduino is one such tool that, on the one hand, allows beginners to quickly and relatively easily get involved in such an interesting area as microcontroller programming, and “sets” and “shield” also significantly expand the scope of use of hardware in their projects ( although it is not cheap).
Arduino (in my understanding) - a kind of framework for "quick start".

Of course, the use of professional tools could help to implement the necessary functionality faster / better / more optimally (underline the necessary), but for a “weekend project” this may be redundant.

Dare!

And once again for the sake of which everything was started:

The display has significantly expanded its ability to display useful (and not so much) information; nothing “alien” has been added in the cabin, while all the regular functions have been fully preserved.

PS If there are those who wish, I will lay out the circuit, board, BOM (I will support “open hardware”) Download it here .
PPS I will not upload the firmware in open access.