Orange Pi One & Lite as music streamers (Part 1)

Meet the Orange Pi One:



and its brother, the Orange Pi Lite:


They are single board computers (SBCs) much like the Raspberry Pi, but they will set you back just over 10€ plus shipping. That is just insane value.

They offer a quad core ARM Cortex A7 processor running at 1.2GHz, 512MBs of DDR3 RAM, an Ethernet port (One) or WiFi (Lite), a couple of USB ports, an HDMI port, etc.
They run Linux (of course..) or Android.

I came across them (the One actually) while watching Dave Jones’ channel on youtube and thought I would give it a try.

I needed an inexpensive way to listen to internet radio while I was in my kitchen. I already had a low end system set up, consisting of a couple of bookshelf speakers, a power amp and a Squeezebox Classic, but I had to move the Squeezebox to another room so I needed something to take its place. The Orange Pi One plus an inexpensive I2S DAC would fit the bill very nicely.

The idea was to load a stable Linux distribution onto the One and set-up MPD to work with my el-cheapo I2S DAC.

The steps that I am about to describe took me about a day to figure out and needless to say, I learned a lot in the process.

Let’s start with the basics.

You will need an Orange Pi board, a proper power supply (USB power will not work – I suggest that you buy a bundle of Orange Pi + Power Supply from aliexpress), a 4GB (or bigger) Micro SD card and an I2S compatible DAC that does not require a MCLK signal (like an ES9023-based one with an on-board oscillator). For the initial setup you will also need a monitor with an HDMI (or DVI with an adapter) input plus a USB keyboard. If you are a bit more hardcore, instead of using a monitor & keyboard, you can just use the Pi’s serial port with a serial to USB module and putty.

The first step is getting our hands on a Linux distribution that will be a good fit to our application. You might notice that there exist a number of official One distributions: The Lite is not so lucky.

The general consensus is that most of them have issues. The best choice appears to be the Armbian distribution:

For the One:
For the Lite:

Armbian is based on Debian and is very similar to Raspbian (also based on Debian), so if you’ve used Raspbian on a Raspberry Pi you will feel right at home.

For our application we are going to go with the Jessie Server image. We need to put this image file on a Micro SD card. I use Rufus.

We insert the SD card in the Orange Pi, we connect our monitor, keyboard, ethernet and power the thing up.

After about 15-20 seconds, the green power-on LED will start flashing and soon after you will see the initial login screen:


The default credentials are root/1234.

You need to change the default password to one of your liking. Following that, your Pi will request that you create a new user account:


Once you’ve done that, you will be asked whether you would like to change your Pi’s resolution to match your screen’s:


In my case, my lab’s monitor has a 1920×1200 resolution, so I chose to go with the highest supported resolution, so I typed:

h3disp -m 10

One reboot to go and we will be done with the initial setup.

At this point I should point out that I routinely log in to my Orange Pis as root. I can see some of you cringing but I don’t care. Security is way low on my list of concerns when it comes to my SBCs that I use for music playback. If you use a normal user (and not root) on your SBC, all you have to do is prefix the commands that I use with the command “sudo”.

So now, if you have a Pi One and it is connected to your network, it should have acquired an IP from your DHCP server. If you have a Pi Lite, you will need to do some extra work to get it to connect to your WiFi network.

To configure the Lite’s WiFi adapter you need to edit the interfaces file:

nano /etc/network/interfaces

If you would like your Pi to get an IP automatically from a DHCP server, you do this:

# Wireless adapter #1
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

If you are the more traditional type and you would like to go for a static IP, you put in:

# Wireless adapter #1
allow-hotplug wlan0
iface wlan0 inet static
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

replacing the above IPs with ones suitable to your environment.

You might notice that in both cases we are mentioning a supplicant.conf file. This file does not exist yet, so we have to create it:

nano /etc/wpa_supplicant/wpa_supplicant.conf

and then type in:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev


Again, replace your_ssid and your_password with your actual SSID and password. Note that it doesn’t matter if you are using WPA or WPA2, the script is the same.

When you are done, save the file (Ctrl-X and then Yes a couple of times) and reboot your Lite.

When the system comes back up log in and check if you are connected to your access point by typing:

ip a

You should see something like this:

1: lo:  mtu 16436 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tunl0:  mtu 1480 qdisc noop state DOWN group default
    link/ipip brd
3: wlan0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:e0:4c:99:f8:3b brd ff:ff:ff:ff:ff:ff
    inet brd scope global wlan0
    inet6 fe80::2e0:4cff:fe99:f83b/64 scope link
       valid_lft forever preferred_lft forever

You should see that your wlan0 interface now has an IP.

Congrats, your Lite now has network access. This means that you can put away the monitor & keyboard that you used to configure your Lite and continue on your desktop / laptop by logging in through SSH (using Putty or any other SSH compatible terminal program).

Logging in from Putty, we come to this prompt:


Next, we have to do a full update & upgrade of our installed packages:

apt-get update
apt-get upgrade

The update part should go pretty fast, but the upgrade part will take some time, depending largely on your SD card’s performance.

This concludes Part 1 (a.k.a. “the boring part”). Part 2 will include enabling the Orange Pi’s I2S output and setting up MPD.

Kali FIFO Buffer & Reclocker for SBCs


Back in August an interesting thread was started on

It described a FIFO buffer and reclocker, aimed at SBCs and more specifically the RPi.

Its name was Kali.

The FIFO board would be able to “fix up” the RPi’s problematic I2S output so as to improve the sound quality of the used DAC.

As the discussion progressed, more interesting details came to light.

Kali was basically an FPGA design with on-board RAM, high quality clocks and flip-flops. It would buffer the DATA stream in RAM (about 0.7 seconds of audio) and it would then reclock it using flip-flops outside of the FPGA. The clocks used for the reclocking would be high quality NDK units sporting extremely low phase noise.

It would be powered by a 5V/3A power supply and would supply filtered power to the RPi (or not, selectable by a jumper) as well to the DAC that would sit on top of Kali.

It would have a claimed 3ps of jitter, which is an impressive feat for any I2S source.

It would provide a high quality MCLK output from a U.FL jack underneath the board.

The board’s general availability was scheduled for the end of August, and its price would be in the neighbourhood of $70.

At around mid August cdsgames offered to give away a number of units to diyaudio members for testing. I took him up on his offer and he was kind enough to send me one (along with a Piano 2.1 DAC board, but that’s for another post).

Fast forward to mid-September, when I received a package from India. In it was Kali and Piano 2.1 (more about that in another post).


On the left side of the board we can see the DC IN jacks (barrel and pin header), plus a couple of inductors that help with filtering the power lines. On the top left there is a jumper that controls whether Kali will supply power to the RPi or not. The Kali lists as minimum requirement a 5V/3A power supply. However, Kali itself will consume only about 100mA. The rest of the power is intended for the RPi and the DAC board. Note that Kali is designed so that it powers the RPi and not the other way around.

In the middle of the board the two chips that dominate are the 4Mbit SRAM chip and the Lattice MachXO3L-4300 FPGA itself.

To the right we have the two NDK clocks, one for each one of the two “families” of sampling rates.


The Kali comes in two versions. One with clocks at 22/24MHz, capable of supporting sampling rates up to 192KHz, and one with 44/48MHz clocks, going up to 384KHz.
Note that there are two footprints available for the clocks so that a curious (and somewhat experienced) DIYer can also try out clocks with different footprints, like for example Crystek units. If you choose to go that way, keep in mind that you will also need to change 2 capacitors from 0.01uF to 0.1uF.

At the top of the board we have the usual 2×20 header that reproduces the RPi’s GPIO pins. There is one notable exception – Kali does not supply 3.3V at the relevant pin, so if your DAC needs to take 3.3V from that pin it will not work (more on that later).

Note that even though Kali has a JTAG header, the manufacturer currently does not support firmware upgrades. That’s understandable.. JTAG is not for consumer use and the manufacturer has to protect his IP..

At the lower end of the board we have an array of LEDs indicating the sampling rate of the incoming signal, along with the status of the buffer (Empty / Full / Lock) and the selected oscillator.


At the bottom of the board there is a U.FL socket that outputs Kali’s MCLK.


So, we have an RPi, we have Kali, now what we need is a DAC. Kali will put a few restrictions on your DAC choices. Your DAC will have to run as “slave” to the RPi, that is it will have to take its BCLK from the RPi and not the other way around. Examples of such DACs include for example virtually all of the DACs based on ES9023 chips. DACs that are designed to run as masters (in order to battle the RPi’s legendary jitter problem), such as the Hifiberry Dac+ Pro & Digi+ will not work, at least not without some extra work.

Plus, like I mentioned earlier, Kali does not supply 3.3V on its top 40-pin header, so if your DAC requires that voltage you’ll need to find a way to supply it externally.

Straying a bit from the DAC HATs, Kali will have no problem feeding pretty much any DAC that accepts standard I2S, like for example a TPA Buffalo DAC.


As a matter of fact, in my system Kali did a remarkable job of improving my RPi’s I2S output. The difference was obvious immediately. My RPi went from being a “net streamer quality” source to giving my Amanero a run for its money. Remarkable.
I am not talking about differences in bass or treble or tonality. It is like Kali manages to extract more music content from the data files. It revealed details that were there but were not audible. The music became more “real”. Imagine going from SD TV to HDTV. And that with the same 44.1K/16bit source material.

This improvement is not apparent only on expensive gear either. My first tests were done on my workbench with my RPi feeding an $8 9023-based DAC and listening through my headphones.


Even with this setup, Kali made a significant improvement to the sound. The $8 DAC went from sounding like an $8 DAC to performing at least decently. It was an obvious improvement.

So I can not imagine a scenario in which the Kali will not make an audible improvement to the sound.

Note that the first batch of Kalis (the ones that were sent to reviewers and a small number of units that were actually sold) had a bug that caused 16bit audio to have its channels reversed (and some more weird stuff happening with their I2S output resulting in somewhat degraded sound quality), but according to all effected units have been exchanged with fixed ones plus the ones that are shipping now to customers come with a fixed version of the firmware.

Even if for some reason you come by an affected unit, all you have to do is tell your RPi to output 32bit audio. That will fix everything.

I’d like to thank Ioan (cdsgames at for sending me the remarkable Kali. It will for sure become a permanent part of my audio chain.

At the time of this writing, Kali is being sold directly from its manufacturer’s site ( as well as from Volumio’s online shop.

uRADMonitor KIT1

About a year and a half back, while watching a mailbag clip from EEVblog, I learned about the uRADMonitor project by Radu Motisan.

The idea was to build a network of monitoring devices all around the globe that would measure radiation levels and display the results on a global map.

I noticed that there existed no data for Greece, so I thought I would fill that gap in the map. I enquired about a uRAD measuring unit but realized that it was kind of pricey (~$200 for a finished unit) so decided to wait for the Indiegogo campaign that had already been announced.

The campaign ran successfully, so I ended up owning a uRADMonitor KIT1. These are the contents of the kit:


The smaller components come nicely sorted and taped to a piece of paper:


The PCB itself is of typical quality:


You might notice that there is no silkscreen detailing the names of the components. I hope Radu changes that in future revisions of the KIT1.. It would make building the kit a lot easier.

The kit comes with a pretty nice manual. In the manual among other useful info you can find a parts placement diagram:


..and a BoM:


You will notice that I have added a couple of transistors to the bottom of the BoM. They appear to have been left out of the BoM by accident. No biggie.

To actually build the kit one has to correlate info from the parts placement diagram and the BoM. It’s not really difficult to do, but it might trouble a novice in electronics.

We start by soldering on the lowest-profile components. That means the resistors, the diodes, the inductors, the ceramic capacitors, the IC’s socket, the crystal and the push-button.
We continue with the transistors and the voltage regulator IC. Take care to follow the instructions here – R7 should be left open (no component) and R13 should be shorted.
Next up is the on/off switch and the terminals that will hold the Geiger tube.
We then move on to the piezo speaker (be careful, it is polarized!), the pin headers for the display and the ethernet board and the power input jack. Regarding the ethernet board, you will need to take care to mount it properly on the first try because it will be soldered in place. You are supposed to mount it in such a height and angle so that it is perpendicular to the main board:


You can power the board with the supplied power supply or any 5VDC power supply. The power switch turns on when it is toggled towards the Geiger tube:


The Atmega328 that comes in the kit is already pre-programmed with a unique identifier for your unit so all you have to do is connect the kit to your router with an ethernet cable and it should get an IP from your DHCP server. Once that is done, it will automatically appear on


Here is my unit powering up:

uRADMonitor may have begun with measuring radiation levels but it is evolving into a more diverse platform, measuring several other pollution factors. I’ll be happy to incorporate more sensors into my KIT1 in due time.

Dimdim vs. The Ball Screw

I know what you’re thinking. What the heck is a ball screw and what am I doing with one.

This is a ball screw, complete with ball nut and supports:


What a ball screw does is convert rotational motion (like from a motor) to linear motion (movement, like front-to-back). Looking at the picture above it is pretty simple to see how that works.

The ball nut contains a number of ball bearings that are used to minimize friction and pretty much eliminate “backlash” (slop).

The screw rotates, but the nut is bolted on to some other surface so it can not turn. Instead it “travels” along the length of the ball screw.

I know that so far I haven’t really given you much useful info, at least nothing that you can’t find on Wikipedia, but bear with me.

Ball screws can get very expensive, if you buy them from the local market, so I opted for a Chinese one off of Ebay. The upside is the cost – the downside is the varying build quality. This particular ball screw had one issue: One of its ends was a very tight fit into the support’s bearing and when I say very tight I mean that I actually had to hammer it in. I know, not the best thing to do to a precision mechanical part, but that is what I had to do. Problem is, the next day I realized that I had forgotten to put in my nut housing. As Murphy would dictate, to put it in I would have to disassemble the tight side of the support. After some swearing and kicking of things, I began to examine my options. I could hammer the ball screw out of its support but I didn’t feel like putting the bearings through yet another ordeal. My other option was to unscrew the ball nut, put in the nut housing and then screw the ball nut back on. Sounds simple, right? Wrong! The problem is the bearings inside the ball nut. These bearings have no support. There is nothing keeping them from dropping out of the ball nut once I have taken it off the ball screw. Knowing that, I looked for a way to put the thing back together properly. Sure enough, I came across this video:

Everything shown on this video is spot-on. You should definitely count your balls and split them into groups of equal number of balls. Getting the first set of balls in is pretty easy. The problems start once you have completed the first set. Now you have a somewhat functioning ball nut. It will rotate with one set of balls, but you need to put in the other sets too.

2016-03-23 19.33.39

When you try putting in the second set of balls, you will realize that you can not. The machined end of the ball screw is blocking the way. You need another strategy.

I looked far and wide for a solution (ok, I Googled it for like 10 minutes). What you need is a tube that has the proper outside diameter to keep the balls supported inside the ball nut, but also has a proper inside diameter to allow the ball screw’s end to go through it so that it can enter the ball nut.

Some people went as far as machining new parts to aid in this procedure. I did not have that luxury, so I looked around the house for a proper tube. I came close with an old flashlight, but its diameter proved to be slightly too big. By that time I was beginning to regret ever having unscrewed the ball nut, but then it hit me: All I had to do is wrap some paper a few times around the shaft and use some tape to make a custom tube.


I then inserted my tube into the ball nut and proceeded to feed the balls. I did the first set, then the second, and then the third. I had to be careful since the tube was flexing a bit. Still, I got it right on the first try.

2016-03-23 22.30.50

Then I took the ball screw and inserted it into the ball nut with my tube still in it. I began screwing in the ball nut, until the tube came out the other side.

2016-03-23 22.31.53

That was it! My ball screw was as good as new!

So, to summarize, if you have to take a ball nut off a ball screw, prepare yourself for some tedious work putting it back on. Do make a paper tubing. Learn from my experience.

Fixing startup issues with Arduino DUEs

If you’ve had a lot of Arduino DUEs go through your hands (or if you are just unlucky), chances are you’ve come across at least one that does not start-up properly.

The symptom is simple: you power up the Arduino but it doesn’t appear to “boot”. Your code simply doesn’t start running.

You might have noticed that resetting the board (by pressing the reset button) causes the board to start-up normally.

I had come across such a board a while back, and had thought to myself “cheap generic, probably faulty” and had just put it aside. At ~13€ it was no big loss.

A few days ago a fellow tinkerer (thank you Alex!) alerted me to a fix for this problem.

It appears that the problem was first spotted on Freetronics’ forum and was dealt with swiftly.

The problem occurs only on some DUE boards and is due to some undocumented behaviour of the ATSAM3X8E processor combined with the behaviour of some MOSFETS installed on the DUE boards. So its occurence is largely a matter of luck.

The fix is simple: you just solder a 10K resistor across the top of this mosfet:


This is a 10K 0805 resistor that is about to be soldered:


..and after soldering:


The discovery of the problem prompted a new revision of the reference design by the Arduino team.

This is what the Rev 2’s relevant part of the schematic looks like:


and the PCB:


And this is what Rev 3 looks like:



You will notice a new component, R99, plus the mosfet is now mounted vertically.

So, if you are shopping for a DUE, look for one with this mosfet mounted vertically, just to be on the safe side.

Universal Signal Isolator Shield: Rev. 1.2

Since there has been a lot of interest in my Isolator shield these past few months, I have been optimizing its design.

The result of this optimization is this PCB:
It’s called “the Rev. 1.2”.

Nothing major has changed. The pinouts are still the same, the major components are the same, the functionality is essentially the same.

The changes are as follows:

  • New SPI header. It just passes through the SPI signals, nothing more. It does not connect to anything on the board.
  • New SPI_CS header. Useful only if / when connecting SPI peripherals.
  • Reset button. Because you never know..
  • New circuitry for the POWER_RELAY header. It now uses a MOSFET and it includes a diode for the reverse current coming back from the relay’s coil.
  • Decoupling cap for the IR receiver. Not absolutely necessary, but good to have.
  • More decoupling for the DC_UNR input.
  • Ground planes. Lower Arduino noise, at least in theory.

Here is the updated parts placement:

And this is the updated BoM:

USI Bill of Materials, Rev. 1.2
PCB Part Value Notes
U1 24LC256 SO-08 EEPROM chip
U2 Si8605 SOIC-16 I2C Isolator
U3 MCP23008 SO-18W 8 input/output port expander
U4 Si8642 QSOP-16 Serial port isolator
U5 ADUM1250 SOIC-8 I2C Isolator
Q1 BC856, BC808 or other equivalent PNP SOT-23 TFT backlight control
Q2 BC856, BC808 or other equivalent PNP SOT-23 port expander transistor
Q3 BC856, BC808 or other equivalent PNP SOT-23 port expander transistor
Q4 BC856, BC808 or other equivalent PNP SOT-23 port expander transistor
Q5 AO3400 or other equivalent N-Channel MOSFET SOT-23 power relay mosfet
B1 Bridge rectifier 1A DB107 DIP-4
C1 1000uF 16V
C2 100n 1206
C3 100n 1206
C4 100n 1206
C5 100n 1206
C6 100n 1206
C7 100n 1206
C8 100n 0805
C9 100n 0805
C10 100n 1206
C11 100n 1206
R1 8.2K 1206
R2 2K 1206 pull-up resistor (optional)
R3 2K 1206 pull-up resistor (optional)
R4 5.1K 1206
R5 5.1K 1206
R6 5.1K 1206
R7 2K 0805 pull-up resistor (optional)
R8 2K 0805 pull-up resistor (optional)
R9 8.2K 1206
R10 10K 1206
D1 1N9001 DO214BA
L1 Ferrite Bead, low DC resistance, 3216
L2 Ferrite Bead, low DC resistance, 3216
Reset PCB-mount momentary switch

Soon I will update the shield’s page with the new info.

Driving the Fostex T50RP MK3 headphones

After too many years of abstinence from headphones, I was given as a present a pair of Fostex T50RP MK3s.

These headphones have an excellent VFM, having true planar magnetic drivers at a price point of ~150€.

This is what they look like on the inside:

Fostex inside (Medium)

Picture borrowed from here:

There is a drawback though, and that is their low sensitivity. ~92dbs mean that my current cell phone has no hope of making them rock. No chance at all. Same goes for pretty much any USB-powered DAC/headphone amp. So anyone serious about driving these headphones needs to look into a proper headphone amplifier.

I said to myself that I should try to build a proper amp with parts that I already had lying around, so I looked at my stockpile. I realized that I had a brand new pair of AMB alpha20 class-a line amplifiers, rated at 3.0Wrms into 33Ω with a ±18VDC power supply.

AMB alpha20

The T50RP are 50Ω and can handle up to 3000mW, so I thought that they would be a good match.

Powering the alphas by my bench power supply, I connected them to my audio card’s line out (an Auzen X-Meridian) and hooked up the headphones. The result was impressive. The alphas delived sound that was clear, crisp, with very little distortion. Plus they managed to achieve SPLs well into eardrum-damaging territory. Good.

Next up was the power supply. I had a set of Salas BiB shunt regulators that were collecting dust, so they would do just fine.

Salas BiB 1.1 alpha20

I set them up for a CCS current of ~300mA.

The case would be a Galaxy 1U aluminum one that I had bought for a project that never went beyond the design phase.

I was missing a transformer that would fit inside the 1U case, so I bought a 25VA unit from Mouser.

At last but not least, I needed a 1/4″ TRS jack that could be mounted on a 10mm thick aluminum face. Neutrik had the perfect part for the job:


So, all I ended up purchasing was the trafo and the 1/4″ jack. Nice.

2015-11-29 17.57.20_resize

So now I had a functioning headphone amplifier.

The next step is to add a USB to I2S interface, a DAC, some sort of volume control, another power supply to power them and an Arduino & Screen to control them. Space might be an issue..

DIYINHK XMOS Multichannel 32ch USB to/from I2S/DSD SPDIF Interface

About a month ago DIYINHK released a USB to I2S interface board based on the brand new and all-powerful XMOS xCORE-200 chip.


The specific chip used by DIYINHK is the middle-of-the-line XU216-512 which corresponds to some pretty serious horsepower: 16 logical cores for a total of 2000 MIPS, 512KB SRAM, 2MB FLASH.


So, what can we do with all this horsepower you say? It’s simple. Tons of channels of high-resolution audio. Plus I2S inputs, besides the usual outputs. Plus DSD1024. Plus use a cool OLED display as a VU meter.

The board I bought came with the default firmware, which supports:

  • 6 channel 384kHz I2S output
  • 4 channel 384kHz I2S input
  • spdif output
  • OLED VU meter
  • Volume up/down control button

Here is a video of it in action:

A maximum 32 channels can be supported with the right firmware (not provided by DIYINHK).


The board (a 4-layer design, btw) comes with three high quality NDK NZ2520SD Ultra low phase noise oscillators. There is provision for powering two of the oscillators externally, by removing a ferrite bead and applying power through one of the headers.

The board is not USB powered. It needs a relatively beefy 3.3V power supply, capable of providing a maximum of 800mA (even though a typical power consumption is in the neighborhood of 570mA). Beware, a weak power supply or an inadequate connector will cause to board to not power up.

It comes with a fully featured Thesycon driver for Windows. Linux & Mac OS don’t need a driver.

An interesting detail is that the Windows 10 driver that is available only supports stereo operation and no multichannel (v2.26). If you want multichannel you’ll have to go back to Windows 7 (v1.67) (or perhaps Linux or Mac OS, it isn’t clear..).

DIYINHK’s site says that the latest available driver is v2.26, but I did not find such a driver in their downloads section, so I emailed them about it. They sent me a link for an even newer driver, v3.20.

DIYINHK XMOS Driver 3.20 1
DIYINHK XMOS Driver 3.20 2
DIYINHK XMOS Driver 3.20 3
DIYINHK XMOS Driver 3.20 4
The board has a ton of exposed I/O, split into three 0.1″ headers. These are the pinouts, according to DIYINHK:


Now, if these pinouts look somewhat cryptic to you, you are not alone. I will try to clarify things a bit.

This is the most interesting header:

Header 1

I have marked in red the power supply input. It is a good idea to use all of the pins for making the connections, since ~800mA is nothing to sneeze at.

The pins in green are the I2S outputs. For 2 channel operation you will need to connect the DATA, BCK & LRCK pins. The rest of the output channels should be available at pins DO2, DO3 and DO4. I say “should” because I haven’t tested them. I should repeat that multichannel operation with the provided driver is only possible at the moment with Windows 7 (and possibly Linux & Mac OS).

The pins in yellow are the I2S DATA inputs. For 2 channel operation you will need to connect the DIO1, BCK & LRCK pins. The rest of the input channels should be pins DIO2, DIO3 and DIO4. The same multichannel restrictions I mentioned above apply to the I2S inputs.

The OLED screen is connected to one of the side headers, like this:

xmos-multichannel-high-quality-usb-tofrom-i2sdsd-spdif-pcb (3)


The left header is the XSYS connector for uploading firmware to the XMOS.

Next up: connecting it to my PCM4222 EVM ADC board.