Berries, Bananas, Oranges and C.H.I.P.s

I’m in the midst of finding a low-cost embedded linux platform to standardize on for IoT/network device experiments. I’ve been using Debian on Marvel Kirkwood ARM devices as inexpensive, low power servers and network appliances for a number of years now. I’ve also used OpenWRT for my home network and other network appliances.

A few years ago though, I grew tired with the difficulty of maintaining/upgrading Debian on my ARM devices and replaced them with a small AMD based x86 box for my main home server. There have still been upgrade hassles, but overall, I think it reduced the fussyness and frustration enough to be worthwhile.

At about the same time, I started growing interested in using OpenWRT more widely, and I was encouraged when the LEDE Project forked off for reasons that included a desire to fix some of the things that frustrated me about OpenWRT. I liked the simplicity vs a full linux distribution. And the minimal system requirements meant OpenWRT could run on small, inexpensive, relatively low-power devices. Last year, I started work on trying to get OpenWRT running on some cheap linux-based network music servers. Before going further, I paused to think about what’s really important.

I realized that, for my purposes the fact that OpenWRT/LEDE runs on a wide variety of compact, inexpensive devices was as much a liability as an asset. It meant more of the communities effort was invested in supporting the hardware, which meant that a lot of the supported hardware and some of the higher-level software wasn’t well supported, or supported at all. Furthermore, the constrained resources on the various hardware made it harder to compile, package, and deploy software packages that were well supported on full linux distributions. These tradeoffs between cost and ease of development/deployment might be acceptable if I was working on a high-volume device, but I’m not. I’m working on one-offs for my own projects. At most, I might make/deploy a dozen similar devices. How much hassle was I inflicting on myself in exchange for saving $20, or $200 vs an easier to use alternative?

As for the alternative, figuring that out is really the point of this post. As I see it, there are three major options.

  • RaspberryPi
  • Chinese ARM (Allwinner, Rockchip, Amlogic, etc)
  • NextThing

And my current impressions on each option:


Anyone who has read this far is probably well aware of the success of the RaspberryPi and its offspring, like the RPi Zero and RaspberryPi v3. Community support is surely the strongest out of any of the inexpensive ARM boards. Unfortunately, I don’t find the boards a great fit for most of my projects.

The Raspberry Pi v3 is quite capable in terms of processing and video. Of those the processing power is probably the most relevant to me, but the projects that call for that also call for better network and disk IO, rather than the shared USB2 on the v3. Also, at $35-40 it’s more expensive than I’d like. It’s a bit on the large size too, and power consumption can be a bit high.

The RPi Zero is cheap ~$5 but availability has been poor, and it still seems hard to get. It’s small, and power consumption is better than the v3. Unfortunately, the Zero seems targeted at people who want to do more hardware hacking than I do. IO is minimal. There is no network, and no included support for USB peripherals (it can be a USB peripheral though).

It’s been almost a year since these two devices were released, so there is a good chance we’ll be seeing upgrades soon. Still, I’m not holding my breath.

Chinese ARM Boards ( with SoCs from Allwinner, Rockchip, etc ).

If I remember right, ARM SoCs from Allwinner and Rockchip first appeared at about the same time as the first RaspberryPi, in android TV boxes and sticks. The first developer board I remember was the Allwinner-based Cubieboard. Since then, there have been many variants from a half-dozen board designers like FriendlyARM, (SinoVOIP) Bannana Pi, (Xunlong) Orange Pi.

Unfortunately Allwinner, and most/all of the other SoC makers aren’t great about providing documentation or source code for their linux variants, and the board makers don’t/can’t exert much leverage. Allwinner chips seem to have a decent community around them, but there are so many SoC variants and board variants that a lot of effort is burned trying to keep up with them. The linux-sunixi (Allwinner) community is making a concerted effort at getting support into the mainline linux kernel, which should both make ongoing support easier and broaden the base of potential contributors.

Next Thing C.H.I.P.

Next Thing grabbed a lot of attention in late 2015 for their promise of a $9 computer called the C.H.I.P. After some challenges, they delivered on their Kickstarter and went on to produce more of the boards, as well as the PocketCHIP and upcoming CHIP Pro.

The C.H.I.P. includes 4GB of fast onboard flash, 2.4GHz 802.11n WiFi, Bluetooth 4.0,  512MB RAM and multi-format video out (built-in composite, or VGA & HDMI with adapters).

NextThing used yet another Allwinner ARM SoC (R8), and by that criteria, belong in the previous category. What sets them apart from other people spinning boards with cheap ARM SoCs is that they have invested time and money into software and documentation — including a full datasheet for the GR8 (R8 + 256MG RAM in package) used on their C.H.I.P. Pro.

They are currently out of stock on the CHIP and all they can say about backorders is that they are expected to ship in Q1 2017.


I already have an RPi v3, which I’ll find some semi-permenant use for. the C.H.I.P. is attractive because of it’s manufacturer support, despite being out of stock, and having an older Cortex-A8 CPU core. I’m not in a huge hurry, so I think I’ll order a couple now and hope they arrive before I wish they were here sooner.

I’m also tempted to buy an Orange Pi Zero, or one of the FriendlyARM NanoPi variants, for comparison.

The Conduit Amplifier r2

I made a major revision to my Conduit amp in order to free some internal space to ease cabling.IMG_8270

The original version used pin-headers on the mono TPA3110 amplifier modules to connect them to a perfboard motherboard. Connectors for power input and speaker output terminals were on the motherbnoard. The new version uses smaller screw terminals, and moves the speaker output terminals to the amp modules, which are held in place by sandoffs. Pin headers are still used for audio inputs to the modules, and power is still connected to the motherboard, and then supplied to screw terminals on the modules via 18 gauge silicone wire. I also managed a more compact layout for the volume control daughter board.


The new version also included improved fit-and-finish to the volume control. I used some aluminum rod and brass tubing to make an extension. This now passes through a drilled-out aluminum plug before being connected to the knob. I’d originally intended to fit a bearing in the plug to support the shaft, but I don’t have one in the proper size (even so, after adjustment shaft alignment is better than pictured).


I also fitted the thermal pad and copper shims to thermally couple the amp modules to the aluminum case.

Unfortunately, only one channel works. I checked for continuity and power before noticing that a small SMD cap near the PTA3110 chip on the amp board got knocked loose. I’ll have to figure out its specs and try to get and fit a replacement… though it would be easier to just replace the board for $2.50.

I think its a nice improvement. I still need to get wire and connectors I’m happy with the power, speaker, and audio pigtails. Someone suggested 4-pole speakon connectors for the speakers. There is an aluminum version that might be a good match for the case, except it costs about as much as all the other parts combined. There are cheaper plastic speakon connectors that I might try. I’d also like to find a decent pot with an integrated switch I can use to switch the power.

The Conduit: A portable, Class D TPA3110 Audio Amplifier

Update: I made a major revision to The Conduit Amp with some improvements and a bit better fit and finish.

A few months ago I was at the hardware store looking for cheap enclosures for electronics projects. Some aluminum junction boxes for electrical conduit caught my eye, so I bought a couple. In parallel, I was interested in building a small, portable amp that could operate off 12v, which led me to buy some little, mono, TPA3110 modules for a few bucks each.

Surveying my box of parts a couple weeks ago, I noticed that the TPA3110 modules would fit nicely in the smaller of the two junction boxes I purchased, and I started tinkering with ways to assemble them into a finished product.


The first idea was to join the boards together with standoffs and slip them inside. I ordered some small terminal blocks for the electrical connections. When they came, though, and I tried assembling things as I planned, I realized I’d need to cut the standoffs down in order to fit a board to hold a potentiometer. I was feeling lazy, and didn’t want to deal with metal filings, so I looked for another way.

I decided to use pin-headers to mate the amp modules with small motherboard made from perfboard. For added mechanical strength, I cut the headers with more pins than needed, soldered the pin positions with through-holes on the amp board, and then glued the rest and trimmed them to the same length as the active pins.

Routing the power input and speaker outputs was kind of a nightmare. Rather than trying to plan it all out, I ended up working a couple of connections at once, trying to leave room for the other connections. It took quite a while. I was concerned about some of the routing and figured I’d probably end up doing a second version, so I soldiered on soldering my prototype.

Once I was done, I used my multimeter to check to make sure that there weren’t any short circuits on the motherboard. Fortunately, everything checked out.

Next I had to finish up the input connections and passive volume control. Rather than routing the audio input on the protoboard, I decided to take advantage of the shielding on the input to help keep the signal clean while passing the high-current power and output connections, and the inductors on the amp board. I connected it to the board with the volume-control board at the far end of the case.

After assembling the components on the volume control board I checked everything with a multimeter. Again, I was fortunate that I hadn’t ended up with any shorts. The volume control board was connected to the the “motherboard” with an excess of soldered pin headers for mechanical stability.

I covered the solder pads on the backs of the amp boards with kapton tape to keep them from shorting on the case. Then I made up a power cable and some speaker cables, screwed them in to the terminals on the motherboard and fed them out of the opening of the case.

Maneuvering the amp board into the case with all the cables attached took a bit more force than I was hoping for, a situation not helped by the fact that the position I chose for for the audio input connector interfered with part of the case casting, depriving me of a few extra mm at the opposite side of the case, and putting the volume-pot a bit off center.


In the end though, I got it to fit.

My plan is to power it off a Quick Charge 2 USB power bank set for 12v output. I have the powerbank, but I still need to make something to negotiate the 12v output, so I powered it off a 12v power brick to test it out.

It works! Even better, it sounds good! So, a second version is a luxury, rather than a necessity. At full volume, the output level with my phone as the audio source is maybe a little lower than I’d like for something intended for use outdoors. I’m not sure yet if that’s a limitation of the 12v supply voltage, or if I need to bump up the gain of the amplifier.

Now that I know it works, I still need to finish it up. I need to fit an extension to the volume potentiometer shaft and pick out a knob that looks good. I also need to put some thermal pads on the bottom of the amp modules to transfer heat to the case. Also I’ll probably find some thinner gauge speaker cable.

Parts Used

Power Rail Noise/Ripple with a Sanwu Blue TPA3118 Mono Class D Amplifier Module

I’m building a few custom audio amplifiers for my personal use out of some inexpensive modules based on the Texas Instruments TPA3118 and TPA3116 Class D amplifier chips.

Class D amplifiers are basically variable switching regulated power supplies (SMPS), which makes them compact and power efficient when compared to traditional amplifiers, which are much more like linear regulated power supplies. The switching frequencies are designed to be well outside of the range of human hearing (and the circuits and transducers we use to reproduce sound) so that it can be filtered without interfering with the audio, and so any remaining signal at switching frequencies is inaudible. In the case of the modules I’m using, the switching frequency is ~400KHz.

The modules I am using have LC (inductor + capacitor) filters on their outputs in order to filter the switching frequency before sending it to the speakers, but I was concerned that the modules would also inject noise onto the power supply rails. TI has provisions for slaving multiple chips together so that they use the same switching clock and can avoid distortion due to interactions on the power supply bus, but the modules I’m using don’t expose the necessary pins, and the small component sizes and spacing between the PCB traces didn’t make me eager to hack them.

Some people have addressed the issue by dedicating a separate power supply to each module, but all things being equal, using a single supply should be cheaper and more compact. I asked for advice on the forum, and got some general suggestions, but nothing specific enough to be actionable. I was going to need to do more of the legwork myself.

So, first step, was to see if there were any existing solutions. I started reading datasheets and application notes, but I didn’t find what I thought I needed. I did learn though that, in addition to the switching frequency, Class D amps draw current at either 1x the audio input frequencies, when configured as a half-bridge, or 2x the audio input frequency, when configured as a full bridge.

Next step was to measure magnitude of these potential PSU noise sources in a naive implementation, with no added filtering beyond the PSU’s output filters and the modules PSU input filters.

I used the 24v DC PSU I had handy, an ~10-12 year old 65W Apple 24V PSU intended for a Macintosh PowerBook. I haven’t seen a teardown of the PSU, but in general, Apple seems to put a lot of effort into making their PSUs electrically robust and low noise.

I paired this with a Sanwu “Blue” TPA3118 PBTL mono module. which has ~1320uF (2x 2x 330uF) of electrolytic decoupling caps on the power rails. I then hooked up my oscilloscope and an Analog Discovery to do the measurements.


With no signal input to the amp, this is what the power supply rail (yellow) and the amp output (blue) look like. You can see that there is a sinuous ~400KHz, 1.2v peak-to-peak signal on the output from idle switching of the output bridge. You can also see evidence of this switching on the power rail, at the same fundamental frequency, but with a lot of ringing. The 400KHz component is about 50mV peak-to-peak, while the higher-frequency ringing and transients are about 190mV p-p.

I also took measurements using my Analog Discovery as a spectrum analyzer.

Baseline 1MHz Narrower Y range (similar lashup, no AC power to PSU)

First with everything connected, but no AC power applied to the PSU.

Apple 24v Brick with resistor load

Next, with AC power, and various resistive loads. I was sloppy and didn’t record the exact condutions, but it gives some sense of what the PSU noise is and how it changes with load. Blue is with no load, magenta is with ~30 Ohms, Green is with ~15 Ohms. Also, note, this is a relatively wide spectrum range, from ~0 to 2MHz.

0-1v 100Hz in. multiple traces. 1MHz wide

With the amp as a load (driving a 7.5Ohm power resistor). There is a 100Hz input to the amp. Each trace is a spectrum measurement of the PSU with a different input amplitude, from signal-off to 1v peak-to-peak. These readings were DC coupled, so the measurement reflects the DC voltage component. As a result, the average level for each trace is closer to the baseline as the DC voltage of the PSU rails sags at higher output powers.

There are peaks at the 400KHz switching frequency, and its harmonic at 800KHz. I’m not sure I understand all the little peaks that group around on each side of the switching frequency.


In the time domain, we can see the amplifier-induced PSU ripple & noise in the yellow trace, along with the amplifier output signal from a 500mv p-p, 100Hz input signal. There is a 200Hz ripple on the power supply rail as the amplifier bridge switches on 2x for each input cycle, once to drive the output high, and then again, in reverse polarity, to drive the output low. This ripple is ~500-600mV p-p and its phase is offset a bit from the output waveform. On top of that, you can see the switching noise in the high-frequency “fuzz” on the power supply rail. This “fuzz” is about 1.3v P2P. The two components together add up to ~1.96v of swing.


Pushing the input higher quickly runs into problems. With 1v input p-p, things look rather nasty as the peaks get brutally clipped off against the limits of the PSU voltage.

I also took PSU rail frequency measurements with input signals of 50Hz and 10KHz.

40-1280Hz 300mV in

I decided to wrap things up by looking more closely at the impact on PSU voltage at different input audio frequencies. Since the human hearing falls off sharply above 20KHz, and the amp current draw varies at 2x the input frequency, I limited the top of the measurement range to 42KHz. The input signal was 300mv peak-to-peak, and the input frequency was stepped starting at 40Hz and ending at 1,280Hz.

I’m really not sure what the high-frequency peaks are starting at 18KHz or so. I probably should have looked into them more closely.

Now that I have the measurements, I have to make sure I actually understand them before I figure out what to do, and how to do it. I note that in PBTL mode, the chip has a power supply ripple rejection ratio of 75-80dB up to 1KHz, rising to ~55dB at 8KHz and continuing at that level for the rest of the audio range.


Mac OS X Kernel Panics with RTL-SDR/RTL2832U and Analog Discovery, and a Fix

Earlier this week I fired up WaveForms in order to do some spectrum analysis of power supply rails hooked up to a Class D amplifier board using my Analog Discovery. Before I got the Analog Discovery plugged in though, my computer froze, the screen went dark, and then a kernel panic error displayed.

This was new, I’ve never had a problem before, whether or not the device was hooked up before firing up the software. I tried again, this time making sure the Analog Discovery was plugged in before launching Waveforms. Another kernel panic. I tried again, this time plugging it directly into my laptop, rather than the USB3 hub I use for convenience. Another kernel panic. I muttered and cursed and speculated that the cause was the OS X 10.11.6 update I’d recently installed, and ended up using a Windows machine for the task instead.

A few days later, I received a cheap RTL2832 USB DVB receiver I’d purchased in order to (finally) experiment with Software Defined Radio (SDR) using RTL-SDR software. My first explorations were tacked from base camps on my patio and bed. Everything worked without issue. The third time though, I was at my desk, and as soon as I launched CubicSDR my computer froze, went black, and then complained of a kernel panic.

I was peeved. I thought, perhaps that my hub was an issue, so I plugged the RTL2832 in directly. It worked. I tried a different hub. It worked again. I tried something else, it crashed.

Eventually, I figured out that the problem only occurs with a USB3 to Gigabit Ethernet adapter connected (with or without a hub involved). The adapter in question is based on the RTL8153 chip, which is used in USB3 to GigE adapters sold under many different names.

This chip is complaint with standard USB Ethernet protocols, and works with generic drivers provided by Apple in OS X 10.11 (El Capitan), and perhaps earlier versions. I’d installed the Realtek provided driver in order to take advantage of some features of the chip which might improve performance and power consumption, but not to a significant degree.

By removing the Realtek RTL8153 driver using a script provided in the installer package, I was able to revert to using the generic apple USB Ethernet driver. Now, I can use my Analog Discovery with Waveforms, my RTL-SDR with CubicSDR, and my USB3 Ethernet adapter at the same time without Kernel panics.

SMSL HV-50 Amplifier, anyone?

Does anyone know anything about the SMSL HV-50 amplifier?



I’m asking, but I think I already know the answer: No, no one knows anything about the SMSL HV-50 audio amplifier, or if they do, they aren’t talking (not in english, anyway). I found a recent reddit thread asking about it, but no one knew much, and I haven’t found much else.

What I do know are some basic details:

  • 50W per channel (stereo)
  • RCA inputs
  • 5-way binding posts for outputs.
  • Based on the TDA7492 Class D Amplifier IC from ST Microelectronics.
  • Aluminum case.

The TDA7492 chip is used in a lot of compact, inexpensive audio amps made by various Chinese manufacturers and sold under various names on Amazon, Ebay, AliExpress, etc.



It is also used in the older, almost identically specced 50 Watt/channel SMSL SA-50 amplifier, pictured above. The chip and specs aren’t the only thing the two have in common. As you can see, the case is the same. The only outward difference is slightly different markings and detailing.

The insides are a different story. Both use the same TDA7492 amplifier chip, but as you can see, the PCB and components are quite different.

Last night I noticed that one seller was offering the HV-50 for just $35 with free shipping, so I ordered one. At that price, it was a no-brainer. I’d have easily spent $25 and several hours getting one of the cheap TPA3116 boards I’ve ordered mounted in a suitable case.

I’ll follow up with a new post in a few weeks, once I have the HV-50 in-hand.


AirMobi iReceiver Preliminary Software Hacking

I recently discovered and purchased an inexpensive, unofficial WiFi-enabled AirPlay and DNLA audio receiver called the AirMobi iReceiver. I couldn’t find much information on the device, but for $12, I thought it was worth buying and trying.

It works reasonably well, but that’s not really why I bought it. I bought it with the intention of taking it apart and seeing what makes it tick. And now, having done that, I plan to hack it to run OpenWRT so I can secure it, customize it, and update the software.


It is based on a Ralink RT5305T WiFi SoC which suggests to me that it is running linux, and probably has a serial console exposed via some test points on the mother board. I only found handful of candidates during my teardown. My guess was that the Tx and Rx lines were available on the unpopulated 4-pin header at the edge of the circuit board. From visual inspection I could tell that the second pin from the left was a ground pin. A little continuity probing with a multimeter suggested the first pin provided power, a fact confirmed when I check its voltage when I powered up the device.

I hooked a logic analyzer up to the other two pins to see which one toggled on and off at boot, but that was really overkill. I could have done just as well figuring out which one was pulled high when I powered up the device.

Once I had the pins worked out, I hooked up a TTL level USB/serial converter to my laptop, connected the ground pins and cross connected the Tx and Rx pins between the adapter and the board. Once I powered everything up, my screen started to fill with garbage. I guessed that 115.2Kbps was too fast, and tried 57.6Kbps instead. Bingo!

After booting up, I hit return and was presented with a login prompt. I tried the password for the webui and was pleased to find that it worked. I poked around the filesystem, looking at various config files, the various files for the web UI, and checking what binaries were installed on the system.

One of them is a telnet daemon (implemented as part of busybox). So, I started it, connected to the WiFi, and was able to log in over the network.

From there, I gathered more information. I was dissapointed that there wasn’t really anything like zip, or tar, or an ftp or ssh server that would make it easy to pull a bunch of files off at once, so I dumped the web UI files to the terminal one at a time and then saved them for further inspection.

Hidden ate_test.asp page

Hidden test_ate.asp page

Once I did, I found hidden functions in the firmware update page for uploading the bootloader over the webui. Exposing it required tweaking the page using web developer tools, which is kind of tedious. Then I hit the jackpot, I found an unlinked file called test_ate.asp. When loaded, it has a button to fire up the telnet daemon, making a command line available with just a WiFI connection, no serial console necessary. It also has an option to update the boot loader and a mysterious ATE function. This discovery made it easier to return and poke at the device at my leisure.

From what I learned in my poking and prodding, it appears to be based on the Ralink provided SDK with some modifications. With any luck, the modifications will be minor, and it will be easy to load an OpenWRT firmware over the webUI.

Before I do that though, I’ll need to take special care since this device doesn’t have an ethernet port, and so recovering from non-working firmware will be more difficult.

A lot of details follow…

Continue reading

AirMobi iReceiver Teardown

I’ve ended up with five small, inexpensive ($7-15 each) routers, running OpenWrt and only really need two of them, so I’ve been thinking of ways to use the others. One of my ideas was to get an external USB DAC, install Shairport-Sync, and use it as an AirPlay receiver for my car stereo, eliminating the need to connect an audio cable to my phone, and avoiding the mediocre sound quality of Bluetooth audio. It hasn’t quite worked out that way though…

While looking for an inexpensive (>$20), compact USB DAC with reasonable quality, I discovered there were integrated commercial products that already do what I planned to do. I already knew there were Apple-approved MFi-certified devices, but they tended to be expensive. I discovered there were cheaper devices using Shairport, but they tended to start at $30+.

Damaged while trying to open the case.

Damaged while trying to open the case.

With a little more digging though, I found a device called the iReceiver, from AirMobi that sells for as little as $12!!!. According to the scant marketing materials, it has a 24-bit Wolfson DAC. I was surprised I couldn’t find anyone who’d opened one up to see what was inside. I did find an Amazon review from someone complaining that the usb power connector had broken off on theirs, and the included photo showed it had a Ralink RT5350F WiFi SoC, which gave me hope that it would be hackable. So, I bought one.

Before opening it up, I tried it out. It works as promised. It defaults to broadcasting an unsecured WiFi network. Once connected, it shows up as an AirPlay receiver in iTunes, etc. From there, you can connect it to some powered speakers, select it and start playing music. The audio quality doesn’t suck (no obvious noise, clipping, or distortion), and in my limited use, there were fewer dropouts that I’m used to with Bluetooth.

Beyond that, there are various configuration options available through a browser based interface. There are no audio-related settings at all. Most of the settings are networking related. You can rename and secure the WiFi network with a password (good), WPS (bad) and by limited connections to specific devices by MAC address (meh). You can also connect to an existing network (good), and, optionally, extend it (meh). This seems like a good point to mention that it also works as a DNLA “renderer” (DNLA is a more open standard than AirPlay, making this useful to Windows and Linux devices, and Android phones with an appropriate app)

Of course, I didn’t buy it to use it with the stock firmware, so after trying it out, I opened it up to take a look inside. In the process, I managed to tear the translucent plastic that was affixed to the top of the case with adhesive. With the trim removed, it was easy to pry off the top, revealing the single PCB inside.

Version 2

As I expected, it is based on the obsolete but inexpensive and popular Ralink RT5350F WiFi SoC which includes a CPU and 802.11n WiFi.

  • Marked “RT5350F, TP08P40609, 1408STA”
  • 360MHz MIPS 24KEc CPU
  • 802.11n 1T/1R (1×1:1) 2.4 GHz 150Mbps MAC/BB/PA/RF
  • 5-port 10/100 Mbps Ethernet switch w/ 5 10/100 PHYs (unused)
  • USB 2.0 host/client (unused)

This is complimented by a modest, but sufficient 32MB of RAM and 8MB of flash memory to hold the firmware.

  • RAM
    • Marked: “EtronTech EM63A165TS-6G”
    • 255Mbit 16Mx16 5, 6, 7ns 166MHz SDRAM
  • Flash
    • Marked: “MXIC MX, 25L6406E, M2I-12G, 30392500, K141983”
    • Macronix MX25L6406E
    • 64Mbit NOR Flash
    • 4KB sector, 64KB block, 2.7-3.6v, H/W Hold
    • 1 or 2 bit bus, 86MHz x1 bus, 80MHz x2

The other major component is a Wolfson WM8960 CODEC to provide the audio output. This chip debuted in 2006, and includes 24-bit stereo DAC and ADC converters supporting sample rates up to 48Khz, a 40mW headphone driver, and a 1W Class D speaker driver.

Despite being a 24-bit DAC, the specified SnR of 98dBS matches that of the 16-bit TI/Burr Brown PCM2705 DAC used in the original AirportExpress, rather than of a modern, premium 24-bit DAC used in more recent AirportExpress’s. Oh well. Good enough for my purposes. Most of what I’m playing is compressed AAC files derived from 16-bit sources, and, AirPlay only passes 16-bit anyway. Beyond that, the design of the rest of the circuitry matters, and I’m not qualified to analyze it, nor am I equipped or inclined to try and measure it.

Beyond that, I see two inductors on the board (one of which is cracked). My guess is that these are part of some small switch mode power supplies, perhaps one for the digital section, and the other for the analog. There are two small LEDs to indicate device status and two momentary switches, one to reset the device, and the other to trigger WPS. It looks like it uses a single ceramic chip antenna for the WiFi.

There are a few unused pads for components, eight test points (half seemingly to do with power) and four unused holes for pin headers that I suspect provide a serial console.

That’s really it for the hardware. I’ve already started poking more deeply into the software and investigating the suspected serial console, and I hope to have another post soon documenting what I found.


iReceiver Elsewhere