Steve's Build Log


I really like it. At least having done the Power Swap module of CE I at least understand the principle of the suggested design. The down side with a vendor specific tool is that I might be missing out on more suitable parts from other suppliers.


I was inspired by the recent videos from @ChrisGammell to have a go at custom/complex board shapes. I had experimented with this before but never brought the shape to OSH Park. Also taking the lead from the Tindie badge, I came up with a simple design that uses some RGB Rainbow LEDs. My first encounter with these devices was at a Makerfaire where someone was immersing these in a mould filled with hot-glue to make small blinking animals - very cute.

My shape is simple (corny) enough. My thought is as a soldering experiment to encourage a junior maker. I created this in Inkscape simply using a series of circles for the head, ears, body, legs and paws. I saved/duplicated the shape at various stages so that I could either reuse or go back if things did not work right. This proved helpful as once I started to import things in to KiCad, I realised I needed different shapes for different aspects of the board, namely the following shapes:

I pretty much followed Chris’ example and it all worked without issue. I also included the steps for inverting the images in GIMP before importing to KiCad. The theory behind this is that when exporting from applications like Inkscape, the white background on the screen will be converted to the Alpha (transparent) channel in the exported image. This causes big problems with the bitmap2component import. There can be no alpha channel. The work around is to invert the image in applications like GIMP or place a white enclosing box behind the image.

Since playing around with this, I have now realised the setting in Inkscape to ensure a white background and no Alpha channel. It can be found in the “Document Properties”, “Background color”, setting everything to white with 100% opacity. Using this saves the extra work step of inverting the image in GIMP.


Excellent work! Thanks for sharing the Inkscape settings. The gold enig on the Oshpark boards really looks fantastic with the bear heart.


Thanks Jon, I am very happy with it as a case study in custom board design. It even does not look too bad when in operation.


Yeah, this is a super cute design! I feel like I have to get deeper into inkscape. I’m a bit dependent upon Sketch (by Bohemian Coding) for a simple/intuitive way to manipulate SVGs, but that is mac only. I highly recommend people start with SVGs for PCBs, I think there’s a lot of value in planning out the art that way (this is also what Saar from Boldport does for his boards, albeit in a more in-depth manner)


I certainly agree and the operative word is planning. I did not do it for the bear but I could have mixed and matched the fill zones like you did for your project. This way, I could have avoided a couple of tracks.
Now, as of writing, I was curious to check in KiCad and it is possible to export the layout as SVG. This means that a complex fill zone shape could be created in Inkscape or Sketch after parts placement.


Leading on from what I learned from the Blinky-Bear project, I wanted to try something a little more practical. I thought about a AA Cell replacement board for a small trimmer where a normal alkaline battery has trouble powering it for any length of time - From the Lab Power supply the device draws around 700mA.

I figured a 5V to 1.5V LDO should do. The circuit is simple enough - based on a ADP3339AKCZ-1.5-R7. Not exactly the cheapest option but it is available and should be able to handle the power requirements. The idea is to use a USB Micro B connector. For this, I will have to modify the case to enable the USB cable to be plugged in.

For the layout, this time I started in Inkscape, rather than KiCad Pcbnew. I made a few attempts before I finalised on a design that will comprise of two boards that will slot into each other to make up the bulk of the AA-Cell shape. I figured I could save a couple of dollars in the by laying out the boards end to end rather than side-by-side. I just had to make special consideration for the “panelisation” of the two boards. For this I consulted the OSH Park design guide document “Panels and Designs”. I actually submitted the boards without an order and requested OSH Park Support to take a look. They were more than helpful and pointed out that I needed to remove the edge cut going through the mouse-bites.

The fix for this was to ensure that the edge cut does not go through where the mouse-bit is expected to be positioned.


I have only just submitted the boards to OSH Park, so I am curious if this will all fit together as I am anticipating. There is certainly a bit more work when doing the edge-cut this way but in the end, I am finding I am spending more time on mechanical aspects of a project than the actual electronics.

This brings me to another point I missed describing on a previous post. Namely another Inkscape setting. In Edit, Preferences, the main preference page gives two options - Visual-Bounding-Box or Geometric-Bounding-Box. The difference in the two options is illustrated below - essentially, visual puts the bounding box on the outside of the line. Whereas geometric places the bounding box in the centre of the line. I personally find the Geometric bounding box easier to conceptualise with respect to the edge cuts.


Is this because it matches the toolpath of a milling bit?


That is certainly the case for a laser cutter - for the milling bit, I am not 100% sure. the graphic on the OSH Park Board Outline document implies that this will line is the outside edge of the tool cut. I am making this assumption and when I get the boards I will then know for sure - it’s a prototype :slight_smile:


I am still waiting for the Tag-Connect Edge Connector to come available in Europe - Here is the comparison of my current footprint to the sample. This is also my first attempt at castellated edges with KiCad. Sort of not bad but I will wait to try with the real connector before submitting again.


I have been working on a Proof of Concept to connect some sensors and possibly actuators back to a “Home Base”. I have been working on this for a while and have already made mention of the sensor part before and also the power module. In order to progress the Proof of Concept, I assembled the remaining two sensor boards as complete modules with a Teensy and a XBee. I was surprised to find that the XBees could not be contacted and would not communicate.
I followed the suggested (simple) connections for the XBee. But for good measure, I added a LED and resistor on each of the Tx and Rx lines to see some activity.

The first board I assembled initially behaved correctly from the first instant, so I never considered that there could be anything wrong. The subsequent other boards would not allow the XBee to communicate. On start up, the Tx LED would just blink. I tried all possible combinations of Sensor Board to Teensy connections and the issue seemed to lay with the Sensor Board.

@ChrisGammell suggested to remove the LEDs out of the circuit. I had thought of trying that, but I could not get it out of my head that the first board was operating correctly - or seemingly correctly. I removed the LEDs and the XBees would now communicate!

Scoping the signals, the failing boards would start up and the Tx line would oscillate (Trace 2). For the board operating OK (Trace 1), the oscillation would occur, but only very short - five or so pulses. Without the the LEDs, there is no oscillation at all. The Tx line is taken Hi without any pulsing

Trace 1. Start up of the original, functioning board

Trace 2. Start up behaviour of the subsequent boards.

Trace 3. Start up of the subsequent boards without the LEDs connected

During the research of this problem, I realised the one difference between the board that is working and the other two that are not is that I used a different LEDs! Having worked through the screen shots and this write up, I realised another test to try - Use the LEDs that are consistent with the working board.

In all cases, I used the same green LED -LTST-C171CKT (Fwd Voltage Typical: 2.0V , Maximum: 2.6V). For the Red LED, I happened to use different brands.

On the working board - LS R976 (Fwd Voltage Typical: 2.1V , Maximum: 2.5V)
On the failing boards - CMD17-21VRD/TR8 (Fwd Voltage Typical: 2.0V , Maximum: 2.8V)

Placing the LS R976 on the boards allows them to all behave consistently i.e. as per Trace 1. This makes me think that simply adding a LED on a signal line, although looks harmless, is probably not a good idea. I now think a driver circuit would be more appropriate. Something like the following. In the mean time, I have removed the LEDs out of the circuit to mitigate further issues.


Nice troubleshooting Steve. That must have been frustrating to debug since the first board worked fine. I imagine this would be an issue folks might run into when they are having their boards mass produced, and the CM opts to use a different part than what’s in the BOM. It reminds me of one of Dave’s videos where he’s troubleshooting a similar situation with an op amp on a new batch of his µCurrent’s:

Were you able to figure out what the difference was between those 2 LEDs that was causing the issue?


It’s also possible that the first board didn’t work fine, it just had fewer errors.

Adding relatively high current loads to signal lines is generally not a good idea. Unfortunately VCC does not put enough info on their datasheet to be able to compare the two LEDs. But none of the datasheets list the LED’s capacitance which could also be contributing to the problem. Having a separate driver for the LEDs, such as a transistor as suggested, is the safest approach.


Thanks @jonthomasson and @1.21Gigawatts,

It certainly had me going for a while.

I have been picked up on this before. I need to watch my terminology and down grade “work fine” to “seemingly behave correctly” until every spike and pulse can be accounted for.