Reconnecting HDMI

Switching my media PC from Windows to Bazzite went awfully uneventful. No issues whatsoever. At least for a while.

My media computer is connected to TV courtesy of type-C HDMI output. And I verified heck out of it. Computer’s output worked flawlessly with TV.

However, once TV was off for a while, turning on TV would result in “No Signal” message. At first I though it was sleep, but no. Computer was still reachable via network and it would all start working after reboot. A lot of troubleshooting later and I found a pattern, courtesy of DP status:

cat /sys/class/drm/card1-DP-2/status

If I run it while TV was on, I would see connected status. If I turn TV off, I would still see connected status. But, once I turned TV back on (after some time has passed), status would change to disconnected. And nothing I’ve tried to do over network helped. Well, nothing but one thing.

If you ever used Ctrl+Alt+Fx keys, you saw virtual terminals in action. Most of the time we only do stuff on the first terminal, but other terminals are sometime handy too. Switching to other terminal would actually reset connection every time. And that is something you can do from the command line.

chvt 2
sleep 1
chvt 1

Figuring it out was the first part. While I now knew how to recover connection to my TV, having to do it every time via network was annoying. I wanted something automatic.

The first step was creating script in /usr/local/bin/dp-reconnect:

#!/bin/bash

function status() {
    for DP_PATH in /sys/class/drm/card1-DP-*; do
        DP_STATUS=$( cat "$DP_PATH/status" | grep '^connected$' | xargs )
        if [[ "$DP_STATUS" == "connected" ]]; then
            echo "Display $( basename "$DP_PATH" ) connected"
            exit 0
        fi
    done
}

status
echo "No connected displays"

chvt 2
sleep 1
chvt 1

status
exit 1

Next step is to create service definition at /etc/systemd/system/dp-reconnect.service:

[Unit]
Description=Switch terminal if no DP is connected

[Service]
Type=oneshot
ExecStart=/usr/local/bin/dp-reconnect

And lastly, we can create timer in /etc/systemd/system/dp-reconnect.timer:

[Unit]
Description=Switch terminal if no DP is connected

[Timer]
OnCalendar=*-*-* *:*:00
Persistent=true
AccuracySec=1s

[Install]
WantedBy=timers.target

With all files in place, the only remaining task is to enable the timer.

sudo systemctl enable --now dp-reconnect.timer

With all in place, if display gets disconnected, script will reconnect it within a minute. Not perfect but lightweight enough not to be a serious hassle.

The 5-pin RS-232 Framework Expansion Card

My previous RS-232 Framework expansion card worked like a treat for 90% of use cases. Due to historical reason, most of RS-232 communication was limited in moder times to just TX and RX lines. But ocassionally one would also benefit of the hardware synchronization. And my expansion card had none.

Once I decided onto hardware control, question was which one. Due to historical reason, there are two distinct ways you might employ hardware to control flow: RTS/CTS and DTR/DSR. Ideally I would have supported both but instead I opted to support only more common (and more modern) RTS/CTS. Why?

Well, the first reason is transciever. I love to use MAX232-style transcievers and they offer only 2-in and 2-out lines. Could I have changed which transciever to use? Most definitelly. There are different transciever that support full 4-in, 3-out signals needed for a full RS-232. However, MAX232 is well understood, has a bunch of “clones” that are equaly good, and it’s pretty much trouble-free. While back in days I ocassionally strayed into other RS-232 transcievers, I was almost always sorry later.

The second reason is the connector. Adding 2 extra lines would bring connector to 7 pins and that size would require moving LEDs from edge since I wouldn’t have enough PCB remaining. If we go further and add a CD line needed for full RS-232 (yes, I am ignoring Ringo as people often do), connector would even lose its symetry. Restricting oneself to 5-pin RS-232, is much more reasonable choice.

With the new design sorted out, it was time to get PCB. And PCBWay didn’t disappoint. With framework expansion cards, the standard edge routing bit will be too large. I’ve had mixed luck with oother PCB suppliers but never with PCBWay. They always switch to a smaller edge routing bit and produce a perfect PCB. Not sure if it’s human checking that triggers it, or it’s good automation, or maybe they tend to use smaller bit than USA does by default. Whatever it is, they never messed up my board.

This time I also wanted to try their 3D printing service and they didn’t disappoint. Prints I received were perfect in all ways. If you ever printed Framework card case, you know that side rail features are easy to mangle without supports. Your printer really needs to be dialed in. With PCBWay all prints I receved had perfectly embossed text on the bottom and side rails that were perfectly sized and smooth.

Since I wanted to compare their print with what comes out from my printer, I opted for the basic PLA. That means you cannot expect print to be without visible lines. That’s just a nature for the process and if you mind them, resin prints will probably work better for you. But I can definitelly say that even this PLA print was better than what I produce.

Now, the difficult question is whether it’s worth it. Prints that I got were cheap but definitelly not as cheap as printing at home. Depending on your printer, it might take a bit (or more) of effort to get results close to what PCBWay provides and that’s before even considering shipping or tariffs. But, for resin prints, my calculation slightly changes. PCBWay provides basic resin printing at lower cost than PLA. Combine that with a general “messiness” of resin printing and hardening and you have a reasonably priced alternative. Yes, shipping and tariffs still blow but for ocassional print you are better off than buying resin printer and all chemicals yourself. While I might not be the perfect fit for this service, I am glad it exists and I do plan to use it again in the future.

Here is where I would usually say that you can get card from my store but it was not meant to be. Even though this was a second PCB for this release (I forgot to select 0.8mm thickness the first time), I made a considerable blunder. I accidentally swapped CTS and RTS lines. Doh!

Mistake was trivial but not really easily fixable by a bodge wire. I am reasonably sure there are no other mistakes but I won’t know until I get new PCBs. Until then, this will be a Schrödinger’s project. Both completed and not, at the same time.

The New Firmware

With all the changes in the AuxPower1U project, it was inevitable that firmware will change too. However, some changes were in order.

First was in regards to my PhotoMOS setup. While 6A AQZ202G PhotoMOS supports all I need, I only had 2 of them handy (actually, I started with 3, but we won’t discuss my testing procedures). So, I filled rest of channels with 4A CPC1706Y PhotoMOS. Why am I mentioning hardware in the firmware part? Well, part of my firmware is handling safety cutoffs. And those are not the same between all channels now. Yes, these are still hard-coded because I am too lazy to create GUI. But they are separated into a function so changing them shouldn’t be a chore. The first three channels have 4A safety limit while the last two have full 6A.

Another change was turning off display after a period of inactivity. While having it always visible was handy, it did cause degradation in cheap displays. After months of having it on with the previous display, burn-in was becoming a problem. Since I rarely check that display, it seemed like a good idea to simply turn it off until button press is detected. Cheap firmware solution for a hardware problem.

And lastly, I changed how output pins are handled. Originally, I handled them via I2C expansion which works like a charm. But, that introduces an extra device in what you might call a critical path. Since, due to other changes, I did have 5 pins available, in the new revision output is controlled directly from microcontroller without going to the expander board. As to preserve compatibility with the previous board, code sets both I2C and pins directly. That way both revisions can work on the same firware.

With all this, my AuxPower1U revision C was ready for “production”.

The New Controller

With the new case sorted out, I decided onto a new power supply controller. Since I recently ended in the possesion of a few PhotoMOS device, I figured to check them out. While my own high-voltage MOSFET switching does work, there is no real isolation between my control circuit and the output voltage. PhotoMOS brings that additional safety.

Changing to AQZ202G PhotoMOS required a major PCB redesign. Fortunately, controlling PhotoMOS was trivial and thus most of time was just figuring how to lay things out without changing PCB size. After hours of “playtime” in KiCad, I sent the new PCB toward PCBWay to manufacture.

Once I got my boards back, I decided to first test it with a cheaper CPC1706Y PhotoMOS. I though yhe only difference between Littelfuse and Panasonic ones was the maximum current. Panasonic supported 6A (which I needed for my 65W PC connectivity) while Littelfuse PhotoMOS supported 4A. Since my fist three power channels were low wattage, I opted to use CPC1706Y for them, reserving AQZ202G for the channel 4 and 5.

And all channels worked flawlessly. Heck, channels CPC1706Y worked even when they were supposed to be off. At first I though it was due to firmware changes I did. But, an embarassing amount of troubleshooting later, I noticed that there is one more difference between Panasonic and Littelfuse. Panasonic uses bidirectional MOSFET switch. Littelfuse does not.

That means that Panasonic doesn’t really care which connection is more positive. And, since I used Panasonic to create KiCAD footprint, I opted for easier routing. But Littelfuse cared which connection is more positive and I selected wrong. Well, after another hour or two of moving traces around I was ready for another go.

Since PCBWay has an action going on where you could get a purple PCB for no extra change, I decided to try it out. And, while coloring PCB is a gimmick without impact to electrical design, over time I grown to appreciate it. With PCBWay offering multiple colors, I always alternate them between orders allowing for easier distinguishing between revisions. It’s way easier to tell whether PCB is purple or yellow at a glance, than if revision is C2531 or C2536.

Combinination of purple PCB and white silkscreen is a really a classical one in a hobbyist circles and PCBWay doesn’t disappoint here. While it is slightly lighter shade of purple than OSHPark, solder mask is of equally same high quality. It handled my clumsy soldering like a champ. :)

All in all I am mostly happy with the new PhotoMOS solution. As compared to my MOSFET switching it offers way better isolation from the rest of my circuit. Heat is about the same which is not surprising. However, when it comes to cost, there is really no competition. Darn PhotoMOS devices are EXPENSIVE. If price is a major consideration, it’s a no-brainer to roll-your-own.

For my AuxPower1U controller, I think I am going to stick with PhotoMOS. They do offer isolation and they are much easier to control. And, since this project is not cheap due to quite expensive power supplies, increase in cost is bearable.

New case for AuxPower1U

My AuxPower1U project was over and all was great. But, one thing always annoyed me - the plastic enclosure. Don’t get me wrong, it is a nice enough enclosure when mounted. But, since power supplies do weight a lot, chasis flexes if unsupported. Not a big issue but not something I like. So, when I ran into a Cheval PF19AL1UD1, I immediately started eyeing an upgrade.

It is a 1U case, a slightly longer than Bud PRM-14460 - 200 vs 240mm. It has ventilated sides in addition to vented top and bottom plate. And it features internal box design with rack mounting being a separate element. While this might be excellent for some projects, I had a few issues with it.

The first issue was it’s box construction with rack mounting being a separate element. Since I needed to drill the front, this was annoyance. Thus I decided to simply omit front extrusion when mounting it. That way I only needed to drill one set of the front holes. As this change made top and bottom flimsy, I had to redesign aluminium plate mounting to stiffen it a bit. Once buttons are mounted, there should be no play.

Another issue I had was with vented top and bottom. While usually a great feature, they were killing my air flow setup. At the end, I just covered them from the inside with a wide duct tape so that air is forced over power supplies.

As luck would have it, all mounting solutions I did for the previous case would not fit this one. Aluminium plate couldn’t rely on central bosses because there were none. Also mounting controller and fans had to change too because there is now no real place to screw it. Mind you, mounting options are probably even better now - there are enough M3 holes available.

In the end, it took a few hours of reacquainting oneself with FreeCAD to get everything in place. And I believe it was worth it. Metal case just feels much better than the plastic one it does offer way more space because there are no protrusions in the middle the plastic case needs.

That said, it is more compliated to work with than the plastic. First of all, drilling is much more work. And, since there will be live AC power in it, grounding case properly is a concern. With powder coated case this means a lot of scraping to expose metal. Nothing too difficult but important not to forget.

But drilling and grounding is a problem for the future me.