1996 CSUN Conference

There was an IRLINK-L meeting at CSUN conference on March 21.

Some highlights and notes from the meeting:

• Trace joined IRDA as a member and now gets the standard materials and listserve postings. It will try to pass on general information though it cannot repost the IRDA postings.

• IRDA uses a 7 level protocol. Documents for two levels were brought to the meeting. each doc was 100 pages long.

• Good news is that we do not need to operate much at most of the levels of IRDA. Most is either done as part of the standard device - or can be purchased as modules (hardware and software).

• IRDA is developing a Consumer Product group looking at longer range slower data transmission. Longer range than 3 feet. Slower than 115 K.

• We may find that we can use some of the consumer product work to address the problem of finding the device - ala talking signs.

• One thing that was suggested by some of the IRDA members was to tack a broadcast burst (so that people in the environment could find the Device) on the tail of each local data packet so that you can do broadcasting and local communicating simultaneously.

• It was noted that broadcasting may need to be done with a separat diode so that it can be high enough to broadcast when people or objects are in the way.

• We are setting up a new area on our web titled 'Designing an Accessible World' that will contain the KIOSK information and will include new NET FORUMs that will allow threaded discussions on different topics. One will be on the IR interface standard.

• According to discussions with IRDA, most of what we will need to implement link already exists in IRDA standard. A person could approach an irda device (which could be a computer, a printer, or a kiosk) and it will negotiate and establish a connection. All that we would need to have the assistive device control the kiosk would be to have the kiosk software look for input coming in on the computers IR link manager -- and then doing something with the input.

• There was a request that we build encription and security considerations in from the ground floor. It was recommended that we use DES. It was felt that we shouldnt leave this til later - since secure communication is important for so many types of communication.

• IRDA ports are now being built into most all laptop computers and many desktop computers, printers and other devices. For existing systems there are small dongles that are about the size of a half dollar that plug into or onto the serial ports on standard laptops and which add IR capability.

• Things are moving quickly and we need to develop an access standard pretty soon in order to get the components we need into the developing IR standards.

• a comment was made that perhaps we shouldnt move too quickly since things are changing. Maybe we should just wait for better IR link stds to appear.

• a counter comment was made that we need to move now since users need solutions now.

• it was noted that the work we need to do would ride on top of the IR standard and could work with future standards as well.

• One thing that would be implemented at the IR standard level would be asking for a dedicated bit in the bit string used in the initial capture routine. The bit would indicate that the device was Universal Disability IR Link compatible . This would just make it possible to identify compatible devices faster. (i.e. you could tell at the start of handshaking rather than having to wait till after you have established the link and carried out some communication)

The recorder didnt work for this meeting - so if anyone attending the meeting remembers other topics or items that are not listed here, please drop a note adding them.

Possible Steps from Here......

From the notes and current status it appears the best next steps should be:

1. Create a list of uses and data needs for IR use by different disabilities

2. Develop a first final format for communication protocol that would meet these needs.

3. Identify any dependencies on IrDA standards that might exist.

4. Look at whether encription can be laid in transparently (e.g. it can be laid in or out or changed to other formats without complicating or compromising the protocol)

5. Create functioning prototypes to test concept

6. Test prototype across disability and applications.

Please comment on these steps

lets see if this is what we should be doing

lets also start building the list of uses and data needs in step 1

Gregg

BACK to UDIRCL NOTES