Having built a few interfaces for similar things, this is no small feat. When are you planning to update us on the hardware needed to help with the software development? (I'm pretty good with designing/troubleshooting hardware...but you don't want me writing your code...it might work, but it ain't gonna be pretty.)
So I guess someone have done this software faster than I could :) I'm in the middle of work to create my own OBD2 reflash tool, I've had good progress with cheap ELM327 compatible hardware, I see no reason to build custom one. Maybe we could help each other finalize that :)
What is the largest packet size you've been able to send? I personally have done quite a bit of work with the OBDLink MX. It has the largest buffer of any of the "Dongle" type interfaces I have come across.
Great news ..kinda curious is this the same GitHub?
https://github.com/blog/2502-github-...nctuary-cities
Our work on this can be found here. It's still being filled in as we sort out every thing. Trust me.... some of the information we have been sending around the group would make your head hurt just looking at it lol. We're slowing making it so others can understand what we did, how we did it and then be able to recreate it on their own.Originally Posted by EDZIP
Currently the hardware is pretty simple. It's 4 resistors, 1 diode and 1 optocoupler. All the magic is done in the Arduino code.
I was almost sure you had used some cheap vpw transiever like motorola 33990 or similar auto grade one.
It is waste of time and effort to turn the arduino in software transiever when you can hook a simple piece of hardware to do it. Not sure how stable will be in car and off the bench test. Noise might be a big stability problem if software can`t compensate. Anyway big respect for the effort. I just want to express that it might not be the most economical approach.
VPW is 0-7 volt signal, so I guess the needed hardware is to change the 0-5 volts on the Arduino tx-rx line.
If you want to go cheaper and software only, ditch the Arduino and link the motorola transiever with 2$ usb to ttl and find a way to control the 4x switch.
The ELm is interesting and not the buffer but the main obstacle is that you cannot send hex data over it. You have to convert from ascii characters, and what a nightmare is to change the header.
Buffer size is the only limit I've ever found with the elm stuff. I've read and written Vin numbers,serial numbers,BCC codes even OS segment id codes with an elm type device in Android. I actually read a bin file out over Bluetooth with my phone last night.....trust me when i say buffer size IS it's biggest drawback. Reading 192 byte blocks takes forever
If your still stuck on the ascii to hex thing i'll give you a tip on an easy hack method I used before I learned how to change from base 10 to base16 to take care of it the conversion for me.
Write a function that does the conversion. Here's a super easy hack method. Set your input = to an output
0=0
1=1
5=5
9=9
A=42
L=4C
Q=51
Etc.....
Yes the statement will be huge and its 100% hack method to do this but it works.
Store your variable
Call the conversion function & store as a new variable
send data from the new variable.
Like I said it's a total hack but it'll work.
Pm me if you'd like to discuss them elm in more depth
So you're keeping this under wraps...just like every other LS1 flash tool that has been done so far, except Dimented24x7's, it's all "free" until it's complete and works...then it's for sale.
HPTuners, EFILive, Antus's flash tool...all of them started right down the exact same "Yeah let's get this done for free" path you're on right now. And all of them said "it's too complicated, I'll release it for free when it's done."
I'm hopeful, and still willing to work on this, but won't be surprised when this comes out to be another few hundred dollar subscription, instead of a free flash tool.
Here's some pepper to go with your salt
https://github.com/LegacyNsfw/PcmHacks
Publishing every thing myself and others have done that lead down this path would be well over a year of collective information. Forgive us for not having that much data formatted and laid out for others to understand right away. There are a number of people involved in this project and every one has the same goal. What makes this different is that no one person holds all the information. Loosing one of the core would seriously hurt our work BUT every thing they have done has been shared with others and WILL be made public before this is all said and done. If this goes belly up before we finish out work you can be sure at least ONE of the people involved will throw EVERYTHING online regardless of how clearly it's formatted just so that all our work will have been for nothing. The idea was that others could finish what we started if we are unable to.
So..... no matter what happens SOMEONE WILL BE ABLE TO FINISHING THIS.
If you search for my alias in the RomRaider.com forums you'll find a handful of open-source projects for Subaru, from tuning utilities to a speed-density implementation that has since been ported (by someone else) to a bunch of other Subarus besides my own, and a rev-matching patch that is still a work-in-progress but is also up on GitHub for anyone who wants it. Everything I contribute to this effort will be open source as well.
I got involved in this effort a couple weeks ago because I bought a Corvette a few weeks ago. If you want to see the code I've written so far, it's all at the link PeteS just posted above. It's mostly just some simple dev utilities and a prototype that we're using to discuss the design of the real app, but hey... gotta start somewhere.
There are basically three main holdups right now.
1) The flash kernel we have now was written by a guy who can't be reached. He posts as Dimented24x7 on some other forums. His job takes him offline for long periods. We have permission to USE it, but nobody thought to ask for permission to post the source publicly before he left, and it wouldn't be right to share the source without that permission. But it works. So it will appear only in the form of a long string of bytes until he gives us his blessing to post the .asm files. (Or tell us to knock it off, in which case we'd just have to write a new one. But I don't think that's likely. And he did give us a nice reference to follow...)
2) We want an interface that doesn't cost an arm and a leg. The proof-of-concept uses an AVT interface, but it's hard to come by and rather expensive. PeteS mentioned the Arduino project, that's got great potential. Hopefully it will be up on GitHub soon as well, but that's up to the guy who is developing it. I also just ordered a Scantools SX in hopes that we can make it work. If anyone else wants to pitch in with a better / cheaper / faster interface, that would be fantastic!
3) The existing app needs to be rewritten for maintainability, flexibility (it's too tightly coupled to the AVT interface), and reliability. That's where I'm focusing my time.
This will be open source when we're done. Parts might not be open source at first, but that just means that we're not done.
Hi PeteS i would be interested in a program that just lets me change vin #s on 411 conversions,etc. since my hptuners wont let between operating systems. please pm me if you can help. i dont mind paying some if i have to for your troubles
If you look back a couple of posts there is a link to the Pcm Hammer and my Android app. Both are "Read Only" but both will change a vin number with out an issue.
That's an amazing project. Just read the whole thread, very interesting!
If you guys want me to add support for all this into ALDLdroid so that you can have the read/write operations and tune editing all in one Android app over Bluetooth/USB, I might be able to do that. Just hit me up at aldldroidapp at gmail.com :)
ALDLdroid author, Android application for ALDL ECU
https://play.google.com/store/apps/d...roux.aldldroid
Like us on Facebook
Visit the app's Website
Posting Permissions
Reply With Quote
Bookmarks