What data will I need to calculate data bandwidth consumption to poll punches on a biometric F-Series HandPunch?

Since most installations of hand geometry readers are not set up to poll punches continuously, the network administrator will need to calculate data bandwidth consumption using speed of transfer and size of user data. There are several F-SDK commands in the Hand Geometry Unit Technical Manual (revision 2.9) that could be used to poll punches from a F-series HandPunch.

In many applications, there is a large number of units on a network, and the host PC is performing real-time polling of these units to gather status information and make decisions. It is important when designing such systems to consider the maximum data throughput that may be achieved. For example, a single status poll command using SendStatusCRC requires 8 bytes for the command and 11 bytes for the response. At 9600 baud, this limits the polling rate to 52.6 polls per second, assuming no communications delays and no response delays.

In practice, it will be difficult to achieve this rate because of slight processing delays in the unit and in the application program. A very efficient application program can achieve a poll rate up to approximately 48 polls per second at 9600 baud. Downloading datalogs requires 8 bytes for the command and 26 bytes for the response. This implies a maximum transfer rate of about 29 per second at 9600 baud, although again processing delays may reduce this slightly. User data can be uploaded and downloaded in two ways. Transferring an entire bank of user data, 4096 bytes, using the SendDataBank command, requires about 4.1 seconds.

If user records are transferred one at a time using the HereIsUserRecord and SendUserRecord commands, in addition to the communication time, there is a database search time that must be considered as the unit searches its database using a linear search. The communications time for the HereIsUserRecord command is about 35 milliseconds, which implies a rate of 28 records per second if the database is empty. However, this drops to about 5 per second if there are 8000 records in the database. On average, each user record adds roughly 25 microseconds to the search time on the Model F units, and about 37 microseconds on Model E units. All commands which require database searching will experience this delay. This includes HereIsUserRecord, SendUserRecord, RemoveUserRecord, and VerifyOnInternalData.

PLEASE SEE NOTES FOR ADDITIONAL INFORMATION


DISCLAIMER:

INFORMATION PROVIDED THROUGH THIS SITE IS PROVIDED TO YOU AS IS WITHOUT ANY EXPRESS REPRESENTATIONS OR WARRANTIES OF ANY KIND, AND WE MAKE NO REPRESENTATION OR WARRANTY THAT THIS SITE(OR ANY INFORMATION PROVIDED IN RESPONSE TO YOUR INQUIRY), WILL BE ACCURATE, COMPLETE, OR ERROR-FREE.

YOU AGREE THAT YOU MUST EVALUATE ALL INFORMATION AND RESPONSES, AND THAT YOU BEAR ALL RISKS ASSOCIATED WITH, THE USE OF THIS SITE, INCLUDING ANY RELIANCE ON THE ACCURACY,COMPLETENESS, OR USEFULNESS OF ANY INFORMATION OR MATERIALS MADE AVAILABLE THROUGH THIS SITE.