This invention relates to data logging systems, and in particular, to systems for logging or registering items of data related to persons or articles. It is particularly, although not exclusively, adapted for use as a classroom roll-taking system, for recording the presence or absence of pupils or students, their test results and other such data.

Various alternative methods of automating the collection of attendance data in schools have previously been proposed, including systems in which pupils are issued with cards which must be inserted in card readers to record attendance, and systems in which specially prepared forms are completed in the classroom, and subsequently inserted into a "optical mark reader" at a central point, to transfer the information into the schools information system.

Both of these systems have specific weaknesses, and in particular, the card reader system is open to abuse by pupils who give their cards to others to make registrations for them, while the "optical mark reader" system suffers from the inherent deficiency of "paper bound" systems, since it requires the completed forms to be physically transferred from the classroom to the school office, wasting staff time and also, of course, giving rise to pupil supervision problems if the teachers themselves are required to deliver the collected data.

Accordingly, the present invention provides a data collection system particularly suitable for use as an "electronic attendance register" system, comprising one or more portable computer devices, forming a mobile data collection means, each including data transceiving means and an attendance data collection programme, and a central data

collecting station comprising a further computer including at least one data transceiving means and a data collation programme for assembling data transmitted from the individual collection stations.

Preferably, the central data collection means comprises a network of wireless transceivers distributed over the area of the premises which are connected to a central computer.

Preferably, the transceivers are radio devices, but alternatively, other methods of data communication, such as modem links or broad band networks may be utilised. For example, data could be transmitted via the schools internal telephone network, but it will be appreciated that radio links have the advantage that the apparatus can be made completely portable, without any temporary or permanent connections being required, to fixed apparatus installed in the premises.

Preferably, the programme of the portable computer is adapted to present the name of each pupil in turn, so as to prompt the teacher to respond appropriately, in accordance with a predetermined number of options, to enable an appropriate record to be made for that pupil. For example, a single key stroke such as "\", "β", "L" may be used to indicate that the pupil is present, absent or late respectively and two key strokes, such as a letter code plus "enter", may be used to indicate other circumstances, so as to minimise the time and number of key strokes required for each roll call.

In use, when all the attendance"data has- been collected, the unit is arranged to transmit it to the central computer collection point, and preferably, a known communication protocol will be used to establish that the data has been properly received in uncorrupted form.

In addition, the individual portable computers may

also be provided with further software for storing pupils performance records, and other general purpose "personal computer" type software such as spread sheets, calculator, or memo writing.

One embodiment of the invention will now be described by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a diagrammatic illustration of a number of portable computer devices in accordance with the invention; and

Figure 2 is a schematic illustration of a central computer installation for receiving data transmitted from the individual portable computer devices.

Referring to Figure 1, each of the portable devices 2 comprises a "palm top" or "lap top" computer 4 which is preferably incorporated in a robust A4 size computer folder and is referred to below as "C-folder". It preferably includes a small display screen 6, such as a multi-line LCD display, a keyboard 8, and a transceiver unit 10 which may, for example, operate on a suitable UHF/VHF band. In the preferred embodiment the transceiver is a license exempt compliant RF transmitter/receiver module.

A suitable number of these devices will be provided, so that each teacher can carry one, and in use, the teacher starts the operator by entering security code (PIN- Personal Identity Number) and class designation. The C-folder communicates with central system and down loads the list from the central system. In order to complete the register, the name of each pupil in the class is presented in turn on the display 6, and the teacher will indicate, in response to the name, whether that pupil is present. When the operation has been completed in respect of all pupils on the list held in the device, a signal including all the assembled attendance information, preferably with an

identifier characteristic of that particular "station", will be transmitted to the central system at the school office.

As illustrated diagrammatically in Figure 2 , the central system will typically comprise a standard "desk top" personal computer (PC) 12, arranged as a multi-tasking server, which is connected to a radio transceiver unit, or "RTU", 14, and also having a printer 16 for producing "hard copies" of attendance reports.

Accordingly, the central PC will be able to automatically record the attendance of all pupils, once the input from each class has been received, and suitable reports, in accordance with class or other desired parameters, can then be generated in conventional fashion.

It will also be appreciated that the system as illustrated provides the basis of a "network" by means of which information can be exchanged, as "electronic mail", and the portable units can also be enhanced by the addition of further software for keeping pupil performance records, for spread sheet manipulation, calculator operations, memo writing or word processing. Because the individual units carried by the teachers are completely portable, and require no external connections, a considerable saving may be made in terms of staff time in particular, since the necessity for teachers to make frequent trips to the school office to deliver or collect information, can be avoided.

The operation of the system will now be described in more detail. In practice a plurality of transceivers ("RTUs") 14 will generally be required, and these are connected to the central server by RS-485 serial links. Each transceiver comprises a license exempt RF transmitter/receiver module, microprocessor based control circuitry, and an RS-485 interface for communication with the central server, as explained below.

Folder to RTU Transmission

Each RTU generates periodic FRΞE slots which can be used by a C-Folder to initiate a transmission. The RTU checks for "Data Carrier" before the FRΣΞ signal is transmitted in order to avoid collision vith another ongoing transmission. When the C-Folder detects a FREE signal it waits for a short period of random length and checks for a "Data Carrier" signal, in order to determine whether another C-Folder or RTU is already transmitting, and if not, it transmits a "Request to Send" command.

A CLEAR to SEND command transnitted from the RTU t the Folder indicates that the arbitration has been won, otherwise the Folder waits for the next FREE signal to retry (see below) . When the Folder receives CLEAR to SEND command, it then transmits its actual cαnmand/data request and waits for an ACKNOWLEDGE. If the ACKNOWLEDGE comes within 5 seconds the cycle is completed, otherwise the transmission is considered to have failed and the arbitration cycle is repeated.

If the Folder expects a reply and/or data block from the server in response to its request, it will wait for a maximum of 20 seconds. If nothing is received from the RTU which received and acknowledged the request after 20 seconds, the Folder considers the transmission as failed and it repeats the arbitration cycle. If the Folder requests a lengthy transfer from the server, such as form/class list transmission, and a transmission error is detected, the Folder requests the retransmission of orly the failed blocks.

If the Folder transmits additional data attached to its ECB and it fails to get the ACKNOWLEDGE within 5 seconds, it transmits a FAILED to GET LIST ACK message to the RTU and waits for a further 5 seconds. If the

ACKNOWLEDGE is still not received at the end of the second wait, the transmission is considered failed and the Folder repeats the arbitration cycle. The purpose of this second wait is to minimise the repeat of lengthy transmissions like form/class list and attendance list transfers. It is possible that the acknowledge from the RTU may get corrupted even if the data transmission from the Folder goes through correctly. In this case, the retransmission of the ACKNOWLEDGE will be much quicker than repeating the whole cycle.

If an existing "Data Carrier" signal is detected the C-Folder will wait for a further, shorter random length period before retrying, and the process will be repeated until the wait period is reduced to zero length so as to give priority to the longest waiting C-Folders.

The frequency of the FREE signals is configurable for each site, and is determined by the duration of the longest possible RTU C-Folder transmission and maximum number of RANDOM slots. These two factors are also configurable with the first being dependent on the Registration Group sizes for the site, and the latter being determined by the concentration of C-Folders in the zone of each RTU.

The RF communication between the C-Folders and RTUs follows a special command block ("ECB") structure described below which, amongst other information includes the origin of the transaction. Whenever appropriate, this information is used by the Server to decide which zone the reply is sent to when transmitting data to a C-Folder.

Only one active C-Folder transmission per RTU is allowed at one time. However it is possible for C-Folders in different zones to initiate RF transmission simultaneously, provided that there is an adequate distance between them so that they do not detect each others Data

Carrier. Furthermore, the frequency of the FREE signals is adjusted in such a way that if the first C-Folder which got through in the beginning of the FREE slot only does a short transmission, there is a sufficient time left for a second short transmission by a re-trying C-Folder.

RTU to Folder Transmission

RTUs play the role of network access controller in the EARS RF Protocol. The periodically generated FREE Signals form the bases of access control for all devices waiting to start RF transmission.

As the FREE Signal follows the ECB structure, it is possible to transmit embedded information to other EARS devices. This includes transmission of a list of "banned" folder ids, indication of the presence of electronic mail/pager message, list of activities prohibited during peak loadings of the EARS network etc.

RTU to Folder transmission takes place by replacing the FREE signal with other commands, usually in response to the requests/commands received from Folders.

After transmitting the FREE signal, the RTU will wait for a pre-specified time for replies from Folders. To start the arbitration cycle, the first command from a Folder will be REQUEST to TRANSMIT. If more than one Folder request is received, the RTU acknowledges the first one by transmitting a CLEAR to SEND command, specifically addressed to the relevant Folder. The RTU then allows only 1 second for the command/request to be transmitted from the Folder. The assumption is that the Folder will have finished all the necessary preparations before queuing up for transmission, therefore having been given the "go-ahead" it will be able to transmit its request immediately. This approach helps to minimise unnecessary delays on the EARS RF protocol. One

the RTU receives a request from a Folder, all following transmissions will be addressed to the specific Folder until the cycle is completed.

Having transmitted the CLEAR to SEND and receiving the command/request, the RTU then ACKNOWLEDGES the reception, which serves to put the requester on a wait while the request is being dealt with. The RTU then transmits the request to the Server via the RS-485 link and resumes the transmission or the FREE signals. It is possible for the RTU to buffer as much as 5 Folder requests while the Server is still acting on the first one. Once the Server finishes processing the request, the reply is transmitted back to the RTU on the RS-485, with all the original address information still intact. The RTU the uses this information to transmit the reply/back to the relevant Folder in the next FREE signal slot. If the reply is a short one, i.e. it does not contain additional data, the RTU only waits 2 seconds for an ACKNOWLEDGE, and does not insist on having one. However, if the response has additional data attached, the RTU will wait for the ACKNOWLEDGE for up to 5 seconds, and if not received will transmit a FAILED TO GET LAST ACK message to the requesting Folder. If the ACKNOWLEDGE is not received after a further wait of 5 seconds, the RTU gives up and starts the transmission of the FREE signals. In that case the Folder has to go through the arbitration cycle if it wants to request the data block again. When a reply is being transmitted back to a folder the RTU does not carry out any initiating activities, rather, it assumes that the Folder is waiting to receive the reply for the request/command previously submitted.

When the Server replies to a request from a C- Folder, it is able to extract the Zone information from the incoming ECB and direct the reply accordingly. A dedicated ECB command issued by the Server, tells all RTUs to HALT the

FREE signal while, at the same time, transferring the reply data to the RTU serving the ZONE where the request originates from. At the next periodic occurrence of the FREE signal, this RTU then transmits the appropriate ECB to transfer the data to the requesting folder, as shown in Figure 3. The RTU then immediately reports to the server which then RELEASES the RTUs to proceed with the transmission of the FREE signal. The RELEASE command also is used as a means of synchronising the internal timer of the RTUs to generate the periodic FREE signal.

Since the FREE signal conforms to the ECB structure, it is possible to transmit control commands embedded into the ECB. For example, certain C-Folders may be prohibited from transmission, or non-urgent activities may be suspended at peak times of the network.

RTU Server Communication

By handling the RF transmission load locally, RTUs enable the server to efficiently service the requests originating from the C-Folder. ECB's coming from the Folders will be optionally time stamped when initiated so that the Server can prioritise the replies to minimise the delays. This proves 'useful especially for large installations.

The server communicates with the RTUs via a RS-485 link at 19.2 Kbps. This is a single-driver/multi-receiver protocol which allows commands to be sent to all RTUs at the same time. However, transfer of data between RTUs and the server is done on polling bases. When polling the RTUs, incoming data is transferred to the server immediately. However, if data is requested from the server, the response may be immediate or queued depending on the type of request. C-Folders generate three types of requests, as listed below.

1. Request confirmation of a list

2. Requests a list/message

3. Return a marked list/message

Reply to Type 1 request can be either an immediate CONFIRMation if the list has not changed or a queued UPDATE if the list has changed. Reply to Type 2 is always queued. In the case of Type 3 request, the list is immediately transferred from the RTU to the server, and the relevant RTU is instructed to send an ACKnowledge back to the Folder at the next FREE slot, while the other RTUs are HALTed.

Radio Frequency Protocol

All communications between the C-Folder and its closest RTU are under the control of a set protocol (the "EARS" protocol) . This has been designed to allow as many C-Folders as possible to use the RTU at one time, but still allow a fast data transfer when required. The RTU at all times is considered to be in control of the channel and it makes 'slots' available to the C-Folder by transmitting a •free-pulse' (invitation to transmit) at regular intervals to which the C-Folders can respond to if they wish to transmit. If the RTU wishes to transmit data to a C-Folder in its range, it does so by substituting a data packet for the free pulse.

Data is protected by two mechanisms, the first is with a simple checksum system where each block is checksummed on transmission and receipt, and if there is a difference the block is re-transmitted. Also all data blocks above 128 bytes in length are split into effective blocks, and these blocks are checksummed individually and these checksums are transmitted after the block, so that if part of the transmission is corrupted, only a small amount has to be re-transmitted.

The EARS RF Communication Protocol is based on the Slotted Aloha principle utilising a non-persistent Carrier Sense Multiple Access (CSMA) mechanism.

In the EARS adaptation of this protocol, all RF communication is controlled by the FREE signals periodically generated by the RTUs. These signals are used as an indication to Folders that the RTUs are ready to receive commands or data requests.

EARS Control Block (ECB)

All RF communication takes places in a structural format controlled with EARS Conμmand Blocks - ECBs, which have the following structure:

Bytes Contents

0-1 lead bytes

2 command byte

3-5 destination

6-8 origin 9 block number

10-11 length

12 checksum

Lead Bytes

'>-' indicates Folder to RTU transmission

'<-' indicates RTU to Folder transmission

•>+' indicates RTU to Data Server transmission

•<+' indicates Data Server to RTU transmission

Command Byte ^{• •••}

RTU to Folder commands

30h Free Signal - issued by RTU to indicate free status

31h Pupil List - RTU transmits the requested form/class list

32h Authorisation Failure - invalid or unauthorised PIN

33h Invalid Form - requested FORM does not exist

35h Clear to Transmit - RTU indicates to a specific Folder to start transmission 39h Configuration Page - School specific configuration page 3Bh Version Incompatibility - requesting Folder is running incompatible or incorrectly configured version of the

EARS Software

Folder to RTU Commands

21h Logon Request - Folder requests user authorisation and form/class list 22h Attendance List - Folder transmits the attendance list 23h Request to Transmit - Folder requests permission to transmit 24h Retransmit Block - Folder requests retransmission of specified block(s) 26h Request Config Page - Folder requests configuration page

coTMTion Commands

34h Acknowledge - RTU acknowledges successful reception of last folder transmission 36h Checksum Block - checksum table for the previous data block 37h Failed Acknowledge - RTU indicates to the Folder that last ACKNOWLEDGE was not received

Designation: indicates who the command blocks is designated to.

Xnn : where x is the device designator nn : is the ASCII coded hexadecimal device number R = RTU F = Folder P = Data Server S = Repeater

Origin: Indicates the originator of the command in the same format as the Destination

Block Number: Indicates Block Number in multi-block re¬ transmission

Length: Length of the ECB + attached data block.

Certain commands will carry additional data attached to the end of the ECB length of which is added to this field.

Checksum: Checksum byte for the ECB contents only. If additional data is attached, separate checksum bytes will be included within the data structure.

Carrier Sense Multiple Access Mechanism

EARS RF Communication Protocol uses a non- persistent carrier sense mechanism to allow multiple RF transmissions to take place without interfering with each other. An EARS device (RTU or Folder) wishing to start RF transmission, first checks for the presence of another ongoing transmission. If none is detected the device immediately starts transmitting. If the device detects ongoing transmission, it gives up its turn and tries in the next slot, hence the non-persistency. For the RTUs the next retry will happen at the periodic FREE Signal Slot. The Folder will retry next time it receives a FREE Signal from an RTU. This non-persistent mechanism prevents retrying devices from causing a pile-up effect.

If an RTU fails to start transmission due to ongoing transmissions, it reports RF LOCKED OUT status to the Data Server. After the third consecutive failed transmission, the server commands the RTU to shift its FREE Signal slot by a small amount, and the process repeats until the RTU finds an empty transmission slot. Following diagrams show the carrier sense and retry process.

Multi-Block Data Transmission

Data transfers on the EARS RF protocol are structured in 128 byte blocks to help with recovering from transmission errors. Each data block carries all necessary information such as length, block number and checksum to enable independent error checking during the transmission. It is also possible for the receiving end to ask for a block checksum table to be transmitted, which is used when multiple block errors are detected.

If a large data stream, which will require multiple blocks is to be transferred, the transmitting end will prepare the necessary number of 128 byte blocks. These blocks will then be concatanated and transmitted in one go. Since the blocks maintain their individual identity within the data stream, the receiving end will be able to isolate the corrupted blocks in case of a transmission failure. It is then possible to request re-transmission of only the failed blocks, which will be inserted into their correct position in the data stream. This method provides the best possible transfer rate. Since it does not include the overload of individual send/acknowledge cycles, or the need to re-transmit the whole data stream in case of a single error.

The operation of the protocol is illustrated below by means of examples:

1. A data block of under 128 bytes in length that transmits correctly. RTU Action C-Folder Action

<free pulse>

<request to transmit> <Ok to transmit>

<data block> <acknowledge OK>

2. A data block that is 512 bytes in length and has one byte corrupted in the first block:

RTU Action C-Folder Action

<free pulse>

<request to transmit>

<OK to transmit>

<data block 0> <checksums block>

<retransmit block 0>

<data block 0>

(... and so on) 3. Two folders each trying to transmit a data block, of less than 128 bytes in length: RTU Action C-Folder Action

<free pulse>

<C-Folder-l:request to transmit>

<C-Folder-2:request to transmit> <0K to transmit C-Folder-l>

<C-Folder-l:data block> ocknowledge 0K> <free pulse>

<C-Folder-2:request to transmit> <0K to transmit C-Folder-2>

<C-Folder-2:data block> ocknowledge OK> RTU to server protocol

There is also a need for a protocol for all the RTU devices to send all their data to the server as they all are connected to the same serial data bus, and they also have to be sure that the server is ready to receive the data, and likewise the server has to be aware of any problems the RTU might be having. This protocol however is simpler than that of the C-Folder as the serial data cable is very reliable and no sophisticated error checking needs

to take place. In this case the server is in charge of the channel, polling each RTU in turn, asking if it has any data/commands to transmit to the server, if the answer is yes, the server receives the data otherwise it passes onto the next RTU, and repeats the question. However if the RTU fails to respond, it is flagged onto the server display screen, and this can be used to trace failed units for maintenance purposes. For purposes of speed, if the server has any data it wishes to transmit to the RTU, it doesn't wait until the cycle of polling is complete, but will transmit to the RTU at any time. Example:

Server Action RTU Action

<poll RTU 1>

<no data> <poll RTU 2>

<no data> <poll RTU 3>

<logon request> <poll RTU 4>

<no data> <Xmit pupil list to RTU 3>