Scope

OBD-2 is a standard that defines the following:

• A connector (DLC == Data Link Connector) to connect a “test equipment” to your car, which for recent enough cars connects to a CAN bus in your car.
• A (mostly) car-independent protocol stack on top of CAN that has access to both real-time and snapshot data in your car’s computer system.

Other stuff defined does not matter if your car is recent enough.

CAN bus

• A CAN bus (1 twisted pair) is shared by many nodes branching off it.
• Messages are broadcast on the bus. Everyone sees everything (but may not deliver every message; there can be software and/or hardware filters).
• Message consists of an ID (either 11 or 29 bits), and 0 to 8 bytes of data.
  • A message with 11-bit ID is also called a “Standard Frame”
  • A message with 29-bit ID is also called an “Extended Frame”
• Arbitration (what happens when 2 nodes are both attempting to send a message) is deterministic, based on the ID of the message: Lower numerical value ID wins. This means the ID of a message is also its priority.

The Protocol Stack

CAN messages are denoted 012 # b0 b1 b2 b3 b4 b5 b6 b7, where:

• 012: ID
• b0 to b7: data

Numbers in code blocks are assumed hexadecimal unless declared otherwise.

In the following sections we will dissect the OBD-2 protocol stack from CAN ID to each byte of the payload.

Request and Response IDs

A CAN bus supporting OBD-2 (one that is connected to the DLC) has 1 master node — the test equipment, and at least one slave node — the ECU(s). Master requests information by sending messages with IDs in a specific range. Slaves respond with corresponding IDs. The IDs are defined as follows:

So just looking at the address space, there can be at most 8 slave nodes if Standard ID is used; 256 if Extended. However, OBD-2 allows at most 8 regardless of which ID format is used. In fact, everything else is equivalent regardless of which ID format is used (some cars support only one and others both though), so WLOG, we can assume that Standard ID is used.

Example (omitting data for now):

• Master transmits 7DF # ... (broadcast request)
  • Slave 0 responds 7E8 # ...
  • Slave 3 responds 7EA # ...
  • Slave 7 responds 7EF # ...
• Master transmits 7E3 # ... (request for slave 3)
  • Slave 3 responds 7EA # ...

Transport Layer, the Short Story

The length of an OBD-2 message (regardless of request or response) is 0 ~ 4095 Bytes. The length of a CAN message, on the other hand, is 0 ~ 8 Bytes. This means one OBD-2 message may not fit in one CAN message. Therefore fragmentation is needed, and the OBD-2 transport layer provides this functionality.

If OBD-2 message length ≤ 7, then the CAN message consists of 1 byte of OBD-2 message length, followed by the OBD-2 message payload. Length of the CAN message can be longer than (1 + length of the OBD-2 message) — trailing bytes after (1 + length) are simply ignored.

Examples:

• 7DF # 02 01 00: length = 2, payload = 01 00
• 7E0 # 06 41 00 B6 3D A8 12 55: length = 6, payload = 41 00 B6 3D A8 12 (notice the last byte 55 is NOT included in the payload)

We will cover the (length > 7) case later.

Service ID + Parameter ID

Valid OBD-2 messages always contain at least 2 bytes.

First Byte

• bit 6: 0 => request, 1 => response
• bits 0 to 5 (inclusive): “Service ID” (like a category, or a database table name; blame naming on historical reasons). This is matched between request and its response.

Examples:

• 09: request, service 09
• 49: response, service 09
• 1E: request, service 1E
• 5E: response, service 1E

Second Byte

The entire second byte is the “Parameter ID” (like a key in a database table). This is matched between request and its response.

Semantics

The Service ID and Parameter ID together form an address space. A part of this address space has (car-independent) standard defintions. Wikipedia has an incomplete list for it. For car-specific Parameter IDs, the third byte could also be considered a part of the Parameter ID, but WLOG it can also be treated as the first byte of the “real payload”.

Simple example:

• 7E0 # 02 01 0C: request, service 01, parameter 0C
• 7E8 # 04 41 0C 2E E0: response, service 01, parameter 0C, data 2E E0

The request is for vehicle engine RPM. Payload is decoded as 0x2EE0 / 4 = 3000 RPM.

Longer example:

• 7DF # 02 01 00: request, service 01, parameter 00
• 7E8 # 06 41 00 B6 3D A8 12 55: response, service 01, parameter 00, data B6 3D A8 12 55

The request is for a bit vector of supported PID in service 01, parameter 01 to 20 (inclusive). Meaning of the payload (B6 3D A8 12 55) is left as an exercise.

Transport Layer, the Longer Story

One example is to read the VIN (Vehicle Idenfication Number), an ASCII string that is obviously longer than 7 bytes. This is defined in standard as service 09, parameter 02, so:

• 7DF # 02 09 02: request, service 09, parameter 02
• 7E8 # 10 14 49 02 01 53 48 48: ???

If you squint hard, 49 02 looks like response for service 09, parameter 02, and 53 48 48 is ascii "SHH" which is a prefix of my VIN. Where is the rest? Recall that the first byte of short OBD-2 messages is its length: 00 to 07. Anything else means we’re dealing with a long (fragmented) message.

To decode part of a long message, first look at the first nibble (higher 4 bits of the first byte):

• 1: first CAN message of a fragmented OBD-2 message
  • the next 3 nibbles (lower 4 bits of the first byte, concatenated with the entire second byte) is the total length of the OBD-2 message (in this example, 014 = 20)
  • all the rest are the first bytes of the OBD-2 payload
• 2: following CAN messages of a fragmented OBD-2 message
  • the next nibble (lower 4 bits of the first byte) is a rolling counter (1, 2, 3, …, F, 0, 1, 2, …)
  • all the rest are part of the OBD-2 payload

Also, to prevent overflowing the receiver, by default the sender only sends the first CAN message, then starts waiting for a flow control message back from the receiver. Details can be found in the Wikipedia article on transport layer, but most commonly, sending 30 00 00 instructs the sender to proceed sending rest of the packets at once. Continuing with the example:

• 7E8 # 10 14 49 02 01 53 48 48: long message, length = 014 (20 bytes), first bytes of payload 49 02 01 53 48 48
• 7E0 # 30 00 00: continue to send, all remaining frames, no separation
• 7E8 # 21 46 4B 38 47 37 35 4A: more bytes of payload 46 4B 38 47 37 35 4A
• 7E8 # 22 55 xx xx xx xx xx xx: more bytes of payload 55 xx xx xx xx xx xx (data redacted for my own privacy

Put all fragments together: 49 02 01 53 48 48 46 4B 38 47 37 35 4A 55 xx xx xx xx xx xx which matches the declared length of 20 bytes. This is service 09, parameter 02, and the data decoded as ASCII reads “SHHFK8G75JU……” which is my VIN.

P.S.: Actually my vehicle only supports extended ID (request 18DA10F1, response 18DAF110); again it does not make a difference in data.

Preword: If you only care about the techy bits… Scroll all the way down

First, let’s set some expectations…

^{Source: https://www.reddit.com/r/starterpacks/comments/b1xuzw/learning_manual_transmission_starter_pack/}

How I Learned to Drive, At All

Way back when I was a tiny kid, my dad somehow got to drive a Beijing Jeep for a couple months. It looked like (admittedly a badly beaten copy of) this:

^{(By Swoolverton – Own work, CC BY-SA 3.0, Link)}
And this:

One day he decided it was high time for me to learn how to drive. Oh how I wished he did it a few years later, as I needed to really stretch to even push the clutch pedal fully in. That obviously didn’t go well, and for the next 10+ years, never once did I felt the need to learn how to drive at all…

Until early 2016, when I was a couple months away from my first day job in the U.S of A. Being spoiled by the great public transportation combined with cycling in Pittsburgh PA (plus my roommates giving me rides now and then, ahem), I came to a panic when I realized that in most places of this country, it doesn’t just fly without me being able to drive around!

So I signed up for a driving school. These schools nowadays only teach automatic, while my peers in China all learned the 3-pedal row-your-own stick shift just like the Old Good Beijing Jeep. At that time though, I seriously dismissed manual transmission as pointless — moving some levers following some rules sounded like grunt work — exactly the kind that a computer is really good at doing, no?

^{(spoiler: actually yes, but that’d be an entirely different topic}

Fast Forward Towards Winter 2018

*kkklink*

*thud*

*klank*

^{(nope — I didn’t just pose for the pictures. I got to enjoy every one of these}

…Wait a sec. What happened?

The First Contact

One evening after finishing up work late (at said day job), my mentor and I decided to eat out. Citing car-pool benefits, he offered me a ride in his then-brand-new 2016 Subaru BRZ:

^{(yadda yadda wrong year, press pic, this is kouki and his was zenki, but They All Look The SameTM ahem)}

The dinner was good, but heck, what an eye-opening ride. I had never once took a ride in a sports car that was driven as one. He took the corners so much sharper than I ever dared to do in my run-of-the-mill family crossover a.k.a. a Forester, even in light rain, yanking me violently left and right. And yup — that alone flipped a switch within my mind. I immediately begged him to teach me the basics, and he kindly agreed. Later that week, he picked me up, drove to an empty parking lot, and we switched places.

20 Or So Stalls Later…

That was hard! Before I came I thought I already memorized the sequencing from a few YouTube videos (just search along the lines of “how to drive stick shift” I guess), but it seems that just starting from stand-still was already making me bang my head on the wheel (figuratively). Surely enough I had never been good at hand-foot coordination (which BTW made it almost impossible for me to play basketball without tripping myself), but seriously, which part of “slowly releasing the clutch pedal” did I not understand?!

Eventually though I realized that there were some fine prints, for this very BRZ at least:

1. Most of the clutch pedal’s travel doesn’t do shit. There is a small window where all the transition happens. So “slowly releasing the pedal” really means “slowly releasing the pedal in that small window“.
2. When the clutch bites, I need to give it a little bit more gas, preferrably just enough to keep the engine rotating at a steady RPM from 1500 to 2000.

For #1, I knew that given enough practice, muscle memory would naturally take care of the fine movements. #2 is in theory just me doing a PID feedback control loop (i.e. keep the engine RPM steady against varying load), but the pain point was that it worked exactly against the muscle memory built when learning how to drive an automatic — that much gas would already get an automatic to take off!

That said, knowing the problem was already 90% towards solving it. By the end of the session, I finally got a hold of starting somewhat consistently on flat ground. Since upshifting and stopping were nowhere as hard as that, these combined already allowed me to drive normally back to the garage (even parking it somehow). Phew!

^{(upshifting smoothly was far from easy though — in fact I’m still working on pulling off a buttery smooth 1 to 2 perfectly every time}

Revival: A Test Drive

Time was Summer 2018 and I moved to the SF Bay Area to work on autonomous driving tech (shameless off-topic plug: We’re Hiring! Ping me on LinkedIn/Twitter!), and somehow that rekindled my interest in becoming a better driver myself. On a whim, I asked my local Subaru dealership if I could test drive a stick shift while I waited for my regular car service. Surprisingly they actually put me on the driver’s seat of a red STI — you know, the flashy one with a hood scoop and the B.F.W.^TM:

I was pretty nervous initially, but as I drove I gradually realized (in this order):

1. I kept all my muscle memories back then on my (ex-)mentor’s BRZ.
2. Said memories actually transferred well enough to a different car (admittedly still a Subaru).
3. Actually driving a stick shift might not be out of my reach as I once thought. In fact I was just driving one alright!
4. A test drive is far from enough to cover the gap from where I was to where I want to be.

At this point I basically declared driving a stick shift as well as an automatic The Next Challenge I Must Tackle. Problem is, I don’t have access to a stick shift anymore. I turned my eyes to a rental car, which would give me enough freedom to pick off where I left when in my (ex-)mentor’s BRZ. However it soon became painfully obvious to me that traditional rent-a-car companies don’t really keep stick shifts in their fleets anymore. Welcome to the U.S. of A! What now?

Turo Comes To Rescue

Search “rent manual car” and there popped out Turo (full disclosure: my affiliate link gives both you and me $25 credit when you book the first trip), a service that connects you to other people short-term renting their cars. What’s different about it though: people do list their stick shifts on it, and you can filter the list to show only stick shifts! After some search I booked a 5MT Jeep Wrangler (citing childhood memories — anyone still remember the Beijing Jeep?), but that got canceled due to circumstances, and I immediately set my eyes on the most suitable car for this: a 2013 Subaru BRZ.

Turo does ask you to confirm your ability to drive a stick shift. Yadda yadda, the classic catch-22 here. But — here comes the trick — this is The BRZ we’re talking about, the very same model on which I developed my first muscle memory on! The trigger was promptly pulled. That said, I was fully aware that I needed more practice before I could declare myself truly road-worthy, and that could only mean one thing at this point. Picking up from exactly where I left, I pulled myself into…

An Empty Parking Lot (Part 2)

Phew. Time to really grind the skills to clear all doubt. It quickly became painfully obvious to me that BRZ is both terrible and wonderful as a car to learn stick shift on: It’s extremely precise to the point that it punishes you for any small mistake you make, and the feel-less clutch pedal made me wonder if it was adversarially designed to confuse my muscle memory. I groaned and looped the parking lot again and again, practiced hill starts (it lacks hill assist so I pretty much had to use the hand brake) and even parallel parking (fortunately this one does have a backup camera). As I gradually improved both consistency and coverage of the individual tasks, I decided to check my progress outside the lot…

And what route works better than the ones used to test our autonomous vehicles in Fremont! A few loops later, I knew for sure — proudly — that I can drive a stick shift around.

Reaping the Fruit

With solid confidence, I took the originally planned trip to the beaches of Santa Cruz, enjoying the Touge of CA-17 and CA-9 along the way. And what’s better reward at the end of the day, than a good bowl of Ramen? Driving the BRZ from Santa Cruz to San Mateo for said good bowl of Ramen!

Since then, I have had the chance to experience quite a few different stick shift cars — not just the ones above, but also some Initial-D-era classics in Hakone, Japan: RX-7 FD3S, S2000 AP1, and Skyline GT-R R34. The more I drove, the more I came to appreciate the unique exposed character of stick shift cars, and became firmly convinced that a stick shift can and should be my daily driver. It wasn’t hard for me to pull the final trigger and trade my Forester for My First Own Stick Shift:

^{My stick-shift Civic. Dammit STFU you car junkies — just Civic, m’kay? I still get judged a lot tho when ppl see the B.F.W.TM :thonk:}

As for the circuit boards tucked away in the phone tray… Actually that’s what I really wanted to write about in the first place, only ending up with the compulsion to introduce the background of it… which became this entire post

One day (2018-01-31 17:30) when I came off work at L. C. Smith Tower, I wandered into the telephone switch operator showroom out of curiosity, and there I found a working Underwood No. 5 desktop manual typewriter, apparently kept borderline-maintained for visitors to play with:

Since I work here, I can basically practice typing every day. One day I met a lady who kindly pointed me to Don, a collector of typewriters in Bremerton, WA. When I visited him I showed him the artists’ impression of the machine our Heroine learned how to type on… and it turned out he had almost exactly the same model in his collection!

And it now has a new home on my desk:

This is an Underwood 4-bank portable, S/N 4B22419. Here are some of its siblings:

• 4B21614
• 4B29225 — closest to this one
• 4B40409 — 5 spokes on spool (anime has 4)

Take note of its distinctive shift lock key design: a metal tab (instead of an actual key) above the left shift key. All other key features match the anime appearance almost perfectly…

For now, gonna re-learn how to type the old-fashioned way

Apparently I have some sort of PTSD now, after so many iterations in vain trying to get TPS65131 to behave. But without a bipolar power supply, this project cannot be considered complete, so I started finding alternatives. Well, I don’t really have to find, because when I did my teardown analysis of CEntrance DACPort Slim, I already documented its bipolar power supply:

Back then I didn’t fully understand what it was, so I asked about this on Electronics StackExchange. But of course it is not a hack that happens to work — it’s an established way to generate an “auxiliary” negative voltage from an existing boost circuit:

• TI app note
• LT1930 datasheet
• LT3467 datasheet
• LT application note
• Someone using it for his guitar pedals

In fact, LMR62014 as used in DACPort’s circuit is a pin-compatible part to LT1930. Apparently this works well, at least for stable symmetric loads. In my project, all analog rails are powered throughh LDOs, and the load is indeed nearly symmetric, as measured when powering off my bench supply.

PCB

With the TPS65131-fiasco still haunting me, I decided to go safe this time. Component picks:

• Main boost inductor: A big one — TYS6045100M-10 at L×WxH = 6×6×4.5 mm. It boasts way higher saturation current and way lower DC resistance than I could possibly need. I think a 4×4 mm profile should do just fine.
• Rectifier diodes: Any SOD-123FL Schottky will do; the less forward voltage the better. I used MBR230S1F-7 which I already have in stock.
• Feedback: 0603 1% resistor; 0603 5% C0G/NP0 capacitor.
• 4.7 µF ceramic caps: 0805 5% X5R/X7R
• CC1/2: Tantalum “B” bulk output cap. Aluminum is fine too.
• FB1/2 (not shown on schematic): 0805 ferrite bead. Short them if you are lazy.

This is a reusable module, so I shared it on OSHPark. Note that it is deliberately not breadboard-friendly (but close enough) so that it fits the DAC main PCB.

Test

It works!

Positive: (using 10 mV/div due to Rigol firmware bug messing up vertical measurements)

Negative: (you can see the messed up average measurement under 5 mV/div, but trigger pos is correct)

I think these are already good enough for powering op-amps since they have reasonably decent PSRR (at least in audio freq range). That said, I am still keeping the LDOs in between just to be safe.

Conclusion: End of the Beginning

I now have this copy plugged into my DAC-amp prototype (v4.2):

Not suprisingly it works. And at this point, all basic issues have been addressed. As I merge the DC-DC and LDO halves of the power board, the last remaining unsightly jumper wires will go away…

2017-04-07 EDIT: Merged power board arrives. Works beautifully.

Does this mean the project is completed? Well, recalling my original goal: “To achieve good objective performance within reasonable budget”. I have not even measured the performance! But while my 8-bit scope is good enough for debugging, for proper measurement I need an audio analyzer, which I do not have and cannot afford. Without precise measurement, any further development would be blind at best — a complete waste of time. So sadly at this point I have to stop working on this project…

…and listen to some good music

I will try to release design files after some extra field testing. Stay tuned.

2017-04-08 EDIT: Design files released in my Hackaday project page.

Problem

I have always had problems incorporating switching regulators in any design, and this project is apparently no exception. I blame my ignorance — totally clueless what to measure and what to expect.

Anyway, here is the schematics for TPS65131, almost blatantly copied from the reference design in its datasheet:

It doesn’t work as intended, as its power rails oscillate at ∼1 kHz, like this:

2 Vpp, seriously?!

You might wonder how on earth does the whole system actually work. Well, because I picked some really good LDOs. Here’s what happens after them:

Note that the waveform is almost at the noise floor of my scope (using 5 mV/div, the lowest setting). Even taking the measured Vpp at face value we have 2.16 V to 4 mV, which is −55 dB of PSRR. So of course it works, if you don’t mind the inductor being driven by that 2 Vpp 1 kHz ripple triangle wave, radiating like crazy into, say, your headphone cable…

Problem

I don’t have proof, but I think it’s caused by inductor saturating. Comparing my parts choices to that of the reference design, the only visible difference is inductor choice.

So this time I’m going to try use a big inductor that saturates beyond the current limit of TPS65131.

(TBD)

In the interim update post I posted the plan for integration into 2 boards: A 2-layer power board, and a 4-layer main board. Actually I have had a good copy of the main board for quite a while:

Story for the power board is not as good though. In the beginning I screwed up on part of the schematics. Then I mis-soldered quite a few 0.5 mm pitch QFNs. After some footprint fine-tuning, I finally made a good copy:

Mount it on the main board, and voila — the system is finally standalone and working!

…with one small but annoying flaw:

DC-DC Audible Noise

While the power outputs are all clean thanks to the stronk LDOs, the DC-DC converter constantly emits a moderately-pitched audio noise.

Schematic:

I have some hypotheses why this is happening, but since I am not that familiar with DC-DC converters, my guess might be totally off… Anyway here they are:

• I disabled the so-called “power saving mode” of the DC-DC chip, out of fear that they increase output ripple.
• The current rating is too big for my application, and the actual current consumption might be near the minimal stable current limit, although I have not found such a description in the datasheet. Perhaps use TPS65131‘s little cousin TPS65130?
• The particular inductor I chose resonates (mechanically).

Fortunately all of these are relatively easy to verify through an extra PCB iteration. Time to get to work…

2017-03-09 EDIT:

• All 3 issues listed above were implemented on an updated PCB, but audible noise persists. The sound is smaller though.
• The ripple on DC-DC output rails is still coupled through LDO and DAC, trashing my SNR.

2017-03-11 EDIT:

Out of curiosity I opened up my DACPort Slim again. Surprisingly (at least to me) its DC-DC section emits similar levels of audible noise. I guess this is an inevitable downside of using inductor-based DC-DC.

While I might accept the audible noise as is, I still want to address the analog power rail noise issue. It appears to me that V_DAC is the weakest link, since DAC does not have as good PSRR as op-amps. Once the noise leaks onto DAC output, PSRR in later stages does not matter anymore, as the damage has been done. Back to design table then…

Months into the project and I was still amazed at the lack of availability of a class of ASICs: USB-I²S bridges. Well I just lied — if you are fine with USB 1.1 (12 Mbit/s, the so-called “Full Speed”) and USB Audio Class (UAC) 1.0, which severely limits your (bit depth × resolution × channel count), then there are countless chips out there, both ASIC and general-purpose microcontrollers, at various level of integration. You might not be able to source prototype quantities from Digikey/Mouser (e.g. the CM103 chip on the cheap dongle I bought on Aliexpress, or various offerings from Sabre/ESS/Via), but they’re there. Some even support 24 bit 96 kHz. A lot of them derive their audio clocks from built-in XO and PLL, sometimes shared with USB, which leads to poor quality…

So what do I care about then?

Spec

• USB Audio Class (UAC) 2.0
• ≥ 2 output channels
• 24 bit 192 kHz support
• external master clock option

Well, I betrayed myself by asking for 192 kHz, as in the very first post I explicitly said 96 kHz is way good enough. The reasoning: My DAC chip already supports 192 kHz, and I don’t want the digital source to be the bottleneck. So even if I end up using 96 kHz for best analog performance, I want the system to be capable of operating at the max data rate supported by the DAC.

MCU Picks

UAC 2.0 means USB 2.0 High Speed (480 Mbit/s). There are only a few budget and/or low-footprint choices:

• Atmel SAM3U: Other than USB, this is just yet another Cortex-M3 chip (which is a good thing!). However it comes in bulky 100-/144-pin QFP/BGA packages.

• Cypress FX2LP (CY7C68013/4/5/6): 8-bit 8051-derivative core (similar to Dallas Semiconductor DS80C320) running at 48 MHz. Turtle slow, few peripherals, but it comes in a tiny 56-pin QFN package (although it does require an external I2C EEPROM, available in TSSOP8).

• XMOS XS1-U8 series: Hugely popular in the “audiophile” market. It is one of these “many small cores” niche market MCUs. Didn’t do much homework though — will explain later.

While I am very comfortable with Cortex-M3 due to past experience, its footprint is way too huge for the project at hand, so I went for CY7C68013. In fact I had known this chip for quite a long time, as it frequently appears in the BOM of budget FPGA-based designs that provides USB connectivity. Heck — even Saleae Logic is (yet another) Spartan 6 + CY7C68013! There doesn’t seem to be a good standalone minimal system board for it though, so I quickly made one:

I intended to attach a small CPLD for I²S output, but still there is a lot of work, especially when I have to write 8051 (!) firmware for CY7C68013 (yes, more annoying than Verilog for CPLD!) that sets up the whole UAC 2.0 streaming…

How About Easier, Sensei?

Well, the focus of this DAC project is, of course, the DAC itself and the associated analog circuits. USB-I²S is more like a necessity — an inevitable chore I have to bolt on to make the system complete. So I kept looking for ASICs, and I found one that is close enough: XMOS XHRA-2HPA. It even comes with a reference design that does exactly what I want (albeit with a crappy all-integrated DAC)! This chip is clearly based on a normal XMOS XS1-U8 with a custom bootloader, but the similarity ends here — it loads encrypted (!) firmware from external Quad SPI flash, and is therefore completely locked down (not user-programmable), so by duck typing it is an ASIC. On the other hand, I don’t have to program it. Sounds like a fair deal. While the reference design was fully integrated, I instead isolated the XHRA minimal system and made a PCB.

XHRA Hiccups — the SPI Flash Fiasco

What was supposed to be a turn-key solution turned into a prolonged attrition debugging warfare lasting well beyond 2 PCB turnarounds, just to make this thing $profanity-ing boot and enumerate! And each time, the culprit turned out to be that innocent-looking, friendly-packaged, 8-pin SOIC Quad SPI Flash.

Quick TL;DR:

• There is a whitelist for SPI Flash ID bytes.
• The “correct” SPI flash does not have built-in HOLD# pull-up resistor.
• SPI clock runs at 2.4 MHz at first, but eventually switches to 100/6 = 16.667 MHz .
• The “nibble ordering” mention in the datasheet is misleading.
• $profanity Bus Pirate.

Apparently, being “pin and instruction compatible” is not good enough — there is a whitelist for IDs. If the wrong ID is returned, the chip drops dead. There is one vague mention of this on the datasheet, and I only realized its true meaning after I dug into a logic analyzer capture run and actually inspected the SPI transfers. Turned out that right before the chip fell silent, it had repeatedly sent command 0x9F over SPI — “read chip ID”. D’oh!

The reason I didn’t look at the logic analyzer output? 16 MHz is too fast for my old good Saleae Logic 16 streaming 6 channels at its max 50 MHz sample rate (because Nyquist). Miscaptures were frequent, but I was lucky that run.

Then there is another misleading information from the datasheet stating that the SPI flash needs to store the least significant nibble (4 bits) of a byte (8 bits) first, which sounds as if before programming we need to manually swap the nibbles for all the bytes… Turns out you don’t have to do anything other than following the datasheet, which clearly transfers MSnibble before the LSnibble on the 4-bit SPI bus. D’oh!

I once wrote a blog post on SPI flash programming using Bus Pirate — and of course I was trying to program this. Eventually I figured out that Bus Pirate is too unreliable (on top of slow) for flash programming, so I bought a dirt cheap dedicated flash programmer on Aliexpress (again), which of course is based on STM32F1, as most things coming from China do these days^{[citation needed]}. Never felt so good about being a native Chinese speaker when I clicked through that Windows 98-inspired GUI in GBK-encoded Simplified Chinese, like a boss.

Note that blank SPI flash chips usually come with 4-bit (quad) SPI disabled, and requires a manual write to a status register to enable it. Since this flash programmer does not do this for me, till this day I still perform this ceremony using my Bus Pirate.

BONUS: The configuration bytes / firmware image generator of XHRA, downloadable from the reference design page, takes as input a config file with .cfg extension. Public service time: It is a Python script. Have fun.

End of Rant

And here’s the minimal system board on OSHPark, and here is the raw BOM full of placeholders. {X60 = 24.576 MHz, X61 = 22.5792 MHz} can be any pin 1 active high enable, 3.2 × 2.5 mm SMD XO.

It’s been a while since I last wrote *ahem* lies *cough* on this project. I am currently a little bit torn whether I should keep writing it here or start posting to my new hackaday.io presence… Anyway here is a brief update:

TL;DR

I now have a working standalone unit — USB in, headphone out — although it looks like this:

EDIT: New output module PCB just arrived. Works on first attempt. With the bulky v2.0 PCB gone, it now looks much neater!

There are still 5 pairs of jumper wires for patching power together, and USB V_BUS is fed directly to V_DAC, but hey — no more bench supply!

What are these modules?

• DAC-Filter (middle, with big tantalum cap): This is a v3.0 copy with matched I/V gain resistors, which means all gain-affecting resistors are matched down to 0.05% on this board, in addition to 0.1% absolute accuracy.
• Output (bottom, with pot and knob): Still the old Objective₂ (NJM4556) I have been using. It works so why not!

  EDIT: Now this is based on OPA1622 which I mentioned in a previous post as my final pick for output amp.

• Power (top, with 3 pairs of jumper wires): the existing v1.0 copy turned out to be working fine except for the LDO responsible for DAC analog +5 V supply (ADM7150), the schematics of which I screwed up. This is the reason I had to resort to V_DAC = V_BUS .

• USB (middle, with LEDs, plugged into DAC): I made a XMOS-based USB-to-I²S dongle (much cliche!), which finally has on-board crystal oscillators (XOs) providing the master clock. My entire journey with USB Audio could become quite a few blog posts (and already a spin-off project I posted on hackaday.io project) — when I have time.

Next: Integration

Since then I have crammed everything into two PCBs, both of which have been sent to OSHPark and will likely get back in the following week.

• 2-Layer Power Board:

  

  I don’t really like the idea of having a DC-DC converter packed on the same PCB as analog, so I dumped that and all 3 analog rail LDOs on this board. ADM7150 is too expensive, so I replaced it with another TPS7A4700, whose output already looks clean enough for me.

• 4-Layer Main Board:

  
  

  USB jack on one end, headphone jack and volume pot on the other. Worth noting that it measures only 2875 × 850 mil — shorter and narrower than my very first DAC-Filter module!

The idea is to stack the two boards together with 0.1″ pitch headers, with component sides facing away from each other. This way 4 copper fills / planes sit in between the sensitive analog circuits and that noisy DC-DC converter. Also, the DC-DC converter is placed near the USB jack, below the digital section of the main board, which further distances it from the analog section. All this should provide enough shielding from switching noise.

Although I got the system working in the last post, it is powered almost entirely off my bench power supply and as a result I could only use it at my workbench. Ultimately I want it to power entirely off USB, so a power supply module is needed…

Input

• USB V_BUS: (+5 ± 0.25) V, 500 mA.
• Optional: AC adaptor (transformer), 9V batter{y,ies}

Output

• DAC analog power: +5 V, 40 mA.
• Analog signal rails (for line-level): (variable but symmetric) e.g. ± 6 V
• Analog power rails (for output buffers): use analog rails directly

Overall Plan

When I first started, I thought I could use V_BUS directly for both DAC analog power and positive analog rail, then use a high current (capacitor-based) charge pump for the negative. The reason I looked into charge pumps was that they are supposed ^{[citation needed]} to be much less noisy than inductor-based converters. However this approach is flawed:

• Voltage swing is very limited; add LDO and we can only have approx. ±4 V rails.
• Ripple on V_BUS is not specified. The positive rail could be very noisy to begin with, which would totally trash DAC performance.

So the only option is to use (inductor-based) DC-DC converter(s) to generate a higher voltage dual supply (which is predictably noisy), then use LDOs to produce regulated rails. This is so cliché that I know from the beginning that the devil is in the details. Of $profanity course!

At > 5 V power rails we’re likely using adjustible-output parts, and thanks to the output levels we’re dealing with, rails are going to be ≤ 10 V, so the specific setpoint does not matter much (yet). I picked ± 7.5 V for DC-DC output and ± 6 V for LDO output. This should give the LDOs far enough headroom for optimal PSRR performance.

Parts

• DC-DC: TPS65131. This part integrates two converters that share the same voltage reference and logic supply (otherwise independent): boost and inverting. Each requires 1 inductor, so 2 in total.
• LDO for V_DAC: ADM7150. This is a huge overkill — it offers unbelievable PSRR up to 10 MHz, and can still put out a whopping 800 mA current. Honestly I am tempted to use it even just for the sake of trying it out…
• LDO for V_CC: TPS7A4700, the go-to premium positive LDO with pin-programmed voltage.
• LDO for V_EE: TPS7A3301, the go-to premium negative LDO with resistor-programmed voltage.

Design

RTFM. That’s enough for making a prototype PCB.

I still have to figure out how to fit the modules together, so for the prototype I just randomly placed headers near the output pins.

Assembly

Sadly All the TI stuff are only available in QFN. Now that I am going to deal with multiple QFNs anyway, I may as well use the QFN package for ADM7150. So 4 QFNs on 1 PCB. Can’t possibly do this by hand with my terrible hot air gun skills, so I finally resolved to invest in a reflow oven: The infamous T962. It now sits comfortably on my bench:

This unit is rumored to be horribly inconsistent, but owing to its phenomenal popularity, there are quite a few mods online that promises better results. Before I go all out in modding though I decided to first give it a try using Tin-Lead paste, which is supposed to be more forgiving. Turns out the heat distribution is so uneven — a TPS7A3301 was (non-visibly) burned (internal voltage reference out of spec), while some paste didn’t even melt!

With some luck I managed to make a good copy. I had to use iron and flux to clear some bridges, but other than that the board looks much neater than what I could do with iron only.

Testing

Turns out that I screwed up the schematic symbol of ADM7150 for v1.0, and of course it didn’t work. Other things seemed to be working: Both analog rails looked really clean (V_PP < 20 mV, DC to 20 MHz), at least using a simple load resistor, which I assume isn't too different from using the actual load since there is enough bulk capacitance across all rails.

However, the next day when I hooked up this copy to DAC v1.0, I found out that negative rail became zero when under load. I still don't know if it's the DC-DC or LDO to blame, and I can't tell for sure because I'm going to order revised boards soon.

EDIT: Problem is now isolated to be TPS65131 negative channel, although I have no idea what went wrong, as I simply used the reference design in the datasheet. TPS7A4700 and TPS7A3301 both work fine.

EDIT again: While I did make a bad isolated TPS65131 prototype PCB copy, the very first Power v1.0 copy actually worked when I tested later.

Next Step

Mostly fitting this module into the whole system. I originally planned to integrate USB and DAC modules (DAC v3.0), as they both require 4-layer stack. However, I have decided to make a standalone XMOS XHRA-2HPA board instead. As a result I'll have to interface Power v2.0 with revised DAC v3.0, preferrably integrating output module into Power v2.0 as well, so that I can have "almost the whole system" — just lacking the USB module, which can be trivially connected.

In the previous post I covered the design of my DAC + Filter module and its initial test results. Before I could actually listen to music through it though, I need at least 2 more modules: a headphone amplifier, and a USB-I²S bridge.

Headphone Amplifier

Initially I picked OPA1622 as my power op-amp chip. It is similar to TPA6120A2, but with a smaller output impedance at 5 Ω and a much smaller (yet still sufficient) output current at 140 mA. However when I first started designing DAC + Filter module, I wasn’t very sure about what circuit I want to use for the output stage, so I quickly made this breakout PCB with built-in decoupling and bulk caps:

Sadly, this part is only available in DFN with thermal pad. And after a few failed attempts at hot air gunning, I ran out of parts and had to find an alternative. So I made myself a copy of NwAvGuy’s Objective₂ headphone amp without its power supply (use my bench supply instead) or input gain (DAC + Filter already has sufficient gain) — basically everything after VR1 (the audio potentiometer) on the schematics.

Sidenote: Although the Objective₂ design is open sourced, its cc-by-nd license does not allow publishing work built on it, even when what I did was simply making my own PCB layout using a part of the original design, verbatim.

This is a dead-simple and well-tested design (voltage divider + RC filter), so I take it for granted that it always works as intended.

USB-I²S Bridge

While a standalone I²S source was well-suited to testing the DAC, listening to a single tone isn’t fun, so I turned to Aliexpress and picked up this little dongle that outputs both I²S and S/PDIF at 10 USD including shipping:

Yes, the silkscreen for the I²S headers was somehow upside-down… Regardless, it does stream 44.1 kHz audio from PC, as advertised. Here are some scope shots:

Master clock (256×F_s = 11.2896 MHz):

Byte clock (64×F_s = 2.8224 MHz):

Sample clock:

Serial data (16 bits on 32 bits frame per channel):

All Together

At last I have the complete signal chain from PC to output. Since I already tested each module individually, I felt prepared to plug in a real headphone and listen to actual music… Well, out of caution, I did not plug in my K702 right away. Instead I grabbed a pair of cheap earpods and then:

1. Double check all power connections.
2. Turn the volume pot on the headphone amp to zero.
3. Plug in the cheap headphones.
4. Enable bench supply outputs (simultaneous ramp-up).
5. Plug USB-I²S dongle into PC and setup streaming.
6. Play some music.
7. Slowly turn up the volume pot.

And… It worked! Still cautious, I allowed it to burn in for 10 minutes. Seeing no problem, I turned the volume back to zero, switched to K702, and turned the volume back up. Not surprisingly, it still works, and I was totally listening to music through my DAC and Headphone Amp!

Next Steps

This is still a modular (read: hacked-together-with-jumper-wires-and-banana-plugs) prototype designed for hand-soldering and easy testing. Long way to go before this could become a standalone unit:

• While Objective₂ works fine for now, its license prevents me from incorporating it into this design which eventually will be released as open source hardware.

• The cheap USB-I²S dongle only outputs up to 16 bit / 48 kHz, and of course the USB-derived master clock is far from clean. For the standalone unit I need at least 24/96 and a clean master clock asynchronous from USB clock, and of course integrated with the rest of the design.

• The power module is still WIP.

Next post will focus on prototyping the power module.