Jump to content

DIY data monitoring via arduino microcontroller


Recommended Posts

I'm in the process of investigating the use of an arduino micro controller to manage data logging and monitoring for my s15. This is going to be the first step in a very long process that may ultimately end up in me building my own ECU and developing a sheet load of additional data collection/monitoring and diagnostics. All of which will be designed to help me get the most out of the (eventual) racecar and how I drive it. I intend to use the collected data to do two things: log the data, and also setup a warning system that will sound an alarm if anything reaches unsafe levels. Taking this further could lead to the possibility of having automatic safeguards like cutting fuel/spark if, say, oil pressure drops too low, or temperatures get too high. Taking it further still, i could possibly develop more complex systems like traction control that would drop power if wheel speeds mismatch or automatic power cuts for shifting with a sequential box. Just know that his more complex stuff is still a LONG way away for me.

All of this is simply an application of my uni studies and my mechatronic engineering degree.

My brief research thus far has taught me that I should be able to connect an arduino to the vehicle OBDII plug and pull all the data from the factory sensors. I believe the OBDII uses a CAN serial communications protocol. I'm told there will likely be open source arduino libraries available for doing the comms.
Once I've established the ability to communicate with the ECU and get the data, then I'll be looking at what to do with it and how. After that, I'll be looking into installing a bunch more sensors of my own to read just about everything you could think of. The additional sensors will be read by a separate, larger arduino with more analogue pins. I'll make that one communicate with the first arduino and simply add the additional data to the existing logger and warning system.

I want to know if anyone has any experience with any of this stuff. Particularly, is anyone familiar with the OBD2 connectors, pin mapping and communications protocols? And is anyone familiar with any of the additional systems i'm looking into, even if it's just adding additional sensors?

Secondly, if I do go through with all this, would anyone be interested in having me set up similar systems for them? I'm just curious to know if it's possible for me to make any kind of financial return on all this research and effort. I'm not planning on being able to make money off this, but it would be nice.

 

I do know that you can just buy ready made cataloguing systems, but this is going to be a sheetload cheaper and will be endlessly customisable. In fact, the only cost of my first stage is going to be the hardware which is ridiculously cheap. The arduino I plan on using should only cost about $10-20 and then it's just wiring, a case and some warning lights/a buzzer all of which should end up costing under $40.

If anyone has anything to contribute it would be very much appreciated. Once I'm close to building a prototype, I'll put up a build thread under unapproved articles.

Link to post
Share on other sites

im sure if it was really feasible Hayden would have already done it or tried it, the bloke probably knows more about the ecu and wiring than the guys who created it! he would be your #1 contact to be friendly with if you want to bounce ideas around.

will be following this closely for progress, this kind of DIY grassroots stuff gets me excited!!!!

Link to post
Share on other sites

Its not feasible for Hayden because he is a ruthless buisnessman and wont work for less than $100 an hour :D.

 

Its worth doing for your own learning but its not worth doing for the people, Its all been done before. The most popular one is probably nissan datascan and ecutalk also do a lcd consult display that can show everything.

 

You can get everything from the ecu via RS232 and the protocol to read all the data has been published on the internet somewhere. Wouldnt be too hard for you to write your own program to display what you want like the ecutalk one

Edited by Munt.
Link to post
Share on other sites

As mentioned, not worth doing unless it is purely for your own interest. Forget ever making money from it.

 

You'd be better off writing an app to do the logging in conjunction with:

http://www.trackelectronics.com.au/consultbt

 

I use this method for datalogging in Nistune:

http://forum.nistune.com/viewtopic.php?t=1279

Link to post
Share on other sites

Always good to see people innovating in this area!

I have plenty of experience with this stuff on an electronics level, as I have been working for a couple of years on a side project involving comms to many different ECU platforms using CAN, UART, ODBII and Some OBDI protocols in an attempt to streamline the data into my own protocol for information & logging purposes via tablet device (android only at this stage) connected with bluetooth with SPP. It is pretty slow going at times due to the monumental amount of coding and learning I have had to do. I have a semi operational device that it CAN only at this stage. I am actually thinking of crowdfunding the project so I can actually get some real help to develop it into a commercial project before cars are all electric or hover mobiles.

 

Regarding the Silvia ECU, it is ODBI as Lee said, but the data stream is not CAN at all, CAN Bus is communications protocol unto its own utilizing a common 2wire non-clock synced bus system which devices can send & receives 'messages' on. If you are familiar with TCPIP, then communications on a CAN Bus is similar to TCPIP in the sense that devices transmit 'packets' on the bus containing all sorts of info including the message itself. Most ECU brands like Haltech package several values into a single can message.

 

The Nissan OBD1 protocol used in the Silvia, AKA Consult, is a simple UART/Serial protocol but with a few differences, it requires an async clock frequency of 154-odd-KHz and a few other things like 12v instead of logic level on the ECU TX line.
Read more about it here: http://www.plmsdevelopments.com/images_ms/Consult_Protocol_&_Commands_Issue_6.pdf

It is also a streaming protocol and for all accounts and purposes - extremely slow. CAN Bus is a sheet ton faster (but a lot more complex) which is why you find it in most common ECU applications for data logging/sharing between devices.

 

Doing this project with Arduino is a great idea, will be a much more user friendly platform to develop this as they provide so much of the ground work for you. All your really going to need is some sort of board with serial capabilities (probably all have this, not sure what MCU they use however) as well as the ability to produce the required clock for the ecu. This is usually done with a timer.

To compare - I have been developing on Microchips PIC32 family writing code in C, which has taken me the better part of 3 years to get very good at. Hardware design is another issue again which is also a massive learning curve. Stick with the arduino and do a heap or reading and I cant see why you wouldn't have a proto up in a year or less.

  • Like 1
Link to post
Share on other sites

Consult to BT is a pretty simple device really as most BT have the ability to run in SPP (serial port profile) and generally have the SPP stack in built. The Roving Network RN42, which I have used, is a good example. With SPP, connecting a PC is pretty much the same as a regular serial consult cable - except for one major BUT. BT being wireless has delays switching from TX to RX and so forth, which is OK if you are streaming data in one direction only, so not too much of a drama for logging, but with things like NIStune it is hopeless. Causes massive delays and disconnects due to delays while trying to tune.

Few guys have tried to rig up BT to consult with NIStune using 2 x BT radios, one for TX and one for RX and still was not fast enough :(

Link to post
Share on other sites

see, this guy^^

 

FYI i have no idea what you just said, all i got was Articuno, Buses and Cans so if you wanna have a drunken road trip with a pokemon im down that!

Link to post
Share on other sites

Wow, Hayden, this is amazing. So much more info than i was hoping for. ...Prepare your inbox.

Arduino is capable of serial comms via USART and generating the clock signal via PWM outputs. Considering this, the only external components I need to communicate with the ECU will be a 12V driver circuit for the TX line to ECU and a regulated, current limited PSU. I think I can do the 12V driver with only a MOSFET transistor. As for the 12V I'll have to look at tapping into the cars wiring somewhere. Any suggestions for the 12 connection to drive the microcontroller? It's also possible to establish USB comms from the arduino to anything else. So far I've only used the terminal in ATMEL studio for this though, so I'll have to look into how to get this to work to for retrieving data logs or otherwise interfacing with it.

There is one thing that confuses me about the Nissan Consult protocol though. According to the document you posted, the TX line to the ECU is idle low. It also states that the start bit for each byte is also low. Given this, how does the ECU identify the start bit and therefore a complete byte? Forgive me if this is an obvious question, I'm pretty new to serial comms.

The more I learn, the more i realise how much more there is to learn haha. There's a long road ahead. Thanks a ton for pointing me in the right direction.

Link to post
Share on other sites
  • 3 months later...

After doing nothing for a while, I decided to get back into this project.

I've decided that communicating with the factory ECU is going to be too hard and I can get the same results by either using my own sensors or tapping into the existing ones directly. I've purchased an arduino ATMEGA 2560 which has 14 analogue inputs and a pretty substantial memory and processing capability for the size of it. If I need more I'll either get a second controller or setup transistor switching on the inputs so I can have multiple sensors connected to each analogue pin. A rough list of things I want to be reading (in rough order of importance) are:

  1. Oil pressure
  2. Oil temperature
  3. Coolant Temperature
  4. Manifold pressure
  5. RPM
  6. Knock (One sensor on each cylinder wall)
  7. Wheel speed
  8. MAF reading
  9. Intake temperatures (before turbo, hot side and cold side of intercooler)
  10. Injector Duty Cycle (With other values will allow me to monitor air/fuel ratio)
  11. CAS
  12. TPS
  13. Exhaust 02
  14. Exhaust temp
  15. Whatever else i think would be mildly interesting

The most important thing to me at the moment is being able to monitor oil pressure as I'll soon have a freshly rebuilt motor and I want to make sure I'm keeping a healthy pressure up at all times. I bought a cheap SAAS oil pressure gauge for this but realised I should be able to just tap into the factory oil pressure sensor. That's assuming the factory unit is an actual analogue sensor and not just a pressure activated switch. If not, I'll use the SAAS oil pressure sender, but connect it to the microcontroller rather than the gauge provided (or maybe both). Mind you, given this project is likely to take a while, I'll probably just end up using the SAAS gauge, but we'll see.

I'll be logging all this data to an SD card via a breakout board wiried up to the ATMEGA. Using a precision real time clock, all data will be timestamped in the log file (otherwise it's pretty much useless) and each log file will be timestamped and dated. I'm aiming for a log of each sensor 10 times a second with the data files capping out at one hour in length. However, those are just first stage estimations and I might be way off what's realistic (Depending on processing speeds and file size). Once the length of the data file has been reached or the vehicle shuts down, it will be saved and a new file created (If the vehicle is still running).

The next step is going to be working on a display. A way for me to not just log the data but view it while I'm driving. I came across this piece on ebay. A 3.2" colour touch screen LCD with an SD card slot for $10. I also found a board shield that makes this unit plug and play with the ATMEGA I already have. Unfortunately, the LCD looks like it's going to use almost all of the pins on the arduino, so I'll probably have to get a second ATMEGA (one to read sensors, and one to control the display) and setup a CAN bus network so that data can be sent between them. The CAN bus will also allow me to add in as many additional microcontrollers as I want. This screen is about the size of my phone and can be mounted under my radio (or anywhere else really). I should be able to show 2-4 sensors at a time and be able to flick between them on the fly via the touch screen capability. I should also be able to graph data and view previous values from whatever has been logged. Basically, I'll be able to do a few laps on the track, pull into the pits and go over the data for that run (Or any run that's stored on the SD) without getting out of the seat.

Unfortunately, getting this particular LCD display (and the touch screen capability) working is a bit beyond my current knowledge level, so there's plenty of reasearch to be done and I expect I'm still a while away from getting anything functioning at that level. But this will be a step by step project; I'll be aiming to get features working one at a time. So the order in which those steps are at the moment are as follows:

  1. Achieve read and write to an SD card with the ATMEGA and current SD card board
  2. Read values from either the factory or SAAS oil pressure sensors and log these files on the SD card
  3. Setup a simple display to display oil pressure in the cabin
  4. Get the LCD screen functioning on a separate, independant ATMEGA microcontroller (displaying literally anything, as long as I can can get it to display what I want)
  5. Establish communications between the two controllers via CAN bus
  6. Display sensor data from the first controller on the LCD via the CAN bus
  7. Get the touch screen functionality working on the LCD
  8. Setup the ability to access historical data logs via the touch screen LCD
  9. ????
  10. PROFIT

I'll be keeping a log book of this project as I go and I want to make this as open source as possible. I'll be posting up all my developments, code, schematics and wiring as they happen. I expect that once I'm done, anyone else out there should be able to follow what I've done and written and be able to replicate the exact same system even with no knowledge of electronics and programming. I expect that once this project is complete, the cost to replicate it will be around $50 plus the cost of whatever sensors you need to add.

Edited by Ungodlyfreak
Link to post
Share on other sites

It almost sounds like your making a homebrew Defi Advance ZD? http://www.defi-shop.com/products/advance_zd/summary_zd/

 

Which then leads me onto the knock off ones, which I have, which do alot of what your attempting to do. Would it be worth looking into one of those and then reverse engineering it in some way?

Link to post
Share on other sites

Nah. With arduino I can literally do whatever I want. There's so many code libraries out there that do most of what I want. Plus there's tons of plug and play componentry that allows me to add on extra functionality. I can make it or change it to EXACTLY the way I like it.

Hell, I could even add buttons on the steering wheel so I can play Mario.

And even a knock off would be more than $50.

...totally going to make it run doom now.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...