Announcement

Collapse
No announcement yet.

BoomzBox HD Radio. Not quite a review, more of a progress report.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • BoomzBox HD Radio. Not quite a review, more of a progress report.

    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.
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

  • #2
    sub sandwich.

    Very cool stuff. Have to say I saw this coming.
    Tidder

    Try RevFE
    The best resurrected frontend I've ever used, period.


    I Wish I could ban people

    Comment


    • #3
      Originally posted by malcom2073 View Post
      I will be releasing the source code for a control library in c#, GPL of course
      Excellent work as usual
      openMobile - An open source C# Front End (why choose openMobile?)
      - Always Recruiting Developers -
      Like what you see? Donations are always welcome

      Comment


      • #4
        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.
        Attached Files
        "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
        RevFE
        My Shop

        Comment


        • #5
          Awesome, mal! Spectacular work already! See the PM I sent you on this.
          Originally posted by ghettocruzer
          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

          Comment


          • #6
            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.

            </rant>

            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.
            "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
            RevFE
            My Shop

            Comment


            • #7
              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:

              Code:
              modeprobe ftdi_sio 0x0403 0x[other pid].
              Otherwise, chunky_ks wrote a nice userland driver that you can also use to give you a serial device.

              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.

              Comment


              • #8
                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?
                "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                RevFE
                My Shop

                Comment


                • #9
                  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.
                  Attached Files
                  "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                  RevFE
                  My Shop

                  Comment


                  • #10
                    How does the com protocol for the boomzbox compare to the directedhd or visteon hd units?
                    openMobile - An open source C# Front End (why choose openMobile?)
                    - Always Recruiting Developers -
                    Like what you see? Donations are always welcome

                    Comment


                    • #11
                      Originally posted by justchat_1 View Post
                      How does the com protocol for the boomzbox compare to the directedhd or visteon hd units?
                      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:

                      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

                      Example:


                      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
                      "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                      RevFE
                      My Shop

                      Comment


                      • #12
                        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.
                        openMobile - An open source C# Front End (why choose openMobile?)
                        - Always Recruiting Developers -
                        Like what you see? Donations are always welcome

                        Comment


                        • #13
                          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.
                          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.

                          Comment


                          • #14
                            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.
                            Originally posted by ghettocruzer
                            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

                            Comment


                            • #15
                              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.
                              "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                              RevFE
                              My Shop

                              Comment

                              Working...
                              X