In Which Jarrett Builds

A lot of the switch-mode power supplies I’ve built have relied on Skyworks Technologies controllers. This is because they are very cheap, and seem to go obsolete almost immediately after purchase.

This is a quick story of bringing up a new switch-mode circuit from a different manufacturer to test its viability in some battery-powered devices.

I’m using a Richtek RT6150A buck-boost controller.

For a 3.3V output, buck-boost topologies are necessary when the input is a LiPo battery. The ~3.0-4.2V safe voltages for charge and discharge are perfectly bracketing the 3.3V target in a way that is about as inconvenient as possible.

 

Other than cost, the reason that I selected this chip was that it seemed marketed towards this exact application. Battery technology is written in the advertising materials, and the datasheet shows this:

 

Oh yeah,  perfect! An undervoltage cutoff. That should be good for LiPo protection.

so I drew a schematic like this:

 

And then sent it off as a one-off PCB through OSHPark.

It costed about a dollar.

 

 

I got it back, soldered it, and did a quick bench-test. Instead of cutting off at 3.3v like I intend, it didn’t turn on until close to 5v.

No good!

So I pulled out the scope and checked the voltage at VINA:

 

 

The input voltage was completely stable, so that wavy portion in the middle of the voltage divider wasn’t coming from the input.

Going back to the datasheet:

 

This was ambiguous, but hindsight tells me it’s not actually intended to be a voltage cutoff. This is just the power for the control circuitry itself.

What was happening was that the internal control circuitry was drawing enough current that the voltage at the middle of the divider sag enough that it hit its cutoff, and turned the chip off, making the voltage rise enough that it turned on again, etc.

This chip is advertised in Richtek’s appnotes as being good for LiPos because of that cutoff, I assumed, but it doesn’t actually work!

So, I bodged VINA to VIN, and now it works, albeit at the full range of the chip. That’s not exactly what I want.

The other thought is to use EN as the cutoff.

It’s supposed to shut the chip off at “logic level low” whatever that means for a wide input voltage chip.

 

Logic level is anywhere from 1.4 to 1.8v, which is annoyingly wide.

 

But I gave it a shot.

 

 

 

Some test results:

Channel 1(Yellow) is output, 2(Teal) is the EN pin, and 3(Purple) is the input voltage.

At 1.11V input, output is still disabled.

 

At around 1.59V, the output springs up to 3.24V:

 

Weirdly, as the EN pin gets closer to the theoretically 1.55-ish point where it’s supposed to turn on, output noise starts to hugely increase:

 

Until right at the logic level high point, the output voltage has almost a full volt of non-periodic, constant noise:

It’s possible that it’s not a coincidence that is right when the controller switches from boost mode to buck mode.

So again, let’s bodge this back into a manufacturer-recommended specification:

Replacing R3 with a 0-ohm resistor (or: a wire) gets this back into spec:

In this case, the output (teal) is still disabled until the input(yellow) starts to hit 1.50V.

 

From there, there’s a sudden switch-on at 1.56V to 3.2V output:

 

And it quickly rises to a 3.3V and stays there for the full range, up to 5V input:

Output ringing is a periodic 1V peak-to-peak for about 20ns, every 1us or so. This gets a little lower when the output is loaded and provides some damping.

 

So the moral of the story is that the Richtek RT6150A works quite well, but only when the datasheet is closely adhered to. Anything “interesting” in the design leads to unacceptable noise or unpredictable results.

 

In the meantime, the RT6150A seems to be on the way to phasing out. Stock on Digikey is 0, with a 16 week lead time for new parts. The catalog not-so-subtly hints at using the RT6150B variant, and the datasheet is almost identical. The glaring differences are a few added lines in the marketing copy on the first page saying that fixed 3.3V operation is possible by tying the feedback pin directly to the output.

Anyway, that’s my debugging story. Nothing was particularly novel or unusual, but it was a good process to document irregularities while abusing the chip.

 

TLDR: I wrote an Inkscape extension to make my life a little bit easier when designing assemblies with laser cutters.

 

For the most part, I avoid using 3D printers while rapidly prototyping. Until very recently, they have been little better than toys; unreliable, inaccurate, and high maintenance. The laser cutter, however, is a tool. By cutting and joining multiple sheets, three-dimensional objects are still faster and often better than 3D printed parts.

Additionally, when I’m trying to build something really fast, I find it much quicker to sketch out profiles in Inkscape than CAD them up. Inkscape is totally rad open-source vector drawing software, if you’re not familiar. Being able to see assemblies in 3D is nice, but I can do that in my head for quick and dirty projects.

One of the bottlenecks in this process that really messes up my flow is hand-drawing box joints. It’s tedious and error-prone to copy mating profiles that are dimensionally accurate.

 

But wouldn’t it be great if it only took two seconds?

So this is QuickJoint. It’s a simple Inkscape extension that will add box joints to selected objects.

 

This first version can do male tabs or female slots. The tabs by selecting a path, and then in the menu choose which side (and direction) to tabify.

The slots will use a single line as a guide, accounting for the laser’s kerf.

 

 

This is a work in progress. Fine tuning with how kerf computation works will be tweaked. Slots/tabs may be changed to autodetect so that everything can be done at once. There are a few more changes, for sure.

 

It’s been tested on Inkscape 0.91 and 0.92, but there was a breaking change in how units are translated in earlier versions, so if you get an error that references self.unittouu, then upgrade your copy of Inkscape! Feel free to submit other issues, with example SVGs.

 

For a two-minute primer on writing extensions for Inkscape, read on!

Everything is based out of the Inkscape/share/extensions folder.

The recommended method to get started is to find a similar extension to the final project, and use it as a starting point.

Two files are required: A .py and a .inx

The .inx is an Inkscape extension dialog file. There’s a reference here, but for simple stuff, that’s not needed. There are plenty of decent examples in the extensions folder. You’ll start by modifying the dialog options, and then setting the self.OptionParser.add_option of the Python script to match.

For the Python portion, there is a little bit of magic.

Most of the files in the extensions folders are just that: extensions. A few of the files in that folder are special helper files, though. They’re listed here. Inkex has the main Inkscape helper functions, and I used simplepath for SVG writing.

One of the key concepts is that Inkscape mostly gets out of your way while running the Python script. You’re parsing and handling the SVG files directly, with the assistance of those helper scripts. It’s not so bad, SVG is a really simple format – In this case, I only needed commands relating to straight lines, listed full SVG spec.

When Inkscape calls your function, it runs YourExtensionClass.affect(), inherited from the Inkex module, which then calls YourExtensionClass.effect(). Yeah, not a typo. It’s a little bit silly.

From there, the “Live Preview” checkbox in the extension dialog is your friend. The .inx only gets loaded when Inkscape starts, so changes to the dialogs don’t get updated, but the .py gets re-run every time the extension renders.

Jumping off from my last post about getting images into Altium Designer, it was surprisingly difficult to do in CircuitMaker.

After three days of attempting a few different approaches, I have one that I’m quite happy with. Conveniently, this is pretty good at getting images into EAGLE as well. At least as good as the built-in ULP.

If you’re just here for the solution, scroll way down and read the paragraph about the brd-builder.py script.

 

This is the story of how I arrived at a robust method of importing bitmaps into arbitrary layers in EAGLE cad or Altium CircuitMaker.

 

The first approach I started with, after drawing some pretty pretty pictures, was to attempt to load them into Altium Designer in the same fashion as described earlier.

These images were way larger and more complicated than the previous experiment, however, and the Delphiscript chewed on it for three or four hours before silently failing. Even if it had worked properly, I’m not particularly happy about being dependent on the expensive professional tool to work with the hobbyist one. So I delved deeper.

Here are the options and approaches I took:

• Importing DXF files directly in Circuitmaker is possible, but largely unsatisfying. The CM importer splits up the original paths into discrete arc and line segments. This is great if you want to draw outlines, but that’s it. Lack of fill options or the ability to merge these objects make it inadequate for my purposes.

 

• Using CircuitMaker “region” objects. Going into the property menus of one of these objects reveals a list of points and coordinates, and import/export options. I wrote a converter to massage SVG files into the proper CSV format. This is svg-parse.py. It’ll take an SVG file, and convert each individual object into a CircuitMaker-compatible CSV file. From there, you can create a region in CircuitMaker, open its properties, and import one of the CSV files.

This is pretty good, and results in native objects that are speedy to move around. There are some caveats, however:

• You must do this for each object, making it labour-intensive for complex canvases
• Curves are not supported, so it is first necessary to follow the “Add Nodes” and “Flatten Beziers” steps in Inkscape, described in the import-dxf EAGLE plugin.

 

• Attempting to hijack the clipboard was the next experiment, read-clipboard.py. Region objects can be copy-and-pasted between documents, so I wanted to take a look at what that data contained, and maybe silently insert my own. This never really worked properly, and I abandoned it quite quickly. It was a hacky approach, anyway.

 

• A quick search on reverse-engineering Altium’s file format brought up this primer (by way of Hack-A-Day). Although very abbreviated (the goal of that guide is to teach a methodology, not to completely reverse the file format), the page was more than enough information for me to write a Python script that opens and dumps the contents of the CircuitMaker-formatted OLE document. So in ole-extract.py, I got as far as grabbing a library document and extracting and splitting header/data information into a folder. Realised at this point that the libraries I was using would have a difficult time repacking the streams into one OLE document. Not to say it isn’t possible – it totally is – it’s just rabbit-hole I don’t particularly want to go down at this time. This is still interesting in that it should be a working Altium and CircuitMaker file reverse engineering effort in Python, which hasn’t been done before.

 

• Importing EAGLE files works really well. They’re XML-based, and very well documented. First, I imported an EAGLE file that contained an image, which looked and worked great in CircuitMaker. I poked around with how that image was created in EAGLE, and it looks like it was just made with the built-in “Import Bitmap” ULP. How it works is that it scans along each horizontal line, creating a one-pixel-high rectangle in the filled area. Repeat for the entire image.

Okay cool. That sounds really simple. Problems with that:

• It doesn’t alleviate my allergy to using 3rd-party software as an intermediate step
• If my image is over the 3 inch (or whatever) size limits of EAGLE’s free version, I’m hooped
• The ULP script seems to choke on images randomly

So what I did instead, is take a dummy EAGLE file, and stripped it to the bare-necessities required to load. This particular brand of XML is the fourth file format I’ve had to parse in this whole process, but it wasn’t too hard. With this dummy file, my final and greatest script, brd-builder.py, grabs a bitmap file, converts and then injects it directly into the EAGLE file, giving you a proper EAGLE file, with no size limitations and no EAGLE install required. CircuitMaker can then easily import this via the File->Import menu.

Input images need to be a 1-bit BMP file.  In Photoshop this is done by converting to grayscale in Image->Mode->Greyscale and then converting to bitmap in Image->Mode->Bitmap. In GIMP, this is done through the menu in Image->Mode->Indexed. Then save as BMP.

Before running this script, open it up and then modify the desired variables – inFile, outFile, layer, and scale. They should be fairly self-explanatory. Scale in my application was found by guessing until it fit my board, due to the resolution I drew my image at.

 

This was a fun detour. Fun is good, because spending time to make tools for your tools can be very frustrating. The last tool in particular works great for me, but If I were to develop a robust system designed for anyone to use, there are a few more avenues I would attempt to pursue first:

• In the Hack-A-Day link posted above, one of the comments mention being able to just open OLE. They turned out to be using 7zip, which supports that format natively. Coincidentally, I found a portable 7zip executable in the CircuitMaker folder. It’s possible that they’re using this for encoding their documents. It would be fun to write an executable shim with the same filename that invisibly passes arguments to the original 7zip program, but logs it to file as well. Will also look into better methods for doing this – Static analysis using X64_DBG or IDA is an obvious candidate here.

 

• Failing that, writing and testing code to modify the OLE document stream and then repack it into a format that CircuitMaker can read

 

• The native importers in the CircuitMaker all have IWZ extensions, and from the binary data seem to be x86/64 executables. Google says these might be installer files. Along the same lines as the executable shim/wrapper above, figuring out how these work and writing my own would be fun.

I’ve written recently about machining my own custom pen because, much like lamps, they are a “form over function” project where the end result can be gorgeous as well as useful. Aesthetically pleasing to everyone, not just techie people. And they don’t take up a lot of space!

 

Initially, my design for the first pen was sketched out in notebooks, and then modelled in CAD, then back to the notebooks when I was in the shop. This helped me get a general feel for what I wanted, but many style, material, and mechanical considerations had to be redesigned on the fly as I found techniques that didn’t work, and others that did.

A lot of the dimensions of final product came down to how they felt in my hands, as I was building. That’s fine for a one-off, but I’d kinda like to parameterize basic measurements so that I have some guidelines on what works for future pens.

 

So here’s a pretty generic pen, modeled in Solidworks.

 

Here are a few pens I had within arm’s reach.

 

 

Starting at the top, I named these 1-4, and made some basic measurements based on the generic model:

 

Now I’ve got a good baseline for what makes a comfortable writing utensil, a recommendation for critical dimensions to stay within, and some language (or at least letters) to be able to intelligently discuss the anatomy of a pen.