Andrew H's Build Log

Hey y’all, I’m Andrew and I’m coming to Contextual Electronics as a software engineer/data scientist by day and electronics hobbyist by night. Hardware and low-level programming has always sort of been a passion of mine, I remember spending way too much time writing Z80 ASM for my TI-86 calculator vs doing homework in high school :slightly_smiling_face:.

I’m a huge fan of the Amp Hour podcast and found the Getting to Blinky series on YouTube a blast. I really wanted to learn more fundamentals and signed up for Contextual Electronics because the project based approach really resonated with me.

Ultimately, I’m really interested in the finding a way to combine my two passions (data science + hardware) and hoping to build some interesting IoT projects to help automate things around house. I’ve enjoyed reading through some of the build logs so far and hopefully y’all enjoy mine!

Hey Andrew! I was always in awe of people who could program their calculators back in school, I was one of the ones who just asked to get whatever programs were already written for them :slight_smile:

What are you hoping to build after taking the course?

Hey Chris! I thought it’d be fun to build something like the Amazon Dash smart shelf but instead use it to track my consumption of different food items like coffee / flour / etc over time. It’d be really cool to run that sort of thing off of a rechargeable battery somehow but even if it’s plugged in I think that would be a great start.

Finished the “Shine On You Crazy KiCad” course!

I took a shot at trying to make the board a little smaller but still following the video instructions. I swapped to 0805 footprints for the components which is the smallest I currently feel comfortable soldering and found the footprint for the female header so it shows up nicely in the 3D viewer!

Didn’t end up ordering the board, but here’s how it looks in the OSH park preview:


I found it pretty awesome that it would only take ~$3.00 to get this printed out!

Up Next:
I’ve already done the “Getting to Blinky 5.0” course, so taking a stab at “The CE Header” next!

1 Like

Continuing along the courses, just finished the “CE Header” course.

I made some modifications to use the latest Teensy 4.0 board instead of the Teensy 3.2 and tried to do all the routing without relying too much on the video. For the Teensy 4.00 schematic and footpring, I modified the schematic & footprints from this github repo.

Here is what the final routing looks like on the board, I tried to keep the SPI lines on the back when possible

If anyone has any recommendations on how to improve my routing or any mistakes I’ve made, it’d be much appreciated! :smile:

Up next taking a look at the “Sensor Board” or “Current Sink or Swim” as the next project.

The SPI lines are close together so there is no copper fill. I would be interested to hear what is the better practice in such cases i.e to.avoid interference etc.

1 Like

Looks like a couple of layers (courtyard and mask?) for the two top-layer SMDs ended up on the bottom, I doubt you want that. Those components are also lacking silkscreen identifiers.

1 Like

Another thing - put your board name and board version number on the silk screen. You may think version is unimportant but if you start making changes you will want to know which schematic represents a board you are holding in your hand. If you are sharing it, put a copyright on it as well.

A suggestion for a tutorial video - creating versions of your design. I do this by copying the entire kicad directory. I hate the duplication but haven’t figured out another way. I think Kicad 6 is better (because of the changes to the libraries). Some people use git but I like to have each version available to me all the time.


Thanks for the feedback everyone!

I added my name + version number to the PCB and cleaned up the routing so there isn’t that gap in the copper fill between the SPI lines.

The silkscreen for R2 and what looks like U2(?) are overlapping copper pads. You fabricator’s process will probably automatically mask that out. Silkscreen stuff that you want to be visible needs to be clear of pads and not under components. The 3D viewer feature of KiCad is great for checking stuff like this.


Still working on the “Current Sink or Swim” project, but went on a bit of a tangent since I was curious how we’re able to program boards like the Arduino over USB. As a result I built this USB-C -> UART board for fun based around the FT231X IC. It’s my first board that I’ve totally researched and built from scratch so any feedback on it is always super appreciated :slight_smile:.

Here’s the schematic:

And the PCB front/back that I ended up with:

That’s great! I have a board with that chip on it, it’s quite useful. The creator of the board actually hooked up one of the I/O pins to a FET output to control 5V power to a downstream devices from Linux. Plus it has the serial, obviously. That’s a great board to strike out on your own for, congrats! Please share a photo when it comes in.

1 Like

Looks pretty good. Since you won’t be using very high speed USB and the run is short you probably don’t need to worry about matching the D+/- lines though I always at least try. Take a look at how Sparkfun lays out the 27 ohm resistors on their board. A little more balanced.

1 Like

Thanks phil! When you say matching D+/D- lines, do you mean the length of the traces?

Yes though it’s more than just length. High speed differential protocols rely on the signals getting there at the same time so length is important. The resistors are for impedance matching. In addition, differential signals need to run next to each other as much as possible which is why SFE placed the resistors like they did. But, your board is so small it probably doesn’t matter. If I were doing a board like this, I’d do it the way SFE did (with the resistors side by side and in line with the trace runs). I’m a bit disappointed that the FTDI Datasheet is silent about placement and routing. Maybe they have an appnote on it.

Here is an example of USB and ethernet differential lines. I used the Kicad tools to create them. 100Mhz ethernet and USB 2.0. The USB lines were a little over 35mm so definitely needed differential routing. I didn’t bother to impedance match them, though.


USB-C FT231X Breakout Build & Test

I received the boards for my FT231X breakout yesterday and took a break from working on the Current Sink or Swim schematic. Really love the fast turnaround on these boards were and as always it looks great.

Building the board was a little rocky at first, the SSOP footprint of the FT231X was a little smaller than I’m used to and I messed up one of the boards trying to remove some bridges between the pins but hey this is why there’s 3 of them!

The second try was a lot better as we can see below:

Now that everything is connected, let’s try it out! Let’s plug into my computer and… nothing happens.


The board wasn’t getting any power at all from cable. Comparing the schematic against other FT231X breakouts, it didn’t seem liked anything was off. The only different is that I’m using a USB-C connector which has a couple extra pins. I looked up the pinout for the USB-C receptacle to see if there was anything I missed.

I’m only using the USB 2.0 interface, so let’s start there:

  1. USB-C data pins are connected in the schematic and on the board.
  2. SBU1/2 are not used and are disconnected.
  3. CC1/2 are disconnected on the schematic but seem to deal with power delivery. Maybe it’s something to do with those?

A little googling around turned up a great intro to USB-C document from MicroChip ( Turns out those pins are used to detect whether a cable is connected and the type of device. Leaving them disconnected explains why nothing was working :man_facepalming: (Sidenote, but definitely adding a power LED to the next revision)

Bodging it up!

According to the USB-C document, I needed to pull both CC1 & CC2 to GND using a 5.1k resistor. I don’t have any of exactly that value but a 4.7k + 470 would get me close enough. I delicately attached them to the back of the board as seen below. It’s not pretty but it gets the job done :smile:

Connecting to the cable again and checking the pins, I see that the board is now getting power! Unfortunately, the computer is not recognizing the board as a serial device and it doesn’t seem like the chip is doing anything. I started to again debug and double check connections:

  1. Chip is oriented correctly on the board, just making sure for my own sanity.
  2. 5V is connected and going into the FT231X chip VCC pin.
  3. Pins used for the RX/TX LEDs are connected and pulled up to 3.3V (they pulse down when something happens), so presumably the chip is getting power and using it.
  4. But strangely, the 3.3v out pin on the chip is not outputting anything. On the schematic, the 3.3v is used as input into other pins on the chip, so that might explain why nothing is working.

Where to next?

At this point, I’m not sure what to do next. I might try taking the 5V from the VCC, converting that to 3.3V and applying it directly to the pins that need it on the board to see if that does anything. But the 3.3v out not outputting anything is really mysterious to me.

Always fun working with new (to me) chips.

For fine pitch part solder bridges - use lots of solder flux and solderwick. Cleans them up very nicely. When I say lots of flux, I mean drowning.

I doubt feeding the 3.3V output with 3.3V will do anything. The block diagram in the datasheet shows it outputting from the VReg.

Do you have schematic of your board - I’ll take a look. Double check that all the IC pins have continuity to your PCB. It’s easy to get a cold solder joint and not have a connection.

One thing that happened to me is I was using the USB C plug schematic symbol instead of the USB receptical symbol. So the pins were all hooked up properly, but I was missing an entire row of the connections.

Just to make sure: Have you tested the USB connections in both orientations?

Thanks @phil_from_seattle! Really appreciate the help, been banging my head against the wall on this one.

Here’s the schematic for this build:

@ChrisGammell did another test flipping around the plug and seems to be the same issue still.

That’s interesting that there are caps on the D+ / D- lines, haven’t seen that before, I assume that’s from the app note or a reference schematic?