Project Logs

Collapse

• Official Raspberry Pi Support

  RF William Hollender • 02/27/2018 at 17:19 • 0 comments

  Support for the SuperAudioBoard has been accepted into the official Raspberry Pi kernel fork, and is now included as part of the bleeding edge 'rpi-update' release.  It will eventually be included in the official Raspbian image, but I don't know the timing of these releases.

  Configuring a Raspberry Pi to work with the SuperAudioBoard is now as simple as updating the latest image of Raspbian using the 'rpi-update' command, and making some changes to the /boot/config.txt (see the user guide for details).
  

• Don't always trust the datasheet (sample rate bug fix)

  RF William Hollender • 09/30/2016 at 04:28 • 0 comments

  TLDR: All of the code for the SAB using either the Teensy or FPGA as a controller had mistakenly set the sample rate to 32kHz instead of 48kHz due to an inaccuracy in the datasheet. The code in github has been fixed so that the sample rate is correct.

  ------------------------------------------------------------------------------------------------------------------------

  I was recently trying to help someone who had built a board up, but couldn't seem to get the correct frequency output. They were trying to simply output a 1kHz sine wave using the Teensy Audio library. Everything seemed to be working, but the output was at 667Hz instead of 1kHz. The sample rate seemed to be at 32kHz instead of 48kHz for some reason.

  The CS4272 codec has a number of different modes, I designed the board to use a 24.576MHz crystal, and only operate in master mode, where the codec generates all the clocks used for the I2S interface, including the sample rate (corresponding with the frame clock or L/R clock). The odd thing is, the datasheet only specifies 2 possible divide ratios for the sample rate in this configuration, 256 and 512, and 512 results in a valid sample rate in the 'single speed mode':

  I chose a divide ratio of 512 for a sample rate of 48kHz (256 would result in a sample rate of 96kHz, which isn't valid for the single speed mode, so only works with lower crystal frequencies). The Ratio1 bit is clearly defined for this case, but the Ratio0 bit is a 'don't care' so I wrote the code to write '11' to this field, just in case there happened to be an issue with bit ordering.

  The codec has a second mode, where there is no external crystal, and it is configured to receive MCLK, the master clock in the I2S interface, instead of generating it from the crystal. In this configuration, the Ratio bits are slightly different:

  Notice in this table, that setting the Ratio bits to '11' results in a divide ratio of 768, which results in a sample rate of 32kHz if the master clock is 24.768MHz.

  This seemed to point to a startup issue causing the codec to start in the wrong mode. This is really curious because the MCLK pin on the codec is supposed to be an input in this configuration, but then there wouldn't be anything driving the pin at all. I thought that maybe this problem was a one off board problem, and that some interference between the clock oscillator and MCLK pin was causing a startup issue.

  After much troubleshooting, however, it turns out that all the boards have this problem, even the ones that I've done all the performance testing on. Oops!

  I hadn't ever seen the problem before because I had only been performing loopback testing, so all the results looked fine. I had played a sine wave out of a speaker, but hadn't noticed that the output was at way too low of a frequency.

  I had played music through it using the Raspberry Pi, but the part of the kernel driver that sets the divide ratio already existed (written for the CS4271, which has a compatible register set), so it actually worked at the correct sample rate.

  I never thought to go back and double check the sample rate because I don't have good enough equipment to measure the performance I was trying to achieve, and, more importantly, the datasheet indicated that any other sample rates were effectively impossible in the configuration used.

  I triple checked the startup sequence used, but it also matches the datasheet to a T. It just looks like the codec's behavior doesn't match the datasheet in this configuration.

  Luckily, it is an easy fix to get the correct sample rate. The correction is just to follow the second table, and set the divide ratio bits to '10' instead of '11'. Needless to say, all of the code in github has been updated to set the correct sample rate.

  Unfortunately, this means that all the performance data that I had collected was at a sample rate of 32kHz instead of 48kHz, and the tones used were at 667Hz instead of 1kHz. I had run a THD+N test using the Raspberry Pi which would have used...

  Read more »

• FPGA example code now available

  RF William Hollender • 06/27/2016 at 05:50 • 0 comments

  I haven't had a lot of time to dedicate to this project recently. A few months ago, however, I finished some HDL and C to get the SuperAudioBoard working with my Spartan 6 Microboard FPGA dev kit. I just never got around to actually putting the code up until now.

  If you check the github repo, you'll see a new folder called S6MicroBoard_PoC. This has all the HDL and C needed to get the SuperAudioBoard working with this particular FPGA board, along with instructions to get started using Xilinx ISE 14.7 and the Xilinx SDK.

  The files include some pretty simple I2C and I2S interfaces that I built from scratch, and the overall FPGA image also includes a microblaze microprocessor system core to handle initializing the CS4272 and send and receive audio data.

  The I2S and I2C modules are meant to interface with the microblaze MCS interface bus, which is a very simple bus, so these modules should be easy to extend to other bus types for use in other FPGAs or applications.
  

  The code is pretty specific to the Xilinx platform, but could probably be easily modified to work on any other soft core.

• Better Raspberry Pi Support

  RF William Hollender • 10/29/2015 at 04:43 • 0 comments

  After all the last minute soldering and testing just before the Hackaday best product semifinals deadline, I was ready for a bit of a break. Things got busy at home and at work, and I haven't done hardly anything on the SuperAudioBoard for 2 months!

  In the mean time, I had received a batch of the pi->SAB adapter boards and soldered them up, but hadn't tested them. A few days ago, I got a few hours to actually try them out. The boards are working great, but I still had a few bugs left over in the SAB kernel driver for the Pi.

  The new adapter boards in action:

  One of the issues that I had earlier with the Raspberry Pi was that I couldn't get files with sample rates other than 48kHz/96kHz/192kHz to play. Most consumer audio (mp3s, etc) have a rate of 44.1kHz, so this was a pretty big downside.

  It turns out that I was missing a bit of code in the kernel driver that constrained the available sample rates to the ones that are actually achievable with the SAB hardware setup. There doesn't seem to be much documentation on the kernel sound support, so finding out exactly what was needed was quite an ordeal.

  Anyway, with the additional code in place, the SAB works really nicely with the Raspberry Pi. There are a million different ways to get audio setup under Linux, but with the driver fixed, things worked well right out of the box. The only third party tool that I installed on top of the base Raspbian distro was pulseaudio, which tends to make dealing with different sample rates and bit depths more seamless than just using the basic ALSA playback methods.

  Here are a couple screenshots showing the board in action:

  The first shows the SAB recognized, and its sample rate and bit depth capabilities:

  Next there's the stream info (48kHz @ 16 bits) while playing back an online stream of a local radio station:

  And, finally, playing back a test mp3 with pulseaudio (resampling from 44.1kHz to 48kHz):

• Teensy Audio library working

  RF William Hollender • 09/09/2015 at 15:39 • 0 comments

  After debugging some really odd behavior, I finally got the SuperAudioBoard working with the Teensy Audio library!

  The Audio library additions are in my fork of Paul's github repo here in the "SuperAudioBoard" branch. Keep in mind that the additions are still in a beta stage until they get added to the official library so some things might change (class names, etc).

  There are a couple of example sketches in the SuperAudioBoard repo that I'm using to test out the library additions.

  I haven't had a chance to test out all the control methods (volume, muting, etc), but the base setup is working well.

  Edit: I forgot to mention that there is a slight gotcha when using the Teensy Audio Library with the SuperAudioBoard: the Audio library defines it's sample rate at 44.1kHz, and all Audio library objects use that as the sample rate, but the SuperAudioBoard operates in master mode, and doesn't support 44.1kHz. The closest sample rate the SAB can support is 48kHz, so all code that uses the SAB and the audio library needs to take the sample rate difference into account when setting or reading frequencies. Check out the example sketches for details.

• Got last proto working

  RF William Hollender • 09/02/2015 at 06:03 • 0 comments

  I've spent the last week or so taking a break since I found out that the project didn't make it past the first round of the Hackaday prize. It would have been fun to keep going, but it means a lot less stress :)

  I finally got around to trying out the SMD removal kit that I got from Adafruit, and it worked awesome! It hardly took any time at all to get the CS4272 off the board and replace it with a new one:

  The two ICs in the bottom of the picture are the two that I removed to try to fix the board after it didn't work. The smaller IC is the I2C isolator that I mangled with a diagonal cutters to separate the pins so that I could remove them one at a time. The other is the codec that I removed using the chipquik kit and it was way easier (and I didn't almost destroy one of the pads).

  It's a little annoying to replace $12 worth of components because I forgot to load 4 pull up resistors worth a total of around 0.03, but that's what happens when you rush, I guess.

  On another note, now that the Hackaday contest is over, I can focus on getting the board production ready, and getting a kickstarter going. Here are a couple of goals for the next month or so:

  1. Finish integration into the Teensy Audio Library
     1. Should go a lot faster now that I have a working prototype
  2. Test out the Raspberry Pi adapter boards that I sent out to OSHPark a few weeks back
     
     1. They should be arriving soon
  3. Find a more user friendly software setup for the Raspberry Pi
     
     1. Instructions for auto-resampling, resampling quality settings, etc
  4. Make some changes to the board for better usability
  1. Use solderable jumper pads for configuration instead of 0-ohm jumpers
  2. Lengthen pads for power supply ICs
  3. Change hole sizes for header pins and make sure that the pins are all on a 0.1" grid

  Hopefully I should be able to get everything done soon and should have a kickstarter going in a month or two!

• Some quick updates

  RF William Hollender • 08/20/2015 at 05:06 • 0 comments

  I put together a quick interface board for the Raspberry Pi so that I don't have to use a bunch of single wires next time I want to connect it up.

  The design is really simple, but I went with a 4 layer board because there were too many signal crossings, and it meant that I could at least make an effort to keep the higher speed I2S bus lines at close to 50 ohm impedances. The boards are off to OSHPark, and I've put them on the SuperAudioBoard GitHub repo. I'll share the design on OSHPark when I've had a chance to test it (if you use the files on github, it's at your own risk :)).

  I also updated the design and user guides with some info that I had forgotten. In my haste, I had forgotten things like

  • the fact that the I2S bus isolators are unidirectional so the codec always has to be the I2S bus master (this is the best performance anyway because the clocks will be derived directly from the 24.576MHz crystal).
  • that the audio outputs are line out only, and cannot be used to drive headphones or speakers
  • the max signal swings of the audio inputs and outputs

  I'm still working on getting my last prototype working. I'm pretty sure that I've narrowed it down to the codec chip itself. I already replaced the I2C isolator, but that didn't help at all.

  I almost pulled off a pad when I replaced the I2C isolator, and it only has 8 pins, so I wasn't looking forward to trying to remove the 28 pin codec without a hot air reflow station. I was looking through Adafruit's website to see how the reflow station was priced, and I ran across this: Chip Quik SMD Removal Kit. It looks like it should be a great help. Anyone else have experience with that stuff?

• Down to the wire

  RF William Hollender • 08/17/2015 at 17:50 • 0 comments

  It's the morning of the first Hackaday prize deadline, and I made it!

  Here's a quick recap of the last week:

  • Finished soldering three more prototypes
    • 2 of the three worked fine
    • 1 of the boards isn't working (won't communicate over I2C)
      • I think that this is because I powered the board up without pull-up resistors on the I2C lines
      • I've replaced the I2C isolator IC, but still not working
      • Next step is to replace the codec, but this will be really difficult without a hot air reflow station
  • Shipped my only three working prototypes to Hackaday
    
    • My first prototype and the two new working prototypes
  • My wife helped me complete the two required videos
    
    • The "Semifinals" video is here: video
    • The "Quarterfinals" video is linked in an earlier post
  • Made a mockup of the product packaging (again, big thanks to my wife for her help!)
  • Added a detailed design guide: link
  • And, added a user guide (still a work in progress): link

  One thing that I had hoped to finish before this deadline was to integrate the SuperAudioBoard with the Teensy Audio Library, but I had to pause work on it to finish the contest requirements.

  Here are my goals for the next few weeks before the final best product deadline:

  1. Fix my last prototype!
     1. It'll be hard to get much testing done without a working proto type :)
  2. Finish integration with the Teensy Audio Library
     1. Just a 16 bit mode to start with (24 bit support requires extensive rework of the entire library).
  3. Update the board design with some usability enhancements
     1. Address some solderability issues
     2. Better annotations
     3. etc
  4. Design some interface boards for the Raspberry Pi
     
     1. Better than point to point wiring
  5. Try Raspberry Pi with other audio distributions for better ease of use
     1. Working with audio in Raspbian wasn't the easiest.

  Stay tuned for more updates!

• Product packaging and artwork

  RF William Hollender • 08/17/2015 at 01:34 • 0 comments

  My wife put together some logos and packaging ideas today. Check out how the final product might look:

  Design:

  Mockup:

• Protos delivered and first video on youtube

  RF William Hollender • 08/15/2015 at 05:03 • 0 comments

  Got delivery confirmation on the three protos sent to Hackaday:

  And, the quarterfinals video is up on youtube:

  Big thanks to my wife for doing all the videography (and all the good pictures, too)!

View all 16 project logs