ToyOBD1 basic Data Logging for Pre OBD2 Toyota's

[stanneh]

This will be my first thread on obtaining data from your Mr2 I only have access to my Gen2 late 92 possibly early 93? Turbo 3sgte so I may have to make some edits along the way to account for any differences we may find.

I'm going to start with ToyOBD1 it's existence appears to be common knowledge in the community here and other Toyota communities but it appears to me that it has never been presented in a way that makes this accessible to all of you for approximately £20 worth of parts if you shop right and get creative.

I initially found out about ToyOBD2 approximately 2 years ago, I found a seriously old Russian github repo Hyperion11 that had documented it and I assume that is the main reason it is still not so easily accessible, along with the fact that his code syntax is always somehow broke and it never compiles until you go through it and fix it.

in the 10 minutes of tireless research I did before opening this new thread I found that the repo has in fact since been updated and he has in fact really improved it a lot except it obviously wont compile out of the box again because his syntax is broke

So once and for all let's get ToyOBD1 available to all of you I propose to do the following...

(1) fix the damned syntax of the latest build and get it to compile.DONE.

(2) update all the comments to English to make it easier for more people to understand the code if they want to go that deep. DONE.

(3) document instructions on how to program an Arduino with the code WIP

(4) demonstrate how to safely hook up your Arduino to your Diag port in your car's engine bay. NOT STARTED


References:

The code for this project can be found here https://github.com/Stanneh1/TOYOBD1

Random document about the toyota OBD 1 interface
http://wilbo666.pbworks.com/w/page/4965 ... yota%20OBD

And another random document about the OBD-1 Serial Interface (a bit more info here)
http://toyota.kgbconsulting.ca/wiki/OBD ... _Interface

Hyperion Toyota OBD 1 Arduino project.
https://github.com/hyperion11/toyota-obd-1

OBD I Diagnostic - CarTester 8000.
https://www.translatetheweb.com/?from=& ... yengine%2f

Arduino forum discussion regarding Toyota OBD1
https://forum.arduino.cc/t/reading-obd- ... 992/231151

[stanneh]

(1) Get code to Compile. DONE.

I have forked off the main branch of code from Hyperion11's code and updated it so that it will compile in the Arduino IDE now.

you can find the new code base on my own github fork of it here

[stanneh]

Part 2 Update the code to English. DONE.

Link to the latest code.

Now that this is done it makes it far easier for everyone to understand a lot more about what the program is doing.

and I can now take a good look at this new version of the code and the new features that have been added.

[stanneh]

Part 3 demonstrate how to upload the code to an Arduino.

Work in progress coming very soon.

Awaiting delivery of a few items some essential some not so...

Arduino Nano. this is arriving today.



Oled Display. this is arriving today


17 Pin Toyota diagnostic connector to 16pin Female OBD2 connector. this is not essential wont receive it for a few weeks. I can demo everything without it


16 pin Male OBD2 connector to open end. this is not essential but will receive it next week.

[stanneh]

Part 4 Demonstrate how to safely hook your Arduino up to your Diag port.

Not yet started.

[stanneh]

Some vids of my janky implementation of ToyOBD in my car on a comically small Oled display.

[stanneh]

The following is from a document that I found somewhere that really helped to drive home a solid understanding of the data stream.


reading is carried out as follows: a cycle is spinning, in which the state of the data line is continuously polled.

The time allotted for one word with the data was measured, and during this time, times of 8.2 ms were detected and the state of the line was determined during these 8.2 ms,
i.e. in what state (logical unit or zero) is the line that gave the bits that make up the data word.

And so on until the time allotted for the entire package passes (163 bits * 8.2 ms = 1.34 s).

And the binding to the data stream (synchronization) is carried out programmatically,
and all protocol bits are recognized based on the time elapsed from the beginning of this binding and allocated to each bit, word, entire packet.


What changed? Now reading takes place according to this principle:
A notification event is expected on the change of line status (from zero to one or vice versa) from the port driver.

Upon receipt of the notification, the line status is read and the countdown begins.

At the next state change (logical level change), the time during which the previous state lasted is read, the new state of the line is read and a new countdown is started.

In the process, the obtained times the line was in a certain state are divided by 8.2 ms (with rounding),
i.e. A breakdown is made into a sequence of single or zero bits of the protocol ones and an array of the form [state, time in this state in bits of 8.2 ms each] is filled.

Summarized along the way and the total number of bits after the start of the packet.

If two sequences are found in at least 16 bit units (the beginning of two packets), the entire sequence between them is considered one packet.

It is checked that the sum of the bits in this packet is equal to the number 163.

Under this condition, such a packet (array) of the form [1, 16], [0, 1], [1, 8], [0, 4], [1, 2] ... [1, 2] is further processed as follows:
protocol words are formed from this array - 16 bits beginning, 15 bits ID, 13 words of 11 bits of data.

From the sequence [1, 16], [0, 1], [1, 8], [0, 4], [1, 2] it turns out: 16 units of the beginning, ID 1 bit of zero, 8 units, 4 zeros, 2 units = 15 bits ID.

By a similar principle, data words from the array are populated.

Moreover, it is checked that at the beginning of each word there is one start zero bit, and at the end - two single bits,
then the bits between them (8 bits) are considered as the correct data byte.

Thus, the reading of information at the hardware level is initially synchronized (upon receipt of a notification from the driver,
i.e., on the front of a unit or zero) within a few protocol bits (i.e. there is no accumulation of time-out error over a large period, as previously ),
and then comes the recognition of packets matching the protocol, their correctness.

To confirm the above, you can do the following experiment:
start reading version 7091 and (two 1.5Vx2pcs = 3V finger batteries connected in series are enough) and “blink” TE2 + 3V with E1 connected to minus 1.5V batteries connected in series.
With a fairly frequent violation of the contact (simulate impulses), awkward data will appear in the program.

With new version this will not work (it is unlikely that anyone will be able to simulate the correct Wink protocol)

[stanneh]

So I just finished my first test of it having made a cable, programmed the arduino and hooked up the OLED Display


Not total success first run with the latest build of Hyperion11's code but I had to tweak it in the past.

[stanneh]

I'm back to work through the week unfortunately, but curiosity got the better of me I've been looking at my old builds of the code from when I had it working.

I've noticed something which also reminded me of another point in short (some cars have I believe have a different ID) in the code it is referred to as ToyotaID and this is the start sequence of the data stream a pointer to us to know where the data stream starts and ends.

for instance one car could be 1010 or true, false, true, false. another could be 1101. and as stated this can determine where to begin reading the data stream.

Bottom line I have previous builds of the code that I had working so this coming weekend I will work with previous builds (Find one that works) then do a comparison and get the latest code working.

The latest code has a lot more calculations and I'd really like to get that up and running rather than deliver a working older build.

[stanneh]

So as I haven't been able to do anything practical this week I've put a lot of thought into what I want to finally achieve with this.

At this point I think this thread will just end up being a weird mess of my process of recovering the code and deciding on the simplest way I can provide an example that almost anyone should be able to achieve for 15 to 20 bucks and an hour or two of patience.

I suspect I will eventually document the above process for all to follow in a separate thread.

As I have already got the code working just fine in the past I am already looking past the initial debugging issues I need to do of the code to get it working and I have began thinking of the neatest package I can present this in which may end up being slightly more work and cost but will be the most useful and practical way to use this.


The easiest example I will put out will be of an all in one package you plug into the diag port and it will display the data on an oled and log it to sd card.

Then I intend to put out a new instructional which will separate this reader/logger into two packages...

One small device that hooks up to the diag port which goes to an opto isolator that take the signal from vf1 and offloads it safely to a small device with wifi/bluetooth capabilities called an (esp32) this will then transmit the signal via bluetooth and wifi.

now that we have a safe signal being transmitted we can now choose any number of methods of displaying this, I will create a simple rechargeable hand held device with oled display as an example but this could be received and displayed in any way even converted to be interpreted by the torque app.

I have began work on a display that replicates the MR2 Turbo gauge cluster which you can see here...

[Wilkie Senior]

Flipping heck my Brain has melted going to take some time to digest

So are you looking to make a digital dash?

Brian

[stanneh]

Flipping heck my Brain has melted going to take some time to digest

So are you looking to make a digital dash?

Brian

Yea sorry this thread has turned into a bit of a brain dump as I piece everything back together.

It's good log I've returned to this a few times so far to get links from above etc.

So yea what I am doing for my car is beyond the scope of this thread I'll get to that as a new thread when I have finished documenting this.

Basically though yes I do not want any kind of aftermarket gauges etc but I do want to monitor my car I am recreating the digital dashboard and that will be driven by real time data, in the meantime I can deliver the data discussed above it is not real time but it is great for logging and to see in close to real time if you have any issues.

In the following week or two I expect to have a new thread documenting a how to for the project I am documenting above and I promise it wont be a mess like this one

[stanneh]

I have got a lot of parts out for delivery, once I have sorted out the code and decided on a first example with the hardware I will likely use the hardware I have left over to give away a few examples to those brave enough to try

Just stick around and be patient with me I certainly do not want to drag this out longer than necessary but I have a full time job and a family.

I did however remember that I have a non turbo 3sge ecu here that I randomly obtained ages ago so I am going to see if I can hook this up on my desk and see if I can debug from that ecu which will save me a lot of time and hassle.

[stanneh]

Update I guess =]

So I have realised a few things...

The hardware used by the original people who did this were using technology that is now completely outdated, having complied to the original electronics design using the same arduino nano etc I started to play around and realised that these old arduino's are simply not powerful enough they are missing 2 out of every 3 packets of data. its a 1.25s delay between packets, processing each packet and sending the data to serial alone takes 3 seconds or more processing time.

So I have moved on from the old hardware still arduino based code etc but had to tweak it slightly to take advantage of multiple processor cores available in modern chips.

Advantages for this are we will never miss any data, we can process it to serial to wifi to displays to SD card anything we want all at once.

I have 2 devices here both wirelessly talking to each other one is a transmitter connected to the Diagnostic port this has a display and SD card attached. the other just receives the obd data from the transmitter that is connected to the diagnostic port over wifi and displays it on screen.

The best part is as we are sending this data out wirelessly anything can receive the data and display it like your phone for instance.

Pics etc to follow shortly, Transmitter and receiver code will be uploaded to git hub as soon as I have cleaned it up.