Avian’s Blog

Wacom Cintiq 16 (DTK-1660/K0-BX) is a drawing tablet that was announced late last year. At around 600€ I believe it's now the cheapest tablet with a display you can buy from Wacom. For a while I've been curious about these things, but the professional Wacoms were just way too expensive and I wasn't convinced by the cheaper Chinese alternatives. I've been using a small Intuos tablet for several years now and Linux support has been flawless from the start. So when I recently saw the Cintiq 16 on sale at a local reseller and heard there are chances that it will work similarly well on Linux I couldn't resist buying one.

Even though it's a very recent device, the Linux kernel already includes a compatible driver. Regardless, I was prepared for some hacking before it was usable on Debian. I was surprised how little was actually required. As before, the Linux Wacom Project is doing an amazing job, even though Linux support is not officially acknowledged by Wacom as far as I know.

The tablet connects to the computer using two cables: HDMI and USB. HDMI connection behaves just like a normal 1920x1080 60 Hz flat panel monitor and the display works even if support for everything else is missing on the computer side. The HDMI cable also caries an I²C connection that can be used to adjust settings that you would otherwise expect in a menu accessible by buttons on the side of a monitor (aside from a power button, the Cintiq itself doesn't have any buttons).

After loading the i2c-dev kernel module, the ddcutil version 0.9.4 correctly recognized the display. The i2c-2 bus interface in the example below goes through the HDMI cable and was in my case provided by the radeon driver:

$ ddcutil detect
Display 1
   I2C bus:             /dev/i2c-2
   EDID synopsis:
      Mfg id:           WAC
      Model:            Cintiq 16
      Serial number:    ...
      Manufacture year: 2018
      EDID version:     1.3
   VCP version:         2.2
$ ddcutil --bus=2 capabilities
MCCS version: 2.2
Commands:
   Command: 01 (VCP Request)
   Command: 02 (VCP Response)
   Command: 03 (VCP Set)
   Command: 06 (Timing Reply )
   Command: 07 (Timing Request)
   Command: e3 (Capabilities Reply)
   Command: f3 (Capabilities Request)
VCP Features:
   Feature: 02 (New control value)
   Feature: 04 (Restore factory defaults)
   Feature: 05 (Restore factory brightness/contrast defaults)
   Feature: 08 (Restore color defaults)
   Feature: 12 (Contrast)
   Feature: 13 (Backlight control)
   Feature: 14 (Select color preset)
      Values:
         04: 5000 K
         05: 6500 K
         08: 9300 K
         0b: User 1
   Feature: 16 (Video gain: Red)
   Feature: 18 (Video gain: Green)
   Feature: 1A (Video gain: Blue)
   Feature: AC (Horizontal frequency)
   Feature: AE (Vertical frequency)
   Feature: B2 (Flat panel sub-pixel layout)
   Feature: B6 (Display technology type)
   Feature: C8 (Display controller type)
   Feature: C9 (Display firmware level)
   Feature: CC (OSD Language)
      Values:
         01: Chinese (traditional, Hantai)
         02: English
         03: French
         04: German
         05: Italian
         06: Japanese
         07: Korean
         08: Portuguese (Portugal)
         09: Russian
         0a: Spanish
         0d: Chinese (simplified / Kantai)
         14: Dutch
         1e: Polish
         26: Unrecognized value
   Feature: D6 (Power mode)
      Values:
         01: DPM: On,  DPMS: Off
         04: DPM: Off, DPMS: Off
   Feature: DF (VCP Version)
   Feature: E1 (manufacturer specific feature)
      Values: 00 01 02 (interpretation unavailable)
   Feature: E2 (manufacturer specific feature)
      Values: 01 02 (interpretation unavailable)
   Feature: EF (manufacturer specific feature)
      Values: 00 01 02 03 (interpretation unavailable)
   Feature: F2 (manufacturer specific feature)

I didn't play much with these settings, since I found the factory setup sufficient. I did try out setting white balance and contrast and the display responded as expected. For example, to set the white balance to 6500K:

$ ddcutil --bus=2 setvcp 14 5

Behind the USB connection is a hub and two devices connected to it:

$ lsusb -s 1:
Bus 001 Device 017: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 019: ID 056a:0390 Wacom Co., Ltd 
Bus 001 Device 016: ID 056a:0395 Wacom Co., Ltd 
$ dmesg
...
usb 1-6: new high-speed USB device number 20 using ehci-pci
usb 1-6: New USB device found, idVendor=056a, idProduct=0395, bcdDevice= 1.00
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-6: Product: Cintiq 16 HUB
usb 1-6: Manufacturer: Wacom Co., Ltd.
hub 1-6:1.0: USB hub found
hub 1-6:1.0: 2 ports detected
usb 1-6.2: new high-speed USB device number 21 using ehci-pci
usb 1-6.2: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-6.2: Product: Single RS232-HS
usb 1-6.2: Manufacturer: FTDI
ftdi_sio 1-6.2:1.0: FTDI USB Serial Device converter detected
usb 1-6.2: Detected FT232H
usb 1-6.2: FTDI USB Serial Device converter now attached to ttyUSB0
usb 1-6.1: new full-speed USB device number 22 using ehci-pci
usb 1-6.1: New USB device found, idVendor=056a, idProduct=0390, bcdDevice= 1.01
usb 1-6.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-6.1: Product: Cintiq 16
usb 1-6.1: Manufacturer: Wacom Co.,Ltd.
usb 1-6.1: SerialNumber: ...
input: Wacom Cintiq 16 Pen as /devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1:1.0/0003:056A:0390.000D/input/input62
on usb-0000:00:1a.7-6.1/input0

056a:0395 is the hub and 056a:0390 is the Human Interface Device class device that provides the actual pen input. When the tablet is off but connected to power, the HID disconnects but other two USB devices are still present on the bus. I'm not sure what the UART is for. This thread on GitHub suggests that it offers an alternative way of interfacing with the I²C bus for adjusting the display settings.

On the stock 4.9.130 kernel that comes with Stretch the pen input wasn't working. However, the 4.19.12 kernel from stretch-backports correctly recognizes the devices and as far as I can see works perfectly.

$ cat /proc/version
Linux version 4.19.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.12-1~bpo9+1 (2018-12-30)

I'm using the stock GNOME 3.22 desktop that comes with Stretch. After upgrading the kernel, the tablet correctly showed up in the Wacom Tablet panel in gnome-control-center. Pen settings there also work and I was able to calibrate the input using the Calibrate button. Calibration procedure instructs you to press the pen onto targets shown on the display and looks exactly like when using official software on Mac OS.

Update: It seems that GNOME sometimes messes up the tablet-to-screen mapping. If the stylus suddenly starts to move the cursor on some other monitor instead of displaying it underneath the stylus on the Wacom display, check the key /org/gnome/desktop/peripherals/tablets/056a:0390/display in dconf-editor. It should contain something like ['WAC', 'Cintiq 16', '...']. If it doesn't, delete they key and restart gnome-settings-daemon.

In GIMP I had to enable the new input devices under Edit, Input Devices and set them to Screen mode, same as with other tablets. You get two devices: one for the pen tip and another one for when you turn the pen around and use the other eraser-like end. These two behave like independent devices in GIMP, so each remembers its own tool settings.

As far as I can see, pen pressure, tilt angle and the two buttons work correctly in GIMP. The only problem I had is that it's impossible to do a right-click on the canvas to open a menu. This was already unreliable on the Intuos and I suspect it has to do with the fact that the pen always moves slightly when you press the button (so GIMP registers click-and-drag rather than a click). With the higher resolution of the Cintiq it makes sense that it's even harder to hold the pen still enough.

Otherwise, GIMP works mostly fine. I found GNOME to be a bit stubborn about where it wants to place new dialog windows. If I have a normal monitor connected alongside the tablet, file and color chooser dialogs often end up on the monitor instead of the tablet. Since I can't use the pen to click on something on the monitor, it forces me to reach for the mouse, which can be annoying.

I've noticed that GIMP sometimes lags behind the pen, especially when dragging the canvas with the middle-click. I didn't notice this before, but I suspect it has to do with the higher pen resolution or update rate of the Cintiq. The display also has a higher resolution than my monitor, so there are more pixels to push around. In any case, my i5-750 desktop computer will soon be 10 years old and is way overdue for an upgrade.

In conclusion, I'm very happy with it even if it was a quite an expensive gadget to buy for an afternoon hobby. After a few weeks I'm still getting used to drawing onto the screen and tweaking tool dynamics in GIMP. The range of pressures the pen registers feels much wider than on the Intuos, although that is probably very subjective. To my untrained eyes the display looks just amazing. The screen is actually bigger than I thought and since it's not easily disconnectable it is forcing me to rethink how to organize my desk. In the end however, my only worry is that my drawing skills are often not on par with owning such a powerful tool.

It recently came to my attention that Google has a new Search Console where you can see the status of your web site in Google's search index. I checked out what it says for this blog and I was a bit surprised.

Some things I expected, like the number of pages I've blocked in the robots.txt file to prevent crawling (however I didn't know that blocking an URL there means that it can still appear in search results). Other things were weirder, like this old post being soft recognized as a 404 Not Found response. My web server is properly configured and quite capable of sending correct HTTP response codes, so ignoring standards in that regard is just craziness on Google's part. But the thing that caught my eye the most was the number of Excluded pages on the Index Coverage pane:

Considering that I have less than a thousand published blog posts this number seemed high. Diving into the details, it turned out that most of the excluded pages were redirects to canonical URLs and Atom feeds for post comments. However at least 160 URL were permalink addresses of actual blog posts (there may be more, because the CSV export only contains the first 1000 URLs).

All of these were in the "crawled, not indexed" category. In their usual hand-waving way, Google describes this as:

The page was crawled by Google, but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.

I read this as "we know this page exists, there's no technical problem, but we don't consider it useful to show in search results". The older the blog post, the more likely that it was excluded. Google's index apparently contains only around 60% of my content from 2006, but 100% of that published in the last couple of years. I've tried searching for some of these excluded blog posts and indeed they don't show in the results.

I have no intention to complain about my early writings not being shown to Google's users. As long as my web site complies with generally accepted technical standards I'm happy. I write about things that I find personally interesting and what I earnestly believe might be useful information in general. I don't feel entitled to be shown in Google's search results and what they include in their index or not is their own business.

That said, it did made me think. I'm using Google Search almost exclusively to find information on the web. I suspected that they heavily prioritize new over old, but I've never seriously considered that Google might be intentionally excluding parts of the web from their index altogether. I often hear the sentiment how the old web is disappearing. That the long tail of small websites is as good as gone. Some old one-person web sites may indeed be gone for good, but as this anecdote shows, some such content might just not be discoverable through Google.

All this made me switch my default search engine in Firefox to DuckDuckGo. Granted I don't know what they include or exclude from their search either. I have yet to see how well it works, but maybe it isn't such a bad idea to go back to the time where trying several search engines for a query was a standard practice.

MightyWatt is a small, computer controlled electronic DC load made by Jakub Polonský. I recently ordered one for work, since I often need to test power supplies and it was significantly cheaper than a similar professional desktop instrument. I was first looking for a Re:load Pro, since I have been very happy with the old analog Re:load, however it turns out they are out of stock and impossible to get. MightyWatt was the closest alternative that fit the budget. After several months, here is a quick review and some notes on how well it performs in practical use.

Compared to Re:load, MightyWatt is not a stand-alone device. It comes in the form of an Arduino shield and you need to mount it on an Arduino Uno (or a compatible) microcontroller board. You also need to compile an open source firmware yourself and program the board with it. The ATmega328 on the Arduino then controls the load and communicates with the computer you connect to its USB port.

It's also worth mentioning that this design already has quite a history. First revision apparently shipped in 2014. I am using revision 3 hardware from 2017 and latest software from GitHub. During these tests I was using an Arduino-knockoff called Smduino. To protect the computer from any mishaps with the load, I'm connecting it over an Olimex USB-ISO USB isolator.

The initial setup went quite smoothly. The instructions on how to program the firmware using the Arduino IDE were nice and clear. After your order, the author commits the calibration file for your serial number to GitHub, which I thought was a nice approach. The control program for Windows has a pre-compiled build in the GitHub repo, so there is no need to install Visual Studio, unless you want to compile it from the C# source yourself.

In contrast to the straightforward software instructions I could find no illustration showing how to actually mount the device onto the Arduino board and initially I was a bit baffled. The 100 mil male headers on the MightyWatt are missing pins from the standard Arduino shield layout, so it's possible to fit them into the sockets in several possible ways. I'm guessing only one of those doesn't end in disaster. In the end I noticed the (very) tiny pin markings on the MightyWatt silk-screen and matched them with the corresponding pins on the Arduino.

Unfortunately, the headers are also the only thing that keeps MightyWatt mechanically connected to the Arduino. Beefy measurement cables are commonplace when working with large currents and the stiffness of the headers alone just isn't enough to keep the MightyWatt securely connected to the Arduino. On several occasions I found that I have pulled it off when messing with the cabling. I was looking into 3D-printing an enclosure, however this MightyWatt PCB doesn't have any spare holes for additional screws, so it's not easy to work around this issue. It seems that an acrylic case existed at one point, but I couldn't find it for sale and since it doesn't seem to screw onto the PCB I'm not sure it would help.

Comparing MightyWatt current readout to VC220. VC220 was in series with MightyWatt current terminals. The load was in constant current mode and was connected to a 5 V power supply.

Comparing MightyWatt voltage readout to VC220. The load was in 4-point mode with a lab power supply connected to the voltage terminals. Current terminals were not connected.

As far as accuracy and calibration is concerned, I can't be certain since I don't have any good reference to compare it to. After some simple experiments with a VC220 multimeter it seems reasonable, as you can see on the graphs above. The current readout on the MightyWatt is with-in the measurement tolerance of the VC220 for the complete 10 A range. Voltage readout does fall outside of the tolerance of VC220. I don't know whether that is a fault of VC220 or MightyWatt, but in any case, both devices only disagree for about 1% and linearity looks good.

One problem I noticed with constant current setting was that there seems to be a momentary glitch when changing the set point with the load running (i.e. without stopping it). This seems to trigger some fast over-current protections, even when currents should be well below the limit. For example, changing the load from 1 A to 2 A sometimes puts a 3 A supply into foldback mode, but doing the same by stopping the load for the change doesn't.

I really like the fact that MightyWatt supports 4-point Kelvin measurements. The software also supports a mode called Simple ammeter, which puts current inputs into minimum resistance. Combined with the 4-point setting, this converts MightyWatt into a computer-controlled ampere- and voltmeter pair. I have not tried this mode yet, but it sounds like it might be useful as a simple power meter.

Other than that, I haven't looked much into the electronics design. However the author has a blog with many interesting posts on the design of the MightyWatt if you are interested in the details.

The Windows software is functional, if somewhat buggy at times. Unfortunately as far as I can see, there is no way to control MightyWatt from Linux at the moment. I would love to automate my measurements with Python, like I've been doing with everything else. Fortunately, the Windows control program allows you do some simple scripting, so that is not that much of a pain. Also, the communications protocol seems well documented and I just might write a Python library for it eventually.

My biggest issue with the software is that the Windows control program seems to often lose connection with the load. This isn't handled gracefully and I often find that it will no longer see the MightyWatt's COM port after that. This then requires some ritual of reconnecting the USB cable and restarting the application to get it working again.

I'm not sure what is the reason for this and I don't know whether this is a software problem on Windows side or whether the Arduino firmware is crashing. First I was blaming electrical interference, since it appeared to often happen when I connected an oscilloscope probe to a supply I was testing. Then I thought the USB isolator was causing it. However after some more testing I found that this still randomly happens even if I just let the MightyWatt run idle, directly connected with a USB cable to a PC.

In conclusion, it's a nice little instrument for its price, especially considering that similar instruments can easily cost an order of a magnitude more. I like that it comes tested and calibrated out of the box and that it's well documented. I really like the open source aspect of it and I always find it hard to criticize such projects without submitting patches. The Windows control software is pretty powerful and can support a lot of different measurements. The ugly part is the flimsy mechanical setup and the connection reliability problem, which means that I can't leave a measurement running without being constantly present to check for errors.