H I F I D U I N O

Continue reading HIFIDUINO...

2010-03-31T13:34:00.000-07:00

Another Musiland 01 Mini mod

2010-03-22T21:48:00.000-07:00

I removed the capacitors I installed in the backside of the board (see here). Instead I removed the capacitor from the switching supplies -power traces cut- (220 uf) and replaced the capacitors of the linear regulators (10 uf). Another advantage of getting the mini...

Buffalo II DAC

2010-03-20T18:08:00.000-07:00

(Click to enlarge)

More here

Comparing Noise Figures in Linear Regulators

2010-03-15T18:19:00.000-07:00

Just like phase noise in clocks, it is difficult to compare noise values among linear regulators because there is no common ground in specifying noise figures. Some companies report noise density, others RMS V noise, and yet others % of Vout. The frequency range for the reported noise figures also varies from company to company.

The LT1763 familiy is a favorite for audio projects because it has low noise figures. Among linear regulators it is probably universally preferred by audio diy aficionados.

In order to compare other regulators to this benchmark device, I decided to calculate the Vrms noise in each of the fequency ranges provided by the chart. The Vrms noise is basically the product of the noise density times the frequency delta.

The results is shown in the graph below. Total Vrms = 23.2 uVrms for the frequency range 10Hz to 100KHz. This approximation is very close to the specified value of 20 uVrms.

I then looked as the specified noise of several common regulators and matched the values to the corresponding value of the LT1763 device.

A couple of observations: The LM340 is actually very good, in fact better than the beloved LM317 according to spec. The LM723 seems of lower noise than the LT1763, at least in the reported frequency range.

We can approximate the total noise Vrms for the 10Hz-100KHz interval by noticing that each frequency range contributes a percentage of the total noise. In the case of the LT1763, we notice that the 10Hz-10KHz range contributes about half of the total 10Hz-100KHz noise. The table below compares all the regulators in the 10Hz-100KHz range.

Here is a very good paper from TI explaining noise in linear regulators: [link]
According to the paper,

"The dominant source of noise in an LDO is usually the
bandgap. In most cases this is solved by adding a large
low-pass filter (LPF) to the bandgap output so that none
of the noise makes it into the gain stage."

Unfortunately, it is not easy to access the bandgap output line in most integrated regulators...

TPA's AC1 FAQ

2010-03-11T21:29:00.000-08:00

Not an Arduino, but based on a cousin of the ATMega168 with built-in USB. Of course totally incompatible with the Arduino development tools. But if you are familiar with Arduino, you'd easily navigate this device.

More pictures over at TPA's website

Instructions for loading (burning) firmware into FEMTO:

1- Download and Install FLIP
2- Copy libusb0.dll from usb directory to bin directory: copy the file C:\Program Files\Atmel\Flip 3.4.1\usb\libusb0.dll to C:\Program Files\Atmel\Flip 3.4.1\bin. Make sure you copy the file because it is needed on both directories
3- Insert FEMTO and do the following sequence:
a- Push HWD button
b- Push RST button
c- Release RST button
d- Release HWD button
4- At this point Windows will recognize the device ( FEMTO) and will guide you though the driver installation. 5- Select manual installation and you point the path to: C:\Program Files\Atmel\Flip 3.4.1\usb
6- Start FLIP
7- Start USB communication: Settings->Communication->USB
8- Select device: Device-Select->AT90USB162
9- Select hex file: File->Load Hex File->filename.hex
10- Click Run

Programming Buffalo DAC: Review of Arduino I2C

2010-02-27T12:53:00.000-08:00

Is is fairly simple to use Arduino to program a DAC such as the ESS Sabre32. After you connect the appropriate signals (wires) from Arduino to the Buffalo board, you follow the tutorial sketches (in Arduino the programs are called sketches) to set up the main code and use the Arduino I2C functions to write values into the registers of the DAC.

In Arduino, the I2C protocol is supported by the "Wire library" and the functions are the following:

begin() - Join the I2C bus as a masterdevice
begin(address) - Join the I2C bus as a slave device
requestFrom(address, count) - Tell device that a request will follow
beginTransmission(address) - Tell device as address that data transmission will start
endTransmission()- Tell device that transmission is ended
send() - Send data (one byte at a time)
byte available() - Queries number of bytes available for retrieval
byte receive() - Retrieve (read) bytes from device
onReceive(handler) - The function to perform when slave receive a transmission
onRequest(handler) - The function to perform when slave receives a request

Before you do anything, Arduino joins the I2C bus as a master device with

begin()

The following code will write one value into one register:

beginTransmission(0x80); // Address of DAC is hex 80

  send(0x01); // Address of register is hex 1

  send(0x00); // Value into register is hex 0

endTransmission;

Hex is hexadecimal notation. It is more convenient to write in hex notation rather than binary notation. Most data sheets give you register address value in hex and register value in binary. You can use any notation in your code but you have to indicate which notation.

You can convert binary to hex with one of many online tools such as this. 

The following code sends one value to 4 registers. This example is typical for setting volume. The same value is assigned to all the internal DACs. Say for example the volume control of the DAC is 1/4 db and you want to set a -10 db volume. The value to use is -40 (you don't have to specify which notation because the default is decimal notation), and assume the registers to control the volume are registers 1 through 4

beginTransmission(0x80);  // Address of DAC is hex 80

   send(0x01); // Address of register 1 is hex 1

  send(40); // Value into register 40
  send(0x02); // Address of register 2 is hex 2
  send(40); // Value into register 40
  send(0x03); // Address of register 3 is hex 3
  send(40); // Value into register 40
  send(0x04); // Address of register 4 is hex4
  send(40); // Value into register 40
 

endTransmission;

That's it.

Update (October, 12, 2010): I just implemented and tested the basic code to control the Buffalo II DAC's volume. However, I couldn't program multiple registers within a single beginTransmission and endTransmission pair as shown above. I had to program each register with beginTransmission...endTransmission separately. You can see the code here.

Audiophile HQCD

2010-02-22T22:18:00.000-08:00

Finally got my copy of Bondy Chiu's audiophile recording from Hong Kong. It was sold out over Christmas...

HQCD is a higher quality pressing by using lens quality plastic and silver allow first developed for the now dead HD-DVD.

Bondy Chiu (you can hear her music here) is a Hong Kong-based artist that with Ken Poon (his blog is Design with Sound), a recording engineer and audiophile has created perhaps the first mass-market Audiophile CD.

The CD sounds very good, and if you got friends in Hong Kong, can be purchased for around HK$ 160.

Programming Buffalo II DAC: I2C Isolation

2010-02-17T11:04:00.000-08:00

As extreme care has been afforded to reduce noise on Buffalo II, perhaps it would be also prudent to implement the I2C isolation solution to prevent any noise sneaking through an external microprocessor such as Arduino on the I2C lines.

Note: a reader alerted me that the on-board microprocessor goes to sleep after setting up the registers of the DAC. In such case, there should be no additional noise from the on-board microprocessor. However, when the microprocessor is sleeping, only an interrupt can wake it up. If one uses the Arduino as the external microprocessor, some of the code may not be interrupt based, for example polling IR remote signals. So, if the microprocessor is doing more than just setting up the registers at power-on, in general it is not a good idea to put the microprocessor to sleep. Therefore some isolation in the i2c lines would be a welcomed noise avoidance implementation.

Analog Devices magnetic coupling devices has a solution for this task: The ADum1250. Previous observations here indicate that this is the best solution.

The ADuM1250/ADuM1251¹ are hot swappable digital isolators with nonlatching, bidirectional communication channels compatible with I²C® interfaces. This eliminates the need for splitting I²C signals into separate transmit and receive signals for use with standalone optocouplers.
The ADuM1250 provides two bidirectional channels, supporting a complete isolated I²C interface. The ADuM1251 provides one bidirectional channel and one unidirectional channel for those applications where a bidirectional clock is not required.
Both the ADuM1250 and ADuM1251 contain hot swap circuitry to prevent glitching data when an unpowered card is inserted onto an active bus.

The application note indicates that side 1 (left) should be used for the device (the DAC) and side 2 for the I2C bus (Arduino)

The pull up resistors on side 2 (right side) in the diagram are already implemented in Arduino (inside the uP and enabled in software).

The pull-up resistors on side 1 (left side) I believe are already implemented in Buffalo II as R14 and R15? -Need to confirm with the designers.

Buffalo II DAC Clock Jitter at 0.1 psec RMS?

2010-02-11T23:10:00.000-08:00

In the previous post we found that the Crystek oscillator used in the Buffalo II DAC is very good, better than the typical oscillator found in many hi end audio equipment, but obviously not as good as the best money can buy. The phase noise graphs look sort close to each other, but how much different are they?

Audiophiles are accustomed to hear jitter values in terms of pico-seconds (psec) RMS, and many oscillators are spec'ed at 1 psec jitter. We know that phase noise is another way to measure jitter, and that jitter RMS values represent the area under the curve. One must realize that the graph is in logarithm scale resulting in large differences even though the curves are sort of close to each other.

Analog Devices has an excellent tutorial on understanding jitter values

You can use the formulas to calculate jitter RMS from phase noise data, but there are easy to use on-line tools that calculate jitter RMS from data you find in datasheets. One such tool is the Phase Noise Calculator from www.jittertime.com (a consultancy on the topic of jitter)

So lets calculate the jitter RMS value for each of the oscillators we compared in the previous post.

Buffalo II oscillator

We find the data points in the graph and enter them in the tool as shown:
The result is 0.446 psec. (if you are wondering why the result is less than the sum of the jitter in each segment, is because they add as Root Sum-of-Squares)

This value agrees with the value is the specification ( typically 0.5 psec). We do the same for the other curves and we find the following:

Crystek 950 (Buffalo II): 0.446 psec
Wenzel oscillator: 0.075 psec
Typical Oscillator (Buffalo I): 29.9 psec

Those are BIG differences when we convert to jitter RMS values. the Wenzel measures 75 femto seconds!. The Crystek 950 measures the expected half a psec; but the typical oscillator measure 30 psec?. But wait a minute, aren't those oscillators spec'ed at 1 psec?.

Lets looks at the specification of the oscillator found in Buffalo I: Crystek c33xx. The spec says: Jitter RMS: 12KHz-80MHz: 0.5 psec. Notice that the jitter is measured after 12 KHz whereas the phase noise plots we see for the better parts starts at 10 Hz. If we instead measure the Jitter RMS for the Crystek 950 shown in the graph with the same scale, of 12 KHz to 80 MHz, we get the value of 0.13 psec.

I used the numbers found in the spec for an 80MHz oscillator and got 0.115 psec for 12KHz to 80MHz. The best spec in the datasheet is for the 100MHz clock with a jitter value of 0.094 psec RMS (12KHz-80MHz). Maybe the custom clock Crystek is making for TPA has better phase noise values than what is stated in the specifications. (Update: according to Brian of TPA, the phase noise specification for their parts is the same as the standard parts)

Thus:

Clock for Buffalo I: 0.5 psec RMS (12KHz-80MHz)
Clock for Buffalo II: 0.115 psec RMS (12KHz-80MHz)

What offset frequency interval is used for audio to calculate jitter? I don't think there are standards in audio, but for other applications there are standards. This article cites two standards:

As an example, SONET uses a frequency offset of 12kHz to 20MHz from the carrier signal to integrate the area under the phase noise plot to measure phase jitter. Fiber Channel uses a frequency offset of 637kHz to 10MHz from the carrier signal to integrate the area under the phase noise plot to measure phase jitter.

According to Analog Devices,

It is a little tricky to specify the bandwidth over which phase noise should be integrated in order to calculate the jitter which will actually be observed when that clock signal is used to clock a converter. There are many variables which are seldom known with accuracy – such as the inherent bandwidth of the sample clock circuit on the converter. Also, it is very difficult to actually measure the broadband phase noise of a clock signal beyond an offset of a few MHz. ... For a true "broadband" jitter calculation some assumptions and simplifications must be made. One assumption made by ADIsimCLK, for example, is that the upper offset integration limit is one-half the clock frequency. The lower offset integration limit is assumed to be between 100 Hz and 1 kHz.

What frequency interval matters then?

If we take a previous datasheet of the Crystek 950 clock and compare it with the current datasheet, we see that the "close-in" phase noise (closer to the crystal frequency) has increased and that "broad band" phase noise (away from the crystal frequency).

It seems that the engineers at Crystek focused on improving the broadband phase noise values and were willing to tradeoff the close-in phase noise. This implies that broadband phase numbers (or the "noise floor" of the oscillator) is a more important value than close-in noise (at least for the market that this crystal is intended to be used, -which I am sure it is NOT DIY DAC boards :-))

Perhaps it depends on the application

According to tutorial from Analog Devices,

Close-in phase noise limits the frequency resolution
Broadband phase noise reduces SNR

According to the discussion on DIYAUDIO (thanks rossl for pointing this out in the comments) close-in phase noise is what is important for high-end DAC applications.

YET another data point for frequency interval

A reader alerted me to an excellent AES paper on jitter for audio components, available for free from Wolfson Micro. There, the authors propose a "baseband" value of 100Hz to 40K Hz

If we use these frequency values we obtain (via the handy online jitter calculation tool) the following jitter values:

1.6 psec or 1600 fsec for a c33xx class clock (100Hz-40KHz)
0.046 psec or 46 fsec for a 950 class clock (100Hz-40KHz)

Unfortunately most of the research on the effect of phase noise revolve around digital telecommunication, where the frequency is in the 100s of MHz. There clock jitter determines the SNR and effectively the bandwidth of the devices, and the phase noise value that is important is the broadband phase noise.

So what is the effect of phase noise in audio?

According to this AES paper by Bruno Putzeys (Hypex, Grimm Audio) it is just noise.

I also took a look at other implementations of the ESS DAC and what kind of clock they use. It seems that only DIY versions can "afford" the high-end clock... Also note that the ESS evaluation board uses a "standard" crystal, rather than a clock (or so it looks like)

Eastern Electric DAC

Clock in Buffalo II DAC

2010-02-11T20:19:00.000-08:00

According the Brian in this post, the clock in Buffalo II is not only the top-of-the line product from Crystek, but a custom made model with even better specifications.

For those with sharp eyes, the photo of the Buffalo II prototype has a 50 ppm (temperature stability) clock, but the production models will have a 20 ppm part.Temperature stability is related to the quality of the quartz crystal used in the clock. It is therefore safe to assume that this will also improve the jitter figures.

But how good is Crystek's best oscillator?

There is a white paper by Crystek showing "phase noise" curves for the 950 oscillator and compared to a typical oscillator. I copied the charts and overlaid them together. In addition I took a look at the specifications of a ultra low phase noise Wenzel oscillator and a Rubidium oscillator and plotted the data on the same chart. The Rubidium is a "$900 low cost" version. Perhaps they are best at frequency stability over a long period of time and therefor they cost so much. The Wenzel oscillators are the lowest phase noise you can find and are used in High Energy Physics and Radio Astronomy applications. If you work for NASA or CERN, maybe you can borrow one of these clocks and hook it up to your DAC :-).

BTW, "phase noise" is just another way to measure jitter. Jitter, typically measured in psec is the area under the phase noise curve. Thus jitter gives you the total deviation from ideal and phase noise gives you the spectrum of that deviation. However, comparing jitter figures is not easy because manufacturers select different frequency range (say 100Hz to 100KHz or 10Hz to 1MHz) and each gives different numbers. Best to compare phase noise numbers. The graph below shows the phase noise curves. One can see that in order to improve on the clock selected for the Buffalo II DAC, one would have to get a Lab grade oscillator

Update: NEL AE-X3A3 oscillators have better specifications than Crystek 950. The NEL Oven controlled oscillator is even lower noise (not sure how much they cost)

(Clik for larger image)

How is Ultralow Phase Noise Achieved?

According to the author in the Crystek white paper,

"A commodity oscillator is nothing more than an ASIC and a quartz crystal blank. In most cases, it does not even have an internal bypass capacitor. The crystal blank is an AT-cut strip with Q of about 25 K to 45 K. This low Q limits the close-in phase noise. The ASIC with all its transistors limits the floor noise to about -150 dBc/Hz. On the other hand, the true ultralow phase noise oscillator uses a discrete high-performance oscillator topology with a packaged crystal with a Q greater than 70 K for excellent close-in phase noise. The discrete oscillator topology establishes the SNR, and hence the floor is lower than -160 dBc/Hz. Therefore, superior performance is obtained with very high Q crystals and a good discrete topology."

How is the Phase-Noise graph obtained? The chart is one half of the power-frequency distribution of the variation from ideal. Instruments are available to generate such charts.

This manual has a good tutorial on phase noise

Quarts oscillators is an "old" technology. "Fundamentals of Quartz Oscillators", an application note from HP from the late '70s is a good read.

The Buffalo II DAC: Best Bang-for-Buck

2010-02-11T00:05:00.000-08:00

(Update, Nov. 2010: I've developed Arduino code to control the Buffalo DAC. Check my other blog: www.hifiduino.wordpress.com)

TwistedPearAudio Released the Buffalo II DAC

This is the 3rd TPA iteration for the top of the line ESS DAC. The first iteration was for the ESS 9008 (24bit) DAC and the second and third are for the ESS 9018 (32bit).

Although it is priced at $249, the ESS DAC includes a spdif receiver, a high speed ASRC and a 32-bit DAC. In Addition, the Buffalo II includes a top-of-the line, ultra low jitter clock from Crystek and a ultra-low noise shunt regulator for the analog section of the DAC.

I think Buffalo II is the new bang-for-buck leader. If we compare a comparable OPUS DAC offering we have the following:

Opus DAC (WM8741): $75
Opus Spdif Receiver (WM8804): $75
Metronome (ASRC): $75
Upgrade Clock (you must mod yourself): $30
Upgrade analog regulation (e.g. Placid, and mod yourself): $40

Total: $295

To be fair, the OPUS does not require an output stage and associated power supply, and the Buffalo II requires an output stage.

In-depth comparison between Buffalo I DAC (ESS 9008) and Buffalo II DAC (ESS 9018) also shows that the new DAC is a better deal than the old DAC (Buffalo I photo scraped from "buyer of board #93 without permission)

BUFFALO I DIGITAL TO ANALOG CONVERTER

BUFFALO II DIGITAL TO ANALOG CONVERTER

Buffalo I ---------------Buffalo II

Panasonic caps: $0.51 ---Oscon caps: $3.14

Crystek 33xx: $2.31 -----Crystek 950: $27.70

ESS 9008: $47.90 --------ESS 9018: $65.60

Regulator: $.75 ---------LT 1763 Regulator: $4.13

Total: 53.75 ---------------------------Total: 115.11

Difference: $61.36

I believe the Buffalo I sold for $169. If we add the price differential for the 4-layer board, and the time spent designing and prototyping and testing the new board, we can easily reach the $80 price difference between the old Buffalo and Buffalo II.

Ah! I forgot the ultra-low noise dual analog regulator, you get that for FREE! (Expect to pay $60 to $120 for two shunt low noise regulators from 3rd parties)

Update:

There are a couple of dozen additional components in the back side of the PCB
The clock is a custom made 20 ppm (standard is 25-50 ppm) model for TPA

COMPARISON WITH BUFFALO 32S

I believe the main difference between Buffalo II and Buffalo 32s (aside from having the I/V stage in a separate board) is the analog supply. It appears (from pictures, I don't have the boards and there are no schematics for Buffalo 32s) the analog supply of Buffalo 32s is similar to the one found in Buffalo I.

Buffalo 32s analog supply: based on two LM4971 single opamps

Buffalo I analog supply: based on a single LM4972 dual opamp

Buffalo II Specification and FAQ

2010-02-10T12:03:00.000-08:00

This post is to summarize information I find elsewhere

EXTERNAL POWER SUPPLY REQUIREMENTS

POWER SUPPLY CURRENT [link]

POWER SUPPLY VOLTAGE [link]

The Buff II board has a single PS connection. Because it feeds both the on board LT1763 regulators and the AVCC dual shunt regulator, it must comply to the design of the AVCC dual shunt:

Vmin=5V
Vmax=5.5V (The AVCC shunt regulator is optimized to this voltage)

AVCC

According the the ESS Sabre DAC white paper, AVCC is specified as follows:

Minimum: 1.8V
Nominal: 3.3V (DNR= -132db)
Maximum: 4.0V (DNR> -133db) - see footnote 17 of paper

INSTALLATION OF AVCC DUAL SHUNT REGULATOR [link] [link]

"Also of note, although the AVCC header has four pins, only three are used by our AVCC module.
The AVCC module does not use the DVCC pin. It is there as a convenience to any who might want to use an ESS demo board style AVCC supply (where DVCC is a VREF). Our AVCC module uses its own low noise VREF, not DVCC."

Note: Buffalo I also derived the AVCC from the DVCC. In the case you wish to replicate such AVCC implementation, you can tap into DVCC as reference and VD will be powering the buffer opamp:

Normal Operating Conditions [link]
(This is one board, there is slight variations between boards)

VD=5V. Notice that one LED is brighter than the other. According to TPA this is perfectly normal.

AVCC1=3.523V, VCC2=3.5626V

VD=5.5V. Notice that the LEDs' brightness is more uniform.

AVCC1=3.556V, AVCC2=3.554V

The shut regulator board can also be installed on the back side of the Buffalo II board (It will get on the way if you are stacking above IVY III)

ON BOARD LINEAR REGULATORS

There are 3 linear regulators LT 1763. Two are 3.3 V and one is variable set to 1.2V
Noise level: 20uVrms 10Hz to 100KHz (meaning you can't do better than this even if you feed it a cleaner supply). For more information on regulator noise see this post.
Regulator Vin max=20V (5.5V max is specified because the same input traces feed the the shunt AVCC regulator which is designed for 5.5V max)
Comments by Russ on the use of LT1763 as regulator for the Crystek clock: "The reason the LT1763 is a good fit for the clock we use is because that clock in essence has a form of local regulation and decoupling internally."

OUTPUT IMPEDANCE BUFFALO I, II (from diyaudio)

195 ohm each output

According to the ESS Sabre DAC whitepaper page 4, each of the 8 DACs can be modeled as a voltage source having an output impedance of approx 800 ohm. Since in stereo configuration 4 such dacs are wired in parallel, the effective output impedance is thus 800/4 ~ 200 ohm.

DUAL MONO INSTALLATION

Latest diagram posted at diyaudio

DIMENSIONS

Buffalo II board: 2" x 3.3". This is the same size as the other modules such as OPUS, COD, Buffalo I, etc.
IVY III: From the layout it appears it is a double size board: 4" x 3.3"
Supplied Standoffs: .5" base standoffs. Inter-board standoffs (not included with the Buffalo II board are .625")

Musiland Driver 1.082: Fast vs Precision

2010-02-08T00:13:00.000-08:00

A reader sent me some measurements on the I2S lines with the latest driver. The first picture is with Fast Mode and the second picture is with Precision Mode. I think the error of 4 Hz is probably due to probe or calibration as the theoretical deviation in fast mode is 17 Hz (The measurement shows 21 Hz deviation)

In addition, he measured the LRCK signal in an oscilloscope. The waveform looks very clean. Note: device is powered with an external low noise regulator (not USB power)

96K Waveform

44.1K Waveform

Programming the WM8804

2010-02-06T01:20:00.000-08:00

I'm going to attempt to use the WM8804 SPDIF receiver in software mode. A quick look at the datasheet shows that there are 30 registers to program!. I've done an extensive search in the internet and there are no projects involving using this part in software mode. In fact, it seems it is not very easy to program.

But first lets explore this device in a bit more detail.

According to the manufacturer, the WM8804 has the lowest intrinsic jitter of any commercial spdif receiver. In addition, it provides large immunity against incoming jitter.

Lets explore why the WM8804 is immune to incoming jitter.

Conventional spdif receivers utilize a PLL to lock into the signal. Devices such as the very popular CS8412/14/16 operate this way. A PLL generates an initial clock with a VCO (voltage controlled oscillator) and compares the phase of that clock with an incoming clock. The error in phase results in a voltage that is feed back to the VCO until the output clock "locks" unto the input clock. According to an AES paper:

Popular S/PDIF receiver chips like the Yamaha YM3623B and Crystal CS8412 are NOT crystal controlled but rather recover the necessary clock from internal Phase Locked Loops (PLL) locked onto the incoming data stream. The simple two pin can crystals often seen directly attached to '3623's and '8412's are optional. The 3623 uses the crystal clock to quickly lock onto the S/PDIF signal. The 8412 uses the crystal clock to determine and display the sample rate and jitter level of the S/PDIF signal. Both parts ignore the local crystal clock once locked onto the S/PDIF signal.

Higher end parts will use a sample rate converter to further clean the jitter. Both TI and Cirrus have spdif receivers with built in ASRCs It is noted that the use of ASRC is controversial in high end audio (there are camps on both sides)

According to Wolfson in their white paper:

The goal here is to synchronize a clock generated from a PLL and high quality oscillator to incoming S/PDIF data stream. This is different to usual approach of using a PLL to recover a clock from the S/PDIF data stream, which inherently has to track the jitter to maintain lock.

The white paper gives the technical details, but suffice to say that it is essentially a PLL followed by a re-clocker (not a sample rate converter) with a time based derived from the crystal. I have a post comparing the difference between re-clocking and sample rate conversion here.

Measurements by Wolfson shows the WM8804 compared with another commercial part

The following picture shows the jitter performance of the WM8804 with incoming signal having 5UI of jitter injected in the input sdif signal (5UI is 5x163nsec for 48K sample frequency). Result: 51.7 psec (period jitter RMS) which is the same as the spec'ed intrinsic jitter of the device (50 psec)

The following picture shows the jitter performance of a competitive device spec'ed with 150 psec of intrinsic jitter. The result is 334psec (period jitter RMS)

To be fair, 5UI of jitter which translates into 800 nsec which is a HUGE amount of jitter. The lowly Apple Airport Express was measured by Stereophile to have a "respectably low 258ps of jitter" in the spdif output. Thus in real life, I think the relevant measure is intrinsic jitter in which the Wolfson part excels at 50 psec

Here is the WM8804 Implementation by TwistedPearAudio:

Musiland 01-US I2S Mod

2010-02-03T10:36:00.000-08:00

A reader sent me a few pictures of his I2S Mod

Clock generation in the Musiland Devices

2010-01-28T10:06:00.000-08:00

Over at diyhifi.org, user simmconn figured out how the clocks of the Musiland are synthesized (I've summarized here):

The Xilinx FPGA has two DCMs ("Digital Clock Managers"). They take an existing clock and perform integer multiplications and divisions in order to synthesize a new clock frequency. The frequencies required to handle all the sample rates are:

24.576MHz for 48KHz, 96KHz and 192KHz sample rate and
22.5792MHz for the 44.1KHz, 88.2KHz and 176.4KHz sample rate

The ratios for the DCMs to generate the required frequencies are as follows:

22.5792 MHz = 48 MHz*(14/25)*(21/25)
24.576 MHz = 48 MHz*(8/25)*(8/5)

Since there are two sets of ratios, the Xilinx chip needs to change them on the fly when sample rate changes (because the fpga used in the Musiland devices only has two DCMs).

Simmconn determined that (the earlier version of the drivers did not have this reconfiguration on the fly capability and) fixed ratios were used in the DCMs. He figured that in order to generate the two frequencies with static DCM m/n numbers, they had to select 24.576 MHz and a frequency close to 22.5792 MHz:

22.588235 MHz = 48 MHz*(8/17) -Using the first DCM
24.576 MHz = 48 Mhz X2 (using clock multiplier function of fpga) = 96 MHz; 96MHz*(32/25)= 122.88 MHz -Using the second DCM; externally divide by 5 using clock division of fpga.

if we divide this frequency by 512 (you divide by some multiple of 64 which is sort of the minimum fs), we can calculate the resultant sample frequency:

22.588235/512 = 44,117.6 Hz (Approximation)
24.576/512 = 48,000 Hz (Exact)

I previously measured MCK from the I2S lines of the Musiland MINI model:

For 44.1K Material:

For 48K Material

I also determined that fs was 128. If we use these numbers we determine that the sample frequency

5,647,218/128= 44,118.9 Hz which confirms the deviation from 44,000 Hz
6,144,177/128= 48,001 Hz which confirms that the sample rate is exact.

This was the way clocks were generated...

A NEW DRIVER...

This week Musiland released a new driver that reconfigures the two DCMs when the sample rate changes, and generates two clocks with exact frequency to support the different sample rates

The driver has two Sample Rate Control modes:

Fast Mode and Precision Mode. Fast Mode is like before: the DCMs are statically configured and the 44.1KHz family clock has a small error.
Precision Mode reconfigures the DCMs when there is change in sample rate family (e.g. from 44.1 to 48KHz) and the resultant clock is exact.

Enter raffle to support the people of Haiti

2010-01-16T19:06:00.000-08:00

Photo copyright CNN

Twisted Pear Audio is sponsoring a raffle to support relief efforts in Haiti. Raffle will be held Wed January 20. Hurry!

Happy New Year!!!

2010-01-01T10:58:00.000-08:00

Before...

May this new year bring lots of joy to you and your families!

I2S LRCK Trace

2009-12-30T23:55:00.000-08:00

Decided to measure the LRCK line again to see if the waveform was cleaner.

The picture speaks for itself. See the trace before here.

Reducing sources for noise

2009-12-30T22:36:00.000-08:00

Elsewhere it has been measured that the DC-DC converters are a potential source for noise. Because I am not using the headphone output, I decided to cut the traces to these DC-DC converters. It is only required to cut two traces which you can later jumper if you decide to reverse the changes.

Power to the second DC-DC converter goes through a trace on the underside of the board

If you are using a different Musiland model, the traces will be in different places. But the procedure is as follows:

1- Identify the DC-DC converters. These are the 8-pin chips marked "3063". You can find the datasheet for these DC-DC converters here. (There are two of them).

2- Identify the Vcc pin:

3- Find the trace that feeds this line and cut. This line also connects a local resistor and capacitors for the DC-DC converter. It may not matter whether you cut before the local cap or after the local cap, but in my mod I cut it before the local cap.

4- Make sure you don't cut the line in a place that feeds the other linear regulators (there are two other linear regulator that feeds off the same lines - there are several traces but they all connect to the 5V USB power). In the second picture you can see the line (next to the crystal) that feeds both the DC-DC regulator and the linear regulator. It branches off and feeds the DC-DC regulator through a bridge underneath the board.

5- If you plan well, you can actually use external wiring and a switch to reconnect the traces. This will re-enable the local analog output in case you feel like using the built-in headphone amp.

MUSILAND SPDIF to OPUS DAC (WM8804/WM8741)

2009-12-10T09:26:00.000-08:00

Because the MCK for the Musiland devices is 128fs which is "not supported" by the WM8741 DAC (see previous post), I decided to use the SPDIF output of the Musiland to the TwistedPearAudio Wolfson WM8804 spdif receiver board and then to the WM8471 DAC board. With this configuration each component is working at its optimal range. 44.1KHz material goes to the DAC as 44.1KHz material and the DAC can apply high up-sampling allowing it work at its optimal range.

The Musiland 01-MINI has SPDIF out, but it is not connected to an output plug. However, all you have to do is install a resistor and connect the cable to the back side of the board.

Install resistor in R22 position as shown in picture

Connect cable to backside of board

NOTE: I use 221 ohm - in theory, this resistor is a voltage divider with the input 75 ohm resistor you find in spdif receivers in order to bring the level down to .5v-1v or so for "consumer spdif". I also didn't bother with impedance matching, transformer isolation and other "audiophile" concerns as the spdif wire is just a few inches long. I did use a coax that I scavenged from a cheap RCA interconnect cable

Some traces of the spdif signal here. (Monitor US 02, but the chips are the same as the mini)

Musiland I2S Connection to WM8741 DAC

2009-12-10T00:16:00.000-08:00

From the MCK compatibility chart we can see that for 44.1 KHz sample rate, 128fs is not supported in the Wolfson WM8741. But I wanted to try it anyway. (Recall that the Musiland output MCK is at 128fs)

It actually works and sounds well. However, when switching through the different internal upsampling options, only medium upsampling and no upsampling work. High upsampling does not work.

This means that the DAC is not working optimally. Perhaps using spdif rather than I2S is a better option for this DAC (Notice from the table that the BB DACs support 128fs with all sampling frequencies)

Master Clock Compatibility

2009-12-07T12:02:00.000-08:00

I've compiled the supported MCK for different DACs. One can see that measuring the ouput MCK from a source device like the Musiland is important in order to determine its compatibility with a particular DAC.

Measuring BCK (Bit clock)

2009-12-05T14:02:00.000-08:00

So far we've measured two out of the 4 lines when using I2S. Strictly speaking, I2S only has 3 lines, but the Master Clock line is required by the DAC and some component generates the master clock.

So we've measured MCK, LRCK and now we measure BCK. The data line cannot be measured because it varies with the data and it is a bit pattern corresponding to the data. So with these 3 measurements, we can characterized the I2S interface.

For 44.1KHz material, we measured 2.8236 MHz. What does this mean? 28236/441=64.0. The BCK is running at 64 times the sampling rate or 64fs. This means that the device sends 32-bit words per channel (yes 32 bits of data per channel).

BCK can be 32fs (16 bit -16-bitx2), 48fs (24-bit per channel) or 64fs (32-bit per channel as it is in our case). DACs data sheet specify the word length it can accept, but since the send and receive bit depth do not have to match, words are either padded or truncated if there is a mismatch.

From Wikipedia:

If the Transmitter is sending 32 bits per channel to a device with only 24 bits of internal precision, the Receiver may simply ignore the extra bits of precision by not storing the bits past the 24th bit. Likewise, if the Transmitter is sending 16 bits per channel to a Receiving device with 24 bits of precision, the receiver will simply Zero-fill the missing bits. This feature makes it possible to mix and match components of varying precision without reconfiguration.

This is possible because data is transmitted MSB first.

Measuring Master Clock and fs

2009-12-05T11:05:00.000-08:00

Here is another way to measure frequency > 100 KHz. The 40-buck scope has a frequency feature that is good up to 5 MHz (It is probably good up to 8 MHz as some users have experienced)

The picture shows the MCK line with 44.1KHz material playing. If we divide this by the sample rate, 5,647,218 Hz / 44,100 Hz = 128.055. Thus the system is running at 128x fs

What would be the frequency for 48KHz? We know the fs=128x, so the frequency is 48,000x128=6.144 MHz

Pretty good measurement...

Measuring MCK (System or Master Clock)

2009-12-05T00:19:00.000-08:00

Another signal line that is required when using the I2S connection is the system clock (MCK or SCK). This runs in the many MHz range so you need a "real" scope. Another diyer, jkenny, took these measurements of his Musiland 01-US. The system clock is the clock that is fed to the DAC and all other signals are based of this clock signal

The picture below is for input signal with 44.1KHz sample rate. If one divides the frequency by the sample rate, 5.71Mhz/44.1Khz=129. System clocks are designed at 128x, 256x, and so on. Thus from this measurement we find that the Musiland device is running its master clock at 128fs

Why is this important? Because DACs are designed to run at a specific range (range of fs) for the master clock. If you operate the DAC outside this range, the DAC performance may suffer

The following picture is for input sample rate of 96KHz

Musiland I2S

2009-12-04T17:21:00.000-08:00

One of the reasons I had to measure the I2S frequency was because I connected the MUSILAND 01-MINI to the WM8741 DAC by tapping the I2S lines. Here you can see the MUSILAND device (which implements asynchronous USB transfer and supports up to 192 KHz sample rate content -and good reviews in the audio forums). I took it out of its metal casing, attached it to a plastic board and tapped the I2S lines that connects the fpga to the internal DAC

I2S lines in the Musiland 01-MINI

The I2S lines on the Musiland 01-US

Measuring I2S with Cheap Scope

2009-12-03T23:58:00.000-08:00

I decided to to some audio measurement with the scope. Measuring I2S was the perfect exercise as the different clocks are sent in separate wire. Because of the limited bandwidth of the scope, choosing the slowest clock was necessary. A quick look at the I2S specification indicated that measuring the LRCK, the clock that tells you left channel data and right channel data was the line to measure.

Because in a single cycle LRCK indicates the transfer of data for a single stereo sample (left channel and right channel), LRCK always matches the sample rate. See Wikipedea for a better explanation.

Here is the measurement when iTunes plays at 44.1KHz sample rate

Here is the measurement when iTunes plays at 88.2KHz sample rate

Here is the measurement when iTunes plays at 96KHz sample rate

$49 Oscilloscope

2009-12-03T18:12:00.000-08:00

A pretty good scope for audio applications. Maximum analog bandwidth is 1 MHz. However, the maximum signal you can comfortably measure is 1/10 of that or 100 KHz (this is a rule of thumb, but I don't know the theory behind it). According to this thread and this thread, the practical upper limit is about 100KHz and with some tweaks and a proper probe you can measure up to 150KHz-200KHz.

There is a Google group with discussions on this scope. Check out the "pages" section for more info on modding/upgrading the scope. The manual can be found here.

Tips & Tricks:

10x diy probe: link

OSR bits in WM8741

2009-11-19T12:36:00.000-08:00

According to a Wolfson Engineer,

OSR, it's the DAC-to-input-rate-ratio. We want that to be high to have the DAC run fast, but not too fast to introduce timing related mayhem. You can't set this ratio directly but only indirectly through R7.

When you set low rate what you tell the DSP is high OSR. It means we use the maximum amount of upsampling since we know the input rate is low enough such that the resulting DAC frequency lies in the sweet spot of performance: high to run the sigma/delta with loads of headroom, not too high so as to introduce analogue problems.

For medium and high rates, the actual upsampling ratio reduces such that with the higher input rates we end up with the same actual DAC frequency.

Thus the OSR bits in the DAC controls the Internal upsampling of the DAC.

Low rate means "apply highest internal upsampling"
Medium rate means "apply medium internal upsampling"
High rate means "do not apply any internal upsampling"

You can test this out with the following:

If you input sample frequency to the DAC is 44.1 KHz, you can select any one of the 3 settings. With Low Rate, maximum internal upsampling is applied, with High Rate, no internal upsampling will be applied.
If your input sample frequency to the DAC is 192 KHz, then you can only select High Rate, meaning that no internal upsampling can be applied because the input data is at high rate or has been upsampled outside of the DAC

Testing WM8741 filter setting

2009-11-18T23:16:00.000-08:00

Some people can hear differences between the digital filters in the WM8741 DAC. In my setup, I can't really hear clear differences between the different filter settings, and up to now I had no way to test whether the different filters were being selected by the software in Arduino.

The good people at AMB did an excellent job in characterizing filters 1, 2, and 3 with different upsampling, and found that without upsampling (i.e., with 44.1KHz material), filters 1 and 2 will roll off at 15Khz as compared with filter 3 as shown in this picture:

I downloaded a 15 KHz test tone (from mosquito ringtones) and played it in a loop in iTunes. The output was set at 44.1 KHz and I set the OSR bit in the WM8741 to "high" (meaning do not use internal upsampling). Then I selected and compared filters 1, 2, 3. Indeed, you can hear an attenuation with filters 1 and 2 as compared to filter 3. Filter 1 is filter A, 2 is B and 3 is C.

Therefore the software is working. (Keep in mind that if you are an old guy, you will need to ask a kid to help you listen to the 15KHz test tone)

Logic Level Converter

2009-11-03T10:33:00.000-08:00

NKC Electronics has released this little board to allow converting voltage levels between Arduino and other devices.

Recall that Arduino is typically a 5V device and devices that you want to control (such as a DAC) are 3V devices. If you use the Arduino I2C interface (which is 5V logic) to control the 3V I2C interface of a device, you need this converter. More information here.

LCDUINO-1

2009-10-15T22:10:00.000-07:00

When I started my project, I posted in DIYAudio and got totally ignored. Fortunately other people recognized the potential of using Arduino for audio and have invested in making Arduino an "audio-friendly" device.

LCDUINO is an arduino-compatible board (I wouldn't call it a clone because it cannot use "arduino shields"). I believe the primary goal was to build a board of the same footprint as a 16x2 LCD so that it fits neatly behind the LCD, facilitating the construction of something like a headphone amplifier.

The device is the equivalent of an Arduino board (or clone) plus a serial LCD (which is what I used for my project). LCDUINO adds a real time clock, but lacks the USB chip for programming. I think a second goal for the project was to provide a lot of code so that for many purposes, no programming is necessary. If you want to program the board yourself, you will need to purchase a USB to serial converter and connect it to the LCDUINO

The real jewel in LCDUINO is the code that linuxworks is developing for the board which will be available to the user community.

You can find more at linuxworks web site and the AMB website.

Arduino+Buffalo

2009-10-15T20:32:00.000-07:00

I think this is the first public project of Arduino controlling a Twistedpairaudio Buffalo DAC [link]

Tuning iTunes

2009-10-08T11:15:00.000-07:00

Haven't posted for a while... Spending time listening to music. I use iTunes running on Windows Vista

One anoying thing in iTunes is that in album view, it separates songs if they have multiple artists. The way to fix this is the following:

"You can mark these songs as a compilation in iTunes. Do do this, select all the songs that you want to be included in the compilation and select Get Info from the file menu and select Yes in the Compilation menu as shown below. After clicking OK iTunes group all the selected songs together." [Link to Apple for complete article]

iTunes on PCs is also bit perfect if you match the sampling rate in the Quicktime control panel to the sampling rate of the source material. Ken Poon explains it well in his blog.

The latest version of iTunes has a different dialog box:

4 1/4 Digit DMM

2009-08-04T13:12:00.000-07:00

Purchased this DMM in Shenzhen, China for RMB 200 (about 30 bucks) at the famous SEG Electronics Market. Yeap, everything you've heard about this place is true!.

2009-06-28T23:04:00.000-07:00

How Asynchronous Rate Conversion Works

2009-06-26T00:12:00.000-07:00

Continuing with the discussion thread at DIYaudio, I will attempt to summarize how ASRC works.

Synchronous rate conversion

Let's say we are dealing with a SYNCHRONOUS rate conversion problem, from 44.1kHz to 48kHz, where both rates are derived from the SAME clock source. Meaning that, when measured with the same stopwatch (clock), the 44.1kHz rate is EXACLTY 44.1kHz, and the 48kHz rate is EXACTLY 48kHz. In this environment, one could simply interpolate by 160 to 7.056MHz and decimate by 147 to 48kHz:

The first thing to do (at least conceptually) is to take the 44.1kHz data stream and stuff 160-1=159 zeros, evenly spaced in the time domain, between each sample. Then you apply the "zero-stuffed" sequence to a low-pass filter (cutoff at half the original sample rate or 22.05kHz), which will finalize the interpolation process by "filling in" the zeros with real data points. (hard to envision, but this is what happens with digital filters).

Now we simply grab every 147th sample, to generate our output sequence at 48kHz. That "grabbing every 147th sample" is precisely DECIMATION. Just digital re-sampling, or down-sampling. We didn't need a special filter for decimation in this case, because the interpolation filter did it's job for us.

Asynchronous rate conversion

In ASYNCHRONOUS sample rate conversion. The 44.1kHz clock and the 48kHz are NOT derived from the same time base, meaning they are not exactly the numbers they claim to be, when measured with the same stopwatch. So, in this asynchronous world, if have two time lines: one with ticks every 44.1kHz, the other one with ticks every 48kHz. Thus by definition, Asynchronous Rate Conversion is this:

There is NO interpolation by any FINITE integer you can do on the INPUT sample points ... meaning, no finite number of samples you can evenly space between the original samples ... that will give you perfect alignment with all the OUTPUT sample points.

Asynchronous Sample Rate Conversion: How does it work

Here we have a situation where we need to digitally CALCULATE output data samples at new points in time, different than the input data time points. And the time points are NOT synchronized. ... so there is no finite integer interpolation that we can perform on the input data that will align PERFECTLY with the output time points we need.

But we don’t have to be PERFECT. Conceptually, we will interpolate the input data by a pretty huge number, in fact, by a pretty huge INTEGER number, so that we effectively "fill in" very many samples in-between the original Fs_in samples. So instead of providing an interpolated input sample that corresponds to that exact point in time, we can provide the closest (in time) interpolated sample that is calculated. How BIG will the error be? The question is therefore is ... How far do I have to interpolate, by what integer, so that grabbing the most recent sample will give me acceptably LOW error ?

We can never achieve perfection here, but we can get ARBITRARILY CLOSE ... simply because the higher I interpolate, the lower the error. So the question is, how big should the interpolation number “N” be?

After a lot of math, it can be shown that input data at the Fs_in rate needs to be interpolated by N~2^20 (1,048,576 -over a million!), so that the error incurred by Asynchronous decimation to Fs_out will be acceptably small. But 2^20 is HUGE resulting in a frequency of 50 GHz and this is for an input sample frequency of 44.1 KHz.

Fortunately, because most of the samples are going to be ignored when decimating to the output sample rate (e.g. 48 KHz), we don’t have to calculate them in the first place. We only need the samples closest to the output sample rate. In order to do this we use FIR filters (Finite Impulse Response). And though clever implementation, and by knowing the output sample rate, the computational demands of implementing the FIR filter are manageable in a typical commercial implementation. (Meaning you don't have to do all the math or have heavy-duty computational engines).

My observations: Rate conversion from 44.1KHz to 192KHz is the same as 44.1 KHz to 176.4 KHz

From the above discussion, it can be seen that because the system is designed to select the interpolated sample that is closest to the output sampling rate, it does not matter whether the output sample rate is an integer multiple of the original sample rate or not.

This is important because in some audio circles it is believed that for CD material with its native sample frequency of 44.1KHz, it would "sounds better" if sample-rate converted to 88.2 KHz or 176.4KHz (integer multiple) than to 96KHz or 192KHz (not integer multiple). The argument presented here (by the expert at DIYaudio), at least from a theoretical point of view implies that the closest matching sample to clock-ticks in a 192 KHz clock, for example, should be no worse than the closest matching sample to clock-ticks in a 176.4 KHz clock.

Asynchronous Re-clocker vs Asynchronous Rate Converter

2009-06-25T21:30:00.000-07:00

The same discussion thread teaches the theory behind sample rate conversion.

We should first distinguish between two terms that are often used interchangeably in audio circles but are completely different technologies:

Asynchronous re-clocking

Asynchronous re-clocking or re-sampling: this term describes a pretty simple operation where a digital audio signal is simply re-clocked by a clock from a different time base. There is no interpolation or rate conversion performed on the signal.

Asynchronous Sample Rate Conversion:

This is categorically different, in the sense that SIGNIFICANT interpolation is performed on the Fs_in (input sample rate) signal to minimize error (both time & freq domain) when the ultimate decimation to Fs_out (output sample rate) occurs. Example chips that can perform this function are the CS8420, AD1896 (and their brethren)...

...and the SRC4192 which is the subject of the next project.

More on Pre/Post ringing

2009-06-25T07:40:00.000-07:00

There is an excellent discussion thread on digital sampling at DIYAudio. In one of the posts, the following is explained:

"Pre/post ringing : most obvious in the classic step response of a steep, linear phase (usually FIR) filter. ... Let me just say now, for the record, that the pre/post ringing we often encounter in digital audio is nothing more than an artifact of the Gibbs phenomenon which simply states that abrupt transitions or discontinuities in one domain, cause ringing in the other.

Band-limited systems unfortunately fit in this category and there is no better example of a SHARPLY band-limited system than digital audio. Don't like the ringing? Sure we can eliminate it but the price you pay will be aliasing, pure & simple, no way around it. And that's a BAD tradeoff."

What is described above is the fact that with a linear phase filter, reducing the ringing will require the use of slow roll off filters allowing higher frequency images to reflect back into the audio band (this is called Aliasing).

More modern DACs such as the one we used in this project are addressing this problem with so called "minimum phase filters" and to completely eliminate any aliasing, the concept of "Apodizing filters" are used together with minimum phase filters.

We previously explained the digital filters of the WM8741 here.

Which I/O Expander?

2009-06-24T15:47:00.000-07:00

My next project is to control the Texas Instruments SRC4192 chip. This device is an "asynchronous reclocker" and feeds the DAC. Theoretically it reduces jitter because it recreates the clock with a much better on-board oscillator. The device is implemented in a kit board from TwistedPearAudio.

The block diagram is as follows:

In order to interface to the control logic lines, I would need an I/O expander that would communicate with Arduino. Basically you want to swith these lines high or low to select the different configurations and features of the device.

Since there are up to 15 control lines and it needs to support the I2C protocol (to communicate with Arduino) and must by in DIP package (for easy soldering). I would need a 16-port I/O expander in DIP package. Looking over at Digikey, there is just one device in stock that meets the criteria: the PCA9555 by NXP Semiconductors.

It cost $2.13 Application note AN469 explains how these devices work in great detail.

More on Volume

2009-06-24T12:21:00.001-07:00

In the latest code, I've fixed the volume values I used to program the WM8741. Previously I mistakenly used 0.25 dB as the smallest interval whereas it is .125 dB the smallest interval, so my volume readings were twice the actual value.

Also I did not see the need to use an interval of less than 1 dB because it is already not very discernible a difference of 1 dB.

Now, the typical listening level is above -50 dB, and mostly in the -30 dB to -15 dB. Therefore above the -48 dB at which point you will start experiencing (theoretically) some loss in information due to the nature of digital volume control.

I also got a response from Wolfson about how the volume control is implemented: Basically input less than 24 bit is padded to 24 bit, input that is 25 to 32 bit is reduced to to 24 bit with dither and the volume control is applied at the next stage.

LCD Settings in Arduino EEPROM

2009-06-22T00:26:00.000-07:00

I've added adjusting the LCD Brightness and Contrast with the remote. I've assigned one button in the remote to select between "no adjustment", "brightness adjustment" and "contrast adjustment". This button is a toggle between these three modes.

When entering the brightness mode, the current value is read from the Arduino EEPROM. Two other buttons in the remote are used to increase the value and decrease the value, and adjust the LCD accordingly.

When entering the contrast mode, the current value for contrast is read from the Arduino EEPROM. Two other buttons in the remote are used to increase the value and decrease the value, and adjust the LCD accordingly.

When you exit the adjustment mode, the current settings for brightness and contrast are saved in the Arduino EEPROM. I've used addresses 0 and 1 in the EEPROM space to save the two values. The EEPROM of the Arduino ATmega 168 has 512 bytes of space and the ATmega328 has 1 K bytes of space.

The code for selecting the mode, read and write to EEPROM is as follows. Pressing a specified key in the remote will invoke the following code:

case KEYDISPLAY:
   BC++;
   if (BC%3==0){
     lcd.setCursor(0,4);
     lcd.print("       ");
     EEPROM.write(BRIADDR,brightness); // Save value
     EEPROM.write(CONADDR,contrast);  // Save Value
   }
   if (BC%3==1){
     lcd.setCursor(0,4);
     lcd.print("BRI ");
     brightness=EEPROM.read(BRIADDR); // Read value
     lcd.print(brightness);
   }
   if (BC%3==2 ){
     lcd.setCursor(0,4);
     lcd.print("CON    ");
     contrast=EEPROM.read(CONADDR);  // Read value
     lcd.setCursor(8,0);
     lcd.print(contrast);
   }
   delay(100);
   break;

To adjust the brightness and contrast, we send a value to a specific address in the LCD I2C interface/controller (This is a I2C LCD from web4robot). We use the Arduino wire library. The I2C address for the LCD is 0x4C, 0xFE is a prefix indicating that it is a command and not text to be displayed. 0x03 is the command for brightness and ox04 is the command for contrast. After sending the prefix and the command, the value is sent. Brightness value is 0-255 and contrast value is 0-100. The code is as follows:

// Routines for LCD Adjustment

// For LCD backlight adjustment
void BackLight(uint8_t bright)
{
Wire.beginTransmission(0x4C);
Wire.send(0xFE);
Wire.send(0x03);
Wire.send(bright);
Wire.endTransmission();
delay(25);
}

// For LCD contrast adjustment
void Contrast(uint8_t cont)
{
Wire.beginTransmission(0x4C);
Wire.send(0xFE);
Wire.send(0x04);
Wire.send(cont);
Wire.endTransmission();
delay(25);
}

Latest Code v 0.7

2009-06-21T23:09:00.000-07:00

Everything I've written is in this new code base. And everything is less than 9K. Link in the sidebar.

New Fonts

2009-06-20T21:05:00.000-07:00

Inspired by a new 4-line large font template at the Arduino forums (you can find the link in the sidebar), I decided to tweak my own 3-line Arduino large font.

Basically you create a number of shapes as custom characters and used them to form the large font. However, you are limited by the number of custom fonts you can specify in an LCD (typically 8). The 4-line large font in the Arduino forums is actually the same size as my 3-line large font. But by having 4 lines you have more flexibility in positioning the custom characters "to preety-up" the fonts but you give up some speed in displaying the large numbers (25% speed penalty: 3 lines vs 4 lines). Here are the results

The left most number displays the selected digital filter in the DAC. Above, I've added an abbreviation to the name of the filter. In this case, LnS is "Linear Phase, Smooth Roll Off".

"LnA" means "Linear Phase, Apodizing". Also displayed is RATE, the input sample rate to the DAC. There is also filter #2: MnS: "Minimum Phase Smooth Roll-off"

"BrK" means "Brickwall" filter. Also displayed is INPT, the input format to the DAC. The WM8141 can receive both PCM (from CD players) and DSD (from SACD players). In the future i will be experimenting with extracting the DSD signal from inside a player and feeding this signal straight to the DAC.

"MnA" is "Minimum Phase, Apodizing" filter. Here RATE has been changed to 48K. Because the incoming signal is processed through a asynchronous reclocker chip to 192KHz, there is a sample rate mismatch and the DAC does not output any sound (In theory, this setting selects the appropriate filters to match the sample rate). In the future I will be using Arduino to control the asynchronous reclocker chip in order to change its output sample rate.

I2C Address and R/W bit

2009-06-13T11:13:00.000-07:00

I was reviewing my code and could not remember why the register addresses I defined in the code was different from the register addresses defined in the data sheet of the WM8741. After an hour reviewing the data sheet and the I2C protocol, I finaly realized that I2C address are 7 bit and the 8th bit is the Read/Write bit.

Since all the registers of the WM8741 are all write registers (R/W bit=0), they all end with zero. So the address value that you send in the I2C protocol is the 7 bit address plus the R/W bit, so the 8-bit values ends with zero.

Example:

7-bit Address plus R/W bit

00h=0000000 plus R/W bit = 00000000 = 00h or 0x00
01h=0000001 plus R/W bit = 00000010 = 02h or 0x02
02h=0000010 plus R/W bit = 00000100 = 04h or 0x04

Why Pull-Up Resistor?

2009-06-11T14:49:00.000-07:00

An often suggestion in Arduino debugging is "whether or not a pull-up resistor has been installed"

Why do we need a pull-up resistor? This article explains it well (and this one too), but in summary,

For an (digital) input pin, A pull-up resistor will set a default value when there is no signal at the input. In other words, when there is no input you don't want some random value but a definite value.

Also,

If when there is input you measure 0 (or low), and when there is no input you want it to measure 1 (or high), then you must use a pull-up resistor.
If when there is input and you measure 1 (or high), and when there is no input you want it to measure 0 (or low), then you must use a pull-down resistor.

But since Arduino has built-in pull-up resistors that can be enabled in software, you should think about a configuration that only requires pull-up resistor or you must implement the pull-down externally. However, if your external signal already has two definite states (high and low), then you don't need to enable the pull-up resistors inside the Atmel chip

Arduino Code for Rotary Encoder

2009-06-01T22:09:00.000-07:00

(Update: I've improved the code. Take a look here. You have the choice to do h/w deboucing or s/w debouncing or both. The s/w debouncing code is just one line of code)

Reliable use of mechanical encoders requires two components: a hardware tweak and (of course) code. Although there are many sample code for rotary encoder, I feel the following is the simplest code for rotary encoders. This version is interrupt-based.

The interrupt routine simply detects direction of motion:

void decoder()
{
if (digitalRead(4) == digitalRead(2))
{
volUp = 1; //if encoder channels are the same, direction is CW
}
else
{
volDown = 1; //if they are not the same, direction is CCW
}
}

Here we connect terminal A of the rotary encoder to Arduino's digital pin 4 and terminal B to digitalpin 2. The third terminal of the encoder is connected to GND. In this configuration the rotary encoder pulses will be pulling the pins to GND. In this example, we are controlling volume so one direction is volume up and the other direction is volume down.

We attach the interrupt with:

attachInterrupt(0, decoder, CHANGE);

and we detects CHANGE of the pulse. We need to detect rising edge and falling edge of the pulse in order to utilize the full resolution of the rotary encoder.

During set up, we want to enable the pull-up resistors for pin 2 and pin 4 with:

pinMode(VOLUPPIN, INPUT); // Pin 2
digitalWrite(VOLUPPIN, HIGH); // Enable pull-up resistor

pinMode(VOLDOWNPIN, INPUT); // Pin 4
digitalWrite(VOLDOWNPIN, HIGH); // Enable pull-up resistor

Note: it doesn't matter which channel is connected to which pin to start with. You can always switch the connections if you expect the opposite result.

Then in a loop we detect when the flags are set and do accordingly:

while(volUp==1) // CW motion in the rotary encoder
{
volUp=0; // Reset the flag
// Do something
}

while(volDown==1) // CCW motion in rotary encoder
{
volDown=0; // clear the flag
// Do something else
}

Code Explained

2009-05-31T22:08:00.000-07:00

Arranged a bit the way I present/share the code. Check out the sidebar links.

Now that I've learned a bit more, I'm going to attempt to explain the code I write, and then present the complete code. Hopefully this will be most useful for beginners.

The code presented in the sidebar is/will be the best and simplest examples I could find, customized to the current application.

Arduino Controller & DAC

2009-05-31T15:51:00.000-07:00

The DAC is a kit from TwistedPear Audio, based on the WM8741.
2-wire I2C connection (plus GND)

Inside the OPUS DAC: Leftmost is the toroid transformer inside a tin can. Middle is a dual DC power supply, rightmost are 3 boards stacked: top is the SPDIF receiver, middle is the asynchronous re-sampler and re-clocker board and bottom is the DAC board based on the Wolfson 8741.

Detail of the 2-wire I2C connection to the DAC board.

Detailed connection diagram

Arduino I2C connections are analog pin 4 and 5

Reusing Hard Disk Parts for the Case

2009-05-30T21:28:00.000-07:00

Always wanted to reuse old hard disks as the cases are made of high quality aluminum. Here are parts from different hard disks. These parts will form the top and bottom of the Arduino controller case. Once you get a hold of the right screwdrivers, it is a breeze to dismantle a hard drive (It is actually faster and more fun than reformatting a hard drive if you want to securely dispose of it)

The first step is to cut the front piece. After measuring the text area of the LCD, I cut the opening with a hand saw (and a lot of sanding to get is straight). Then in order to align and mount the LCD I glued two strips of wood with the LCD in place. (Although the picture below shows the sides already glued, you do this step without the sides in place)

Next I cut the sides and glue them to the front piece. In order to facilitate positioning and gluing, I first mounted the top and bottom aluminum pieces to the sides and then with the box already formed, I glued it to the front piece. I also put some weight on top of the box to allow better gluing. Used regular wood glue.

The front and sides glued together.

Next, I mounted the "shield" to the case. In this configuration, the shield is fixed and the Arduino (Freeduino) is removable. All the connections are to the shield, including DC power. I can easily remove the Arduino board for programming and leave the controller attached to the stereo system. The small green board at the forefront is the 3.3V I2C level shifter. The DAC connects to the Arduino controller through these 5 pins. Center pin is GND as GND has to be shared between controller and device.

Below, you can see the Freeduino board mounted on top of the "shield". As the Freeduini is a kit, I soldered the headers on the bottom of the board.

Here you can see detailed connections to the different parts.

Posted Code for Large Numbers

2009-05-24T19:18:00.000-07:00

Follow the link the post below.
I used a little utility from LadyAda to format the code. (Unfortunately, the formatter doesn't work with the template colors I selected in this blog, so the code is posted in a wordpress blog.)

Arduino LCD Custom Fonts, Large Numbers

2009-05-23T19:24:00.000-07:00

Couldn't see well the standard size text of the display from the listening position (partly due to old age and old glasses :-)). So I did some research in the Arduino forums and found some code for using custom characters to display large numbers. Also used the example sketch that came with the LCD libraries.

The numbers I created are 9X the standard text size (3X3). Each number is composed of 9 custom characters.

The numbers can display very fast if you change the built-in delays in the library to zero with lcd.setDelay(0,0). The movie shows the speed with this setting.

The programming is very simple. First the custom characters are defined. In the LCD I am using you can define only up to 8 custom characters. For example, the following code defines one custom character where all the pixels are turned on:

uint8_t cc1[8] = { // Custom Character 1
B8(11111),
B8(11111),
B8(11111),
B8(11111),
B8(11111),
B8(11111),
B8(11111),
B8(11111)
};

NOTE: B8 is a macro defined in "macro.h" - Binary constant generator macro by Tom Torfs and included in the sample code that comes with the LCD library -there may be an easier/different way to define the characters, but I did not try...

Then you load the custom characters into the LCD's memory. The library for the web4robot LCD has a function to load the custom characters. For example, the following call loads custom character 1 into location 1:

lcd.load_custom_character(1,cc1);

In order to print custom character 1, the function lcd.write(1) is used. In order to facilitate the printing of the composite larger characters, a "bit map" is created with arrays as follows:

//___________0_____1_____2...
char bn1[]={1,2,1, 3,1,4, 2,2,1,...};
char bn2[]={1,4,1, 4,1,4, 7,6,5,...};
char bn3[]={1,3,1, 3,1,3, 1,3,3,...};

In other words, the number 1 is created by writing custom charters 3,1 and 4 in row 1, custom characters 4,1 and4 in row 2 and custom characters 3,1 and 3 in row 3. The following function does precisely that.

void printOneNumber(uint8_t digit)
{
// Print position is hardcoded

// Line 1 of the one digit number
lcd.setCursor(1,0);
lcd.write(bn1[digit*3]);
lcd.write(bn1[digit*3+1]);
lcd.write(bn1[digit*3+2]);

// Line 2 of the one-digit number
lcd.setCursor(2,0);
lcd.write(bn2[digit*3]);
lcd.write(bn2[digit*3+1]);
lcd.write(bn2[digit*3+2]);

// Line 3 of the one-digit number
lcd.setCursor(3,0);
lcd.write(bn3[digit*3]);
lcd.write(bn3[digit*3+1]);
lcd.write(bn3[digit*3+2]);
}

The complete code can be found here.

Bug in Volume Value

2009-05-21T17:23:00.000-07:00

I miss read the specification and thought volume control resolution was 1/4 dB. The specification says 1/8 dB. Thus rather than having a volume control range of zero to -99 dB, in reality it was only zero to -49.5 dB.

This is actually "good news" as my normal listening level was in the -50 dB range which in fact was -25 dB.

As discussed in a previous post, from a theoretical point of view, there is no loss of data for the upper 48 dB volume level. I was wondering why for a passive volume control, -50 dB sounded so "loud"

Installed IR Remote Sensor

2009-05-20T08:55:00.000-07:00

Used a small piece of fiber optic to transmit the IR signal to the inside of the case where the IR sensor is installed

Simplest Arduino Sony Remote Code

2009-05-16T13:46:00.001-07:00

Following the example indicated in the previous post, I've modified the remote control code to a simpler version. I've deleted all the error checking because the code only acts upon a valid code (uses a switch statement) thus if a code is invalid, nothing will be done and therefore the error checking is not necessary. Just like before, it is interrupt driven.

The Sony TV remote protocol is the simplest to program because we only need to detect the start pulse and then determine if the length of the next 12 pulses (13 pulses total).

The pulses are only measured while low
The first pulse, the start pulse, lasts about 2.4 ms (2400 microseconds)
The following pulses are 1.2 ms (1200 microseconds) for a 1, 0.6 ms (600 microseconds) for a 0
Each data pulse is about 0.3 ms (300 microseconds) apart
Every set of 13 pulses is about 20-30 ms apart from each other, repeating when a button is held down

The code below will watch for a 13 pulse set and returns the set's integer equivalent,

The interrupt service routine is very simple. The remote signal is connected to pin 3 (which in Arduino is interrupt 1). When there is a pulse, an interrupt is generated and the service routine sets a flag:

void remoting() // The ISR
{
remoteOn=1;
}

And in the setup portion of the Arduino code, the interrupt routine is attached:

attachInterrupt (1, remoting, FALLING);

We detect the FALLING edge of the pulse because the pulses pull down. Once the flat is set (indicating that there is remote control signals, we proceed to detect and decode the pulses with the following code:

int getIRKey() {
  int duration=1;
  int result=0;
  while((duration=pulseIn(IRPIN, LOW, 50000)) < 2200 && duration!=0)
  {
    //do nothing waiting for start pulse
  }

  int mask = 1;        // set mask to bit 0
  for (int idx = 0; idx < 12; idx++)     // get all 12 bits
  {
    duration = pulseIn(IRPIN, LOW, 2000);   // measure the bit pulse
    if (duration > ONEPULSE)      // 1 bit?
 result |= mask;       // yes, update ir code
    mask <<= 1;        // shift mask to next bit
  }
  return result;
}

The while loop waits for the start pulse, however when there is no start pulse and we are still inside this loop, we need a way to exit this loop. We use the duration!=0 condition.

In the main remote loop we detect the pulses and perform the functions specified by the codes as follows:

while (remoteOn==1)
{
int key = getIRKey(); //Fetch the key

// Interpret the keys and do something: increase volume, etc
// I use a switch statement

delay (30);
remoteOn=0; //reset flag
}

I found that I needed some delay to get rid of "spurious interrupts" (interrupts that resulted in invalid code). You may or may not need this delay. Invalid code are innocuous because they are ignored in the switch statement.

Note: some parts of the code is missing. Please see the full code from the link above.

Simpler Arduino Sony Remote Code

2009-05-15T11:14:00.001-07:00

Found and even simpler code for Sony Remote: link.

The only modification required is for the do while loop that waits for the start pulse to break out when pulseIn() times out.

Digital Volume Control

2009-05-13T08:00:00.000-07:00

One of the features enabled by Arduino is Digital Volume Control. The DAC can control volume through its software interface.

In audio, the function of a preamplifier is really just to attenuate its volume (in the post vinyl era) but modern DACs are beginning to do that in the digital domain without sacrificing any sonic detail throughout most of the volume scale. Wadia has a good paper explaining how this works. To summarize, every 6 dB of attenuation is equivalent of reducing resolution by 1 bit. With 24-bit DACs and 16-bit content (CD content is 16-bit), 8-bits of resolution can be "thrown away" before affecting the data. Therefore with the Wolfson DAC, 48 dB of attenuation is achievable without whatsover impacting the data.

I have implemented the volume control from 0 to 99 dB attenuation. This means that down to -48 dB, the original data is completely retained, and in theory you will start loosing some resolution below this volume level. In practice, CDs have resolution only up to 14-15 bits and therefore there is virtually no loss of fidelity down to -54dB to -60dB of volume attenuation.

PS Audio explains the advantages of controlling the volume in the digital domain in this post. According to Paul McGowan,

"The rub (with the digital volume control) comes in when we listen to high resolution 24 bit audio, In this case, we are indeed losing some of the bits when we use the control. However, I still prefer using this straight into the power amp vs. a preamp. This is because those last few bits are so far down into the noise area of the system I don’t know if anyone can hear them. Indeed, theoretically this is hampering the dynamic range and losing some of the advantage of the higher bit rates, but from a practical standpoint it doesn’t seem to matter - or if it does, I can’t hear it. Maybe others can."

Apodizing vs Non-Apodizing

2009-05-11T19:01:00.000-07:00

I've interposed the filter response diagrams of the WM8741 DAC found in the data sheet. Indeed, the Apodizing filter has a sharper roll-off than the "soft-knee" filter. Both filters are minimum phase, (thus eliminating the pre-ringing), but the Apodizing removes aliasing distortion and the soft-knee reduces post ringing. Conceptually, Ayre is a proponent of the minimum phase soft-knee filter whereas Meridian is a proponent of the minimum phase apodizing filter. Which one is "better". I think Wolfson was wise to include different filters as there is no consensus about which filter is "better.

Here is a comment from the Meridian Forums by user scottb:

The discussion of eliminating artifacts from the original A/D conversion is not a function of apodising filters per se, but rather a function of the specific filter parameters chosen. Peter Craven, when he originally proposed minimum phase filters, also proposed that the filter should roll off very steeply after 20 khz, more steeply even than the usual filters applied at the A/D and D/A conversion. That way, any ringing from the A/D conversion process would be filtered out, albeit at the expense of considerable post-ringing and phase shift from the apodising filter itself - which shows up in JA's measurements. [Note: This is from Stereophile]

By contrast, the Ayre white paper I've mentioned frequently before claims that their implementation sounds better with quite gentle filter slopes, which will obviously allow more ringing from A/D conversion to get through, as well as more aliasing distortion, but will create much less post-ringing from the minimum phase filter. That's a pretty interesting disagreement between the ears of two of the best digital audio designers in the business, and JA's evaluation of the new Ayre MP filter will bear watching.

BTW, you must upsample to do apodising, or any digital anti-aliasing filtering, because the filter knee is so close to the Nyquist frequency. Whether you speak of the filtering being applied after upsampling, or as part of the upsampling process, is really a matter of semantics. From the perspective of upsampling the original digital signal, you must upsample in order to filter, and you must filter if you upsample.

WM8741 Digital Filters

2009-05-09T19:05:00.000-07:00

One of the reasons I embarked to use Arduino to control the WM8741 DAC was because certain digital filters are only available thought the s/w interface. I've done some additional reading about these filters. The DAC has the following 5 selectable filters. The names of these filters are mentioned in a white paper and in the data sheet of the new WM8742. (The 8742, however seems to be a cost-efficient version of the older WM8741 which is spec'ed as having better signal to noise ratio). These filters are:

Linear phase ‘soft knee filter’
Minimum phase ‘soft knee filter’
Linear phase brickwall filter
Minimum phase apodising filter
Linear phase apodising filter

Filter #3, the linear phase brickwall filter is the traditional/historical filter for digital audio. It is a steep filter right after 20 KHz and has been shown to produce a lot of pre and post ringing from an inpulse response. Wolfson indicates that this filter is to be used with other filters (from other components such as DSP chips) in the digital audio path. Filter #1 is the "slow roll off" filter that more modern DACs and CD players have used to remove some of the "digital hash" that have been observed in the past. The slow roll off filter reduces both the pre and post ringing of an impulse response. These two filters brickwall or fast roll-off and soft knee or slow roll-off have been the mainstay of digital audio reproduction for all these years.

Filter #2 is a new kind of digital filter. Whereas in the past audio engineers have insisted in phase linearity (meaning all frequencies have equal phase or delay), More recent research have shown that a "minimum phase" filter sacrifices some of the phase linearity (adds some phase distortion) for better time response. Specifically, minimum phase filters minimizes the pre-ringing of an impulse response. Audio researchers have argued that pre-ringing is an un-natural effect and therefore the ear is more sensitive to this kind of distortion. They have also argued that phase distortion is not very audible. This filter also incorporates soft-knee or slow roll-off and this reduces post ringing as well. The properties of this filter are similar to the "MP filter" found in Ayres latest CD player.

Here is a diagram depicting the impulse response in a linear phase filter and a minimum phase filter.

According to the Ayre white paper, adding the properties of slow roll-off filter to the minimum phase filter will decrease the post ringing, resulting in something like this:

Note that the axis are different, but in relation ot the first diagram, the second diagram shows no pre-ringing and much reduced post-ringing.

Conceptually, the Wolfson Minimum Phase soft-knee filter is the equivalent of Ayre's MP listen filter. Obviously the implementation is different and the relative quality of these filters have not been evaluated.

Filter 4 and 5 are only available through the s/w interface. "Apodising" ("Apodizing" in American English) filters have been equated to minimum phase filters and minimum phase filters with slow roll-off in the literature. But as the name of the filters in the Wofson DAC suggests, "apodizing" is an additional filter technique to that provided by minimum phase soft-knee.

The use of slow roll-off filters allows some of the higher frequency (beyond the Nyquist frequency) energy to be reflected back into the audio band. This is known as "aliasing" an is a source of distortion. An apodizing filter according to the Wolfson white paper, is one where the filter fully attenuates by Fs/2 (the Nyquist frequency) and thus they start attenuating earlier than Fs/2 often sacrificing flat requency response to 20KHz.

Filter #4 appears to combine the best qualities of these filters. "Minimum phase apodizing" signifies that pre-ringing is eliminiated, post-ringing reduced and aliasing distortion eliminated. As the Wolfson white paper indicates, no one filter is the perfect filter but a designer hopes to makes the best trade offs by using multiple filters.

Conceptually Filter #4, minimum phase apodizing filter, is what Meridian is using in their latest CD player. Obviously the implementation is different and the relative quality of these filters have not been evaluated.

Get started with just a few bucks

2009-05-09T15:21:00.000-07:00

Great Deal on Arduino compatible Seeeduino. $16 from NKC electronics. Although using the "old" Atmel 168, there is plenty of room for all the code to control the OPUS DAC and more.

I wish I was associated with NKC :-)

Almost There...

2009-05-09T13:26:00.000-07:00

With a little polish and oil, the richess of the wood delights the eye. Cast-aluminum parts of old HDDs add to the solidness of the case. Crowned with a polished solid aluminum knob, it begs to be caressed... :-)

Coming Along

2009-05-09T09:55:00.000-07:00

Bought a piece of African Padauk hardwood from Rockler... Enclosing Arduino in exotic hardwood improves the sound :-). Edit: it is actually "Bubinga" or African Rosewood

Improving Responsiveness of Rotary Encoder

2009-05-06T08:15:00.000-07:00

The rotary encoder was behaving a little flaky. After doing some research I found that this is a common complaint. All mechanical encoders do have noise in their transitions. Since I was using an interrupt routine to detect motion and direction, I was experiencing multiple interrupts within one transition. After some experimentation, I figured I was sometimes getting 3 interrupts within one transition, so that the volume was increased, decreased and increased resulting in no change.

One solution was to write "debouncing" software to ignore spurious transitions. However the software solutions and code examples I found were a little too complicated to my liking and understanding. Adding simple delays in the software in the hope of ignoring the spurious transitions did not solve the problem, and in fact adding too much delay in the hope of masking the spurious interrupts caused the rotary encoder to be somewhat irresponsive.

After some research in the web, I decided then to add capacitors between the A, B terminals and Gnd. At first adding .1 uF did not seem to solve the problem, but it appeared that there was some small improvements. But adding an additional .01 uF solved the problem. I can't explain why adding a smaller value capacitor would solve the problem, since it is expected that larger values are better at smoothing the transitions. But it worked.

The 103 capacitors are .01 uF. The blue capacitors are 104 (.1 uF). They are installed between terminals A-GND and B-GND.

Two Modules Together

2009-05-02T12:28:00.000-07:00

I salvaged (from ethernet routers) some surface mount LEDs for the Tx/Rx. Yellow and Green. The Freeduino board does not have the automatic power selector, I replaced the jumpers with a switch. In order to reuse the traces in the red board, I've had to reroute certain signals and cut a couple of traces.

Completed and Tested

2009-05-02T12:03:00.000-07:00

The "shield" handles the external 8V power and routes it to the Vin pin to feed the Freeduino. The small green PC board is the 3.3V level shifter for I2C. The pins in the back are 3 sets of power pins (5V). The diode/resistor is for the 8V line. The blue capacitor is for the 3.3V supply for the 3.3V levels in the level shifter. The small blue cap is for noise bypass for the 8V line.

Building a Freeduino

2009-04-29T08:27:00.000-07:00

I'm builing a Freeduino but making some modifications. The red shield will be permanently placed in a box and will have all the connections to the LCD, the DAC, the rotary encoder, etc. It will also get the DC power and male headers facing up.

I'm building the Freeduino with the female headers facing down so that I can plug it into the shield and take it off to program. I've changed the capacitors for "audiophile" components just for fun :-), and added a switch to select the power (USB or External). The red shield is an old Arduino design and it lacks the 3.3V pin (which is needed for the 3.3 I2C). I would recommend a Freeduino bare-board instead. But it was an easy fix. (just drilling a couple of holes)

Here is a picture of the two modules stacked.

Wolfson Parts are NOT 5V Tolerant

2009-04-27T14:40:00.000-07:00

Got a response from Woflson and they said that the DAC is NOT 5V tolerant. Thus you must implement the level shifter solution.

Remote is pretty Cool

2009-04-25T22:51:00.000-07:00

Having been without a remote for quite a while (DIY audio equipment), it is pretty nice to have remote... I've integrated the remote code and have enabled remote volume and remote filter selection. The remote change is pretty fast, so there is no need for a 10x volume change speed as it is plenty fast already. The filter selection is by pressing a number. I've also posted the code.

Implemented 5V to 3.3V I2C level Shifting

2009-04-25T00:16:00.000-07:00

Implemented the circuit with the two MOSFETs (page 10 of this application note). The opto isolator has to be ordered from Digikey and that will take a while. I couldn't find MOSfets at the local electronic shop so I cut a piece out of a junk board, removed all the components around the transistors and rewired it (so ignore the white drawing in the board). The MOSfets threshold voltage are nominal 2V which is on the high side of the specified components, but it works. The 5V side measures at 5V and the 3.3V side measures 3.3V.

The 5V i2c connects to the LCD and the 3.3v connects to the DAC. Now I have piece of mind. The pull-up resistors for the 5V side are back to 5V. Thanks to PJotr who alerted me.

Best Solution for Level Shifting

2009-04-24T10:41:00.000-07:00

It seems that the best solution to level shift the i2c lines, especially for high-end audio, is the optoisolator I was reading about. Not only enables the 5v-3.3v level shifting, but provides noise isolation preventing any potential high frequency noise from entering the DAC through the wires. This is what the data sheet shows. Vdd1 would be 5V and Vdd2 3.3V.

5V to 3.3V

2009-04-24T00:02:00.000-07:00

I've made the change from 5V to 3.3V as shown in the picture. A reader alerted me to this oversight. However, it is not that simple. Discussion here. The internal pull-up resistors are enabled by default. Thus when i measure the I2C pins, they still measure 4.5v. A simple solution is to add a resistor (1K) between the 5V and the 3.3V lines

The correct way to support both 3.3v devices and 5v devices is specified in this document as follows:

"The simple addition of two low-cost transistors, placed between the different voltage level sections of the I²C-bus, separates and transfers the logic voltage levels of the bus lines on either side of the level-shifter." More info in this application note, and here.

Yet another solution is to use bus buffer as specified in the application note:

WARNING! WARNING!

2009-04-23T22:30:00.000-07:00

I've been using 5V I2C into OPUS which is a 3.3V device. So far it has worked, but I am going to find out from Wolfson if the device is 5V tolerant. However, I think it is safer to use the pull-up resistors referenced to 3.3V instead of the 5V. The 3.3V reference in Arduino can supply 50 mA. I'm going to check if this is sufficient.

Update: I've attempted to make the change to 3.3V (by changing the position of the pull-up resistors) and although everything works as before it is not yet the right solution because Arduino enables the pull up resistors internally. See post on final solution.

Modified IR receiver

2009-04-22T23:32:00.000-07:00

I removed the resistor from the output pin of the IR receiver to the Arduino input pin. After reading some data sheets, what is recommended is a pull-up resistor to VDD. Since Arduino pins have built-in pull-up resistors, I enabled it in software.

Got the IR software to work, finally

2009-04-22T23:03:00.000-07:00

The IR remote code I got from the Arduino forums worked great as a standalone application, but not too well with other applications sharing the main loop. After some modifications, I finally got it to work. I posted it in its original thread (see the post below). Now I am ready to integrate it with the rest of my code. Plan to implement the following remote functions:

1X volume control
10X volume control (the remote has lots of keys)
"dim"/"undim" (mute)
Direct filter selection (select 1, 2, 3, 4, 5)

Adding Remote Control

2009-04-19T22:33:00.000-07:00

Here is the standard 3-pin IR Receiver. right pin to 5V through a 150 ohm resistor, middle pin to GND, Capacitor between 5V and GND. And left pin to Arduino digital input through 150 ohm resistor. The first resistor and capacitor are for noise suppression. The resistor for left pin I'm not sure what it is for, but the code I used, specified it.

Update: the 150 ohm resistor on the left pin to Arduino digital input is not needed because it is a pull-up resistor and you can enable the built-in pull up resistor in Arduino. More here.

The IR receiver module I used is the Vishay TSOP348. $ 1.14 from Mouser. These modules from Seeedstudio will also work: IRL106A2B , and probably any IR receiver will work.

As it turned out, the protocol for the Sony remote is the simplest and there is code available in the Arduino forums. I used the code in this post as-is and it worked right away. I will incorporate this code into my code. There is no need for a "remote pre-processor" as I thought I needed in this post.

Adjusting LCD for optimum contrast

2009-04-18T19:07:00.000-07:00

Wrote some code to use the 4-button switch I made to go through the full range of brightness and contrast for the LCD. I found that optimum setting is Brightness: 200-250 and Contrast=45. Code in the sidebar

Rotary Encoder with Knob

2009-04-17T22:44:00.000-07:00

For audio, it is more natural to use a knob. Replaced the mouse click wheel for a potentiometer type rotary encoder and added a nice metal knob. The rotary encoder I used is the cheapy $.99 one from Electronic Goldmine.

It even has a momentary switch when you push it (to which I will wire the volume "dim" function). This particular encoder does 30 clicks per revolution (in my application that's 30 dB). Same wiring as the click wheel (center tab to Gnd, A tab to Arduino digital pin 2 -interrupt 0- and B to pin 4 (can be any other pin). Code is v 0.4

Mouse Click Wheel Implemented

2009-04-15T23:16:00.000-07:00

Rotary encoder controls volume. Can change volume with with any speed and precision. With the button switch, the control is more limited. Earlier I though it would be good to utilize a hardware decoder, but the is very simple: An interrupt routine detects the motion and updates a variable. Inside a loop, the volume is adjusted every time the variable is set. At first I put the code to change the volume inside the interrupt service routine, but inside the routine interrupts are disabled and therefore I2C does not work. So the code to update the DAC registers has to be outside of the interrupt routine.

Experimenting with rotary encoders

2009-04-15T13:26:00.000-07:00

Here is a click wheel from an old MS mouse. It is a mechanical quadrature encoder and therefore requires no power. Now that I've done more reading up on Arduino, you can make this work with one single interrupt. I tried it and it works well counting "up" clicks and "down" clicks. I'm going to use it to control volume.

Latest Display

2009-04-12T00:14:00.000-07:00

In real life, the text is whiter/brighter.
S Rate: not yet functional, but the register in the spdif input chip can be read
Source: the DAC can switch between PCM and DSD
"DIM" is functional.
Code is v 0.3

Volume Tweaking...& "DIM"

2009-04-11T19:43:00.000-07:00

At first, I programmed the minimum volume to be -63 dB. Mainly because I wanted to use a byte instead of an int and thus save precious memory space in the Atmel 168 (The DAC adjusts volume in 0.25 db increments, so 63x4=252 is the largest number a byte can hold). It turns out -63 dB is plenty loud with the DAC connected directly to the amplifier. So in this iteration:

Increased control range from -99 dB to 0 dB
Added a "DIM" control. This is like mute but it goes to -80 dB instead of total mute, and when you "undim", it goes back the the original volume. You can "undim with the same dim button and also with the volume control buttons
The 4 buttons are now functional: right for "DIM", left for Filter, top for up volume and bottom for down volume. Sort of intuitive

DAC Volume Control is Working

2009-04-07T22:45:00.000-07:00

Got the volume control working. I'm currently using two button switches to adjust the volume in the DAC. I've programmed it to go from -63 dB to 0 dB in 1 dB increment. You can find the code in the sidebar. The little module I made has 4 buttons. Two of them have not been enabled.

ATMega I/O pull up resistor

2009-04-06T12:04:00.000-07:00

Here is a diagram from the spec describing the circuit configuration for each I/O pin.

According to the spec, all ports have individually selectable pull-up resistors with a supply-voltage invariant resistance of 20K-50K ohm. In addition, all ports have protection diodes to both VCC and GND.

The pull up resistor can be enabled by software with the following code:

pinMode(pin, INPUT);     // set pin to input
digitalWrite(pin, HIGH); // turn on pullup resistors

This means when the pin is configured as input:

No need for external pull up/down resistors
Value of pin when nothing is connected is "pulled-up": HIGH (1)

Note: (From the Arduino reference documentation)

"Consequently a pin that is configured to have pullup resistors turned on when the pin is an INPUT, will have the pin configured as HIGH if the pin is then swtiched to an OUTPUT with pinMode(). This works in the other direction as well, and an output pin that is left in a HIGH state will have the pullup resistors set if switched to an input with pinMode()"

"The analog pins also have pullup resistors, which work identically to pullup resistors on the digital pins. They are enabled by issuing a command such a:"

digitalWrite(14, HIGH);  // set pullup on analog pin 0

CODE v 0.1

2009-04-05T23:18:00.000-07:00

You can find the code for the project here: link

Hook up Details

2009-04-05T19:24:00.000-07:00

The PS of the DAC (7.5V -mistakenly labeled 6.5V) provides the power to the Microcontroler. The Local regulator of Arduino provides 5V to the microcontroller and the LCD.
Two I2C (2-cable) connections: one to the LCD and one to the DAC.
NOTE: I've made changes to the pull-up resistors for the I2C lines because the OPUS is a 3.3V device. See this post.
One button switch that when pressed provides 5V to pin 2 of Arduino. Pressing this switch changes the Digital filter.

Success!

2009-04-05T00:51:00.000-07:00

Was able to control the DAC with ARDUINO. Here are the switch settings for S/W control (and the switch settings for H/W control on the right).

Spent hours debugging the code and programming most of the registers. It turned out that I was trying to be too smart and added the write bit to the DAC 7-bit DAC address. Only after re-reading the Arduino Wire Library did I realize that wire.begingTransmission() only needs the 7-bit address.

Note: the I2S switch sets the address of the DAC (for I2C communication purposes). The WM8741 can have one of two addresses:

0011010 (or 0x1A) I2S switch=0
0011011 (or 0x1B) I2S switch=1

In my case I set the switch=1 because that is the address I use in my code (0x1B)

Here is some info from the WM8741 datasheet (page 5):

I2S: in 2-wire s/w mode (using I2C protocol), this sets the address of the device. I would assume setting it low gives one address and setting it high gives the other address
DIFFHW: 0= normal; 1= MONO. IMPORTANT: for s/w operation this has to be set to zero. If set to one it assumes h/w mode
With DIFFHW=0, then MODE=Z for 2-wire control (I2C protocol); MODE=1 is for 3-wire protocol. When in s/w mode, register 8 is used to set the chip in stereo or mono mode
OSR is unused
IWO is an output, so set to Z
DSD and DEEMPH must be set to Z because these become the control wires to the controller in s/w mode
MUTE: 0= Mute active; 1= Normal operation
FSEL: Unused.

So in summary:

I2S: try 0 or 1 to determine the address of the chip
DSD: Z
DEEPH: Z
MODE: Z (for I2C mode)
IWO: Z
DIFFHW: 0 (for s/w mode)
FSEL: Z
MUTE: try 1 for "Normal operation"
OSR: Z

So the only switches to adjust/try in S/W mode are I2S and MUTE

Modding the Shield

2009-04-02T22:53:00.000-07:00

Added an extra pair of pins for I2C and a reset switch. The reset switch in the Arduino is under the shield and inaccesible if you install a shield. Reset is used to restart the program. I used a PCB drill bit and a handheld Dremel to make the extra holes.

NOTE: I've had to make some changes to the pull-up resistors for the I2C lines from the 5V connection to the 3.3V connection because the OPUS is a 3.3V device. See this post.

HIFIDUINO and OPUS DAC

2009-03-31T11:07:00.000-07:00

Here is Arduino/LCD with my DAC. It is the OPUS DAC from Twistedpear Audio.

Got my ARDUINO

2009-03-31T11:06:00.000-07:00

Just received my Arduino from NKCelectronics.

Connected the I2C LCD, downloaded the 0015 IDE for WinXP, downloaded the LCD libary and tested the "Hello World" example. Incredibly easy!
The Arduino is under the green "shield" which I used to install the pull-up resistors (5 Kohm) for the I2C lines (pin 4, 5) and to facilitate connections. IMPORTANT: The picture shows the pull up resistors connected to 5V. I later realized that the OPUS is a 3.3V device. So I now have it connected to the 3.3V pin
The LCD brightness and contrast is adjusted in software. I set it for Brightness=200 and Contrast=50. In real life, it looks much better than the picture.

Opto Isolation for I2C

2009-03-30T13:00:00.000-07:00

In audio, one of the main concerns is to eliminate any source of noise. The I2C line may be a source of noise as it is connected to a micro controller, LCD and other devices such as an RF remote.

Optocouplers are a standard way to isolate circuits. With I2C, the use of optocoplers is a bit more challenging because the signals are bi-directional. One way to do it is to use an I2C bi-directional buffer and a couple of opto-isolators as shown in this image:

Recently, Analog Devices released a fully integrated solution, the ADUM1250/2250. An 8-pin/16-pin chip solution with transformer-based isolation:

The technology is called "iCoupler Technology" and claims to be superior to pure optical or pure transformer isolation. The following diagram gives an idea on the technology:

I2C in Arduino

2009-03-29T21:22:00.000-07:00

Configuring DAC for I2C Operation

2009-03-29T18:59:00.000-07:00

Diagram shows how to set the switches to software operation (in this case I2C). Also where to connect the two I2C wires: SCLK, SDIN. SADDR sets the address for the chip which can be set with the switch as follows:

I2S=0, address is oo11010
I2S=1, address is 0011011 Use this address since it is already configured this way for hardware mode

Notice that the address is only 7 bits. In I2C, the address byte is 7 bits followed by the read(=1)/write(=0) bit. In our case, we want to write, so we use 00110110

Next notice that to switch from H/W mode to S/W mode (I2C mode) you only need to move the mode switch from "0" to "z" and we are done

The DAC

2009-03-29T17:26:00.000-07:00

This is the DAC I intend to control with Arduino. It is TwistedPearAudio's implementation of the Wolfson State-of-the-Art WM8741 DAC

Detail of Serial/I2C Interface Board

2009-03-27T20:26:00.000-07:00

Remove the Jumper for I2C
Also use 4.7K resistors as pull up resistors to 5V for the I2C lines (connect a 4.7K resistor between analog 4 and 5V and analog 5 and 5V). Here is why: http://errantengineer.blogspot.com/2007/07/pullup-resistors-how-and-why.html

Got the 4x20 LCE

2009-03-27T20:18:00.000-07:00

This is backside of the LCD. Note the Serial/I2C interface board

Bought the DUEMILANOVE

2009-03-27T12:32:00.000-07:00

It was on sale at NKCElectronics. The Arduino Mega was also released and it has 6 external interrupt pins, but it cost almost 3X what I paid. I guess I'll live with 2 interrupt lines for now.

How to Read Rotary Encoders (II)

2009-03-26T23:11:00.000-07:00

Since the Arduino only has two interrupt lines, we want to save one interrupt line for other applications and use one line to read the Rotary Encoder.

There are two ways of doing so:

The Easy Way
Connect the rotary encoder to the I/O expander, read the value of the A and B pins off the I/O expander and do the "XOR shortcut" with the previous state. See this article.

The Even Easier Way
Purchase the LS7184 integrated circuit (About $3.00 from www.geminielec.com) and connect the rotary encoder to it. The chip will output the clicks and the direction. This will make programming even easier.

Update (May, 2011): These posts were done when I was learning how to use Arduino. Latest implementation can be found here: link1, link2, link3

I/O Expander (Interrupt Saver)

2009-03-26T19:02:00.000-07:00

If you run out of I/O in your Arduino, you can use this chip. It is accesses through I2C, and it costs less than two bucks.

It provides and additional 8 I/O pins.

But what is interesting is that you can use it to control one or more rotary encoders and only utilize one interrupt line in the Arduino (remember that the current Arduino only has 2 external -easy to use- interrupt lines). I learned a lot from this article. However, there is an easier way to detect the rotation direction of the encoder, and that is the "XOR" shortcut as described in this article.

A Keypad for Input

2009-03-25T17:48:00.000-07:00

I think I am going to use a keyboard to get started. It will be useful for:

Selecting the different filters in the DAC
Adjusting the digital volume in the DAC
Selecting between PCM and DSD in the DAC
Mute/unmute

A rotary encoder is a cool feature because it allows the use of a knob and a knob is a big part of audio :-)

I found this keyboard in ebay, which is perfect for my serial LCD which also has input for a 4x4 matrix keypad