Bristol Wearable Computing

[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]


Pinger Design

Introduction

This page describes the design of a device which enables the Wearable Computer to receive information about it's location. Originally this was intended to supplement the GPS positional data e.g.within buildings, however the concept has been extended to become an event generator enabling communication to be established with a web server associated with a location.

The pinger event concept is capable of being further extended, for example:

Design

The requirement for a simple cost effective solution without the need to submit the design for DTI approval, restricts the options to modules operating at 173MHz or 418/433MHz. The higher frequency requires a smaller aerial (16cm whip or 20mm helical); has a shorter range (50m in buildings); and provides higher data rates (up to 9,600bps) making it more suitable for our needs. 458MHz modules are also available, however these are designed for longer ranges and are considerably more expensive.   

The off-the-shelf pinger design supplied as part of the Radiometrix Evaluation kit allows for eight address bits and four data bits to be transmitted in each ping.  This is sufficient to provide for 16 unique pinger locations.  Whilst this is adequate for trial purposes we envisage the potential for extensive use of such devices (see above).  For example in our Shopping Jacket application every chain of shops wishing to gain the attention of a Wearable Computer requires a unique identifier i.e. an IP address. We thus require to be able to transmit a short string of bytes containing the four bytes of an IP address; a pinger type identifier byte; and a checksum byte. (Alternatively, if we wanted to identify every room in an office building we would, again, require considerably more than 16 pingers).

To achieve this a Microchip PIC16F84 micro-controller has been chosen and programmed to produce a string of nibbles representing the bytes described above.  The nibbles are coded along with an identifier byte using a Holtek HT12E, and transmitted using a Radiometrix  TXM-418A low power, licence exempt, UHF radio telemetry transmitter module. Though the transmitter module has a 10kbps bandwidth, the HT12E encoder converts each nibble into a 24 bit word which is transmitted four times resulting in a much reduced effective bandwidth. The coder clock frequency is approximately 4kHz resulting in a minimum transmission time of 140ms for each nibble to ensure reliable reception.

The transmitted signal is represented in the diagram below:

pingtime.gif (3387 bytes)

The circuit diagram for the Pinger is shown below and this works in conjunction with the receiver described for the parallel interface.

pinger.gif (6104 bytes)

The 'receiver' is programmed to search for a ping once every second. On detecting a ping the scanning rate is increased to once every 50ms until the header byte is found (or for 10 seconds). The nibbles are then read, and the checksum calculated. If the checksum nibbles match the calculated value, the IP Address and pinger Type are treated as a valid ping by the Pinger Event Module and the scanning rate returns to once per second. 

Performance

The design described receives and decodes IP addresses within five seconds of coming into the range of a pinger. The aerial choice has a significant effect on the range. The combination of a whip(tx) and a helical(rx) provides consistent results; two helicals suffer from 'blackspots'; and in the extreme, poorly wound, badly placed, helicals will only operate when they are very close.

Tests have given satisfactory results within large rooms e.g. 1.15 MVB, and between adjacent areas e.g. from inside the building to the pavement outside. 

The reliability of the system is also greatly affected by the scanning rate once the presence of a ping has been detected i.e. when searching for a valid header. If the signal is sampled at twice the 'nibble' rate approximately 50% of the readings are not validated (though it is usually the checksum that is incorrectly read!). At three times the nibble rate the header nibble is decoded earlier and the whole packet correctly read consistently.   

Further Development

The current design is limited by the HT12 codec. This runs at a comparatively low clock frequency and has a considerable amount of redundancy (more than 100 bits required to transmit one nibble). Holtec also manufacture eighteen bit devices - the HT640 series - capable of operating with clock frequencies of over 100kHz and transmitting one byte of data on top of a ten bit address code. Clearly a larger amount of data could be sent using these codecs, and thus open up the possibility of remotely pinging GPS position or even short messages - a location based pager (you arrive at work and immediately receive a ping to let you know that an important meeting has been organised at short notice and you should go straight to it).     

A more ambitious development would be to use transceivers. The wearable computer would search for pings of interest by transmitting to the pingers requesting data. Any pinger with data matching the request would respond. An ethernet-like design with MAC addresses could be adopted to deal with the collisions which would inevitably result (possibly a big problem with the simpler designs described above). The wearable computer would become a wearable network! (n.b. this configuration is already under development as the Bluetooth project*).

cnr 9/08/99


* Project Bluetooth, the current short-range communications standard on which the computer and communications industries have settled, uses 100 milliwatts (about a tenth of a watt) to transmit one million bits per second (1 Mbps) a distance of about 30 feet.

unicrest.gif (4191 bytes)

The material displayed is provided 'as is' and is subject to use restrictions.
For problems or questions regarding this web contact Cliff Randell.
Last updated: January 14, 2000.
logoep.gif (1404 bytes)
ęCopyright Hewlett-Packard 1997-2000.