*Shameless bump* How is this going kids? Now that I've learnt the principals of .NET at the end of last year and have started coding, this app is on my future 'to-do' list I use C#... not that it matters at all. But I find VB too verbose.
This project has stalled and it's my fault. In September '09 I temporarily moved to Singapore for work. i thought that I'd have plenty of time to dedicate to this project. As it turns out I live over the road from a 24 hour bar and 4 floors of KTV - clubs with lots of lovely ladies. When I'm faced with the choice of sitting in front of a computer (which I do all day), or walking across the road, I always take the second choice. I'm back in Aus in April and I'm hoping to pick up where we left off then. The library is about 30% complete, still a way to go, but only effort is required, there's no unknowns to slow things down. So apologies to the other guys who were involved but... There's not only girls, but cars, very rich people come to the KTV clubs which means I get to look at R8's, Aston Martins, Gallardos, Murcialagos, Porsches, Maserati, etc. ever night. It's not a bad life. I miss my Zed though
Must mention noticed three red ferrari within 15 mins time bracket in orchard road....and yes according to the description you are staying near orchard plaza....fun place to be..
I've just arrived back in Australia. Have not spoken to anyone else involved yet but I think that Dave may have started a different branch.
I've gotten myself an ECU I can connect to out of the car now. I can do some basic ECU comms, but not good enough for proper use. To be honest I haven't looked at it in about a month, but will the wet weather hitting us this week, it should prompt me to get back into it.
iPhone / iPad support There's a growing amount of people interested in using iPads for CarPCs which already have a music player, GPS and a touch screen....as well as some other bonus features like 3G internet, etc. Have any of you had a look at Monotouch? http://monotouch.net/ What is MonoTouch? MonoTouch allows developers to create C# and .NET based applications that run on Apple's iPhone, iPad, and iPod Touch devices, while taking advantage of the iPhone APIs and reusing both code and libraries that have been built for .NET, as well as existing skills. I'm hoping that in the long term it will make this library working on an iDevice a reality (though an expensive one).
The iPhone / Touch doesn't have a serial port like PC based devices. There is an Apple API for connecting to external devices but the C# library that this library uses would not be compatible with it. In reality the majority of this library is communication with the ECU via the serial port using the Consult protocol. I doubt that this library (if/when it gets finished) would ever be usable with an Apple device. Sorry
thats good news - but unfortunately irrelevant until there is a way to get the data from the consult port into the ipad?
Well, this is how the OBDII apps connect to iphones... not sure if it could be adapted at all? Kiwi WIFI http://www.plxkiwi.com/kiwiwifi/hardware.html Updated: In fact, there is a whole stack of them here... but they are all OBDII. http://devtoaster.com/products/rev/
expensive + would probably take forever to implement, which for such a small market would then cost too much to ever make the money back, and the programs would have to be re-written to use wifi (rather than working as-is). unless something like the redpark serial cable for iphone/ipad is ever developed, i very much double we'll ever see consult on apple stuff - you wouldnt bother when you could buy a complete non-apple setup for less probably. only people to blame is apple, they want to make $$$ off anything and everything thats used on their products - just look how they had to use wifi just to get data in/out of the apple - no ability to use the serial port, or bluetooth. i know a lot of software developers who wont touch apple stuff just on the principle of how apple like to bend everyone over and make money off everything, and secondarily cause its not financially viable due to the restrictions.
I see your point there, which is a shame as it's the brick wall I keep hitting here. At the end of the day it comes back to a hobbyist and what he/she is willing to do to achieve whatever it is they're after. The only (rather bad) solution I can think of that isn't Apple specific, is using a small car pc with a regular consult cable and WIFI connection hosting the information on a web server. That way assuming the library is ever created, iPhones, iPads, Android phones or whatever else could view the information in a web browser, instead of displaying it in Windows forms or whatever. You could even have some remote diagnostic possibilities with a 3G connection too...
that would again probably come back to cost to user - having to buy a carpc (if they didnt have one already) just so the data can be shown on the ipad/iphone, which is hardly convenient (when the car is being driven, i.e. 95% of the time), compared to showing it on the carpc screen.
ECUTalk for Android/iPhone apps... Any chance of creating a version of ECUTalk or similar for Android/iOS phones? Would be very handy to have that app on my phone... Rob.
No chance. Incidentally, if someone was to do it, how would you expect to connect your phone to the car's consult port?
Yeah, read upwards in the thread. Already discussed in length as a financially crippling and frustrating idea. Easier to buy a 96+ 300zx with OBD II I think..
or just the ECU from a 96+ ZX (assuming other electrical stuff/pinout is compatible). bluetooth would be the only option really, but generally theres been a pretty dismal success rate with bluetooth adaptors for consult, and the ones that work havent been cheap.
Update! Ok, so here's an update (a couple of years late)... Recently I lost my job and I wanted to resurrect this project. When I got around to it, I couldn't get my testbed ECU to work. So, I borrowed one and then found my cable still works. Further investigation shows that my TT manual ECU has (had!) a TT Auto Nistune board in it which causes it to not respond to my ECU connection attempts. Hopefully no damage, and I will fix this problem in the fullness of time. Anyway, I digress - as I said, I now have a testbed working... Right now, I have .NET 4.0 code (C#) (VS 2012) that performs the following: Connects to ECU Reads Part number Reads fault codes Next on the list: 1. Clear fault codes 2. Read sensors 3. Run tests (Idle adjust, etc) 4. Read ROM 5. Modify ROM (temporarily of course) 6. [more] On the horizon is the following: Convert to C++ for Arduino (probably) Convert to NETMF for Netduino and GHI devices Down convert to .NET Framework 2.0 (to allow Windows 98+ access to any final solutions) [more] I am aiming for a full-featured solution. Notes: At this stage I am the only person working on this, and I'm happy with that arrangement. My resultant code will work on any version of Windows that can take .NET Framework version 4. I currently have no plans to release the source code. (However that does not mean that I will not be releasing the binary files to the community) If any of this doesn't make sense, sorry.
