Steve's Build Log

[Steve_Mayze]

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.

[jonthomasson]

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

[Steve_Mayze]

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.

[ChrisGammell]

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)

[Steve_Mayze]

@ChrisGammell

I think there’s a lot of value in planning out the art that way

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.

[Steve_Mayze]

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.

[ChrisGammell]

@Steve_Mayze

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?

[Steve_Mayze]

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

[Steve_Mayze]

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.

[Steve_Mayze]

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.

[jonthomasson]

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: https://youtu.be/1VlKoR0ldIE.

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

[1.21Gigawatts (Rob)]

@jonthomasson

That must have been frustrating to debug since the first board worked fine.

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.

[Steve_Mayze]

Thanks @jonthomasson and @1.21Gigawatts,

It certainly had me going for a while.

@1.21Gigawatts

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

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.

[Steve_Mayze]

I already posted about a AA-Cell adapter where I wanted to extend what I learned about custom board shapes from the “Blinky-Bear” project to something a little more practical. I received the boards for the AA-Cell Adapter while ago and managed to get some time to assemble and test. Everything worked find ant they fitted together nicely. The custom board shape was not the end of the mechanical challenges! I needed to modify the end cap so that the board will fit and also make a good contact with the plus and minus poles of the device. This would mean having only have one chance since I would have to destroy the end cap to make the change. The alternative is to 3D print a new end cap. I have not had a 3D project before, so here were a few more skills to pick up.

The goal and the model

I wanted to try out Fusion 360 and this seemed a simple enough project to make a start. The modelling is not exactly easy since the original seems to be round at the base and slightly elliptical at the opening. The thickness of the walls is also not uniform. I started with a base model and decided to just give it a go. It turned out it did not fit as I had used the “shell tool” which made the walls of the cap parallel to the outside, which were tapered. The piece of the main body that fits into the end cap is more cylinder like. Taking what I had already learned, I then created a whole new model. This time cutting out a cylinder from the end cap body rather than using the “shell tool”. So it was off to the local FabLab to print out Attempt #2. This result was much better and the cap fitted neatly on the main body part. I added a small self-made copper spring for good measure to take up any slack that might be in the housing. However, this was not going to be my problem - The base was too thick and the USB mini plug could not go in far enough to make a solid connection.

I changed the model to make the base thinner and now Attempt #3 does the job. It fits neatly on the main body and the USB plug can make a good connection.

I think in the last twelve months or so of Contextual Electronics, I feel it is the mechanical aspects pose the biggest hurdles when developing something new and where I feel I have spent most of my time. Sure, getting the electronics right has its challenges. But trying to get these things to fit neatly together needs a lot more consideration. I guess, electronics seems simpler because if it does not work, then a component value change, wire bridge or lifting a pin might sort out the issue. But with the mechanical aspects, it can mean a whole new spin of the housing or even a board.

[mikef (Mike Frith)]

Very cool! Nice work! I agree that the mechanical/fab part is a hindrance. I’ve got some projects but not sure how to build the housing for something that is not a straight line, such as bike frame shapes, where the radius changes over the extent of where I want to attach something.

[jonthomasson]

Looks good Steve! It looks like the third time was the charm. That final part came out great. Were there any Fusion 360 tutorials that you found useful for learning this stuff? The cost of 3D printers are so cheap now I may try to get one under the christmas tree this year.

[Steve_Mayze]

It ws certainly a case of third time lucky Each time I was confident that it would simply be right. But then there was something else that I had not considered. Taking the measurements off a relatively small original part was not easy. I also struggled a bit with how to model the part as simple as possible since my niveau of 3D modelling is still novice. I was finding variences in wall thicknesses and other aspects were neither staight nor round. So I opted for a best guess/fit approach.

When getting into Fusion I worked through the first few set of tutorials from Autodesk, especially the UI where I learned the “S” hot key becomes a good friend.

A 3D printer to have in the Lab would be very convenient. For me, the price is one aspect, but the benchspace is probably worth more. I am very fortunate to be able to cycle 5 minutes to the nearest FabLab, and I am enjoying just talking to others about their projects while the part prints. I work from home so I see this as a substitute for the coffee machine at the office

[Steve_Mayze]

I was Looking for a quick exercise to try out KiCAD 5.0, so I decided to go back to the first exercise I never really finished - Getting to Blinky! The original Getting to Blinky series is what convinced me that KiCAD was what I needed for my purposes and made me aware of Contextual Electronics.

[mikef (Mike Frith)]

How was the experience? Any issues/gotchas? I’m debating moving sooner than later.

[Steve_Mayze]

I had a rough start as I downloaded one of the original archives. This install would throw an error when clicking on the Tools menu. Apparently the archive was updated shortly after the release. I downloaded it again and now it is fine. That was the only major issue.

When opening an existing schematic, I did have a bit of a doubt. I get the dialogue to re-map the symbols. My first fear was what that would mean in 4.0 - symbols suddenly appear in a different size and things don’t quite connect any more. From a brief look around, it seems the best is to accept the defaults. I have not looked into the details yet to know any better. Needless to say, accepting the defaults for the couple of projects I have tried this on has not shown any surprises.

For a new project like the Blinky, it went smoothly. The only thing that lost me was the renaming and re-locating the OpenGL option for in Pcbnew. The hot-key has not changed, just the name. It used to be under View. But they are now located under Preferences.

I found the explanation and now it all makes sense. Legacy (F9), the old layout canvas and will be removed at some stage. Modern Tool set (F11), is the preferred canvas and is renamed from OpenGL. This name had no real functional meaning with respect to the Pcbnew. The Modern Tool set Fallback (F12) is in case F11 does not work i.e. problems with the graphics drivers.

Once that was understood, it was clear sailing. I also noticed there is an “add vias” tool. This really simplifies things like via stitching as I don’t have to create a special footprint for the purpose.

There is more to explore in Eeschema too… a Symbol Field Editor in speadsheet format where it looks like the component values can be updated. This will be handy for making corrections etc before creating the BOM. One of the reasons I have never really used the BOM feature that much is the back and forth making corrections.