Longwave Fun (part 2; aka Standalone)

This is a part 2 in my WWVB time signal series (part 1, part 3).

After I essentially reproduced TxTempus project in PCB format, I thought to myself - what if I remove Raspberry Pi portion and get it working over USB?

Choosing the enclosure was the easiest part. I saw this project fitting perfectly in Hammond 1593DBK. Its long format gives me enough space for antenna while its shape just calls for a watch to be placed around it. Even better, if I cannot get the original, there is an extremely similar HP-3653-B from Bud Industries.

Mind you, they are not exactly the same. For example, one has screws on the top while other has them on the bottom. Bud has just a smidgen shorter length. Even the shape of the panel is slightly different. So you cannot really just get PCB designed to fit Hammond directly into the other. However, if you are aware of those things, you can abuse tolerances a bit and design both board and panels that fit either case without any noticeable difference.

At first I decided to have a 0.8mm PCB so my favorite type-C can be easily soldered. PCBWay generously offered to get them to me for free. While this wasn’t the first time I ordered from them (and yes, I paid for boards more times than I got them free) it was the first time I used them for 0.8mm board.

They have a crazy amount of options and I keep changing my mind about how user-friendly this is. For some projects it makes sense to go over many options and fully customize everything but having all options on one page is slightly overwhelming and selecting the “wrong” option can really increase the price. If you don’t catch it immediately, it might be hard to figure out which option changed the price. Fortunately, both 1.6mm and 0.8mm are the same price. While some colors do involve extra cost, there is a fair selection of colors you can get for free. I went with green just because it ships faster.

For this project I didn’t go with any extra options and the only thing I missed was gold plating. While their HASL surface was leveled and I didn’t have any issues soldering 0.65mm SSOP components, the “golden” ENIG finish is nicer. However, $35 price increase for such finish seemed excessive and was not worth it for me.

When it comes to how the finished board looks, a basic green PCB is not a looker. While normal 1.6mm boards are a bit translucent, going to 0.8mm makes it excessively so. I cannot say I’m a fan of how it ended up looking and I would go with any other color (love the blue they have), even if it means a few days more.

Also worth it, is the removal of an internal product number PCBWay places on their boards unless you pay the extra $3. The placement itself was unobtrusive and sensibly done (way better than a few years before) but I am not sure if it was due to the care or pure coincidence. Even so, I think not having that number should be the default (and free).

My board didn’t push any limits (8/8 mils) so I didn’t really expect any issues. And I must say I saw none. The quality was good with traces looking really even. Based on just that I can bet their process is quite better than 6/6 they offered as a default. Either way, hand soldering 0.65mm SSOP was not troublesome at all. Not only traces and their solder masks were perfectly aligned but also surface didn’t have any serious leveling issues. I did notice there were some leveling artefacts (more on those later) but they seemed to be purely visual.

Interestingly, something went wrong with board sizes once I uploaded gerbers and my board suddenly became smaller as the order was placed. Their support did notice the same and we managed to sort it out but it caused a small delay. And yes, it was repeatable as board I ordered some time later (non-sponsored) had the exactly same issue. It might have been that their parser had issues with my DipTrace gerbers but I didn’t notice anything suspicious in them.

In any case, the boards arrived quickly. Some might say too quickly as I was still waiting for my microcontroller of choice - PIC16F1454. And I waited. And waited. Yep, I got hit by a chip shortage. But eventually Microchip came through (yes, I had to order directly from them) and the chips were in my hand.

PCB design itself was reasonably simple and only about a fifth of board was used by components. The heart was already mentioned 16F1454 with an USB connector on one side and an antenna output on another. And I simply love this microcontroller.

If you want to make a serial USB device, it’s hard to get it easier than this. The only extra components you need for everything to work are two capacitors; one for general decoupling and one for the built-in USB module regulator. No external crystal, voltage regulator, nor USB pull-ups. That leaves fair 9 pins for general I/O.

Considering I just needed USB communication (D+ and D- pins), PWM module to generate 60 kHz, one output to modulate antenna signal, and another to blink a LED, even this microcontroller was more powerful than needed. However, if I needed some other features (e.g. ADC), its pin-compatible brethren - 16F1455 and 16F1459 - would allow for some growth before going to a completely different device.

The most notable board feature is, of course, its rectangular PCB antenna. First of all you should understand that realistically you cannot create a good 60 kHz antenna on a PCB. For such a low frequency you need a LOT of wire and this PCB is way too small to fit so many loops. Even if I could fit all these loops, a PCB is not a friendly environment for it. Not only putting wire loops in a close proximity will make an inductor but it will also make a capacitor and a decent resistor.

Even if you cajole inductance and capacitance to get it to resonate at a right frequency, the amount of resistance all those trace loops have would force us to use a proper antenna driving circuit and not just a few resistors you see here. Even with all that, the imperfections in PCB process would make it impossible to retain all parameters from board to board as even the smallest trace change would throw it out of whack. And remember, we’re talking here about impractically big PCB to start with.

However, since I was intending to use this antenna in a close range, a lot of things don’t matter. Having such a huge mismatch actually helps with preventing signal going to far and messing with devices further away. It also doesn’t matter if antenna has solder mask removed or not. For this board I decided to go with solder mask removed but looks are literally the only reason for that decision. At 60 kHz this solder mask simply doesn’t change anything.

While waiting for components to arrive, I also decided to trim board a bit and make it easier to solder as not everybody likes SSOP and a type-C connector. This variant was a standard 1.6mm, slightly shorter in length, and with some components moved around a bit. And yes, I got it too from PCBWay but I paid for it with my own money . Regardless, the service I experienced was the same (including support for gerber size issue). The only change was a definitely nicer blue color - well worth extra few days of waiting if you ask me.

One extra thing I noticed about the blue board is that antenna looks much nicer and more leveled when compared to the green PCB. While the green board seemed leveled enough, on photos (or if you turn it slightly under the light), antenna has what looks as a “wave” across its surface. The blue board has the antenna surface looking much more leveled and without such artefacts.

I did check boards I previously ordered from PCBWay and I don’t see similar issues. My best guess is that their HASL leveling is not really optimized for 0.8mm boards and when you combine this with a slightly transparent (and thus less forgiving) green board you get visually worse result. Mind you, I only noticed it once I took photos under bright light so it’s really not a big deal.

In any case, with the board ready, it was time to do the firmware…

Please note I have received PCBs for this project for free from PCBWay and they are also the current sponsor of my website. They didn’t request anything specific for me to say and all opinions given here are mine and mine alone.

Longwave Fun (part 1; aka HAT)

This is a part 1 in my WWVB time signal series (part 2).

I have been aware of “atomic” clocks and watches for a while now. Those devices rely on WWVB signal (at least in USA) for occasional time synchronization. Between two synchronizations they depend upon a standard quartz crystal to keep time. This allows for decent accuracy almost assuring time is always within a second of precision.

So, this year I decided to jump on that particular band wagon with a Casio Lineage watch. And I was immediately hit by a disappointment. While watch itself was exactly what I wanted, I simply couldn’t get it to receive and decode WWVB signal during the day. Night was slightly better and I could get it synced in the wee hours. And yes, night-time synching is what watch does anyhow and for any normal person that would suffice. But me? I wanted to play with it.

So I went searching for a WWVB transmitter. And it took no time to find Radio time station transmitter by HennerZeller. It worked wonderfully using nothing more than three resistors and a loop of wire. Instead of leaving the perfection alone, I decided to mess a bit with it.

First of all, I decided to put all components of HennerZeller’s design onto a PCB. Already with this change things got even simpler as the only external element was the antenna wire. So I attempted to remove even that using PCB trace. And here comes the first issue - if you want to make a proper antenna for WWVB at 60 kHz, you need quite a long trace. About 1.25 km for the quarter length. A bit too much for a PCB.

However, same principle as in the original design applies. If you’re ok with making a really bad antenna, any loop will do. And bad antenna has unexpected benefit - it will limit range of transmitter. Since we want to keep emissions under 40 μV/m as measured at 300 meters in order to keep FCC happy, having an imperfect antenna is really a good thing. Moreover, since watches were designed to work with weak signal, better antenna might cause issues at close range.

It did take me a few tries to figure out the exact geometry to make it work. I found that 13 loops in rectangular area allows for up to 10-20 cm (4-8 inches) of working distance. If more distance is required, PCB also includes a connector for external antenna. While transmitting longwave is troublesome, one could look into a loop stick or even a spiderweb antenna.

When it comes to PCB, one thing that immediately grabs attention is its wonky shape. Overall dimensions were clear to start with as I wanted to match Raspberry Pi zero footprint. And as long as one makes 65x30 mm rounded rectangle PCB, you have it. Since full size Raspberry Pi can take smaller boards, one would think that there’s no need for messing with it further. Until you try to put it into the official Raspberry Pi case.

Due to how the official Raspberry Pi case connects together, rectangular PCB hits side pillars and prevents it from closing. Further more, there is a camera connector underneath it so notch is needed to allow easy routing. Due to both these issues, the actual PCB got a few curves and a slim down on sides where it would interfere thus giving it the final shape.

The end result is a WWVB transmitter fully compatible with HennerZeller’s design and software fitting nicely into an official Raspberry Pi case.

PS: While this device complies with FCC rules for low power transmitters, that doesn’t make it legal in every other country. Do your research before using it._

PPS: If you’re interested in building your own, you can grab source files from GitHub or purchase kit here.

Overthinking UART Pinout

Quite a few of my boards have a 4-pin UART output. And it’s always the same: [TXD GND RXD VCC]. But this pinout seems strange to quite a few people. I promise, there’s a method to the madness.

First of all, what is the most common UART pinout and why don’t use it? Well, the most common output I’ve seen on other people boards is [VCC RXD TXD GND] and I hate it because it’s really unforgiving if you accidentally plug it the wrong way. When I started playing with electronics, I used to use this pinout and, after frying a couple of boards, I’ve learned to triple-check that I don’t plug it rotated 180°. Even so, it still makes me nervous.

The other common pinout I’ve seen around is [VCC GND RXD TXD] and this one is slightly better as you can safely rotate it 180°. When it comes to common accidents (180° or off-by-one), it’s really hard to fry the board using this one. But this pinout also has its twin brother [VCC GND TXD RXD] thus ensuring you need 1x1 Dupont connector for each wire.

For my “standard” pinout I wanted to be able to easily switch TXD and RXD lines. Since UART really needs only three pins, it was clear that the first three pins had to be [TXD GND RXD]. This way rotating 180° allows you to connect two cables together allowing for point-to-point connection.

In order to provide power, I just added the extra pin for the final [TXD GND RXD VCC] pinout. If you accidently rotate it 180°, nothing happens. If you plug it off-by-one, nothing happens. And, if you don’t need power, you can plug only the first 3 pins and everything still works.

It’s as full-proof as it gets for me.

Calculating Mean for Microchip PIC

Averaging ADC readings on microcontroller is often needed but also often quite problematic. The easiest way to do it is remembering the last N values, summing them together and simply dividing by count. Simple, reliable, and uses a BUNCH of memory. If you want to store 50 16-bit values, you will need 100 bytes. When dealing with Microchip PIC, that’s a fortune.

However, if you’re ok with a mean rather with an average, there’s an easier way (and I would argue that mean is a better measure anyways in 90% of cases). You can use Welford’s online algorithm to get mean value using only 3 bytes of static storage and a few bytes more when executing. Of course, use of such algorithm in microcontroller environment will require a bit of a trade off (the least of them is me using average and mean interchangeably further down in post).

For my case, I assumed I need it for unsigned 10-bit ADC values. In the context of Walford algorithm, this means my intermediate values can be up to 15-bits (16-bit signed integer is needed internally) and this leaves 5 bits to use as a fixed decimal point. My case also called just “averaging” a handful of values, so I was ok with a 8-bit counter.

This means my variables are as follows:

uint8_t walfordCount = 0;
int16_t walfordMeanEx = 0;

As compared to the standard Walford’s algorithm, a few things are different. First of all, if we have more than N entries, it will reduce count to half over and over again. This trickery is allowing for “sorta” running average. And yes, you shouldn’t really use Walford’s for running average but it’s close enough. Secondly, when adding the value into the internal variable, we convert it to the signed integer and shift it 5-bits to simulate a decimal point. The only expensive (in CPU terms) operation here is dividing by count as everything else is quite cheap (shift, subtractions, and comparisons).

void walford_add(uint16_t value) {
    walfordCount += 1;
    if (walfordCount > WALFORD_CUTOFF) { walfordCount >>= 1; }
    int16_t delta = (int16_t)(value << FIXED_DECIMAL) - walfordMeanEx;
    walfordMeanEx += delta / walfordCount;
}

To get a value out, we just shift variable 5-bits back to remove the “decimal point”.

uint16_t walford_getMean(void) {
    int16_t value = (walfordMeanEx >> FIXED_DECIMAL);
    return (value > 0) ? (uint16_t)value : 0;
}

And that’s it. It’s a cheap (memory-wise) way to get an average on a 8-bit microcontrollers. As compromises go, I had worse.

In any case, you can download code here.

Why My Serial Port Device Is Detected as a Mouse

When designing electronics, probably the easiest way to make it communicate with a computer is to connect it as a serial port. However, occasionally you might see your device detected as a serial mouse instead of a plain serial port. When this happens the device will obviously not work and you might even see your mouse cursor jump around.

This behavior is an artefact of how Windows detect a serial mouse since that was written way before plug’n’play times. Widnows will first raise DTR and RTS signals and then monitor if there’s an M or B character coming at 1,200 baud. If either character appears, congratulations - your device is now a mouse. And anything it sends will be processed as if it was a mouse action.

There’s a brute force solution of disabling serial mouse in registry and that would honestly be the easiest way around. However, what if you cannot modify the registry? What if you need to make your device work in the face of an unknown machine? Well, there are certain tactics you can employ to either make this behavior unlikely or avoid it altogether.

The simplest solution of not sending M or B will unfortunately not work as easily. Yes, if your device works at the 1,200 baud rate, avoiding those characters will be fine. But if your device works at faster baud rate (and it probably does) the other end receiving at 1,200 will misunderstand its output. Depending when the actual bit sample is taken and what your device is actually sending, you might see an offending character appear either every time or every 10 times. Even worse, the frequency of the issue might change depending on the computer or even the room temperature. So, not really a solution.

The second obvious choice is detecting DTR and RTS combination and pausing whatever output your device gives until that state passes. If you can afford this, it’s a great and surefire way to sort the issue out as DTR and RTS are not baud rate sensitive. The only problem happens when you need those signals for flow control or for something completely custom. Even if you’re not using them they’ll still “cost” you two pins.

The most practical way I found of stopping this issue is by having device not speak until spoken to. If you design your serial protocol so that a device must receive a valid command before it will send any data, it will pass serial mouse detection unharmed. And, if you really need a streaming output (a perfectly valid requirement), just use a command to turn it on. If you can additionally somehow get CRC check into your protocol, the world is your oyster.

Framework Expansion Board

One of most exciting recent developments in laptop world for me is definitely the framework laptop. A major component of that concept are its expansion cards. And, of course, you can build your own.

This repository is quite encompassing if you’re using KiCAD. However, for those who love nicer tools (ehm, DipTrace), it’s annoying to find that there is no board size specification in human readable format (and no, KiCAD XML is not). So I decided to figure it out.

To cut the long story short, here are the board outline points for the expansion card PCB:

• (0.0, 0.0)
• (26.0, 0.0)
• (26.0, 26.5)
• (25.0, 26.5)
• (25.0, 30.0)
• (17.7, 30.0)
• (17.7, 28.0)
• (16.0, 28.0)
• (16.0, 29.0)
• (10.0, 29.0)
• (10.0, 28.0)
• (8.3, 28.0)
• (8.3, 30.0)
• (1.0, 30.0)
• (1.0, 26.5)
• (0.0, 26.5)

In order to make it slightly nicer to handle, each corner is additionally rounded with a 0.3 mm radius.

And let’s not forget two holes at (1.7, 10.5) and (24.3, 10.5), both with a 2.2 mm diameter and 4.9 mm keepout region.

With that information in hand, one can create PCB board in any program they might prefer. Of course, I already did so for DipTrace and you download the files here.

And yes, PCB is just a first step in a development process. What I found the hardest is actually getting appropriate connectors for the enclosure as there’s not too much height to work with.

PS: No, I do not own framework laptop at this time. I am waiting for 15.6" model as 13.5" is simply too small for me when not used external monitor.

Battery Pack Load

Powering device via USB has its advantages even if device doesn’t need connectivity. Most notable of those advantages is a wide availability of USB battery packs. That makes powering device really easy. However, what if your device uses so little power that batter pack keeps turning off?

All three battery packs I had available had the same issue. Put something that pulls just a trickle of current and they would turn off. One of them did have a trickle-charge functionality and that sorta worked but required manual intervention. And yes, I forgot to turn it on more times than I care to remember.

So I went looking for solution and found Dorkbot PDX article by Paul. The way how he solved this issue was quite a nice one. Just put intermediate load on the bus and you’re golden. Instead of going with his solution, I decided to use my favorite hammer - Microchip PIC microcontroller - to make my own board using the same concept.

Realistically, there’s no reason to use microcontroller for this. Having a programmable part just introduces assembly complexity and you cannot use it out of box, without programming it first. But there are advantages too. The major one being adjustability and that came in really handy when figuring out the timings needed. Instead of dealing with large value capacitances, one can use inherit time keeping mechanisms of microcontrollers. Furthermore, it also allowed for easy placing of blinky light. And who doesn’t love those?

The whole solution is based on a small 6-pin PIC10F200 microcontroller. When you discount programming pins, that leaves you one pin to work with. And yes, you can pretty much use programming pins too (3 of them) if you use a few extra passives but I generally leave them alone if I can. Fortunately, application I had in mind was simple enough to solve with a single pin.

The device logic is as simple as it gets. To keep the battery pack turned on, it uses MOSFET to pull 200 mA over two resistors for about 20 milliseconds. Once pulse is sent, wait for 10 seconds. Rinse-repeat. On all packs I’ve tried this combination worked flawlessly. Of course, if there’s a pack where this doesn’t work, adjustment is easy enough (yes, I will update code with some constants later :)).

The heavy lifting is done by MOSFET driven directly by microcontroller. Once turned on, it will allow two resistors to dissipate a bit over 200 mA of current. While this seems like a significant amount of power to pass over puny 0805 resistors, short duration means they will never get hot enough to present a problem.

One could also take an offense to how MOSFET is driven too. Due to the nature of the beast a lot of current will flow out of the gate pin and by common knowledge one has to have a resistor to limit it. However, this MOSFET is small enough that current limiters built-in to Microchip PIC microcontrollers are fine. I had even bigger MOSFETs work in circuit for years without gate resistor so I am not too worried. That said, if I ever change to different microcontroller, some reevaluation will be needed.

And yes, there is no bleed-off resistor on MOSFET gate either. If circuit is powered on, PIC will be driving it either low or high so pulling the MOSFET gate down is not really needed. If circuit is not powered on, who cares - there’s no power to go around anyhow. That leaves only the short amount of time when circuit is powered on and PIC is not yet driving the gate. And that is the interval we can safely ignore as it’s shorter than 20 milliseconds and even erroneously active MOSFET will cause no damage to the circuit in that time.

Thanks to Microchip’s semi-standard pinout, this device can use any number of PIC microcontrollers. As long as footprint fits (SOT23-6), you’re golden. I have tried it with already mentioned PIC10F200 and PIC10F320 but any variant should work too. Yes, the firmware did need a bit of adjusting between methuselah PIC10F200 and newish PIC10F320 but those were simple enough. In these times of chip shortages, having multiple parts fit is always a nice thing.

How much battery this uses, you might ask. It would be a bit annoying to have your battery drained by a device whose only purpose is to keep it awake. Well, to start with, we need to account for all power usage. The main one is of course our 220 mA pulse (5V/(47Ω÷2)) lasting 20 milliseconds. Since it repeats every 10 seconds, that leads us to a duty cycle of 0.2%. Multiply one by another and we can see that average power usage is about 0.5 mA.

Second power user is our LED that blinks with the pulse. Due to large value resistor, it will require slightly less than 1 mA for each pulse. Using our duty cycle, that us average consumption of 2 µA (0.002 mA). Pretty much a noise compared with our load.

And lastly there’s the PIC itself. Good news is that this is well under 1 mA. How much under? I have no idea as I didn’t have anything capable of measuring it. I will definitely need to create a board for that too. However, I did use USB power meter to get a long term reading of the usage and it was slightly under 0.5 mA (averaged over an hour) if using PIC10F320. For older PIC10F200 usage is a smidgen above it.

Those reading more carefully might wonder, if a power pulse needs about 0.5 mA, and total consumption is under 0.5 mA, we have the free energy as microcontroller is actually using the negative power from a far dimension to run itself. Sadly, it’s not so. Due to how MOSFET is driven, it won’t turn on nor it will turn off instantly. So our 200 mA pulse average will actually be lower. And PIC consumption is low enough to “hide” in those numbers.

Code actually runs constantly in the background due to a quirk of PIC10F200. If you put it in sleep, it resets itself (by design) making it annoying to keep track of time longer than 2.3 seconds. I was toying with idea of just using the newer PIC10F320 but power usage of constantly running PIC was low enough that I decided not to care.

Either way, if you have 10000 mAh battery, this device could theoretically run for 20000 hours. Suffice it to say that it shouldn’t reduce battery life too much. If you really want to squeeze the last possible mAh out of it, you could adjust timings. For example, my Anker power bank was quite happy with more than a minute between pulses (0.033% duty cycle). However the default 0.2% duty cycle is probably a good starting point when it comes to compatibility.

Lastly, there are actually two versions of the device. The “normal” one just plugs in USB port while pass-through has a female USB connector on it allowing it to be used on battery packs with a single type A output. You can find gerbers for both on GitHub alongside with the source files.

Dealing with part shortage - Microchip edition

For a small electronics project of mine, I needed literally only one output pin. My go-to part for these situations is PIC10F200. It’s a 6-pin SOT-23 device offering internal oscillator and not much more. Microcontrollers don’t really get smaller/simpler than this.

Due to the hamster habits I have, I actually had enough enough parts to finish up the prototype so the only thing left was to order a few more parts of DigiKey. Well, as many components lately, my favorite PIC was out of stock.

However, when one door closes, another one opens. Microchip is really good at keeping pinout similar over multiple microcontrollers. And DigiKey had PIC10F202, PIC10F206, PIC10F220, PIC10F222, and PIC10LF322 available in stock. While all these PICs are slightly different, they share the same basic pinout. And for my project any of them would do. Even if I used some less common feature, Microchip often has multiple products differing only in memory amount.

While hardware might be similar enough, firmware does have significant differences - especially between older PIC10F206 and newer PIC10LF322 setup. Even turning LED on/off uses different registers between them. Instead of having different firmware for each, one can make use of compiler directives and check which PIC is actually being used. Something like this:

#if defined(_10F200) || defined(_10F202) || defined(_10F204) || defined(_10F206)
    GP2 = 0;                // turn off GP2
    TRISGPIO = 0b11111011;  // GP2 is output
#else
    LATAbits.LATA2 = 0;    // turn off RA2
    TRISAbits.TRISA2 = 0;  // RA2 is output
#endif

While out-of-stock syndrome has hit Microchip too, with a bit of care, they do make transition feasible if not always trivial.

Adding USB to A-BFastiron SS-305MP

I needed a cheap power supply for a project and it was easy to find a nice one in A-BFastiron SS-305MP. It was small enough, looked good, and had shiny display. What could man want more?

Well, when I got it and saw cutout for USB, I know what more I wanted. An USB port.

And strangely enough once you open the power supply, you’ll find connector providing about 8.2 V already there without anything to plug into. It’s almost as if somebody placed it there to be an input for 5V linear voltage converter and then later figured electronics and heatsinking would cost too much and covered the hole. And yes, it’s a proper hole cover that you can remove - no drilling necessary.

If you open power supply you will even find standoffs already in place. It’s simply begging to have PCB mounted in.

First thing to figure out was which USB connector will fit. Searching on DigiKey found quite a few of them roughly matching the dimensions. So I just selected the cheapest one that matched standard footprint. And yes, looking on side you might find it protruding a bit too much but not criminally so. It might be original designers were fine with this or the had a custom length connector in mind. For me this was as good as it gets.

With connector found, it was time to figure PCB. And I decided to keep it really simple. The whole setup would revolve around VXO7805-1000. It’s a nice DC-DC switching regulator that will take any input higher than 8 V and drop it down to 5 V with some efficiency. In its pinout it emulates beloved LM7805 but at 90% efficiency and without all the heat.

Regulator itself requires just two capacitors and I decided to go just with them. I was tempted to add a smaller 1 µF capacitor to output and maybe even a 100 nF one for decoupling purposes but decided against it. Due to wide variety of cables and outputs USB device might face, all of them already have more than sufficient decoupling and adding more wouldn’t really do anything. So why waste a component.

The only really unneeded components would be an LED and its accompanying resistor. While they serve no function, I really love to have an indicator of output. If there was ever an issue, looking at LED would at least tell me if power is going out. And quite often that’s quite a big help.

Speaking of power going out, I don’t consider a fuse optional. It’s a minimum you need in this setup. Another thing I would consider bare minimum for power supply would be a short-circuit detection but that’s fortunately already a part of voltage regulator. And yes, I could have gone further, especially by adding reverse polarity protection to the input and I was tempted but in reality you’ll just connect this thing once and leave it connected. As long as you connect it correctly the first time, you’re good.

Connecting all this to the power is entrusted to any JST-XH 2-pin cable - 10 cm in length. Just make sure that the negative wire is going next to COM marking on the power supply motherboard. If in doubt, just double-check with voltmeter.

And that’s it. For a few bucks more and some extra soldering, we have a nice 500 mA USB port at the front of the power supply. Just in case we need it.

On GitHub you’ll find source files and releases with gerbers and part list.

Changing A-BFastiron SS-305MP Binding Posts

I needed a cheap power supply for a project and it was easy to find a nice one in A-BFastiron SS-305MP. It was small enough, looked good, and had shiny display. What could man want more?

Well, how about proper binding posts?

And no, I am not only talking about quality albeit one coming with it are quite flimsy and it already arrived with one cracked. I am talking about spacing. I simply hate when binding posts don’t observe standard ¾" distance between them.

And this power supply almost had it right. I measured spacing to be a smidgen over 20 mm while standard would call for 19.05 mm. With such a small difference, there was literally no reason to go non-standard. But non-standard they went.

If you open the power supply, you’ll see that binding posts are held by the PCB in the back. Thick wires are soldered onto it and nuts are used to connect to posts themselves. So the whole operation can be done with a simple PCB update with correct spacing. Only thing needed extra is a bit of filing action and you can reassemble it all.

However, since my binding post was already cracked, I decided to swap them for Pomona 3760 (black and red) set. But that brought another issue - panel cutout for them is completely different. And yes, a patient man might shape it enough, but for those with 3D printer there’s an easier solution.

To mount it all, I used some nice red MH Build PLA to print really tight mounting base and spacer for posts.

After filing plastic a bit to expand holes toward each other, I placed binding posts into the printed base, pushed it through the hole, used another 3D printed spacer on inside and added some more height to set using spacers that came with binding posts themselves. Then in goes the custom PCB and finally all can be fastened using lock washer and nut that cane with posts.

Result are nice binding posts at proper spacing. :)

On GitHub you’ll find source files and releases with gerbers and part list. 3D model can be found on TinkerCAD.

PS: The only downside of Pomona is that it uses ¼" imperial nuts while the power supply originally had 7 mm nuts. So, in addition to metric socket set you already have, you’ll need a witchcraft-sized set too.