Very cool stuff. Have to say I saw this coming.
Every month, mp3car selects someone to receive an "Innovation Grant". That is, they give a piece of hardware or software to a community member in an effort to help spawn innovation and creativity among the community. They were nice enough to choose me to receive one of their brand new shiny BoomzBox HD radios. First off I want to say thanks! Upon receiving it, the first thing I did of course was plug it in and try to get it up and running. After some initial issues with the drivers I opened up the interface box to see what was inside. It has a FTDI interface chip and a TI Analog to Digital USB chip, both on a FTDI USB hub. So of course I replaced the drivers included with the radio with the official FTDI drivers for the two FTDI chips and had no further driver related issues. Control for the device is over virtual com port (serial), and audio shows up as another input ("USB Audio Codec"). This of course leads to some interesting audio issues writing my own test app, however let's start by using the radio as it was originally intended before I go off on a tangent.
I started the application that came with the radio and the radio works as expected... audio over usb and all that. Pretty simple stuff and fairly easy to play around with. It locks on to HD Stations quickly even with a wire antenna and the sound quality is good for radio. I used it to listen to radio for about an hour and the box wasn't even warm to the touch, so heat should not be an issue. I decided that it was about time that I should start trying to decode the protocol and get at least a rudimentary third party application up and running in an effort to get this thing into Linux and OSX as I promised.
Fortunately when you first connect to the radio, it turns on with the previous settings (Station, volume, etc). This means I could set it to a station in the "official" application, close the program, and start up mine. This let me figure out how to pipe audio from the input over to the output, which was a hassle, but quite successful. I learned that you should not turn on the audio until after the radio starts up as you will hear some garbage and popping but that's easily fixed by delaying audio startup by a second or so.
After trying unsuccessfully to get some kind of official help with the protocol (Very amusing for reasons a few people here are aware of) I decided to figure it out myself. I loaded up my friendly Portmon serial port monitoring utility, which on a side note is a favorite second only to a hardware logic analyzer for decoding serial protocols. I went to town playing around with the official application. After a few captures, and some tinkering around I've managed to get the radio up and running, switching stations, even reading RDS and HDText in my own application. Woot!
I will be releasing the source code for a control library in c#, GPL of course since the SDK will likely not be open if past experience is any indication, and therefor incompatible with GPL. I may consider LGPL if there is enough interest in integrating it in closed source apps. I will also be porting this to a c++ library for both Linux and OSX, and am more than willing to work with any OSX Frontend developers on integrating it into their frontend.
Also If anyone is interested, I will also be releasing some of my notes on the protocol, as well as documentation as to what does what, and in what sequence as I've found out. Just in case anyone wants to write their own library, and doesn't want to dig through mine.
Well there you have it, the Mp3car BoomzBox HD from a programmers perspective. Not nearly as difficult as I thought it would be, but all in all a very enjoyable unit. If anyone writing a frontend is interested in integration before I get the library released, I can give you the heads up on what kind of interface the it will have so you can start in on integration before I am finished with it, just let me know.
Very cool stuff. Have to say I saw this coming.
The best resurrected frontend I've ever used, period.
I've completed the first revision of the interface, it's attached here if anyone wants to play around with it. I'm still working on putting in error checking and cleaning it up, but I think I have the implemented interface fairly solid. There are still a few things I have to add, like mute, volume, and AM (The lib only supports FM at the moment). I'm also thinking about having the library save station information so you can browse by station name as the information gets filled out via RDS and HDText.
Very simplistic example code below:
Code:HDRadioControl radioControl = new HDRadioControl(); radioControl.setPort("COM4"); radioControl.PowerOn(); // Radio turns on, and starts playing the previously loaded station radioControl.tune(979); //tune to 97.9FM,this station has 3 HD channels radioControl.selectNextHD(); //Listen to some music for a while radioControl.PowerOff();
The attached zip file contains the library in source form, which I am releasing GPLv3 or later. I'll work on polishing up my test application to give people are more in depth example of how to handle the callbacks and different functions of the library. I'll also soon be posting a documentation detailing the protocol as I've discovered so far for anyone who is curious.
Alright, so it seems that whoever build the interface box (As far as I can tell, that was Mitchjs... so sorry Mitch but you're going to get the brunt of my anger here) changed the FTDI productid on the FTDI serial converter chip. That is by far the stupidest and most ignorant thing I've ever seen done on a hardware level. In windows it is an easy fix of editing the .inf files of the official FTDI drivers to get them to install, and it didn't occur to me that I would run into issues in linux, but I did.
So by changing the product ID, this device has been locked to using proprietary drivers. There was ZERO reason to do this other than so people would be required to use Mitch's drivers, I'm looking into fixing this on a software level, but the linux kernel module is locked to the three main FTDI serial module product id's, because there is no reason to support other ID's. Anything using these three pid's is compatable with the driver, anything not using them isn't.
But wait, there HAS to be a reason for releasing custom drivers.., and yes there are legitimate reasons, which is why they provide the provision for setting your own ProductID. The reason for this is if you implement custom functionality that the default driver does not support. Guess what? The default drivers work fine, so there is no custom functionality which justifies a custom driver. Shock!
After doing some research I found that it is possible to edit the productid in software. I will be looking into how to do this, and release a program to change the productID of the chip inside the converter box back to the proper productid which will allow it to work out of the box on both Linux and OSX. What does this mean? It means that people will be able to use the proper FTDI drivers in windows, and Mitchjs's drivers will no longer work.
As a quick fix, I can recompile the linux kernel module ftdi-sio with the special product id's, and that will make it work, but that's hardly a fix I want to push on everyone. Changing the product id of the hardware back to the factor setting is likely the way to go so default modules work fine.
I'm frankly glad he/whoever changed the product id. How many devices are ftdi-based and don't do this? a lot. It make plug-and-play a nightmare. When they are the same, I don't know if that ftdi device is a gps receiver, a scantool, or the boomzbox.
You should be able to modprobe the ftdi driver and tell it what product to use:
Otherwise, chunky_ks wrote a nice userland driver that you can also use to give you a serial device.Code:modeprobe ftdi_sio 0x0403 0x[other pid].
Code:obdftdipty -V 0x0403 -D 0x[PID] -d
Former author of LinuxICE, nghost, nobdy.
Current author of Automotive Message Broker (AMB).
Works on Tizen IVI. Does not represent anyone or anything but himself.
Kev: What kernel version was that feature introduced in? I'm still using Ubuntu 9.04, and the last kernel released for it does not have this feature.
I can see where you would find that easier, however like in windows, you generally point an application to whatever com port (or ttyUSB) the device is plugged in to. Wheras with that method, you require users to modprobe, find out which device it attached to, and... oh wait... STILL point the application to the proper port.
Edit: What about Mac users? Has this ftdi feature been ported there yet?
Here's a test application for the radio library, written in c# for anyone who is interested. I'd be very interested in hearing if this works for people who have the radio. in the bin\release\ folder there is a working executable.