The final(?) word on the QuickPhones phone.

It has been a while, but a few weeks ago I go another update from the QuickPhones guys about the multiple AP issue that I ran in to. I was extremely disappointed to hear that they were unable to find a fix for the multiple AP issue, and have given up trying.

So, what can I say? I will still tell you that this phone has the best battery life of any of the lower priced wifi phones out there. (I have not had a chance to try the more expensive ones. Feel free to contact me if you want to send me one!) When I didn't have it associated to a network, and just sitting on my desk the battery lasted about a month. When connected to an AP, the battery lasted about a week.

Now, just to be clear, it is possible that this phone would work perfectly on wireless gear that "pretends" to be a single huge AP. The one that comes to mind is Meru networks. I have some Meru gear that I am going to install, and will post a follow-up on this phone once I get it installed.

I have, however, discovered a bit of a workaround to the multi-AP issue. If you happen to have a single AP around that can broadcast another SSID, you can still use the phone in an area with multiple APs on one SSID. To do this, you need to shut down all of the APs that are broadcasting the same SSID so that the phone can pick up the AP that is single.

That didn't make a lot of sense, so let me expand on it. Lets say you have 5 "brand X" APs, all broadcasting an SSID called "CorporateFoo". While those APs are all broadcasting the SSID, the phone will be unable to consistently see any SSIDs around you. So, to get the phone working, you need to run to your local electronics store and purchase an inexpensive "brand Y" AP. Set that AP up and name it something like "IWishQuickPhonesWorkedOnMultiAPNets". (yes, I know that is too long for an SSID.. work with me here.) Now, shut down all of the APs that are broadcasting the "CorporateFoo" SSID, and reboot your QuickPhone. When the phone comes back up, it should be able to see your single AP that is broadcasting the "IWishQuickPhonesWorkedOnMultiAPNets" SSID. Configure the phone to use this SSID, make sure it connects and can talk to your SIP server. Once you verify it is working, you can turn your other APs back on. Now that you have the configuration set in the phone, it should always talk to the single AP. When it is powered on, it might take a while to find the AP, but it should eventually connect to it.

So, in a nutshell, if battery life is king for you, and you either only have a single AP, or don't mind jumping through hoops to get your phone working, the QuickPhone is what you want. If having a phone off the charger and on standby for more than 24 hours isn't important, then I recommend the UniData phone I reviewed a few months ago. It is a solid phone that has been working perfectly in my environment.

Xfce and Ubuntu

The title may be a bit misleading. It is likely that this is really an Xfce issue only.

When I upgraded my Revo from Gentoo to Mythbuntu I ended up with a situation where the font size was significantly larger than it should have been. Okay, perhaps "significantly larger" would be an understatement. The clock on the menu bar was so large, I could only see the bottom lines for the numbers!

Googling around found that the issue was with Xfce trying to determine the best font size by using the DPI values from X. X, in turn, got the DPI information out of the EDID information from the monitor. I am sure in most cases this works just fine, but when you bring a cheap LCD flat panel TV in to the equation along with an ION graphics card, the results are less than stellar.

After searching many web pages looking for the answer, I finally found it in the first place I SHOULD have looked. (Yeah, I can admit when I was being stupid.) If you hop over to the MythTV Wiki at http://www.mythtv.org/wiki/Specifying_DPI_for_NVIDIA_Cards you can find the "magical" answer to the problem.

Specifically, you need to add the following options to the "Monitor" section :

Option "UseEdidDpi" "FALSE"
Option "DPI" "100 x 100"


After this, everything started to look reasonable on my screen again!

Of Acer Aspire Revo and Ubuntu 10.04 LTS

I have been running one of my Myth frontends on an Acer Aspire Revo for a while now. When I first got it, I loaded it up with Gentoo, which was my favorite distro at the time. Since then, I have set up several other frontends using Mythbuntu, all of which speak to my backend still running on Gentoo.

Since all of my frontends except one were running Mythbuntu, I decided to do myself a favor, and convert the last one to Mythbuntu as I upgraded toward the final 0.23 release of Myth. It seemed like it would be a pretty straight forward thing to do, but it turns out, it isn't so straight forward.

I managed to get the system to install reasonably pain free. I selected my usual options during install, such as using the proprietary NVidia drivers, instead of the open source ones. (Mainly because I need VDPAU, or else these low power machines won't be able to keep up.) Following the final reboot, I saw some text on the screen about a failure to load something related to the NForce chipset, quickly followed by a blank screen. But, not just any blank screen, the blank screen my TV gives when there is either no signal, or an invalid signal on the input.

Needless to say, this was annoying. After running some nmap to chase down the DHCP address given to this machine, I was able to log in. While looking through a "ps xaf" output, I noticed that there was a process called "zenity" running, that seemed to be trying to display an error message about Ubuntu running in low graphics mode. Googling around found that this usually happens when the driver installed is incorrect, or improperly configured.

A quick "lsmod" showed that the expected nvidia kernel module wasn't running! At this point, it seemed pretty clear why the configuration didn't work! Looking through the available apt packages, I couldn't locate the proprietary nvidia drivers. (Or, at least they weren't where I expected them to be.)

A bit more Googling around came across this web site : http://www.ubuntugeek.com/howto-install-nvidia-drivers-manually-on-ubuntu-10-04-lucid-lynx.html

So, what does it all mean? Darn good question. I am far from an expert on the subject, but it would seem that the latest version of Ubuntu doesn't have a way to install the NVidia driver without going through the old method of downloading it directly from NVidia, and doing the work yourself.

What I can say, however, is once I followed the instructions from the link above, my machine booted right up in to X, and started working as I would have expected.

Marshal double dereferenced strings in C#

I have been working on some interesting bits and pieces of software that involve the use of C# on Windows Mobile. Specifically, I am using the DMProcessConfigXML() function call to feed an XML provisioning document in to Windows Mobile to change settings on the device.

Today I ran across the need to make full use of the function to query existing settings. To date, I had only pushed data in, I didn't have a need to actually read anything back out.

Where is where it gets fun. The data that is returned is defined as "LPWSTR* ppszwXMLout". Marshaling simple data types in C# isn't terribly hard, but a pointer to a pointer!? Such things are the crazy constructs of a C programmer! After digging around, I found a sample on jaredpar's blog that showed how to marshal a double dereferenced pointer to an integer. I figured getting a string would be similar, except the final step would be to marshal a string, instead of an int. Lucky for me, it really is that simple.

For more on the gory details, I would suggest clicking on the list to jaredpar's blog. He describes the details well, so I won't bother repeating his work. Instead, here is a quick bit of code that shows the difference for dealing with a string instead of an int :

public void queryProxyData()
{
    IntPtr outptr = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(IntPtr)));
    string query = "";

    if (DMProcessConfigXML(query, 1, outptr) == 0)
    {
        // See if we can demarshal that crazy thing!
        IntPtr newPtr = (IntPtr)Marshal.PtrToStructure(outptr, typeof(IntPtr));
        string xmlData = Marshal.PtrToStringUni(newPtr);
        Debug.WriteLine(xmlData);
        Marshal.FreeHGlobal(newPtr);
    }

    Marshal.FreeHGlobal(outptr);
}

Pretty simple, huh? I can safely say this is a much better solution that a previous one that I found!

Well, isn't this QT... (Building 64-bit binaries on Windows 32-bit)

For a project that I work on, we have a 32-bit build "server" running on Windows XP Professional. We are starting to expand this project to support 64-bit systems. No problem, right? Visual Studio has cross-compilers for x64 machines. So, we can still use our 32-bit system to build 64-bit binaries.

Umm.. Sure... Something like that.. I spent a rather long weekend trying to figure out how to do this very thing. The problem that I ran in to is the UI for the project uses the QT libraries.

I started off trying to build the x64 QT libraries using the x64 compilers on a Windows XP development machine. I didn't get very far in the process before I hit a dead end. The build would bail out when it attempted to run qmake.exe. After beating my head on it for a bit, I realized that the build system that QT uses expects to compile tools like qmake, and then execute them to complete the rest of its build process. So, the build process would build qmake for the x64 architecture, then attempt to run it, which obviously wouldn't work. (Remember, I was on a 32 bit system.)

I suspect that someone that wanted to badly enough could work around this with various types of trickery. But, I happened to have an x64 machine kicking around my house, so I just built it on that machine, and then decided to try to move it to the 32-bit build system. The x64 build went smoothly when it was done on an x64 machine. (Imagine that!)

Of course, once I moved my shiny new x64 libraries over to the Windows XP build machine, nothing worked. It didn't work because all of the .exe files that were used to handle the QT magic were 64 bit binaries! So, to get things working, I had to find a way around it.

Since the tools that are used in compiling QT programs basically take some type of data (usually XML) and translate it to code that can be compiled. The code that is generated is nothing more than a text file that is then fed in to a compiler. So, it seemed that I might be able to replace some of the .exe files that QT was attempting to call, and end up with something that worked, even if it was something the QT guys would turn up their noses at.

My first attempt was to copy all of the .exe files from the /bin/ directory of a 32-bit install over the .exe files in the /bin/ directory of the 64-bit install. After doing this, I kicked off a build and waited to see what blew up so I could figure out how to fix it. To my surprise, the project built without complaining.

I figured it couldn't POSSIBLY be THAT easy. But, it looks like it is. The binary that was built seems to work on x64 versions of Windows when cross-compiled from a 32-bit version of Windows.

Hands on with the Unidata WPU7700 (and a Quickphones update)

First, two quick updates on the Quickphones QA-342. First, the battery on that phone finally died. The available information on the expected life of the battery seems to vary a bit depending on which site you are looking at. The site I purchased the phone from claims it should last 7 days. The Quickphones release notes claim 70 hours. Based on this, I figured if I got 70 hours out of it, I would call the battery life a success. After three days, the phone still showed 50% of the battery available. After 9 days, it was finally dead. To put some quick perspective on the battery life. This isn't a situation where I just put the phone on the desk and waited for it to die. I actually used it during that week. I probably spent 30-45 minutes talking on the phone. (Which, while not a lot of time, should have at least a small impact on the battery life of the phone.) So, the verdict on battery life for the Quickphones is an overwhelming two thumbs up.

Second, I heard back from the Quickphones guys. They said they are looking in to the multiple AP issue. If they could get this fixed, I would be sold on these phones for day to day use. As I mentioned in a previous post, the voice quality isn't great, and the shape of the phone could use some work. But, both of those things aren't annoying enough to keep me from using the phone.


However, while I was getting no response from Quickphones, I decided to pick up a Unidata WPU7700. From what I could tell, this phone offered the next best battery life in a Wifi phone.

The phone itself is built well, and feels pretty hefty. Not that I would recommend dropping it, but it does feel like it could take a drop or two. (Assuming the screen didn't break, of course.)

Out of the box, each button press resulted in a beeping noise. This was extremely irritating. Fortunately, hitting the menu button, and switching to the "sounds" menu, I was able to shut that off. This made the phone a lot more pleasant to use.

This phone quickly connected to my WPA2-PSK network. And, after figuring out how the text input worked, I was able to quickly get it signed on as an extension on my Asterisk box. So, I got on quickly to the first test I wanted to run. The battery life test.

I let the phone get a full charge, and then unplugged it from power and left it sitting on the desk. About 21 hours later, the phone was beeping and complaining it was low on power. This was shocking, to say the least. This phone was supposed to have 40 hours of stand-by battery time.

While configuring it, I had turned on the internal web server. So, I wondered if that was keeping the phone more awake that it needed to be. I shut it off, and charged the phone back up completely, and left it sitting on the desk again. About 21 hours later, the phone was again beeping and complaining that it was low on power.

Since I don't see any more options for adjusting the power savings on the phone, I have to conclude that the battery life on this phone is nowhere near what the manufacturer claims. (And down right pitiful compared to the Quickphones!)

As for the sound quality of this phone, it was quite good. It is on par with any cordless analog phone you would find.

One of the more interesting things about this phone is all of the crazy features it has. It has a small web browser built in, some text messaging functionality, a calculator, and a bunch of other little applets. For many, or perhaps most, of the applets, I can't see a point to them. It is functionality that exists on other pieces of equipment that exist in a normal business or even a house. The one feature the Unidata phone has that is great, is the ability to do 802.1X. (Or, WPA(2)-Enterprise, if you want to call it by that name.) I didn't test the functionality, since I have not had time. But, for businesses that care about security, this would be a major win.

QuickPhones follow up....

Well, it has been a bit over a week with the QuickPhones QA-342. So, I thought I would follow up with my view on the hardware so far.

So far, I have not had time to dig in to the multiple AP problem any farther than I had during the last post. But, to get the phone working, I set up a NetGear AP with a different SSID. After doing that, the phone has been reasonably stable.

One of the key things that interested me in this phone was the battery life. So, I let it charge over the weekend that I got it, and have left it powered on, our of the cradle for the last 7 days. Looking at the phone just now, it shows the battery is at 75%. As a result, this phone certainly meets my needs for battery life!

I REALLY wish I could say that the rest of the phone meets my needs. Since I started using it, I have come up with a pretty hefty list of complaints about the phone. Obviously, the first one is with the multi-AP support.

I cut the QuickPhones guys a lot of slack initially about this. Mostly because they were so responsive about getting me access to the 4.0 firmware. It seemed like they were a solid company that really wanted to make a top-notch product. In the last week, my opinion has changed. Early last week, I e-mailed my list of issues to their support people, and included information about my credentials for wireless and offered to help them in debugging the issues. That e-mail seems to have fallen on deaf ears. Later in the week, I pinged them again to verify that they had gotten my first e-mail. Again, I got no response.

Now, let me go off on a bit of a side rant here. I did something in my e-mail to support that I rarely do. I gave them information about my credentials as a wireless networking professional, and wireless network software developer. I generally don't do this because I have been in too many big box electronics stores where the sales people claim to be experts on a topic by nature of working for that store. I don't want to come off sounding like those people. That said, I did include that information in my e-mail to their support people. The main reason being that I liked the build of the phone and wanted to help them get the issues hammered out so I could purchase more of them.

Which leads me back to the additional issues I have seen. The sound quality on the phone is sub-par. There was a lot of static in the background when I was talking to someone. This wasn't comfort noise type static, this was pops and clicks as if packets were being lost in transit. Since it is wireless, and running at 2.4Ghz, I can understand a little bit of that. But, when I compare it to my older D-Link phone the sound quality is night and day. The D-Link was crystal clear, the QuickPhones was less than ideal.

The other sound quality issue I had is with the volume. I will be the first one to admit that I have been to too many loud concerts, and played my stereo louder than I should. So, I don't have the best hearing in the world. So, I usually like to have my phones turned up fairly loud so I can hear everything clearly. When the QuickPhones was to quiet, I tried to use the volume buttons on the side of the phone to increase the in-call volume. From what I could tell, the volume buttons didn't do anything. Again, I have not had time to play with the phone enough to determine if the volume is all the way up, or if the buttons just don't work how I would expect. But, the sound really isn't good.

Which leads me to the next sound related issue. The front of the phone is curved. If the sound on the phone was better, I suspect I wouldn't have noticed this. But, since I was straining to hear the sound, I noticed the curvature of the phone kept it from feeling like it fit nicely against my ear. While this seems like a nit, keep in mind that the vast majority of phones out there are flat. I have to believe there is a reason for that.

So, what comes next? Well, I am supposed to take delivery of a Unidata WPU7700 phone today. It should be interesting to see how it stacks up to the D-Link and the QuickPhones. I also took delivery of an OpenVox A400E board about an hour ago. So, I expect to blog a bit more about the installation an effort involved in getting those running.