I don't know enough about what you are trying to do to know what kind of information is useful to you otherwise I'd be happy to help research etc. Eg. Hex addresses for fuel maps / speed limiter etc? Is that stuff useful to you?
Yes, that info is what we need. We already have a lot of it, however, we don't know if we already have what you have, so please email it to either me or EvZ. I don't think we know anything about Hicas, AT or Aircon yet.
Update Ok, so two things... Firstly, thanks to ChilledPain for letting me at his wreck. I grabbed some wiring and connectors, the ABS Control unit, and a unit that sits to the right(?) of the ECU, but I think under another unit(?). It may be the ASCD unit. Next is the write up we are going to have on our website... Diagz What?s the problem? At this time it is too hard to get all the pieces together to build a good complete in-car system. Sure you can buy cheap head-units with touch screens, whack a GPS into your car, and you?re away. But is it the one integral unit? No. Is it possible to add your own software to it? No. Is it possible to get it talking to your car?s engine management unit (ECU) to provide diagnostic and performance information? No. What are we going to do? Our aim is to provide to the 300ZX community a worthy alternative to commercial in-car systems, allowing the equivalent of a mash-up, but for in-car software. How much does it cost? This is a closed-source development project, but for the foreseeable future, will be provided free of charge. What does all this mean? We will provide discrete pieces of software that can be bolted together to provide the capabilities you need. These individual pieces can be used all together, or on their own (mostly) within an application to do the job you want. I?m still confused. Tell me straight! We will provide individual .Net Assemblies to the community free! These assemblies will target areas such as: ? Serial Communications ? ECU Abstraction ? Application Logic ? Logging ? GPS Abstraction ? Video file playback ? Audio file playback ? Hardware interfacing ? Reversing camera interface ? Web camera interface ? Real-world map interface Who is working on this project? ? Adam ? Infrastructure and project support ? Dave ? Project management and documentation ? Evan ? System design and ECU communication development Who will own the project? Adam, Dave and Evan will own the source code. Compiled source will be provided to anyone that wants it. If you can assist, let us know, and there may be a job for you. What are we being paid to do this? Nothing, nada, zip.
Closed source I for one don't really support the use of closed source in this project. Very disappointing. I sure hope that nobody steals any GPL'd code that certain people spent a long time reverse engineering hardware to develop, then use it without abiding by the derivative work licensing terms.
so long as the final version has cool looking computer game style guages as an option, im 100% behind it ...and maybe a few colour choices and a "set your own background" option with a tempplate graphic to tinker with (....ok so I'm more a front end design guy than a programmer )
You make a good point. As far as the code for communicating with the ECU goes, I've written everything from scratch, in C#, using the PLMS word document as a guide. Obviously there is information in there that someone gleaned from reverse engineering the existing hardware but as far as I can tell that information has been released as is, with no restrictions on its use. My involvement in this project is to produce a library that anyone can use to build whatever they want upon it. At the end of the day it's written in .Net so anyone could run a copy of Redgate's Reflector on it and get the full source code anyway.
Get a start using WPF then. You can have all of the fancy visuals that you want (everything skinable too). One of the core tenets of the WPF philosophy is the separation between front end design and actual programming. Get involved, the more the merrier.
The idea of Closed Source is that we, as a team, have the right to do anything we wish with it. If the project becomes as good as I hope, then we can choose to take it wherever we want. Open Source can change that, and I don't want to remove the option. As EvZ has already mentioned, the compiled assemblies will be free to whomever wants them, and as such free from licensing and cost. Our decision to go Closed Source means that we HAVE to write our own code, and as such, forces innovation upon us. In that light, I am hoping we are not tied down to someone else's design or coding practices. Your statement is usually the type of thing I hear when people espouse their view of Operating Systems. I don't want to continue down this line for fear of starting a flame war except that I see your title is in itself inflammatory, and supports my supposition. If you wish to continue this type of discussion, happy to do so via PM.
The only problem is that there isn't any WPF tools that are free. He would have to buy a copy of Expression Blend.
Here is an unfinished concept of the front end I would like... The zed in the corner is your diagnostics interface... as things go wrong, the specific area of the car (engine, HICAS, Radiator, O2 sensors etc) light up in red, with text next to it. Clicking (tapping) on the car will then open up a 3D view of the car with extra information. This view doesn't include Phone or audio info.
People still buy software? BWahahahaha. Anyhow, why not use http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License for the libraries and full GPU for the app?
i like the concept very much (looking past its current uglyness) I fully get what your talking about now. Awesome idea Still think it needs a guages option though
Guages The guages option is up to you. If you want guages then you can write them. Currently (with software you can get now) there is no way to just get the data that you might need to display with a guage. So now you can write the guages to look however you like (the new GTR dash would be a good idea) and then you get the data from the library to display in your own guages. Get to work, there's no excuses!
still keen to help out with this, i'm working on a similar project at the moment (not exactly the same but similar), but in retrospect i'd only be keen to offer my time if this was opensource.:bash:
sounds like a good project, if you can get enough people with necessary expertise to get it done. overall theres nothing too difficult in all the consult stuff, if you get stuck with anything let me know. main thing i almost forgot to do is correctly handle load or slow computers that cant keep up - i.e. dropping packets if you get behind. without that youll end up with a delay between receiving data and it showing up. that was pretty much the only thing i didnt think of also given this may be primarily for 300zx, you might consider exceeding the 20 byte sensor limit via continual request first half of sensors, stream 1 packet, stop, request the remaining, steam 1 packet, stop, repeat. most mainstream cars dont always have enough sensors to get past the 20 byte limit once i update ecutalk to .net 2.0 i was going to do some user codable gauges (main reason i couldnt do much better gauges is due to .net compact framework limitations) but not sure if there would have been anyone out there who'd actually design their own. there is the ability to use ecutalk in centrafuse via startorfocus.exe and using the LTRB gauge bounds setting, but from the sounds of it you want a more complete solution. anyway good luck!
Is there any reason you can't modify the existing libraries for OBD2 that exist in open source? Is there more of a difference between OBD1 and OBD 2 than just interface/translation difference? Or is it more the licence you want to attach to it causing the problem?
