Speed issues between ObSys and Compass

To help you understand timing issues between the third-party system and ObSys and Compass, we have compiled the most frequently asked questions.

If a Compass Network is used in preference to OSMs, is this going to result in a slower interface?

The perceived problem is: If an OSM is used, the only delay incurred is between ObSys and the third-party system. If a Compass Driver is used you will have a delay between ObSys and the COL Compass Point, a delay between the Compass Points on the Compass Network, and a delay between the Compass Point and the third-party system. Surely as the message is passed in three stages as opposed to one the resulting delay is considerably greater?

There are a few reasons why this is not the case - primarily, baud rates, request queuing and design for purpose.

What is meant by baud rate?

A baud rate is the speed at which data can be sent digitally and is measured in bits per second (bps). The longer the message length is, the longer it will be in bits and therefore the fewer messages can be sent per second.

The majority of systems communicate at a baud rate of 9600bps. Some can go twice this speed (19200 aka 19k2), and frequently we will come across systems that communicate at the slower speeds of 4800, 2400, or 1200 baud (this is especially true of older systems). On the other hand, the Compass Network has a baud rate of 156 kbaud - that is more than 8 times faster than 19200 baud, and therefore 16 times faster than 9600.

What is meant by multiple request queuing ?

A Compass Point without lid. The Compass Network also has the facility of multiple request queuing - whilst the Compass Point is waiting for the reply to it's first request, it already has the next request lined up and ready to transmit. Instead of each request being dealt with after the previous one has been completed, several requests are sent to the Compass Network and placed in a queue. As soon as a reply is received by the Compass Point from the third-party system, the next request is sent to the system whilst the reply is being sent back via the Compass Network. Therefore, if you have more than one request for information the delay does not get compounded.

What is meant by design for purpose?

The other issue is that of design for purpose. Compass Points and the Compass Network, both hardware and software, were designed by North specifically to communicate with various systems and for data sharing. Therefore, we were able to dedicate more processor power to communications. A PC, although powerful, is not a dedicated system. It performs other tasks (redrawing the screen and monitoring the mouse are two tiny examples) and we can not allocate it's processor time as we would like.

For these reasons, there is negligible difference between the two methods. If you require clarification, or have any feedback on this topic please contact our support team for further information.


e-Library

e-Library reference book For the complete reference guide to all North products. Visit the North e-Library

Training courses

mortar board North offer a range of training courses for each of our product ranges. learn more..