PocketRemote: Integrating a Universal Remote Control with a Handheld Computer

by

Angus Huang

Submitted to the Department of Electrical Engineering and Computer Science in Partial Fulfillment of the Requirements for the

Degrees of Bachelor of Science in Computer Science and Engineering

and Master of Engineering in Electrical Engineering and Computer Science

at the Massachusetts Institute of Technology

February 1, 2002

2002 Angus Huang. All rights reserved.

The author hereby grants to M.I.T. permission to reproduce and distribute publicly paper and electronic copies of this thesis

and to grant others the right to do so. Author Department of Electrical Engineering and Computer Science February 1, 2002 Certified by Dr. Amar Gupta Thesis Supervisor Accepted by Arthur C. Smith Chairman, Department Committee on Graduate Theses

i

PocketRemote:

Integrating a Universal Remote Control with a Handheld Computer by

Angus Huang

Submitted to the Department of Electrical Engineering and Computer Science

February 1, 2002

In Partial Fulfillment of the Requirements for the Degrees of Bachelor of Science in Computer Science and Engineering

and Master of Engineering in Electrical Engineering and Computer Science

Abstract As technology brings more and more portable devices into common use, applications must be available to sustain this trend. While the features and performance of these portable devices are fast advancing, they are still quite limited when compared to a desktop computer. To be successful, applications should take advantage of these devices’ portability and convenience, but should be careful not to overstep their technological limits. This thesis examines such an application. The PocketRemote is an application that runs on Pocket PC handheld computers, in essence, turning each of these devices into a universal remote control to communicate with virtually any electronic component around the household. It is aided by SmartGuide, which downloads TV program information from the Internet via a connected PC. After transferring the data to the handheld device, PocketRemote will contain a fully integrated TV listings viewer as well. This thesis will look at the implementation of the PocketRemote and rationale behind various design decisions. It will then conduct a comparative analysis of PocketRemote with other options currently on the market. Thesis Supervisor: Dr. Amar Gupta Title: Co-Director, Productivity from Information Technology (PROFIT) Initiative, M.I.T. Sloan School of Management

ii

Table of Contents

1 Introduction...................................................................................1

1.1 PROJECT DESCRIPTION ...................................................................................... 3

2 Background ...................................................................................5

2.1 PERSONAL DIGITAL ASSISTANTS ....................................................................... 5

2.2 UNIVERSAL REMOTE CONTROLS....................................................................... 7

2.3 ALTERNATIVE SOLUTIONS ............................................................................... 11

Radio Shack 15-1994 ................................................................................................ 12

Philips Pronto ............................................................................................................ 13

Proton Smart ............................................................................................................. 14

OmniRemote ............................................................................................................. 16

3 Design........................................................................................... 18

3.1 PROJECT GOALS ............................................................................................... 18

3.2 POCKET PC....................................................................................................... 20

3.3 SKINS................................................................................................................. 23

3.4 PROGRAMMING LANGUAGES ........................................................................... 25

3.5 GENERAL APPROACH....................................................................................... 26

3.6 MATERIALS....................................................................................................... 27

Software .................................................................................................................... 27

Hardware ................................................................................................................... 29

4 Specifications.............................................................................. 30

4.1 SMARTGUIDE (PC COMPONENT) .................................................................... 30

iii

Setup.......................................................................................................................... 30

Using SmartGuide..................................................................................................... 38

Database Synchronization......................................................................................... 38

4.2 POCKETREMOTE (POCKET PC COMPONENT) ................................................ 41

Remote Control Setup ............................................................................................... 42

Learning Mode .......................................................................................................... 44

Using SmartGuide Within PocketRemote ................................................................ 47

Creating Skins ........................................................................................................... 50

5 Implementation.......................................................................... 53

5.1 DESIGN RATIONALE ......................................................................................... 53

5.2 SMARTGUIDE – CHANNEL LINEUP .................................................................. 55

HTTP Connection..................................................................................................... 56

HTML Parser ............................................................................................................ 57

Channels Database .................................................................................................... 61

5.3 SMARTGUIDE – TV SHOWS ............................................................................. 63

HTTP Connection..................................................................................................... 65

HTTP Connection (Channel-Specific)...................................................................... 65

Channel Parser (Channel-Specific) ........................................................................... 68

HTTP Connection (Show-Specific).......................................................................... 69

Channel Parser (Show-Specific) ............................................................................... 69

TV Shows Database .................................................................................................. 71

5.4 POCKETREMOTE – USER INTERFACE ............................................................. 71

5.5 POCKETREMOTE – INFRARED ......................................................................... 73

5.6 POCKETREMOTE – SMARTGUIDE ................................................................... 79

6 Results.......................................................................................... 80

7 Future Work............................................................................... 84

iv

7.1 INFRARED .......................................................................................................... 84

7.2 TV GUIDE ONLINE........................................................................................... 85

7.3 BUSINESS PLAN ................................................................................................. 86

8 Conclusion................................................................................... 88

9 Appendix A - Skins.................................................................... 90

9.1 BASIC BLUE TV ................................................................................................ 91

9.2 BASIC BLUE VCR ............................................................................................. 92

9.3 PR VCR............................................................................................................ 93

10 Appendix B – SmartGuide Source Code ........................... 94

11 Appendix C – PocketRemote Source Code ....................... 95

12 References................................................................................ 96

v

List of Figures

Figure 1 - PocketRemote's Overall Architecture. ............................................................... 3 Figure 2 - Radio Shack 15-1994. ...................................................................................... 12 Figure 3 - Philips Pronto. .................................................................................................. 13 Figure 4 - Proton Smart..................................................................................................... 14 Figure 5 - ProntoEdit screen shots. ................................................................................... 15 Figure 6 - OmniRemote running on a Palm Pilot. ............................................................ 16 Figure 7 - SmartGuide Provider window. ......................................................................... 31 Figure 8 - TV Guide Online - Listings Setup - Enter Zip Code. ...................................... 32 Figure 9 - TV Guide Online - Listings Setup - Select Cable Provider. ............................ 33 Figure 10 - TV Guide Online - The Provider ID for this example is 71086..................... 33 Figure 11 - SmartGuide Channels window. ...................................................................... 34 Figure 12 - SmartGuide Times window. ........................................................................... 35 Figure 13 - SmartGuide Task window. ............................................................................. 37 Figure 14 - ActiveSync screenshot. .................................................................................. 39 Figure 15 - ActiveSync Options. ...................................................................................... 40 Figure 16 - Database Synchronization Settings. ............................................................... 40 Figure 17 - Import from Database to Mobile Device ....................................................... 41 Figure 18 - Database Synchronization Settings ................................................................ 41 Figure 19 - PocketRemote initial screen........................................................................... 42 Figure 20 - PocketRemote Options form.......................................................................... 42 Figure 21 - PocketRemote new remote form. ................................................................... 43 Figure 22 - Remote control created................................................................................... 43 Figure 23 - PocketRemote displaying newly created remote control. .............................. 44 Figure 24 - “Remotes” menu with newly created remote control and “Learn…”............ 45 Figure 25 - Ready to capture IR signal…… ..................................................................... 46 Figure 26 - Command learned. ......................................................................................... 46 Figure 27 - The learned button ("1") appears in an alternate color................................... 47 Figure 28 - SmartGuide hidden. ........................................................................................ 48 Figure 29 - SmartGuide Simple View. ............................................................................. 48 Figure 30 - Detailed show description. ............................................................................ 49 Figure 31 - SmartGuide Full Screen. ................................................................................ 49 Figure 32 - Example "image.bmp" file. ........................................................................... 51 Figure 33 - Example "imagealt.bmp" file. ........................................................................ 51 Figure 34 - Skin directory structure. ................................................................................. 52 Figure 35 - SmartGuide Module Layout........................................................................... 53 Figure 36 - PocketRemote Module Layout....................................................................... 54 Figure 37 - SmartGuide Data Flow for Channel Lineup Setup. ....................................... 55 Figure 38 - TV Guide Online partial screen shot corresponding to

“http://www.tvguide.com/listings/index.asp?I=pid”. ........................................... 57 Figure 39 - Channels Database structure. ......................................................................... 61 Figure 40 - SmartGuide Data Flow for TV Show downloading....................................... 63 Figure 41 - TV Guide Online screen shot of channel-specific ("7A WHDH") listings .... 64 Figure 42 - Show-Specific page........................................................................................ 70

vi

Figure 43 - Shows Table. .................................................................................................. 71 Figure 44 - Pulse-Width Modulation [22]. ....................................................................... 74 Figure 45 - Space-Coded Modulation [22]. ...................................................................... 76 Figure 46 - Shift-Coded Modulation [22]. ........................................................................ 76 Figure 47 - Implementation and testing of IR learning process........................................ 76 Figure 48 - Channel Retrieval Time. ................................................................................ 80 Figure 49 - TV Listings Download Time. ........................................................................ 81 Figure 50 - ActiveSync Transfer Time. ............................................................................ 82 Figure 51 - PocketRemote Startup Time. ......................................................................... 83

vii

List of Tables

Table 1 - Palm OS v. Pocket PC - System Features Comparison [10] ............................. 22 Table 2 - List of all software required for development. .................................................. 28 Table 3 - List of all hardware required for development. ................................................. 29 Table 4 - IR encoding for Sony remote controls [23]. ...................................................... 75 Table 5 - Size of entries in the Channels table.................................................................. 81 Table 6 - Size of entries in the Shows table. ..................................................................... 82

viii

Acknowledgements

First and foremost, I would like to thank Dr. Amar Gupta for the guidance and support he has given me in this long, arduous process. He always made time to sit down and talk with me at every step of the way. I would also like to thank Nicoli Ames, my partner in developing this project, for all her hard work and selfless commitment to making this project a success. A thank you goes to Mark Chuang as well for his technical contributions and advice. Last but not least, my parents have supported me whole-heartedly throughout my entire college career. I would like to give them thanks for none of this could have happened without them.

1

1 Introduction

Two emerging technologies, the personal digital assistant (PDA) and the

universal remote control, seem destined to be unified into one device. While the two

alone are extremely popular among the general consumer market, both can gain so much

more by being fused together. Each would be able to make up for what the other lacks,

and this marriage would result in the special case where the resulting combination is truly

greater than the sum of its parts.

The PDA, or handheld computer, is currently one of the hottest technological

products on the market. It follows precisely the trend of shrinking devices. The PDA is

the present-day manifestation of decades’ worth of evolution. Over the years, we have

witnessed computers taking up entire rooms to desktop computers to laptops and finally

to the PDA – computing machines that fit in the palm of a hand. While PDAs cannot

compare with current desktops in terms of computing power, they are only a handful of

years behind; a top-of-the-line PDA today has the same processing power as that of a PC

only four years old. Gadget-loving consumers are snatching up these devices because

they are feats of technology and simply neat toys. Despite all of this technological

progress, however, PDAs are still used for little more than as address and schedule

managers. Their growing popularity may not last long as their novelty begins to wear off

and users begin to demand more useful functionality. A “killer app” is desperately needed

to sustain the PDA’s growth.

2

The universal remote control, on the other hand, already has its “killer app”; it

eliminates the mess of remote controls present in many households. Lately, just about

every home entertainment component and even some ordinary household appliances

come with their own personal remote controls.

Universal remote controls, however, are filled with flaws. Their goal of

convenience is often times shattered by a mess of complexities in their design and

implementation. One of its biggest flaws is its often-exorbitant price, which can

sometimes single-handedly match the price of the entire home entertainment system it is

intended to work with.

It then becomes appropriate to fuse these two devices into one device. The

universal remote control provides the PDA with a “killer app”; in turn, the PDA provides

a foundation upon which the universal remote control can be implemented with minimal

complexity and error.

The PDA has all the right makings to run a remote control application. An

infrared port is already present to beam commands to various enabled devices. An LCD

(liquid crystal display) touch-screen helps to alleviate the clutter of buttons found on

many universals by displaying only those functions that are needed. The ability of the

PDA to synchronize with a desktop computer gives increased power to the remote control

application, which can now harness the resources of the PC to do extra computing,

editing, or Internet communication. The remote control itself would be software-based,

which can help to provide a more flexible end product and limit bugs and complexity.

3

1.1 PROJECT DESCRIPTION

In this project, we will develop a program called PocketRemote that turns a PDA

into a generic universal remote control. In PocketRemote, graphical buttons on the PDA’s

LCD touch-screen represent the remote control. The PDA’s infrared port carries out

communication, and the PocketRemote will be able to control any household electronic

component that is capable of receiving remote control commands (see Figure 1).

Pocket PC(PocketRemote)PC

(SmartGuide)

Internet

TVGuide Online

Television

Receiver

Cable

Camcorder

VCR

Satellite TV

Figure 1 - PocketRemote's Overall Architecture.

The remote control’s appearance will be completely customizable by the user.

This can easily be accomplished because the “remote controls” simply images created in

a common image format (i.e. bitmap). Therefore, different button layouts, or skins, can be

created using any standard drawing program. The actual buttons, then, are simply

rectangular designations of pixels within the remote control image.

4

In addition, PocketRemote will be able to download TV listings from the Internet

via a PC and transfer the information to the PDA. This feature, called SmartGuide, is the

main feature distinguishing PocketRemote from any other universal remote control. The

TV listings viewer will be fully integrated into the PocketRemote application so that

changing channels with the remote and knowing what is currently on TV will be a single,

seamless experience. As users flip through channels, SmartGuide will be able to follow

along and display media content for the various channels. Users can additionally scroll

through the listings, click on any program within SmartGuide, and instantly be taken to

its channel on their TV.

This paper goes on to describe the design and implementation details of

PocketRemote and attempt to show that PocketRemote is currently the best solution to

“remote control hell”. Section 2 (Background) provides a general background giving an

overview of the fundamental technologies used in this project – the PDA and the

universal remote control. It goes on to describe current alternative solutions and their

potential areas for improvement. Section 3 (Design) draws upon these areas of

improvement and lays out the design goals that PocketRemote aims to meet. Section 4

(Specifications) serves as a user’s manual for PocketRemote stepping through the

common operations of the program. Section 5 (Implementation) delves into the details of

the program and its implementation. Section 6 (Results) presents the results of the project

and discusses whether the end product has met the goals of Section 3 and how it matches

up with those solutions in Section 2. This discussion leads into Section 7 (Future Work),

which describes areas of the project that warrant future work. Finally, Section 8

(Conclusion) concludes with a general analysis and critique of PocketRemote.

5

2 Background

2.1 PERSONAL DIGITAL ASSISTANTS

As we progress into the new millennium, technology is advancing at a faster pace

than ever. What used to be at the forefront of this technological revolution - the personal

computer - is now fast becoming an antiquated device. The PC is too confining for the

new wave of technology, restricting people to sitting in front of a desk. In response to

such a lack of freedom, the current technological trend is going through a fusion of

computers and portable devices. Computing power is being distributed to all sorts of

portable devices, delivering functionality never before seen or imagined.

A personal digital assistant (PDA) is a handheld computer that allows one to store

and organize information. Sizes are typically comparable to an adult hand, but are getting

smaller and slimmer every year, although prices remain relatively constant between $100

and $600. Interaction with the PDA is normally carried out using a stylus via a touch-

sensitive screen.

The PDA is the embodiment of the trend towards decreased size and increased

convenience. These very popular devices give people many of the same functions as a

desktop computer, all in a package that is capable of fitting into a trouser pocket. Users

have computing power at their hands no matter where they are. The fascination with the

latest technology and gadgets has made the PDA a big sell. New York-based NPD

Intelect has estimated that handheld sales in 2000 topped 3.5 million and raked in $1.03

6

billion. These figures are way up from the 1.3 million devices ($436.5 million) sold in

1999 [1]. Drop in sales of personal computers during this same time highlights the trend

towards portable computing.

While getting closer and closer, PDAs nevertheless still have far to go before they

can match the performance of today’s desktop computers. Many PDAs are still being

used as little more than high-tech schedulers and address books. The Internet was a major

factor in creating demand for computers and will play a similar role for PDAs as well.

While wireless Internet connections for PDAs are available, current options are still too

slow, expensive, and bulky.

Wireless Internet seems to be the “killer app” that will make the PDA a truly

useful device instead of just a fad, but right now, that feature is simply not practical.

According to Palm, more than a third of the buyers of the wireless Palm VII, the best-

selling wireless PDA on the market, have never even used its wireless features [3]. Jim

Forbes, analyst for IDG Executive Forums, stated “once we stretch the budget to buy a

$200 gadget, 99 percent of us aren’t about to pay another $20 or more to put the thing

online. Not when we’re already paying for cable, long distance, cell phone and regular

Internet access, even as electricity seems to get costlier by the minute” [3]. For example,

to get the very popular Compaq iPAQ online, one would need to first purchase a PC Card

Expansion Pak that retails at $150. Second, an actual wireless PC Card such as the Sierra

AirCard 300 is needed – that is $400. And last but not the least, consumers need to fork

over about $60 to an ISP for monthly Internet service. That is much more than the great

majority of consumers are willing to pay, especially for connections at a painfully slow

40-50 Kbps.

7

In addition, small screens incapable of properly displaying standard websites

further detract from the Internet experience on PDAs. There are sites that have special

HTML source specially designed for the miniature browsers of PDAs, but these sites are

still rare. When one encounters a site not tailored towards PDAs, the page will usually

appear incorrectly formatted.

In somewhat of a catch-22 situation, this limited display has resulted in software

that shies away from any sort of display-intensive nature whatsoever. Currently, there are

few applications that use the PDA’s display to its full potential. Jeff Hawkins, co-founder

of Handspring and the co-inventor of the Palm OS, does not believe that color screens

currently make market sense; there needs to be more software applications that use color

effectively [3]. So far, the only applications that really rely on a good color display are

games and photo viewers, but games have been quite lacking amidst the backdrop of

exciting new video game consoles, and photograph viewers have just not caught on.

So there seem to be many limitations that inhibit the success of the PDA, the most

critical being the lack of software applications. More specifically, it is the lack of useful

software applications that play on the strengths of PDAs and avoid its weaknesses.

2.2 UNIVERSAL REMOTE CONTROLS

Home entertainment devices have been multiplying in recent years. The

outpouring of different types of media has spawned a multitude of different components

with which to play them. A decade ago, a VCR and tape deck may have sufficed, but

now, every household seems to have a list of must-haves that include TVs, satellite or

8

cable, receivers, stereos, speakers, and various media players. When each of these

components comes with a separate remote control, users quickly find themselves

inundated.

The remote control has engrained itself into our society. “Since [its birth], the

remote control has become a cultural icon, a bane of television advertisers, a focus of

household power struggles and an enduring symbol of American life. ‘We are in a

remote-controlled world,’ said Dan Williard, president of Replacement Remotes. ‘People

are lost without it.’ The most frantic calls to his company come from people who need

replacements sent overnight before ‘the big game,’ he said” [8].

David Alpert, president of an Internet startup called MarketingInfo, admits that he

is addicted to remote controls, as is his family [8]. The Alperts have accumulated around

fifty-five remote controls around their house over the years to control things as trivial as

the air-conditioning system and the lights. Five remote controls are required just to watch

a movie, and twelve to listen to the radio (because of separate controls for components

like the subwoofers and the equalizer). Although an extreme example, the Alperts show

how remote controls can overrun a family’s life.

The figures can be quite astounding. Remote controls now outnumber the entire

population of the United States [5]. And according to the Consumer Electronics

Association, the average U.S. household has more than four remote controls [3], which,

in many instances, is greater than the number of residents in the house. In fact, 99 percent

of all TV sets and 100 percent of all VCRs sold in the United States come with a remote

control [9]. Simply having a TV and a VCR at home means owning two remote controls.

Add any other electronic component, and it too, is likely to have a remote control as well.

9

Beyond the home entertainment system, remote controls are now found with such

appliances as the fans, air conditioning, lighting, synthetic fireplaces, and drapes. In the

car, there is the in-dash stereo system as well as passenger video consoles. And even in

front of the computer, PlanetPortal will introduce the WebRemote Control, which will

allow a user to surf the web with a touch of the button – just for those who have become

too impatient with using even a mouse.

The universal remote control is the solution to the mess of remote controls that

multiple electronic components bring. It is a single remote control that can be used in

place of all others to control any device that at one time relied on its own remote control.

With the current state of remote controls, there has never been a greater need for such a

device.

Universal remotes are priced from $7.99 to over $1000; this range makes it

evident that different remote controls have very different features. Low-end remotes can

be had for $20 or less. They work, but don’t come with any extended functionality. They

will probably require users to enter codes for each of the components and will not likely

support the more advanced options such as Picture-in-Picture for TVs. Mid-level remotes

usually retail for less than $100. Most midrange remotes add the feature of IR learning;

instead of entering codes for each component, the remote control can “learn” IR codes by

simply aiming and clicking a working manufacturer’s remote at the universal remote. The

universal will then pick up the code and assign it to one of its buttons. The high-end

remotes often take the form of PDAs and have a wide array of advanced features and

price tags that can soar in the hundreds of dollars. Not only can they learn IR codes, they

often come with an LCD touch screen (much like a PDA) and the ability to connect to a

10

PC. Some come with software programs that let users customize the interface on these

touch screens. They can also accommodate a lot more equipment such as home lighting

and WebTV.

Companies have flocked to the universal remote control market, and customers

have likewise flocked to stores to snatch them up. MSN's eShop currently lists 66

different models for sale [5], and the fact that many are willing to pay hundreds of dollars

for a universal remote shows the high demand for such devices. Many universal remote

control fanatics have even risen from this crowd. For Daniel Tonks, updating,

maintaining, and writing independent remote reviews for the Web became his new full-

time job [1]. He maintains a site named RemoteCentral.com that contains just about any

information one would need to know about universal remote controls, whether a novice

looking into getting a universal for the first time or an experienced user looking to get the

latest tips and tricks. “[There] you can join in community debates, such as whether macro

pause buttons should be activated after a one-second or a two-second delay” [4].

Despite their popularity, universal remote controls currently on the market are far

from perfect and far from solving all the problems for which they were intended. Many

fight a losing battle to achieve both functionality and simplicity, and usually are

succumbed by one or the other. Low-end remotes usually manage to keep themselves

simple and straightforward, but they lack the functionality to make them truly useful

devices. As the remotes become pricier and more functionality is added, the complexity

is magnified by several magnitudes. “At some point, massing remote features in one

push-button unit becomes self-defeating, experts say. With so many options, confusion

can displace convenience” [5]. Users get turned off quickly as complexity and the

11

learning curve increase. Both sides of the price spectrum are vulnerable to bugs and

defects as well. The low-end models are faulty simply because they are cheap and use

cheap parts. The high-end models suffer from complexity, and therefore, a greater chance

of bugs.

One reviewer for the Wall Street Journal invited several computer engineers to

test out and play around with a handful of universal remotes [4]. This intelligently elite

group was baffled by many of the remotes and overwhelmed by their complexity. One of

the members of this group was Yaroslav Faybishenko, who is regarded as one of the top

Java programmers in the Silicon Valley. He used words like “awkward” to describe some

of the remotes that he dealt with that day.

These problems have caused much trouble for users. There have been stories of

people who decide not to deal with the additional grief that many universal remote

controls can bring. Instead, they make their own by taping their four most essential

remote controls around a block of wood. Although this is an extreme example, many

people are looking for a universal remote control that is reliable, cheap, convenient, and

simple to use. So far, few, if any, of the current universals can offer all these qualities.

2.3 ALTERNATIVE SOLUTIONS

The list of alternative solutions consists mainly of the universal remote controls

discussed above – each of them has multiple weaknesses. The OmniRemote program is

the exception in that it runs on Palm PDAs rather than a proprietary remote control

device. This program comes the closest to resembling the PocketRemote but still falls

short in many aspects. This section details a select few of the possible universal remote

12

controls currently on the market. This is a critical section of this paper because a large

part of the motivation behind PocketRemote was drawn from the weaknesses that the

alternative solutions exhibited. The design of PocketRemote was guided largely by trying

to remedy these faults.

Radio Shack 15-1994

Figure 2 - Radio Shack 15-1994.

The Radio Shack 15-1994 is one of the more popular models on the market,

attested to by the fact that it has its own website (www.hifi-remote.com). The 15-1994 is

a mid-range remote retailing at $39.99, but many claim that it can do everything a high-

end model can. It can control up to six devices, including satellite and cable receivers. Its

ability to support picture-in-picture controls is also attractive. Because of the lack of an

LCD display, however, the 15-1994 is forced to clutter itself with an array of buttons so

that the users will find a place for all their desired buttons.

13

Philips Pronto

Figure 3 - Philips Pronto.

The Philips Pronto leads the way into the higher end of the universal remote

control spectrum. It has seven “hard” direct-access buttons along with an LCD touch-

screen that displays the soft buttons. Its 5.4 × 3.6 inch dimension makes it larger than

most universal remotes and helps to prevent frequent “mistypes” of the soft buttons. The

larger size, however, may require most people to use two hands when using the Pronto.

The screen has a 320 × 240 resolution and is backlit for visibility in the dark. The lack of

color and decent contrast, however, takes away from the screen’s full potential and makes

viewing somewhat strained.

One of the most unique features of the Pronto is the ProntoEdit, a complimentary

software package used to create button layouts on a PC. A layout is created with

ProntoEdit and then downloaded to the Pronto remote. Layouts can likewise be posted on

the Internet and swapped and downloaded by any other Pronto user. This feature, in fact,

has spawned its own website (www.prontoedit.com) where users can share layouts. The

site also serves as a forum where users can go to easily obtain information, icons,

program files, and infrared codes. The software itself, however, is both complex and

14

somewhat limiting. It undoubtedly requires an experienced computer user, such that for

most persons, making new button layouts will be far from a trivial task.

The Pronto has impressive features, but at $399, it is a major investment and

seems hardly worth the price. Throw on the optional rechargeable battery pack and

recharging station and the price increases by another $99. Philips recently unveiled its

new color Pronto, which sells for $999. The ridiculousness of this price becomes even

more evident when considering the fact that a customer can buy a complete home theater

system for the price of this remote control.

Proton Smart

Figure 4 - Proton Smart.

For somewhat of a more reasonable price, the Proton Smart is available for $200

and comes with some of the same advanced features as the Philips Pronto. It is longer and

slimmer than the Philips Pronto and takes the shape of a more conventional remote

control making it easier to manipulate with one hand. The LCD touch-screen is also

15

smaller, such that more of the focus lies on its “hard” direct-access buttons, of which

there are eight of them (“On”, “Off”, “Volume”, “Channel”, etc.).

Figure 5 - ProntoEdit screen shots.

The display is still capable of being customized, however, with similar PC-based

editing software. The software is much like the ProntoEdit, but is much more limited.

Buttons are limited to simple rectangles, and no real graphics are allowed – only text and

a selection of commonly used symbols such as arrows can be used. The program also has

known bugs, which causes the program to crash if the right settings are not in place. The

Proton also limits the number of buttons on a page, and the number of total pages as well.

The Proton does not quite live up to the Philips Pronto’s features, but it also costs

significantly less. However, everything with the Proton is sold separately so that to have

the docking station and the editing software, customers must fork over $110 and $50

respectively. After doing the addition, the Proton no longer seems quite as affordable.

16

OmniRemote

Figure 6 - OmniRemote running on a Palm Pilot.

The OmniRemote is a universal remote control program for Palm-based PDAs. It

will convert PDAs running Palm OS version 3.0 or higher into a self-contained remote

control with the buttons being displayed on the touch screen. The OmniRemote has a

configurable user interface meaning users are allowed to create and place buttons

wherever they wish. Up to fifteen screens and an unlimited number of buttons can be

made, but only out of rectangles with plain text and a palette of common symbols. Not

much else can be asked for out of the Palm in terms of graphics because of the limited

resolution and color of the display. The black and white boxes of the OmniRemote are all

that can be handled adequately from the Palm’s display anyway, making for somewhat of

a dull and overly simplistic feel.

The remote learns different IR commands from the remotes that it replaces –

direct a remote at the Palm’s IR port, and the OmniRemote will learn the command. One

major problem is that some Palm models do not come with built-in IR. In this case, the

user must purchase either a Palm upgrade IR card or the OmniRemote external IR

module, which retails for $30. Even with it built in, the IR port on the Palm points out the

17

bottom, making for very awkward controlling. This requires having to flip the interface

and then holding the PDA upside-down in order for the IR beam to shoot out the front.

Therefore, using the remote control can be somewhat of an awkward experience. The

software retails for $20, but this can be somewhat steep for people who are not used to

paying much (or at all) for software. Add on a $30 IR module, and the price might

persuade many to go with a conventional universal.

With most of the alternatives discussed, there is a general theme of being overly

complex and pricey. In terms of consumer preferences, these are the two most important

aspects of universal remote controls. The success of a universal remote lies solely in the

consumer; any technical benchmark must give way to the user’s happiness about the

product, which is dependent on how much the user paid and how easy the product is to

handle.

18

3 Design

3.1 PROJECT GOALS

In order for PocketRemote to be successful, it must meet several design goals,

which are discussed in this section. The most important of these goals is convenience (for

the user). If we examine the fundamental goals of both PDAs and universal remote

controls, we will see that convenience is the underlying motive. Without a doubt, the

functions of a PDA can be reproduced by less convenient means – people can manage

their information using pen and paper, and any other computing needs can be

accomplished back at home on their PC or possibly a laptop. Likewise, a universal

remote control does not really do anything ordinary users cannot already accomplish on

their own. The PDA and the universal remote control exist to provide a convenient

alternative to having to lug around a laptop or having to get up to change the channels.

Several goals spin off from the ideal of convenience – PocketRemote should be

user-friendly, affordable, and attainable. The application should be very intuitive and

users should not have to study manuals for long periods of time before being able to use

it. PocketRemote is not intended solely for the technically inclined; it must be simple

enough for the general public to use as PDA ownership begins to move beyond just the

“techies” and goes deeper into the general public.

Other goals that motivate the development of PocketRemote involve the market

perspective on PDAs. Without more programs beyond basic PIM applications, future

19

increases in sales figures for PDAs could be in jeopardy. One of PocketRemote’s goals is

to provide the PDA with a much-desired application to boost its usefulness and chances

of survival in a harsh market.

In order to accomplish this task, the application must take advantage of the PDA’s

strengths while avoiding its weaknesses. The infrared port is an extremely underused

communications means on the PDA. Currently, it is the most viable method of wireless

communication, and applications simply do not take advantage of it enough. Few

applications have really made much use of color screens either. Advanced displays with

high resolution and a large number of colors exist, yet black and white PDAs still are big

sellers simply because color screens are not necessary. Synchronization with the PC is

also a very strong feature of PDAs. Because PDAs still do not have the full capabilities of

a modern PC, they can gain a lot from being able to sync with the latter. Much of the

work can then be done on the PC, and the results can be transferred to the PDA.

There are some things that the PDA is not yet equipped to handle efficiently. One

of those is wirelessly connecting to the Internet. As mentioned in the previous section,

wireless Internet connections on PDAs are still extremely expensive (monthly payments

plus additional hardware) and slow (maximum speeds of 40-50 kbps). Furthermore, web

pages do no display correctly on the miniature-sized screens of PDAs, especially when

images are involved. All of this makes surfing the Web a very awkward and laborious

task. The Internet is probably the greatest resource out there, and easy access to it would

bring a great deal to the PDA; however, Internet access is simply not a practical option at

this point in time and should stay on the desktop.

20

Another weakness of PDAs is text input. Without a full size keyboard, inputting

text usually requires the user to write on the touch-screen using the stylus in some OS-

specific handwriting guideline or to tap individual letters on a “soft” keyboard displayed

on the screen. Needless to say, entering text is time-consuming and somewhat unnatural.

A good application will keep the need for user input of text to a minimum.

3.2 POCKET PC

The decision to base the application around the Pocket PC operating system was

the most critical issue affecting program development, since any application is strongly

tied into its operating system.

In the handheld world, there are basically only two operating systems in

existence: Microsoft’s Pocket PC and the Palm OS. Such manufacturers as Compaq, HP,

and Casio use the Pocket PC in their devices, while the Palm OS runs on Palm,

Handspring, and Sony PDAs. These two families are fighting a bitter battle over market

share for PDAs. Palm was at the forefront of the PDA revolution in 1996 and therefore

has an overwhelming majority of the market. However, Microsoft debuted its Pocket PC

operating system for the PDA in the spring of 2000 and is now fast on the heels of Palm.

Pocket PC and Palm subscribe to two completely different mantras. Palm

sacrifices features in favor of battery life and simplicity [2]. Pocket PC, on the other

hand, is all about features and tries to mimic, as much as possible, the capabilities of a

desktop computer. Although Palm has been the winner so far in the marketplace, its

mantra may also be its downfall. As users’ preliminary fascination with Palms begins to

21

wear off, they will increasingly demand more features. No longer being satisfied with this

glorified address book, they will look to things such as color screens, MP3 and video

playback, word processing, and wireless communication. The Palm OS will be hard-

pressed to provide such services while maintaining long battery life and an overly

simplistic operating system.

The Pocket PC is a more forward-looking system; it is the closest thing one can

get to a desktop computer fitting in one’s trouser pocket. In fact, the Compaq iPAQ,

running the Pocket PC, has made it into the Guinness Book of World Records as the

“Most Powerful Personal Digital Assistant” and many other PDAs rival the performance

of desktop computers only a couple of years old. Although the battery life cannot

compare with that of Palm’s, the issue may become trivial in the future, as new battery

technology is introduced over time. Pocket PCs come with 16-bit color screens with a

320×240 resolution. Such a display makes for a much-improved PocketRemote, which

relies heavily on the user interface, skins, graphical buttons, and a TV listings viewer that

is easy to read and navigate. It would be difficult to make a decent-looking remote

control on Palms, which usually employ a colorless gray-toned display with much lower

resolution. Pocket PCs have CPUs clocking at over 200 MHz while Palms are still

operating at around 33 MHz, insufficient to handle many of the more advanced

computing applications.

22

Palm OS Pocket PC Applications Address Book

Calculator Calendar Expense tracking Games Mail Security Memo pad To-do list

Address Book Calculator Calendar Expense tracking Games Mail Security Memo pad To-do list eBook reader Internet Explorer MP3 player Voice recorder Street Maps

Battery 11 – 12 hours 6 – 12 hours

Character Input Methods 2 3

Connection Options COMM, IR COMM, IR, USB

Memory 8 MB 16 MB – 32 MB

Color Levels 256 4,096 – 65,000

Resolution 160 × 160 320 × 240

Processor 20 MHz 133 – 206 MHz

Automated Synchronization No Yes

Synchronization Speed 115,200 kbps 690,000 kbps

Percent of PDA Sales (August 2001) 51.2% 13.0%

Change in Percent of PDA Sales (June – August 2001) - 16.7% + 2.8%

Price (MSRP) $499 $499 – $599

Table 1 - Palm OS v. Pocket PC - System Features Comparison [10, 26]

23

The decision to go with Pocket PC was not only based on the fact that

PocketRemote would run better on its specifications, but that its features would

eventually pull Pocket PC out as the dominant OS behind the world’s PDAs. As more

and more serious PDA applications come out, people will come to realize that the Pocket

PC is the superior operating system. Although still far behind, Pocket PC is gaining on

Palm at a rapid pace. And with Microsoft’s track record, it is not crazy to think that the

giant software corporation can come to control any technical domain that it sets its sight

on. It already has a monopoly on PC operating systems, and that can only help its efforts

in the PDA world. Because Pocket PC is based heavily on Microsoft Windows, users get

a familiar interface, which even includes miniature versions of Microsoft Word, Excel,

Outlook, and Internet Explorer. All of these factors will work towards Microsoft yet

again owning the PDA market.

3.3 SKINS

PocketRemote takes the unique approach of using ordinary bitmap image files

(skins) to make up the appearance of the remote controls. Currently, most other LCD-

based universal remotes provide their own template of buttons that the user can lay out

with specialized software. PocketRemote’s use of skins holds several advantages over

this current approach.

The first advantage is ease of use. Creating a PocketRemote skin does not require

users to learn another program, given that users already know how to use a basic drawing

program such as Corel Draw, Adobe Photoshop, and Microsoft Paint. In order to create a

remote control on most other LCD-based remotes, users are required to learn a

24

specialized program made by that manufacturer. Many of these programs, based on the

author’s trials, are not intuitive, limited in function, and difficult to use.

The second advantage lies in the flexibility that these graphics programs offer.

PocketRemote only puts a few restrictions, such as image size, on the type of remote

control skins that a user can create. Because of this freedom, PocketRemote users can

create skins to perfectly suit their needs and are not subject to the limited configurations

of other universal remotes. Virtually any type of button can be placed anywhere.

This flexibility leads to the third advantage of increased creativity. Remote

controls made for the PocketRemote have the potential to be much more exciting and

more appealing than the competitors’ because they can be made with the most powerful

graphics software and are virtually unrestricted. The best that one can accomplish with

the competitors’ software is usually some sort of arrangement of gray rectangular buttons

with some text. Aesthetics, not just practicality, is an important part of the user

experience and PocketRemote recognizes that fact.

All of this leads to the goal of creating a large user community to create and share

skins with each other. As an increasing number of persons join into such a community,

excitement over PocketRemote will grow, attracting even more users in a snowball effect.

This process of creating skins has already proven to be successful with programs such as

the popular media player WinAmp, and PocketRemote hopes to play on that same

strategy. Skins will be posted on the Web and made freely available for downloading

among users. In this way, users do not even necessarily need to create their own skins.

Yet, the author expects many users to get involved in creating skins resulting in some

very elaborate creations.

25

3.4 PROGRAMMING LANGUAGES

The creation of PocketRemote involved a range of development tools and

programming languages, leveraging each language’s strength to a specific purpose in the

overall development process.

The main portion of PocketRemote that runs on the Pocket PC is developed using

Microsoft eMbedded Visual Basic. Visual Basic is a good programming language to use

for rapid software development. Its ease of use and high-level functionality allow for

programs to come to life in a short matter of time. It is also a good fit because

PocketRemote is based heavily on graphics, and eMbedded Visual Basic allows for drag-

and-drop of GUI objects making the creation of a user interface very straightforward.

Microsoft eMbedded Visual C++ is used to supplement development on the

Pocket PC. C++ is more difficult to program, but is a much more powerful language than

Visual Basic. It is able to get on a much lower level than Visual Basic, which results in

much greater functionality and is used in those areas that Visual Basic is not capable of

handling. COM (Component Object Model) objects are developed in C++ in order to

incorporate object-oriented programming (OOP), since OOP is not supported in

eMbedded Visual Basic.

The PC component (SmartGuide) is developed using Visual J++. The object-

oriented aspects of the language are well suited for the program, and the Windows

Foundation Classes (WFC), which are included in Visual J++, will allow for authentic

Windows interfaces. WFC is an object-oriented framework that provides Java class

encapsulation of the Win32 API, the direct interfaces to programming the underlying

Windows operating system.

26

3.5 GENERAL APPROACH

At the time of development, Pocket PC was still a relatively new handheld

operating system. Not many people had programmed for the Pocket PC, so virtually

everybody (including the author) was a novice in this area. The author did not have any

experience in general Windows programming either, which would have been of

considerable help in the field of Pocket PC programming.

Making the task even harder, resources for programming the Pocket PC simply

did not exist because of the newness of the operating system. The only published

reference material was on the Windows CE operating system, the outdated ancestor of the

Pocket PC. Microsoft Press had not even released any books or guides to programming

its new operating system.

A few resources did exist and were extensively used during the development of

PocketRemote. These resources were mainly in the form of websites. The main site of

interest was Microsoft’s MSDN Online (http://msdn.microsoft.com), which provided

resources, tutorials, and code examples for developers using any Microsoft technology.

Other sites were created solely for the Pocket PC. DeVBuzz (http://www.devbuzz.com) is

devoted to eMbedded Visual Basic development for the Pocket PC and contains many

tutorials and forums. Many bugs and problems were discovered by looking through other

developers’ postings in the forums.

27

3.6 MATERIALS

The following is a list of all materials used in the development of PocketRemote,

divided into software and hardware.

Software

PRODUCT DESCRIPTION

Microsoft eMbedded

Visual Tools 3.0

Development environment designed specifically for creating applications

on the Pocket PC. Includes eMbedded Visual Basic® and eMbedded

Visual C++®, including SDKs for the Pocket PC.

Main development tool used for creating the PocketRemote application.

Microsoft Visual J++ 6.0

Development environment for the Java programming language.

Used to create SmartGuide, the portion of the PocketRemote application

that runs on the desktop.

Microsoft Visual C++ 6.0 Development environment for the C++ programming language.

Used to integrate SmartGuide with the Windows 2000 operating system.

Microsoft Visual Basic 6.0

Development environment for the Visual Basic programming language.

Used to test and debug because it provides the fastest way to develop

28

programs.

Microsoft Access 2000

Database program that is included with Microsoft Office 2000.

Used to transfer TV listing information downloaded by SmartGuide from

the desktop to the Pocket PC.

Microsoft ActiveSync Allows data transfer between desktop and Pocket PC.

Used to transfer TV listing databases from the desktop (SmartGuide) to the

Pocket PC.

Corel Draw 10 Graphics/illustration program.

Used to create icons and remote control skins.

InstallShield Professional:

Windows Installer Edition

Setup-authoring tool.

Used to create the installation/setup process for PocketRemote.

Table 2 - List of all software required for development.

29

Hardware

PRODUCT DESCRIPTION

Workstation

Any PC running the Windows 2000 operating system.

Used for all development efforts.

Pocket PC

A PDA running the Pocket PC operating system (i.e. HP Jornada, Compaq

iPAQ, Casio Cassiopeia, etc.).

Essential for testing purposes.

IR Receiver

An infrared receiver connected via serial port to the PC.

Used for capturing the infrared signals sent by the Pocket PC and remote

controls.

Photodiode

Used for capturing the infrared signals sent by the Pocket PC and remote

controls.

Oscilloscope

Used for analyzing the infrared signals sent by the Pocket PC and remote

controls.

Table 3 - List of all hardware required for development.

30

4 Specifications

The Specifications section serves to give a detailed run-through on how to operate

PocketRemote, acting like a brief user’s manual. The section will cover how to set up

both the PC and the Pocket PC component of the application and how to use them.

4.1 SMARTGUIDE (PC COMPONENT)

This part of SmartGuide is meant to run on any Windows-based PC hooked up to

an Internet connection. The “PC component” serves solely to collect TV show

information from the Web. After parsing, the data can then be transferred to the Pocket

PC component for viewing within the application.

Setup

To start SmartGuide on the desktop, select it from the “Start Menu\Programs”

folder; it should be listed as “SmartGuide” next to its icon. The SmartGuide window will

pop up (Figure 7).

The first thing to do is to set up the Provider ID, which determines who the

particular cable provider is. Depending on geographic location, users may receive

drastically different channel lineups, local programs, and show times from each other.

Therefore, before being able to use SmartGuide, users required to look up their Provider

ID from the TV Guide Online website.

31

Figure 7 - SmartGuide Provider window.

Users must go to http://www.tvguide.com/listings in order to configure their cable

setup (Figure 8). Following the instructions at the site, users will first enter their zip code,

which leads to a list of possible cable providers (Figure 9). Once the cable provider is

selected, the configuration is done, and the correct TV listings will appear for that

particular user. Now, the Provider ID can be found by simply placing the mouse cursor

over any show in the listings. In the status bar at the lower-left hand corner of the

browser, a message of the form “javascript: cl(‘xxxxxx’,’yyyyyy’) will appear (Figure 10).

‘xxxxxx’ is the Provider ID. To enter this number, go to the “Provider” tab in the

SmartGuide window (Figure 7), type it into the text box, and then click “Enter”. Once

32

entered, SmartGuide will automatically connect to TV Guide Online using this new

Provider ID to scan all of the channels available to the user.

Figure 8 - TV Guide Online - Listings Setup - Enter Zip Code.

33

Figure 9 - TV Guide Online - Listings Setup - Select Cable Provider.

Figure 10 - TV Guide Online - The Provider ID for this example is 71086.

34

Once the channel scan is completed, select the “Channels” tab to view the channel

lineup (Figure 11). From here, users can select the specific channels for which they want

information. To do this, simply click on a channel in the “Available Channels” column

(or multiple channels while holding the Ctrl key) and click “Add” to move them over to

the “Selected Channels” column. SmartGuide will only download information for those

channels listed in the “Selected Channels” column.

Figure 11 - SmartGuide Channels window.

Of course, users can simply add all of the channels instead of choosing specific

ones, but it is undoubtedly more advantageous to select only those needed. Slimming

down on the number of channels selected will save connection bandwidth and download

time. And because PDAs have limited memory, we wish to eliminate as much

35

unnecessary data storage as possible. Lastly, the PocketRemote user will be inundated

with TV show information if all of the channels were selected, and navigating through

them will be slow and disorderly. Therefore, being conservative on the number of

channels selected will result in simplicity and efficiency.

Figure 12 - SmartGuide Times window.

After the channels have been selected, users will select the times of the day during

which they want listings. In the “Times” tab, the days of the week are listed with start

times and stop times for each (Figure 12). For each day of the week, a different time

period can be set in order to maximally and efficiently coincide with a user’s TV-viewing

preferences. This form allows users to limit downloading to only information that will

likely be of use. For example, if the only TV a particular person watches was prime-time

36

on Mondays, Wednesdays, and Thursdays, then they can simply set the start time to 8:00

PM and the stop time to 10:00 PM for each of those days and likewise select their

corresponding check boxes. Only TV show information that falls during these times will

be downloaded.

One important fact about the “Times” form is that a day is defined to start and end

at 4 AM instead of midnight. This modification allows for continuous viewing since only

a single time period can be set for each day. Because many people are still awake – and

watching TV – at midnight, a time period will have to be cut in half and separated on two

consecutive days without this modification. In selecting 4:00 AM, we have set the day

cut-off to be a time when almost everybody is asleep. In this way, the entire contiguous

block of time during which a person is awake can fall under a single day.

Furthermore, the “Default” buttons can make setting times easier. If TV viewing

times are the same across multiple days, users can simply set that start and stop time in

the “Default” row. Then, by simply clicking the “Default” button corresponding to a

particular day of the week, that time period will be automatically set to whatever is

displayed in the “Default” row.

Finally, the “Task” tab provides the settings to enable automation of SmartGuide

(Figure 13). Users can specify when and how often they want fresh data to be

downloaded and SmartGuide will automatically run at these times. In the “Task

Schedule” frame, users specify how often, in terms of number of days, that they want

SmartGuide to run, and additionally, the time at which they want to run it. The time can

be set to anything, but it is usually set to the early morning when users are asleep. This

way, SmartGuide can automatically do its job and not have to take away processing time

37

or network bandwidth from anybody during peak hours. It is not necessary to run

SmartGuide every night since a few days’ worth of data can be obtained in each

download. A balance must be struck in deciding the frequency of downloads. Users want

to maintain a higher number of days in between downloads in order to save the trouble of

frequent downloads and synchronizations, but too high a number can also mean

overwhelming memory demands or outdated information. A time period of two to three

days is usually ideal.

Figure 13 - SmartGuide Task window.

The “Download Amount” frame allows the user to specify how many days of TV

show information to get during each download. This number should be coordinated with

the download frequency value just mentioned. If the download frequency was set to three

38

days, then the download amount should probably be set to at least three days so as not to

miss data for any day. Of course, a number higher than three days can be set in case the

data are not synchronized for more than three days, for example. Too high a download

amount, however, will exhaust precious memory resources.

Lastly, the “Download Status” frame gives information while the downloading is

taking place such as current TV show or channel being parsed.

Using SmartGuide

Once the setup is complete, there is not much to using SmartGuide since it is

completely automated. All users have to do is make sure to have their computer on during

the scheduled download events. Users can also initiate unscheduled downloads, however,

by simply clicking the “Download” button. Once clicked, SmartGuide will instantly

begin the process of downloading without affecting SmartGuide’s regularly scheduled

sessions.

Database Synchronization

After SmartGuide finishes downloading TV listings, the data are stored in a

Microsoft Access database on the desktop’s hard drive. So the obvious next step is to get

this information from the desktop onto the Pocket PC for viewing. This transfer is done

via ActiveSync (Figure 14), the software that allows Pocket PCs to synchronize data –

such as calendar, contacts, and tasks – with a PC.

39

Figure 14 - ActiveSync screenshot.

The Microsoft Access database on the PC is synchronized with the Pocket Access

database on the Pocket PC. Whenever the PDA is docked, ActiveSync will determine if

the database on the PC has different (fresher) data than the one on the Pocket PC; if so,

the Pocket PC database will be automatically updated. So the entire process of

transferring the TV listings is hidden, in a way, since synchronization is done

automatically whenever the Pocket PC is put in its cradle.

To setup such a configuration, dock the PDA in its cradle to start up ActiveSync.

Then double-click the ActiveSync icon in the system tray and select “Options” from the

“Tools” menu. Select “Pocket Access” in the list and hit “OK”.

40

Figure 15 - ActiveSync Options. Figure 16 - Database Synchronization Settings.

In the ActiveSync window (Figure 15), double-click on “Pocket Access” to bring

up the “Database Synchronization Settings” dialog box (Figure 16) and click “Add…”. In

the resulting “Open file” dialog box, navigate to the location of the “SmartGuide.mdb”

file on the desktop computer; this is the database file where SmartGuide has stored all the

downloaded TV listings. The location should be the PocketRemote installation directory,

which defaults to “C:\Program Files\System26\PocketRemote”, but it could vary

depending on which directory was specified during installation. Click the “Open” button

once the file is located.

In the “Import from Database to Mobile Device” dialog box (Figure 17), enter the

location where the database will be stored on the mobile device. If PocketRemote is

installed in main memory, then it is probably “\Program Files\PocketRemote\

SmartGuide.cdb”. If PocketRemote is installed on a storage card, then it is probably

“\Storage Card\System26\PocketRemote\SmartGuide.cdb”. Make sure all check boxes

are selected and then click “OK”.

41

Figure 17 - Import from Database to Mobile Device. Figure 18 - Database Synchronization Settings.

When the database finishes copying to the device, one should be returned to the

“Database Synchronization Settings” dialog. Make sure the SmartGuide database appears

in the list and that it is selected for synchronization; then click “OK” to complete

database synchronization.

4.2 POCKETREMOTE (POCKET PC COMPONENT)

We now turn to the Pocket PC side to discuss the operation of PocketRemote. The

application is dependent on user-created skins to serve as the actual interface for the

remote control. This strategy allows for maximum flexibility in allowing users to control

how they want their remote control to appear and what kind of remote controls they need.

42

Remote Control Setup

To start the PocketRemote application, click its icon in the “Start Menu\

Programs” folder on the mobile device. The application could take up to several minutes

to load if the SmartGuide database is large. Once the application is fully loaded, a screen

will pop up indicating “You need to create a remote control!” (Figure 19). Click

“Options” from the Remotes menu at the bottom of the screen to setup a remote control.

Figure 19 - PocketRemote initial screen. Figure 20 - PocketRemote Options form.

This brings up the “Remote Options” screen (Figure 20), where all of the

management of the remotes is performed. Any installed remotes will show in the list box

on the left side of the screen. To create a new remote to add to this list, simply click the

“New…” button.

A different form will now appear to allow users to create their new remote control

(Figure 21). All skins subsequently placed in the correct directory will appear in the

43

lower half of the screen in preview form and users can browse through them with the

arrow buttons to either side. The skins are categorized by their type (i.e. what devices

they control). The first thing users need to do is select the skin that they want. Then a

“Remote Name” must be provided; this is how the new remote control will be identified

in PocketRemote, so the name should be a good indicator of what exactly the remote is

intended to control. Once this is done, click “ok” in the top-right corner.

Figure 21 - PocketRemote new remote form. Figure 22 - Remote control created.

Now, the “Remote Options” screen will reappear but with the newly created

remote control listed in the list box (Figure 22). If unhappy with the recently chosen

name or skin of the new remote, users can change these values by highlighting the remote

in the list box and selecting the “Edit…” button. Otherwise, if everything is satisfactory,

click “ok” to return to the main PocketRemote screen.

44

Learning Mode

Now, the newly created remote will be displayed in the PocketRemote main

screen (Figure 23). At this point, however, it is only an image with no functionality – it

has not yet been taught what to do.

Figure 23 - PocketRemote displaying newly created remote control.

The learning mode is the process where each button “learns” what specific

infrared signals to send out. This process provides for maximum flexibility in designing

remote controls. Users can put any button that they want on a particular remote control or

even mix buttons on a single remote from different physical remote controls. This will

not affect the proper functioning of the program since each button is trained

independently of others.

45

Figure 24 – “Remotes” menu with newly created remote control and “Learn…” entry listed.

In order for the new remote control to learn the appropriate commands, one must

enter “Learning Mode”. To do this, select the “Remotes” menu at the bottom of the

screen (Figure 24). At this point, there should be some new entries in the menu list. The

first new item is the newly created remote control. This is where users can switch

between different remote controls in their collection. The second new menu item is the

“Learn…” entry. Select this entry to enter “Learning Mode”.

To learn the command for a specific button, push that button in the PocketRemote

display. A dialog box will appear indicating that PocketRemote is ready and waiting for

any infrared signals to save for this button (Figure 25).

46

Figure 25 - Ready to capture IR signal. Figure 26 - Command learned.

To carry out the learning process, align the infrared ports of the Pocket PC and the

actual remote control, making sure that they are as close as possible to ensure a strong

signal. Hold the button on the actual remote control for approximately one second. Once

PocketRemote has picked up the infrared signal, it should indicate that the command was

learned (Figure 26). Press “OK” if finished, “Retry” to relearn the command, or

“Cancel” to undo changes to this button.

After “OK” is pressed, the button that has been programmed should appear in

another color in the learning mode screen indicating that it now has a command

associated with it (Figure 27). Now, repeat this process until all buttons have learned

their associated commands. To exit learning mode and return to the normal mode, press

the “ok” button in the top right corner of the screen.

47

Figure 27 - The learned button ("1") appears in an alternate color.

Using SmartGuide Within PocketRemote

SmartGuide is the main factor in setting PocketRemote apart from all the other

universal remote controls. SmartGuide is integrated into the PocketRemote application so

that the user can view TV listings while using the remote control and even interact with

the TV listings to jump directly to a channel or show.

There are three view settings for SmartGuide: hidden, simple, and full screen. In

hidden mode, SmartGuide is simply not displayed (Figure 28). To view the simple mode,

click the “SmartGuide” menu at the bottom of the screen and select “Show Simple”.

SmartGuide will appear as a single bar at the top of the application, displaying several

attributes for a particular TV show: (1) channel number, (2) station ID, (3) show name,

and (4) starting and (5) ending times for the show (Figure 29). A show that is currently on

(based on the PDA system time) will have its name written in white; otherwise, the name

48

will be in black. Being confined to only the top of the screen allows the user to operate

both SmartGuide and PocketRemote at the same time, while having the essentials of each

on the screen.

Figure 28 - SmartGuide hidden. Figure 29 - SmartGuide Simple View.

The entire database of TV listings can be accessed from the simple view by

scrolling through it one show at a time. Using the up and down arrows to the left of the

channel number, users can scroll through the various channels for which they requested

data. In addition, clicking the starting and ending times on the right-hand side of the

SmartGuide bar will scroll through the database by time. Clicking the starting time will

display the previous show on that channel, and clicking the ending time will display the

next one. To return to the current time, simply tap-and-hold within the time display’s red

pane.

49

Much more information for each show is available than what appears in the

simple-view bar of SmartGuide. In order to pull up additional information on a particular

show, simply tap-and-hold in the blue plane that contains the show’s name.

Figure 30 - Detailed show description. Figure 31 - SmartGuide Full Screen.

A dialog box will appear which lists the basic information seen in the simple view

along with the category, the show title, and a show description (Figure 30). Tapping

anywhere in this screen will make it disappear.

There is also the option to view SmartGuide in “Full Screen…” mode, in which

SmartGuide is displayed on top of the remote control using the full extent of the display

(Figure 30). In this view, SmartGuide looks more like the traditional TV listings found

online or in the newspaper. The grid-like setup lists TV shows with channels on the

vertical axis and times on the horizontal axis. The screen of the PDA can accommodate

about eight rows of channels and two half-hour columns of times.

50

To scroll through the entire database of shows, one can scroll through the

channels by clicking the up and down arrows in the white pane in the corner of the grid.

Clicking the left and right arrows in the white pane will scroll the times by one-hour

increments. To scroll by one-day increments, click on the left and right arrows to the

right of the date in the green pane. The swooping arrow (similar to the button found in

Pocket Outlook) will return the screen to the current time. Just as in the simple view, a

tap-and-hold of a show name will bring up a detailed description of that show. To return

to normal PocketRemote use, click “ok” in the top-right hand corner of the screen.

Creating Skins

Although skins are simply bitmap image files, they need to follow some basic

guidelines in order to be compatible with PocketRemote. First, it is recommended that

two bitmap files be made for each skin – one representing the “rest” state of the remote

control and the other representing the “pressed” state. The “rest” state will be used for the

regular state of the remote control. The “pressed” image file will represent the remote

control when all of its buttons are pressed. It is recommended that for each button, the

“pressed” image should be different (i.e. inverted colors) in order to be able to signify

that a user has pressed the button. The “pressed” file, therefore, should be the same as the

regular “rest” file except that every button should be drawn as if it were pressed.

Whenever a user presses a button, PocketRemote will display that button’s corresponding

area in the “pressed” file for a second to notify the user that the button was pressed. The

“rest” state file should be named “image.bmp” (Figure 32), and the “pressed” state file

should be named “imagealt.bmp” (Figure 33).

51

Figure 32 - Example "image.bmp" file. Figure 33 - Example "imagealt.bmp" file.

The bitmap files described above store only the image of the remote control. One

cannot, however, tell from just the image where the exact buttons are. To specify button

locations, one needs to create a text file named “skin.txt” containing x-y coordinates of

the top-left corner and the bottom-right corner. These two coordinate pairs will be

sufficient to specify a rectangular bound for each button. In addition, a button name is

required for each button and should be descriptive of the button (i.e. “power” for the

power button). A row in the text file will correspond to one button and will take the

following form:

ButtonName xleft xright ytop ybottom

52

The corresponding skin text file would look something like the following.

# skin name: vcr1 # category: VCR # Buttons # Name xleft xright ytop ybottom power 14 47 31 64 rec 56 93 84 121 epsp 94 128 84 121 disp 130 167 84 121 tvvcr 194 234 87 120 chanup 194 234 134 167 chandn 194 234 168 201 volup 194 234 201 234 voldn 194 234 235 268 stop 90 128 151 189 rewind 52 89 190 227 play 90 128 190 227 fforw 129 166 190 227 pause 90 128 228 265

After taking the previous steps, we should end up with three files – “image.bmp”,

“imagealt.bmp”, and “skin.txt”. These three files should all be placed in one folder and

that folder should be placed in the correct directory according to the file structure shown

in Figure 34.

Figure 34 - Skin directory structure.

The first level folder underneath the “PocketRemote” directory is the “Skins”

folder. Within “Skins”, users are free to create a folder for each type of remote control in

their arsenal. The folder containing our three skin files should then be placed under the

correct category. PocketRemote uses the name of the folder as the name of the skin.

53

5 Implementation

5.1 DESIGN RATIONALE

PocketRemote was designed with two main modules: SmartGuide, which resides

on the desktop, and PocketRemote, which resides on the PDA.

SmartGuide

User Interface Database Download Parsers

Task

Provider

Channels

Times

Settings

TV Shows

Channel Parser

HTML Parser

Figure 35 - SmartGuide Module Layout.

SmartGuide is divided into four main submodules – user interface, database,

download, and parsers (Figure 35). The user interface module covers the windows that

allow a user to manipulate SmartGuide’s settings. The “Task” window allows users to

customize their downloading preferences (in terms of when and how much). The

54

“Provider” window is used to establish the correct cable provider for the current user, so

as to obtain the correct TV listings. The “Channels” and “Times” allow a user to specify

which specific channels and which time periods they want data for. This allows for a

more streamlined process since only pertinent information, with respect to the particular

user, is downloaded.

PocketRemote

User Interface Learning Skins/Remotes SmartGuide

buttons commandsTV1

TV2

VCR

Cable

...

Hidden

Simple View

Full View

Figure 36 - PocketRemote Module Layout.

The PocketRemote portion is likewise divided into four major submodules – User

Interface, Learning, Skins/Remotes, and SmartGuide (Figure 36). The User Interface

consists of the actual remote control and its appearance on the PDA screen along with all

menu items. The Learning module is responsible for the PocketRemote’s learning of IR

commands from another remote control. The Skins/Remotes module handles all of the

55

skins that represent the various remote controls in a user’s database. An important aspect

of this module is managing the storage of the skins. The SmartGuide module is that part

of SmartGuide that runs on the PDA. It is responsible for tying the desktop portion of

SmartGuide in with the rest of the PocketRemote application. This module also needs to

retrieve TV show information and display it within the application.

5.2 SMARTGUIDE – CHANNEL LINEUP

Before any TV show listings can be downloaded, SmartGuide must first discover

the channels available to the user based on the user’s cable provider. The cable provider,

as the reader will recall, is represented by the Provider ID, which the user can look up at

the TV Guide Online website. This is a one-time process that is executed whenever a new

Provider ID is entered. The channel lineup rarely changes, so once determined, it is saved

and can be referred to whenever SmartGuide downloads TV listings. This eliminates the

need to rediscover the channel lineup on every download. The process of retrieving each

channel is generalized in Figure 37.

HTTPConnection

HTMLParser

ChannelsDatabaseHTML Channels

(b) (c) (d) (e)(a)

Figure 37 - SmartGuide Data Flow for Channel Lineup Setup.

First, an HTTP connection is established to the TV Guide Online Web server. The

exact URL for the correct channel lineup depends on the Provider ID. The entire HTML

56

source for this page is downloaded and sent through the HTML Parser module, where the

specific channels are picked out from the HTML. The channels for this specific provider

are then be stored in the Channels database. Once stored in the database, this process

should not need to be repeated unless a new Provider ID is selected, in which case, the

new channels must be discovered for this new provider.

The following subsections describe the implementation of this process and are

supplemented with excerpts of the Java code used in the implementation.

HTTP Connection

The first step in retrieving the channel lineup for a particular user’s cable provider

is establishing an HTTP connection with TV Guide Online’s Web server. To do this, a

URL is specified that contains the Provider ID. The exact URL is

“http://www.tvguide.com/listings/index.asp?I=pid” where pid is the value

of the Provider ID. This URL is then used to create a new URL object, thereby

establishing the connection.

static String URLPATH = "http://www.tvguide.com/listings/index.asp?I="; URL url = new URL(URLPATH + pID);

Now, the entire HTML source from this page is downloaded and stored in a single

String variable. A BufferedReader is used so that the file is read in and appended to

the String variable line by line. When the reader has finished scanning the file, the

connection is closed.

57

InputStreamReader isr = new InputStreamReader(url.openStream()); BufferedReader in = new BufferedReader(isr); String inputLine; while ((inputLine = in.readLine()) != null) result = result.concat(inputLine.trim() + " "); in.close();

HTML Parser

Figure 38 - TV Guide Online partial screen shot corresponding to “http://www.tvguide.com/listings/index.asp?I=pid”.

Now, SmartGuide has the HTML source for the web page and must now pick out

the channels. The web page that SmartGuide initially connects to is simply the TV

58

listings for all channels at the time of connection (Figure 38). During this initial phase in

which SmartGuide retrieves the channel lineup, it is not concerned with the actual TV

listings just yet. It only needs to scan through the channels displayed down the left-hand

side of the grid.

Looking at the HTML, SmartGuide is able to loop through and easily pick out the

listed channels because of the repeating nature of the HTML source code. Each channel

in the lineup has a block of HTML code with the same basic structure. The following

code excerpt from the HTML source, for example, shows the block corresponding to

channel 2A WGBH.

<!-- Start of code for channel “2A WGBH” --> <TR> <TD WIDTH=14 BGCOLOR=#CCCCCC align=left wrap> <a HREF=index.asp?view=chan&I=362884&S=206& ST=36974.6666666667&N=2A>2A&nbsp;WGBH</a> </TD> </TR> <!-- TV listings code for above channel --> <!-- Next channel -->

There is a lot of content in the HTML source that is not pertinent to the channel

lineup information that SmartGuide seeks, such as ad banners, logos, time and date, and

other preliminary information. SmartGuide skips over this and jumps directly to the first

instance of “<TR><TD WIDTH=14”, which is a unique code segment that identifies the

start of the actual TV listings. At this point, all of the channels follow almost immediately

in the HTML source.

SmartGuide then loops through the next section looking for the unique HTML

segment “<a HREF=index.asp?view=chan&I=” during each iteration. This segment

59

is present with every channel’s HTML block and occurs right before the critical

information that SmartGuide needs. Looking in the HTML example above, SmartGuide

will parse for the S and N values as well as the station’s number and name; the S and N

values are codes used by TV Guide to construct the URL specific to that channel.

Therefore, using the previous example, one would have an integer value of 206 for S and

a string value of “2A” for N. SmartGuide takes three other pieces of data as well. The

number variable simply holds the number of the channel. Some cable providers arrange

their channel lineup with channels split between cable A and B; the cable variable holds

this character, and if no letter exists, it is assigned a special null value. Lastly, the

station variable holds the string identification of that channel. In summary, the

example above would have the following values:

(int) S = 206 (String) N = “2A” (int) number = 2 (char) cable = ‘A’ (String) station = “WGBH”

This entire process is made possible because of the channels’ repeating blocks of

code and their similarities in code structure; SmartGuide can easily identify the critical

values for the channels by taking advantage of the code patterns. The parsing loops until

the segment “<a HREF=index.asp?view=chan&I=” can no longer be found, meaning

that there are no more channels remaining.

60

private final static String CHANNEL_IDENTIFIER = "<a HREF=index.asp?view=chan&I="; sub = sub.substring(index); // sub = "<TR><TD WIDTH=14..." index = sub.indexOf(CHANNEL_IDENTIFIER); while (index != -1) // while still more channels { sub = sub.substring(index); // S identifier index = sub.indexOf("&S=") + 3; sub = sub.substring(index); index = sub.indexOf("&ST"); sString = sub.substring(0, index); S = Integer.parseInt(sString); // N identifier index = sub.indexOf("&N=") + 3; sub = sub.substring(index); index = sub.indexOf(">"); N = sub.substring(0, index); // number & cable index = sub.indexOf(">") + 1; sub = sub.substring(index); index = sub.indexOf("&nbsp"); channel = sub.substring(0, index); number = getNumber(channel); cable = getCableSelect(channel); // station name index = sub.indexOf(";") + 1; sub = sub.substring(index); index = sub.indexOf("<"); station = sub.substring(0,index); // add new Channel group.add(new Channel(number, cable, station, S, N)); index = sub.indexOf(CHANNEL_IDENTIFIER); // next }

In every iteration of this code, a Channel object is created which represents a

data structure to group the fields – number, cable, station, S, and N – for a particular

channel. The Channel object is then added to a ChannelGroup object, which is simply

a collection of Channel objects. When the looping has completed, the ChannelGroup

object will contain the entire channel lineup.

61

Channels Database

The channel lineup information, now in the ChannelGroup variable, must be

transferred to a permanent store since the ChannelGroup variable will only have a

lifetime as long as the program runs. We, however, need for the channel lineup to be

persistent so that it can be called up for every run of SmartGuide. This is why this

information must be stored in a database. A Microsoft Access database is used because of

its compatibility with Pocket Access on the Pocket PC. The structure of the Channels

database is shown in Figure 39.

Channels

groupID BITnumber INTEGERcable CHAR(10)station CHAR(10)S INTEGERN CHAR(10)

Figure 39 - Channels Database structure.

The number, cable, station, S, and N fields should be familiar variables at

this point; the groupID designates whether the user wants information for that particular

channel and will be explained in more detail later.

public final static String connectString = "Provider=Microsoft.Jet.OLEDB.4.0;" + // Access 2000 "Persist Security Info=False;" + // security "Data Source=Settings.mdb"; // database filename private void storeDatabase() { Connection connection = new Connection();

62

connection.open(connectString); storeChannels(connection); storeTimePeriods(connection); connection.close(); } private void storeChannels(Connection connection) { Recordset rs = new Recordset(); rs.open("Channels", // table name connection, // Connection object AdoEnums.CursorType.KEYSET, // cursor AdoEnums.LockType.OPTIMISTIC, // security AdoEnums.CommandType.TABLE); Database.clear(rs); // clears Channels table // store select channels for (int i=0; i < selectChannels.size(); i++) { Channel channel = selectChannels.get(i); rs.addNew(); rs.getField("groupID").setBoolean(true); rs.getField("number").setInt(channel.getNumber()); rs.getField("cable").setString( String.valueOf(channel.getCableSelect())); rs.getField("station").setString(channel.getStation()); rs.getField("S").setLong(channel.getS()); rs.getField("N").setString(channel.getN()); } rs.close(); }

Initially, a connection must be made to the database “Settings.mdb”. Next, a

recordset corresponding to the Channels table (inside of the Settings database) is opened

and each field is inserted into the table channel by channel. ADO (ActiveX Data

Objects), Microsoft’s newest high-level interface for accessing databases, is employed to

carry out the saving of the values from within the Java code. Once this is completed, the

data for the channel lineup are persistent and can be referred to at any point in the future.

63

5.3 SMARTGUIDE – TV SHOWS

Discovering the channel lineup for a service provider is only the preliminary task;

the real work of SmartGuide is in the downloading of TV show listings, which is shown

in Figure 40.

HTTPConnection

ChannelParser

TV ShowsDatabaseHTML TV Shows

(a) (b) (c) (d) (e)

ChannelsDatabase

(f)

TimePeriodDatabase

Figure 40 - SmartGuide Data Flow for TV Show downloading.

Through the SmartGuide GUI, users can set their preferences regarding the

channels they watch and the times during which they watch them. Out of the entire

channel lineup, users can select a group of channels for which they want information

downloaded; these channels will have their groupID field set in the Channels table. The

TimePeriod table similarly holds the user’s preferences regarding times of the day and

days of the week for which they want TV listings. SmartGuide uses these pieces of

information to customize the downloading.

For each channel in the Channels database with its groupID field set,

SmartGuide will connect to a page on the TV Guide Online site that is specific to that

channel. This page will list shows in a full 24-hour period for the one particular channel

(Figure 41). This single column of times differs from the regular page, which shows a

two-dimensional grid of both times and channels.

64

Figure 41 - TV Guide Online screen shot of channel-specific ("7A WHDH") listings

SmartGuide will connect to the page corresponding to a specific channel and day

and download the HTML source. The Channel Parser then parses the HTML and the

individual shows that fall into the user-defined time periods for that day are saved. The

Channel Parser then must take each show and jump to a show-specific page to gather the

show’s detailed information. Finally, all of this is stored into the TV Shows database.

65

HTTP Connection

In channel lineup retrieval, the HTTP connection depended on only one variable –

the cable Provider ID. When downloading TV listings, a lot more information is needed

in addition to the Provider ID. When connecting to the channel-specific listings, both the

channel and the day must be specified as well. When connecting to the show-specific

description, that show’s ID must be used.

It is evident that retrieving TV listings is much more complicated than retrieving

only channels. Numerous HTTP connections must be set up and torn down in this

process. First, there needs to be a connection for each channel and each day for which the

user wants information downloaded; the number of connections in this case is the product

of the number of channels and number of days. In addition, for each of these channel-day

connections, SmartGuide needs a connection to each show-specific details page that falls

in the time period specified by the user.

HTTP Connection (Channel-Specific)

The first HTTP connection to be made in the download process is the one to the

channel-specific page. SmartGuide must examine a channel-specific page for each

channel on each day that the user has selected. It first loops through the days, beginning

with the current day, and iterates for a number of days specified in the “Download

Amount” field of SmartGuide. For each day during iteration of the loop, SmartGuide will

check to see if it was selected for information retrieval. If it was, then an inner loop will

66

go through every selected channel. This process is described by the following

pseudocode.

for (day = current; day < current + downloadAmount; day++) { if (day is selected) { for each selected channel { parse channel-specific page; get all show information for that channel; } } }

Connecting to a channel-specific page is somewhat of a complicated process that

requires the formation of a URL containing encoded parameters. The URL for a channel-

specific page has the form:

“http://www.tvguide.com/listings/index.asp?view=chan&I=i&S=s&ST=st&N=n”

To come up with the correct page, SmartGuide needs to derive the correct values for i, s,

st, and n in the URL above. Deriving the values for three of the four are a trivial matter.

“&I” is simply the Provider ID which is learned before any of this process begins. The

“&S” and “&N” values are the S and N values associated with the channels, which were

found and saved during channel lineup retrieval. The last value “&ST” is associated with

the date and time of the channel-specific listings and is a more complicated value to

derive.

The algorithm was reverse-engineered from analyzing TV Guide Online’s website

and by examining a large sampling of channel-specific pages corresponding to different

times and dates. Recall that a channel-specific page for a specific time and date will have

all of its shows listed starting from that time and date for the next twenty-four hours. It

was discovered that for the March 27, 2001 page, the integer part of the ST value was

67

36977. Each day corresponds to one ST unit, such that one hour corresponds to 1/24

(0.0416666667) ST units. Therefore, the integer part of the ST value would correspond to

the day while the decimal part would correspond to the hour of that day. Similar tactics

will reveal that for 4:00 AM, the beginning of a day as defined in SmartGuide, the

decimal part of ST will be 0.375. And luckily discovered because implementation of the

ST-calculating algorithm was under way during a daylight savings switchover, the

decimal extension for 4:00 AM during the daylight savings part of the year is

0.3333333333. One now has enough information to calculate the ST value for any

desired date and time. The algorithm is shown below.

// ST base value for Tuesday 3/27/01 private final static double ST = 36977.0; // ST decimal extension for 4AM (non-daylight savings) private final static double EXT_4AM = 0.375; // ST decimal extension for 4AM (daylight savings) private final static double DLS_EXT_4AM = 0.3333333333; private static double calculateST(Calendar current) { double result = ST; // ST value associated w/ epoch // gets # of days since the epoch to current time // epoch = 3/27/01 4:00AM Calendar epoch = Time.getEpoch(); // adds this value to ST (1 day = 1 ST unit) result += TimePeriod.getDurationDays(epoch, current); TimeZone tz = TimeZone.getDefault(); // if current is in daylight savings time if (tz.inDaylightTime(current.getTime())) result += DLS_EXT_4AM; //add daylight savings ext. else result += EXT_4AM; // add regular extension return (result); }

68

First, the ST integer value for a particular date (March 27, 2001) that is well-

known is hard-coded into the algorithm and is used as the base ST value or epoch. Now,

for any date, the function calculateST() takes in a date and returns the ST value

corresponding to the start (4:00 AM) of that day. It first determines the number of days

between this input date and the epoch and adds this number to the base ST value. It then

checks to see if the date is a daylight savings date, and depending on the answer, will

append the correct decimal extension to the value.

Channel Parser (Channel-Specific)

Once the ST value is calculated, it can be combined with the values for I, S, and

N, which are already known, to get the desired channel-specific page. SmartGuide then

downloads the HTML for this page and breaks it up into chunks for each show so that

parsing is easier. Each chunk will have the form similar to the following.

<TR> <TH WIDTH='25%' ALIGN=CENTER BGCOLOR='#CCCCCC'>10:00 PM </TH> <TD WIDTH='75%' bgcolor='FFFFFF' ALIGN=LEFT>

<a style="color:#000000" href="javascript:cl(71086,3298016);" >

Dateline NBC </a></A> <FONT class='gvcr'style="color:#000000"> &nbsp;&nbsp;[27148] </FONT>

</TD> </TR>

The important values that should be parsed from each chunk are the show name

and the Q value, which is the unique ID for that show. The Q value in the example above

is 329016 and is given in the HTML segment “javascript:cl(71086,329016)”. Note that

this segment is the exact message that shows up in the status bar when users roll over a

69

particular show with their mouse (this is done when finding the Provider ID). The first

number, 71086, is the Provider ID and should be the same across all shows. The second

number’s significance, which was not apparent before, is the particular show’s Q value

and will be different for each show. The show name is found after the tag containing the

javascript reference and Q value and before the next tag. In the example above, the string

that SmartGuide will pull out is “Dateline NBC”.

HTTP Connection (Show-Specific)

The only useful pieces of information with respect to the PocketRemote user that

have been obtained at this point are the show name and its channel. One still does not

have any information such as time or description. This is where the Q value comes in; it

is used to form a URL that will lead to a page containing detailed information regarding a

particular TV show.

This URL has form “http://www.tvguide.com/listings/closerlook.asp?I=I&Q=q”.

The I parameter is simply the Provider ID, and the Q parameter is the Q value.

Channel Parser (Show-Specific)

After grabbing the HTML for the show-specific page (Figure 42), SmartGuide

can scrape it for the rest of the information needed for each TV show. This information

includes start and end time, title, duration, description, and category. Other information

such as names of cast members and rating were deemed unimportant and are ignored by

SmartGuide in order to save time and space.

70

Figure 42 - Show-Specific page.

Parsing is carried out on three different chunks. SmartGuide first analyzes the

main block, which contains the show name, title, and duration. Next, the description is

pulled out. And finally, the category is pulled out of the section lying between the line

separators in the page in Figure 42.

The parser searches for special HTML tags that denote the beginning of each of

these values. As in the previous examples, the HTML source for each of the show-

specific pages follows the same structure so that the parser can use the same algorithm in

picking out values from it.

71

TV Shows Database

Once all of the values are pulled from every single TV show for a download

session, the information is stored into the Shows table in the “SmartGuide.mdb”

database. The Shows table has a format shown in Figure 43.

Shows

PK showID INTEGER

showName CHAR(10)episodeTitle CHAR(10)description TEXT(10)category CHAR(10)startDate DATETIMEendDate DATETIMEchannelID INTEGER

Figure 43 - Shows Table.

This table contains all of the attributes for a TV show. Notice that it contains a

primary key, which is the Q value that serves as the show’s unique ID. This field is

required by every TV show entry and must be unique. The channelID field is a reference

back to the channel to which the show belongs.

5.4 POCKETREMOTE – USER INTERFACE

PocketRemote’s user interface consists of only five forms supplemented with

whatever remote control skins the user has. The forms were created in Visual Basic using

Basic’s graphic developing capabilities – forms and buttons can be created by dragging

and dropping objects onto a palette. The forms are as follows:

72

Main. The Main form is the main point of interaction between PocketRemote and

the user. This form displays the actual remote control and SmartGuide

views and provides access to all of the other forms.

About. The About form simply provides information about PocketRemote such as

program name, version, copyright, and legal messages.

RemotesOptions. The RemotesOptions form leads to the last two forms –

NewRemote and RenameRemote. All modifications made to the remote

controls are performed here.

NewRemote. The NewRemote form allows users to select a new skin and to

create a remote control from it.

RenameRemote. The RenameRemote form provides the single functionality of

letting users give a current remote control a different name.

While Visual Basic was the optimal programming language to use in creating the

forms and basic GUI components, it fell short in providing the power and flexibility of

C++. C++ was required to provide object-oriented capabilities in order to represent as

independent classes “remote controls”, “buttons”, “commands”, etc.

In order to allow C++ and Basic to work together, however, one needed a

common interface through which these two languages can communicate. This common

interface is the Component Object Model (COM) [16]. COM is a programming standard

that allows any software component, regardless of language or platform, to communicate

with any other software component. The only restriction on these components is that they

73

must follow the COM standard. Once subscribed to COM, these pieces of the software

puzzle will be connected and be able to communicate seamlessly with one another.

Any program written to the COM standard is well encapsulated; that is, no access

to its internal implementation is allowed. Access to functions and methods are provided

only through well-defined, COM interfaces. The interfaces come as either a required

“Iunknown” interface or user-defined interfaces. Programs using other COM objects

always refer to them through their interface pointers. The objects and interfaces need to

maintain the same identifier across all machines known as a GUID (globally unique

identifier) that is generated for each COM object.

5.5 POCKETREMOTE – INFRARED

Infrared is the fundamental component of PocketRemote, or any other remote

control for that matter. It is what allows communication to take place between a remote

control and the device which it is controlling.

Infrared light lies in the part of the electromagnetic spectrum located just below

the red portion of normal visible light; that is, it has a lower frequency and longer

wavelength than visible light. This means that infrared light is invisible to the human eye,

yet it has the same qualities as any other light source that allow it to encode information.

Just about all remote controls use infrared as their means of communication. An

infrared diode at the front of the remote control beams out an infrared signal whenever

the user presses a button, and an infrared receiver on the device will capture and process

the signal. This signal is sent by modulating, or quickly turning ON and OFF, the infrared

74

light. These ON and OFF combinations are used to represent binary code, which in turn,

can be used to specify commands for the receiving device.

The modulation of the IR signal is conducted at 40 KHz for most remote controls.

This specific frequency helps to distinguish the signal from noise and other nearby light

sources. There are three common ways in which binary data can be encoded into the

infrared.

Pulse-Width Modulation. Used by Sony remote controls, pulse-width modulation varies

the pulse to represent data (Figure 44). For example, if the pulse width is short (550

microseconds), then it corresponds to a logical "0". If the pulse width is long (2200

microseconds), then it corresponds to a logical "1" [22].

Figure 44 – Pulse-Width Modulation [22].

A burst pair is a pair of values that specify the number of cycles for which to turn

the infrared light ON and OFF. Sony, for example, represents a "1" by having the ON

period twice as long as the OFF period, and "0" by having them equal.

Because the modulation frequency is set at 40 KHz for the carrier, the period for

each cycle is its inverse, or 25 microseconds. To represent a "1", Sony uses a burst pair of

(48,24), which would turn the IR emitter on for 48×25=1200 microseconds and off for

75

24×25=600 microseconds. A burst pair of (24,24) is used for "0" – 600 microseconds of

light followed by 600 microseconds of no light [23] (Table 4).

Parameter Value

Carrier Frequency 40 KHz

Burst Time 25 cycles

Lead-In Burst (96, 24)

“1” Burst Pattern (48, 24)

“0” Burst Pattern (24, 24)

Lead-Out Burst (x, 1014)

Table 4 - IR encoding for Sony remote controls [23].

The lead-in burst serves as a sort of wake up burst, notifying the receiver to start

listening to the signals about to come. The lead-out burst signifies the end of the message

and usually has a long OFF time period to guarantee that two IR messages cannot be sent

too close together. In the case of Sony remote controls, there is no explicit lead-out burst;

instead, the OFF time on the last bit is simply increased.

Space-Coded Modulation. In space-coded modulation (REC-80), the pulse width is kept

constant, but the space in between pulses is made to vary (Figure 45). If this space

between the pulses is short (550 microseconds), it corresponds to a logical "0". If the

space is long (1650 microseconds), it corresponds to a logical "1" [22]. This encoding is

used by Panasonic remote controls.

76

Figure 45 - Space-Coded Modulation [22].

Shift-Coded Modulation. With shift-coded modulation, every bit has a constant time

period; it is the direction of the signal’s transition that designates the binary value (Figure

46). A falling signal - from ON to OFF - corresponds to a logical "0" while a rising signal

- OFF to ON - corresponds to a logical "1" [23].

Figure 46 - Shift-Coded Modulation [22].

In order to analyze the signals coming out from a remote control, a PC equipped

with an infrared receiver is used. The receiver is an Extended Systems XTNDAccess

IrDA PC Adapter that connects to the PC via its serial port.

PC

PDA

Remote Control Comparator

Figure 47 - Implementation and testing of IR learning process.

77

The main testing components used are a conventional remote control and a Pocket

PC PDA equipped with an infrared port. The Pocket PC needs to learn the commands

coming from the conventional remote control. There are two tests to be conducted using

the help of the PC and IR receiver, which capture and display the infrared signals. The

first test determines if the infrared signal being captured by the PDA is the same signal as

that being captured by the PC. The second test determines if the PDA sends out the same

signal that it was supposed to have captured. The schematic for both tests is shown in

Figure 47.

To run these tests, an application running on both the PDA and the PC to capture

and display the infrared signals is needed. The test applications are written in Visual

Basic for the PC and eMbedded Visual Basic for the Pocket PC and make use of the

COMM control. The COMM control is an ActiveX control that provides connection to a

serial (COM) port on the device. In the test programs, the COMM control represents the

IR port on the Pocket PC and the IR receiver connected to the PC; these IR transceivers

will be controlled by directly manipulating the COMM control in the program.

In addition to the COMM control, there is a text box to display the received IR

signal for both the PC and Pocket PC applications. On the Pocket PC, the main receive

function, Comm1_OnComm(), is automatically executed for every bit of data that is

received. When the first bit is received, the connection remains open, accepting all bits

that arrive during a specific period of time. All of these bits are then appended together in

the text box. The purpose of the timer is so that an entire command can be captured

instead of having the text box being refreshed for every bit of data. The timer is set to one

second – ample time for an entire command’s data to be captured. The following code is

78

the main function called on the Pocket PC when a bit of data is received through its

COMM port (IR port); similar code is found on the PC portion of the test program.

Private Sub Comm1_OnComm() Dim receiveData As String Dim result As String Select Case Comm1.CommEvent Case comEvReceive ' receive IR signal ' first CommEvent generated by a button press If (Not ButtonTimer.Enabled) Then ButtonTimer.Enabled = True ReceivedDataTextBox.Text = "" ' clear text box ' array of values receiveData = Comm1.Input ' join values to display as String result = Join(receiveData, " ") ' append new values to previous in text box AppendText (result) ' additional CommEvent's generated ElseIf (ButtonTimer.Enabled) Then ' array of values receiveData = Comm1.Input ' join values to display as String result = Join(receiveData, " ") ' append new values to previous in text box AppendText (result) End If End Select End Sub In test simulations, the first test failed in that the signal from the conventional

remote control did not seem to register in the same way on the PC as on the Pocket PC.

Different values appeared in the text boxes of each device, and while a few sequences of

0's and 1's were identical, the overall sequence was not. The problems arising from these

tests will be discussed in more depth in the Future Work section of the paper.

79

5.6 POCKETREMOTE – SMARTGUIDE

SmartGuide, running inside of PocketRemote, is responsible for displaying and

scrolling through the shows in the database such that information is easily obtainable by

the user. When PocketRemote is started, its first task is to load the entries of the Channels

Table and Shows Table into active memory from their database on disk. By storing all of

the data into the much faster memory, PocketRemote can avoid the slow accesses to disk

during execution of the program. This improves performance of the program at the cost

of a much longer startup time.

The channels are stored as Channel COM objects and the COM objects are in turn

stored into an array. The shows are likewise stored in Show COM objects, which are

stored into an array. COM objects are used to fulfill the object-oriented traits necessary

for the program; by using object-oriented properties, all of the attributes for a channel or

show can be organized under one “class” or COM object. Furthermore, each show object

contains the index into the Channels array that holds that show’s channel.

Once the database is loaded into the program’s local variables, SmartGuide

displays itself in either Simple View or Full View. The background for each view is

simply a bitmap image; the Simple View is displayed at the top of the screen on top of

the remote control skin while the Full View is an entirely separate form. After the

background image is displayed, the pertinent information (such as show name, time, and

channel) is laid on top of the image as plain text. Since all the locations of the buttons are

well known on the bitmap, the screen coordinates of a user’s click are sufficient for

SmartGuide to know what action to perform.

80

6 Results

The lengthiest and most complicated part of PocketRemote is SmartGuide and its

consequent HTTP connections, downloading, parsing, and handling of large databases.

For this reason, the “Results” section looks at the performance of these parts of the

program. All simulations were run on a Pentium III, 800 MHz PC equipped with 128 MB

of RAM and a 10 Mbps Ethernet connection.

The first task to be accomplished by SmartGuide is channel retrieval. Figure 48

shows how much time the process takes depending on the number of channels available

for a given provider.

Channel Retrieval Time

0

5

10

15

20

25

30

0 20 40 60

# of Channels

Tim

e (s

eco

nd

s)

Series1

Figure 48 - Channel Retrieval Time.

The resulting data are stored in the Channels Table, and the memory requirements

for an entry in the table is show in Table 5. The “Max Size” column denotes the

81

maximum number of bytes that each field can take. The “Avg Size” is the average of fifty

random sample entries.

Field Data Type Max Size (Bytes) Avg Size (Bytes)

channelID Long Integer 8 8

number Integer 4 4

cable Text (2) 2 × 2 = 4 2

station Text (10) 10 × 2 = 20 8.7

Total: 36 22.7

Table 5 - Size of entries in the Channels table.

After channel retrieval, SmartGuide can then proceed to download the actual TV

listings. This is by far the most time-consuming portion of the entire process. For each

day in the simulation, the time periods of 8:00 PM to 12:00 AM were selected and every

day of the week was selected. The download was conducted across eight randomly

selected channels (Figure 49).

TV Listings Download Time

0

10

20

30

40

50

60

70

0 5 10 15

# of Days

Tim

e (m

inu

tes)

Series1

Figure 49 - TV Listings Download Time.

82

Field Data Type Max Size (Bytes) Avg Size (Bytes)

showed Long Integer 8 8

showName Text (50) 50 × 2 = 100 29.6

episodeTitle Text (200) 200 × 2 = 400 15.5

description Memo 65,535 × 2 = 131,070 522.2

category Text (50) 50 × 2 = 100 30.4

startDate Date/Time 8 8

endDate Date/Time 8 8

channelID Long Integer 8 8

Total: 131,702 629.7

Table 6 - Size of entries in the Shows table.

Once the TV listings are downloaded, the information is stored in the Shows

Table. The memory requirements for the Shows Table entries are shown in Table 6.

ActiveSync Transfer Time

00.5

11.5

22.5

33.5

44.5

0 50 100 150 200

# of Show Table Entries

Tim

e (s

eco

nd

s)

Series1

Figure 50 - ActiveSync Transfer Time.

83

Once stored away in the database, the TV listings need to be transferred over to

the Pocket PC via ActiveSync. The time for ActiveSync to transfer the data (in terms of

number of show entries) is shown in Figure 50. The transfer time is very fast over

ActiveSync using a USB connection, which operates at 480 Mbps. The transfer is also

aided by the fact that Pocket Access databases have much less overhead than regular

Access databases, and so not as many bits need to be sent over.

PocketRemote also takes some time to process the database of TV shows when

starting up. The processing includes loading the shows from the database and into local

memory (arrays) for quicker access during program execution. This faster performance,

however, comes at the cost of a longer startup time. The startup time sampled over

several different sizes of databases is shown in Figure 51.

PocketRemote Startup Time

0

2

4

6

8

10

12

14

0 50 100 150 200

# of Show Table Entries

Tim

e (s

eco

nd

s)

Series1

Figure 51 - PocketRemote Startup Time.

84

7 Future Work

7.1 INFRARED

One needs to achieve full compatibility between the Pocket PC's infrared port and

the receivers of consumer electronic devices. There are many potential reasons for why

PocketRemote's infrared component is not compatible with consumer electronic devices

and the various possibilities need to be further investigated.

One possibility is that the standard used by Pocket PCs is not compatible with

consumer electronic devices. The infrared port on Pocket PCs is based on the IrDA

standard whereas consumer electronic devices simply use raw IR data. IrDA was created

to allow interoperability among all infrared devices and to enable data transfer among the

devices. The devices envisioned, however, only included PDAs, computers, laptops,

printers, cameras, and other similar technologies. It was not intended for remote control

applications dealing with products such as home theater equipment.

The incompatibility may also lie within the Pocket PC's hardware. The IR port on

a Pocket PC was designed to work within close range of another IrDA device. Data

transfer is usually carried out by setting up the two devices almost at the point of contact

and with their IR ports pointing towards each other. In order to reduce interference and

make data transfer more reliable, the infrared beam was designed to be very narrow (5

degrees) and the range very short (2 meters) on the Pocket PC. The power of the Pocket

85

PC's infrared signal may therefore be too weak to be able to control consumer electronic

devices.

The timing of the signal sampling is also a critical aspect to consider. In general,

IR equipment is pretty lenient and operates with a timing tolerance of +/-10 percent [23].

However, if the Pocket PC does not operate within this tolerance, then the entire

sampling and transmission will be corrupted.

7.2 TV GUIDE ONLINE

There are two serious limitations with the current method of TV listings retrieval.

First, HTTP connections, which depend on the network speed, are fairly slow. In

addition, the current method needs to perform repeated HTTP connections for each

channel, day, and show, and this can result in a very lengthy process. Second, the parsing

is completely dependent on the HTML source format, and when TV Guide decided to

change their website around sometime in early Fall of 2001, it broke down the entire

SmartGuide parsing algorithm.

Both of these problems can be solved with the same solution. If SmartGuide could

connect directly with TV Guide’s database or if TV Guide would provide some sort of

Web service, the download process could be streamlined by several factors. For this

solution, however, a business deal would need to be negotiated between PocketRemote

and TV Guide. This would take considerable time to work out, but is a step worth taking

in the future.

By providing a Web service, TV Guide would be able to provide access to their

database of TV shows. A Web service is an application running on one computer that

86

allows other computers to execute its methods over a network [11]. The protocols used

for such remote procedure calls would usually be a combination of XML and HTTP. The

data representing the TV shows would be represented in XML, an industry-standard

format use for representing and defining data. Using these standard protocols, TV Guide

can make certain APIs available for SmartGuide to call and to be able to access their

data.

7.3 BUSINESS PLAN

The eventual goal is to disperse PocketRemote among the general public and to

earn some revenue on each download. As with most applications designed for PDAs, the

executable file can be posted on a website like c|net (http://www.cnet.com/downloads).

By posting the program at a centralized location such as c|net, it is instantly made

available to the hundreds of thousands of people who already frequent the website in

search of new programs to download.

PocketRemote can be made available either as a demo or shareware. In the demo

version, a user can experiment with a limited version of the program before deciding

whether to actually purchase the full version. With shareware, the full version will be

made available but will be automatically disabled after a certain time period if the user

does not register for a certain fee. Both the demo and shareware methods allow users to

try out programs before paying any money for it.

The revenue potential from selling PocketRemote through these channels is very

great. OmniRemote, for example, netted 819 downloads in just one week (December 18-

25, 2001) on c|net; in all, it has 89,640 downloads since being posted November 17,

87

1998. OmniRemote is a good basis for comparison because it is a similar program for the

PDA. Using OmniRemote’s download statistics, however, is only a modest estimate for

PocketRemote downloads because PocketRemote, once finalized, will be a superior

product with more features and should get even more users’ attentions. PocketRemote

will be priced from $10-$20 (the registration fee for OmniRemote is $20); this would

yield very high profit, especially since the program was developed at minimal cost. Given

the success of OmniRemote and the large sales of both PDAs and universal remote

controls, it is safe to assume that there is great business potential for PocketRemote.

88

8 Conclusion

Conceptually, PocketRemote is superior to any other universal remote control

currently on the market, the major reason being that it provides the greatest level of

convenience for the user. The innovation lies in SmartGuide; no other remote control

provides an integrated TV listings viewer. The combination of SmartGuide and

PocketRemote represents the ultimate in TV-viewing convenience. And because flipping

through channels on the TV makes up the overwhelming majority of remote control use,

SmartGuide adds a useful service that caters to the largest need. Users can now find out

what they are watching without having to actually look it up; the information is right

there in PocketRemote and includes show name, channel, times, show description, and

more.

The design of SmartGuide allows for maximum convenience and performance by

respecting the limits and capabilities of the various resources available. This is why

downloading takes place on a PC rather than directly on the PDA. With current

technologies, Internet access on a PDA is still too slow, too expensive, and simply not

practical. Most people have Internet access from their PCs, however, and high-speed

connections are not uncommon. Using wired connections from PCs to download

SmartGuide data allows for a dramatic increase in efficiency, and the subsequent transfer

over ActiveSync (as seen in the results) is a relatively quick process. And if the entire

process can be made to occur when the user is asleep, the amount of the user’s time that

is consumed is practically nil.

89

Once the download and ActiveSync transfer are completed, all of the required

tools are located on the user’s PDA, which means that purchasing another device is not

necessary. Besides avoiding a messier situation by adding yet another remote control,

users will never have to part from their PDA; it will be available for them to perform

daily tasks while watching TV. Besides the convenience aspects, not having to buy

another device results in great savings in spending. All that needs to be purchased is the

PocketRemote software, which can be priced at a trivial amount. Users can download,

install, and use the program without ever having to leave the house.

Because PocketRemote meets the design goals of convenience and affordability,

it has the potential to take over the universal remote control market. Users can simply pay

a small fee and can then start using the program immediately; however, its use is

restricted to individuals owning PDAs. A symbiotic relationship between PocketRemote

and the PDA is expected – each one will boost the success of the other. In the end,

PocketRemote will hopefully boost the demand not only for PDAs but also for devices

that blend the functionality of multiple devices into one seamless product. One simple

device that does it all is the ultimate goal. Technology has been headed in that direction

for some time now, and PocketRemote is simply the next step in that path.

90

9 Appendix A - Skins

The following contains examples of remote control skin files including the regular

state image, the pressed state image, and the skin text file.

91

9.1 BASIC BLUE TV

Figure 52 - BasicBlueTVimage.bmp Figure 53 - BasicBlueTVimagealt.bmp

# PocketRemote Skin # skin name: Basic Blue TV # category: TV # Buttons # Name xleft xright ytop ybottom mute 3 47 36 64 sleep 53 97 36 64 power 166 218 33 67 one 5 45 88 127 two 55 94 88 127 three 105 144 88 127 four 5 45 133 172 five 55 94 133 172 six 105 144 133 172 seven 5 45 178 217 eight 55 94 178 217 nine 105 144 178 217 lastchan 3 47 228 256 zero 55 94 222 261 okay 103 146 228 256 chandn 164 223 230 258 chanup 164 223 186 214 voldn 164 223 135 163 volup 164 223 92 119

Figure 54 - BasicBlueTVskin.txt

92

9.2 BASIC BLUE VCR

Figure 55 - BasicBlueVCRimage.bmp Figure 56 - BasicBlueVCRimagealt.bmp

# PocketRemote Skin # skin name: Basic Blue VCR # category: VCR # Buttons # Name xleft xright ytop ybottom mute 3 47 36 64 tvvcr 53 97 36 64 power 166 218 33 67 eject 5 45 88 127 rewind 5 45 133 172 play 55 94 133 172 fforw 105 144 133 172 pause 5 45 178 217 stop 55 94 178 217 record 105 144 178 217 chandn 164 223 230 258 chanup 164 223 186 214 voldn 164 223 135 163 volup 164 223 92 119

Figure 57 - BasicBlueVCRskin.txt

93

9.3 PR VCR

Figure 58 - PRvcrImage.bmp Figure 59 - PRvcrImagealt.bmp

# skin name: PocketRemote VCR # category: VCR # Buttons # Name xleft xright ytop ybottom power 14 47 31 64 rec 56 93 84 121 epsp 94 128 84 121 disp 130 167 84 121 tvvcr 194 234 87 120 chanup 194 234 134 167 chandn 194 234 168 201 volup 194 234 201 234 voldn 194 234 235 268 stop 90 128 151 189 rewind 52 89 190 227 play 90 128 190 227 fforw 129 166 190 227 pause 90 128 228 265

Figure 60 - PRvcrSkin.txt

94

10 Appendix B – SmartGuide Source Code

Files Included:

- Channel.java

- ChannelGroup.java

- ChannelParser.java

- Database.java

- DownloadData.java

- HTMLParser.java

- Messages.java

- RegEdit.java

- SmartGuide.java

- Time.java

- TimePeriod.java

- TVShow.java

- VisualSG.java

95

11 Appendix C – PocketRemote Source Code

Files Included:

(Pocket Remote.ebp)

- About.ebf

- Main.ebf

- NewRemote.ebf

- RemoteOptions.ebf

- RenameRemote.ebf

- Database.bas

- Library.bas

- SmartGuide.bas Pocket Remote.cpp

(RemoteDLL.vcw)

- Button.cpp

- Button.h

- Remote.cpp

- Remote.h

- RemoteDLL.cpp

- RemoteDLL.def

- RemoteDLL.idl

- RemoteDLL.rc

- StdAfx.cpp

- StdAfx.h

- Resource.h

- Button.rgs

- Remote.rgs

96

12 References

[1] c|net News - http://news.cnet.com/news/0-1006-200-4601431.html?tag=prntfr

[2] Maximum PC, June 2001, “Palm vs. Pocket PC” [3] San Jose Mercury News, June 14, 2001, Section E, “handhelds: what’s missing” [4] GOMES, LEE. Wall Street Journal, April 26, 2001, Personal Technology,

“Manufacturers Sell Convenience With Universal Remote Control”. http://ptech.wsj.com/archive/ptech-20010426.html

[5] BEDELL, DOUG. The Dallas Morning News, September 26, 2001, Technology,

“Taking control: Those dadgum remotes prove a universal source of frustration”. http://www.dallasnews.com/technology/368835_remotes_17per.html [6] SCHWARTZ, BRUCE. USA Today, February 28, 2001, CyberSpeak, “The search for

the perfect remote control”. http://www.hifi-remote.com/ofa/USA-Today.shtml [7] ROSSIE, JOSEPHINE. Kiplinger’s, January 2001, “Total Control”. http://www.hifi-remote.com/ofa/kiplinger.shtml [8] LEE, JENNIFER. The New York Times, September 14, 2000, “The Ultimate Remote

Means Never Having To Leave the Couch”. http://www.hifi-remote.com/ofa/nytimes.shtml [9] GENOVESE, PETER. The Star Ledger, October 22, 2000, “The TV remote at mid-

life”. http://www.hifi-remote.com/ofa/star-ledger.shtml [10] SEMPERAPTUS STAFF. SemperAptus, June 1, 2000, “There’s a War Going on In Our

Pants! (the Palm OS vs. Pocket PC)”. http://www.semperaptus.com/reviews/r6100b.shtml

[11] DEITEL & DEITEL. C# How To Program. Prentice Hall: Upper Saddle River, New

Jersey, 2002. [12] MUENCH, CHRIS. The Windows CE Technology Tutorial: Windows Powered

Solutions for the Developer. Addison-Wesley: Boston, 2000.

97

[13] DONALD, B., OANCEA , G. Visual Basic 6 from Scratch. Que Corporation: Indianapolis, 1999.

[14] MICROSOFT CORPORATION. Microsoft Visual Basic 6.0 Programmer's Guide. Microsoft Press: Redmond, WA, 1998.

[15] ZARATIAN, B. Microsoft Visual C++ 6.0 Programmer's Guide. Microsoft Press:

Redmond, WA, 1998.

[16] SWANKE, J. COM Programming by Example: Using MFC, ActiveX, ATL, ADO and COM+. R&D Books: Lawrence, KS, 2000.

[17] MCGREGOR, R. Practical C++. Que Corporation: Indianapolis, 1999.

[18] MSDN Online, http://msdn.microsoft.com

[19] deVBuzz, http://www.devbuzz.com [20] Pocket PC, http://www.microsoft.com/mobile/pocketpc/default.asp [21] "Infra Red Remote Controls - How They Work",

http://www.ee.washington.edu/conselec/A95/projects/pierreg/works/works.htm

[22] "An analysis of IR signals used by a remote control", http://cgl.bu.edu/GC/shammi/ir/ [23] GORDON, BARRY. "Infra Red Signals - Pulse Width Method", http://www/hifi-remote.com/infrared/IR-PWM.shtml [24] Infrared Data Association (IrDA), http://www.irda.org/ [25] "Microsoft eVB COMM control on your Pocket PC using eMbedded Visual Basic" http://www.devbuzz.com/content/zinc_eVB_COMM_control_pg1.asp [26] BATISTA, ELISA. Wired News, October 12, 2001. “How Palm Became All Thumbs”. http://www.wired.com/news/business/0,1367,47474,00.html