## Weirdly clogged inkjet nozzle

30.09.2020 16:01

Recently I noticed some unusual red dots and lines on the printouts from my Epson L310. It was interesting because it seemed like extra dots were getting added to the paper. This is just the opposite of the usual problem of clogged nozzles. In that case, dots (or whole lines) are missing on the paper. The extra dots also looked well-defined and didn't look like ink was just getting smudged onto the paper by a dirty print head.

I've ran the nozzle check using escputil -n and this is how the test area looks like:

It looks like one magenta nozzle is spewing ink at an angle. At first I thought it was an electrical problem and somehow one nozzle got shorted to another. But this looks more like the ink from that nozzle gets deposited onto the paper a bit to the top and left from where it should be. The line from that nozzle looks a bit more blurry than the other ones, which also suggests that something is interfering with the ink flow.

I don't remember seeing something like that before. Anyway, I just thought that was interesting. So far it didn't bother me too much and maybe it will go away during printer's regular self-cleaning cycles. If it doesn't fix itself I'll probably try to clean it up manually.

Posted by | Categories: Life | Comments »

## Parking the CubieTruck

19.09.2020 15:30

Back in 2013 I bought the CubieTruck, a single-board computer based on the Allwinner A20 ARM system-on-chip. Soon after I got it up and running with Debian I began using CubieTruck as a tiny home server. I eventually migrated this blog to it as well after my other server was knocked off-line by ice. It's been happily running on a shelf for almost 7 years now and has been an incredible value for its original 100 € price. It has been showing it's age though and with Debian Jessie running out of security support it was time to move on. I had a spare Zotac CI327 ready as a replacement and a few weeks ago I finally managed to move the last services off CubieTruck.

My CubieTruck really had a very good track record as far as reliability goes. It currently has a 464 day uptime and in recent memory only got reset because of a short power outage. In its early days I had problems with CRC errors on the SATA bus. This mostly got resolved after I changed to stock cable that came with it with a different one. At least it never again caused filesystem corruption (that I know of). The UDMA CRC error count reported by SMART currently sits at 276. It still incremented by 1 every once in a while, most often when I was doing something in the physical vicinity of the CubieTruck. I suspect the SATA signal integrity was still pretty marginal, even with a different cable.

Unfortunately, the long uptime is also a symptom of the largest problem I had with it: hugely outdated kernel. The SoC requires running a special Allwinner fork of the Linux kernel and it was soon severely outdated. I'm very grateful that Daniel Andersen kept the kernels updated with upstream patches for as long as the 3.4 branch was officially supported by kernel developers. Still, the last released one which is running on it right now, 3.4.112, is ancient by modern standards.

There was an effort to merge all the required code to the upstream kernel. As far as I remember it did come to a point where running the upstream kernel was perfectly viable, but I never did it. The problem was that NAND flash was never well supported. CubieTruck boots off 8 GB of on-board flash. Without support for it in the kernel you can't access the boot partition from Linux, which in practice means no easy kernel updates, which is the whole point. The alternative is to boot off an SD card, but I wanted to avoid that at all costs.

The machine I'm replacing CubieTruck is a Zotac Zbox nano CI327. It is itself outdated at this point and has a quad-core Celeron N3450 and 4 GB of RAM. I've also installed a Kingston 120 GB SSD (SA400S37120G). Unfortunately I haven't done a comprehensive HTTP benchmark comparison like I did last time I moved my blog installation. Mostly because I forgot about it, but there's also the fact that I don't know how to properly benchmark a HTTP service anymore. Apache Benchmark I used last time doesn't give representative results because it doesn't support SSL session caching.

I did measure how long it takes to rebuild the blog though. This is a single-threaded Perl process that builds around 25 MB of HTML files. The following shows user space time as reported by the time utility. I recorded the fastest run out of three on each machine:

CubieTruck Zotac
CPU time to rebuild static pages 51.4 s 9.0 s

As you can see, Zotac really leaves CubieTruck in the dust in this test. The CubieTruck numbers here aren't comparable to my old test. Even though the method was the same, my blog now has more entries and hence takes more effort to build. Also, in my previous test the CubieTruck was still running of an SD card, before I installed a SATA SSD.

As far as HTTP performance goes, I did notice this nice drop in the page load time graph after migration to the Zotac. This is from a Munin plug-in that runs on some other host on the Internet and requests my blog's homepage. On the other hand, server's 90 percentile response times for regular traffic haven't changed noticeably. In any case, CubieTruck was already fast enough to handle HackerNews home page traffic without major problems.

In conclusion, CubieTruck has been a joy and one of those machines that leave a lasting good impression. Even though it's inviting to scavenge its SSD I will very likely keep it around in case I need an ARM build machine or something similar. As far as I know it is still one of the rare ARM-based single-board computers that has decent storage performance due to it's native SATA interface. It's unfortunate that later Allwinner SoC versions abandoned it. It was only recently that the new Raspberry Pis with USB 3 got significantly better throughputs, although I would still like to see some long-term reliability figures for USB 3-attached storage.

Posted by | Categories: Life | Comments »

## Transmission line mismatched on both ends

14.09.2020 20:30

In one of my previous posts I mentioned a result of a RF gain-versus-frequency measurement that looked like a sine wave. I said the sine wave probably means that there is some impedance mismatch in the measured signal path. I wasn't completely sure back then so I did a quick refresh on transmission line theory. Indeed, if you have a transmission line that is driven by a mismatched source and also has a mismatched load on the other end at the same time, the amplitude on the load will vary periodically in relation to the signal frequency.

Consider the following circuit. You have a sine wave source ug with a source impedance that has a reflection coefficient Γg. The source is connected through a transmission line to a load with its own reflection coefficient Γl. The transmission line has a characteristic impedance Z0, length d and propagation speed c. I've also marked the forward voltage wave in the transmission line uf and the reverse voltage wave ur.

We keep the amplitude of the signal source ug constant and vary the frequency. If we measure the amplitude of the signal on the load ul the amplitude will vary with applied frequency in a sinusoid like on the following graph. Note that the horizontal axis is frequency, not time. The vertical axis shows amplitude, not instantaneous voltage:

The amplitude on the load ul will show peaks every Δf. At the peaks, the signal will have the amplitude umax and in the valleys it will have the amplitude umin.

It turns out that Δf has the following relation to transmission line length and propagation speed:

\Delta f = \frac{c}{2 d}

This equation can be useful in debugging since it can point to the part of the signal path where the mismatch is happening. For example, if you know the propagation speed it allows you to calculate the length of the mismatched segment.

The ratio of the maximum and minimum amplitude (in linear scale) on the load depends on the reflection coefficients at the source and the load ends of the transmission line:

\frac{u_{max}}{u_{min}} = \frac{1 + |\Gamma_g\Gamma_l|}{1 - |\Gamma_g\Gamma_l|}

This last equation is interesting. At the first glance it makes sense. If either of the ends is perfectly matched (Γg = 0 or Γl = 0), then the ratio is 1 and there is no dependency on frequency. This is the expected result. A transmission line that is mismatched on only one end still has a non-optimal power transfer but the amplitude on the load is constant and doesn't depend on the signal frequency.

A signal flow diagram, similar to the one mentioned in this article, can also be used to verify its correctness.

The equation for the ratio of amplitudes on the load is very similar to the equation for the voltage standing wave ratio:

\mathrm{VSWR} = \frac{1 + |\Gamma_l|}{1 - |\Gamma_l|}

In a VSWR calculation you only have a mismatched load. In the case where you have two mismatched ends, it then kind of makes sense that you multiply both reflection coefficients together.

However if you think about it, it's quite weird that it turns out this way. In the VSWR case you are calculating the ratio of the sum and difference of the forward wave (uf = 1) and the reflected wave (reflected once off the load, hence ur = Γl). Since the source is perfectly matched in that case, the reflected wave doesn't reflect back the second time. It's obvious that the formula for the ratio is this simple.

On the other hand in the case where both the source and load are mismatched, you get an infinite number of reflections. When the source first gets switched on, the first forward wave driven by the source reflects off the load with Γl. When the reflected wave gets to the source it reflects off the mismatched source impedance with Γg and travels back to the load superimposed on the original forward wave. This combination of the signal driven by the source and the first reflection again reflects off the load and so on to infinity. The steady-state amplitude of the signal on the load is the sum of all those infinite reflections.

If you think about it this way, it's surprising that the ratio ends up being this simple equation that is the same as if the signal only reflected once from the load and once from the source.

Posted by | Categories: Analog | Comments »