THD+N</th>	dBFS</th>	Volume %*</th></tr></thead>
0.015%</td>	0dB</td>	87%</td></tr>
0.014%</td>	-1dB</td>	86%</td></tr>
0.014%</td>	-10dB</td>	78%</td></tr>
0.022%</td>	-20dB</td>	68%</td></tr>
0.066%</td>	-30dB</td>	58%</td></tr>
0.150%</td>	-40dB</td>	47%</td></tr>
0.480%</td>	-50dB</td>	37%</td></tr>
0.185%</td>	-60dB</td>	27%</td></tr> </tbody></table> (The highest 13% of Tangara's volume meter is used for digital gain.)</p> From this we can see that, as long as your headphones reach a comfortable volume above 47% of Tangara's maximum volume (equiv. to 60% consumer line level</a>), there should not be any perceptible noise or distortion. But, what about more sensitive headphones that are only comfortable to use below this level? To address these, first we need to talk about signal-to-noise ratios.</p> Signal-to-Noise Ratio (SNR)</h3> SNR is a measure of the difference between the loudest sound a device can produce, and the loudest noise present when not playing anything (or more specifically per AES17, the noise present when playing a -60 dBFS test tone). This is an important metric for understanding audio devices, as it gives an indication of how much listenable volume a device has before you will begin to hear the background noise inherent in every device (the "noise floor").</p> Your ears have an effective dynamic range of about 70-80dB before you begin to damage your hearing. Tangara has an SNR of 106 dB. But how do you compare these numbers? Does Tangara's wider range mean you won't hear any background noise? It's difficult to answer this without knowing the characteristics of your headphones; particularly the SPL (sound pressure level; usually measured in decibels per watt, or sometimes decibels per volt) and impedance (usually measured in ohms).</p> A full explanation of these characteristics is beyond the scope of this post, but at a very high level you can put most headphones into one of three categories:</p> "Easy to drive" headphones that are neither particularly sensitive, nor particularly high fidelity. Most non-audiophile headphones are in this category.</li> "Easy to drive" headphones that are highly sensitive, but also high fidelity. Most IEMs (especially the cheaper ones) are in this category.</li> "Difficult to drive" headphones that are less sensitive, but high fidelity. This category includes the bulk of what you might call "high-end" gear; everything from fancy studio headphones to expensive planar IEMs.</li> </ol> The second and third categories are the most problematic, as they have contradictory requirements.</p> Highly sensitive headphones need only a tiny amount of power to produce sound, which makes them susceptible to high noise floors. To support these devices, it's best to use your available SNR at the low end (by applying damping, then running your DAC at a higher volume), in order to keep the noise floor below an audible volume.</p> "Difficult to drive" headphones, on the other hand, will rarely pick up a device's noise floor. They may, however, struggle to produce sound at a loud enough volume to be well audible. To best support these devices, it's best to use your available SNR at the top end by applying gain, so that you have enough headroom to increase volume before you run out of power.</p> Ultimately, when designing a device like Tangara, you have three options for what to do with your dynamic range:</p> Use it for top-end, giving people with high-end headphones the best experience.</li> Use it to lower your noise floor, giving people with more sensitive headphones the best experience.</li> Use a substantially better DAC, increasing the cost of the device.</li> </ol> For Tangara, we chose option one. First, because we didn't want to further increase the cost of the device with an expensive DAC that most users won't get value out of. Second, because lowering the noise floor post-hoc is a much easier modification to make than adding more amplification.</p> A Hack for Budget IEMs</h3> There is a whole market these days of cheap, high-fidelity 'in-ear monitors' (IEMs; they're fancy earbuds). You can typically find them for $20-$40, and they sound great.</p> The main downside of this style of headphone is that they typically are overly sensitive; often able to pick up and make audible the noise floor of even very good DAC implementations. You will hear this as a very quiet 'hiss' or white noise during quiet pieces of music.</p> It is difficult to provide a good experience for this kind of device without either spending more money on a more advanced DAC chip, or adding complicated circuity to modify your amplifier's gain (both upgrades that are wasted when paired with higher-end headphones).</p> Tangara's noise floor is</em> audible through such devices; although it's quiet enough that most of the team could only hear it when I coached them into what to listen for and then played back pure tones through various other devices. It's therefore probably good enough for you.</p> If you're a real audio head, and this isn't</em> good enough for you, then soldering two small resistors is an easy mod that will shift the whole signal down. You can then listen at a higher volume, without an audible noise floor.</p>* Referring back to the schematic for Tangara's audio chain, pay attention to the region between the DAC's output filter and the amplifier's input.</p> This is a tremendously good location for implementing all kinds of modifications. In this example, we're going to add some small resistors from the signal path to ground. This will attenuate the entire signal -- including the noise floor. We can then set the volume level higher to compensate for this, resulting in audio output that is still loud enough to listen to, but with greatly reduced background noise.</p> This is the same principle as devices like the iFi iEMatch</a>. However, because Tangara is an open source device constructed with hand-solderable parts, it's very practical to implement this solution completely internally. This avoids a bulky extra dongle, and also eliminates any chance of affecting the frequency response of the output.</p> In our case, we're going to solder one 0603 resistor per channel, on top of C15 and C6.</p> </p> This creates a voltage divider together with the DAC's output filter resistor and the input impedance of the amplifier (which I've simplified into one resistance value. Don't worry about it!)</p> </p> We can then make an equation to find the damping amount provided by various resistor values:</p> `20log10(x / (525 + x))</code></p>` Resistor</th> Damping (approx)</th></tr></thead> 650</td> -5dB</td></tr> 250</td> -10dB</td></tr> 100</td> -16dB</td></tr> 60</td> -20dB</td></tr> 16</td> -30dB</td></tr> </tbody></table> In my case, I wanted to use a pair of Salnotes Zeroes. These felt comfortable at around 30-40% volume, so I used a 100 ohm resistor to bring the noise floor down by 16 dB.</p> Soldering this together is fairly easy as SMD work goes, since we can place the new resistors directly on top of the capacitors:</p> </p> Redoing my THD+N measurements with the mod in place, I got the same results as earlier, except that now my device's "0dB" point is a bit quieter than it was earlier. Finally, testing with my IEMs, there is now dead silence (to my ears, anyway) during very quiet playback.</p> Conclusion</h3> I hope this update has been informative about not only Tangara's audio quality, but also discussions of audio quality in general. There is no perfect solution to high quality audio, but I think we've designed a device that strikes a good balance between quality, cost, and upgradeability.</p> A Deep Dive Into the Design of Tangara's Touchwheel 2024-02-07T00:00:00+00:00 This is a mirror of a campaign update originally posted on CrowdSupply</a>.</em></p> First off, thank you so much everyone for your amazing initial response! We hit our funding goal within half an hour of campaign launch!</p> Over the next few weeks, we'll be releasing a series of updates showcasing particular aspects of Tangara's design. The first of these is written by Daniel (@ailurux), and will cover a feature many of you have been curious about: the touchwheel</p> In this update, we'll go through the history of why we chose a capacitive touchwheel for Tangara, how the current design works, and what it can do, as well as some resources and tips for incorporating this kind of touchwheel into your own projects.</p> To Begin, a Bit of Background...</h3> Tangara's input hardware has changed a lot over the last year of development. Whilst Tangara's current design may be nostalgic for fans of the original iPod, our original concepts were actually much more inspired by cassette tapes. I've long had an affinity for cassette tapes, and there is some overlap between my love of tapes and my excitement about making a physical, distraction-free music player that can't suddenly decide you don't have the right to listen to your music.</p> </p> The notion of using a circular screen was short-lived. Whilst it's absolutely possible, and circular TFT screens are available and fairly cheap, it just wasn't functional to reduce the screen real-estate by about a fifth just for the aesthetics. But already, a wheel was feeling like a compelling input method.</p> We made a few prototypes that used a rotary encoder with a 3D printed wheel or knob, but we realised this method was going to add a lot of complexity and bulk to the case, especially if we wanted a push-button as well.</p> Our next idea was to use an angular sensor, as they have a lower profile and can detect position as well as rotation. However, these components don't come with push buttons, often don't have a full 360 degree operating angle, and still required a separate part – one with even tighter tolerances.</p> With neither of those two initial ideas working, we went back to the drawing board and came up with a bunch of different ideas. We had a pretty good idea of what our requirements for the input were at this point: we wanted something low-profile, affordable, with some kind of haptic or tactile feedback, and with enough flexibility to support multiple methods of use.</p> </p> The most promising idea was to use a circular trackpad module, like the Azoteq ProxSense or Cirque Glidepoint trackpads. These are very low profile, high resolution trackpads that come in a variety of sizes and seemed ideal. We ordered a few of these modules and built some prototypes to test. Unfortunately, we discovered the Azoteq ProxSense range requires an additional, rather-costly flashing tool (and Windows-only software) to unlock its full functionality, with only basic gesture controls available by default. Our prototypes with the Cirque Glidepoint trackpad worked better, but we were worried about the cost and availability of these modules for smaller manufacturing runs.</p> </p> We then considered designing and manufacturing our own custom trackpad module for Tangara. Whilst researching this, we found a design guide</a> on capacitive touch sensors that described a wheel sensor design for capacitive touch electrodes. This design would allow us to build a capacitive touchwheel directly onto Tangara's faceplate. Not only would we be able to do this with just one affordable IC and three fancy-shaped electrodes, but it would also be extremely low profile, give us the flexibility to customise the size and shape, and even leave us room for a middle button and haptic motor. We were really excited by this and so we set to the task of making a prototype.</p> How (Not) to Re-Invent the Wheel</h3> The aforementioned design guide is a really great resource on how this kind of capacitive touch wheel works, and I'd highly recommend starting there. The guide lists a few different arrangements of electrodes for different capacitive buttons, sliders and wheels.</p> One way to make a capacitive touch wheel is to place many electrodes in order in a circular arrangement and when one of these electrodes detects a touch, based on the known order of electrodes the approximate position of the finger on the wheel can be determined. This is actually how the iPod's click-wheel works.</p> </p> Another way is to use just three electrodes with an interpolated shape, so that as the finger moves around the sensor, the signal moves smoothly between electrodes and we can use this to determine roughly where the finger is on the wheel.</p> </p> We were pretty excited to try out the interpolated wheel design, the only thing left was to figure out how to create that tessellating, radial zig-zag shape. I watched Jacqueline try to trace the image from the design guide in KiCad, manually clicking each point along the path for 15 minutes or so, when a misclick caused the path to be lost and she paused for a moment, sighed, and then started over again. I felt a need to jump in at this point and said I'd create the path as an SVG and send it to her.</p> I knew I wanted to programmatically create this shape, with the ability to tweak the parameters so that we could quickly iterate on the design if needed. I've previously used JavaScript to generate SVG files, so I reached for that here.</p> I found this decade old blog post</a> which was really helpful. It details how the author solved this problem with OpenSCAD by using chain-hulls in place of arbitrarily defined paths. As SVG does allow for arbitrarily defined paths, I could use the author's first idea of generating a triangular path around an arc.</p> The basic process is to generate the shape using polar coordinates, which, instead of defining a position from the origin in terms of X and Y, defines a point by its distance and angle from the origin. This allows us to move outward from the center in an arc, and we can switch the direction by changing the angle or draw a straight line outwards by changing just the distance.</p> </iframe> You can access our SVG tool here</a>, along with the code that powers it, all of which is visible in the page source. The SVG path does usually need some manual processing before it can be used in a PCB, but this should hopefully be a good starting point for anyone looking to incorporate this kind of touch sensor into their own projects. I think it would be really cool to see more projects using it!</p> </p> We were super-impressed with the performance of the final result. With just three electrodes and a cool form-meets-function design, we're able to offer a touch input that feels really responsive and nice to use. This design can also support other input methods, such as a directional pad mode, or even just using the wheel as a large button. We've even experimented with using the angular detection to control the pitch of a basic square wave synthesizer, which produced fun results.</p> Final Thoughts</h3> Overall, we're really happy about what we've come up with for Tangara's input. It's space-efficient, versatile, and effective. We think the touchwheel is a great fit for this kind of device, but because we've implemented it on a separate PCB, it's also easy to replace with other input hardware. In a later update, Jacqueline will be showing off a custom faceplate featuring a rotary encoder and buttons.</p> All Aboard! 2024-02-01T00:00:00+00:00 And we're away!</a></p> Tangara is a cool, hackable, ESP32-powered music player that provides high-quality audio, long battery life, and a design that's easy to customize, repair, and upgrade.</p> If you read our pre-launch page, you may be delighted to learn that Tangara has gotten even better since then! Standby battery life is now much longer, and we've rewritten our entire user interface in Lua, for easier customization.</p> We'd love for you to give our campaign page</a> a look, and consider backing Tangara!</p> </p> ps: here's a picture of jacqueline's cat</p> </p>

cool tech zone

Pre-production Progress

2024-03-07T00:00:00+00:00

This is a mirror of a campaign update originally posted on CrowdSupply</a>.

Our campaign crossed 500 backers this week! Thank you so much to everyone for your kind support! All of us in the Cool Tech Zone feel so lucky to have this opportunity to share our little music player with so many people.

This week we were intending to talk about the design of Tangara's case, but some illnesses in the team have left us without time to do a proper write-up. So instead we'll tell you about the case design next week, while this week I'll be giving you a short update on how things are going with our pre-production work.

Lua Support

2024-02-24T00:00:00+00:00

This is a mirror of a campaign update originally posted on CrowdSupply</a>.
Hey everyone, Daniel here again. At the time of writing this we just passed 2000% funded! Thank you all so much!
This week's update is about Tangara's support for the Lua scripting language. I'll talk a bit about what Lua is, describe what it can do, and share some fun examples of how you can control Tangara from a Lua console. Then Hailey will show off the desktop companion app she's been working on, which uses Lua to do some really cool things as well.
Lua on Tangara</h2>
We've previously said that, in striving to make a truly hackable music player, we accidentally created a really fun and useful development board. One place where this really shines is in Tangara's Lua support. By connecting your Tangara to a computer, you can use an interactive Lua session to run code directly on the device.
What Is Lua?</h3>
Lua is a scripting language similar to Python or JavaScript. It's a great first language as it's beginner friendly, has a lot of online resources, and is used in many different types of applications, especially in the worlds of game development and modding.
Control Your Device With Code</h3>
Tangara's UI is written in Lua, using the same APIs that are that are exposed through the serial console. What that means is that anything that Tangara's UI can do, you can do with code as well.
Let's go through an example of what that actually looks like. I'll start by connecting my Tangara to my computer with a USB Type-C cable, and use the screen</code> program to connect to the serial console. Alternatively, you could connect using our companion app (more on that later).
Once connected, we can open an interactive Lua shell by using the lua</code> command:
→ lua Lua 5.4.4 Copyright (C) 1994-2023 Lua.org, PUC-Rio luarepl 0.10 Copyright (C) 2011-2015 Rob Hoelz >> </code></pre> That >></code> is Lua's prompt, where we can write code and have it run directly on the device.
>> print("hello") hello </code></pre> Our Lua API allows us to directly interact with many of the firmware's features. For example, we can use the volume</code> module to see the current volume and other related settings.
>> volume { current_db = property { -9 }, current_pct = property { 100 }, left_bias = property { 0 }, limit_db = property { -10 }, } </code></pre> We can see here that current_pct</code> is a property with a value of 100, meaning the volume is currently at 100%. Tangara's Lua API has many of these properties, which are values from the C++ firmware that you can inspect, modify (if the property is not read-only), and do data binding with. In this case, none of these properties are marked as read-only so we can use the set</code> method to change their values. Let's try setting the volume to 60%:
>> volume.current_pct:set(60) true >> volume { current_db = property { -40 }, current_pct = property { 60 }, left_bias = property { 0 }, limit_db = property { -10 }, } </code></pre> Not only has the current_pct</code> value changed, but we can also see that the current_db</code> value has updated to reflect the new volume as well. Now let's take a look at another module, the Bluetooth module.
>> bluetooth { connected = property { false, read-only }, devices = property { table: 0x3f939364, read-only }, enabled = property { false }, paired_device = property { nil }, } </code></pre> The connected</code> property describes whether or not Tangara is currently connected to a Bluetooth device. This property is read-only, meaning we cannot set the value of this property from Lua. It can only be updated from the firmware when a device is connected or disconnected – it wouldn't be very useful to be able to set connected</code> to true if the device isn't connected to anything. To turn Bluetooth on, we can set the enabled</code> property to true.
>> bluetooth.enabled:set(true) >> bluetooth { connected = property { true, read-only }, devices = property { table: 0x3f93ec18, read-only }, enabled = property { true }, paired_device = property { table: 0x3f93f418 }, } </code></pre> Here I was able to connect my Method ANC Bluetooth earphones by setting enabled to true, then the firmware automatically connects to previously connected devices, in this case my earphones. Checking the Bluetooth properties again shows that connected</code> is now true.
Other Fun Examples</h3> Controlling Playback</h4> For properties and functions related to audio playback, we have the playback</code> module. >> playback { playing = property { false }, position = property { 0, read-only }, track = property { nil, read-only }, } </code></pre> To pause playback we can do something like playback.playing:set(false)</code>, and to begin playing again, we can do the same but with true</code> instead of false</code>. We could toggle play/pause by using a combination of get and set to get the current value, then set the new value to the opposite: >> playback.playing:set(not playback.playing:get()) </code></pre> Adding Tracks to the Queue</h4> This one is a bit more advanced, and explaining each element would be outside the scope of this post. As an example, though, here's how you might add all tracks from the database to the queue: >> iterator = database.indexes()[3]:iter() >> queue.add(iterator) >> queue.size:get() 607 </code></pre> For more about database indexes and getting tracks from the database, you can check out the ldocs pages here</a>. Controlling Display Brightness</h4> Changing Settings</h3> You can use Lua to change many of Tangara's settings, including display brightness, volume, input control method, scroll sensitivity, and more. This not only gives you more control over your device, but also improves accessibility and reliability. For those of you already familiar with Lua or willing to learn, this is another way we're giving you control over your device. Of course, we don't expect everyone will be comfortable with or interested in writing code. You can also change all of these settings from within the on-device settings screen. The fact that these settings are available in Lua also means you can easily set them from Tangara's desktop companion app. Our friend Hailey has been doing amazing work on this, so I'll hand the mic over to her to tell you all about it. Take it away, Hailey! Desktop Companion</h2> Thanks Daniel :) Hailey here! I've been helping the team out by working on Tangara Companion – the desktop companion app for Tangara. Our vision for Companion is to make it as easy as possible to hack, update, and explore your Tangara, without first needing to become an expert on the commandline or wrangle a whole pile of commandline tools. We want Companion to be convenient for seasoned users while also providing a gentle on ramp for everyone else looking to learn how Tangara works. Just like Tangara, Companion is hackable and open source, under the GPL-3 license. Companion is written in Rust</a>, a programming language that makes it hard to make mistakes, and built with GTK</a>, a desktop framework that originally came from the Linux world and that makes it easy to write gorgeous cross-platform apps without getting too snarled up in the details of the various platforms. This means Companion is fully cross platform too, and we'll be providing official downloads for all three major platforms: Linux, Windows, and macOS. We'll make it as easy as possible to compile yourself, if that's more your style, and if you happen to be an enthusiast of little-known operating systems, we'd also love to hear about your experience getting it going. Let's dive in and see what Tangara Companion actually looks like: Straight away it shows a bunch of important details about your Tangara. Companion communicates with Tangara over USB Serial, and the serial port in use is shown. On my machine, that's /dev/ttyACM0</code>, but on Windows for example, it'll be the familiar and enduring COM port. You don't actually need to know all about serial ports to use Companion, but we're building a hackable music player here, and it's just not in our nature to hide the details. From the topic of this post, you might be able to guess how Companion retrieves the rest of the information shown on this screen. That's right – with Lua! Tangara's Lua environment is exposed over the serial console, and Companion uses the Lua console to talk to Tangara just like you would if you were exploring what Daniel talked about above. To retrieve the firmware version, for example, Companion sends the code require("version").esp()</code> to the Lua console and reads whatever that function returns. The settings page works the same way, and even uses the fancy data binding stuff that Daniel spoke of. All settings changes in Companion take effect immediately on Tangara. Likewise, all settings changes on Tangara are reflected live in Companion. When I first got the settings page working, it was extremely cool—and kind of magical—to see my Tangara's screen brightness change in real-time as I dragged the brightness slider up and down with my mouse. Finally, there's the Lua console and the firmware update pages. I won't go into the Lua console in this part of the post, since I'd just be repeating what Daniel has already said, but it's worth taking a look at how Tangara firmware updates work. Firmware updates are distributed in a format we've designed specifically for Tangara—the Tangara Release Archive—which is also supported by Companion. This format is really simple. A Tangara Release Archive is just a ZIP file that contain binary images to be flashed to Tangara and a tangaraflash.json</code> manifest that lists each binary image and its address in ROM: { "version": 0, "data": { "firmware": { "version": "0.6.0", "images": [ { "addr": 65536, "name": "tangara.bin" }, { "addr": 11599872, "name": "lua.bin" } ] } } } </code></pre> Hitting the flash button will take care of it all, and pretty soon you'll have a freshly updated Tangara! Happy listening :)
Creating a Custom Faceplate 2024-02-21T00:00:00+00:00 This is a mirror of a campaign update originally posted on CrowdSupply</a>. Hello again! Thanks so much to everyone for continuing to support our campaign! We're so excited we'll be able to get our little music player into so many people's hands and pockets! So far we've talked a lot about Tangara being "easy to hack on" and we've shown you a few small examples. But what about larger changes to your device? In this update, I'll be walking through the process of creating a totally custom faceplate. Specifically, it'll be a faceplate that uses a physical rotary encoder, rather than a capacitive touchwheel. This is a great little project that's very easy to design and cheap to build. The most difficult part will be soldering the small pitch 15-pin FFC connector. If you're interested in diving deeper, the sources for this design are all available on Sourcehut</a>. Constraints</h3> We want our custom faceplate to be compatible with an unmodified Tangara mainboard, so we don't have to build a totally new device. Mostly, that means we need to reuse the same general faceplate form factor (the size, mounting hole locations), as well as the same FFC connector and pinout. The FFC connector has 15 pins, including: 3v3 power</li> Ground</li> An I²C bus (SCL and SDA)</li> A half-duplex SPI bus (SCLK, PICO, CS)</li> Three extra GPIO pins, connected directly to the ESP32</li> </ul> The display -- which we'll leave unchanged -- uses the SPI bus and two GPIOs. This leaves us with one spare GPIO, which we can use either as a CS line for a second SPI device, or as an interrupt line for an I²C device. This may not sound like a huge array of possibilities, but remember that it's very easy to "add" extra GPIO lines by using a cheap microcontroller configured as an I²C device. Selecting Parts</h3> For our rotary encoder, we'll be using a low-profile "scroll wheel" from Adafruit</a>. It clicks in a way that feels nice, the extra buttons it includes are handy to have, and it's small enough to not add too much bulk to the device. To act as an interface between the encoder and the ESP32, we'll be using a small microcontroller. I happened to have some Microchip ATTINY816s</a> left over from a previous project and they're very easy to implement (although flashing is a slight pain), so I'll use one of those. The rest of the parts used are the same as Tangara's production faceplate; some passives, a MOSFET, an FFC connector (all available on Mouser), and a display panel (Adafruit</a> actually stocks these too!). Making a Schematic</h3> The easiest way to start on the electrical design for our faceplate is to take the existing faceplate KiCad files</a>, make a copy, then delete the parts we don't need. In this case, I deleted the touchwheel controller, the test points, and the haptic motor driver (who needs haptics when you have a real physical dial!). Adafruit provide a schematic symbol for their touchwheel and the ATTINY816 has a symbol built into KiCad, so adding them into the schematic and wiring them up is a breeze: You can obviously get much more complicated than this. There's enough room between the faceplate and mainboard PCBs (especially in the top half of the PCB) to add even something like a micro-usb port, if your choice of microcontroller supports it. It may also be a good idea to add a small LED (plus a series resistor) to one of the unused GPIO pins to help with debugging; I left this out of the schematic and PCB because I'm confident in just soldering a through-hole LED directly to one of the legs of the ATTINY; YMMV! Routing</h3> Similar to the schematic design, we can start with most of the work done for us by copying the standard Tangara faceplate PCB and then deleting the components, fills, vias, and traces that we don't need (KiCad can even do most of this for us automatically). In this case, this leaves us with just five components to place. Routing traces for each of these components is not too challenging, even for beginners, as it's all just slow-speed I²C signals and some GPIO lines. Ordering this PCB is also very cheap; I got five copies from JLCPCB for AUD$6. Soldering</h3> Soldering the board is something that comes down very much to your own preferences, skill level, and available tools. For the small MOSFET, passives, and the FFC connector, I usually lay down a small amount of solder paste by hand, place each component, then reflow the board on a hotplate. For the FFC connector especially I've found this to be the most consistent approach for hand assembly. For assembling this faceplate in particular, I constrained myself to just my soldering iron and ordinary solder. The result looks like a complete mess, but it does work! The display may seem intimidating, but there's a trick to soldering it easily: first ensure your iron is well cleaned and tinned. Then, lay down some flux over the pads. Next, line up the display's connector and solder one pad. Double check the alignment, then solder the pad on the opposite end. Lastly, go back across every pad until everything looks properly soldered. Programming</h3> The ATTINY816 I used has Arduino support, which makes putting together a working firmware very, very quick. First, I used a simple firmware that blinks an LED off and on in order to verify that my flashing setup worked. Then I altered the firmware to blink the LED differently depending on how the rotary encoder is used. After this, I added I²C support. Most I²C devices use a model where you first write a byte indicating which "register" you'd like to read, then begin a read to get the value of that register. Implementing this model with Arduino is quite straightforward: static volatile uint8_t sRegister = 0; void i2cReceive(int numBytes) { while (Wire.available()) { sRegister = Wire.read(); } } void i2cRequest() { if (sRegister == 1) { // Encoder register. Returns the number of ticks since the last read. Wire.write(static_cast<uint8_t>(encoder.getPosition() + 127)); encoder.setPosition(0); } else if (sRegister == 2) { // Button register. Returns the state of each button. // FIXME: Ideally we would set one bit per button. For this example, we // only make use of the centre button. Wire.write(digitalRead(kButtonCentre)); } } void setup() { // [...] Wire.pins(kI2cSda, kI2cScl); Wire.onReceive(i2cReceive); Wire.onRequest(i2cRequest); Wire.begin(0x1C); } </code></pre> (The above code snippet is actually almost the entire file</a>.) ESP32 Changes</h3> Finally, we need to modify Tangara's input driver to support using this clickwheel instead of the usual touchwheel. This largely involves deleting code</a>. Result</h3> I asked Robin to throw together a modified case design for me and she came up with something that feels like it should be much more beige: As you can see, it works pretty well! But looks kind of weirdly undersized! I hope you can see that from this simple approach of using a low-power microcontroller to monitor an encoder, many different faceplates are possible. You could use the same approach to implement different kinds of touch interface, physical keypads, or even a physical d-pad and buttons to give the device more of a handheld console aesthetic. Long-term, we'd love to produce more faceplate designs (in particular, I really want to make one that's just the FFC connector + display, a microcontroller, and then a protoboard-like array of through-hole pads). Measuring (Tangara's) Audio Quality 2024-02-14T00:00:00+00:00 This is a mirror of a campaign update originally posted on CrowdSupply</a>. Hi there! In this week's update, I'll be talking about the thing you have to talk about if you've made an audio device: the design and quality of Tangara's audio output. I don't like just throwing out a bunch of very technical measurements and hoping people trust they're good, so I will also give a very brief introduction to audio quality measurement in general. I'll then go through a neat little hack you can do to Tangara's audio chain to improve compatibility with cheap, sensitive IEMs. Tangara's Audio Design</h3> Tangara's audio chain is designed to perform well with both average and high-end headphones, whilst also being easy to understand and modify. We start with our digital-to-analogue converter (DAC), the WM8523 (and its recommended output filter). The DAC takes the raw digital audio samples and converts them into an audio signal. The WM8523 in particular is a fairly cheap device -- its specifications may be unexciting to folks craving the absolute best performance numbers -- but in my opinion this DAC's performance is good enough that any deficiencies with it are inaudible to human ears. Where we've chosen to spend money on high quality components is with Tangara's amplifier: the INA1620 (for nerds, it's an OPA1622 with integrated resistors). I selected this amplifier due to its fantastic features when used as an output stage: It provides a very well-matched +6 db of gain on each channel, for better compatibility with high-end headphones.</li> Its 140 mA maximum output current is more than enough for the kind of headphones you would want to use with a portable device.</li> Its output is very consistent across a wide variety of loads; many cheaper amplifiers have issues with distortion as you approach their power limits.</li> Power-on pop and click elimination and shorted output protection built-in make implementation very simple. Other amplifiers might be cheaper, but then end up needing a larger amount of supporting components.</li> </ul> By using such a sophisticated amplifier, we've made it very easy to hack on the audio chain of Tangara without compromising the quality of your output. Whether you're replacing the DAC, dampening the signal for a lower noise floor, or adding an alternate source such as an FM receiver, the INA1620 makes for a great, stable front-end between Tangara's audio source and your headphones. Now that we've examined what Tangara's audio chain is, we can talk about how it performs. AES17 is the Audio Engineering Society's standard for characterising audio devices, and the metrics that tend to be of most interest are "total harmonic distortion and noise" and the "signal to noise ratio". Total Harmonic Distortion and Noise (THD+N)</h3> THD+N is, very broadly speaking, a measurement where you play a test tone at a specified frequency, then filter that tone out of the recording. The resulting signal is a combination of any distorted elements of the test tone, plus any background noise. The difference between the level ("volume") of this resulting signal, with the level of the original test tone, represents how much of a device's audio output differs from a "perfect" reproduction. THD+N is often presented as a single number, either as a percentage or a decibel (dB) value. This presentation is quite difficult to reason about, for a number of reasons: A device's THD+N typically varies depending on the output level. For example, our WM8523 DAC's datasheet</a> shows that its THD+N at its maximum volume is slightly higher than its THD+N at 1 dB below its maximum volume.</li> The exact test setup can have a very large impact on THD+N measurements. For example, it is possible to perform the same test with an unloaded output, a 32 ohm load, or a 10k ohm load, and end up with very different numbers (and not all manufacturers disclose their exact test setups).</li> Whether or not a particular THD+N statistic is actually audible is incredibly difficult to determine; it depends on the exact nature of any distortion, as well as whether the distortion or noise component is dominating the calculation. At high volumes, the distortion will tend to dominate. At low volumes, the noise will tend to dominate.</li> </ol> I measured Tangara's THD+N using a Cosmos E1DA ADC, with a load of 600 ohms and a variety of different volume levels: THD+N</th> dBFS</th> Volume %*</th></tr></thead> 0.015%</td> 0dB</td> 87%</td></tr> 0.014%</td> -1dB</td> 86%</td></tr> 0.014%</td> -10dB</td> 78%</td></tr> 0.022%</td> -20dB</td> 68%</td></tr> 0.066%</td> -30dB</td> 58%</td></tr> 0.150%</td> -40dB</td> 47%</td></tr> 0.480%</td> -50dB</td> 37%</td></tr> 0.185%</td> -60dB</td> 27%</td></tr> </tbody></table> (*The highest 13% of Tangara's volume meter is used for digital gain.) From this we can see that, as long as your headphones reach a comfortable volume above 47% of Tangara's maximum volume (equiv. to 60% consumer line level</a>), there should not be any perceptible noise or distortion. But, what about more sensitive headphones that are only comfortable to use below this level? To address these, first we need to talk about signal-to-noise ratios. Signal-to-Noise Ratio (SNR)</h3> SNR is a measure of the difference between the loudest sound a device can produce, and the loudest noise present when not playing anything (or more specifically per AES17, the noise present when playing a -60 dBFS test tone). This is an important metric for understanding audio devices, as it gives an indication of how much listenable volume a device has before you will begin to hear the background noise inherent in every device (the "noise floor"). Your ears have an effective dynamic range of about 70-80dB before you begin to damage your hearing. Tangara has an SNR of 106 dB. But how do you compare these numbers? Does Tangara's wider range mean you won't hear any background noise? It's difficult to answer this without knowing the characteristics of your headphones; particularly the SPL (sound pressure level; usually measured in decibels per watt, or sometimes decibels per volt) and impedance (usually measured in ohms). A full explanation of these characteristics is beyond the scope of this post, but at a very high level you can put most headphones into one of three categories: "Easy to drive" headphones that are neither particularly sensitive, nor particularly high fidelity. Most non-audiophile headphones are in this category.</li> "Easy to drive" headphones that are highly sensitive, but also high fidelity. Most IEMs (especially the cheaper ones) are in this category.</li> "Difficult to drive" headphones that are less sensitive, but high fidelity. This category includes the bulk of what you might call "high-end" gear; everything from fancy studio headphones to expensive planar IEMs.</li> </ol> The second and third categories are the most problematic, as they have contradictory requirements. Highly sensitive headphones need only a tiny amount of power to produce sound, which makes them susceptible to high noise floors. To support these devices, it's best to use your available SNR at the low end (by applying damping, then running your DAC at a higher volume), in order to keep the noise floor below an audible volume. "Difficult to drive" headphones, on the other hand, will rarely pick up a device's noise floor. They may, however, struggle to produce sound at a loud enough volume to be well audible. To best support these devices, it's best to use your available SNR at the top end by applying gain, so that you have enough headroom to increase volume before you run out of power. Ultimately, when designing a device like Tangara, you have three options for what to do with your dynamic range: Use it for top-end, giving people with high-end headphones the best experience.</li> Use it to lower your noise floor, giving people with more sensitive headphones the best experience.</li> Use a substantially better DAC, increasing the cost of the device.</li> </ol> For Tangara, we chose option one. First, because we didn't want to further increase the cost of the device with an expensive DAC that most users won't get value out of. Second, because lowering the noise floor post-hoc is a much easier modification to make than adding more amplification. A Hack for Budget IEMs</h3> There is a whole market these days of cheap, high-fidelity 'in-ear monitors' (IEMs; they're fancy earbuds). You can typically find them for $20-$40, and they sound great. The main downside of this style of headphone is that they typically are overly sensitive; often able to pick up and make audible the noise floor of even very good DAC implementations. You will hear this as a very quiet 'hiss' or white noise during quiet pieces of music. It is difficult to provide a good experience for this kind of device without either spending more money on a more advanced DAC chip, or adding complicated circuity to modify your amplifier's gain (both upgrades that are wasted when paired with higher-end headphones). Tangara's noise floor is audible through such devices; although it's quiet enough that most of the team could only hear it when I coached them into what to listen for and then played back pure tones through various other devices. It's therefore probably good enough for you. If you're a real audio head, and this isn't good enough for you, then soldering two small resistors is an easy mod that will shift the whole signal down. You can then listen at a higher volume, without an audible noise floor. Referring back to the schematic for Tangara's audio chain, pay attention to the region between the DAC's output filter and the amplifier's input. This is a tremendously good location for implementing all kinds of modifications. In this example, we're going to add some small resistors from the signal path to ground. This will attenuate the entire signal -- including the noise floor. We can then set the volume level higher to compensate for this, resulting in audio output that is still loud enough to listen to, but with greatly reduced background noise. This is the same principle as devices like the iFi iEMatch</a>. However, because Tangara is an open source device constructed with hand-solderable parts, it's very practical to implement this solution completely internally. This avoids a bulky extra dongle, and also eliminates any chance of affecting the frequency response of the output. In our case, we're going to solder one 0603 resistor per channel, on top of C15 and C6. This creates a voltage divider together with the DAC's output filter resistor and the input impedance of the amplifier (which I've simplified into one resistance value. Don't worry about it!) We can then make an equation to find the damping amount provided by various resistor values: 20log10(x / (525 + x))</code> Resistor</th> Damping (approx)</th></tr></thead> 650</td> -5dB</td></tr> 250</td> -10dB</td></tr> 100</td> -16dB</td></tr> 60</td> -20dB</td></tr> 16</td> -30dB</td></tr> </tbody></table> In my case, I wanted to use a pair of Salnotes Zeroes. These felt comfortable at around 30-40% volume, so I used a 100 ohm resistor to bring the noise floor down by 16 dB. Soldering this together is fairly easy as SMD work goes, since we can place the new resistors directly on top of the capacitors: Redoing my THD+N measurements with the mod in place, I got the same results as earlier, except that now my device's "0dB" point is a bit quieter than it was earlier. Finally, testing with my IEMs, there is now dead silence (to my ears, anyway) during very quiet playback. Conclusion</h3> I hope this update has been informative about not only Tangara's audio quality, but also discussions of audio quality in general. There is no perfect solution to high quality audio, but I think we've designed a device that strikes a good balance between quality, cost, and upgradeability. A Deep Dive Into the Design of Tangara's Touchwheel 2024-02-07T00:00:00+00:00 This is a mirror of a campaign update originally posted on CrowdSupply</a>. First off, thank you so much everyone for your amazing initial response! We hit our funding goal within half an hour of campaign launch! Over the next few weeks, we'll be releasing a series of updates showcasing particular aspects of Tangara's design. The first of these is written by Daniel (@ailurux), and will cover a feature many of you have been curious about: the touchwheel In this update, we'll go through the history of why we chose a capacitive touchwheel for Tangara, how the current design works, and what it can do, as well as some resources and tips for incorporating this kind of touchwheel into your own projects. To Begin, a Bit of Background...</h3> Tangara's input hardware has changed a lot over the last year of development. Whilst Tangara's current design may be nostalgic for fans of the original iPod, our original concepts were actually much more inspired by cassette tapes. I've long had an affinity for cassette tapes, and there is some overlap between my love of tapes and my excitement about making a physical, distraction-free music player that can't suddenly decide you don't have the right to listen to your music. The notion of using a circular screen was short-lived. Whilst it's absolutely possible, and circular TFT screens are available and fairly cheap, it just wasn't functional to reduce the screen real-estate by about a fifth just for the aesthetics. But already, a wheel was feeling like a compelling input method. We made a few prototypes that used a rotary encoder with a 3D printed wheel or knob, but we realised this method was going to add a lot of complexity and bulk to the case, especially if we wanted a push-button as well. Our next idea was to use an angular sensor, as they have a lower profile and can detect position as well as rotation. However, these components don't come with push buttons, often don't have a full 360 degree operating angle, and still required a separate part – one with even tighter tolerances. With neither of those two initial ideas working, we went back to the drawing board and came up with a bunch of different ideas. We had a pretty good idea of what our requirements for the input were at this point: we wanted something low-profile, affordable, with some kind of haptic or tactile feedback, and with enough flexibility to support multiple methods of use. The most promising idea was to use a circular trackpad module, like the Azoteq ProxSense or Cirque Glidepoint trackpads. These are very low profile, high resolution trackpads that come in a variety of sizes and seemed ideal. We ordered a few of these modules and built some prototypes to test. Unfortunately, we discovered the Azoteq ProxSense range requires an additional, rather-costly flashing tool (and Windows-only software) to unlock its full functionality, with only basic gesture controls available by default. Our prototypes with the Cirque Glidepoint trackpad worked better, but we were worried about the cost and availability of these modules for smaller manufacturing runs. We then considered designing and manufacturing our own custom trackpad module for Tangara. Whilst researching this, we found a design guide</a> on capacitive touch sensors that described a wheel sensor design for capacitive touch electrodes. This design would allow us to build a capacitive touchwheel directly onto Tangara's faceplate. Not only would we be able to do this with just one affordable IC and three fancy-shaped electrodes, but it would also be extremely low profile, give us the flexibility to customise the size and shape, and even leave us room for a middle button and haptic motor. We were really excited by this and so we set to the task of making a prototype. How (Not) to Re-Invent the Wheel</h3> The aforementioned design guide is a really great resource on how this kind of capacitive touch wheel works, and I'd highly recommend starting there. The guide lists a few different arrangements of electrodes for different capacitive buttons, sliders and wheels. One way to make a capacitive touch wheel is to place many electrodes in order in a circular arrangement and when one of these electrodes detects a touch, based on the known order of electrodes the approximate position of the finger on the wheel can be determined. This is actually how the iPod's click-wheel works. Another way is to use just three electrodes with an interpolated shape, so that as the finger moves around the sensor, the signal moves smoothly between electrodes and we can use this to determine roughly where the finger is on the wheel. We were pretty excited to try out the interpolated wheel design, the only thing left was to figure out how to create that tessellating, radial zig-zag shape. I watched Jacqueline try to trace the image from the design guide in KiCad, manually clicking each point along the path for 15 minutes or so, when a misclick caused the path to be lost and she paused for a moment, sighed, and then started over again. I felt a need to jump in at this point and said I'd create the path as an SVG and send it to her. I knew I wanted to programmatically create this shape, with the ability to tweak the parameters so that we could quickly iterate on the design if needed. I've previously used JavaScript to generate SVG files, so I reached for that here. I found this decade old blog post</a> which was really helpful. It details how the author solved this problem with OpenSCAD by using chain-hulls in place of arbitrarily defined paths. As SVG does allow for arbitrarily defined paths, I could use the author's first idea of generating a triangular path around an arc. The basic process is to generate the shape using polar coordinates, which, instead of defining a position from the origin in terms of X and Y, defines a point by its distance and angle from the origin. This allows us to move outward from the center in an arc, and we can switch the direction by changing the angle or draw a straight line outwards by changing just the distance. </iframe> You can access our SVG tool here</a>, along with the code that powers it, all of which is visible in the page source. The SVG path does usually need some manual processing before it can be used in a PCB, but this should hopefully be a good starting point for anyone looking to incorporate this kind of touch sensor into their own projects. I think it would be really cool to see more projects using it! We were super-impressed with the performance of the final result. With just three electrodes and a cool form-meets-function design, we're able to offer a touch input that feels really responsive and nice to use. This design can also support other input methods, such as a directional pad mode, or even just using the wheel as a large button. We've even experimented with using the angular detection to control the pitch of a basic square wave synthesizer, which produced fun results. Final Thoughts</h3> Overall, we're really happy about what we've come up with for Tangara's input. It's space-efficient, versatile, and effective. We think the touchwheel is a great fit for this kind of device, but because we've implemented it on a separate PCB, it's also easy to replace with other input hardware. In a later update, Jacqueline will be showing off a custom faceplate featuring a rotary encoder and buttons. All Aboard! 2024-02-01T00:00:00+00:00 And we're away!</a> Tangara is a cool, hackable, ESP32-powered music player that provides high-quality audio, long battery life, and a design that's easy to customize, repair, and upgrade. If you read our pre-launch page, you may be delighted to learn that Tangara has gotten even better since then! Standby battery life is now much longer, and we've rewritten our entire user interface in Lua, for easier customization. We'd love for you to give our campaign page</a> a look, and consider backing Tangara! ps: here's a picture of jacqueline's cat

What Is Lua?</h3>
Lua is a scripting language similar to Python or JavaScript. It's a great first language as it's beginner friendly, has a lot of online resources, and is used in many different types of applications, especially in the worlds of game development and modding.</p>

ESP32 Changes</h3>
Finally, we need to modify Tangara's input driver to support using this clickwheel instead of the usual touchwheel. This largely involves deleting code</a>.</p>

A Deep Dive Into the Design of Tangara's Touchwheel

All Aboard!

cool tech zone

Pre-production Progress

Lua Support

Creating a Custom Faceplate

Measuring (Tangara's) Audio Quality

cool tech zone

Pre-production Progress

Firmware Development</h3> In amongst the pre-production work, we're also making steady progress on improving Tangara's firmware. Most recently, we've made some substantial performance improvements and implemented a few more important features, including seeking support and gapless playback.</p>

Thanks Again!</h3> That's all we have for this week. Thanks so much to everyone again for your support!</p>

Lua Support

What Is Lua?</h3> Lua is a scripting language similar to Python or JavaScript. It's a great first language as it's beginner friendly, has a lot of online resources, and is used in many different types of applications, especially in the worlds of game development and modding.</p>

Creating a Custom Faceplate

Measuring (Tangara's) Audio Quality

A Deep Dive Into the Design of Tangara's Touchwheel

All Aboard!

Firmware Development</h3>
In amongst the pre-production work, we're also making steady progress on improving Tangara's firmware. Most recently, we've made some substantial performance improvements and implemented a few more important features, including seeking support and gapless playback.</p>

Thanks Again!</h3>
That's all we have for this week. Thanks so much to everyone again for your support!</p>

What Is Lua?</h3>
Lua is a scripting language similar to Python or JavaScript. It's a great first language as it's beginner friendly, has a lot of online resources, and is used in many different types of applications, especially in the worlds of game development and modding.</p>