Page 1 of 4 1234 LastLast
Results 1 to 10 of 36

Thread: Voyager: Bluetooth OBDii for the Droid

  1. #1
    Low Bitrate
    Join Date
    Dec 2009
    Posts
    78

    Voyager: Bluetooth OBDii for the Droid

    Project name: Voyager:

    This is a little project I'm working on to connect my Droid phone with my vehicle through Bluetooth.

    So far the project is a great success. The only bottle neck is designing (learning curve, grrr) the user interface. All mode 01 codes are working great at this point.

    Right now I'm working to enhance the user interface. I'm thinking of decoupling the user interface from my communications logic so that anybody can write a user interface by making a TCP/IP connection to the Voyager service. Anybody interested?



    As we can see in the screenshot, the data is there, it just needs to be presented to the user in an appealing format.

    I've written the code with future enhancements in mind so the sky is the limit. If you have an idea feel free to request it in this thread and we can discuss.

  2. #2
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Great job so far! I like the idea of disconnecting the UI from the comm logic. In fact, this is along the lines of what we aim to to with the OSDash project. For example, there could be an "OBDII user interface" service that is drawn upon when you run the program.

    Other users on different phones could use the interface even if they weren't running Voyager on a Droid. Several different interfaces could be designed and the user can choose them from the web interface.

    If you're interested, head over to the OSDash forum and see what the deal is. There's already a VIN and DTC web service proposed. These two could work together to compliment each other.
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  3. #3
    Confusion Master
    Auto Apps:loading...
    Enforcer's Avatar
    Join Date
    Sep 2003
    Location
    If you go down to the woods today, You're sure of
    Posts
    14,629
    Moved to Software & Software Development.

    Show off your projects is basically for CarPC installs etc.

  4. #4
    Constant Bitrate chronoglass's Avatar
    Join Date
    Nov 2009
    Posts
    91
    man, add the ability to accept input from a second touchscreen monitor, and play files from a usb hard drive, then FB support.. and i just wasted money on trying to get an actual computer in my car..
    that's kinda depressing.
    but really exciting too.
    ---------
    I'll do the bumbling, and i'll be the idiot.
    if you've got a "stupid" question, search for some of mine!

  5. #5
    Low Bitrate
    Join Date
    Dec 2009
    Posts
    78
    Quote Originally Posted by Bugbyte View Post
    Great job so far! I like the idea of disconnecting the UI from the comm logic. In fact, this is along the lines of what we aim to to with the OSDash project. For example, there could be an "OBDII user interface" service that is drawn upon when you run the program.

    Other users on different phones could use the interface even if they weren't running Voyager on a Droid. Several different interfaces could be designed and the user can choose them from the web interface.
    Great perspective, thanks! I am still trying to wrap my head around OSDash, FB. etc. A lot of progress has been made by other users and I think it is beneficial for new apps to mesh with the existing framework. I'll continue to get up to speed and do what I can to "mesh".

  6. #6
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Right, so the basic idea would be to write the platform specific code for the Droid. Then, the skin could be supplied by the service. Obviously, you could code a default skin but with the web service, and people could select different skins using the web interface for OSDash. With user ID and password in place, you would store your personal settings.

    Since a VIN and DTC lookup service is proposed for OSDash, you could add that to your app without rolling your own.

    If someone writes a car maintenance and tracking service, again, you could use your app to supply OBD information to that service or use that service to supply your app with info, if it applies.

    Nobody has stepped up to write a client for the Droid yet but since the Linux client is open source, maybe someone will use that as a starting point and we can supply OSDash services to the Droid community.
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  7. #7
    Low Bitrate
    Join Date
    Dec 2009
    Posts
    78
    Although what you are explaining sounds more like a Droid front-end for OSDash, I think it would be possible to have a single UI for OSDash and Voyager after I separate the Voyager UI from the Voyager Service.

    For the short term, it may be best to keep Voyager focused on Droid + Bluetooth + OBDii and spin it as "Droid is the carputer", and save "Droid connects to the carputer" for a future, fun project.

    Some long-term goals I have for Voyager:
    * Add support for vehicle specific OBD codes for things beyond the basic mode-1 PIDs
    * Analysis - analyze historical data and provide summaries and reporting
    * Add a timepedia chronoscope to view historical data on composite graphs (Load versus speed for example).
    * High-level diagnostics - one example might be to tell that the air filter is due to be replaced, based on historical datapoints from the appropriate mode-1 PID or PIDs combined.
    * Calculate vehicle weight, power, acceleration profile, etc etc.
    * Interface to a central database which stores vehicle metrics, statistics, trip info, etc. for reporting and data mining.
    * Interface with GM Driver Information Center (the dot matrix display in the dash)
    * Interface with OnStar, anything else on the CAN network.

  8. #8
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Sorry, not trying to throw you off track there. OSDash isn't a front end. It is a project to implement web services that can be used by whoever for whatever they want. Sure, front ends can use it but so can standalone apps. The idea is to write once, share across platforms. The mobile hobbyist universe is too small to have to reinvent the wheel all the time.

    In your case, support for vehicle specific OBD codes would be something that you could use an OSDash service to retrieve.

    The central database stuff would make a good OSDash service as well but hasn't been proposed by anyone yet.

    Keep up the good work!
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  9. #9
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by regulatre View Post
    Although what you are explaining sounds more like a Droid front-end for OSDash, I think it would be possible to have a single UI for OSDash and Voyager after I separate the Voyager UI from the Voyager Service.

    For the short term, it may be best to keep Voyager focused on Droid + Bluetooth + OBDii and spin it as "Droid is the carputer", and save "Droid connects to the carputer" for a future, fun project.

    Some long-term goals I have for Voyager:
    * Add support for vehicle specific OBD codes for things beyond the basic mode-1 PIDs
    * High-level diagnostics - one example might be to tell that the air filter is due to be replaced, based on historical datapoints from the appropriate mode-1 PID or PIDs combined.
    No need to re-invent the wheel: OpenOBD (yup another subproject)

    And like bugbyte said these features will be available from the OSDash project.

  10. #10
    Low Bitrate
    Join Date
    Dec 2009
    Posts
    78
    Aah I'm getting up to speed, slowly . OSDash has a web component that Voyager could interface with to obtain information and upload information, thus offloading the amount of stuff (Logic and stored data) that has to be packaged with the app.

    If the OBD data could be uploaded to an OSDash web server then some of the analytics I proposed might be carried out from the OSDash web site. Users might even have an option to compare their vehicle's performance to others' with the same year/make of car.

    Thanks BugByte!

Page 1 of 4 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •