Thread: Frontend - Comprehensive Features Comparison

Originally Posted by malcom2073

Maybe I will have to make it support aldl

ChunkyKs can confirm this, but I believe that if you had something that read the port/sensors on the aldl protocol and exported them via DBus signals, obdsim + obdgpslogger can then relay it to the listening obd-II app. Probably much easier than writing the aldl interface layer AND the GUI and you get logging and cool exporting as a bonus by using obdgpslogger as well. The end user also has the freedom to use any compatible GUI app as well.

ALDL is a protocol similar to ISO-9141, not sure what you mean by reading the port/sensors. Sure you could tie directly into the sensors, but for those of us that don't want to hack up the ECU harness buying an ALDL reader and using a plugin.

CF:

Design: Monolithic Frontend with Plugin Support
Cost: $125 / How did you get $300.00!!!!!!!!!!!! Do not get the nav version it sucks because of destinator.
Skinning System: Behavioral, XML, Image based ?
Navigation: Yes
OBD-II: Yes
Fusion Brain Support: I think so

Media:
Media Browser Type: ID3 Metadata sorting
Playlist Editor: Yes
Supports UPnP Streams: ?
Bluetooth Streams: Only phone support
HD Radio: Yes
Satellite Radio: Yes
Multi screen support: Yes

Its also very easy to skin. CF3 will have support to use any Nav engine and embed it into CF. Flux realizes that Destinator sucks. Also multi screen support is going to be beefed up to also support multizone audio. So if users in the front are listening to something, the rear can listen to something different. A Windows CE version is in the works to work on CE devices, like pocket PC and hopefully CE based headunits. Thin clients also work with CF CE. Also CF3 will use a really good graphics engine with nice transissions and what not. http://forums.fluxmedia.net/centrafu...3-youtube.html There are alot more things I can list but I wont kill you with every detail.

fixerofallthing: ALDL actually had three different connectors depending on the year and vehicle, it's only a semi-standardized protocol, but for the most part it's all single wire 0-12v serial. The only difference between vehicles is what data is actually returned.

Originally Posted by malcom2073

fixerofallthings: Go look at a GM Technical manual for any car equipped with ALDL before you start making statements about it as to not confuse people. Thanks.

Let thread get back on track. I deleted my posts so I do not confuse you. Search for ALDL and read up so others are not confused. Sorry to bother you.

ChunkyKs can confirm this, but I believe that if you had something that read the port/sensors on the aldl protocol and exported them via DBus signals, obdsim + obdgpslogger can then relay it to the listening obd-II app. Probably much easier than writing the aldl interface layer AND the GUI and you get logging and cool exporting as a bonus by using obdgpslogger as well. The end user also has the freedom to use any compatible GUI app as well.

Disclaimer: I know almost nothing about ALDL.

You don't necessarily have to use dbus to work with obdsim. If you like, you could also write an ALDL module for obdsim [I will gladly add it to obdgpslogger's repo].

I think it's worth noting that if you just export dbus signals from a daemon, you can use obdsim + obdgpslogger to kind of normalise the signals - this way the nghost guys need only read obdgpslogger signals.

Or, alternatively, if you were to write an aldl tool that exports dbus signals signals from a daemon, nghost could work with those signals directly - no need to work with obdsim or obdgpslogger at all. Really, I think it depends on what you desire, what features of ALDL you want to see in use and supported.

Obviously I'm somewhat biased, but I think that obdsim is a great tool that can save lots of effort, if you write modules for it instead of doing more stuff yourself :-)

Gary (-;

I added Rev (carpal) to the list. I won't add anymore for the sake of space. When we actually get this in the wiki, we can add more frontends as needed.

I also added bluetooth phone support feature since that seems like a pretty big one and Graphics Backend for the sake of the "eye-candy" feature.

I still need clarification on RR and CF where there are question marks.

Oh, and I renamed the thread to something that makes more sense now that Rev is included.

CF's graphics backend is DirectX if I recall correctly.

RR:
Design: Monolithic Skin-Engine with plugins for Audio/Video/DVD and to extend functionality.
Cost: Free for personal use.
Skinning System: Comma Delimited, Image, Object and Command Based with Flash Support.
Navigation: Yes
OBD-II: Yes (External App/Plugin)
Fusion Brain Support: Yes
Bluetooth Phone Support: Yes
TV Support: Yes
AM/FM Radio Support: Yes
External Application Support: Yes
Graphics Backend: GDI, GDI+ and DirectX
Audio Backend: Winamp/WMP/FMOD/Foobar2000/iTunes/more can be made
Video/DVD BackEnd: Built-In/WMP/MPC/VLC/MSVid/more can be made

Media:
Media Browser Type: File/Folder defined by skin and settings
Playlist Editor: Yes
Supports UPnP: Solely depends on player choice
Bluetooth Streams: By hardware or plugin only
HD Radio: Yes
Satellite Radio: Yes (Sirius & XM)

Documented API: Yes
Native Language: VB6
Language Support: All/Any
OS Support: Windows 98SE/ME/2000/XP/Vista/Win7
Open Source: No, but developers are welcome to join development team.