The Firehouse

I have decided to split this blog and dedicate it fully to firefighting-related posts. My personal blog, where I will be writing most frequently, can be found here:

http://mikepuchol.com

See you all there!!

If you’re certain you’re going to crash, where better to plant your SUV than a fire station? For bonus points, damage the engine inside so they have to give your their full attention rather than be distracted by pesky things like fires and such…

It had to happen, after Starbucks and Swisscom ended their contract a few months ago, WiFi has been missing from Starbucks in Spain. Some stores still have the old routers switched on with the ‘eurospot’ SSID, I guess it will take some time to get them all replaced.

Grabbing a coffee I noticed something new on the receipt:

At last, WiFi at my local Starbucks! It’s a shame that it comes a few months late, but welcome nevertheless. It seems that if you own a VIPS card you get double time, up to 90 minutes. The launch was confirmed by BT via Twitter (nice to see they are on top of things!). All they need now is some nice PR material at the stores to show people that WiFi is available, and how to get online.

[Update] I tested the connection on my iPhone today, and there are a few things that need fixing:

- The WISPr code is not fully recognized by the iPhone, and thus you are shown the hotspot’s default landing page.

- Once you have the landing page, you need to tap through to ‘other operators’ so that you can login with the provided BT credentials.

- The BT login page is not mobile-formatted, which makes it a pain to navigate in order to login, even on the iPhone.

- There should be only a password for the free session, having such complex username/password combination is going to put some people off (“where’s the damn forward slash on this phone?!”).

Ideally, BT OpenZone should recognize mobile Safari, and present either a formatted landing page, or suitable WISPr code for the iPhone’s built-in authentication software to kick in. Otherwise, the WiFi connectivity is superb!

YMMV, but I’m very happy with Apple’s Magic Mouse – the absence of a scroll wheel or button is bliss, and the ergonomics, while not as good as some mice by Logitech, are quite good. What I do miss however is the third button, and having other commands via alternative gestures. TUAW even posted an article earlier calling the Magic Mouse a “dog”, in part, due to the lack of a middle button.

Thanks to ifixit.com, we can appreciate that the underside of the Magic Mouse sports a grid of 10 x 13 sensor pads from the logo towards the top of the mouse, and two final rows at the very top, one with 8 sensors and the other with 6:

This gives the mouse the potential to detect one or two fingers placed on it, and the individual motion of each finger, anywhere on the mouse’s usable surface. So, I propose the following gestures. To middle-click (third button), simply place two fingers on the mouse, and click with both at the same time, thus:

To open Exposé or Spaces, place the right finger on the mouse, and scroll up or down with the left finger:

It’s actually quite ergonomic, try it on your mouse, and if you like it, send the suggestion to Apple – if anyone finds a form specific to the Magic Mouse, let me know, otherwise the link points to iMac feedback (as it comes with one). And yes, the images above are taken from Apple’s page and badly photoshopped, my apologies!

So Erick Schonfeld took a shot at the iPhone maps app, which uses Google Maps as its data source, and all other car-mount GPS manufacturers such as TomTom or Garmin, saying that Google should make Apple beg for maps navigation. I don’t agree with much of his post, here is why:

1. Real-time navigation availability depends on the type of license map data is served under, as I explained in a post a few months ago. The map data served by Google to Apple for use on the iPhone does not allow real-time, turn-by-turn navigation, thus, it is cheap and much less money flows from Apple to Google for it. This is explicitly referenced in the iPhone SDK’s licensing terms. Google must be paying a premium on the data it serves on the Android GPS app for this kind of use.
2. A real-time navigation system depends on constant availability of maps, which means online devices, such as an Android phone running Google’s app, must have perfect wireless coverage, in terms of both connectivity and bandwidth, and we know this is next to impossible. A comment on Erick’s post suggests Google caches map data when the route is created, which would be fine…if people followed the route perfectly. Many times, this is impossible for a number of reasons, such as bad routing, roadworks, or heavy traffic. All of these require re-routing, so Google, and any online system, would need to cache also every possible deviation and re-routing from the original path, which is impossible. There is a reason why TomTom’s iPhone app comes loaded with several hundred megabytes of map data.
3. The GPS chipset on mobile devices is not well-suited for high-rate position updates. This is evident if you use TomTom’s iPhone app, and is also evident as TomTom includes a separate GPS chipset in their iPhone car kit, for “…the most accurate positioning“. Since position update rate means battery consumption, and a phone has a ton of battery-consuming electronics on its own, the GPS typically provides less frequent updates than a dedicated GPS device.
4. Dedicated GPS units are best at taking you from A to B, re-routing you within a couple of seconds if you deviate, and showing you the location of speed traps safety cameras and other points of interest (POI). As you go up the price ladder, you are provided with additional functionality, such as voice commands, phone connectivity for hands-free audio and real-time traffic data. On this particular point, I totally agree with Matt Burns on his CrunchGear post, who says of GPS makers: “They are in the habit of producing 78 different versions of the same GPS. Each model steps you up $20 and adds another feature“. But I digress. With such a model, of charging for map updates, or for safety cameras, would they not also be charging for POI data if it was of any real use in vehicle navigation? Like updates to the “Restaurants” category? No, the issue here is that POIs are the least used feature in GPS navigators, and the makers know this. You may occasionally look for the nearest gas station, but that’s about it. If you want to eat something, you will ask around at your destination, or will have looked up options before the trip, but very very rarely do people go looking for stuff on their GPS devices. It’s true that Google makes it a lot easier to access this kind of information, and puts it right there on your face, but nothing will beat a dedicated service such as Yelp, or a dedicated app such as Bliquo (shameless plug for my good friend David Douek, who works there now, hope it helps your SEO at tiny bit!).
5. You can pick up a dedicated GPS unit for almost what you will spend on car mounts and cig-lighter adapter cables. They have faster routing, better planning capabilities, no need for wireless connectivity, and a much better audio output than any mobile phone.
6. You are supposed to be looking at the road while the GPS guides you by voice instructions, not at the GPS screen while it provides you with fancy data and/or graphics. Once you safely stop to look at the GPS, there are much better ways to present useful data, such as POIs, than Google’s interface. Many countries are looking into forcing GPS manufacturers into blanking the screen while the vehicle is moving in order to further prevent distractions to the driver.
7. TomTom, as an example, can add natural voice route requests to their higher-end units via software updates. Some already feature dictated destination input, but its use is clunky and not very useful right now – I bet we will see improvements soon. All it takes is the licensing of a proper speech-recognition engine. Google doesn’t have any major competitive advantage here, other than being the first to implement an (allegedly pending actual reviews) good functionality.
8. TomTom owns Tele Atlas, and Nokia owns NAVTEQ, which combined provide a huge chunk of the map data used by Google Maps. I love you Fake Steve, but you’re wrong on this one – GPS makers are fine, and they know it. Unless Google is planning on re-creating all the map data on their own of course, which is discussed extensively on this post by James Fee, but this would only mean Google would be free from other providers, not crush them.
9. Erick argues that “…the future of mobile apps are Web apps”. I think this is a huge over-simplification – the future of some mobile apps are apps that pull some or all of their data from the web. I regularly use an iPhone app that provides emergency response information on hazardous material (HazMat) incidents – I would be screwed if I had to depend on cellular coverage and a web service for this! We all saw how long Apple’s hard stance on iPhone web apps lasted, and the App Store just broke the 100.000 approved app barrier, so I rest my case.
10. Further from the GPS-centric topic, I’ll question wether Google really developed the Mail and Search functionalities of the iPhone – AFAIK, these are implementations of Mail and Spotlight respectively, can anyone confirm this one?

While it does contain most of the ad-hoc stack, the recently announced Wi-Fi Direct standard is actually an attempt to become more like Bluetooth. Ever since Wi-Fi was invented, ad-hoc mode allowed two or more adapters to form a peer-to-peer network without an access point (AP) running the show. In certain scenarios, there would be connectivity problems when adapters were not configured for automatic IP assignment in the auto-discovery range, or had static IPs setup. Saving these, the user would then have to make sure his operating system had enabled the appropriate sharing protocols so that meaningful things could happen, such as sending files from one machine to the other.

Ever since Bluetooth was invented, it provided a communications stack, and a protocol stack, which encompassed a growing number of profiles. An application only had to talk to the right profile in order to establish communication with another Bluetooth device supporting the same profile, for example, serial port, audio gateway or FTP. During device discovery, a Bluetooth device would query the other about its available profiles, and would then choose the right one as needed. As a practical and recent example, the iPhone initially supported the handset profile, which provides very rudimentary headset functionality and leaves out things like address book access. Over time, the iPhone has been upgraded with more profiles, some as complex as A2DP which allows highish-definition audio to be sent to stereo headphones or speakers. I say “highish” as it uses an audio bandwidth of 16kHz, way below the normal audio response of a set of headphones, leading to a noticeable decrease in quality. But I digress.

In my view, the press release was very badly worded, making it appear as a re-branding of old-time ad-hoc, when it really implies adding a number of protocol stacks and profiles to the standard ad-hoc mode. It is also an attempt to take Bluetooth head-on, with the argument that Wi-Fi is a gateway to a bigger number of services – Bluetooth DSL router, anyone? no? I rest my case. Having such a set of profiles would obviate the need to have Bluetooth chipsets on top of Wi-Fi, which are always an added cost and source of radio interference. We would then have to see how audio accessories cope with this, but then again, I’ve not seen many people carrying Bluetooth headsets around, while car kits can accommodate a Wi-Fi chipset thanks to their board space and bigger battery.

I read with interest the many articles being written around the USB-IF’s decision to give its blessing to Apple’s use of the USB vendor ID, and claim that Palm’s usage of Apple’s Vendor ID in the Pre violates its policy. Now let’s sit back for a minute, and consider what the USB-IF actually is.

The Implementer’s Forum, as it is know, is made up from various companies that helped develop the USB standard and its newer, faster derivatives. The USB-IF acts as a central clearinghouse that provides USB vendor IDs to manufacturers who wish to use USB ports in their products. Every vendor using USB is supposed to register on this forum and pay its fees, which then gives them the right to use the USB logo on their products, and an individual vendor ID, which combined with a product ID, identifies every device on a USB bus.

In theory, this is sweet and dandy, but in the real world, shit happens. Anyone who has played with hardware peripherals long enough will have seen at least once a device identified by Windows as something else – this happens when a vendor “clones” another vendor’s ID. Some can get away with using the other vendor’s ID and a random product ID, combined with a customized driver on CD. In fact, there are tons of products shipping today which bear the USB logo without paying any duties to the USB-IF, and thus, running with “pirated” IDs.

The only power the USB-IF has is self-regulation. If you want to bear their logo, you need to pay their royalty, and agree to abide to its policies, including non-cloning of vendor IDs. So let’s say Palm gets booted off the USB-IF. They just need to remove the USB logo from their product (if they bear it at all – check your iPhone as an example), and they’re home free. They are free to use Apple’s vendor ID as much as they want, and there is no legal recourse Apple or the USB-IF has. With so much legal power, don’t you think Apple would have sued Palm already if there were grounds for legal action? Rather, they engaged in a technical cat-and-mouse game involving iTunes updates to kill off the attacker.

Personally, I think Palm is in delusion. Making the Pre compatible with iTunes will not make it any more popular that it already is not. And Apple has every right to place technical blocks on the Pre, particularly if they miss-represent the vendor ID. Still, if I was Apple, I would have just ignored the issue. The Pre is not a threat to the iPhone, which is far superior in all aspects (apart from the non-removable battery).

It’s unreal – every single multiple-input dedicated DVR I am looking at for taking care of recording my home’s CCTV setup, only supports Windows. When network access is provider, it invariably involves loading an ActiveX control, which of course is not supported in OS X. Even more ridiculously, manufacturers such as AverDigi, a branch of AverMedia, claim to run “embedded Linux” as some sort of badge of honor!

Let me get this straight – you use embedded Linux so that you can serve Windows-only ActiveX-infested web interfaces? Far worse, many of them use weird codecs that come in their Windows-only install CDs, which means that you’ll have to go back to a Windows machine or a VM in order to use these things. Mobile support of course isn’t much better, with Windows Mobile devices supported, again, via ActiveX, and Symbian via Java applets.

I’ll keep searching, but my hopes are fading…

It was all due to a clogged up heat sink in the ATI X1900 card that sits inside my Mac Pro – since the idle fan was not pulling in an airflow, it slowly wound up to full speed, until it was full-on all the time. The build-up of dust was quickly cleared by a blast of compressed air…but this brought about an idea – why don’t idle video cards reverse the fan for a few seconds, say once a day, in order to blow back any dust build-up? This way, the heat sink radiator would be kept clean and efficient.

I had been an avid user of Camtasia for Windows until 2006, when I switched to Mac, so I was pleasantly surprised when I read a TUAW post announcing that Techsmith were porting it to OS X. It has been a long-missed app on the Mac, with other contenders available, such as ScreenFlow, not as powerful.

Now, once Camtasia has been released, it looks like ScreenFlow doesn’t have much to fear – the Mac version is severely crippled compared to the Windows equivalent, by the looks of the comparison table available. These are some of the important features they left out:

• Only full-screen recording, you cannot record only a region of the screen – duh!
• Recording cannot be paused.
• No audio-only tracks, ScreenDraw, or markers.
• No captions.
• No audio enhancements or replace a portion of the audio track with silence.
• No production preview or batch production.
• No customization whatsoever of the Flash player controls, the start and end screens, or the about box.

This may seem offset by features like upload to YouTube or iTunes, but these are bland features as they both only take a couple of extra steps to do manually. Frankly, I will stick with ScreenFlow for the foreseeable future.