Type-C Power Delivery as Passive PoE Source – Fixes

This is part 2 out of 3 in the series. PCBs were sponsored by PCBWay.

The first version of any project is rarely without faults. And this one is not an exception.

The simplest issue has been me simply forgetting to wire up enable lines on 74HC238D decoder. I assumed, for no good reason, that lines were enabled by default. Thus, no matter what my code did, LEDs stayed dark. After a bit of probing and seeing correct voltage on input, I decided to check the datasheet again and saw the issue almost immediately. A fix required two wires though, as G2A and G2B lines required pull-down while pull-up was required for G1.

The next issue I noticed was that my internal button wouldn't work. I knew of this risk since, due to pin shortage on PIC12F1501, I ended up using this pin as both input and output. As the microcontroller was booting, I wanted to detect button presses so I can put it into configuration mode. If the button wasn't pressed during configuration, I would simply use the same pin as power-on signal input towards the transistor. Well, in theory, that should have worked. In practice, I had it pull to ground via an external base resistor. In order to keep the transistor at a known level when the line is input, I used my bodge powers to make the button pull the line high when pressed. Here is where my habit of connecting only two legs of the four-legged button actually helped as I was able to simply snip off one leg and solder 3V3 to another.

With the configuration mode sorted out, I started switching voltages only to find out that I am maxing at 9 V. I could select 5 V just fine but no matter what higher voltage I selected, CH224K would give me 9 V. It took me a while and a lot of datasheet deciphering (Chinese-only datasheet didn't help) to understand what was happening.

You see, there are two ways you can configure CH224K. You can either use 3 CFG lines to set the desired input state in binary or you can use a resistor on CFG1 line alone. My 10K series resistor made the chip think I was using a single-resistor setting. 10K was close enough to 6.8K so that's where 9 V came from. In 5 V mode, I had that pin pulled high, and that was enough to stop the single-resistor setup. The solution was to remove series resistors altogether. Ironically, I didn't actually need them but decided to place them anyhow to help with troubleshooting.

One thing that definitely did help with this troubleshooting was the quality of the PCB. For example, while trying to troubleshoot my voltage settings, I soldered and resoldered CH221K multiple times. Since ground is on the pad that is inaccessible to a soldering iron, I had to reheat the board multiple times. I honestly expected to damage the solder mask after the second time getting it to 300 °C. And while the smell wasn't the best, the PCB handled it without problems. Yes, you can damage the solder mask if you really want to but it will take a lot more than heavy-handed rework to do so.

With bodges sorted out, the next step will be to update the firmware.

Gone cold

On paper, there's little not to love about Pinecil v2. It's a nice portable soldering iron, it uses low-ohm tips allowing for quick heating, uses the sweet type-C power, and at $25 it's quite a deal. Do I need another soldering iron? Not really. But such deal was simply too tempting to pass.

As it often happens, my enthusiasm led me to buy two irons, some extra tips, nice silicone type-C cables, and even the darn replacement tip contacts. And no, I didn't buy both for myself - one I figured was a perfect present for a friend.

The shipment arrived reasonably fast and I immediately tested it. I still preferred my KSGER but the Pinecil seemed quite usable when I needed to solder something quickly without getting the big guns out. I definitely believe there is a place in my arsenal for something like this. However, in a practical sense, it would always be my second choice. Thus, over a 3-month period, I found myself using the Pinecil only a few times.

And then it came time for some microsoldering on Framework HDMI Expansion Card. It was a single-wire mod but QFN package made it ideal work for the Pinecil. So, for maybe the 10th time in 3 months, I inserted its soldering tip, plugged it into a type-C charger, and... nothing. It was bereft of life.

After trying a fAfter attempting several solutions suggested online, I finnally contacted Pine64 support. They responded almost immediately, asked me for order number and requested pictures of my power supply, only to follow up with an extended silence. After a week or so, I got bored and pinged them to see what the status is, only to be informed that the warranty for the Pinecil was merely one month and there was nothing more they could do.

I don't care how cheap the product is but 1 month warranty is not acceptable. Either you stand behind your product or you don't. By having warranty match no-questions-asked-return period offered by most retailers, it's clear that they're doing the bare minimum. I would argue that a one-month warranty equates to virtually no warranty at all.

Should have I known that before I made the purchase? Maybe. Maybe not. But as I am in the market for a new portable soldering iron, one thing is certain: my new portable iron will not be a Pinecil. Not because it died - that happens. It's purely because I know I cannot count on company for any support. And if they're not willing to support their customers, it's reasonable to assume they're doing the bare minimum with their manufacturing process as well.

Are other portable soldering iron companies the same? Possibly, but that remains to be seen. However, with the Pinecil, the adage "buy cheap, buy twice" certainly proved true. And at $50, it's not exactly a budget device anymore.

PS: My friend's Pinecil still works. Alternatively, maybe it died but he's too thoughtful to tell me. :)

Type-C Power Delivery as Passive PoE Source

This is a part 1 out of 3. PCBs were sponsored by PCBWay.

A long time ago I decided upon passive 48 V PoE for my network. Choice was made due to both hAP ac and Audience access points supporting up to 57 V. Thus 48 V was closest lower standard value with a reasonably priced power supplies. However, this decision came to bite me in the ass with my new hAP ax³ supports going only up to 28 V. Placing it into my network would lead to a lot of sparking fun. What I needed was a lower voltage.

Well, the next logical step was switching to 24 V. However, buying two 24 V power supplies (one to use, and one for backup) allowing for 60 W was actually not that cheap. Since I had bunch of leftover power supplies, I started to wonder if I could use something I already have.

Yes, I could have used one of vendor-specific laptop power supplies but that would involve cutting cables as their connectors were anything but standard. The only standard connector I had was type-C. And then it hit me. Why not simply use power delivery to get 20 V out of it?

Realistically, probably the easiest in-place replacement was one of many prebuilt cables out there. And I think this is the best way to go if you just need power. But, for my home setup I connected PoE over ResetBox device which allows for an easy power reset. Wouldn't it be really nice if I updated ResetBox to directly use type-C?

And no, ResetBox is not just a simple switch albeit it offers essential functionality of one. Its a bit smarter than that as it contains microcontroller that gets to control a relay. For example, it will ignore short, accidental, presses and allow reset only when held for 3 seconds. Ideal for controlling things you don't want to reset by accident - for example your home wireless network.

For this update it would be ideal to switch input to type-C, allow for on-board voltage selection (5 V, 9 V, 12 V, 15 V, and 20 V), and lastly have a nice way to indicate the selected voltage.

With that in mind, the first task became selection of PD chip. It is possible to control PD on your own but I quickly decided against it as setting it to function right with various PD and non-PD type-C devices would take ages. No, I wanted something standard.

Quick search quickly pointed toward IP2721 as a reasonably easy to (hand)solder device used in many existing triggers. However, its package was a bit on a large side and voltage output was quite limited since it only supported 5 V, 15 V, and 20 V operation. Definitely not a full set of voltages I wanted. And yes, you could get lower voltages by using IP2721_MAX12 variant but then you lose the higher voltage options.

Second device I found was HUSB238 and I immediately liked its SOT33-6L variant. Unfortunately, this easy-to-solder variant was nowhere to be found for purchase. Even worse, the chip didn't support the full PD 3.0 5A operation. Yes, probably not a deal-breaker for this particular scenario as 60 W was plenty but still no ideal for a new design.

After quite a lot of additional search I stumbled across CH224K. Not only it came in (seemingly) easy to solder ESSOP-10 package but it also supported easy control. Based on a few examples I found it seemed possible to tease the full 100 W with it.
The datasheet also mentions an even more appealing CH221K in the SOT23-6L package, but I had difficulty finding it in the market. On the other hand, the ESSOP-10 variant was readily available all over AliExpress.

With chip selected, the second order of business became figuring out how to connect all this. With only 6 I/O pins available, the current PIC12F1501 was a bit crowded. In addition to 1 button input, 1 LED output, and a 1 relay output it already handled, I would add 3 outputs for voltage control (also used to show LEDs status). Total of 1 input and 5 outputs. Not comfortable but just enough.

Originally, ResetBox had the option to handle AC input. However, with type-C, this is no longer necessary, so we can replace the relay with a small P-MOSFET and completely bypass the diode bridge. We don't control this MOSFET directly, but rather via a small NPN transistor. This approach serves two purposes: first, it prevents our PIC from seeing 20 V at any given time, and second, it allows the PG signal to override the output (i.e., no PG, no voltage).

While originally ResetBox had option to hadnle AC input, with type-C we don't need this anymore and thus we can replace relay with a small P-MOSFET and omit diode bridge altogether. We don't control this MOSFET directly but over a small NPN transistor and that's for two reasons. First one is to avoid our PIC seeing 20V at any point in time and the second reason is allowing PG signal to override output (i.e. no PG, no voltage).

The power supply for the main PIC is managed by an LDO. While this approach does waste some energy, it's not too significant as the PIC won't need more than roughly 20 mA. For such a small current, it simply wasn't worth opting for a switched-mode regulation. I considered using a 5 V LDO despite the input being at 5 V, but chose to make the smarter decision and go with 3.3 V instead. And yes, I did test the 5 V LDO in the same circuit and it worked, albeit with a slight voltage drop.

For PCB creation I chose PCBWay and they generously provided me with free PCBs. As it's common with my projects, I don't really push the boundary of what's possible but there were a few non-standard things with this PCB. The first one was its thickness as I needed 0.8 mm due to type-C connector. The second one were really small holes for the same. And yes, this was quite well within the specification but I actually had issues with this when it came to other PCB manufacturers.

But more about that the next time when I go over all the things I've botched during the PCB design.

Latest design is available on GitHub

Native ZFS Encryption Speed (Ubuntu 23.04)

Well, Ubuntu 23.04 is here and it's time for the new round of ZFS encryption
testing. New version, minor ZFS updates, and slightly confusing numbers at some

First, Ubuntu 23.04 brings us to ZFS 2.1.9 on kernel 6.2. It's a minot change on
ZFS version (up from 2.1.5 in Ubuntu 22.10) but kernel bump is more than what we
had in a while (was kernel 5.19).

Good news is that almost nothing has changed as compared to 22.10. Numbers are close enough to what
they were before that they might be a statistical error when it comes to either
AES-GCM or AES-XTS (on LUKS). If that's what you're using (and you should), you
can stop here.

However, if you're using AES-CCM, things are a bit confusing, at least on my
test system. For writes, all is good. But when it comes to reads, gremlins seem
to be hiding somewhere in the background.

Every few reads speed would simply start dropping. After a few slower measurements,
it would come back where it was. I repeated it multiple times and it was always
reads that started dropping while writes would stay stable.

While that might not be reason not to upgrade if you're using AES-CCM, you might
want to perform a few tests of your own. Mind you, you should be switching to
AES-GCM anyhow.

As always, raw data I gathered during my tests is available.