Cassandra - Tuesday Diversion: EU and Standardized Chargers; RAW Photos from DSLR to iOS via WiFi; Apple Redirects and Browser Failures

By Graham K. Rogers

I would prefer it if iPhones used USB-C, however recent EU moves rumoured to be about the Lightning connector, may concern standardization of chargers. I cannot tether my camera to the iPad Pro, but I can download RAW images by cable and now WiFi. Apple tries to protect users when Safari detects too many redirects, but this does not account for the hops, skips and jumps Thai internet providers impose on user requests.

A resurfaced attempt by the EU to standardize phone connectors is intended to reduce waste from trashed chargers, in part. I am not sure there will be the effects desired, but it is certainly about time people moved on from those awful mini-USB connectors. A possible casualty is also rumoured to be Apple's Lightning connectors and all those cables: the favoured EU solution seems to be USB-C. I say bring it on.

I was slightly disappointed that Apple did not move to USB-C for the iPhone 11. Fallout would have been limited as Samsung had already made the change to one of its handsets, so the usual accusations would not have been valid, although some will always find a reason to have a moan at Apple. It was pointed out to me, however, that the Lightning connector is firmer when being inserted to a port than the connection made with USB. I would not deny that.

A couple of days after some articles about this surfaced on the Internet, an item on The Verge suggested that, despite what many suggest, the EU move is not specifically aimed at Apple and its Lightning connectors. Cameron Faulkner writes that this is less about cables and the Lightning port, and more about the other end: the charger itself. There used to be 30 types of proprietary charger and now there are 3, but their disposal still makes up far too much waste each year.

I have USB-C on 50% of my devices and find it pretty good. I have reduced the number of cables and chargers. I have now figured out a way to cut this down some more. I have added several cables and third-party accessories, so I am able to swap about with devices quite easily.

I gave one of those micro-USB to USB-C cables to a friend who found it one of the most useful accessories he had. His own company provided the MacBook Pro for his work, but failed to provide any hub and he was unwilling to purchase his own, so found the USB-C MacBook Pro less flexible than the previous Mac he had been using.

Additional features are needed to make the iPad Pro a real "Pro" device, such as flatbed scanner support and tethering. I recently wrote to Nikon about this as Hasselblad now has the feature in their iPad Phocos app: the iPad Pro has the capability and there is an API. I was given the Apple-like reply, that the company does not comment on future product developments, which is fair enough. At least I have registered a user want.

The Nikon SnapBridge software was updated this week. I mainly use this for adding GPS metadata to the images I take with the D850, but the previous update added a feature that would allow downloading of RAW images directly from the camera to an iOS device using WiFi. Try as I might, this did not work for me. With the latest update I had another go. Rather than go through a local WiFi router, the user connects the portable device to an in-camera WiFi network. It was already setup to recognize the camera once I turned on its WiFi capability, but it still did not work.

I used the "forget this network" option and tried again. This time the option for downloading images was not greyed out. When I pressed this I was shown the single test image on the camera. I selected this and was given 2 options: a 2MP download or the original image. I chose the latter as I wanted to see if this really was possible. The download to the iPhone began, but progress was slow. I was called out of the office and when I returned a few minutes later the download appeared to have failed and the WiFi on the camera had turned itself off.

On a second attempt, I watched both devices like a hawk as the progress bar crept slowly across the screen, tapping the camera Menu button several times as the screen went off to make sure the WiFi stayed connected. This time, the file was downloaded, but when I checked the library there were two versions, both with the same number. That first download had worked, although I had not seen any image in the library at that time.

Emboldened by this, I downloaded the SnapBridge app to the iPad Pro and set up the WiFi on that. Finding the images and the correct folder was not as easy as I expected when selecting the download process. I did find the new test image I had taken for the iPad Pro connection and noticed that the progress bar was much quicker. This time there was only one version of the file.

Even though I only tried single file downloads, the slowness of the process suggests that this is not a particularly practical solution. Cable connections are far more efficient. That does not work with the iPhone with its Lightning connector, although I do have the SD card reader. The photos, however, are on the camera's XQD card (the SD card is backup) and there is no card reader for this format for the Lightning port. I can transfer images from one card to another in-camera, but this changes the date and time of the image to when that transfer took place, not the original time the photo was taken.

The best solution on the street is the iPad Pro plus a cable, but that also has a limitation with the number of images that can be transferred. That seems to be around 20 or so with the large RAW files from the D850. Any more and I have to wait until I have access to the Mac.

One of my jobs at the Faculty of Engineering, Mahidol University, is to check the English output of those who ask. I am still disappointed that some don't think they need advice, and this has seen some poor output, with grammar problems, spelling errors and even new words. A newsletter from a small department this weekend took me a few minutes to check. On Monday I spent about 15 minutes with the person responsible for the work and we made the corrections to the file.

That department was set up fairly recently and is focused on logistics and rail engineering: both main line and metro systems. As I am often asked to look at output, including editing articles for a book that is to appear soon, I have been able to see more of how railway systems are to be developed, particularly in Bangkok, with some 32 metro projects under consideration. Some of these are already in operation or under construction. Some are many years away.

One of the members of the group has put out an app that gathers much of the information of the metro systems in use or being developed in the near future: BKK Rail. It has the twin purposes of consumer information and guidance for rail engineers who come from abroad. I suggested that the English needed tidying up, so was handed the files recently and made a first run through the text. This appears in an update that was released at the weekend, although there are some display issues, particularly on the iPad. It is a work in progress and already fixes are in the pipeline.

While trying to download some diagnostics software from Apple while I was on the phone to the Apple Helper a short time ago, the connection failed as the link had been redirected too many times. The Helper sorted that out but I mentioned that this was perhaps also due to the unusual number of redirects users in Thailand have. A local user commented on this point when I discussed the problem in a recent article and wrote several helpful emails (I have permission to use these). He wrote:

I think that what happens here is that Apple's content delivery network (Akamai?) attempts to redirect to a locally hosted page (with en-th in the URL). But that page doesn't exist so the CDN redirects back to a non-localized page and then back to the non-existent page. Eventually the redirect limit is reached and the browser gives up.

He had reported this several times to Apple, but the only sure way is to use a VPN or proxy. He added, "I don't think browsers are aware of the long routing dance imposed by Thai ISPs." While he used a Lynx utility to trace the route, there is a Network Utility on the Mac, but this is well-hidden nowadays. On Mojave it can still be found in Utilities.

Searching for Network Utility on Catalina

On Catalina I found this by searching for Traceroute in the Finder, then refining the search with "Application". The screen shot shows how deeply buried this now is. I guess Apple does not want us to play with it too much. I also tried later at home as the office servers hide a lot of the information. Even a simple check with Apple shows 11 jumps before it leaves the country, then it is just one link to the Akamai servers Apple uses, and some of those jumps look as if it is all jumping about in different parts of the same server: True at its most efficient. No wonder Safari balks with its jump limit.

Running Traceroute on Mojave

There is also Terminal for those who are able to use the command line: after all, Traceroute, Ping and other tasks in Network Utility are just UNIX commands with a graphic interface. It is easier to use the IP number than a site name with the UNIX version.

We are currently at the stage with analysis of my iPhone Photos sync problems when an hour of logging is not enough. This week a second run of Photos diagnostics - this time for 24 hours - was run for information to be fully gathered in an attempt to discover why photo-syncing to the iPhone has stopped. It will soon be 3 months since the iOS 13.2 update stopped the process and I am keen to have this resolved.

Graham K. Rogers teaches at the Faculty of Engineering, Mahidol University in Thailand. He wrote in the Bangkok Post, Database supplement on IT subjects. For the last seven years of Database he wrote a column on Apple and Macs. After 3 years writing a column in the Life supplement, he is now no longer associated with the Bangkok Post. He can be followed on Twitter (@extensions_th)