Recently I’ve been doing quite a bit of work with Symbol’s new wearable terminal, the WT4070 and the WT4090, the long awaited upgrade to Symbol’s original DOS wearable terminal the WSS1060. For those unfamiliar with these terminals, these are wearable terminals typically used by warehouse and distribution center workers such as UPS, FedEx, etc. The WT4070 is the currently shipping version that support 802.11 b/g, and the WT4090 will support 802.11 a/b/g. It is actually the same unit with software changes to handle some regulatory hurdles with the radio.

For the last few months, I’ve been working on migrating the SVTP terminal emulator I wrote at Symbol, from the old DOS terminal to Windows CE (SVTPCE) for one of our larger customers. Symbol does ship the WT4090 with a license for another terminal emulator, but our customer preferred having a version that was drop in compatible with their existing terminals, which used the original SVTP, and could be customized to meet their exact requirements.

Since I’ve been working with this new terminal, I thought I’d give a short review of the new WT4090 terminal and some tricks for working with this terminal.

Overall the WT4090 is a great terminal, and is a long awaited addition to the Symbol product line. It’s lightweight at only 12.6 oz. and has a very nice display and keyboard layout. The WT4090 will be available in two keyboard layouts, a “2-tap” keyboard that functions like the legacy WSS-1060 did, and a “3-tap” keyboard that operates more like a cell phone keyboard.

However, the biggest feature is that you now have a full Windows CE 5.0 operating system strapped to your wrist or belt which opens up a huge number of possible applications. Initially I see this product as a technology refresh for the current WSS1060 users who will mostly use it for warehouse and distribution centers, but down the road this could easily be used for many other types of field force applications where it would be helpful to not need to carry the terminal around. And with the belt option and voice capabilities the options expand even more.

Scanners
The WT4090 also comes with two scanner options, the RS-309 Scanner and the RS-409. The RS-309 scanner is very large and bulky for a wearable scanner and I wouldn’t recommend it, but the RS-409 is a very nice device that compares favorably to the older RS-1 and SRS-1. Also, the scanner can be connected on either side of the terminal to allow for either left or right-handed users.

Display (not Touchscreen)
The display is a nice 320 x 240 landscape pixel addressable QVGA. It is sufficiently bright for working indoors, but would be difficult to use in an outdoor environment. Overall a pretty nice display.

One of the first things that I noticed was, like the MC1000, the WT4090 does not have a touch screen!!! When asked, Symbol told me that this was a design decision to help improve the terminal’s ruggedness in the wearable environment. Since the terminal is meant to be worn on the wrist or belt, they felt that having a touch screen would reduce the ruggedness of the device and receive stray mouse events.

However, I find that the lack of a touchscreen on a Windows operating system is difficult to work with. After a while I was able to navigate fairly well with the keyboard, but there are some functions that I was never able to access. Also, its hard to get past the habit of trying to push the buttons on the screen when looking at a windows environment. In a production environment this is probably ok since the end users will not need to navigate the Windows CE Shell, but as a developer or administrator it can be quite painful.

There are two ways to get around this “problem”. First, Symbol has provided USB keyboard and mouse drivers for their terminal which you can use to connect directly to the WT4090 (through the cradle). However, it requires an odd cable, a Mini USB A to USB A Female connector, which is apparently commercially available but not at any of the normal electronics stores (Radio Shack, CompUSA, Best Buy, …).

The second option, is to run the Microsoft ActiveSync Remote Display program to connect to the device over a regular ActiveSync connection. This is the choice I took, since it didn’t require finding special cables, and as a developer I needed to use the USB connection to debug the application. See my article on ActiveSync Remote Display for CE 5.0.

One more consideration when developing applications for the WT4090 is the memory configuration. The device has 128MB of RAM, and another 64 MB of flash available in the /platform and /application directories that Symbol uses for installing applications.

The WT4090 does not provide any slots for an external memory card. In general this is not a problem since the terminal is targeted for a warehouse environment which is continuously connected, but will prevent this terminal from being used in other field force applications.

New Bluetooth Stack
This terminal uses the StoneStreet OneBlueTooth Stack which Symbol is now also using on the MC9094. While in theory switching between the various BlueTooth implementations shouldn’t be a problem, it is when they implement different programming APIs. So for us this means migrating our BlueTooth implementation from using the Microsoft Socket interface to the API provided by Symbol on devzone.

Also note that Symbol is not providing the BTExplorer GUI on this terminal so all BlueTooth access must be done using the software APIs.

Software Development
Development for this terminal is essentially the same as any of the other Symbol handheld terminals. Since it is a Windows CE 5.0 device it is best to do your development in Visual Studio 2005 to be able to deploy your applications.

Symbol provides the folowing set of SMDKs for wearable development (available in devzone):

• SMDK v1.1 for C (replaces SMDK v1.4 for eVC4)
• SMDK v1.2 for Java (1.3 will support WT40xx and Fusion)
• SMDK v1.3 for .NET (1.4 will support WT40xx and Fusion)

There are two ways to cause an application to run during the Symbol startup of the terminal, either using the Symbol Startup Program Registry Keys or as a Startup Application in the Symbol Startup Folder. You should pick only ONE of these choices.

Symbol Startup Program Registry Keys

Symbol has created a set of registry keys that can be used to create a controlled launch of programs during the boot sequence. By setting these parameters, and using the Microsoft wceload command, it is easy to orchestrate the applications that are run during startup.

HKEY_CURRENT_USERSoftwareSymbolStartupProgramsProgN

Where ProgN can be set to any value between 1 and 20. However, be careful since some of the values are reserved for Symbol applications, and may be used by other applications.

Reserved Values:

• Prog4 Symbol .NET Class Libraries
• Prog5 Symbol AirBeam Abboot.exe
• Prog7 Symbol AirBeam Abstart.exe
• Prog10 Symbol Printer Drivers

Another nice part of the Symbol Registry is the options that can be set for each of the programs. This allows you to have real control over applicationstartup.

Registry Options:

• Name Application file name with full path spec (string)
• Command Application command line parameters (string)
• Continue Block or not block, 1 = do not wait for program to finish
• ColdBootOnly Run on cold boot, 1 = run on cold only (dword)

While these commands can be used for launching any program, they can also be easily used to install CAB files as well with the Microsoft application. By using Microsoft’s wceload utility you can easily install CAB files from the command line with several helpful options. See the wceload page for details on the command line option.

An Example:

;****************************************************
;
; SVTP CE
;
;****************************************************

; Load .NET CF 2
[HKEY_CURRENT_USERSoftwareSymbolStartupProgramsProg11]
“Name”=”windowswceload”
“Command”=”/delete 1 /noaskdest /noui windowsNETCF2.CAB”
“Continue”=dword:0
“ColdBootOnly”=dword:1

; Load SVTPCE
[HKEY_CURRENT_USERSoftwareSymbolStartupProgramsProg12]
“Name”=”windowswceload”
“Command”=”/delete 1 /noaskdest /noui windowsSVTPCE.CAB”
“Continue”=dword:0
“ColdBootOnly”=dword:1

; Run SVTPCE – Example, uncomment to use.
; Per Symbol the “preferred” method is to use the ApplicationStartup
; directory, but you can’t control the order
[HKEY_CURRENT_USERSoftwareSymbolStartupProgramsProg13]
“Name”=”Program FilesSVTPCE_FDXSVTPCE”
“Command”=””
“Continue”=dword:1
“ColdBootOnly”=dword:0

Symbol Startup Folder

The other main choice is using the Symbol Startup Folder. In this method, you simply create a “.run” file which provides the options for running an application, and installing the file in the “ApplicationStartup” directory. Symbol says this is the preferred method.

A “.run” is a text file with two lines. The first line is the complete name of the executable file (with full path information), and the second line is an optional command line argument to be passed to that executable file. For instance, if the run file contains the command:

Program FilesSVTPCESVTPCE.exe

It will launch the SVTPCE application. However since the execution order is unspecified, if the program needs to be installed first, you will either need to load the CAB files with Registry parameters, or create an application to load the CAB files and run the application.

Pros and Cons of These Methods

Each of these methods for controlling application startup have their pros and cons, and this must be carefully considered when setting up a configuration.

Registry Method: The key advantage of the Registry Startup method is the absolute control that can be had with the startup of the applications. This allows specifying if the applications only runs at cold boot, whether the application is run synchronously or asynchronously, and the exact sequence of the programs. All of which provide a huge amount of control for the user.

Despite all of these advantages, there is also a downside to the Registry Startup method. Since there are a small set of registry values allocated these must be managed very carefully. This is fine if you are integrating a custom system, but can be very dangerous with a product that must be able to interoperate with other programs.

Application Startup Method: This option provides the simplest method for starting applications, but what you gain in simplicity, you lose in control. Unlike the Registry method there are no guarantees on the sequence of the applications that are launched. Likewise, you aren’t able to control how and when the applications are launched. Any such control must be provided in a custom program for your application.

Although you lose control in the launch sequence, it is the simplest method for applications that don’t require special treatment. Also, it is the best method for products that must be able to launch in any environment.

Other references:

• Symbol White Paper – Installing Applications for Persistence:
  http://devzone.symbol.com/resources/Installing_Applications_for_Persistence_v2.pdf
• Microsoft wceload command reference:
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcepbguide5/html/wce50lrfWceloadTool.asp
• Automatically Installing Applications After a Cold Boot – Graham Atkinson:
  http://pbdj.sys-con.com/read/195262.htm