We touched on the Veer when it first hit our doorstep with a this just in post, and since then I’ve been using the device daily and trying to get an understanding for where it fits in both HP’s vision for WebOS and the greater scheme of things among all smartphones. The Veer’s launch is quite honestly a puzzling one.  Usually launches are top down - launch the big flagship first, then reduced size and price ‘lite’ editions afterward that build off the flagship’s success and appeal to niches that aren’t served by the primary device either due to cost or size. For that reason, the Veer launch initially seemed a bit backwards, but factor in HP’s desire to get excitement for WebOS 2.0 started and ignite interest for the Pre 3, and things begin to make sense. 

Size Comparison: (Left to Right) HTC EVO 4G (Sprint), Palm Pre Plus (AT&T), HP Veer 4G (AT&T)

The HP Veer 4G (henceforth just Veer) is the Palm Pixi’s obvious spiritual successor. It’s refreshed with a faster SoC, better camera (but without an LED flash), WiFi, WebOS 2.0, and repackaged in a different, smaller form factor. The two bear the same exact same screen size and resolution (2.6 inch, 320x400), and both include a keyboard in a diminutive package. One of the Palm Pre’s original differentiators was the inclusion of a keyboard, and thus far every WebOS device has likewise included one. For extremely small devices, hiding a keyboard somewhere isn’t exactly an easy task.

Left: Palm Pixi, Right: HP Veer 4G

The Pixi included one by sticking it beneath the display, resulting in a long and skinny phone that ended up having a funny aspect ratio. The Veer, however, keeps a much more Palm Pre - like form factor with sliding keyboard. 

If the Palm Pre full size devices could be described as feeling like smooth river rocks in the hand, the Veer is more of a pebble. It truly feels like a scaled down Palm Pre. It’s small - no, that doesn’t even do it justice. It’s downright tiny. 

The Veer has an outline just smaller than that of a credit card, and hides a four-row QWERTY keyboard away in the slider and only tacks on 4.25 mm of thickness and 10.5 grams in the process compared to the Pixi. 

While the overwhelming trend right now is ever increasing display size, it’s obvious that HP recognizes an unfilled niche on the other side of the spectrum for something incredibly small. There’s definitely a market for devices with pocketable size that don’t “print” with tight fitting clothing. I’m told by my female friends that having a small device that fits those criteria is a big part of smartphone shopping. That said, the Veer is still thicker than a bunch of other phones, which is perhaps an even more important criteria for female shoppers.

Whether the Veer goes in the front pocket or is small enough to make it into the back pocket is ultimately a matter of clothing choice and personal preference. I will say that it’s refreshing to carry something around that doesn’t weigh my pants down, though at times it’s easy to forget there’s anything in there at all when checking to make sure you’ve got keys, wallet, and phone.

The only downside of the Veer is that it’s clear HPalm had to make a few design tradeoffs to make such a small device. It’s pretty easy to illustrate the tradeoffs by just looking at all four sides of the Veer.

The Veer sticks to pretty much the same button placement as the Palm Pre. On the left side is the volume rocker, which is one continuous chrome button. Volume up and down are slightly mushy but nothing to complain about. 

Up at the very top is a small port for a lanyard, and inside there is the port for dual-microphone noise cancellation in calls. To the right of that is a small black strip, even on the white colored Veer.

This strip is the SIM card slot cover, and pries off with a thumbnail. The SIM is held in place with a standard click-in, click-out mechanism that gets the job done. To the right of that is the vibrate and silence switch, and lastly the power button which straddles the right side. 

Where things get unique is on the right side of the Veer. If you’ve been paying attention, you’ll notice that absent from the Veer is a microUSB or 3.5mm headphone jack.

The Veer instead uses a proprietary magsafe-like connector with five pins for supplying both audio out and USB. There are two ferromagnetic metal pieces on either side which mate up with permanent magnets on the supplied USB cable and 3.5mm headphone jack adapter.

The result is that the Veer itself thankfully isn’t magnetic (and thus does not attract metallic particles, keys, and the like when in the pocket), but the cable and headphone jack both do. 

Both connectors don’t interfere with the slide open mechanism, and the USB cable doesn’t interfere with comfortable typing. It’s obvious to me that the port was positioned as far up on the Veer as possible and not dead center so that there’s as little interference with holding the phone and typing when either accessory is connected. 

The downside of this tradeoff is that to charge the Veer, you need to bring the cable along. Honestly, I’d prefer a microUSB adapter that lets people use existing hoards of microUSB cables, car chargers, and AC adapters over a cable. Further, in European markets where microUSB is a standard, it seems that such a dongle will have to be supplied, likely in conjunction to the entire cable assembly. 

The Veer also uses the same proprietary port to supply its 3.5mm headphone jack. This is accomplished with the use of a small dongle that likewise magnetically attaches to the side of the Veer. 

The 3.5mm headphone jack works fine, though the dongle’s size is slightly larger than the USB connector - it’s slightly thicker to accommodate the whole port. The connector is also a bit stiff, and as a result plugging and unplugging headphones the first couple of times is best accomplished by taking the dongle off and removing rather than inserting and ejecting while mated to the Veer. I did manage to break the detachable cable I was using in my Sony MDR-NC50 headsets, but that's more a function of the fact that the cable was loose and very close to death. Just be warned, the Veer's headphone jack is stiffer than most.

To be completely honest, the headphone jack adapter probably will be the thing most Veer owners lose first in part due to its very small size. If you’re going to get a Veer and are keen on listening to lots of music with it, you’re probably better served by purchasing a pair of bluetooth headsets with A2DP and AVRCP support. The adapter is nice to have but ultimately something that increases the size of the Veer when attached and is just one more thing to carry around. Obviously you can’t charge the Veer when the headset adapter is connected either, unless you use a touchstone charger. 

So what about the device itself? Build quality on the Veer is very good, it’s obvious to me at least that HPalm now has learned how to make a device with slide-out keyboard that doesn’t have any “Oreo effect” like that which plagued the original Palm Pres. The slider is completely solid and has virtually none of the aforementioned flex in any direction. It decisively slides open and closed with a firm spring assisted mechanism that nice controlled friction. It feels precise and crisp sliding open and shut. As a result, it’s easy to flip the Veer open with one hand and proper thumb placement on the display lip or center surface.

One of the problems I had with the Palm Pre Plus (and before it, the Palm Pre) was that when sliding the phone open quickly, the screen would exhibit obvious LCD distortion from pressure at the corners. This was extremely unnerving, and no doubt leads to excessive fatigue and premature display failure. None of that happens on the Veer, which is another plus. I can’t find any fault with the slider mechanism at all, which gives me hope for the Pre 3’s slider being equally awesome and sturdy.

HP Veer's internal battery - Photo Licensed with Permission from WebOS Internals Veer Disassembly

To preserve its small size, the Veer’s battery is internal and not user replaceable, and it’s on the small side as well, at just 910 mAh, or 3.4 Whr. This is reasonably comparable to the Pixi’s 1150 mAh battery, but still just short. There’s no obvious way to take the Veer apart, as the backside is one solid piece of plastic, and there are no visible screw holes or plastic snap tabs. That’s another tradeoff - you get an extremely small device with excellent build quality, but lose the ability to remove the back case and do replace the battery. I think for this form factor the tradeoff is a valid one. As we’ll show shortly, battery life really is surprisingly good on the Veer. 

On the backside at the top left are the camera and speakerphone grille. Likewise, gone is the Palm branding, in its stead is the HP logo and beneath it AT&T. I find it a bit depressing that the Palm brand is now nowhere to be found (even the boot logo is a glowing HP logo), but that’s entirely HP’s perogative.

You might be wondering where the FCC and regulatory iconography went, since there’s no longer a battery door to hide it under. 

Slide the Veer open and the answer presents itself. The serial, part number, IMEI and FCC ID are all laser etched into the mirrored back surface of the display assembly. Palm has been consistent about preserving this back mirrored surface on the slider, which does some double duty for framing self portraits (not MySpace angle shots). 

The front of the Veer is one continuous glass surface, the bottom area retains capacitive touch detection for WebOS’ gesture area. More on the display in a moment. Up at the top is the Veer’s tiny chicklet-like headphone grille. I’m reminded of the Nokia N900’s similarly tiny speaker grille when I look at the Veer’s. I always had a tough time aligning my head with the N900 speaker since the area was so small, but by virtue of the Veer itself being small, it’s much easier to center the Veer up with the auditory canal than the N900. Despite being small, earpiece volume and quality doesn’t take a hit either. 

So I think it’s time to finally talk about the Veer’s small size and about how that actually works in practice. It’s an incredibly tiny phone, and Zoolander jokes aside, can indeed feel considerably awkward to hold if you’re coming straight from one of innumerable substantially larger phones. The first couple of calls I made on the Veer were slightly challenging because of the phone’s minuscule size. 

First up is how the Veer looks side by side with some other devices. The most obvious comparison is the Palm Pixi. The Veer is unfortunately a bit thicker to accommodate the slide out keyboard system, but preserves the same width and also is a fair bit shorter. 

Next is how the Veer compares to the Palm Pre Plus and HTC EVO. Here you can get an appreciation for just how small the phone is compared to a growing list of comparatively gargantuan >4” display phones. 

I also got an opportunity to take photos of the Veer next to the Pre 3 and a black Veer.

The difference in aspect ratio between the Veer and the Pre 3 is pretty dramatic, which does make me worried that developing good applications that work well on the Pre 3 and Veer using the same binary could be challenging. 

Already there are Pixi-specific versions of some applications in the WebOS store, and the difference between the Pre aspect ratio and Pixi isn’t all that great. The difference between Veer and Pre 3 will likely cause even more of this, especially for games. For example, there’s currently a Pixi specific version of Angry Birds that works fine on the Veer as well. 

 

With the keyboard slider closed, it’s understandably a bit unnerving to hold the Veer to one’s head. There’s an impulse to want to have all five fingers on the phone, when realistically your pinky will hang off, otherwise the grip is fatiguing. In reality, that’s not a big problem since the pinky doesn’t add much grip strength at all - the problem is that it hangs out awkwardly, and as a result holding the phone to one’s head is like drinking tea in polite British style. 

The solution to this is actually pretty simple, with the keyboard slid out, the Veer is much easier to hold with a normal five finger grip. In addition, since microphone is located right next to the symbol key, there’s a chance you’ll get better voice quality this way. I tested with the phone open and closed and couldn’t detect any appreciable difference, so it’s clear that it’s intended to be used in either state, but all bets are off when talking outside in the wind. 

In the palm when in regular use the Veer is also a little bit awkward to hold, but only for the first couple of hours. After that there’s nothing challenging about holding the phone with the slider closed and doing anything normal. With the slider open, it’s easier to get a good perch and firm hold on the phone. 

 

That’s a nice segue into how typing on the Veer goes. It’s surprisingly easy to peck out SMSes and emails on the Veer despite its size. I can get both thumbs on the keyboard and type fairly easily, as long as I use my fingernails to press on the key domes rather than the fleshy part of the thumb. 

While errant key-presses are definitely the norm, the situation is mitigated rather well by the inclusion of autocorrect in WebOS 2.0, which works impressively well at most words. It’s called Text Assist in WebOS 2.0. If you type a word incorrectly and have done a decent enough job to get most of the characters right, it’ll autocorrect and get underlined with dashed grey dots. If you’re too far away from a commonly misspelled word, it’ll be underlined in dashed red just like every other word processing program. 

This can then be tapped on revealing a number of correction options, and for the most part it does a decently good job. If you type a word that isn’t in the dictionary, it will likewise be underlined in red (or, annoyingly enough, autocorrected), and then tapping on it will make a pop up with “+” prepended to the word, symbolizing the option to add it to the autocorrect dictionary. 

 

My only complaint about WebOS’ autocorrect implementation is that unlike iOS and Android, there isn’t a fast way to tell the keyboard software that you really did mean to type “pwned” instead of “owned,” and to leave it spelled how the keyboard software thinks is wrong. Sometimes you can get into a tug of war, where successive backspaces correct back to the “misspelled” word you want, but then typing more yields the correction. It’s just unnerving occasionally. 

Where WebOS’ autocorrection beats iOS is that it (thankfully) allows easy entry of words into the autocorrection dictionary without making you encounter it in real use. Instead there’s a menu for both adding user defined words and autocorrection shortcuts. Oddly enough I had to add HSPA, HSPA+, and the Veer’s own name to the dictionary pretty much immediately since they weren’t present by default. HPalm is being way too modest if they’re not including all their product names in the autocorrection corpus - every other smartphone I’ve played with seems to include every one of the manufacturer’s products in its own correction corpus. As an added leg up on the competition, the autocorrection dictionary on the Veer includes the full spectrum of insults and swear words. It won’t correct to these words, but they thankfully aren’t marked as being misspelled.

The next discussion point about the Veer’s keyboard is tactile feel. Honestly the Veer’s keyboard doesn’t feel as good as the Pixi’s, even when my comparison point is a very used loved Palm Pixi. The keys on the Veer are considerably more mushy and accommodating, which is accentuated by both the mushy plastic material used for the domes, and a lethargic click mechanism. The Pixi on the other hand has rigid domes that click much more decisively, and as an end result yields a much more confident typing experience. When it comes to physical keyboards, I think communication is the big issue. Honestly, the Veer’s keyboard feels a lot more like a aspect-scaled Palm Pre keyboard than the Pixi’s keyboard which is laid out in a very rectangular fashion. The keys on the Pixi are also slightly taller than those on the Veer. 

Anand used the word communication in a discussion with me about driving, and it got me thinking about how the same can be said about the haptic experience of typing. Two things need to be communicative on a physical keyboard for it to be great - the first is that the key tops need to be easy to feel for positioning one’s fingers atop the appropriate keys for alignment. The second is that the key dome mechanisms need to click in a way that communicates successful character presses. If either of those things isn’t right, typing on the keyboard will never quite be full-speed. The Veer gets the first one right (the domes are convex, easy to locate, and the F character has a recognizable bump), but only is middling at the second one - there’s just a tad too much travel.

I know I sound like I’m ripping on the Veer’s keyboard, but in practice I didn’t find myself want for more physical area or a larger keyboard, just slightly firmer domes and clicking. The presence of autocorrect in WebOS 2.0 catches about 80% of my typing mistakes when going super fast, which is respectable. That said, if you have large fingers, couldn’t type on the Pixi, or even found the Pre keyboard frustrating, then the Veer is likely going to be less than ideal for you.

The next part of the Veer’s compact size is its smallish display. The only issue with the entire thing is that because of the Veer’s decidedly square display aspect ratio (320x400, 4:5) and overall squarish shape, it seems much more prone to errant rotation than any other smartphone I’ve ever used. There just seems to be a higher than average propensity to either wind up with the display rotated completely upside down (since WebOS honors rotation a full 180 degrees from portrait), or have application launches start out rotated to landscape. It happens with surprising frequency, and since the home screen doesn’t have a landscape orientation, often it catches one entirely by surprise when new cards are launched. This wouldn’t be so bad except there’s also no option to disable auto rotation from the screen and lock settings page. 

 

The Veer’s display is the same LCD TFT we’ve grown accustomed to seeing in WebOS devices, not something fancy like AMOLED, Super AMOLED, or “Super LCD”. I still generally prefer LCD over AMOLED due to color accuracy issues that still aren’t sorted out, and in that department the Veer is actually pretty decent. Out of the box at max brightness, the Veer had a white point of 7057K as measured by an i1 Pro. 

The brightness controls on the Veer are a bit deceptive. The Screen & Lock settings application has a brightness slider with analog control (the slider doesn’t snap to quantized levels), however there’s no auto brightness toggle. What’s confusing is that the Veer actually does have auto brightness, and a decently aggressive auto brightness algorithm at that - but you can’t turn it off. I’m a fan of simplifying things whenever possible, but not totally removing control at the same time. I doubt most users will complain, but for measuring brightness this initially posed a problem for a few seconds.

Measuring brightness and contrast on the Veer required me to carefully shine a white LED into the sensor while masking the rest of the display and i1 Pro off when taking measurements. In that manner, I could measure the Veer’s true maximum brightness, which came to almost exactly 400 nits. With the LED still enabled and shining into the sensor (so auto brightness adjusts to maximum brightness), I measured black point and contrast as well, and the Veer actually does very well.

I still think that the WebOS family of devices could benefit from some AMOLED, if nothing else because the edge of the UI is rounded and black. Remember that with AMOLED displays, black regions are truly black. There’s no backlight, so inside black regions pixels literally aren’t turned on. This would work perfectly for WebOS whose status iconography at the top is white on black with rounded corners, and at the bottom the notifications area is likewise black. These regions that are just painted black on an LCD display always look slightly off when next to the black bezel. 

I didn’t get a chance to measure the brightness and contrast levels on the Pixi for comparison with the Veer, but I fully expect that had I done so the values would be almost exactly the same. The Veer’s display resolution and size are identical to the Pixi’s. 

Outdoor viewing on the phone is what we’re used to seeing for LCD displays, and is quite good thanks to the Veer’s very bright backlight. The Veer also uses a capacitive panel that has small reflective regions that become evident in strong sunlight – another thing I’m used to seeing on some displays. 

The Veer continues the WebOS tradition of having a fixed focus 'enhanced depth of field' camera. The Veer is simultaneously an improvement and step backwards from the Pixi just on paper. The Veer has a 5 MP camera with no LED flash. For comparison, the Palm Pixi has a 2 MP camera with LED flash. 

Both cameras are of the fixed focus sort. The Veer captures still images at 2592 x 1952 with filesizes of just around 2 MB in JPEG format. WebOS continues to take the minimalist approach in the camera application with virtually no toggles other than a link to the gallery, a capture button, and a switch for changing between video capture and stills. For being such a basic camera, the Veer produces some surprisingly decent stills when you're outside in good daylight. Beyond the camera's admittedly close hyperfocal distance, there's good focus and sharpness. 

Indoors or inside that hyperfocal distance, the Veer's camera is very disappointing. You can see that behavior in a few of the gallery shots that aren't part of our test suite but just taken in daily use. In those situations that are low light, at night, or close to the device, the Veer doesn't perform well. That's to be expected however given the camera constraints. 

The camera application on the Veer is far and away the most buggy part of the experience. With geotagging enabled, I suffered a number of constant problems. Sometimes I'd get errors like this:

Other times I'd simply get a complete abrupt reboot of the device, or some very troubling screen corruption followed by a reboot either immediately or a few minutes later. When things were going very badly, the Veer would capture a ton of 0 KB images - lovely. Disabling geotagging fixed the problem entirely - just don't enable it if you want a functioning camera. 

Videos on the Veer are captured at a decidedly last-generation 640 x 480 (VGA), and are encoded with MPEG-4 at a bitrate of exactly 1 Mbps with one AAC audio channel. I'm disappointed that there isn't 720P video capture on the Veer - MSM7230 should be more than capable of doing that instead of low bitrate VGA. 

The nice thing is that for the most part you can still mash the capture button or spacebar endlessly and capture tons of images quickly. This is one thing WebOS still has on everyone else - stupid fast capture with virtually no input lag. The downside is again that WebOS hasn't caught up in the video or camera side of things - everyone else is busy duking it out over 720P and 1080P capture quality, while the Veer putters on with VGA. For those interested, I've uploaded the two video samples taken from the Veer here. 

I'm not going to go into super deep detail about what's changed in WebOS 2.0 because our own Mithun has already done an awesome job going over the differences in much better detail than I could in an earlier piece for AnandTech. 

That said I think it's still important to go over the higher level software changes just for the sake of doing so, and again make some comparisons to the Pixi. Side by side with the Pixi running WebOS 1.0 and the Veer running WebOS 2.0 something immediately stood out. In WebOS 2.0 there now is a "just type..." search logo at the top of the card view screen, and cards are appropriately smaller underneath it. My friend who uses a Pixi daily at first insisted that the Veer's screen was smaller (they're the same size) which was confusing until I realized that the discrepancy in card size when in the card view zom level is rather dramatic. See for yourself:

  
Left: Palm Pixi (WebOS 1.0), Right: HP Veer (WebOS 2.0)

The screen size and resolution between the two is exactly the same, howver the addition of the "Just type..." search bar at the top of the WebOS 2.0 view results in dramatically smaller cards. When it comes to the messaging application and others, this often made the difference in terms of whether text inside the card was readable or not. You can really see just how much smaller the cards are now, and the Veer's very square aspect ratio accentuates the problem. I get the impression this was a feature designed on and for the Pre 3 with a much more rectangular aspect ratio.

The improvements to the "Just type" search system are actually very good, with google suggestions populating the list, prompts to add new search engines whenever they're encountered on webpages, and more local application searching. 

The other major improvement is Flash support in WebOS 2.0. It's enabled out of the box, though by default Flash elements are not preloaded and played, though you can enable this functionality. By default, you get grey boxes with a play symbol where Flash lives.

 

Tap on them, and Flash starts running, and the browser locks its current zoom level and translation so you can interact purely with the Flash element. Tapping on the X in the bottom right corner doesn't stop the Flash plugin, it gives focus back to the browser so you can multitouch translate and zoom around again. This is honestly a superior implementation to Android's unstated hybrid of the two. 

Quite honestly other than the lack of any improvements in boot time (reasons for which we will get into in a few pages), I found that WebOS 2.0 is a decent step forward that's mostly incremental. To be completley honest, WebOS 2.0 feels more like WebOS 1.5 than a big update that really warrants a full version change.  I understand what HPalm is trying to do here though, and for the most part I'm pleased with the changes - there just needs to be even more of them, faster. Android and iOS both are borrowing from WebOS more and more each update. 

In the Touchstone the Veer also goes into exhibition view, even if right now it's essentially just the default display Mithun already showed in his own WebOS 2.0 exploration. I couldn't quickly find any examples of applications that leverage this view, but it's just one of the interesting innovations I feel like WebOS is pushing that it has to capitalize on before others beat it to the punch. 

Last week, Anand and I hopped on the phone with Qualcomm to talk about the finalization of its acquisition of Atheros. As it is right now, Qualcomm SoCs already come with both an application processor, GPS, camera ISP, encode and decode blocks, and the all important cellular baseband. There are one or two other chips that are part of the package as well for power management (in the case of the Veer’s MSM7230, the included PM8058 PMIC), and another for the RF front end and subsystem which can include Bluetooth and FM radio support (in this case possibly the QTR8600). All that’s missing from that list right now is WLAN, and Qualcomm’s long-term strategy is to eventually add it to the solution as well. I’m not sure whether the Veer uses it, but it’s possible that Qualcomm’s WCN1312 is its 802.11 b/g/n solution. 

 

The fruits of having an SoC that includes connectivity are really evident in the Veer, which is both smaller and offers more connectivity than the Pixi it replaces. Recall for a moment that the Pixi included Bluetooth and GPS, but completely lacked any WLAN connectivity options. Space considerations are already a challenge in mobile devices, as having a smaller PCB means more volume that can potentially be allocated to a battery. It’s an even bigger constraint for the smallest of mobile devices. Not having additional die for the baseband, its accompanying NAND, and possibly another power management IC is an appealing space and power savings. Nvidia knows it just as well as Qualcomm, having recently acquired Icera for their cellular baseband IP. Having the same consolidation take place for WLAN would be yet another potential selling point for Qualcomm SoCs. Right now, the far and away most popular WLAN stack is Broadcom’s BCM4329 - it includes 802.11a/b/g/n (5 GHz support comes if you include the RF for it) alongside Bluetooth 3.0 and FM radio support. As an aside, many more mobile devices need to include 5 GHz WiFi support, the 2.4 GHz band is unusable at conferences and incredibly crowded in urban contexts. 

The Veer supports single spatial stream 802.11n (2.4 GHz) with short guard intervals, and thus connects at 72 Mbps. In our throughput test, which consists of a PDF over 100 MB being loaded over WiFi using the Veer’s browser, we saw an average throughput of 22.4 Mbps over WiFi. I’m not entirely certain which WLAN stack is being used in the Veer, but it’s very likely either BCM4329 or Qualcomm’s own WCN1312. Given the size constraints and HPalm’s recent switch to everything Qualcomm, it seems possible that WCN1312 is the chipset of choice. 

I suppose now is as good a time as any to go into the cellular connectivity situation on the Veer. There was some confusion initially about whether the Veer “4G” truly had HSPA+ or not, and a number of incorrect assertions came up surrounding whether HSDPA 21.1 (and thus 64QAM) support is required for a device to be considered actually HSPA+. I went into this in my earlier this just in post when talking about the Veer 4G  and encourage you to read it, but wanted to go in a bit more depth with explanations now. 

Before I go any further, let’s discuss modulation. Modulation is the act of physically encoding data on a signal, or in this case an electromagnetic wave. The simplest example of modulation is On Off Keying (OOK) or Amplitude Shift Keying (ASK). With OOK, you can imagine no light at all being coded to a binary 0, and the presence of light being coded to a binary 1. Then, with the simple act of blocking the light (either with a chopper, or your hand, or by turning the source on or off) you can encode that binary 0 or 1. It turns out that just turning a source on and off (and only using two states) isn’t a very spectrally efficient means of encoding data. But there are other ways of encoding data. Regardless, amplitude is one parameter we can vary.

The next is the frequency of the electromagnetic wave. To explain this we need to first realize that a wave can be described with a cosine. Looking at the equation shows us almost everything we can modify or modulate with respect to the signal, with the exception of one more parameter - polarization. Those three are amplitude, frequency, and phase. Everything inside the cosine’s parameter together serves to describe the wave’s phase angle. Obviously the next possible thing to modulate is this phase angle – we could code a phase of 0 to a binary 0, and phase of π (180 degrees) to a binary 1. This is called Binary Phase Shift Keying (BPSK). You can imagine using more positions along the phase to encode more data – just go up a power of 2 and encode a phase of 0 to binary 00, phase of π/2 to 01, π to 11, and 3/2π to 10. Often this is shifted by π/4, but in either configuration with 4 points you get to Quadrature Phase Shift Keying (QPSK). 

This can be visualized in polar coordinates, where the amplitude is the distance from the origin to a point, and the phase angle is simply the angle from the x-axis to the point. Now the term phase angle makes sense.  A plot very similar to this is called an I/Q plot, with I standing for in-phase, and Q for quadrature (90-degrees out of phase). This is essentially a polar plot, but with the names for the two orthogonal components just labeled I and Q due to their common use in an IQ modulator. 

It doesn’t take much imagination to see how you can modulate amplitude alongside phase and get even more points to encode to binary data. This is called Quadrature Amplitude Modulation (QAM) and essentially is the combination of both ASK and PSK. If you divide the I/Q plot into regions, each can then correspond to some predefined coding. The encoder and decoder share this mapping, and we can transact data based on a specific value of the amplitude and phase angle. 

Things go by powers of two here so we can add one more digit of coding – thus 16QAM lets us code four binary digits, and 64QAM lets us code six. These different codings are simply different higher powers of QAM, and sometimes you’ll just hear them referred to as higher order modulation schemes. All we’re doing is increasing the power of two and dividing the IQ plot into more points. Plotted on the I/Q plot, these points form what’s called a constellation map.

I'm not even going to bother labeling the codings on this one...

There is a tradeoff, however. Moving to more and more decision points results in a densely packed constellation, with correspondingly less space between each point. We can’t get any more area, since we’re encoding between an amplitude of 0 and 1, and phase angle of 0 and 2π. As a result, sensitivity to noise and interference goes up, as tolerances (the area between points) shrinks. On the demodulator, there’s a component called the decision circuit whose job it is to decide what coding each point should correspond to. It does its job simply by looking at where points land and how close they are to a symbol. There are ways of improving the decision circuit, but there’s no getting around the fact that each power of two makes the decision circuit’s job harder. 

 

So how does this all loop back to cellular networks? Well the modulation schemes we’ve described here are what are at play right now in cellular networks. In the beginning of WCDMA, in 3GPP Release 99, the only modulation scheme was QPSK. Later in the HSDPA release-5 standard, 16QAM was added, and finally in release-7, 64QAM was added. That’s all only talking about the downlink from the tower to the handset. That said, the same gradual addition of higher and higher order modulation has taken place on the uplink as well, with the new addition of 16QAM in release-7 to supplement existing QPSK from release-6. User equipment continually reports its own downlink quality measurement to the tower in uplink signaling, and the tower makes its own decision about what modulation scheme to use depending on link quality. When quality is very good, 64QAM gets used, else 16QAM, else QPSK.  

The addition of 64QAM thus makes it possible to achieve much higher data rates, but only close to the cell center where there’s minimal interference or noise, or good Signal to Noise Ratio (SNR). There’s been some drive testing done which shows that in real world environments, 64QAM only gets used around 10% of the time – it isn’t something used a lot of the time by any stretch of the imagination. 

So what’s the confusion here relating to the Veer? It stems from an incorrect assumption about what is and isn’t mandatory in ‘HSPA+’ 3GPP release-7. It is a gross oversimplification of the standard to call HSPA+ merely the previous release with 64QAM added in. The reality is that there are many more things included in release-7, including MIMO user equipment categories that lack 64QAM, numerous layer two enhancements, improved signaling which increases data rate, reduces signaling load, and speeds up state transitions, and the already mentioned changes to upstream modulation (inclusion of 16QAM). Even beyond release-7 is release-8, which adds dual carrier HSDPA, essentially enabling the modem to use two 5 MHz WCDMA downstream channels at the same time, doubling performance. That comes in release-8, and there are categories with all the bells and whistles - MIMO, 64QAM, and/or dual-carrier. I've put together a table with all of the user equipment categories for releases 5 through 7. 

HSDPA User Equipment (UE) Categories, Modulation Scheme, Max Data Rate Table
3GPP Rel.	UE Category	Max number of HS-DSCH codes	Minimum inter-TTI Interval	Maximum Data rate (Mbps)	Modulation Schemes Used	MIMO Y/N
5	1	5	3	1.22	QPSK, 16QAM	N
5	2	5	3	1.22	QPSK, 16QAM	N
5	3	5	2	1.82	QPSK, 16QAM	N
5	4	5	2	1.82	QPSK, 16QAM	N
5	5	5	1	3.65	QPSK, 16QAM	N
5	6	5	1	3.65	QPSK, 16QAM	N
5	7	10	1	7.21	QPSK, 16QAM	N
5	8	10	1	7.21	QPSK, 16QAM	N
5	9	10	1	10.13	QPSK, 16QAM	N
5	10	15	1	13.98	QPSK, 16QAM	N
5	11	15	2	0.91	QPSK	N
5	12	5	1	1.82	QPSK	N
7	13	5	1	17.64	QPSK, 16QAM, 64QAM	N
7	14	15	1	21.1	QPSK, 16QAM, 64QAM	N
7	15	15	1	23.37	QPSK, 16QAM	Y
7	16	15	1	27.95	QPSK, 16QAM	Y
7	17	15 15	1	17.64 23.37	QPSK, 16QAM, 64QAM QPSK, 16QAM	N Y
7	18	15 15	1	21.10 27.95	QPSK, 16QAM, 64QAM QPSK, 16QAM	N Y
8	19	15	1	35.28	QPSK, 16QAM, 64QAM	Y
8	20	15	1	42.20	QPSK, 16QAM, 64QAM	Y
8	21	15	1	23.37	QPSK, 16QAM	N
8	22	15	1	27.95	QPSK, 16QAM	N
8	23	15	1	35.28	QPSK, 16QAM, 64QAM	N
8	24	15	1	42.20	QPSK, 16QAM, 64QAM	N

Implement any one of the features from release-7 in your modem, and it is considered HSPA+. With respect to the Veer, the features from release-7 HSPA+ that are implemented are reduced cellular signaling for faster call setup, state changes, and less latency. The Veer is based around Qualcomm’s MSM7230 and uses its integrated cellular baseband, which supports HSDPA 14.4 and HSUPA 5.76, which means it supports up to 16QAM on the downlink, and QPSK on the uplink, but still is an ‘HSPA+’ modem due to the improved signaling. Again, it’s an incorrect and gross oversimplification to draw the line based on the lack of 64QAM on the downlink. It’s similarly puzzling why if we’re drawing lines in the sand based on modulation support that uplink modulation wasn’t considered. Education is the only way to mitigate such confusion.

That said there are other HSPA+ modems that do include 64QAM support on the downlink, the earliest of which that I’m aware of is Samsung Galaxy S 4G. That particular phone had an ST Ericsson THOR 5730 baseband with HSDPA 21.1 support. That same modem is likely in the Galaxy S 2 (which we haven’t played with in detail yet) and the Samsung Infuse 4G I have sitting on my desk for an upcoming review. That particular baseband is HSDPA 21.1, HSUPA 5.76, meaning it supports up to 64QAM on the downlink, but again only QPSK on the uplink, yet there aren’t similar confusing rumors about it not being HSPA+. 

I’m not even touching on whether HSPA+ should be considered “4G” or not, as that’s an entirely different argument, this is purely about whether or not certain UE categories are part of release 7, and thus HSPA+. Long story short, the HP Veer 4G is definitely an HSPA+ device. 

I did the usual due diligence and ran just above 100 speedtests on the HP Veer 4G. One interesting thing I did notice is that using the provided SIM, the Veer’s cellular connectivity indicator stayed on “3G.” The times that I used it with my own SIM for testing (we try to use each device as best we can as our own during testing periods), I saw “H+” which AT&T is showing on a number of devices. I’m definitely intrigued by why there would be any discrepancy since there shouldn’t be any difference, yet I saw this behavior all of my time with the Veer. Speeds with either inserted were virtually the same. 

You can see our breakdown the usual histogram view we’ve been presenting since our LTE investigation. Speeds on HSPA+ are definitely faster than EVDO, but still nowhere near LTE. I saw a maximum throughput result of just over 8 Mbps down, which I think to date is the fastest I’ve seen AT&T in my area. Throughput testing on the Veer was performed by running speed tests over flash to speedtest.net and then exporting results at the end. 

 

I'm starting to see this very bimodal distribution of upstream speeds (clustered around 384 kbps for just WCDMA upload when no HSUPA is working, and around 1.5 Mbps when HSUPA is working). I'm beginning to think AT&T is doing something interesting here, but that's for another story. 

We’ve been measuring signal attenuation with devices for some time now. Unfortunately WebOS 2.0 seems to do away with MiniDM, the 3G radio engineering application which was what I used on the Palm Pre Plus and other WCDMA WebOS devices.

 

Firing that up now shows null or 0 values in all fields, likely because it hasn’t been updated to measure anything from Qualcomm’s modem in the MSM7230. Unfortunately I am not aware of any other way to get RSSI from the device. That said, I didn’t notice the Veer being any more prone to deathgrip than any other phone. The only other missing piece that I still have a gripe with in WebOS is the absence of any 3G/WCDMA or 2G/GSM/EDGE toggles. There's absolutely no control over which the device is going to prefer, which was a problem on the GSM Palm Pres as well. More control is always in the interest of users. 

I was a bit worried about speakerphone volume on the Veer due to its miniscule size. Incredibly, audio loudness on speakerphone is middle of the pack and totally adequate. Handset audio quality is also very good from what I could tell. 

Compared to the Pixi and even the Palm Pre Plus, the Veer offers a dramatic difference in speed and smoothness. Unfortunately the Pixi lacks WiFi so running our webpage loading suite didn’t make much sense, however I timed application loads between the Pixi, Veer, and Pre Plus. There’s a dramatic difference between the older ARMv6 Pixi and the newer ARMv7 Veer. Again the Veer runs an 800 MHz MSM7230 with 512 MB of LPDDR RAM. 

Application Launch Time Benchmarking
Application / Launch Time (s)	Palm Pre Plus	Palm Pixi	HP Veer 4G
Maps	15.3	20.1	7.1
Camera	4.5	5.0	3.6
Memos	4.0	4.5	2.7
Web	3.3	2.5	2.1
Clock	5.0	3.8	3.3
Startup	2:19.1	-	1:39.9

The difference in raw, perceptible performance difference between the Veer and everything that came before it (save the Pre 2) is huge. Animations are completely fluid, typing fast no longer results in dramatic lag, and there’s no longer huge stalls in responsiveness. WebOS 2.0 also seems to have better memory management – I opened nearly 100 cards with AnandTech.com fully loaded and never once got an out of memory error. I did notice huge amounts of memory being swapped to disk (it’s very easy to monitor using top over novaterm on the Veer), but the device continued being fully responsive. 

 

Unfortunately loading times on the Veer are still incredibly long due to some mismanagement of the linux boot process. Unfortunately it appears that WebOS increases the sleep time that apps send to the caller during the boot process from an already crazy 60 seconds to 120 seconds. There’s discussion of this on WebOS Internals, but the situation is even worse now, at 120 seconds.

This is somewhat masked with much faster hardware, yet I have very little doubt that the Pre 3 will take an inexcusably long time to boot as the Veer and every WebOS device that came before it. 

We also ran the standard web benchmarks on all three devices. Results are comparable here but not entirely - WebKit remains 532.2 between both versions of WebOS, but it's clear that a newer JavaScript engine is being used in WebOS 2.0, possibly V8 which Qualcomm works closely to maintain and optimize for OEMs. What we’re seeing here however does translate to a perceptible performance delta. 

Whereas the Pixi is essentially laggy to the point of unusable, so much so that I honestly wonder how the device was ever considered releasable, the Veer is completely fluid.

We ran the Veer though our battery life testing suite, which consists of endlessly loading a few dozen pages over both WiFi and 3G with the screen set to half brightness (200 nits) until the battery runs out and the device powers down. On the Veer, there’s a bit of a possibility for some discrepancy due to the auto brightness that is impossible to disable. However its small display (and thus less backlight drain) no doubt also are a big factor that help it have good battery life. 

I also ran the Veer through our hotspot test, which consists of four tabs of our battery life test being loaded endlessly in addition to a 128 kbps audio stream.

 

The Veer’s mobile hotspot application is actually very impressive, allowing configuration of both the DHCP sever and wireless AP channel. 

We’ve talked about discharge time a lot so far in our smartphone reviews, but what of actual charge time? About half of my battery life testing time is spent carefully monitoring devices and their charge status (so they can be unplugged, test, and then shuffled onto the next test). The Veer includes built-in Touchstone charge compatibility, and unlike other devices doesn’t require a special back to leverage it. I used the same old touchstone from the original Pre with the Veer, no problem. 

One of the things I always wondered about with the original Pre was whether charge time was slower on the Touchstone than simply plugged in. The old Pre got alarmingly hot on the touchstone sometimes, and I never was totally convinced it was charging as fast as it could have just plugged in. The Veer doesn’t heat up anywhere near as much as I remember the Pre heating up. 

Charge Time to 100% from Fully Discharged - HP Veer 4G
Charge Method	Time
Touchstone (inductive charging)	1.798 hours
Plugged into charger (Palm)	2.223 hours

I timed charge time from completely empty after our tests to 100% full, and found that the time is virtually the same between the two. Even though the Touchstone looks a bit faster, I think we’re just seeing how not every charge cycle is completely the same. 

I mentioned at the beginning that product launches generally seem to be top down, rather than bottom up. Launch the flagship first, get the enthusiasts excited, then release mainstream and lite versions to cater to flesh out options for everyone else. The original Palm Pre launches went this way for a reason - imagine how different the Palm Pre would have turned out had the Pixi preceded it. That said, I completely understand HPalm's reasoning for launching the Veer when it did, and the reason is simple.

WebOS needs new hardware. The Palm Pre 2 wasn't a widespread mass market device that appealed to many more than WebOS enthusiasts, and in the US at least it's been proven time and time over that phones absolutely need carrier backing and subsidy to sell. The Veer undoubtedly is an easier device to manufacture, it's using a very popular SoC, and most of the package is altogether very safe. There's no time for HPalm to wait for the Pre 3 to get to a similar level of readiness, and so we get a launch like this that's bottom up. Short term it might make the situation confusing, but long term we're talking about whether WebOS will have a place at the table this time next year. 

I've come away with a bunch of different thoughts having used the Veer for this long, but the biggest of them is that although the device is definitely not for me, it has actually had the side-effect of getting me excited about the Palm Pre 3. There's nothing wrong with the Veer itself, I'd just prefer a larger display, bigger keyboard, and more importantly the flagship device where most of the developer attention will be focused. That's an important point too - the experience will always be best on whatever device the most developers have in their pocket, purely by virtue of them spending the most time with it.

The next thought is that WebOS feels incredibly smooth and fluid on the 800 MHz MSM7230 - it's a mind blowing difference in speed compared to the Pixi, and likewise with the Palm Pre Plus. In subjective terms the Veer feels dramatically smoother than any of the Android phones I've played with which also use the MSM7230. On Android the only real competitor in terms of this size is the LG Optimus One series of devices (which go under a variety of names stateside for each carrier), and although I'm a big fan of those devices, the compromise that's made is you get a decidedly slower phone based on a 600 MHz ARMv6 MSM7227. Then there's the matter of price. As of this writing, can get the Veer for $99 from AT&T directly, or $50 from Amazon Wireless on contract.

Left: LG Optimus One, Right: HP Veer 4G

I was originally skeptical that WebOS could remain competitive with an entirely single core lineup in a world where dual and even quad core is becoming the norm, but honestly I've come away with renewed confidence. 

If you're in the market for a tiny smartphone and are willing to use a nonstandard cable for USB and a small detachable dongle for your headphone jack, the Veer makes a lot of sense. The other big ones are the non user-replaceable battery and lack of external storage, but admittedly that's the same boat the Pixi was in. The Veer runs the full version of WebOS 2.0 on a modern SoC, and is a huge step forward in polish and performance from the Pixi. There's nothing lite about the experience, and WebOS 2.0 definitely feels like a step forwards from WebOS 1.0. Now, about that Pre 3...