I’m currently looking for a better way of mounting a number of different gadgets to my car, including my iPod, two ham radio remote heads, my Garmin eTrex GPS, and perhaps a few more. Since many of these devices will be upgraded over time, I need any mounting system to be standard enough and interchangeable enough to make this a no-brainer. It appears that there are at least two standard mounting systems that would help me—the AMPS and NEC mounting hole patterns. These are common on many of the mounting brackets on the market, including those from Pro-Fit International, Panavise, and RAM Mounts. Some have both, though the AMPS pattern is more common.

It’s not just these three companies that use AMPS—it is found on some GPS navigation systems (Magellan, at least), many XM radios, and many automotive mobile phone mounts.

Yet despite knowing part of the AMPS specification (a rectangular hole pattern measuring 1.496 by 1.181 inches on-center), I can find no verification or definition of the standard; nothing that comes close to a citable source or reference document. I asked Pro-Fit International’s product designer (co-incidentally a fellow ham) about this, and he knows that it was a Motorola-originated standard, but has never seen a specification either. And there is no agrement on the spacing, either. One drawing from RAM Mount Systems shows 1.50″ × 1.188″ with a hole diameter of 0.218″, and nowhere can I find any mention of what size screw or bolt and thread count is to be used when designing female threads into a device.
AMPS appears to be a long-lived mounting system for the mobile electronics industry, but with no technical documents to reference, its specifications and existence seem to get passed around by word of mouth. This is insane. And it has now become one of the acid tests for CADJournal. If you make a product designed to go in a car—or a CAD tool used to design them—that I wind up reviewing, support for the AMPS pattern (along with other interface standards) will be one of the items I grade on.

Today’s task is something that should be simple–I have our radio club logo in vector form as an Illustrator CS2 image (with nothing but vectors, arcs, and text) and need to a scalable vector version that can be used in applications such as PowerPoint. Windows’ Enhanced Metafile (EMF) is the perfect choice for this, since it can support all of these drawing elements correctly, and with 32-bit precision.

WMF, the older 16-bit Windows Meta File standard from Windows 3.1, is not as capable, and is not capable of rendering the line joins correctly, and doesn’t even support arcs and circles. The Windows 95 version of WMF does support arcs and circles, but is still problematic.

Exporting the logo from Illustrator is easy enough, with the Export command. And using Windows XP’s Preview feature in Windows Explorer shows the result to be a perfect copy of the Illustrator file. However, when placing that EMF in Word or PowerPoint (Office XP), the line joins are incorrectly beveled, making the logo ugly and incorrect.

One problem with Illustrator is that it doesn’t let you choose between the two flavors of EMF–the original GDI based EMF from Windows 2000, or the enhanced GDI+ based EMF from Windows XP.

Since Windows XP’s image preview handles the EMF logo just fine but the Office XP applications don’t, I’m fairly confident that the problem lies with Microsoft’s code, not Adobe’s.

There needs to be a reliable way to include high-quality, scalable company logos in a wide range of software that design firms use in their communication and marketing efforts. For at least the Windows platform, this means EMF, so let’s get this right folks!

To borrow a phrase from a former co-worker and tech editor of mine, the Mobile Web “sucks dead bunnies”. Unlike other technologists who believe that WAP was a solution looking for a problem, I’m a firm believer that just reformatting Web pages designed to be used on desktop and laptop computers is not sufficient for providing a fully useful Internet experience to PDAs and mobile phones.

What went wrong, and must be fixed to make the Mobile Web happen for more than just those with deep enough pockets to tie themselves in with the carriers? Something very simple called content negotiation. Every WAP browser I have ever tried makes the same fatal error of claiming to support both (X)HTML and WAP in the header they send to Web servers, and not specifying a preference. When visiting a server that is properly configured for content negotiation with both (X)HTML and WAP pages, the server will properly send the higher-quality file–the desktop (X)HTML one–that most mobile phones can’t handle (either in a usable manner or more oftent not at all). This is relevant for anyone involved in the CAD or design markets because of the coming of SVG and location-based services to mobile phones. Before these can be widely deployed though, this fundamental (and extremely easy to fix) flaw must be corrected.

So the acid tests begin now. My latest site, PDAcritic.com, is properly configured with most pages available in both XHTML and WAP versions. All of the content there fully complies with the IETF and W3C standards, so if a desktop browser (sorry, Microsoft) or WAP browser (sorry, Nokia, Motorola, Samsung, SonyEricsson, et. al.) can’t even load the site, don’t blame me–ditch that browser and go find one that works.

I’ll provide updates as I test browsers, phones, and PDAs for compatibility with this and other technologies of interest to this community. And you’ll know who the winners and losers are, because I’ll be handing out letter grades that won’t pull any punches. Sony Ericsson is the first, and their S710a earned a D−.

One of the tasks for the ham radio club I’m involved with is updating the membership “database”. Not updating in the sense of adding and revising records, but updating its structure from an Excel spreadsheet to a proper database. This has been actually been a multi-phase process.

The first time I got involved last year, it was because of the need to quantify the percentage of our members who are also current ARRL members (a requirement for club affiliation with the ARRL is 51% membership among the club members). Part one was straightforward–converting text entries of dates to date values, for example. But then adding all the data needed to be able to calculate paid/unpaid members, voting elegibility, and the other needed calculations proved difficult to do. I wound up adding 10 columns to the spreadsheet, each with complex formulas that resulted in either a 1 or 0 that could then be counted and used in other calculations. It wasn’t the right way, but the most expedient because the maintainer was most familiar with Excel and we needed to put more thought into our database needs.

We’re now in that phase, and I’ve been playing around with a trial copy of FileMaker Pro 8, expecting it to be a snatch to migrate the data and design a proper database. (The two members who will be maintaining the database already have FileMaker, so it’s the obvious choice.)
Hah! The first problem is that FMP imports all 65,484 rows of the Excel spreadsheet as records, even though all but a few hundred are empty. (Selecting and naming a range didn’t help, because FMP doesn’t let you specify ranges, named or otherwise.) Fortunately, deleting all of the blank ones only required 5 separate steps. Of course, FMP imports all fields as type “Text”, so you have to go re-define all the number and date fields that already had been marked as such in Excel.

After all of this nonsense, I decided to design the database from scratch, then import from Excel. Since my Excel and database field names are slightly different, FMP doesn’t get the mapping quite right. And although the import dialog allows me to reorder the fields, the design completely fails if I only need to fix one field, since dragging it into position forces everything below it that had been correct to be off by one. Talk about fencepost errors!

After working around all these problems, I have a rough database design that I like. I still have to fix some of the formatting (some membership numbers are showing up as 2.0001e+09), convert a few fields to a Boolean type, define pick lists, and restructure a few other fields, then I can enjoy the fun of figuring out how to do a mail merge in yet another application, and discovering if this FileMakre Pro 8 database will work with older versions.

I was experimenting with a new web service this morning for our local ham radio club, and the profile page requested an icon of a very specific size: 48 pixels square. Since I have our club logo as an Illustrator vector image, this should have been an easy, one-step process. Right?

Wrong. Although the Save for Web command in Illustrator allowed me to save the vector image to a PNG raster image directly, I could only resize the aspect ratio that Illustrator had chosen (48×30). Getting the simple square image desired required me to open the image in Photoshop, change the canvas size and specify on which edge(s) blank pixels were to be added to fill in the rest of the space.

Needing to save vector artwork to very specific image sizes is so common–in creating icons, Web ads, and many other tasks, that I’m amazed the ability to specify the export size and dimensions has not been a part of Illustrator for years.

Although the implementation of the mobile Web and cell phones has been badly bungled, last night’s Mobile Monday event, focused on Location-Based Services (LBS) in San Francisco was proof that the mobile Web seems likely to succeed despite the cell phone vendors’ and carriers’ bumbling. Not only was attendance large (about 225 people), several of the speakers were from very large companies. Autodesk ($1.2B annual revenue) and Tele Atlas (€127M annual revenue) are both big players in the mapping business, and their presence helps to validate market potential, while the smaller firms that spoke, such as Bones in Motion, demonstrated the basis for innovation that the co-mingling of mobile technologies can provide.

Autodesk’s Chuck Cone outlined the company’s role in the mobile Web; that of infrastructure and foundation APIs. In addition to providing some of the carriers with back-end technology that enables them to calculate and transport location-based information (from mobile phones with aGPS receivers), they also have partnerships with most of the major carriers to provide mobile application developers with a BREW or J2ME API that is used to retrieve the mobile phone’s location. As is the case with Autodesk’s original AutoCAD developer program, there is no charge for the API or support of it. Autodesk is making its money from the carriers, usually by taking a part of the “dips”, as each GPS location fix is called. If you’re looking to get in on the ground floor of a new industry, now is the time to start trying out the capabilities that LBS will bring to mobile phones and other devices. Currently, the only mobile phone providers with good LBS services are those using CDMA (Sprint/Nextel and Verizon). Cingular and T-Mobile have apparently given up on network-based (TDOA) LBS (except for 911 calls), and will be rolling out aGPS services eventually.
Perhaps the coolest use for LBS I have seen recently was demonstrated by Bones in Motion’s Spencer Nassar. With a small team of just five people, they are developing a location logging tool designed for casual athletes. If you like to hike, bike, or run, their software will let you log your travels and transfer a log to your computer when done, so that you can keep track of your time and distance traveled, post images of your route (on street maps or topographic maps), and perform other analysis on your exercise routines.

Tele Atlas’s talk by was also interesting. Although this company is based in the Netherlands, it has acquired two major U.S.-based navigation companies since 2000–ETAK and GDT. The combination makes them one of the two major players in navigation systems (along with Chicago-based NAVTEQ).

The best laid plans of mice and men…. If you have been wondering what became of me, I have spent the last six months on a completely perpendicular course to what I had set out to take when starting this Journal. I was offered the chance to work for a small ham radio manufacturing and retail firm; an opportunity that combined my desires to be an entrepreneur with my favorite hobby.

While the gig was interesting for a while, it had became clear that it was distracting me from the CAD industry I have spent my career involved in. Despite the frustration with it I found, the experiences were enough to reinforce my beliefs that much of today’s technology is frustratingly inadequate for the smooth and efficient operation of business, and in particular those involved in design and manufacturing. While writing from an ivory tower of sorts at CADENCE magazine, I was often worried that my bitching at hardware and software that didn’t work as easily as I thought it should was much more easily dealt with by those of you in the “real world”.

Having experienced even more frustration in not being able to get all the applications the business uses to work well together (or sometimes, even by themselves) than I ever found conducting product reviews, I have a renewed sense of purpose, and a primary goal of focusing on usability, interoperability, and overall capability in returning to my original goal of creating a new sort of technology journalism.
Now, however, I’m off to Mobile Monday, to find out what Autodesk and others are up to in location-based services. A full report to follow tomorrow, along with an exposé on how the mobile web industry screwed up their browsers big time.

—73