Don’t Hate
Fixing Dropbox’s Camera Upload Organization Mess – EXIFmover
Dec 15th
First, I have to note that I love Dropbox. I’ve been using the service almost since the beginning to synchronize my work across multiple desktops, notebooks, and mobile devices. There’s really no alternative at this point that rivals Dropbox in my mind.
That said, the state of their camera upload organization is abysmal. This is a recent new emphasis for Dropbox, automatically uploading all the photos taken on a mobile device or onboard an SD card inserted into a notebook. The problem is that all of these photos are dumped into the same /Dropbox/Camera Uploads folder, so you end up with a huge list of photos. That’s not so bad, except that in my case I’m dealing with sample photos taken on multiple devices for testing results in a completely unwieldy directory with so many files that it often causes Finder on OS X or Explorer on Windows to stall for seconds upon opening.
This isn’t that well organized…
I’ve pleaded my case for a simple feature to be added – per device folder creation. This didn’t make it into the last update, and about a week or so ago I wrote a script to do exactly that. It parses the EXIF data, and sorts photos into a folder with name /[type]+[model]. The end result looks like this:
Finally, some per-device sorting
It’s called EXIFmover and I stuck it up on Github as a Gist since it’s pretty simple. I use Python 2.7 personally, so that’s what this is tailored for. I’ve tested on OS X, Windows, and Ubuntu. Python’s OS interface is fairly platform agnostic. The one prerequesite is EXIF-Py for parsing the EXIF metadata from photos, which can be obtained from that project’s Github page.
Stick both EXIFmover.py and EXIF.py in the Camera Uploads directory, and run. As more files are uploaded, this can be run again and photos will be sorted once more.
Finally, some organization.
How to Switch from Bars to Numerical Signal Level on iOS without Jailbreaking
Sep 30th
I’ve made a habit of only ever looking at signal level in numerics on iOS since the iPhone 3GS days. This has paid off a few times in the past (notably the iPhone 4 antenna situation) but in general just gives a better perspective for network conditions. I regularly post screenshots with both cellular and WiFi in numerics instead of the default bars, and on iOS this is pretty simple to make happen, at least to the cellular signal level indicator, without jailbreaking.
To do this the basic workflow is to enter FieldTest.app, then force quit the application. When FieldTest launches, it changes a .plist file for springboard which controls whether numerics are being shown for cellular signal. This is exactly the file that SBSettings tweaks if you’re toggling “Numeric GSM” and “Numeric WiFi.” I should note that these settings also stay around across iOS restores. Anyhow a lot of people have been asking on Twitter lately for some reason how to make this happen, so I thought I’d write it up.
Dialer for FieldTest (left), FieldTest.app (right)
Anyhow to show cellular signal without using SBSettings:
- Launch FieldTest.app by going into the dialer and dialing *3001#12345#*
- Hold down standby/lock like you’re going to turn the phone off
- Release standby/lock after the power off slider appears, then hold home (this is force quit on iOS – it’s impressive so few people know it)
- Boom, you have numerics instead of bars
This can now be tapped to switch back and forth. Launching FieldTest again and quitting will restore the file however, so every time you quit this will have to be a force quit to preserve the setting without jailbreaking or restoring an iOS backup with the plist file set how you want it.
I should also note that on LTE this number is RSRP (Reference Signal Received Power) in units of dBm. On WCDMA this is RSCP (Received Signal Code Power) in dBm, and on CDMA2000 1x/EVDO this is RSSI I believe (or EC, I haven’t ever carried a CDMA2000 iPhone for an apreciable amount of time). On WCDMA and 1x/EVDO values between -50 and -113 dBm are typical, with -50 being at cell center and -113 dBm being at cell edge. On LTE because the iDevice is showing RSRP, values between -75 and -120 dBm are typical, with RSRP showing ~20 dB lower than the analogous RSCP/WCDMA-land signal if you’re trying to compare.
AT&T 4G LTE in Tucson, AZ – Coming Before End of 2012
Sep 7th
It has been what seems like an eternity since I wrote a bit about Verizon 4G LTE coming to Tucson, AZ. Since then, the network has been deployed and working just fine, and made it into my mental take-it-for-granted state. Since then, Cricket has lit up their own LTE network on AWS (1700/2100 MHz), and next up is AT&T who just recently announced details about their LTE deployment for a bunch of markets before the end of this calendar year. I wrote about the AT&T LTE news at a high level at AnandTech, and the announcement comes a not-so-coincidentally timed week before the next iPhone announcement in an attempt to prevent lots and lots of LTE related churn.
I’m burying the lead a bit, but before the end of 2012 AT&T will have LTE finally lit up in my part of the world. There’s a relevant press release here which is relatively light on detail – there’s no outline for what parts of town will get LTE, whether it will include surrounding areas, or any further detail. I guess we can only hope that they mean the greater metro area. I’ve asked a few of my sources for a better timeline, but can only say that before December LTE should be lit up.
I hope it goes without saying, but LTE (3GPP Long Term Evolution) is completely different from the earlier announcements AT&T made about “4G” coming to Tucson in May 2011. That was really just deployment of HSPA+ with up to 16QAM on the downlink (HSDPA 14.4) and some additional WCDMA carriers for capacity reasons. I’m pretty pleased with the state of AT&T WCDMA in town, I see around 2-3 carriers on PCS (1900 MHz) around town and what I consider very good peak speeds.
AT&T Spectrum Holdings in Pima County (As of Sept. 7 2012)
Since AT&T LTE doesn’t use the same channel bandwidth everywhere, it’s worth noting that in this particular market (Pima County), AT&T can run 10 MHz FDD-LTE on Band 17, (Lower 700 MHz B+C blocks) and 5 MHz FDD-LTE on AWS (1700/2100) when the time arises. I haven’t seen AT&T enable any LTE on AWS quite yet, this is likely coming at some future date after the rollout is closer to completion or as a way to mitigate loading in the future.
Ditching the Key Ring – Keyport Slide V01 Review
Jun 25th
For the longest time, the number of keys on my keychain seemed to be growing out of control. I couldn’t really figure it out, but it was to the point that I had a carabiner and multiple rings to contain all the keys I somehow was accumulating. Then it occurred to me that I didn’t really need all those keys every day – just the few that I use on a day to day basis, then the rest could be stored and used when necessary. I had seen Keyport a few times before, including on the very popular every day carry blog, but something about going through the process didn’t seem worthwhile when a move between houses was looming and my future was relatively nebulous. Recently however, while thinking of an ideal Father’s day present, stumbled on a coupon code for the Keyport and decided I’d order two – one as the gift, another for myself just to see how it goes.
The order process is pretty simple. After picking out the desired Keyport color, number of keys, and accessories (I went with a USB drive and bottle opener), you snap photos of the keys on a printed form and write down markings on the keys. The bits can be blanked out in photoshop, all that needs make it are the head, shaft, and both sides. These then get sent off so Keyport can ship back the appropriate blanks. I had two keys which Keyport couldn’t mail blanks for – a US Post Office box key (which was expected), and my locking gas cap key (which looks incredibly generic). For these, one needs to either ship the key in for Keyport to cut the head off of and turn into a keyport key (in the case of the post office key), or properly identify. I ended up with the following codes:
After a while, the Keyport comes in the above tin with some documentation, along with your blanks. The interesting part of the key blanks is that it appears that Keyport simply cuts the heads off of blanks themselves. If you look closely at the blanks, it’s pretty obvious that they use a bandsaw or something, then mate them up with the plastic Keyport insert. Nothing wrong with this, just an interesting note.
After you get the blanks back, it’s then a matter of finding a locksmith who will cut the keys. There’s a list of approved locksmiths from Keyport, however there weren’t any down in Tucson, AZ. Since there’s really only one go at getting the blanks cut (without paying money and ordering more), getting a good cut is key, and I worried that Ace or Home Depot might mess things up, especially after having a few keys cut at Home Depot that needed to be re-cut. I ended up going to Bruce’s Lock Shop on Broadway, who had no problem with the blanks, and charged just $2 for my 4 keys. All of my keys worked perfectly in their respective locks – phew!
Of particular interest is the chipped car key, which comes along with a plastic insert (for you to stick a loyalty club barcode on) and the transponder chip at the end. Both of the relevant vehicles I ordered car keys for support onboard programming, which is simple – you insert the original OEM keys one after the other, then the third key you want added to the ECU, and boom, it works. How this goes is largely a function of your car, of course.
The other difficulty with the car key is that you must make sure you have adequate clearance around the keyhole for the whole Keyport to rotate, a little over a 1″ diameter circle. In addition, this means that the middle two Keyport slots basically must be dedicated to the car key and transponder / barcode insert, so the turning radius is minimized. I have no problem with clearance or turning the Keyport in my 2005 F-150, though it is tight. I also worried about whether a Keyport full of keys would be heavy enough to cause concern about wearing the car’s key slot on the steering column, and thankfully it seems light enough that I’m not worried about damage happening.
The rest of the keys for me were very simple and turn in their respective tumblers just fine. If you have a particularly torquey lock, however, I could see how Keyport might not handle it. The documentation supplied with the box notes a design torque of up to 20 inch-lbs, and that most locks only require 1-3 inch-lbs. I can see how this is a very big design concern, since you’re no longer just torquing the metal head of a key, but instead this large assembly.
Overall I’m pretty pleased with how things turned out, and the end result is that I no longer have a huge carabiner of keys poking me in the leg or taking up space in my pocket that could be otherwise used for additional smartphones. I still have to get the second set cut, but don’t expect any problems since it’s largely the same set of keys.
A Quick Analysis of EXIF data from iPad (3rd Gen) Camera Samples
Mar 8th
Previously I posted about the EXIF data present in Apple’s untouched, straight-from-the-device iPhone 4S camera samples. Today, I saw that they had done the same thing again by posting original samples of images taken from the iPad. There’s still no original video sample (instead just a compressed one) so unfortunately there’s no telling whether A5X gets a better encoder than the one from A5. I wouldn’t hold my breath, however, as it’ll probably wind up being the same 24 Mbps H.264 baseline with 1 reference frame.
Like before, Apple has left the EXIF data intact on its samples, including the geotagging data for a surprising number. I think it’s interesting to just take a look.
Image 1 – IMG_1610.jpg
Flowers seem to be a recurring thing for Apple photo samples, and in general are a subject that probably resonates with even amateur macro photographers.
ExifTool Version Number : 8.68 File Name : IMG_1610.JPG Directory : /Volumes/Macintosh HDD/nerdtalker/Downloads File Size : 1518 kB File Modification Date/Time : 2012:03:08 12:44:45-07:00 File Permissions : rw-r--r-- File Type : JPEG MIME Type : image/jpeg Exif Byte Order : Big-endian (Motorola, MM) Make : Apple Camera Model Name : iPad Orientation : Rotate 180 X Resolution : 72 Y Resolution : 72 Resolution Unit : inches Software : 5.1 Modify Date : 2012:02:16 11:19:30 Y Cb Cr Positioning : Centered Exposure Time : 1/2160 F Number : 2.4 Exposure Program : Program AE ISO : 80 Exif Version : 0221 Date/Time Original : 2012:02:16 11:19:30 Create Date : 2012:02:16 11:19:30 Components Configuration : Y, Cb, Cr, - Shutter Speed Value : 1/2160 Aperture Value : 2.4 Brightness Value : 10.13573086 Metering Mode : Multi-segment Flash : No flash function Focal Length : 4.3 mm Subject Area : 1295 967 699 696 Flashpix Version : 0100 Color Space : sRGB Exif Image Width : 2592 Exif Image Height : 1936 Sensing Method : One-chip color area Exposure Mode : Auto White Balance : Auto Focal Length In 35mm Format : 35 mm Scene Capture Type : Standard Sharpness : Normal GPS Latitude Ref : North GPS Longitude Ref : West GPS Altitude Ref : Below Sea Level GPS Time Stamp : 19:19:30.6 GPS Img Direction Ref : True North GPS Img Direction : 267.2341772 Compression : JPEG (old-style) Thumbnail Offset : 904 Thumbnail Length : 10049 Image Width : 2592 Image Height : 1936 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2) Aperture : 2.4 GPS Altitude : 0 m Above Sea Level GPS Latitude : 38 deg 21' 21.60" N GPS Longitude : 123 deg 4' 1.20" W GPS Position : 38 deg 21' 21.60" N, 123 deg 4' 1.20" W Image Size : 2592x1936 Scale Factor To 35 mm Equivalent: 8.2 Shutter Speed : 1/2160 Thumbnail Image : (Binary data 10049 bytes, use -b option to extract) Circle Of Confusion : 0.004 mm Field Of View : 54.4 deg Focal Length : 4.3 mm (35 mm equivalent: 35.0 mm) Hyperfocal Distance : 2.08 m Light Value : 13.9
Like last time I’ve reproduced the entire EXIF output using the ever-awesome exiftool, or you can do the same thing (which uses it as a backend) on exifdata.com. It’s the same data just presented in a nicer fashion online (and with a link to google maps).
So a couple things immediately stand out which I’ve bolded. First, the model of the device reflects Apple’s new naming scheme, and reports simply “iPad.” There’s no 3 or “Late 2012″ or any other moniker, which should further confirm (if it’s even possible to more strongly confirm) that the name of the thing is literally just “iPad.” The software this iPad was running is iOS 5.1, which makes sense. Image size is 2592×1936 which works out to exactly 5.01 MP as well – the original iPhone 4 also produced images 2592×1936 in size, in fact, I wouldn’t be surprised to see the same OmniVision CMOS being shared between the 4 and iPad (3rd Gen).
Moving on we also see that the focal length and field of view reported in EXIF data are exactly the same as those from the iPhone 4S. This does seem to back the claim that the iPad 3rd Gen is indeed using the same optical system/module as the iPhone 4S, at least superficially. Further, this means that the two must be using the same size sensor to achieve the same field of view with the same 4.3mm focal length.
Update: This ended up being the case, as the iPad (3) uses the same CMOS as the iPhone 4 (as predicted), which is OmniVision’s OV5650. That sensor has 1/3.2″ size and 1.75µm pixels. Recall that the iPhone 4S uses Sony’s IMX145 sensor which is 1/3.2″ as well, but with 1.4µm pixels. Using the same optical format is what makes it possible for Apple to reuse the same 5P optical design between the iPhone 4S and iPad (3).
The image is recorded at ISO 80 (which is the lowest I’ve seen the 4S go as well) and at 100% crop looks pretty good, though I wouldn’t go so far as to say it’s mindblowing. There’s some definite noise visible in the sky and some noise-reduction which seems to battle it. Thankfully Apple still isn’t using a sharpening kernel, so there aren’t any halos around the flower’s petals. The lower part of the flower petal also has some oversaturation (100% white). The good part is that it seems to inherit the good optical qualities from the 4S system (same module, different CMOS I guess) and there’s minimal distortion or vignetting, two things that drive me absolutely crazy with most smartphone/tablet camera modules.
Location this photo was taken is Bodega Bay, CA. The photo was also taken on February 16th if the data is to be believed.
Image 2 - IMG_0470.png
Image 2 is pretty surreal. First off, it isn’t a jpg (which is why I’ve added the extensions to these headings) but is rather a png. I’m not sure whether this was just an honest mistake, but something is really weird here and the image obviously didn’t come in this extension or format directly from an iPad.
Pulling out the EXIF data raises more questions than it answers:
ExifTool Version Number : 8.68 File Name : IMG_0470.png Directory : /Volumes/Macintosh HDD/nerdtalker/Downloads File Size : 5.1 MB File Modification Date/Time : 2012:03:08 12:44:50-07:00 File Permissions : rw-r--r-- File Type : PNG MIME Type : image/png Image Width : 2592 Image Height : 1936 Bit Depth : 8 Color Type : RGB Compression : Deflate/Inflate Filter : Adaptive Interlace : Noninterlaced Pixels Per Unit X : 2835 Pixels Per Unit Y : 2835 Pixel Units : Meters Profile CMM Type : Lino Profile Version : 2.1.0 Profile Class : Display Device Profile Color Space Data : RGB Profile Connection Space : XYZ Profile Date Time : 1998:02:09 06:49:00 Profile File Signature : acsp Primary Platform : Microsoft Corporation CMM Flags : Not Embedded, Independent Device Manufacturer : IEC Device Model : sRGB Device Attributes : Reflective, Glossy, Positive, Color Rendering Intent : Perceptual Connection Space Illuminant : 0.9642 1 0.82491 Profile Creator : HP Profile ID : 0 Profile Copyright : Copyright (c) 1998 Hewlett-Packard Company Profile Description : sRGB IEC61966-2.1 Media White Point : 0.95045 1 1.08905 Media Black Point : 0 0 0 Red Matrix Column : 0.43607 0.22249 0.01392 Green Matrix Column : 0.38515 0.71687 0.09708 Blue Matrix Column : 0.14307 0.06061 0.7141 Device Mfg Desc : IEC http://www.iec.ch Device Model Desc : IEC 61966-2.1 Default RGB colour space - sRGB Viewing Cond Desc : Reference Viewing Condition in IEC61966-2.1 Viewing Cond Illuminant : 19.6445 20.3718 16.8089 Viewing Cond Surround : 3.92889 4.07439 3.36179 Viewing Cond Illuminant Type : D50 Luminance : 76.03647 80 87.12462 Measurement Observer : CIE 1931 Measurement Backing : 0 0 0 Measurement Geometry : Unknown (0) Measurement Flare : 0.999% Measurement Illuminant : D65 Technology : Cathode Ray Tube Display Red Tone Reproduction Curve : (Binary data 2060 bytes, use -b option to extract) Green Tone Reproduction Curve : (Binary data 2060 bytes, use -b option to extract) Blue Tone Reproduction Curve : (Binary data 2060 bytes, use -b option to extract) White Point X : 0.31269 White Point Y : 0.32899 Red X : 0.63999 Red Y : 0.33001 Green X : 0.3 Green Y : 0.6 Blue X : 0.15 Blue Y : 0.05999 Image Size : 2592x1936
The Microsoft and HP lines above are just talking about the ICC profile and header attached to the image. It’s an sRGB 1998 ICC profile, and there are CMM type fields (Lino) and others. I would suspect that this image was put through some software with a color management system which saved this information in the headers, and the person saving it chose PNG to not introduce more JPEG artifacts by re-encoding an already lossy-encoded image.
I’m not going to pretend to know exactly what went on here, but it’s fairly obvious the image didn’t come out of camera.app this way…
Image 3 - IMG_1190.jpg
Image 1190 is of a beached boat with “Point Reyes” marked on it. Thankfully this is a JPEG and not a PNG with everything stripped out.
Software : 5.1 Modify Date : 2012:02:14 16:14:55 Y Cb Cr Positioning : Centered Exposure Time : 1/1439 F Number : 2.4 Exposure Program : Program AE ISO : 80 Exif Version : 0221 Date/Time Original : 2012:02:14 16:14:55 Create Date : 2012:02:14 16:14:55 Components Configuration : Y, Cb, Cr, - Shutter Speed Value : 1/1439 Aperture Value : 2.4 Brightness Value : 9.728654971 Metering Mode : Multi-segment Flash : No flash function Focal Length : 4.3 mm Subject Area : 1295 967 699 696 Flashpix Version : 0100 Color Space : sRGB Exif Image Width : 2592 Exif Image Height : 1936 Sensing Method : One-chip color area ... GPS Altitude : 0 m Above Sea Level GPS Latitude : 38 deg 5' 51.60" N GPS Longitude : 122 deg 51' 3.00" W GPS Position : 38 deg 5' 51.60" N, 122 deg 51' 3.00" W Image Size : 2592x1936 Scale Factor To 35 mm Equivalent: 8.2 Shutter Speed : 1/1439 Thumbnail Image : (Binary data 9285 bytes, use -b option to extract) Circle Of Confusion : 0.004 mm Field Of View : 54.4 deg Focal Length : 4.3 mm (35 mm equivalent: 35.0 mm) Hyperfocal Distance : 2.08 m Light Value : 13.3
I didn’t paste the whole output since it’s a lot more of the same as before. Still an iPad running iOS 5.1, same focal length, field of view, all that good stuff. ISO is still 80 as well.
The location is Martinelli Park near Point Reyes (hence the marking), taken on February 14th, 2012. This is two days before the first image in the set, and very close to it (Bodega Bay and Point Reyes are essentially neighbors, at least based on Google Maps)…
Subjectively this image looks pretty decent, though there is definite blurring and loss of high spatial frequencies in the brown grass at left, though this is a challenging subject and great place to look for any camera to start making things a homogenous mess.
Image 4 - IMG_0561.jpg
This is a photo of some dog, and is the only portrait orientation photo in the set. Seriously I have no idea what kind of dog this is, I guess that cements my status as not an animal person.
Software : 5.1 Modify Date : 2012:02:09 12:03:06 Y Cb Cr Positioning : Centered Exposure Time : 1/1890 F Number : 2.4 Exposure Program : Program AE ISO : 80 Exif Version : 0221 Date/Time Original : 2012:02:09 12:03:06 Create Date : 2012:02:09 12:03:06 Components Configuration : Y, Cb, Cr, - Shutter Speed Value : 1/1890 Aperture Value : 2.4 Brightness Value : 10.12332838 GPS Altitude : 0 m Above Sea Level GPS Latitude : 34 deg 1' 14.40" N GPS Longitude : 118 deg 47' 10.80" W GPS Position : 34 deg 1' 14.40" N, 118 deg 47' 10.80" W Image Size : 2592x1936 Scale Factor To 35 mm Equivalent: 8.2 Shutter Speed : 1/1890 Thumbnail Image : (Binary data 8699 bytes, use -b option to extract) Circle Of Confusion : 0.004 mm Field Of View : 54.4 deg Focal Length : 4.3 mm (35 mm equivalent: 35.0 mm) Hyperfocal Distance : 2.08 m Light Value : 13.7
Again there’s no point in republishing all the EXIF data as much of it is the same as before and seems to be valid. ISO is 80 once again.
This photo interestingly enough was captured before all the others, on February 9th, 2012, five days before the third image above. Location this time is Paradise Cove right on the PCH. It’s interesting to me that all the images seem to be of or taken near beaches for some reason.
Final Thoughts
Of the images we can extract EXIF from, all are taken at ISO 80. This is probably no coincidence, as Apple probably wants to stay away from low light performance where basically everything struggles right now even with BSI CMOSes and fast F/2.2 or F/2.4 optics. I guess the beach is a logical choice of scenery to that end since there’s a lot of light (sand is reflective, after all). The photos are from different dates as well, which seems like a risky thing to do when trying to minimize the chances of some crazed tech-paparazzi catching an Apple engineer/exec with an unreleased iDevice snapping photos. With the iPhone 4S we saw a huge variety of different locations spanning California to Yosemite to Germany, whereas the iPad essentially gets a drive up the coast and a week of photos. Read into that what you may.
Obviously the last point is that the iPad 3rd gen’s camera is much improved from the almost universally-derided iPad 2 camera (which borrowed the iPod touch module). It’s interesting to see a move to using the same optical system as the 4S and likely the same CMOS as the 4, though it does make sense to maximize component cross-compatibility and drive up volume.
Verizon 4G LTE Coverage Profile In Tucson Arizona
Apr 5th
A while back, Verizon announced more detail about their plans to bring 4G LTE to the Tucson area. I’ve been paying hyper-close attention to each carrier’s 4G rollout plans in my area, primarily out of personal interest, secondarily because that means when phones launch I won’t have to keep driving to Phoenix to test them. The actual press release is here, if you want to read it. If you want the actual nugget of new information, however, just read this:
The 4G LTE network will extend through Tucson between Interstate 10 and Harrison Road, north to Sunrise Drive and south to Valencia Road, including the Tucson International Airport.
That’s a bit curious actually, since the four thoroughfares specified don’t completely bound a region. Sunrise doesn’t extend all the way to Harrison, and Valencia is a bit discontinuous as well. Further, Interstate 10 bounds the bottom and left side of the box. I spent some time figuring out what that actually looks like, and created a google maps/earth .kmz overlay image, and image.
There’s a bit of interpolation going on here, namely assuming that Ina will bound the north part after Sunrise disappears, and that the jump from Sunrise to Harrison takes place like shown. It gives a decent impression of what the initial profile will be like, however.
A few things immediately stand out. First, there’s a bit of the east side that is genuinely clipped off. Second, south tucson between I-19 and I-10 doesn’t seem to make sense. It’s definitely a part of “Tucson,” yet the bounded region that Verizon stipulates would seem to preclude coverage making it down there. But perhaps the most head-scratchingly surreal part of the box is the fact that coverage will only extend to Sunrise.
Beyond and around the Sunrise/Skyline line is the foothills. This is the region where it makes the most sense to deploy 4G LTE due to the kind of neighborhood it is. Extending only to Skyline (and not even a little beyond) seems like a completely missed opportunity. It’ll be interesting to see the actual coverage profile and when things start rolling out. As of right now, I can confirm that there isn’t 4G LTE anywhere in town – I’ve tested at the airport, downtown, U of A, and throughout town with the HTC Thunderbolt, Pantech UML290, Samsung hotspot, and another unreleased datacard thus far to no avail. Hopefully it comes soon. Verizon has 22 MHz of 700 MHz spectrum (upper c block) in most of Arizona including Phoenix and Tucson. Only the far west part of Arizona has 34 MHz.
Update:
Today Verizon Wireless announced that the Tucson, AZ market will be included in the August 18 nationwide LTE rollout. Last week I heard from a good friend of mine with a Droid Charge that LTE was working in various parts of Tucson already, no doubt as Verizon tests individual eNodeBs for functionality.
Update 2:
At around 10:30 PM on August 17, Verizon 4G LTE went live in Tucson. Some people on Twitter sent me notifications about them seeing the service light up in areas that were even outside the circle painted by earlier press releases, so if you’re reasonably close to the boundary outlined in the press release, there’s a good chance LTE is active in your area.
One person tweeted a link to some speedtests, which show that things are indeed working:
Currently I don’t have any 4G LTE devices, but when I get another one for testing we’ll have a better picture of coverage and speeds in this market.
Update 3:
It’s live, and it’s fast! I’ve tested it thoroughly and published some results already in the context of the Droid Bionic review, which is only a UE Category 2 device. Soon as I get a UE Category 3 LTE device I will run some more tests and get a better picture.
AT&T Bands in Las Vegas – 850 GSM/EDGE, 1900 UMTS/3G
Jan 3rd
Last time I was in Las Vegas it was for MIX 10 and Windows Phone 7 (back when it included ‘series’ at the end). This time, the reason is CES 2011 with AnandTech and a whole bunch more mobile devices.
I thought it was interesting last time I came that most casino floors in Las Vegas had shockingly poor or non-existant UMTS (3G) coverage on AT&T. I guess I didn’t find it too shocking, since coverage inside buildings in a dense urban environment is probably the most challenging for mobile networks, but it seemed to be a consistent problem. After getting frustrated about 6 hours into my stay, I decided to switch entirely to EDGE for the duration just because of how annoying being constantly handed between GSM/EDGE and UMTS is when you’re trying to do things. For whatever reason, back then I didn’t think to pull up field test on the iPhone 3GS I was currently carrying to see what bands were assigned to which network technology.
Now that I’m back, I decided to check. Thankfully, Apple has restored most if not all of the Field Test data products in iOS 4.2.1, a huge step forward from 4.1 just allowing signal strength in dBm at top left, and a far cry from 4.0 which shipped with no field test whatsoever. To save potential readers some googling, to get here, enter *3001#12345#* from the dialer and hit call – if it hasn’t been removed yet, you’ll get dumped into Field Test on iOS.
In EDGE and tapping on GSM RR Info, it’s immediately obvious why I saw that behavior last time I was here:
ARFCN dictates what channel inside what band we’re on, and 142 just happens to lie inside the GSM 850 band. It’s a number basically used to refer to the FDD pair of frequencies the phone is currently using. You can calculate exactly what frequency downlink and uplink are on with a little math and some reference guide (there’s a good table here), but basically with an ARFCN of 142 we know immediately that GSM/EDGE is on AT&T’s 850 MHz spectrum. Between 128 and 251 is that GSM850 spectrum.
Now, what about UMTS/3G? Enabling 3G (look at how weak that signal is…) and going into UMTS RR info, I saw the following:
Looking at the fields “Downlink Frequency” and “Uplink Frequency” we can see the device’s UARFCN channel numbers. It’s the same thing, but U for UMTS. Again, with a reference aide (read: wikipedia) we can see that UMTS/3G is working in the PCS 1900 MHz band.
Remember that higher frequencies are less effective at propagating through buildings. It’s pretty obvious now why getting good 3G coverage on AT&T is a challenge deep inside a casino in Las Vegas. There’s nothing inherently wrong with putting GSM/EDGE on 850 and UMTS on 1900, it’s just interesting in practice how immediately obvious the difference is walking around. Propagation is a challenge in dense urban environments with lots of people moving around to begin with, I’m sure this doesn’t help in Las Vegas. AT&T promised to put all of its 3G (UMTS) network on the 850 MHz band (wherever it’s licensed to use it) by the end of 2010, but sadly that hasn’t happened quite yet, at least in this market. I’ll keep checking, but thus far it’s been solidly in 1900 PCS. Oh well.
Setting SSD instead of HDD Icon on OS X
Aug 2nd
It’s been an awful long time since I’ve blogged anything on my personal site. I’ve been working hard and doing lots of smartphone reviews for AnandTech lately, and just haven’t found the time. That said, I do have a rather substantial backlog of ideas that I’ve been meaning to post. The first and quickest of which is how I swapped my HDD icon on OS X 10.6.4 Snow Leopard on my MacBook Pro from the rather generic HDD icon to a more fitting SSD icon.
To begin with, I acquired an OCZ Vertex 2 120 GB SSD and installed it in my 2010 MacBook Pro. I had been waiting for a while to do this move, particularly because I find the optical drive of marginal use and decided to try an OptiBay adapter which would let me use the optical drive’s space as an other 2.5″ bay for whatever I wanted. More on that later, but I moved the MBP’s rather generic 5400 RPM 500 GB traditional platter drive into this optibay space, and stuck the 120 GB Vertex 2 where the HDD was.
Just get to how you did it already!
Cloning the drive onto the SSD was easy, everything works fine, but I was left with that generic and somewhat ugly mechanical hard disk drive icon that OS X has stuck with since forever.
First, I set out to create an appropriate SSD icon. Getting a Vertex 2 image was pretty simple, and I cleaned it up, cropped it, and added the appropriate clipping mask/alpha channel (depending what name suits you) for transparency. It’s a nice big PNG here:
Vertex 2 SSD by OCZ
The next step was changing the icon. It used to be trivially simple in OS 9 to do this, but things got a bit more complicated in OS X. To do so, I found a program named (aptly enough) “Set Icon” you can get here.
Set Icon for OS X
Pretty straightforward. Select the drive, drag an icon in, and click set icon.
Now you’ll have something like this:
Mac SSD
Looks pretty good alongside the old icon, if I may say so myself: 
Pretty simple, right? Enjoy!
NiZn PowerGenix Batteries
May 13th
I’ve been meaning to write about a set of interesting new rechargeable AA batteries I came across for a while now. Last year (wow, has it really been that long?) I came across a review on engadget of some PowerGenix NiZn (Nickel Zinc) rechargeable batteries which promised better performance, higher voltage than NiMH, and greater capacity. I was compelled to invest in some otherwise experimental and new rechargeables for a few reasons:
Doing indoor photography with my girlfriend – especially weddings – it becomes apparent just how many AAs you can go through quickly. So many that it’s relatively expensive and prohibitive to keep up and carry all those batteries around. They’re expensive, and just don’t last long enough. One or two hundred shots or so, if I recall correctly.
SB600 Flash
Anyhow, right after getting them and charging them, I decided to shoot a wedding with my SB600 flash and the NiZn batteries. I was immediately floored at how fast the flash recharged and how performance never seemed to fade like alkalines do. Usually, flash performance seems to fall off exponentially with the generic alkaline batteries – eventually the time it takes to recharge gets so long you can’t take photos of anything. So what’s useful about the NiZn was the hugely fast, super quick recharge time.
That’s also… the problem. While shooting that wedding, I managed to somehow completely blow out the flash. This thing was under 2 months old, used at a few other weddings, without what I’d consider very many activations at all. The SB600 apparently has no thermal cutoff at all, allowing the whole thing to overheat. Whatever the case, while shotgunning some photos of the dance floor in low light, it stopped working. The flash didn’t feel notably hot, but the flash showed an error on the screen and wouldn’t work from then on. Anyhow, I shipped the flash back into Nikon and had a replacement about a month later, but the point is that I’m now far too scared to repeat the “experiment” again.
It seems that two things are possible:
- The SB600 lacks adequate/any thermal protection preventing the flash from overheating or being fired too quickly
- The SB600 possibly relies on alkaline AA battery performance to prevent the flash from being overheated
- I realize that the NiZn PowerGenix batteries are 1.6 volts (as opposed to the 1.5 standard for alkaline, and 1.2 for NiMH). At the same time, there should definitely be regulation of some kind preventing failure.
The batteries themselves are remarkable in their performance, but it’s that which scares me out of using them in the flash where they’re needed most.
NiZn PowerGenix AA Batteries
What brings this all up is that engadget compared the PowerGenix batteries to some of the other new (and exotic) choices from Energizer and Sanyo Eneloop, and I left a comment.
I purchased the NiZn batteries after your initial review and was super stoked when they came. I’m an avid digital photographer, and replacing flash batteries at a wedding actually gets expensive enough to make buying a bunch of rechargables worthwhile.
That said, I had a brand new SB600 (just like yours) burn out with no warning while shooting with the NiZn batteries. I had to ship the whole thing in and get it replaced. I browsed the Fred Miranda forums some time later and found a bunch of people with the same issue – the SB600 relies on Alkaline batteries simply not being able to drive enough power quick enough when shotgunning that flash to avoid burning out. There isn’t any thermal safeguard.
So be warned, even though you’re testing on an SB600, if you actually do go out and abuse the batteries like you would at a big event firing the flash a lot, you WILL nuke your stuff. I’m too scared to use my NiZn batteries now.
That Fred Miranda forum thread I mentioned is here.
iPhone 4G – ‘HD’ Antennas Found?
Apr 20th
****
See the update at the bottom for the real deal, I was partly wrong about some of the antennas in iPhone 4, though I was indeed right about the connector locations for the bottom, and partly for the top.
****
I’ve been following the iPhone 4G/HD leak saga like a hawk, and until now I haven’t been able to really add anything to all that’s been said. However, today, Gizmodo published pictures of the inside of the iPhone 4G hardware they obtained. They didn’t talk about much other than the absurd number of screws (upwards of 30), battery size, packaging, and potential ease of replacement. In fact, their primary aim seems to have been locating “APPLE” markings on the few ribbon cables inside, rather than picking apart Apple’s hardware choices. No doubt disassembly was challenging, potentially explaining why there aren’t any photos of the iPhone with the “connect to iTunes” lock screen (broken after disassembly?).
They neglected to remove the EMI shields atop the interesting bits on the PCB, what I would’ve considered the biggest news about the device. So we still don’t know virtually anything about SoC, how much NAND flash there is onboard, RAM, the hugely important baseband (and whether this thing is potentially dual CDMA/GSM and UMTS for it to work on Verizon/Sprint alongside T-Mobile and AT&T), WiFi or Bluetooth choices (likely the same as the iPad, however), or anything else you’d expect to glean without those shields in place. In short, all the squares in this diagram from the iPhone 3GS are big question marks for the iPhone 4G. Still, we can make very good guesses about what the likely choices are.
PCB components for the iPhone 3GS labeled by Phone Wreck
However, being the RF-obsessed dude I am, I scrutinized the photos for some time looking for other interesting bits. I think I’ve found some interesting things.
First and foremost, I think that there are two discrete antenna assemblies in the phone. One at the top, one at the bottom (as you’d hold it in your hand).
Red box is antenna 1, Blue is antenna 2. Source gallery
Note that the phone in this picture has been rotated; the red circled area on the hardware is actually the bottom. Now, look at the two places I’ve marked with the white arrows. You can very clearly see a pigtail and standard radio connector on the top one, and a connector pad at the tip of the arrow at right. This is 100% certainly an antenna, and it’s also in the same region of the hardware (at the bottom) as the 3GS.
Bottom Antenna - two connectors
Above is what I’m talking about at 100% resolution.
Bottom Antenna Connectors Plugged In
Above shows the antenna before being removed, with the pigtail clearly connected to the mainboard PCB. We can make an educated guess that whatever is under the EMI shield next door is the baseband.
Now, compare and contrast to the iPhone 3GS’s ribbon/kapton antenna assembly:
iPhone 3GS flex PCB
And see it inside the black plastic holder (only the trailing ribbon connector is visible at bottom left):
Flex PCB fits inside the black plastic case at bottom
If I’m not mistaken, the two connectors there are for discrete antennas inside, for cellular radio and WiFi/Bluetooth. I’m not infinitely familiar, but there only seems to be one antenna assembly in the 3GS at the bottom.
Now, on the iPhone 4G photos, there appears to possibly be a second possible antenna at the top.
Top antenna in place
Top antenna removed
I’ve labeled the connector that I can make out. Given the similar black packaging (possibly housing the flex PCB like in the 3GS), it seems likely this is another antenna.
I’ll leave you to speculate about why Apple might potentially want two discrete cellular antennas in their next generation phone…
Update:
After looking through the FCC OET internal photos of a huge number of other dual CDMA/UMTS design phones, all of which only require one antenna, I’m pretty sure the other top component is something less insidious. It’s entirely possible this is nothing more than a connector, some support structure, or perhaps maybe it is indeed an antenna, but for WiFi (N?). Whatever the case, I’m completely uncertain what this thing is, or if it’s part of the baseband. Obviously, the part at the bottom is an antenna, but the top part I’m more and more uncertain about.
We’ll see as time goes on and better pictures are made available what it is, but I’m not confident it’s an antenna anymore.
Update 2:
Of course, we now know the real deal with the iPhone 4. I was wrong about what the antennas were, but right about the connectors. Up at the top, if you scrutinize iFixit’s teardown, you can see a small gold pad right above a test junction for the WiFi/GPS/BT 2.4 GHz antenna. There’s a trace on the EMI shield which leads to a contact screw (gold, so it’s visible) leading directly to the antenna. So the connector for the 2.4 GHz antenna is up at the top near that seam.
iPhone 4 Top Connectors
For the UMTS/GSM antenna, the connector snakes across from the PCB to the left side of the phone facing up (facing down, it snakes to the right, like in this photo):
Inside the red square is the contact point
You can see the test point and connector at the left, the pigtail leading to the right across the EMI shield, and the gold screw which connects the whole deal to the aluminum antenna.
Of course, the interesting part is that this becomes the most active region of the antenna. It’s a monopole, rather than a dipole – in this configuration. The result is that for 1/4 wavelength, that part of the aluminum is very active at radiating RF. This is also the location your palm rests, interestingly.
I’m going to talk about the real deal on AnandTech shortly, so stay tuned…
It’s live here now: http://www.anandtech.com/show/3794/the-iphone-4-review/1
