Doh! Bad news: I forgot to add a very important feature; Data streaming. Basically if you want to read 5 codes, 50 times so that you can display the information in some kind of graphical display you can perform the following: ----- Iteration 1----- Send code to read (1) Read result Send code to read (2) Read result Send code to read (3) Read result Send code to read (4) Read result Send code to read (5) Read result ----- Iteration 2----- Send code to read (1) Read result Send code to read (2) Read result Send code to read (3) Read result Send code to read (4) Read result Send code to read (5) Read result ----- Iteration 3----- Send code to read (1) Read result Send code to read (2) Read result Send code to read (3) Read result Send code to read (4) Read result Send code to read (5) Read result [etc... I.e. 50 times] You perform the following: Send code 1 to ECU Send code 2 to ECU Send code 3 to ECU Send code 4 to ECU Send code 5 to ECU Tell ECU to stream data Read data Read data Read data Read data Read data Read data Read data Read data Read data Read data ... ... ... ... ... [At some point (i.e. after 50 or 500 or whatever iterations you want)]- Tell ECU to stop streaming This means that the ECU isn't having to listen to commands from you, it just sends data in 1 continuous stream. Well, when I reported my progress over the weekend, I hadn't added this function. Silly me The good news is: A few more hours coding, and TADAH! I just added it. It's definitely getting there... :zlove:
Ok, so I refactored the code today so that I now have a standalone Arduino Library that provides all the required functionality. A typical output is as follows: Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 -----etc---- Every so often it will also output the current codes: Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 Codes:2 Code:13,0 Code:42,0 CLEARED Coolant:80 Timing:16 Battery:9 Speed:0 Tacho:0 MAF:0 TPS:0 O2L:0 O2R:0 This allows me to present live diagnostic information. Obviously it won't clear the codes every time; that is something I would leave for the driver to perform manually. I think this aspect of it is now complete.
More info... It can now handle either KPH and Celsius or MPH and Fahrenheit, and debugging is enabled as required. Both are controlled by two switches (so there is no extraneous messages happening)
If anyone is wondering how fast the updates occur, it is about 50 reads of each of the following per second: Coolant temp Speed Battery voltage Ignition timing Tacho MAF voltage TPS voltage Left O2 sensor Right O2 sensor I have coded it to read 60 seconds of the above sensors, then read error codes, then repeat. This is of course adjustable (at the moment only by adjusting the values in the code). Once I get the info displayed in an app then I will see if that update speed is acceptable. It should be - playing a computer game at > 35 FPS is normally acceptable.
Who wants me to continue this thread? I have had a significant win today, and want to know if it's just me talking to one or two others.
The WORLD is watching, waiting, stunned by the brilliance of your achievements ... !!!! Stay with us, Baby .........
This is what I can do TODAY: Provide the ability to connect OBD2 software to your OBD1 Z32 (read only diagnostics ONLY) Alert the driver (visually) when coolant is over temperature (audio to come) Read OBD1 codes and transfer to a connected PC (via USB) Display selected codes to connected LCD display This is of course all performed in real time and concurrently. Regarding the OBD2 stuff, don't get too excited just yet. The number of sensors we have available is nothing like what OBD2 cars have, so the reported information will be much less. I still have to do the interesting GUI stuff, but when I receive interesting stuff in the mail that I paid for weeks and weeks ago, I need to test the ideas I had all that time ago before I get disenfranchised. Thanks for the interest so far. It looks like this may actually get off the ground in more than just my car, which is great. Edit: to connect and read OBD2 codes you need an OBD2 cable. Obviously these are much cheaper and easier to source than the Consult cable we have relied upon up to now.
No. That adapter is for the small number of cars that are OBD2 but still have the OBD1 plug. They kind of call them OBD1.5.
Our cars are 14 pin sockets (OBD1) so any mention of needing an OBD2 cable meant (to me) that an adapter cable would also be needed to be 16 pins compatible with the OBD2 Bluetooth pictured in my previous post.
Another idea would be that you plug a box into our Consult port that has an OBD2 socket, this making our cars OBD2 compliant. The box does all the work of course. I guess that given enough time and effort, the box could be integrated into the cable. What I have done is a lot more than simply wiring a 14 pin socket to a 16 pin plug (or vice versa).
At this stage I don't know how big a beta there will be. The cost price of the hardware for 1 unit is approaching $300. Yes, that means I don't make a cent for that price. I may have to do some magic to get it down to <$100.
Great question. The answer is: both. It makes sense to stream diagnostics information to a connected device (e.g. PC, Phone or another Micro controller) for that device to work with (e.g. log to a file, display as graph) or use as input to other calculations), AS WELL AS provide configuration of the system with the other device. Consider this example: I have a clock. The clock sits in my stereo surround. It shows the current time AND DATE. There are no buttons on my clock, but it still shows the correct time regardless of how long I leave the car sitting, or if I take the car's battery out. How does it do this you may ask. Well, when you get the clock, it has both a bluetooth and USB connector. The USB connector can be used to connect another device (PC/Laptop), and with an app, you would set the following: Hour Minute Second Day Month Year Timezone These would all be set by an app on the PC or phone. "Hang on, you said 'Timezone'". Yes. Wouldn't you like it that when you moved into and out of daylight savings, you didn't have to reset the time? Also, wouldn't you like that when you connected your phone (over bluetooth) that the time was synchronised automatically? And how is it that removing the cars battery doesn't force the time to be reset? Easy - the clock has it's own battery backup (that should last between 5 and 9 years). To summarise: The phone or PC/Laptop will be used to recieve data (for whatever purpose), plus for certain configurations, it can or will act as the interface for configuration purposes. And lastly, you may be wondering what I mean when I say "Configurations" Well, I have decided to provide a bunch of different products, starting with a replacement for the clock. When I have finalised the design I will let you know more, but suffice to say that I am pretty excited to get one in my car, so you may be as well.
Awesome! just a thought, it would be nice to be able to configure tolerances for alerts on the OBD data... but I imagine you would have thought of that already I love the idea of tech in our Zeds, the connected car has always been a goal of mine and I believe this is an important part of that! nice work
