Steve's Build Log

I have created a write up to give closure to the Timed LED Lighting Project and describe the change of direction from the previous posts.

1 Like

In playing with the NeoPixel board I created, I got curious to see how this could be expanded. I settled on using a 74HC595 Shift Register as a way to address the strips. I then use the enable on the Shift Register to send the colour information to the strips. This has the advantage of being able to send the data in parallel to only those strips that I want to receive the data.

I have a more detailed write-up on my Blog and also put together a short video to demonstrate the results.

4 Likes

Oh that’s really neat. I may have to grab a few of these. For size-and-weight critical applications like the HAB tracker I’m working on, this seems better than a 2x3 .1" header.

Hi Juliean, I have been using these for a while now and have not turned back. The “No Leg” variant is the smallest since it does not need those four larger holes. It just needs a retaining clip to keep the programmer header in place.
I was at Embedded World last week and saw their Edge Connect version. This looks really interesting, as it takes up no real estate on the board. Just along the edge. I will need to check with @fustini (OSH Park) if this could be supported.

[edit]
I just checked the OSH Park Docs and found their note on Castellated Edges. I will simply have to give it a go and see how it turns out.

1 Like

The comment from @jgalak reminded me I wanted to eventually try out the Tag-Connect Edge Connector.. So I have submitted a board with a couple of foot prints I have created.

I don’t have the actual edge connector yet. But I did pick up one of their sample boards at the Embedded World. I can use that as a comparison.

I used the Texas Instruments WEBENCH® to come up with another power regulator. This time I wanted 5V from a range of 6V to 18V. The initial testing is positive in that it gives a clean 4.92V from 5.5V to 18V (I did not push it higher than that since 18V is already over what I expect). Below 5.5, the system drops out. On the circuit I added the provision for an additional battery backup. The thought was for 4xAAA cells to provide a short-lived 6V. At this stage, I am not worried about the 0.08V discrepancy as I am not yet sure if some of my part substitutions had an effect.

What was interesting is that without load, anything below 6.7V would also show an unstable output. For the initial testing, it was easy to add a 9V battery connector instead of the 4xAAA cell holder. I can imagine the 6V battery pack can still be used once the module has a more permanent connection to the load.

I find using the WEBENCH® a great way to get an in-road on using some of these power devices. The generated design gives all details down to BOM and suggested layout. The simulated thermal images are also pretty neat.

For this design particular design, I took up the WEBENCH® feature and swapped out the 0401 parts for 0805 parts to simplify assembly.

I have to admit, it does not feel like my design. It is more like a kit to my specification. At best it is implementing the application note without having to calculate the specific RC values. Time will tell, of course, on how this design will stand up when the module is really put to work.

3 Likes

Looks good Steve! WEBENCH® looks like a really useful program. I like the simulated thermal image view.

1 Like

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.

1 Like

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.

3 Likes

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.

1 Like

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.

mouse-bites-prep

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.

1 Like

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.

1 Like

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.

1 Like

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 Like

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.

1 Like