Professional Documents
Culture Documents
1
Contents
2
Introduction & Reference
2.0 Introduction
The purpose of this document is to define the High Level protocol that is used by the V4, V45, V48
and V4 ASN series of metal detectors. It defines how a host should interact with the metal detector,
as well as the data that the host has access to.
The metal detector communications protocol is split into two parts High Level, and Low Level. The
High level handles the Metal detector specific messages, whereas the Low Level handles the
transmission of the data across a communications link.
The purpose of this document is to define the High Level communications to enough degree to enable
a third party to write interface applications.
It is intended that this protocol will be run over a number of interfaces including asynchronous
(RS232/422) and Ethernet. It shall not only allow feedback of all pertinent information including
important event alerts (e.g. metal detected), but also allow remote control and setup of the metal
detector.
3.0 Reference
Related Documents:
Low Level Comms Protocol Specification
3
Functional Overview
4
Functional Overview
Figure 1 – Overview
Master Slave
(Controller) (Metal Detector)
Data
High Level High Level
Comms Comms
Virtual
Connection
Data Data
5
Functional Overview
Note: All field sizes stipulated in this document are of the transmitted data so if 12 (decimal) is ASCII
encoded meaning the size would be 2 bytes.
As can be seen from the table above, char values 0x00 to 0x7F are identical to the single char
representation so numbers (decimal and hexadecimal) are unaffected as well as the most commonly
used chars.
e.g. the French word hôtel (ô = 0xF0 => 0xC3 0xB4) would be transmitted as
h ô t e l
0x68 0xC3 0xB4 0x74 0x65 0x6C
6
Functional Overview
Any attributes and services no longer in their respective lists should be disabled in the application for that class.
Note: An attribute can be added or disabled but not replaced. If an attribute needs to be replaced, the existing attribute
2c will be disabled creating a gap in the attribute numbers and its replacement will be added to the end of the class.
E.g. if attribute 2 is replaced in a class containing 3 attributes (1,2,3) its new Attribute list would be “1,3,4”. A “Get
Attribute All” would actually only get attributes 1,3,4 ignoring the invalid attribute.
When using a “Set Attribute All” service the User should be aware that in the example where attribute 2 is disabled,
and replaced by attribute 4, only set values should be specified for the current (not disabled) attributes. Using the same
example again, to “Set Attribute All” of the class containing active attributes 1,3,4 the User would:
<Set All Attributes>:<Class No>:<Instance Id>:<Attribute No>:<Attribute Val(1)>:<Attribute Val(3)>:<Attribute Val(4)>
Note the ordering of the attribute values, and the omission of attribute value 2.
Communicate
3 Communication can continue as before, as long as the restrictions listed above are observed e.g. invalid data must not
be used or errors shall be generated.
16
Functional Overview
17
Functional Overview
18
Class 1: Current Status
Table 9
23