1. LADA NIVA 1.7 (GM's Throttle Body Injection) Diagnostics

I owe for almost one year an LADA NIVA, build in year 2002 (some photos will follow), equipped with GM's Throttle Body Injection (TBI). My first idea was (because of my professional deformation) to connect it to the computer and to make some measurements and/or hacks, as usual :-) For this purpose I use the pretty old piece of Fujitsu B110 Lifebook as the “master board computer” (playing also the MP3's and controlling the cooler).

First thing was to build the appropriate RS232 to ALDL (and vice versa) converter. I designed quickly an two transistor + MAX232 device (with some capacitors and resistors). I will publish the schematics here (soon, after I will draw it to some paper and/or software). I was too quick in doing this -> because there are a lot of much simpler designs (using only one diode, and so on). So, if you want to make some hacks, then search the things on the internet first :-)

I downloaded the software EFILive 4.x to test all this. EFILive looks good (and works fine), but it is only the trial version. I was too stupid to set up the EFILive to produce the communication trace of the ALDL, so, I wrote quickly simple preliminary version of the diag software:



This VERY preliminary (0.1.0) version of software is absolutely Lada Niva 1.7 TBI oriented, and, pretty in development. In any case it plays the EFILive 4 traces (the *.alg files). And, as there was no reason to invent own data format, it also stores the ALDL communication in the EFILive 4 *.alg file format (so far I understood the file structure by simply looking into the logfile “gmh-vs8dyno.alg”). All this is currently tested only with the Lada Niva 1.7 TBI. Current version of my SW shows an very simple dashboard with the SPEED, RPM and VOLTAGE gaugages. Extensions are very easy to made, if I will have time I will add also the interpretation of EFILife car description XML files (some day, may be...). The software has currently some minor problems during the communication (because of wrong critical sessions/mutexes handling in my multithreading “design”).

My small diag SW works well on Win98 (it is funny, that the screenshot from above comes from the Ubuntu – I started the SW under Wine shortly only to take the screenshot :-))

So, this is the first info I have about this experiment. I will put a LOT of helpful links here, and, after I will solve ALL the communication issues of my SW I will make it available to download here (the 1.0.0 version :-))

OK, I know that there are no much informations here till now, but, if someone wants to contact me (some Lada Niva fans, and so on), then here is my e-mail address:

karol<underscore>kostolny<at>hotmail<dot>com

→ the characters placed between the <> brackets needs to be replaced by proper characters (only small anti-spam action :-))


    1.1. ATMega as controller used in place of the PC

Yesterday (2013-03-07) I changed my mind. After several experiments with ALDL in my NIVA I found out, that there is no really place in the car for the computer (it is small, but the display is “big enough” and I don't want to disassemble it so that it fits somewhere). So, I decided to replace the notebook with small controller. I extended the ALDL interface schematics a little bit, now the ALDL, RS232 and ATMega8 controller are wired together (if desired). Now it is the controller and/or the PC connected who is sending the ALDL requests and receives and evaluates the responses. The preliminary version of the schematics is here:


I used the gEDA schematics editor to paint it. It is my first experience with this SW → may be there is a better way to make it, but I think it is “good enough”. The switch from PC to ATmega8 has some consequences, I think the positive ones are compensating the negatives:

  1. No MP3 player anymore :-(

  2. No cable mess and no notebook flying around when driving in hard terrain :-)

  3. The PC can be still connected during the communication and can visualize the response data (only small change in the request/response logic of the PC SW must be done)

  4. The SW can be downloaded into ATmega8 using the bootloader over RS232

The output pins of the controller will be used to drive the digital and analog (using PWM) devices to display the data read from the TBI's ECU.

I will publish also some photos here later..... hopefully soon ;-)


    1.2. ATMega8 + RaspberryPi

Yesterday (2013-06-02) I decided to use this GREAT piece of HW – the RaspberryPi (www.raspberrypi.org) in place of the PC. The circuitry from above will be unchanged and the Rpi will be connected using the RS232 to the board – so that it can be disconnected if needed. The ATMega8 will be sending the ALDL requests in the loop and will display some basic infos using LEDs and/or some additional gauges. And the RPi will be listening to the incoming ALDL responses and interpret them in parallel with the ATMega8 and will display all the data on the display. RaspberryPi is SIMPLY GREAT and PERFECTLY suitable for my purposes – single 5V power supply, it is small, it has by far enough power to display the data using pretty OpenGL graphics and, my lovely MP3s can be played again! Unfortunately I have INSANELY few time for all this. BUT, after everything will be wired together, then I will have my Lada NIVA running Linux ;-) Now I need to rewrite my diag SW (see somewhere above) to run on Linux (will be no problem, because the diagnose/data model/data processing is implemented to be completely OS/platform independent, of course), only the visualization and COM port access needs to be reworked. As the Rpi has also SPI interface lead out, it will be possible to connect the MCP2515 CAN controller. It is SPI controlled CAN cell. In this way also the OBD2 responses can be interpreted and processed/visualized...... but, for first, the ALDL must work ;-)


(2014-10-24) Ok, finally I had time to do something for my Lada Niva. I built the HW from above again (but somewhat simpler one, I'll update the schematics later... with a little bit of luck :-D.... some day). But it was VERY annoying to go to the car and eventually start it to test whether the HW+SW works, whether the communication and interpreting of the ALDL response works and so on. To avoid this I wrote an very simple Lada Niva ECU simulator running on the PC. In this way I can develop my HW+SW without the need to leave my messy lab to test it all. Currently no Raspberry is connected to it, only ATmega8 is sending the requests and outputs the RPM to the pin using the PWM so that I can connect the analog gauge to it. I created & uploaded the video how it works: http://www.youtube.com/watch?v=0lM-QDd-G4Y

(I was creating the video at night, after I returned from an very long family celebration :-D, you know what I mean ;-))

(2015-05-25) So, finally, I had some time to do something for my Niva. The HW is finished and is working I placed it all to the metal plate from the old car radio. This is the photo of all this (sorry for the ugly, long wiring):


It works more or less in this way:

  1. The cooler fan is controlled independently from the ALDL communication – the temperature is taken directly from the temperature sensor – only very simple SW for the ATmega8 is needed to handle this functionality, no ALDL communications is needed for this

  2. ATmega8 is sending the ALDL mode 1 request and receives the response, all this using ATmega8's UART with some additional circuit to adapt the signals and so on (see the schematics somewhere above....). Additional MAX232 is wired to all this and any device can be connected using RS323 serial interface and can read the communication between ATmega8 and the ECU. ATmega8 is used to output some (this is decided in the ATmega8's SW) values read from the car ECU to display them using analog gauges using PWM (currently the RPM is wired).

  3. All the mode 1 response data are sent over SPI to any SPI master connected to the ATmega8. In my case this SPI master is the Raspberry Pi – there the data are interpreted and can be processed/displayed in any thinkable manner. Currently very simple SW is implemented to display some basic things.

The SW for the Rpi (or any other linux machine) is currently very simple:

OK, from now on my Lada NIVA is running Linux ;-) I will continue to develop the RPi SW, the problem is that I have very few time, as always. My idea is (as already described somewhere above) to have nice OpenGL GUI with nice graphics and effects..... this will be done too.... some day ;-)

    1.3. Rework of the cooler fan

OK, now, the ATmega8 should control the cooler fan also. The previous owner of my LADA did some strange things with the cooler. Apparently the fan in the car is not the original. To be honest – I have no idea how the fan is connected in the original TBI NIVAs – I didn't found it in the NIVA schematics I have. Currently it is connected directly to the battery over the switch on the panel. This is not good – the cooler must be switched manually and the connection is currently not secured by fuses at all. Also the wiring behind the panel is pretty ugly:



Now the fan will be turned on and off depending on the cooling water temperature using the relay and controlled by the Atmega. I want to leave also the possibility to turn on the fan using the same switch as today – using the same relai, and with one feedback LED signaling the real state of the fan power supply. I have some really antique relays made in the Sowiet Union. These 70's relays looks simply historically-great and are (I hope) strong enough to feed the fan with the amps it needs (there are absolutely no datasheets for these pieces – I didn't found them, at least). The ATMega is (of course) not strong enough to switch the relay, so, some additional transistor (one or even two) will be needed.

Ok, I plan to install the relay (only manual switching for now) in next days. I will put the photos here after it is done and working :-)

(2015-05-25) The work is done, the cooler fan is now controlled by Atmega as descibed and the whole HW and SW works as described in the chapter above.


    2. ISO TP (ISO 15765-2) communication/protocol analyzer/interpreter

Two weeks ago in the night, I was not able to sleep at all (because of many different reasons). So I decided to hack quickly the ISO TP communication analyzer. I don't have enough time to implement it during my work time... so I decided to write it in my private time, pretty tired, not able to sleep ;-)

I wrote the SW in MS Visual C# 2010 Express. I decided to use the C# (I am strong C++ fun, but, in the last time I wrote a lot of SW in pure C for embedded systems, so, I had some need to use an higher level language... tell me why MS C#... I don't know exactly why.... simply so.... the code looks like C++ written in C#... but, who cares).

Well, the SW is in development. I wrote it to be pretty modular, it interprets any amount (currently two) of input file formats (containing the CAN (or, theoretically any other) communication). For now only the ISO TP 'Filters' are implemented, but it can be extended easily by any other filter/interpreter (I can imagine the interpretation of UDS/KWP services (if appropriate diagnosis description is provided), or any other communication protocol ;-) available in the form of some art of formal description).

The main application window looks like this:

The output can be written down in the form of HTML, plain TEXT or the GUI form. The GUI provides some additional functions, like e.g. the computation of the time difference between the selected CAN frames, or, it can select all the CAN frames belonging to single ISO TP data transfer chunk. All the ISO TP data are interpreted to the human readable form, displaying/filtering out of error frames and checking the fulfilling of communication constrains communicated using the ISO TP flow frames and so on. The GUI looks like this (currently):

I am working on this SW, but, as already mentioned above, I have too few time for this project too :-) The description of the input/output formats is still missing. I will publish the SW here soon, after some additional fine tuning is made.... because of performance..... I mean I want to use the virtual list view to display the data as several millions of CAN frames needs to be displayed.... In any case the SW will be available for download here very soon (now, we have 2014-03-12, midnight, so, lets say, in one week the SW is here). I want to make it available as Freeware.



    3. LADA 2105 Motor control ECU

OK, just small background: today (2017-04-11), I had an really bad day in my work. Some people is trying to tell me that I am complete idiot, producing “too complicated” software (single(!!!) automata’s state machine processing the answers from the HW watchdog). The problem is completely different, indeed. OK, now, based on this, I decided to implement the motor control unit for the carburettor engine of the LADA 2105 (I’ll place some photos here) using ATmega8 running @ 12MHz to prove the contrary. Lets see whether I’ll be able to succeed.

The goals:

  1. Measure the RPM of the engine and perform the needed computations based on the results

  2. Control the sparks and the spark advance depending on the current RPM, car speed and the throttle position, with parameters stored in the predefined table with appropriate interpolation, use the semiconductors to control the sparks in place of mechanical pieces (this is somehow (almost) clear ;-))

  3. Implement basic ECU diagnostic accessible over the RS232 and/or CAN

  4. Support any other functionality which will be needed and/or useful during the development


First considerations:

  1. I will use the modules I wrote in C++ for the ATMega8 in the past (comparators, SPI/UART/CAN drivers, event counters, signal filters)

  2. Some kind of rotation sensors will be needed – hall sensor(s) are the first choice at this place – I’ll use only one at the beginning combined with the mechanical crankshaft position detector already present in the engine.

  3. Completely asynchronous “modus operandi” of all the drivers/actors used – this is necessary because of low resources CPU – the calculations must be running during the e.g. communication HW is working

  4. The main goal: better and more effective performance of the really obsolete carburettor engine, and the prove that I am not the complete idiot as somebody is trying to insinuate


To be continued (as always, too much stress and no time for anything… bt lets try It!)...