Same style communication, but different protocol. It still uses binary communications rather than ascii for the most part (besides the text of course), but there is a message format just like the directed/visteon units so you can set up enums for the commands to make things readable. The base message format is:
Originally Posted by justchat_1
0x5A 0xA5 XX XX YY ZZ ZZ ZZ ZZ ZZ QQ
0x5A 0xA5 is a header that is in all messages
XX XX is the length of the message ( the y's and z's only)
YY is the message identifier, which defines what the message is all about
ZZ is the actual message
QQ is a checksum
0x5A 0xA5 0x00 0x04 0x05 0x01 0x03 0xD3 0xEF
This message has 4 bytes, 0x05 0x01 0x03 0xD3.
0x05 means "Tune to station",
0x01 is FM (0x00 is AM)
0x03 0xD3 is 979, which is 97.9
0xEF is the checksum (I made the number up, since I don't have an easy checksum calc in front of me)
That's off the top of my head, so it could be wrong, but you get the idea. I'll be releasing a detailed protocol specification as soon as I figure more stuff out, and neaten it up :)
gotcha....I was just wondering if it was close enough that I could tweak it and use my directed unit to test. Looks like more effort then its worth though.
You only have to modprobe vender=0x0403 product=foo in the 2.6.28 kernel that comes with 9.04. In 9.10+ it'll just show up as a normal ttyUSBx device. Also, 9.10 and ftdi is broke. I hear they've got a fix in the "proposed" updates, but my testing has yet to prove that it works.
As for mac users, i have no idea how they are going make it work.
I had trouble getting the BoomzBox HD to work on my Intel Mac even using a Windows install on it. It appears to install but then it doesn't work. :-(
It won't work on OS X because of the FTDI driver issue.
Alright, modprobe worked thanks Kev. That could be a potential solution for Linux users, but is still not optimum. Bugbyte: I know that there is an application FTDI has that allows you to change the vendor/product ID's... so if all else fails you could get on a windows machine, use their app and change the ID's back to the proper values which would allow it to work in OSX no problems. I'm not sure how viable of a solution this is. I know Mitch has the ability to distribute an application which updates the VID/PID(He did it once to fix an mis-labeling), but I can almost guaranty he won't release a version that switches them back to the default values... but I'll ask him later anyway :/ This leaves us with each individual manually changing theirs using the FTDI Windows application as the only option for OSX users.
AFAIK, something like obdftditpty will work for it on OSX. Gary will have to confirm though.
Originally Posted by Bugbyte
I'll get together with him and play around, see what I can find, though I couldn't get the method that obdftdipty uses to work with the boomzbox.
using the default PID would be a voilation of terms with FTDI, that is for their products (usb to rs232 dongles) this is not that, this is specifically made for a specific piece of hardware
luckly in this case its just a comport, and linux fully supports custom PIDS
u just need to edit a file (i dont know which, but its known for LINUX users)
solve the problem with LINUX config
also... there is some info here
i dont know enough about linux to tell you exactly what to do
but this looks like it should help
Originally Posted by mitchjs
Huh... then I guess the GPS modules, obd2 devices, Serial hubs, Arduinos... (shall I go on) Are all in violation of the terms... I wonder how they do it... but somehow they do, and they maintain compatibility with Linux and OSX without any special tricks. All the FTDI chip is doing in your device is a usb to ttl serial converter, it's nothing special unless I'm missing something... since all the default drivers for both Linux and Windows work great.
Though thanks to trip, the Linux side seems to be up and running, OSX is just going to be an issue.
Edit: Don't get me wrong, I'm not dissing the product, it's a very nice product and I plan on putting it in my car once I get my carpc back up. I'm disagreeing with your method of implementing the FTDI setup, as it has caused me issues with integrating in other operating systems. I am well aware that you have no plans to support other operating systems, and that is your prerogative... but expect flak when you exert extra effort that happens to make things difficult :).