Infrared, IR, Communications technology is used to link consumer equipment such as a remote control with a television since the late 1970’s. Over the years manufacturers have developed a multitude of digital communication protocols most commonly based on Amplitude Shift Keying, ASK, modulation. The introduction of new protocols differentiated communication schemes, im-proved robustness, and optimized data transmission capability. As IR communication protocols matured, companies developed competing IC solutions tailored to fit OEM remote controls, univer-sal remotes, and computer based hardware. However, specialized hardware solutions for mobile devices are conspicuously missing from this list… until now.
Flash forward to the era of mobile devices; the technology of IR communications has virtually remained unchanged. However, in living rooms around the world, an increasing number of televi-sion watchers are sidelining OEM remotes in favor of smartphones equipped with “IR Blasters”. A multitude of companies have remote control Apps that do much more than just change the televi-sion channel. Some Apps have features that suggest programming to users, signal users when favorite shows are about start, automatically change the channel, and present individualized adver-tising content. Sadly, these intriguing features will not continue to be available because manufac-turers simply can’t afford the monetary cost or the printed circuit board space using traditional IC solutions. Manufacturers are only willing to offer IR Blaster features if the IC costs less, is smaller, requires less power, drops in to the hardware architecture, and integrates seamlessly with the sys-tem software. Happily, ams has developed new hardware technology called IR-BeamTM which is tailor made solution to integrate IR communication in mobile device applications.
Existing IR Blaster integrated circuit solutions are no longer a good fit for mobile devices. This leaves cell phone and tablet manufacturers to weigh options and make tradeoffs. As with all con-sumer technology, the scale is tipped as semiconductor solutions become smaller, cheaper, and easier to integrate. The inclusion of IR remote control into mobile devices is no exception. Long standing IR solutions use dedicated/specialized 8/16-bit microprocessors, FPGAs or ASIC – none of which are well suited for mobile devices. Such solutions may be cost prohibitive, physically too large, unable to support certain IR protocols, difficult to integrate into system hardware, lack soft-ware drivers, or may simply consume too much power.
Despite being ill-suited, an FPGA with 4kB RAM along with discrete MOSFET driver and 940nm LED is the current solution of choice in smartphones. Operating as a FIFO, pattern data originating from the Application Processor, AP, is buffered, mixed with a carrier frequency, and output to an external IR LED circuit. IR communication using FPGAs are a well proven technology but many manufacturers are designing them out of mobile devices. Current FPGA technology has a mixture of advantages and disadvantages in mobile applications. Since the FPGA is re-configurable, HDL code can be quickly written and debugged reducing time to market. Furthermore, FPGA manufac-turers offer reference designs to assist OEM in development. Package size can be as small: ≥7 mm2, however larger footprints are more common1. Disadvantages include high monetary cost and high static power consumption ( ≥75uA). Additionally, OEMs would have to design and maintain an additional HDL codebase.
Note 1: Smartphones which use an FPGA for remote control pattern generation may also incorporate other functions and features, resulting in the need for a more powerful FPGA and larger footprint.
For decades small 8-bit/16-bit microprocessors have been used in handheld remote control devices and have significant advantages in mobile device applications. They are relatively inexpen-sive, and perform well. Code optimization and sleep/wake feature reduces power consumption which increases battery life. A non-volatile memory may be employed to store many protocols to suit a large number equipment manufacturers. Additionally, both the processor firmware and the non-volatile memory may be reprogrammed to further improve user experience. However, a micro-processor is not an ideal choice for mobile devices. Typically, microprocessor based solutions are physically large: >15 mm2 , require additional codebase, and could be expensive. Furthermore, mobile devices already incorporate at least one processor, the AP, which is capable of IR pattern generation.
Interestingly, many mobile device manufacturers employ a two processor scheme. The Appli-cation processor, AP, typically has 1 to 2 GB of RAM, 1 to 2 GHz clock, and multiple cores runs an OS, user applications. The second processor, called a Hub, is a small 8/16-bit low power device that is used to process data from peripherals such as a proximity detector, Ambient Light Sensor (ALS), accelerometer, or barcode emulation. This scheme is used to conserve battery power while offloading sensor specific tasks from the AP. Current hub technology is typically capable to generate IR remote control patterns; however, mobile device manufacturers don’t utilize the hub for this purpose. The hub has a rudimentary operating system that services “always-on” devices and sensors. Therein lies the problem; remote control requires all of the processing power during a transmission. In addition, from a software point of view, remote control transmission algorithm is not compatible with current hub technology employing an OS with a scheduler.
If an FPGA is combined with a microprocessor the result would be an Application Specific Integrated Circuit, ASIC. From a physical layer point of view, an ASIC has all the advantages of FPGAs and microprocessors combined into one device. The device is highly optimized, resulting in few unused circuits, static power consumption is low, package size is variable (≤ 36 mm2 ), and operation is tailored for high performance. Also, the OEM is not responsible to develop or manage HDL or firmware. ASICs have some significant disadvantages as a remote control solution in mobile devices. First off, as the name implies, they are “Application Specific”; which invariably results in a long development cycle which delays the time to market. ASICs can also be an expensive solution depending on the volume of devices sold.
An Application Processor could surely generate and output remote control patterns on a dedi-cated pin. A Serial Peripheral Interface, SPI, pin such as MOSI is an ideal choice to drive an exter-nal LED driver circuit. Advantages of using the AP are obvious: no additional hardware cost, no additional power consumption, easy software updates, and any pattern can be easily be generated. Additionally, if the MISO pin is connected to a specialized IR photodiode circuit, then a learning function can implemented to record the IR signal from an OEM remote control. The disadvantage of using the AP is less obvious, yet pose significant challenges.
The problem actually has more to do with the operating system and software architecture than with hardware. Currently, kernels have evolved to juggle processes on multi-core processors. Be-sides scheduling process execution, it balances core utilization, adjusts AP power management, handles interrupts, etc. The question becomes, how can a pattern be generated with exact timing, output on a particular pin while using a non-real time OS? One way would be to halt all processes and utilize 100% of the AP for pattern generation. Obviously, this solution is unacceptable. How-ever, refining this idea so that the pattern is generated in one core, leaving the three remaining cores to continue normal operation, seems much more reasonable.
The issue with this approach is that the OS would have to be built such that at any instant, a user “button push” event must cause a designated core’s processes be transferred to the other cores, then an RTOS or routine would run to generate the electrical waveform on a dedicated pin. From a hardware point of view, this sounds like a great solution, from the software side many chal-lenges exist. The scope of the project includes: modification of the OS and kernel, design of the stand-alone pattern generation routine, creating a comprehensive scheme to transfer processes between cores and adjust power management. Then custom software must be created to glue the OS pieces together and provide at least one method of interface to the application layer. The oldest and most common interface is Consumer.IR; however, new interfaces exist which improve and augment functionality.
New IR pattern generation technology from ams is designed to avoid problems when traditional solutions are paired with cutting edge mobile devices. The two most difficult challenges to overcome are physical size and cost of the remote control pattern generator. Additional PCB space eliminated adding IR remote control functionality to an essential existing IC. Smartphones use an optical sensor module to detect ear-to-phone proximity and ambient light, ALS. The addition of IR remote to an IR optical device is a natural fit, and does not increase package size (10mm2 or less). Optical devices are typically mounted atop the phone with a flexible PCB along with other components such as earphone jack, indicator LEDs, and the forward-facing IR LED. Connection from the pattern generator to the IR LED driver is simple and may even help to reduce the size or number of attendant system components. As the component count falls, and the level of integration rises, the monetary cost is reduced to pennies.
Power is conserved in two ways: removal of a stand-alone IC eliminates current consumption when the remote control pattern generator is idle. The sleep or idle current consumed by the re-mote control enabled optical device remains at the same level as similar optical devices without the remote control option. Additionally the duty cycle of the carrier frequency is adjustable and can be set as low at 25%. This is useful because peak current consumption occurs during IR transmission as the LED is modulated.
Typically, the optical sensor communicates with a hub via I2 C. This hub-AP archi-tecture is popular because a low power hub can reduce the processing burden from the AP, and also allow the AP to enter a lower power “sleep” mode on occasion. Following this concept, the optical device offloads pattern generation and timing tasks from the hub preventing delays in hub operation. The hub need only bridge a 50 to 300 byte data set to the optical sensor a single time. After this, the pattern generator will handle all transmission. The remote control engine in the opti-cal device does not require any software development further accelerating time-to-market. From a monetary perspective, the addition of a remote control blaster in to a mobile device may cost just pennies, made possible by combining digital pattern generation technology with advanced optical analog technology.
IR remote control has been and continues to be the most popular communication solution for consumer equipment. While the development of new protocols has slowed, innovation of new inexpensive and robust transmission solutions is still alive and well. Integration of pattern generation functionality into small, IR based optical devices marks the latest milestone in IR remote control enabled mobile devices.
More articles like this