Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Hardware

Specifications for Alpine's M-BUS Protocol? 20

Posted by Cliff from the unrevelling-the-machine's-dialog dept.
An Anonymous Coward asks: "Like every geek on the planet, I have attempted to create a slick, well integrated MP3 player for my car. I have the unit in place, a biscuit pc running of a dc power supply that is ACC line aware, wireless 802.11 to download music from my home server when parked in the driveway, and it sends its sound signal to the receiver via the Alpine cd changer connector in my car. What I have looked for religiously is the specification for the Alpine M-BUS protocol so I can cleanly integrate it with my in-dash Alpine receiver. I see lots of questions but no answers when I search the web and newsgroups. Any one out there reverse engineered this spec? I just want to know before I go try to reverse engineer it myself." I've gotta admit, the 802.11 extension is a new twist on the traditional car MP3 player! Pretty slick, that. Are there any projects currently in the works to reverse engineer the M-BUS protocol, or will our anonymous friend here need to start this off on his own?
This discussion has been archived. No new comments can be posted.

Specifications for Alpine's M-BUS Protocol? More

Specifications for Alpine's M-BUS Protocol?

Comments Filter:
  • I've been keeping an eye on these guys [phatnoise.com] for a while, after searching for a spec for the Sony changer protocol, for similar reasons.

    They currently have a changer box that will talk to Kenwood head units, and takes hard-disk cartridges. They claim to have have compatibility for other brands (Sony, Alpine etc) in the works.

    Nice looking kit, too.

  • *snip*
    ...
    wireless 802.11 to download music from my home server when parked in the driveway
    ...
    *snip*
    ...
    I've gotta admit, the 802.11 extension is a new twist on the traditional car MP3 player!
    ...
    *snip*

    Does this mean that when going on long trips (and even around town, I guess), you could download/trade songs from neighboring vehicles? Napster-on-the-go, anyone?

    Seriously though, how could we implement something like this? I'm trying to figure out how this would work, using my Linux background as a basis for information. Since there really wouldn't/couldn't be a centralized server, it would be up to the individual vehicles to negotiate connections with each other. I guess some sort of daemon performing a multicast broadcast to announce availability every few seconds would be needed to share the files, and then a client listening for those broadcasts and handling the connection for those wishing to search for and download files. Of course, some type of MD5SUM or something would have to be generated for each file to do integrity checking, and the thought of using something like rsync just popped into my head. I think I like that idea better. I'm actually surprised more of these file sharing programs don't use rsync, a well-established download-and-resume-incomplete-files protocol (or do they, and I just don't know?). Considering you'll be going in and out of range of vehicles quickly and frequently, I think resume is important, especially with an MD5SUM system, so you can resume the same file from a different vehicle.

    Once that's in place, I guess you need to think about the interface.. not really too easy to do on an in-dash system (especially while driving!). That is one of the bigger headaches.

    Okay, here's a plan.. someone feel like developing it? Let me know if you do.

    Oh, by the way, if you decide to use this idea, it better be an open protocol/standard/codec and open sourced, or I'll come after you. I'm tired of proprietary junk.

    • or... you could ice/shout/honk?cast mp3/vorbis streams from your car...
      • Wow, another interesting possibility I hadn't even considered. Roaming radio stations.

        That'd be pretty cool.. although for people like me who ride with grrrls who sit there and do nothing but change radio stations to look for that one song they want to hear, that would be a nightmare.. thousands of stations to choose from, and they change every couple of minutes..
    • Quit with the stealing and do something good with your skills.

    • a friend of mine and I did this a while ago kinda, but not nearly as cool as you're saying (we weren't moving, etc).

      We took two Acer Warplink cards and hacked together a basic client-server system (one of us was set as the service, one client, but if we had continued work on it there would probably have been some kind of election process, etc). When I went over to his place I'd leave my laptop based MP3 player running (as did he) and our music would synchronize between each other, not too hard.

      The problems in extenting the capabilities are great, though. One, if you want to use wireless like this, you either need to use something like TCP/IP and be on the same subnet, use netbeui and deal with "chatter" or write some new protocol. DHCP is a distinct possibility, though the clients would probably have to tell their rigs to refresh addresses explicitly.

      The cards we used were slow... sloowww.... like 100-125 kbps if we were lucky and they didn't suffer distances over 300 feet and didn't seem to deal with Doppler shifts very well.. but then again, these cards are shite and can be had on ebay for 40 bucks (I DO NOT recommend them). 802.11b/a are probably better.

      Due to the limited range of ye olde average wavelan card, I'd say transfering music while driving isn't a possibility for a few more years unless you were willing to maintain a static speed while transfers were taking place. If 802.11 in cars becomes more prevalent you could institute a routed/ping-pong system, but that would max out the effective bandwidth pretty fast. But it would be damn cool to transfer files over a relay-p2p highway network.

      It could work with a request/response system (human-wise, I;m talking) where the cars co-pilot would send a message to a vehicle near them asking for them to stay stationary relative to them while they traded songs, but I'm not sure people are that social.

      For now the best way would be to have servers set up near places like parking lots, etc, where people can stay still for long periods of time.


      (if you wanna see my car as it is now (sans wireless networking), go here [pyxidis.org].

  • gives new meaning to wardriving... (Score:3, Funny)

    by spike666 ( 170947 ) on Friday December 07, 2001 @10:17AM (#2670438) Journal
    just think. if you integrated a decent text to speech system, you could have the car tell you "dave, i'm sorry, i cant snort that WEP key if you drive this fast"
    or...
    "well here's another unsecured network! oh look! he's surfing goatse.cx !"
    or...
    "well we now have his passport account information, shall we go buy me a new set of tires?"
  • We want to see what you built! Post the specs, and some pictures, damnit!
  • ...contacting Alpine?

    I know it sounds stupid, but it couldn't hurt - since you have already come so far, explain it to them, and what you want to do - hell, they may want to help you for promotional reasons (you may want to mention this to them). Or, you may have to buy the spec (which may be cheap - or could be INSANELY expensive).

    If they flat out won't help, then you have lost nothing. Go ahead and RE it...

    I can't imagine that they won't help in some way - why create the interface and publicize it, if it is proprietary and only used by them anyway? I would think they have created it to allow third party manufacturers to interface to it (maybe find who those manufacturers are, and contact them as well).
    • why create the interface and publicize it, if it is proprietary and only used by them anyway?

      Isn't that obvious? If they published the spec you wouldn't have to use an Alpine CD changer. It's called vendor lockin.

      • I realize this, but why go out of the way to name the spec, and publicize what it can do (ie, spend money on marketing the name of it), if it is only going to be used for your products?

        Seems like a waste of money - I mean, as a business, would you proclaim:

        "And our new widget utilises ConnectLinkX for superior interfacing"

        And then not give out the spec, and make all of your products "ConnectLinkX" compatible (like that wouldn't be obvious to a consumer), then market the shit out of "ConnectLinkX" (ie, spend the money on marketing), or would you proclaim:

        "Works with our other cool widgets"

        And then put that on each box, maybe say it a bit, and save the money that would go to marketing.

        I guess I can see your point, but consumers would have to be STUPID, STUPID, STUPID - not to realize the lockin!

        It would be like buying a car that only uses "BrandX" gas - "Cool, where do I sign up?".

        Maybe consumers are that dumb...

  • No alpine.. but Changer protocls for a few others (Score:3, Informative)

    by mfarver ( 43681 ) on Friday December 07, 2001 @02:48PM (#2671887) Journal
    This guy has pinouts and protocols for Kenwood, Panasonic and Pioneed changers. Might give you some ideas.

    http://www-user.tu-chemnitz.de/~harn/mp3_cdc.htm

    Mark
  • Check the mp3car webboard.
    www.mp3car.com
    and click the link at the bottom. Tell them lstrunk sent you. Make sure to use the search button first before asking a new question though.
  • One thing I always wanted to do with my future car mp3 player is to have 802.11 sync up mp3s with other cars on the road. You should design an open protocol for sharing mp3s between your house and car that would also adapt to the open road.

    Sure it'll be useless in the near future, but could be usefull later on.

Slashdot Top Deals

I program, therefore I am.

Close