pocketremote: integrating a universal remote control with...
Post on 15-Mar-2021
2 Views
Preview:
TRANSCRIPT
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 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(" "); 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"> [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
top related