07/06/2014 at 15:44 •
After much research and fiddling, I finally figured out how get the Twisted Pear Audio WM8804 board to do my bidding. The only thing I want it to do is convert I2S data to S/PDIF data. I had a hard time figuring out how to make this work because the user manual from Twisted Pear Audio only gives configuration information for converting S/PDIF to I2S. I initially thought I would need a microcontroller to configure the registers in the chip, but after digging through the datasheets for WM8804, I finally found a small section describing how to run the chip in hardware mode (no µController needed) and get the results I wanted. Below is a picture of my test setup using the RN52 bluetooth module as a I2S source, and a picture of the WM8804 board showing the switch positions for configuration.
The picture (left) doesn't do a very a good job of showing it, but in order to make this work, I connected the bit clock output of the RN52 to both the master clock and bit clock inputs of the WM8804 board. The S/PDIF output from the WM8804 board is then connected to a TOSLINK optical transmitter which is connected to a cheap TOSLINK to analog converter. This configuration works flawlessly.
In the picture to the right, you can see the dip switch positions. The dip switches, from left to right are up, down, up, down. This translates to low, high, low, high levels.
I haven't decided if I'm going to use this board or not. Although I still really want to use an optical medium to move audio data across the vehicle, I'm not sure I want to go through the trouble of figuring out volume control.
06/01/2014 at 18:03 •
After getting the RN-52 module hooked up to a USB/serial cable and getting the module configured and paired with my phone, I connected my logic analyzer to the digital audio output. It took me an embarrassingly long time to figure out that the silkscreen on the breakout board was incorrect and that I was trying to monitor output from a input line (I should have just read the product description on Sparkfun's website). But, silly mistakes notwithstanding, I did manage to get data out of the device and it appears to output good I2S data.
While digging through the datasheet for specifics on how to configure the device, I found that it is capable of outputting S/PDIF. I set the module to output S/PDIF and connected it to my A/V receiver. It works great as a Bluetooth A2DP to S/PDIF adapter. (I might re-purpose it for that.)
After listening to a few songs and playing with software control of pause/play/next/prev, I started digging through the datasheet and command reference to try to figure out how to get track/artist information from the Bluetooth source. Lo and behold, the RN-52 is not capable of retrieving that information. I should have figured that out long ago, but I was skimming the datasheets like an idiot. And so, I have to figure out a new way to handle audio.
My current idea on how to do this is to use the existing head unit since it has all the Bluetooth capabilities I'm looking for, it already has the circuitry/interfaces for the microphone and steering-wheel controls, and it has a built-in amplifier. That's a few less things to figure out. The plan is to offset the head unit back a few inches into the dash and mount the tablet in front of it. I'm considering eliminating all of the parts of the head unit that do not contribute to producing sound from either Bluetooth or line-in. That would leave me with only a single PCB (with two small daughter boards) to mount behind the tablet.
The one big question is how to communicate with the head unit to get track/artist info and send commands (play/pause/next/prev, answer call, volume, etc.). I poked around the innards of the unit a bit and found a few interesting things. Bluetooth is implemented using a BT module much like the RN-52. It's soldered to the main PCB in the head unit, and most of the useful data lines have bare solder test points that are easily soldered to. These data lines include AVRCP control lines over ASYNC serial and PCM I2S signals.
The test points are on the bottom on the PCB. This is the top side showing the Bluetooth module. It's worth noting that this module does not have a built-in antenna as the RN-52 does. There is a U.FL connector nearby for the antenna that is mounted in the front panel.
Here is the bottom side of the PCB.
Box 1 is the UART that I found AVRCP data on. The track info is tranferred as normal ASCII data. Box 2 shows what appears to be a UART but I wasn't able to get anything useful from it. The silkscreen in box 3 tipped me off to the possibility of there being I2S data lines there. I recorded a little bit of data from the for points in box 4 and it appears to be valid I2S. It would make sense becuase most CD players use I2S to transfer audio data around. You can also see some silkscreen that implies some other functions can be hacked into with little work.
The front panel of the unit connected to the main PCB with a single ribbon cable. It has its own µC that seems to interface everything on the front panel to the main board. In the picture below you can see the RX/TX lines that I ended up getting data from.
When I connected the logic analyzer to it, I assumed that it would be communicating using standard 8N1 ASYNC. But all of the data I captured had framing errors. My initial thought was that the two controllers were communicating with 10 bits instead of 8, but this only helped about half the framing errors. Not to mention, the data the analyzer came up with seemed random. After fiddling with the analyzer settings for a while I finally came across the proper setting: 8E1. That's 8 data bits, even parity, and 1 stop bit. This is the first time I've ever seen parity used, and I almost gave up before figuring it out.
I reversed engineered part of the communications protocol used by the front panel µC, specifically the part for track info. It seems straightforward enough. You can see my efforts here: Google Spreadsheet. Be warned, the spreadsheet contains conditional formatting that makes it run a little slow in the browser. "Sheet1" breaks down the captured data into blocks for each time the track info changes. "Sheet2" and "3untitled" have the full data-sets for each of the UART channels.
Here's a shot of the head unit with the top removed, along with the CD player and heatsink. The front panel is laying flat. The black rectangles show where the photos above highlight.
You may not be able to tell it from the photo, but when the unit is fully assembled, there is a whole bunch of wasted space inside. Enough space that if I leave the entire unit in the car, I can probably mount a µC inside the unit. I'll have to program a µC that lets me communicate with the unit over IP so that it can be integrated with the rest of my car PC system. If I can mount it inside the unit and expose only a RJ45 plug (for Ethernet) then I won't have to worry too much about electrical noise and interference.
I found that the unit works just fine without the CD player installed. If it will work without the front panel, or if I can spoof the existence of it, I might be able to get away with using only the main PCB. This would allow me to mount it nearly anywhere since I would be able to built an enclosure for it. If I can completely emulate the front panel with a µC, and just relay messages between the tablet and the main PCB, then I would be able to still use the line-in, USB, and tuner capabilities of the unit. This will be my ultimate goal, however, I won't consider the project a failure if I can't managed it.
One last thing to note: because the Bluetooth radio has an external antenna with a U.FL connector, I think I will be using a full-sized 2.4GHz antenna in the final build. You can see in the photo that I had it set up that way for testing.
My next update will likely be my experiences with the Wolfson Audio chip. Since I can get at I2S data, I might as well bring that data out to a S/PDIF connection on the back of the unit. The final design may even use my original idea of transmitting audio to the amplifiers over optics.
05/31/2014 at 07:10 •
I ordered the RN-52 BT module from Amazon and it arrived yesterday. As soon as I get a day off work, I'll be working out the specifics on how I am going to connect to and control it. I plan on using the I2S output of the module but I don't yet have the Wolfson Audio module that will accept the I2S signals. As a result, I going to connect my Saleae Logic to the BT module and check the I2S output against what the Wolfson chip expects (as per the WM88024 datasheet). This whole project hinges on being able to get the audio to work as I want it to, and so this is a pretty big step. I also need to work out how to use both the streaming audio profile and hands-free profile on the module, along with how to switch between them. I may even go as far as trying to measure audio degradation over the BT link. My next update will detail my findings.
On a related note, I'll be ordering the Wolfson Audio S/PDIF module within a week or so. Here's the link to it: Twisted Pear Audio S/PDIF Transceiver. This module will be connected to an optical output board that I plan on custom building. It will have at least two outputs (identical data on both/all) to feed the DAC's/amplifiers.