Bi-directional communication functionality, a plea to change the FAQ.

[EvanCarroll]

First, thanks for listening to me. ;)

This is specifically addressing this entry in the FAQ. I wanted to urge you to reassess this while asserting that I totally 100% respect both your goals (supremely) and your position (even if we disagree),

Since I prefer AndrOBD development to stay a open source spare time project, I don't see a chance to implement any additional protocols / ECU data.

This is 100% the right conclusion. However, it doesn't follow imho that any support for additional diagnostic data within AndrOBD would: Require to change to a full time, closed source, pay app project, to pay off above efforts.

This FAQ entry is imho flawed for a lack of imagination. Just feature gate the functionality and say "patches accepted". I wouldn't knee cap your own project like that. Just imagine where Linux would be if Linus's opinion was supporting additional architectures would "require Linux to change to a full time, closed source, pay app project, to pay off above efforts."

Not to mention, it's quite possible a legislative boon somewhere in the world forces an OEM to produce the exact documentation which is absent now. If so, it's better to have the plumbing ready for new protocols.

In my case, I need ABS brake bleeding. I don't imagine it's that complex to figure this out. The $150 tables from Shenzen have APKs on them with this secret too. If someone figure it out, and submits a patch, it doesn't make sense (from my perspective) to leave that value on the table.

[fr3ts0n]

Thanks for your comments,

AndrOBD is intentionally designed to do generic OBD diagnostics for all vehicle makes and nothing more.

I understand, that you would like to have more functionality with your Mobile + ELM adapter.
I also know that this is technically feasible. Also the plumbing for new protocols is already there (in the libraries).

Since I already got some experiences in doing reverse enineering on vehicles and OEM specific functions, I had to find out that the effort of time and money spent is just too much for myself. I'd rather spend it with my family and friends.

However, since all the sources are open they can be re-used for any different purpose (i.e. OEM specific functionality) at any time. Everybody who does have the knowledge on OEM functionality, or wants to spend the effort is welcome to to do this, and create a new project/product from it as long as it meets the GPL license requirements.

I don't want to stop or slow down any innovation, but as soon as it leaves the generic OBD path I would suggest this to be done as another (cloned) project.