Newton IrDA White Paper

This paper lists some of the specifics of the Newton IrDA subsystem, for those curious to see.

Hardware

The Newton MP2000, MP2100, and eMate all have IrDA-compatible infrared transceivers that are capable of sending and receiving data at up to 115 kBaud. This is known as SIR, or "Slow Infrared". More advanced IrDA-compatible devices can also send and receive data at up to 4 MBaud. This is known as FIR, or "Fast Infrared".

Fortunately, the IrDA standard requires that any device capable of FIR also be capable of SIR. This means that new devices coming out should be able to operate with the Newton; however, the possibility exists that some new not-quite-standard device might be introduced that could only communicate with the faster FIR. The Newton would not be able to communicate with this device.

Earlier Newton devices (OMP, MP100, MP110, MP120, and MP130) are all capable of infrared beaming; but their hardware and software is aligned around the Sharp ASK protocol, which is not compatible with IrDA. For compatibility, the later Newtons (MP2000, MP2100, and eMate) can also transmit and receive over Sharp ASK, but most non-Newton devices cannot (although there are still some devices out there that use Sharp ASK, none are IrDA-compliant).

Built-in Software

The MP2000, MP2100, and eMate have sufficient system-level software support to build IrDA IrLAP (Link Access Protocol, the most basic IrDA communication protocol) and IrDA IrLMP (Link Management Protocol, built on top of IrLAP) endpoints; but there are some problems with the implementation. This is an incomplete list:

The IAS (Information Access Service) support required by IrLMP is minimal and limited.
IAS in theory allows a server implementation to specify a number of provided IrDA services; each service is identified by a classname and an arbitrary set of attributes. Typically, every service includes at least one well-defined attribute that indicates the IrLMP connection address for that service. A client connecting to the server should be able to query for the list of services, and select the one most appropriate or capable.
The Newton IAS implementation allows a server to specify only one service, with a single classname and a single attribute. This works fine for a simple transport service, but makes more capable servers difficult.
Further, a Newton client is similarly limited; a client must know in advance the name and associated attribute of the service with which it will connect. It cannot query the list of available services (and hence cannot arrange to choose one from the list). Again, for a simple transport, this is no problem; but for more sophisticated clients, this can be a strong constraint.
The built-in software does not "packetize" received data correctly. The data stream is available, but it's not possible to distinguish where the beginning and ending of each packet lies - a crucial necessity for even Tiny TP, the most basic protocol built on top of IrLMP.
This means that higher-level protocols that cannot determine packet boundaries from the data stream itself will be difficult or impossible to implement.
Undocumented error codes and event codes can appear during the sending or receiving of IrDA data.
This can require considerable research to resolve, as there are very few resources available to the Newton IrDA programmer to decipher such codes.

For more information

Smart Dog home page (downloads and ordering)
Smart Dog BackTalk press release
Smart Dog BackTalk
Smart Dog BackTalk FAQ
Smart Dog BackTalk User Guide
List of supported devices

[an error occurred while processing this directive]
This page was last modified on April 24, 2001.