When I switched from an iMac to a Mac mini in late 2024 I choose an ASUS ProArt 5K PA27JCV (24″, 60 Hz) for the monitor and while it looked great, it died after 14 months, seemingly with a backlight or power supply problem. ASUS’ warranty support requires shipping the monitor back, potentially waiting 3-4 weeks, and then getting a replacement. And worse, the replacement could have dead pixels, as the ASUS warranty doesn’t consider ≤5 dark pixels a problem.

The old HP ZR2440w that I swapped in as a spare wasn’t cutting it, so with an indeterminate wait ahead of me, potentially receiving something with bad pixels, and my being vaguely interested in something larger and with a faster refresh rate I went looking at new monitors.

Coming to the realization that 4K is probably fine I picked up a Dell 32 Plus 4K QD-OLED Monitor – S3225QC from Costco for $499. It was well reviewed online and looked pretty good when I played with one for about 20 minutes at Micro Center. When I got home and sat in front of it doing my normal things it looked a bit… different… almost as if my glasses weren’t working quite right. But I figured new monitor tech just needed some time for me to get accustomed to. After all, it had a very high contrast ratio and sharp pixels; maybe it’s just that?

After a few days it still didn’t feel right, so I began looking for a solution. Costco has a 90-day return window for computer monitors, but this didn’t look good; I wanted an answer soon.

Thankfully I the chance to borrow a Dell UltraSharp 32 4K USB-C Hub Monitor U3223QE for the weekend, and being a high end display with the same resolution and panel size as the S3225QC from the same manufacturer I compared them side to side. And the LCD just looked better.

I took some macro photos of both displays and it turns out that what was bothering me was fringing, a problem common to OLEDs. It was hard to point out during normal use other than text-is-a-bit-blurry-and-weird , or like an oversharpened image, or almost like artifacted text in a JPEG image, but with photos it was much easier to see what’s going on. And better, the cause: the arrangement of the subpixels; the little red/blue/green dots that make up a pixel.

As shown above, the subpixles in the Dell S3225QC QD-OLED form a square with green on the top, a larger red pixel in the lower left, and smaller blue in the lower right. The Dell U3223QE, a typical LCD, has three vertical stripes making a square.

The result being that high contrast edges look very different on an OLED, often with a strong off-color border along horizontal and vertical lines. In the photos above, note the vertical part of the 1 which has red and green dots along its right side, and large red dots along the top of the 6 with green along the bottom. These are the strongly colored fringes. On the LCD they appear white as the three equal size subpixels pixels act equally.

This meant that things that I tend to do, text or fine lines in maps or CAD-type drawing, are not right at all on the pixel pattern found in this OLED panel.

And beyond the pixel pattern, I also suspect that the much crisper pixels (defined points of light) contribute to the fringing having an artifacting-like effect.

This was much more pronounced when looking at light text on a dark background; the way that I read most websites. Visual Studio Code does a wonderful job demonstrating this problem:

This gets at why OLEDs make great TVs and gaming monitors. The contrast is outstanding, color is excellent, and high refresh rates are ideal for moving images and fast-response games. And there’s no noticeable fringing because edges are constantly moving across pixels; almost nothing is still. They also work great on small devices like phones where the pixel density is so high that fringing is too small to see.

But on desktop monitors for still things — text and fine lines — OLEDs currently just aren’t great; I guess that’s why office and productivity type monitors are still LCDs. Even though I don’t like being that person who returns computer stuff just because they don’t like it, I ended up returning the monitor after only four days of using it. The S3225QC and it’s QD-OLED just doesn’t work for me; it made my eyes feel funny to use.

Within the past few weeks LG has announced RGB stripe OLED panels which will resolve this problem, but there aren’t currently any monitors available using these panels, so back to an LCD I’ll go. (It looks like ASUS and MSI will some them available soon, but only as wide-screen gaming monitors. And I suspect the first ones available will be fairly expensive.)

Whether this’ll be buying my own U3223QE, perhaps a Dell U3225QE (adds 120 Hz scanning, an ambient light sensor, and a Thunderbolt dock), or just waiting for an ASUS PA27JCV to come back, I’m not sure… But whatever I end up using will, for now, will be an LCD, not an OLED.

Comments closed

Part of our Home Assistant (HA) setup uses the Companion Mobile App for easy remote control and to collect data from our devices. The main tracked item is the phone’s location, so HA can tell if we’re home or not, and currently I only use it to change how some lighting automations work.

I also have HA set up to log all device state data (switches, outlets, climate sensors, power consumption) to a local instance of InfluxDB, and then have Grafana installed so I can visualize this data.

My original use for this was long-term logging of temperature and humidity sensor data — which is neat to see — but as I’ve experimented with graphing things like mains voltage. This was neat because it made it easy to see things like how voltage drops and becomes erratic during summertime cooling periods. And showed that grid voltage jumped up by ~2VAC in March 2025, around which time I recall DTE doing utility work on the grid just north of our house. (Yes, evidence of them improving things locally.)

Late on Christmas evening, wanting some time to just sit alone and do things, I put together a map showing where my phone had been. I’m pretty happy with how it came out, as I can now input a time range and dots will appear for each logged location, color-coded with geopositioning accuracy (brighter green is more accurate).

I also used this as another exercise in working with LLM tools like ChatGPT. I’m (finally?) realizing how useful this can be when thought of as a modern search engine. There’s still constant reminders of how imperfect and problematic results can be, but with a domain background it’s helpful. I find that thinking of these tools as tireless (yet emotionless) junior employee who makes lots of mistakes and needs all responses tested and vetted works… decently… in pointing me in a decent direction.

But I digress… Here’s the query that’s the main point of this and makes it all go:

SELECT "latitude", "longitude","gps_accuracy"
FROM "homeassistant"."autogen"."state"
WHERE "entity_id" = 'pixel_8'
AND $timeFilter
AND "gps_accuracy" < 100

It was then simply a matter of putting this into a Geomap that displays a point for each location, and colors it based on gps_accuracy state and looks decent. I was even able to place it all on the Thunderforest Landscape map tiles which shows OSM-mapped trails and has been oh-so-useful on my RAMBA Trails Map.

Initially I looked at a heat map, but it didn’t seem as useful as individual points. I may explore this later, but the device where I’m currently running HA is a bit under-powered for this. And note that the query above excludes records that have a GNSS accuracy worse than 100 meters as this generally means that GPS (et al) wasn’t working at all and geopositioning likely came from local mobile towers (which shows me as being on tall local buildings, in fields I’d never visit, etc).

While obvious in retrospect, the most notable things this shows me is that when I’m driving — typically running OsmAnd+ or Google Maps (or both) — the recorded points are high accuracy and frequent. When riding my bike, carrying my phone idly in a pocket, the GNSS sensor is likely PRIORITY_PASSIVE so the dots are both infrequent and low accuracy.

It’s also just neat to look at. Things jump out like a trip to IKEA in Canton, riding at Island Lake and Holly Wilderness, etc.

I’m curious to see what I can further tease out of the logged data. The HA Companion mobile app can get all sorts of interesting info via its Sensors. For example, the Activity Sensors on iOS automatically detect:

• Stationary
• Walking
• Running
• Automotive
• Cycling

And on Android:

• in_vehicle
• on_bicycle
• on_foot
• running
• still
• tilting
• walking

Plus there’s things like what’s being done with the device, what’s seen about its environment (including visible wireless networks, Bluetooth devices), etc…

It might be neat to see what more I can get out of this. Or it might just end up as a nudge to decrease what HA is collecting (and possibly purge some of it from the db).

Of course, it pales in comparison to what the telcos, device manufacturers, OS vendors, and app vendors can do with their data engineers, massive troves of data and ability to cross-reference, etc. (A bit of a reminder that phones are just behavior-trackers that also make calls and take pictures…)

I hope to soon try migrating this HA instance from a Raspberry Pi 4B to a higher-powered slim PC. While I don’t intend to take this much further, it will provide more power for chewing on data like this and will hopefully let me figure out a disaster recovery plan for HA that includes preserving all logged data. When first setting up this map I tried to draw both a location and heatmap and this was a little too much for the Pi and as it ground to a halt Kristen noticed that the back yard lights weren’t turning on properly. Doh! Or I guess I could just do the processing on another machine…

Comments closed

Four years after my post on doing network captures on macOS with Process ID, Wireshark 4.6.0 has been released which includes support for parsing this extra metadata, including the process info.

So how do you do it? Easy! You just need the pktap interface parameter.

From the tcpdump(1) man page:

Alternatively, to capture on more than one interface at a time, one may use “pktap” as the interface parameter followed by an optional list of comma separated interface names to include. For example, to capture on the loopback and en0 interface:

tcpdump -i pktap,lo0,en0

An interface argument of “all” or “pktap,all” can be used to capture packets from all interfaces, including loopback and tunnel interfaces. A pktap pseudo interface provides for packet metadata using the default PKTAP data link type and files are written in the Pcap-ng file format. The RAW data link type must be used to force to use the legacy pcap-savefile(5) file format with a ptkap pseudo interface. Note that captures on a ptkap pseudo interface will not be done in promiscuous mode.

Therefore, we just need something like:

tcpdump -i pktap,en0 -w outfile.pcapng

or

tcptump -i pktap,all host 192.168.0.6 -w outfile.pcapng

And then open outfile.pcapng in Wireshark and under Frame → Process Information you can find the process name, PID, etc. (See screenshot above.)

Filtering can be done with frame.darwin.process_info as listed here. For example:

frame.darwin.process_info.pname == "firefox"

or

frame.darwin.process_info.pid == 92046

This is super helpful to figure out both what unexpected network traffic is being generated by and the inverse, what a process is doing on the network. And now thanks to Wireshark 4.6.0 it’s even easier.

Comments closed

I have an Epson Perfection 3170 Photo scanner for years, it works great, and don’t want to replace it. Unfortunately, Epson hasn’t published drivers for Windows 10, 11, etc and choosing any of these OS’ from their download page either results in a blank set of downloads, or a suggestion to download the Epson Event Manager which… doesn’t contain drivers. Great, thanks Epson. (And no, a driver doesn’t get automatically installed by Windows Update, either.)

However, it turns out there is a way to get it working under Windows 10/11/etc, and that’s the point of this blog post: Choose Windows Vista 64-bit and download Scanner Driver and EPSON Scan Utility v3.04A, filename epson12180.exe (or get it from this mirror). This self-extracts to C:\epson\epson12180_twain_driver_and_epson_scan_utility_304a and includes a signed 64-bit TWAIN driver that works great on Windows 11.

Comments closed