Year: 2007

  • Back to Basics: Jumping Bluetooth Com Ports

    One of the two RAM DIMM sticks in my main PC went bad last week. So, I had to unplug the cables from the back, take the case cover off, replace the bad DIMM (lucky to have guessed on the first try which of the two DIMMs was bad), replace the cover, and plug all the cables back in. Simple, right? One would think so. But, not really.

    My Bluetooth USB dongle is on a USB hub. When I plugged the hub and other USB cables back in, I didn’t plug them back in to the same USB ports they were in before I took the PC’s case cover off. After I turned on the now repaired PC, I tried to Sync my Windows Mobile smartphone over Bluetooth. Didn’t work. When, I checked ActiveSync, it showed grayed out options. A bit of digging around revealed that the pseudo COM port Windows XP assigned to the Bluetooth dongle had jumped from COM4 to COM6. A bit of fiddling around fixed this and got things working as expected.

    So, if you need to pull cables from your PC, be sure to note which physical port the Bluetooth dongle is assigned to. FYI: This is an issue for the USB sync cable too. Although it does not suffer from the jumping pseudo COM port issue, Windows will not recognize your Windows Mobile device hardware and will have to re-recognize it. This should not require any intervention on your part. But, it does take a bit of time and may be anxiety causing the first time you see this. This has been like this for years. So, I don’t expect it to change anything soon.

  • Mailbag Q&A/Back to Basics: ActiveSync and Bluetooth

    Having used Windows Mobile devices since 1997 when the Handheld PCs running Windows CE (still the core engine underneath the Windows Mobile shell) had been out for just a few months, I sometimes forget that things that seem obvious to Windows Mobile enthusiasts may not be obvious to other people. So, I’ll pontificate 🙂 talk about some real basic type topics here now and then to try to help people who haven’t spent the past decade playing with these things.

    Back in May I posted a short video to YouTube titled T-Mobile Dash WM6 Bluetooth ActiveSync demonstrating syncing with my PC using BT. I received an email from viewer ZTT asking:

    hello, so on active sync you just have to turn bluetooth on and how does it connect to the computer? does the computer have to be bluetooth??

    Oy! Good question. Microsoft ActiveSync and Bluetooth (BT) are two of the most problematic basic tech items I know of. They shouldn’t be. But, they are.

    First, yes, your desktop or notebook computer must have a Bluetooth radio in order to sync with a Windows Mobile device over Bluetooth. Unlike Apple Macs (which all have BT these days), very few desktop and notebook Windows PCs come with an intergrated Bluetooth radio. Some notebooks have the option have adding an integrated BT radio at the time of purchase. If your Windows PC does not have BT, BT dongles are fairly inexpensive these days.

    You need to partner your Windows Mobile device with the PC using a USB cable the first time. If all goes well, you should be able to configure ActiveSync and the WiMo device to sync over BT. I have an earlier blog entry that details this process. It can be found at…

    Tips for ActiveSync With Bluetooth

  • New Windows Mobile Site: The Wow Stops Now?

    Microsoft launched a new Windows Mobile site that apparently has the slogan Start Doing More.

    Microsoft Windows Mobile 6 Start Doing More

    However, this heavily flash-based site seems to be about less instead of more. The initial page with its three tiny thematic buttons sitting in the middle of the screen looks lonely on the nausea inducing full motion video sitting in back of it. Clicking a button results in another long Flash site load that takes a long long time even on a broadband connection. This is not a sticky site design and offers little useful information. All flash, no substance.

  • Google Mobile Phone: T-Mobile or Verizon Wireless?

    RCR Wireless News reports that T-Mobile may be the US carrier that launches the Google mobile phone.  Information Week reports that Verizon Wireless may be the lucky carrier. If Google uses Apple’s one carrier strategy for a mobile rollout, VZW seems like the more likely candidate since it has a much larger presence than the far smaller T-Mobile USA.

    My guess, ok wishful thinking, is that Google has more clout than Apple (though that may be hard to believe) and is able to avoid the whole exclusive carrier agreement and roll out both a CDMA (VZW) and a GSM (T-Mobile) solution. VZW would give it the US footprint to compete effectively with the Apple/AT&T Wireless iPhone product. The T-Mobile GSM solution would give it worldwide roaming. The combined rollout would also have a larger customer population than AT&T Wireless.

    I guess we’ll see how things shake out in the next couple of weeks if we believe the various reports and rumors published in the past few weeks.

  • T-Mobile Shadow: Here Come the Custom Interfaces

    The T-Mobile Shadow has been generating a lot of interest (not as much as the iPhone did, but quite a lot in the scheme of things). Like most HTC designs, the slide-out keyboard design for a Windows Mobile 6 smartphone (Standard Edition) looks good. The odd thing (to me anyway) is that the Shadow is being marketed as a cool hip lifestyle music playing phone.

    The issue is that Windows Mobile 6 is not designed for cool hip consumers. It is designed for uncool, unhip enterprises with Microsoft Exchange Server (which actually does some cool stuff with Windows Mobile but not in the sense of young people cool). Does putting an easier to use Today screen really make that much of a difference? Probably not IMHO. And, unless some significant enhancement was done to Windows Media Player for Windows Mobile, it does not have a good non-techie end-user story to tell as a media player.

    The Shadow looks like a good solid Windows Mobile 6 smartphone. Its lack of a QWERTY keyboard probably takes it out of the e-mail focused crowd. It will be interesting to see which market segment actually gravitates towards these green and brown (brown?) phones.

  • Mailbag Q&A: Using a Mobile Phone for Heart Attack Care

    Reader D.S. has an interesting question. I usually post interesting questions because I think the question and my response might be of general interest. This time, however, I’m posting it because I think the question needs a better response than I can provide. D.S. asks…

    We are in the midst of setting up a system to improve the care for patients who are suffering a heart attack in the city and county of […]

    One significant issue is how to to allow the cardiologist to see the electrocardiogram. This is important for the cardiologist to make a decision as to whether an emergent cardiac catheterization should take place.

    Obviously if it is during business hours or if the cardiologist is at home and has a fax machine, this is not as much of an issue.

    However, we need to address the possibility that the cardiologist on call is out and about. Hence the question about how a cardiologist might be able to view the electrocardiogram in the field.

    One thought is for the cardiologists to have mobile devices. In my research of the topic, there do appear to be ways for a fax of the electrocardiogram to be sent to a mobile device. However, the worry is that there is still a delay, especially with a fax to email solution. In acute heart attack care, seconds and minutes count, so the image would need to be available in real time.

    In your experience, what would you recommend as a way to get an image of the electrocardiogram to the cardiologist. Some way for the emergency room to send a fax of the electrocardiogram to the phone? Could it be send via MMS messenging?

    First, here’s a caveat/disclaimer: My response here should not be considered as advice, recommendation, or consultation. It is merely a response to an interesting question. (Sorry for the weasel words :-).

    Couple of thoughts…

    1. First, before starting on the technical aspects of the project, be sure to consult with an authority in the Health Insurance Portability and Accountability Act (HIPAA). You may need to encrypt the electrocardiogram image for transmission.

    2. As you point out both SMS and email are subject to potential delays. And, sending images may be problematic depending on how email is configured, the storage capacity of the receiver’s mail server, and other factors. It may be worth investigating the possibility of keeping multiple resolutions of individual images (low, medium, high) on the server and sending alerts to the cardiologist via simultaneous multiple channels: E.g., automated voice call, SMS, email. This message would point the receiver to a password protected site where the image could be called up on a mobile device for viewing.

    3. Don’t rule out the possibility of an old-style client-server application where coded alphanumeric data is sent from the server to the client (mobile device) instead of a graphic image. An electrocardiogram image could be rebuilt from this smaller coded data. This could greatly reduce the amount of data that is sent compared to an image file and thus speed up the process of receiving and viewing the electrocardiogram image.

    Here are links to two mobile technology sites that may provide more information than I can provide.

    MedicalPocketPC.com

    Smartphone & Pocket PC Magazine has an M.D. as a regular contributing author

    Finally, if anyone has other information links that might be useful to D.S., please post it in a comment to this blog entry.