Jump to content

  •  

  • Welcome to

    Hello and welcome to SilviaWA, You will require an account to use selected sections of our forums, you can register an account by clicking the register button at the top of the screen.

    Photo

    DIY data monitoring via arduino microcontroller


    • Please log in to reply
    13 replies to this topic

    #1 Ungodlyfreak

    Ungodlyfreak

      Q's Spec

    • Inactive
    • PipPipPip
    • 232 posts
    • Name:Israel
    • Gender:Male
    • Location:South-East Hills
    • Cars:
      S15
    • Joined: 24-June 14

    Posted 26 May 2016 - 10:06 AM

    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.


    Israel
    Perth
    S15


    #2 3lite

    3lite

      Bought NOT Built

    • Inactive
    • PipPipPipPipPipPipPipPipPip
    • 1,320 posts
    • Name:James
    • Gender:Male
    • Location:The Vines/NOR
    • Cars:
      SG5 Florister XT
      180sx Ugly Duckling
    • Joined: 17-April 07

    Posted 26 May 2016 - 11:48 AM

    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!!!!


    Name: James

    Location: Wine Country

    Cars of Old: 1992 180sx (Hulk Boot), Kouki S14 of WIN!, Ebisu Sil80, S15NA S13, HakunaMiata NA6 MX5, Florester XT (Cresh!), Adopted 180sx Trouble Child, 1997 Mr Miragi (RIP-2016)

    Cars of Now: 2015 Isuzu D-Max, 1989 BMW E30 M52B28


    #3 SR14WA

    SR14WA

      Gomu Gomu No DORIFTO

    • Admin
    • PipPipPipPipPipPipPipPipPip
    • 2,509 posts
    • Name:Lee
    • Gender:Male
    • Location:Hobart, Tas
    • Cars:
      1997 Nissan Silvia S14
      1991 Nissan 180SX
    • Joined: 22-February 11

    Posted 27 May 2016 - 09:14 AM

    Not that it would make much difference but silvias are obd not obd2. A lot less metrics come across in obd.

    #4 Munt.

    Munt.

      Custom Spec

    • Inactive
    • PipPipPipPipPipPipPipPipPip
    • 2,580 posts
    • Name:Matt
    • Gender:Male
    • Location:SOR
    • Cars:
      S14A
      WGNC34
      Old Holdens
    • Joined: 28-December 09

    Posted 27 May 2016 - 11:45 AM

    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., 27 May 2016 - 11:47 AM.

    Name: Matt
    SOR
    S14+WGNC34

    [18:22] what happen if munt wants to do a burnout before the oil warms up?
    [18:23] <@kev> the world divides by zero and we all perish in a worm hole


    #5 VFR15

    VFR15

      J's Spec

    • Inactive
    • Pip
    • 64 posts
    • Name:Julio Menedez
    • Gender:Male
    • Location:mexico city
    • Cars:
      esse15
    • Joined: 30-August 12

    Posted 27 May 2016 - 12:11 PM

    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.trackelec...om.au/consultbt

     

    I use this method for datalogging in Nistune:

    http://forum.nistune...opic.php?t=1279



    #6 Munt.

    Munt.

      Custom Spec

    • Inactive
    • PipPipPipPipPipPipPipPipPip
    • 2,580 posts
    • Name:Matt
    • Gender:Male
    • Location:SOR
    • Cars:
      S14A
      WGNC34
      Old Holdens
    • Joined: 28-December 09

    Posted 27 May 2016 - 12:32 PM

    Nice i didnt know someone made a consult to BT. I was looking at wiring a module onto my consult cable to get BT but i just bought a haltech so it wont be happening

    https://www.adafruit.com/products/1588

    Dont see why it wouldnt work

    Edited by Munt., 27 May 2016 - 12:33 PM.

    Name: Matt
    SOR
    S14+WGNC34

    [18:22] what happen if munt wants to do a burnout before the oil warms up?
    [18:23] <@kev> the world divides by zero and we all perish in a worm hole


    #7 ONETEN

    ONETEN

      Custom Spec

    • Inactive
    • PipPipPipPipPipPipPipPipPip
    • 1,144 posts
    • Name:Hayden
    • Gender:Male
    • Location:Woodvale
    • Cars:
      M35 Stagea
      Datsun 1200
      Evo 3
    • Joined: 21-September 09

    Posted 27 May 2016 - 03:02 PM

    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.plmsdevel...nds_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.


    Whizzit_160px.png
     


    #8 ONETEN

    ONETEN

      Custom Spec

    • Inactive
    • PipPipPipPipPipPipPipPipPip
    • 1,144 posts
    • Name:Hayden
    • Gender:Male
    • Location:Woodvale
    • Cars:
      M35 Stagea
      Datsun 1200
      Evo 3
    • Joined: 21-September 09

    Posted 27 May 2016 - 03:07 PM

    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 :(


    Whizzit_160px.png
     


    #9 3lite

    3lite

      Bought NOT Built

    • Inactive
    • PipPipPipPipPipPipPipPipPip
    • 1,320 posts
    • Name:James
    • Gender:Male
    • Location:The Vines/NOR
    • Cars:
      SG5 Florister XT
      180sx Ugly Duckling
    • Joined: 17-April 07

    Posted 30 May 2016 - 11:21 AM

    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!


    Name: James

    Location: Wine Country

    Cars of Old: 1992 180sx (Hulk Boot), Kouki S14 of WIN!, Ebisu Sil80, S15NA S13, HakunaMiata NA6 MX5, Florester XT (Cresh!), Adopted 180sx Trouble Child, 1997 Mr Miragi (RIP-2016)

    Cars of Now: 2015 Isuzu D-Max, 1989 BMW E30 M52B28


    #10 Ungodlyfreak

    Ungodlyfreak

      Q's Spec

    • Inactive
    • PipPipPip
    • 232 posts
    • Name:Israel
    • Gender:Male
    • Location:South-East Hills
    • Cars:
      S15
    • Joined: 24-June 14

    Posted 04 June 2016 - 02:08 AM

    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.


    Israel
    Perth
    S15


    #11 Ungodlyfreak

    Ungodlyfreak

      Q's Spec

    • Inactive
    • PipPipPip
    • 232 posts
    • Name:Israel
    • Gender:Male
    • Location:South-East Hills
    • Cars:
      S15
    • Joined: 24-June 14

    Posted 15 September 2016 - 10:34 PM

    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, 15 September 2016 - 10:34 PM.

    Israel
    Perth
    S15


    #12 SR14WA

    SR14WA

      Gomu Gomu No DORIFTO

    • Admin
    • PipPipPipPipPipPipPipPipPip
    • 2,509 posts
    • Name:Lee
    • Gender:Male
    • Location:Hobart, Tas
    • Cars:
      1997 Nissan Silvia S14
      1991 Nissan 180SX
    • Joined: 22-February 11

    Posted 16 September 2016 - 09:56 AM

    It almost sounds like your making a homebrew Defi Advance ZD? http://www.defi-shop..._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?



    #13 Ungodlyfreak

    Ungodlyfreak

      Q's Spec

    • Inactive
    • PipPipPip
    • 232 posts
    • Name:Israel
    • Gender:Male
    • Location:South-East Hills
    • Cars:
      S15
    • Joined: 24-June 14

    Posted 17 September 2016 - 12:46 AM

    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.

    Israel
    Perth
    S15


    #14 datman55

    datman55

      Q's Spec

    • Inactive
    • PipPipPip
    • 154 posts
    • Name:Mark
    • Gender:Male
    • Location:Swan Valley
    • Cars:
      Past - SR20DET powered Datsun Sunny (race car)
      Present - VW Amarok
      Future - S15 (track car)
    • Joined: 26-September 10

    Posted 17 September 2016 - 06:16 AM

    I remember the days when I had enough spare time to tackle things like this....... Good luck with the project. Keep us updated.






    0 user(s) are reading this topic

    0 members, 0 guests, 0 anonymous users