How do I make a 6 disk work with the RIO?

I just got done installing my system in my truck and realized that I really need CD playing capabilities. Which cd changer should I buy and how would I go about running it with the rio?
I do not have a tuner modual either.

You can check out my set up at www.evilsvt.com/audio.html
Any help is very appreciated.

You can hook up any line-level device (cd player, cd changer, tape player, whatever) through the Rio Car's aux-inputs and/or outputs. The device must have line-level inputs or outputs for this to work, or it can be connected to a converter box that converts it to line-level input or line-level output.

However, the Rio Car does not control CD changers. The FAQ entry on this subject is here. Please read through the FAQ before asking more questions on this BBS.

cool pics form your setup...

bye

In reply to:

---

...realized that I really need CD playing capabilities.

---

Just out of curiosity, why do you?

One of my many side projects is having a crack at trying to emulate the Alpine MBus system they use for changers. I have got the basics down like changing CDs, reading timecodes, seeking etc, but I'm a little way off yet. Then it should be just a case of a custom application for the RioCar to drive the changer through the serial port and accept the audio via the AUX inputs

Remember not everything comes as an MP3 - and if we're doing the right thing and not freely copying MP3s then sometimes a CD player can be useful. Sometimes my friends will have a CD to listen to or when I buy one it might be a while before I get around to encoding it.

I already own the changer and it's basically worthless so I am giving it a shot. It's been something I've meaning to do for nearly two years now. And I'm definitely not suggesting you go out and buy an Alpine changer since there might be a problem I can't figure out.

I want to do this because I have a high end stereo and I can tell the difference between the MP3s and CDs, also it sucks not being able to play a cd a friend has.

I can tell the difference between the MP3s and CDs

Then your MP3's aren't encoded properly...

<runs away quickly to avoid religious debate>

Yeah really, there's gonna be a point where you're fooling yourself if you think you can tell the difference.

What do you encode at, and with?

You can always store the music you intend to demo as WAV files.

Calvin

In reply to:

---

also it sucks not being able to play a cd a friend has.

---

I've always viewed this was one of the best features. Depends on your friend, I guess.

Matthew

How far have you gotten on the Alpine changer project. I would like to help as I want to do the same thing.

I have basically worked out the baud rate, how the bits are encoded etc. I have a service manual for my headunit so I should be able to emulate the circuitry on that fairly easily.

My biggest stumbling block at the moment is how the checksums are calculated. If I send you some sample packets and point out what certain things are - is that something you think you could tackle? Do you know about stuff XOR, CRC etc?

Currently all this info is basically in my head (and a dodgy debug program I have written). I haven't really written/typed anything out yet...

If it's anything like the alpine bus on the NSX head unit, ISTR it looked like an 8 bit checksum - but there was no carry from the bottom 4 bits to the top. Probably using an 4-bit CPU somewhere...

Hugo

Thanks for that idea Hugo. It should be very similar since Honda seem to use only very slightly modified Alpine gear. They swap two pins in the cable generally.

I will have a look. It is very 4 bit oriented alright. Everything is done in BCD basically. I think it might only be a 4 bit checksum. It's the algorithm that's got me at the moment.

Did you see only ever 4 different bytes transmitted? 0x10, 0x70, 0x13, 0x73? They seem to translate into 00, 01, 10, 11 (in that order)

I don't have the unit here so I can't check, but it did look 4-bit and used pulse widths to convey 0's and 1's (ie, self clocking) as opposed to standard async.

This is a very old alpine bus though, the head unit design was fixed in '91 when the first NSXs were made and it hasn't changed since.

Hugo

Don't think it's the same then. This is definitely async standard old 8N1 1500 baud it seems. This changer is from about 96 so maybe they changed somewhere in between. As far as I was aware though the were two changer types only MBus and AiNet.

I have found a site though here that talks about 91-92 NSXs and retro fitting an Alpine MBus changer so maybe I have something slightly screwy - but I doubt it since I can currently pull things like button presses/commands, disc, track and track time out of the data stream.

It's basically just the checksum and all the different packet types I have to sort out now.

Mmm, possibly it isn't async which would explain why you only ever see 4 bytes. Have you got a scope trace of a packet? The bus I looked at was MBus, definitely not AiNet.

For checksums, I figured it out by capturing packets identical except for one bit, eg track 2->track 3 (bit 0 being set in the status packet) and compare the checksums then. It *might* have been XOR of the 4-bit values, maybe. It was about 6 months ago I last looked at it...

Hugo

I am willing to consider that it is not asynchronous but when I have it basically directly connected (level converter / inverter) to my PC and have a program receiving and decoding track times/disc changes etc perfectly, I really think I have it right.

I don't have a scope trace saved but I can easily get one if you're still interested.