Abstract:
A method of electronically registering student attendance data includes storing a plurality of student names in a central collection station. The stored student names are downloaded and stored to at least one portable data collection device. The portable data collection device is used to access the set of student names stored therein and one select student name from the set of student names is displayed on a visual display of the portable data collection device. The portable collection device prompts an operator thereof to input attendance data for the select displayed student name into the portable data collection device. The operator input attendance data includes one of a first input indicating that the student having the select displayed name is present, a second input indicating that the student having the select displayed name is absent, and a third input indicating that the student having the select displayed name is tardy. The input attendance data for each select student name is stored in the portable collection device and the foregoing is repeated for each student name in the downloaded set of student names. The input student attendance data is then uploaded from the portable data collection device to the central data collection station and stored in said central data collection station. A student attendance report is generated using the attendance data stored in the central data collection station.

Description:
BACKGROUND OF THE INVENTION 
     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 &#34;optical mark reader&#34; 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 &#34;optical mark reader&#34; system suffers from the inherent deficiency of &#34;paper bound&#34; 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. 
     SUMMARY OF THE INVENTION 
     Accordingly, the present invention provides a data collection system particularly suitable for use as an &#34;electronic attendance register&#34; system, comprising one or more portable computer devices, forming a mobile data collection means, each including data transceiving means and an attendance data collection program, and a central data collecting station comprising a further computer including at least one data transceiving means and a data collation programmed for assembling data transmitted from the individual portable computer device. 
     Preferably, the central data collection station comprises a network of wireless transceivers distributed over the area of the premises which are connected to a central computer. 
     Preferably, the transceivers of the central data collection station are radio devices, but alternatively, other methods of data communication, such as modem links or broad band networks may be utilized. 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 program 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 &#34;\&#34;, &#34;φ&#34;, &#34;L&#34; may be used to indicate that the pupil is present, absent or late respectively and two key strokes, such as a letter code plus &#34;enter&#34;, 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 portable computer device is arranged to transmit it to the central computer collection station, 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 &#34;personal computer&#34; type software such as spread sheets, calculator, or memo writing. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     One embodiment of the invention will now be described by way of example, with reference to the accompanying drawings, in which: 
     FIG. 1 is a diagrammatic illustration of a number of portable computer devices in accordance with the invention; 
     FIG. 2 is a schematic illustration data of a central collection station for receiving data transmitted from the individual portable computer devices; and, 
     FIG. 3 is a flow chart depicting a method of electronically registering student attendance data in accordance with the present invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Referring to FIG. 1 through 3, each of the portable computer devices 2 comprises a &#34;palm top&#34; or &#34;lap top&#34; computer 4 which is preferably incorporated in a robust A4 size computer folder. Each portable computer device 2 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 portable computer 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 portable computer device 2 communicates with a central data collection station 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 portable device 2, will be transmitted to the central data collection station at the school office. 
     As illustrated diagrammatically in FIG. 2, the central data collection station will typically comprise a standard &#34;desk top&#34; personal computer (PC) 12, arranged as a multi-tasking server, which is connected to a radio transceiver unit, or &#34;RTU&#34;, 14, and also having a printer 16 for producing &#34;hard copies&#34; of attendance reports. 
     Accordingly, the central PC 12 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 &#34;network&#34; by means of which information can be exchanged, as &#34;electronic mail&#34;, and the portable computer devices 2 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 portable computer 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 the central data collection station includes a plurality of transceivers (&#34;RTUs&#34;) 14, and these are connected to the central PC 12 by RS-485 serial links. Each RTU 14 comprises a license exempt RF transmitter/receiver module, microprocessor based control circuitry, and an RS-485 interface for communication with the central PC 12, as explained below. 
     Folder to RTU Transmission 
     Each RTU 14 generates periodic FREE slots which can be used by a portable computer device to initiate a transmission. The RTU 14 checks for &#34;Data Carrier&#34; before the FREE signal is transmitted in order to avoid collision with another ongoing transmission. When the portable device 2 detects a FREE signal it waits for a short period of random length and checks for a &#34;Data Carrier&#34; signal, in order to determine whether another portable device 2 or RTU 14 is already transmitting, and if not, it transmits a &#34;Request to Send&#34; command. 
     A CLEAR to SEND command transmitted from the RTU 14 to the portable device 2 indicates that the arbitration has been won, otherwise the portable device 2 waits for the next FREE signal to retry (see below). When the portable device 2 receives CLEAR to SEND command, it then transmits its actual command/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 portable device 2 expects a reply and/or data block from the central PC 12 in response to its request, it will wait for a maximum of 20 seconds. If nothing is received from the RTU 14 which received and acknowledged the request after 20 seconds, the portable device 2 considers the transmission as failed and it repeats the arbitration cycle. If the portable device 2 requests a lengthy transfer from the central PC 12, such as form/class list transmission, and a transmission error is detected, the portable device 2 requests the retransmission of only the failed blocks. 
     If the portable device 2 transmits additional data and it fails to get the ACKNOWLEDGE within 5 seconds, it transmits a FAILED to GET LAST ACK message to the RTU 14 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 portable device 2 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 14 may get corrupted even if the data transmission from the portable device 2 goes through correctly. In this case, the retransmission of the ACKNOWLEDGE will be much quicker than repeating the whole cycle. 
     If an existing &#34;Data Carrier&#34; signal is detected the portable device 2 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 14 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 portable devices 2 in the zone of each RTU 14. 
     The RF communication between the portable devices 2 and RTUs 14 follows a special protocol referred to hereinafter as &#34;EARS&#34; and utilizes an EARS command block (&#34;ECB&#34;) structure described below which, amongst other information includes the origin of the transaction. Whenever appropriate, this information is used by the central PC 12 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 portable devices 2 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 portable device 2 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 portable device 2. 
     RTU to Folder Transmission 
     RTUs 14 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 portable devices 2 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 &#34;banned&#34; portable device ids, indication of the presence of electronic mail/pager message, list of activities prohibited during peak loadings of the EARS network etc. 
     RTU to portable devices 2 transmission takes place by replacing the FREE signal with other commands, usually in response to the requests/commands received from portable devices 2. 
     After transmitting the FREE signal, the RTU will wait for a pre-specified time for replies from portable devices 2. To start the arbitration cycle, the first command from a portable device 2 will be REQUEST to TRANSMIT. If more than one portable device 2 request is received, the RTU 14 acknowledges the first one by transmitting a CLEAR to SEND command, specifically addressed to the relevant device 2 portable device 2. The RTU then allows only 1 second for the command/request to be transmitted from the portable device 2. The assumption is that the portable device 2 will have finished all the necessary preparations before queuing up for transmission, therefore having been given the &#34;go-ahead&#34; it will be able to transmit its request immediately. This approach helps to minimise unnecessary delays on the EARS RF protocol. One the RTU 14 receives a request from a portable device 2, all following transmissions will be addressed to the specific portable device 2 until the cycle is completed. 
     Having transmitted the CLEAR to SEND and receiving the command/request, the RTU 14 then ACKNOWLEDGES the reception, which serves to put the requester on a wait while the request is being dealt with. The RTU 14 then transmits the request to the central PC 12 via the RS-485 link and resumes the transmission or the FREE signals. It is possible for the RTU 14 to buffer as much as 5 portable device requests while the central PC 12 is still acting on the first one. Once the central PC 12 finishes processing the request, the reply is transmitted back to the RTU 14 on the RS-485, with all the original address information still intact. The RTU 14 the uses this information to transmit the reply/back to the relevant portable device 2 in the next FREE signal slot. If the reply is a short one, i.e. it does not contain additional data, the RTU 14 only waits 2 seconds for an ACKNOWLEDGE, and does not insist on having one. However, if the response has additional data attached, the RTU 14 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 device 2. If the ACKNOWLEDGE is not received after a further wait of 5 seconds, the RTU 14 gives up and starts the transmission of the FREE signals. In that case the portable 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 portable device 2 the RTU 14 does not carry out any initiating activities, rather, it assumes that the device 2 is waiting to receive the reply for the request/command previously submitted. 
     When the central PC 12 replies to a request from a portable device 2, it is able to extract the Zone information from the incoming ECB and direct the reply accordingly. A dedicated ECB command issued by the central PC 12, tells all RTUs 14 to HALT the FREE signal while, at the same time, transferring the reply data to the RTU 14 serving the ZONE where the request originates from. At the next periodic occurrence of the FREE signal, this RTU 14 then transmits the appropriate ECB to transfer the data to the requesting portable device 2. The RTU 14 then immediately reports to the central PC 12 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 14 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 portable device 2 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 14 enable the central PC 12 to efficiently service the requests originating from the portable device 2. ECB&#39;s coming from the Folders will be optionally time stamped when initiated so that the central PC 12 can prioritise the replies to minimise the delays. This proves useful especially for large installations. 
     The central PC 12 communicates with the RTUs 14 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 14 at the same time. However, transfer of data between RTUs and the central PC 12 is done on polling bases. When polling the RTUs 14, incoming data is transferred to the central PC 12 immediately. However, if data is requested from the central PC 12, the response may be immediate or queued depending on the type of request. portable devices 2 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 central PC 12, and the relevant RTU 14 is instructed to send an ACKnowledge back to the portable device 2 at the next FREE slot, while the other RTUs 14 are HALTed. 
     Radio Frequency Protocol 
     All communications between the portable device 2 and its closest RTU 14 are under the control of a set protocol (the &#34;EARS&#34; protocol). This has been designed to allow as many portable devices 2 as possible to use the RTU 14 at one time, but still allow a fast data transfer when required. The RTU 14 at all times is considered to be in control of the channel and it makes `slots` available to the portable device 2 by transmitting a `free-pulse` (invitation to transmit) at regular intervals to which the portable devices 2 can respond to if they wish to transmit. If the RTU 14 wishes to transmit data to a portable device 2 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 portable devices 2 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 Command Blocks--ECBs, which have the following structure: 
     
         ______________________________________Bytes              Contents______________________________________0-1                lead bytes2                  command byte3-5                destination6-8                origin9                  block number10-11              length12                 checksum______________________________________ 
    
     Lead Bytes 
     `&gt;-` indicates portable device to RTU transmission 
     `&lt;-` indicates RTU to portable device transmission 
     `&gt;+` indicates RTU to central PC transmission 
     `&lt;+` indicates central PC to RTU transmission 
     Command Byte 
     RTU to portable device 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 portable device to start transmission 
     39h Configuration Page--School specific configuration page 
     3Bh Version Incompatibility--requesting portable device is running incompatible or incorrectly configured version of the EARS Software 
     Folder to RTU Commands 
     21h Logon Request--portable device requests user authorisation and form/class list 
     22h Attendance List--portable device transmits the attendance list 
     23h Request to Transmit--portable device requests permission to transmit 
     24h Retransmit Block--portable device requests retransmission of specified block(s) 
     26h Request Config Page--portable device requests configuration page 
     Common Commands 
     34h Acknowledge--RTU acknowledges successful reception of last portable device transmission 
     36h Checksum Block--checksum table for the previous data block 
     37h Failed Acknowledge--RTU indicates to the portable device 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=portable device 
     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. In accordance with the protocol, an EARS device (RTU 14 or portable device 2) 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 14 the next retry will happen at the periodic FREE Signal Slot. The portable device 2 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 14 fails to start transmission due to ongoing transmissions; it reports RF LOCKED OUT status to the central PC 12. After the third consecutive failed transmission, the central PC 12 commands the RTU 14 to shift its FREE Signal slot by a small amount, and the process repeats until the RTU 14 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 concatenated 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        Portable Device Action______________________________________&lt;free pulse&gt;             &lt;request to transmit&gt;&lt;Ok to transmit&gt;             &lt;data block&gt;&lt;acknowledge OK&gt;______________________________________ 
    
     2. A data block that is 512 bytes in length and has one byte corrupted in the first block: 
     
         ______________________________________RTU Action         Portable Device Action______________________________________&lt;free pulse&gt;              &lt;request to transmit&gt;&lt;OK to transmit&gt;              &lt;data block 0&gt;              &lt;checksums block&gt;&lt;retransmit block 0&gt;              &lt;data block 0&gt;              (. . . and so on)______________________________________ 
    
     3. Two portable devices each trying to transmit a data block, of less than 128 bytes in length: 
     
         ______________________________________RTU Action     Portable Device Action______________________________________&lt;free pulse&gt;          &lt;Portable Device-1:request to transmit&gt;          &lt;Portable Device-2:request to transmit&gt;&lt;OK to transmit PortableDevice-1&gt;          &lt;Portable Device-1:data block&gt;&lt;acknowledge OK&gt;&lt;free pulse&gt;          &lt;Portable Device-2:request to transmit&gt;&lt;OK to transmit PortableDevice-2&gt;          &lt;Portable Device-2:data block&gt;&lt;acknowledge OK&gt;______________________________________ 
    
     RTU to Server Protocol 
     There is also a need for a protocol for all the RTU devices 14 to send all their data to the central PC 12 as they all are connected to the same serial data bus, and they also have to be sure that the central PC 12 is ready to receive the data, and likewise the central PC 12 has to be aware of any problems the RTU 14 might be having. This protocol however is simpler than that of the portable device as the serial data cable is very reliable and no sophisticated error checking needs to take place. In this case the central PC 12 is in charge of the channel, polling each RTU 14 in turn, asking if it has any data/commands to transmit to the central PC 12, if the answer is yes, the central PC 12 receives the data otherwise it passes onto the next RTU 14, and repeats the question. However if the RTU fails to respond, it is flagged onto the central PC 12 display screen, and this can be used to trace failed units for maintenance purposes. For purposes of speed, if the central PC 12 has any data it wishes to transmit to the RTU 14, it doesn&#39;t wait until the cycle of polling is complete, but will transmit to the RTU 14 at any time. 
     Example: 
     
         ______________________________________Central PC Action    RTU Action______________________________________&lt;poll RTU 1&gt;                &lt;no data&gt;&lt;poll RTU 2&gt;                &lt;no data&gt;&lt;poll RTU 3&gt;                &lt;logon request&gt;&lt;poll RTU 4&gt;                &lt;no data&gt;&lt;Xmit pupil list to RTU 3&gt;______________________________________