Thoughts on the unreleased Tangara audio player

A brief analysis of the Kicad source files. Surprisingly uses two 32-bit microcontrollers.

Rubenerd recently mentioned a Crowdsupply for a portable music player called the Tangara.

This article is a random collection of my thoughts about the Tangara audio player based purely off a brief perusal of the released hardware sources. Everything here is theoretical, I don’t have an actual working unit in my hands to test. I’ve tried to include praise as well as criticism, but the latter is always easier (especially when you’re not the one doing the designing & hard work).

Quick summary of interesting points:

• Audio pathway: high-quality parts.
• Audio pathway: possibly a bad anti-aliasing filter (may or may not cause audible issues)
• Battery: probably can’t use the full marketed capacity (maybe only 3/4).
• Battery: good to see the (wrong model in schematic?) battery has a protection board.
• Charging: will likely charge slowly due to thermal constraints and linear charging chip.
• Interface: capacitive touch circle thingy like on original ipods, not tactile buttons. Dankpods would probably approve of this
• Robustness: would like to see some thoughts on 3.5mm audio jack toughness or replaceability.
• Complex hardware design with many single-source parts, including two microcontrollers. Will cause delays and headaches if some of the parts go out of stock.
• One of the main device photos on the crowdfunding page shows signs of being edited, it would be nice to confirm.
• Probable EMI & signal problems on the faceplate PCB and flat flex cable.

Power

Battery

The Crowdsupply page says the Tangara has a 2200mAh battery, but the schematic says (and links to ) 1000mAh. Presumably there is enough space in the case for either?

A selling point is the battery uses a common 3-pin JST connector, so it should be easy to replace with others that you can find online:

I hate this connector (and its 2-pin cousin). It’s very hard to unplug it by gripping the white plastic wings, so instead you tend to pull on the wires (either intentionally or accidentally when your pliers slip). It’s so easy to then pull the pins out the back of the connector and short out the battery. Alas it’s also the common standard, so I don’t know a good solution to this that wouldn’t sacrifice ease of replacement.

I love that the linked battery has a protection circuit board on it. Woohoo. Undervoltage (set to 3.0V not 2.5V yay) and overcurrent protection (so it will theoretically save fools like me that short it out).

I don’t think you will actually get the full 1000 or 2200mAh from the batteries (so claiming them to be that size in this product could be a bit misleading). The main microcontrollers are powered through an AP7365 3.3V linear regulator, which (if we assume a 100mA current draw) needs at least 3.4V to output 3.3V (perhaps even more for stability). Perusing lithium ion constant-current discharge curves suggests that discharging a lithium cell only down to 3.5V or so might skip anything from negligible capacity to 1/4 of its useful capacity under constant-current load conditions. Exact losses depend on the cell’s ESR, but that will be higher with the protection circuit and PCB polyfuse installed.

Charging

Two chips are used: one to negotiate USB power and a second to charge the battery. The MCP73871 charger is a linear (resistive) type, so it dissipates the difference between the input 5V and the battery voltage as heat.

I think this is a rather odd choice. Resistive chargers can’t charge very quickly, even 500mA requires 0.4W to 1W of heat dissipation. USB will give you 500mA without negotiating. I would have thought a negotiation chip only really necessary if you want to charge at higher rates (eg 1A or 3A) using a switchmode battery charger chip.

500mA could be an optimistic estimate. The MCP73871 charger chip can do 1A, but it will start throttling down when it hits 100degC internally:

Its heatsinking on the PCB isn’t as good as it could be, so I suspect this will happen rather quickly:

The big square pad where “21 GND” is written is the thermal pad underneath the charger chip. All heat generated by the chip needs to be wicked through the 4 small vias in the corners and into the ground planes inside the middle of the PCB. I would prefer to see more vias and I would prefer to see an outer copper layer of the PCB being used as heatsinking too.

I might be wrong, this amount of heatsinking might be enough. I’m not good at doing thermal modelling inside my head so I instead rely on vague ideas of what does and doesn’t work. They’re often inaccurate :)

The MCP73871 charger chip has configurable voltage charge limits, potentially allowing it to be configured to only charge to 4.10V instead of the standard 4.20V. Some users might want access to this setting as it’s believed to increase the life (number of cycles) that the batteries can survive.

Robustness & safety

I am very happy to see fuses everywhere.

I am very happy to see ESD protection on the USB input. Perhaps also some low value resistors in series with the USB data lines might also be good (or is that an old myth that I follow blindly)?

Radio performance

The ESP module has a wiggly antenna on it:

Having bits of metal near antennas, such as copper in PCBs, will change their radiation patterns and tuning (which can in turn make them perform poorly and possibly even emit more EMI, depending on the radio design). I would prefer to see these two areas of the board either removed or have all copper excluded:

Maybe this is actually perfectly fine and I’m worried about nothing? I wonder if Espressif has recommendations about how to position their modules on your PCB.

Lots of single-supply parts & complexity

There are approximately three tiers of availability to consider when choosing components in a design:

1. “Jellybean” or multi-vendor parts. Components that multiple companies make compatible clones or variants of. These will be very cheap and never go out of stock, but their specs and capabilities will be years to decades behind. You will need to use more of them to get the same job done as a more complex part.

2. Parts with equivalents in different footprints. Eg different brands of I2S DAC (turns bits into audio waveforms) and opamps with incompatible pinouts. You can put multiple footprints into your design and only choose to use one during manufacture. Altering your design when a part goes out of stock is annoying but not too hard. This is why many products have revisions.

3. Single-source (“SS”) components. Replacing them requires rewriting a big chunk (or all of) your firmware and/or major revisions to your board.

I’m a member of the Cult of Passionately Hating Single-Source Components. I’ve been burned by SS at work, in my hobbies and when repairing other people’s stuff. Sadly it’s really difficult to avoid SS completely — microcontrollers, for instance, are only sometimes cloned by another company — so the best you can do is minimise the amount of SS parts you use.

Sidenote: RISC-V microcontrollers will not fix this problem unless they also standardise on peripherals. ie allow people to take code for one micro and run it on another without modification (or at least with minimal modification). The only microcontroller ecosystem that I know about that is close to achieving this is the 8051 ecosystem, but an 8-bit design with 3 different types of register/memory and low clock speeds won’t do for driving colour LCD screens, talking microSD, talking USB and decoding music; so it’s a bit useless to suggest here.

A project with lots of SS components can work perfectly fine, but, you will have to (1) be very quick between designing your stuff and ordering the components (some parts go out of stock or mega-price-jack within weeks or months) and (2) you must resign yourself to headaches if you ever want to manufacture a second batch of units at a later date. Big companies work around this by waving fat stacks of cash and thick contracts at suppliers.

The Tangara has lots of single-supply parts, much more than I would expect or recommend for a device like this being made by a small group. I’ll mention this a few times throughout, but the gist is: I expect the makers to have some headaches come manufacture time. I hope they don’t, but the more SS you use the worse your odds.

Two microcontrollers means double the trouble

The Tangara has two microcontrollers:

1. An Espressif ESP32-WROOM-32 (in WROVER-E-N16R8 package) for doing the processing gruntwork whilst the unit is turned on and for wireless comms. 32bit, up to 40MHz, Xtensa LX6 architecture (not ARM or RISC-V).

2. A Microchip SAM D21 for handling some auxiliary tasks. 32bit, up to 48MHz, 256KiB of flash, ARM variant.

Designing with one microcontroller is scary enough, two would terrify me. It looks like the ESP32-WROVER-E-N16R8 is still in stock but the datasheet says its not recommended for new designs (that’s vague terminology that often means they have a stockpile of chips or wafers but probably won’t make more). The SAM part is still current (but that doesn’t necessarily mean much).

Why did the designers choose to go with two micros? They’re both vaguely equivalent in processing power. I’m not certain, but I can hazard some guesses based off my experience:

1. Brownout (low battery voltage) handling. It simply might be easier on the SAM part. Perhaps the ESP32 needs a nice, stable 3.3V for its flash memory to even boot (ie for it to even run any code to detect & handle low-voltage conditions). Perhaps a discrete brownout detector (using a jellbean comparator) could be used here, so this argument alone is unlikely to be enough.

2. Software momentum. If there are pre-existing codebases for (eg) USB handling on one micro and audio handling on the other then it’s simply easier to spend more money on parts than it is to spend more time on writing and testing completely new code.

The ESP32 firmware for this project is over 10,000 lines long (not including the libraries or FreeRTOS) so I suspect the author has put a lot of time and effort into it. I totally respect them if they took shortcuts like “screw this, I’m not a team of developers, no way am I writing my own USB/codec/SDcard/etc implementation and making it happily coexist with the rest of the realtime code”.

Probably an even lazier (read: better for mental sanity) solution worth considering would be to use a micro big enough to run a stripped down Linux OS (down to a few MiB). I’m not sure if you can get good sleep modes on these chips however (so that you don’t annihilate the battery) and you might have to externally buffer the audio samples going to the DAC so the chip can stay asleep for longer (maybe waking every 100msec just to poll button inputs). If done correctly it might be competitive; and perhaps even be less effort to port to another chip if the micro goes out of stock (that would be the big attraction for me). Maybe.

Unexpected complexity

Both microcontrollers can access the same MicroSD card via some switch chips. Why?

An IO expander chip is used that both microcontrollers can access via I2C. Is this because the microcontrollers don’t have enough pins, or is it so they can share pins?

Audio

Audio pathway quality

We have a WM8523 DAC (digital to analog converter) followed by an anti-aliasing filter (to hide the sins of the DAC) and then an INA1620 audio amp.

The WM8523 seems OK. I’m cheap and would go for a simpler 8-pin I2C stereo DAC, but this WM8523 part claims some high specs that might help with sales.

The anti-aliasing filter… is set to 105Khz? That seems a bit high?

Hmm I wonder what the datasheet recommends…

Huh.

I don’t like it. There are too many (unwritten) assumptions for this to work correctly.

There is a lot of background frequency domain technical material needed to properly explain this, so instead I’ll just summarise the key takeaway points:

• This will only work correctly if you are running the WM8523 at the full 192KHz samplerate OR if the WM8523 is equivalently upsampling/interpolating to that or higher (but I can’t find mention of those keywords in its datasheet). If you’re running it slower then the anti-alias filter will not prevent lots of unwanted high-frequency junk appearing at the output.
• High-frequency junk isn’t supposed to be audible to human ears, so it might be fine, or it might cause distortion of the audible frequencies too. It could also cause other minor issues like increased power draw and earlier audio clipping/sticking artefacts.
• You might need to upsample all audio to 192Khz in software (in the ESP32) to avoid this problem. Or maybe I’m wrong about the WM8523 and it does upsample/interpolate for you anyway.
• Even if it does work AND your digital frequency domain is flat above 20KHz: it will only attenuate 200KHz junk by about 6dB. That’s not much.
• If your digital frequency domain contains content above 20KHz it will technically be even worse. But hey, only worse by like 6dB \_(o.o)_/

I’d much prefer a lower frequency anti-alias filter and more poles so that it attenuates more quickly. The tradeoff will be that there will be a few degrees more phase distortion (delay) in the audible frequencies.

Maybe I’d suggest two poles (series copies) of an approx 50Khz lowpass filter? I’m not sure, I don’t normally design things that are supposed to sound nice and sell well. This is also assuming you are either upsampling in software or getting the chip to interpolate for you, otherwise you would want to slam that filter down to 10-20KHz or so (and cry).

Anyway, let’s move onto the audio amp, an INA1620. I think the built-in resistors are kind of cute. It’s expensive at $5-10USD each, I’m far too cheap for that :) It’s a single-source part with a unique footprint, you could potentially replace it with a jellybean rail-to-rail opamp, but the power output power levels would be lower. Good to see it’s EMI immune (so it should hopefully not pickup mobile phone interference or other radio-frequency junk from other parts of the design).

Layout

Nice to see the analog parts are at a separate end of the PCB to the digital parts. Hopefully very little power rail noise will get to them, but you’ll have to listen (whilst using features like BT/Wifi/LCD) to find out.

I’m a bit flummoxed by the choice of inner PCB layers. It’s a 4 layer PCB, so normally you would expect the middle 2 layers to be 3.3V and GND. Instead they’re both GND. 3.3V wires snake in small parts of one of the two layers (breaking the ground plane up anyway).

Misc audio notes

It’s interesting to note the INA1620 is fed by a pair of +5V and –5V rails but the whole device is only powered by a single lithium-ion (~4V) battery. A switchmode power supply (a TPS65133) is used to generate the rails. It’s very efficient (~90%) and I guess the few USD it costs is fine compared to the audio amp. In my head I just think it a bit inelegant to use a switchmode power supply to run a resistive AB audio amplifier — why not skip the middleman and use a class-D audio amplifier directly? Take the inductors you put on the power supply and place them on the class D amplifier, remove one chip, profit?

The schematic mentions a “Stage 3: buffer” in the audio chain, but it looks to be missing. The schematic has probably been edited since that comment was added.

Audio jack

I don’t like the lack of ESD protection on the audio jack. Humans plugging in headphones might (?) eventually kill the INA1620 audio amp chip.

Some series resistors might also be a good idea, for when people plug stuff with phantom power into the TRS jack. I don’t mean 48V studio phantom power (oh god!) but instead things like desktop mic phantom power (something like 5V through a resistor?) and line-level mishaps. Alas these also lower output power. Perhaps the short-to-GND protection of the INA1620 might be enough under short-to-something-other-than-GND conditions too.

The audio jack itself looks flimsy. Hopefully the unit is light and small enough that it’s hard to break the jack. You could fix this by either going for a more heavy duty 3.5mm female audio jack OR by putting it on a little daughter-board (connected via ribbon cable) and selling replacement daughterboards to end users for when they sin the inevitable. I would be interested to see if anyone has any good experience in this area — are there certain designs of PCB-mount 3.5mm jack that are better than others?

I notice a 3.5mm jack insert detection circuit:

I’m not quite sure but I think the wire this monitors is also the microphone line? Ie the 4th metal contact on a 3.5mm TRRS headphone jack. This gets used by volume control buttons on headphones interestingly enough, so it would make sense that this is monitored. I don’t know the timings of this signal and it’s connected to the IO expander chip, so it might require lots of polling (and software debouncing) to use.

Alternatively perhaps it’s just there to auto-pause your music when your headphones fall out 8)

Screen & touchpad

The screen and touchpad are a second PCB called the “faceplate” that stacks ontop of the main one. They’re a separate Kicad project in the sources repo.

Touchpad

It’s an actual circular touch thingy! Not tactile buttons.

I have no idea how these are designed or what the tradeoffs are, so I can’t comment further. Hope it works well :)

LCD screen

It’s a JD-T1800. It’s unlikely to be pretty and it will pull something like 100mA when backlit. I suspect it was chosen because (unlike fancier things such as e-ink) this LCD is popular enough that you can buy it off the shelf and Adafruit has libraries for it.

Layout problems

I suspect that this 2-layer board will have emissions and signal integrity problems. The return paths of the signals through the GND planes are poor.

High speed signals like to return in a path very close to the way they came. When you break this rule you make loop antennas. This is a really good video on the subject with lots of graphics, sadly it’s long but I think it’s worthwhile.

I think most of the problems could be solved by re-arranging the pins on this connector:

Instead of clustering the grounds at each end: intermingle them between each of the signal wires. Then put a GND via next to every GND pin on the connectors (both ends). This will allow the return paths of signals to travel through the GND plane and the GND traces of the flat flex connectors whilst staying very close to each signal wire.

Mirror universes

I appreciate this detail in the schematic next to a flat flex cable connector:

Hahahaha I’ve done that too many times before. Everything is stacked against you getting this right.

In a recent design I did: I used double-sided flat-flex connectors (so you could plug the ribbon cable in upside down) and used two connectors next to each other, one with the pinout reversed. That way I could worry about the “right” and “wrong” cable orientations later without having to re-order boards. The extra $0.10 or so to do this was well worth it, especially since we moved the daughterboard (making the flat flex cable upside down, which naturally reverses the order of its pins).

Something odd in one of the photos

This shot here:

It looks like the LCD screen may have been edited onto this photo.

This is quite common. It’s really hard to get a photograph that has both the real world and an LCD screen looking good at the same time, one or the other tends to be under or overexposed. Often people taking photos of computers will take two photos with different exposure settings and then edit them together manually afterwards.

Have a look at the lower-right corner of the screen:

Is the bright light caused by a backlight leaking out of the side of the LCD matrix? Or has the screen been added onto the photo using an additive colour mixing model? The white plastic bezel should make the screen look darker, not lighter.

Also look at the upper-right:

I think I can see a hair of white plastic from the 3d printed case that seems to vanish when over the screen. Alternatively it could be actual real life optics doing this (the screen is quite bright in this photo), not sure.

If this has been edited: as far as I can tell it’s not misleading, just interesting. If it turns out the screen is so dim that it can’t be reasonably read in that environment then people might not be as happy, however.

MicroSD card

It looks like the Tangara is using a click-in click-out MicroSD card holder. I’ve found the friction ones to be nicer to use, break less and be less likely to be bumped out whilst in a bag. YMMV.

MicroSD cards can sometimes take siestas for hundreds of milliseconds after you ask them to do something. It might be wise to avoid writing data as much as possible. This bit me recently with some embedded audio work (saving recordings live to MicroSD cards with limited RAM to buffer the samples).

Final odds and ends

Thankyou to Jacqueline Leykam & co so much for releasing the sources to the hardware and software. I’m very glad for that, it lets me get an understanding of the product before buying it (a bit like a game demo). It will also allow me to repair it much more easily and to extend upon it. This is pro-consumer and a breath of fresh air compared to most portable devices.

(To do the devs: you should also ignore most of my critique. If you tried to fix everything from everyone’s criticisms or wishlist then you will never release)

Financial nitpick: The PCB has parts on both sides (“double-sided load”) even though I think it might be possible to fit all of the parts on just the top side. This will increase manufacture costs (they have to use glue dabs on parts for one of the sides) but I don’t know by how much, I’ve never been involved with this process before.

Schematic nitpick: The Kicad schematic is spread across multiple sheets with labelled wires. This makes it quite hard to find where things actually connect to (you have to use Ctrl+F quite a lot). I much prefer schematics where everything is on one page, wires drawn to join almost everything. I guess an analogy to this can be made with C code: it’s hard to read a codebase that communicates through dozens of global variables instead of direct function calls. I often end up drawing my Kicad schematics on A3 or A2 sized paper so that I can fit everything on it.

Tangara is one of my favourite Sydney train model names, but sadly the trains themselves are not fun to ride in with their permanently fogged windows. Is this a curse that will continue?

I’m hoping these devices get made, shipped and I start hearing reviews.