Download tele - De Montfort University

CSCI 3426 15 credit module -- Telematics
August 2012
1 INTRODUCTION
A short introduction to why we need telemetry can be found here. It is recommended as background
reading.
2 CANBUS
We will start our discussion of wired telematic systems by an in-depth analysis of CANBUS (Controlled
Area Network). CANBUS was originally developed by Bosch, for use in vehicles; it has now been
adopted by a wide range of vehicle manufacturers and is widely used in industry.
ISO 11898 – ‘Road Vehicles – Interchange of Digital Information’ is now a definitive standard for layer 1
of the CAN protocol. SAE J1939, from the Society of Automotive Engineers overlays a MAC and LLC
protocol for use with CAN, and goes on to define a complete 7 layer model that we will explore in depth.
A number of microprocessors include a CAN interface as standard. One example is the CC03 from
Atmel. Their data sheet has a reasonable description of CAN, and is worth reading. See CC03
Another family of CAN devices are produced by Microchip. The data sheet for the device used in the labs
can be found here http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en531089
Look up the CAN section
2.1 Physical Layer
The electrical standard defines two wires CAN-HIGH and CAN-LOW. These two lines have a nominal
voltage of 2.5V when they are in the ‘recessive’ state; that is the voltage difference between CAN-HIGH
and CAN-LOW is zero. In the ‘dominant’ state CAN-HIGH rises to a nominal 3.5V, and CAN-LOW falls
to a nominal 1.5V.
The recessive state represents a logic level 1, and the dominant state represents a logic level 0.
If two ECUs (Electronic Control Units) attempt to pull the CAN cables to a 1 and 0 simultaneously then
the ECU offering the dominant state will win. Thus a 0 will defeat a 1. The value of this will be seen
when we examine the MAC protocol layer.
Each data bit is split into 4 fields known as
SYNC
PROPOGATION SEGMENT
PHASE SEGMENT 1
PHASE SEGMENT 2
SYNC SEG
This part of the bit time is used to synchronise the various ECUs on the bus. An edge is expected within
this bit segment.
PROP SEG
This part of the bit time is used to compensate for the physical delay times within the network. These
delay times are caused by the propagation time of the bus line and the internal delay time of the ECUs.
PHASE SEG1, PHASE SEG2
These Phase-Buffer-Segments are used to compensate for phase-errors and can be lengthened or
shortened by resynchronization.
SAMPLE-POINT
The Sample-Point is the point of time at which the bus level is read and interpreted as the value of that
respective bit. Its location is at the end of PHASE_SEG1.
When initialising a CAN device the programmer is required to set the length of each of these phases.
For example. Assume that we are using a 6MHz system clock, how do we set up our CAN device to
transmit data at a rate of 250kHz?
First we have to divide down our system clock to give as a System Clock. With experience you will be
able to determine suitable system clocks, in this instance 2MHz will work very well. So we set our CAN
Baud Rate Divider to 2 – WHY TWO?? Because it is usual procedure that the CAN controller adds 1 to
all division ratios, so a divider of 2 actually divides by 3.
Our System Clock will be 6/3 = 2MHz
To obtain 250kHz we need to divide this down by 8
2MHz/8 = 250Khz
To achieve this we need to partition up the 8 available bits between the 4 segments that make up a data
bit. The SYNC segment always takes up 1 system clock, leaving 7 bits. A rough rule of thumb is to split
the remaining bits across the remaining phases. If we allow 3 system clocks for the PROP PHASE and 2
system clocks each for each of the PHASE segments our system will work OK. To achieve this we will
programme up our PROP PHASE divisor to be 2, and our PROP PHASE divisors (1 and 2) to be 1.
So our partition will be
SYNC 1 system clock
PROP 3 system clocks
PHASE ONE 2 system clocks
PHASE TWO 2 system clocks
Making a total of 8 system clocks per data bit.
2.2 Medium Access Control (MAC) Layer Protocol
In order to understand the MAC protocol we must consider the Link Level Control (LLC) as well.
An LLC frame consists of a header and a data section. The header can be either 2 bytes long for CAN A
systems, and 4 bytes long for CAN B systems.
CAN A defines 11 bits for the address, one bit as the response bit, and 4 bits to define the length of the
data section. The bit total is 16 bits, spread over two bytes. The first byte transmitted contains the upper 8
bits of the address, sent most significant bit first. The second byte transmitted sends the lower 3 bits of the
address first, most significant bit first; then it sends the response bit followed by the data length (MSB
first).
Bit
15
Add
10
Bit
14
Add
9
Bit
13
Add
8
Bit
12
Add
7
Bit
11
Add
6
Bit Bit 9
10
Add Add
5
4
Bit
8
Add
3
Bit Bit 6 Bit 5 Bit 4
7
Add Add Add Response
2
1
0
Bit
3
Len
3
Bit
2
Len
2
Bit
1
Len
1
Bit
0
Len
0
CAN B extends the header field by 16 bits to give a 29-bit address field. These new bytes are transmitted
MSB first. Bit 2 of the last byte is the Remote transmission request bit; bits 1 & 0 are reserved. An
additional byte is inserted that includes the data length data.
Bit
31
Add
28
Bit
15
Add
12
Bit
30
Add
27
Bit
14
Add
11
Bit
29
Add
26
Bit
13
Add
10
Bit
28
Add
25
Bit
12
Add
9
Bit
27
Add
24
Bit
11
Add
8
Bit
26
Add
23
Bit
10
Add
7
Bit
25
Add
22
Bit 9
Bit
24
Add
21
Bit 8
Bit
23
Add
20
Bit 7
Bit
22
Add
19
Bit 6
Bit
21
Add
18
Bit 5
Bit
20
Add
17
Bit 4
Bit Bit 18
19
Add Add 15
16
Bit 3 Bit 2
Bit 17 Bit 16
Add 14 Add 13
Bit 1
Bit 0
Add Add Add Add Add Add Add Response reserved reserved
6
5
4
3
2
1
0
The data section then follows and can be any length from 0 to 8 bytes long.
Some additional bits are inserted into the LLC frame by the MAC layer, but these are beyond the scope of
this module. They are automatically inserted by the CAN controller, and are not the responsibility of the
programmer.
So how does an ECU gain access to the transmission medium?
The MAC protocol uses a Carrier Sense Multiple Access (CSMA) technique, similar to ETHERNET, but
unlike ETHERNET is guaranteed to be collision free. That is because two nodes are incapable of
transmitting their messages onto the bus at the same time. This is because a dominant bit (0) will defeat a
recessive bit (1). Before a node transmits it listens to the bus to see if it is free. If the bus is in use it waits
for the other ECU to finish transmitting. If it is free it starts to send out its’ message onto the bus,
transmitting its’ address first. Whilst transmitting it simultaneously listens to what it is sending. If another
ECU starts to transmit at the same time, then the ECU with the lower address will win. The ECU with the
higher address will ‘see’ that when it attempts to send a ‘1’ the other ECU overwrites that address bit with
a dominant ‘0’. As soon as an ECU sees its’ own address overwritten it ceases to transmit, leaving the bus
free for the higher priority unit. The higher priority unit is unaware of what has happened and simply
sends its’ message in the normal way. Thus we have achieved collision free arbitration.
There is a penalty with this concept. The propagation delay within the complete network must be
substantially less than bit rate, to ensure that a competing bit from the opposite end of the network arrives
in time arbitrate with all nodes.
2.3 LLC Layer
In the discussion of the MAC layer it will be seen that an address relates to a message, not to an ECU. It
is in this way that CANBUS differs so clearly from other protocols. It is the data frames that are
‘addressed’. Each ECU can broadcast as many messages as it wishes onto the BUS, each of which can be
given different addresses. Thus it is the data entity that has an address.
As ECUs are not assigned addresses, as in a traditional network, it follows that they can listen in to any
message that they wish.
CANBUS IS NOT A POINT TO POINT NETWORK, it is better thought of as a knowledge base.
ECUs are responsible for generating data, which is broadcast onto the BUS, usually at regular intervals.
Each ECU can broadcast as many messages as is required. It is advisable not to allocate the same message
address to more than 1 ECU.
ECUs can then listen to any, or all, of the messages that are available on the BUS. So it is possible to have
multiple ‘listeners’ that all ‘tune-in’ to the same message.
At least one listening ECU must acknowledge receipt of every message (this is automatically done at the
MAC layer), otherwise the ECU that is sending that message will repeat it until someone acknowledges
receipt. Eventually an unacknowledged ‘talker’ will go into error and stop all transmissions.
WHAT YOU NEED TO KNOW ABOUT CANBUS
HOW A BIT IS MADE UP OF 4 SEGMENTS
HOW A FRAME IS FORMATTED
WHY A LOW ID DEFEATS A HIGH ID - THUS WHY CAN IS A COLLISION FREE
NETWORK
HOW TO DERIVE A DATA RATE
2.4 J1939
J1939 is a 7-layer protocol published by the Society of Automotive Engineers. It defines a common
messaging structure for a range of measurands that are to be found on cars and trucks.
Also have a look at the Kvaser web-site - Kvaser
The 29 bit CANBUS address field is divided down as follows (most significant bit first).
3 bits MESSAGE PRIORITY LEVEL
1 bit UNUSED
1 bit PAGE SELECT
8 bits PDU FORMAT
8 bits PDU SPECIFIC
8 bits USER DEFINED
Bits 31/30/29
Bit 28
Bit 27
Bits 26/25/24/23/22/21/20/19
Bits 18/17/16/15/14/13/12/11
Bits 10/9/8/7/6/5/4/3
Bits 2/1/0
Message Priority Level 0 to 7
Unused
Page Select (usually 0)
8-Bit PDU Format
8-Bit PDU Specific
8-Bit user defined
unused
Note that the priority level uses the most significant bits, thereby defining a priority groups. If two
messages from the same priority group attempt to gain access to the bus at the same time, then the
message with the lower FORMAT/SPECIFIC fields will win.
Each message always includes 8 data bytes, but they are not always defined. Each message has a
recommended repetition rate
For example consider entry 5.3.7. in the specification ELECTRONIC ENGINE CONTROLLER #1: or
just EEC1
(Note this is offered as an example and will not be examined)
Transmission repetition rate: engine speed dependent (see 5.1.7.2)
Data length: 8 bytes
Data page: 0
PDU format: 240
PDU specific: 4
Default priority: 3
Parameter group number: 61 444 (00F004 16 )
The 'parameter group number' consists of the 16-bit value obtained by concatenating PDU Format & PDU
Specific.
240 = F0 HEX and 4 = 04 HEX thus a parameter group number of F004 HEX
The standard then goes on to define the meaning of the following 8 data bytes
Byte: 1 Status_EEC1
Bit: 8-5 Not defined
Bit: 4-1 Engine/retarder torque mode 5.2.2.1
Byte: 2 Driver’s demand engine - percent torque 5.2.1.4
Byte: 3 Actual engine - percent torque 5.2.1.5
Byte: 4,5 Engine speed 5.2.1.9
Byte: 6 Source address of controlling device for engine control 5.2.5.298
Byte: 7-8 Not defined
Taking the data fields in turn
BYTE 1 STATUS_EEC1
Bits 8-5 are undefined (note that bits and bytes are numbered from 1 not 0)
Bits 4-1 are defined by section 5.2.2.1 – Shown below is an extract from that part of the specification. It
will be seen that these 4 bits are used to inform other ECU’s of the current ‘torque mode’
TABLE 7
ENGINE/RETARDER TORQUE MODES
Bit States Engine/Retarder Torque Mode
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
Low idle governor/no request (default mode)
Accelerator pedal/operator selection
Cruise control
PTO governor
Road speed governor
ASR control
Transmission control
ABS control
Torque limiting
High speed governor
Braking system
Remote accelerator
not defined
not defined
Other
Not available
BYTE 2 DRIVERS DEMAND ENGINE TORQUE
This is a single byte that gives us the % torque that the driver is demanding. In effect it is a measure of
rotational force. The definition of this byte is given elsewhere in the specification, part of which is
reproduced below.
5.2.1.4 Driver’s Demand Engine - Percent Torque
The requested torque output of the engine by the driver. It is based on input from the following requestors
external to the power train: operator (via the accelerator pedal), cruise control and/or road speed limit
governor. Dynamic commands from internal power train functions such as smoke control, low- and highspeed engine governing; ASR and shift control are excluded from this calculation. The data is transmitted
in indicated torque as a percent of the reference engine torque. See 5.3.17 for the engine configuration
message. Several status bits are defined separately to indicate the request which is currently being
honoured. This parameter may be used for shift scheduling.
Data Length: 1 byte
Resolution: 1%/bit gain,
125% offset (00 = -125%, 125 = 0%, 250 = +125%)
Data Range: -125 to 125%
Operating Range: 0 to 125%
Type: Measured
Suspect Parameter Number: 512
Reference: 5.3.7
Note the way that the value is expressed. It consists of a scale and offset. The offset is –125, and the scale
is defined a 1% per bit. So a data byte of 125 = 0%. This is typical of most numerical values defined by
J1939.
BYTE 3 ENGINE TORQUE
This has the identical format to byte 2, and is a measure of the torque that the engine really delivering.
BYTES 4&5 ENGINE SPEED
Better known a RPM or Revolutions Per Minute.
This is an integer variable defined in section 5.2.1.9 of the specification.
5.2.1.9 Engine Speed
Actual engine speed which is calculated over a minimum crankshaft angle of 720 degrees
divided by the number of cylinders.
Data Length: 2 bytes
Resolution: 0.125 rpm/bit gain, 0 rpm offset (upper byte resolution = 32 rpm/bit)
Data Range: 0 to 8031.875 rpm
Type: Measured
Suspect Parameter Number: 190
Reference: 5.3.7
Integers are transmitted lower byte first, so byte 4 holds the least significant byte and byte 5 holds the
most significant byte. Note again that there is an offset and a scaling factor. To obtain the engineering
value if RPM the integer variable must first be multiplied through by the scaling factor, and then the
offset is subtracted. In this instance the offset is defined as zero so the subtraction is not necessary.
BYTE 6 SOURCE ADDRESS
The user can assigns an 8-bit address to the ECU that broadcasts the EEC1 data frame.
BYTES 7&8
These are unused
WHAT YOU NEED TO KNOW ABOUT J1939
THE FORMAT OF A J1939 MESSAGE
AN OUTLINE OF HOW DATA IS INTEPRETED – i.e. I do not expect you to know the
example given above, but you should be able to propose a way of encoding a data parameter
2.5 CAN IDENTIFIERS & MASKS
Whatever application layer is used for a CAN network, a node is required to selectively accept only those
data messages that it is interested in. This is achieved using the CAN identifier and mask registers. Let us
assumed that we are using CAN B, with a 29-bit address. The address data is carried in the 32-bit header
of the CAN message, of which we are only interested in examining the upper 29 bits. If the protocol if
J1939, then only some of those bits are used to identify the message type. If we want to capture only
EEC1 then consider how the address is defined >
3 bits MESSAGE PRIORITY LEVEL Unknown
1 bit UNUSED Unknown
1 bit PAGE SELECT 0
8 bits PDU FORMAT F0
8 bits PDU SPECIFIC 04
8 bits USER DEFINED Unknown
So the address that we are looking for is
XXXX 0111 1000 0000 0010 0XXX XXXX XXXX
The CAN receiver has a set of registers know as the identifier registers, into these you should write the
address of the message that you wish the device to capture. There are also a set of mask registers, into
these you must write which bits of the identifier registers are to be used.
In this case –
Identifier =
Mask =
0000 0111 1000 0000 0010 0000 0000 0000
0000 1111 1111 1111 1111 1000 0000 0000
Which means that the incoming message must contain a 0 in bit position 27, a 1 in bit position 26 and so
on. All the other bits can be anything.
Consider a simpler example, to capture all messages with the pattern 1010 in the top 4 bits of the address
1010 0000 0000 0000 0000 0000 0000 0000
1111 0000 0000 0000 0000 0000 0000 0000
IDENTIFIER
MASK
Here are some more notes on the use of MASKS and IDENTIFIER filters
WHAT YOU NEED TO KNOW ABOUT IDs & MASKS
YOU MUST BE ABLE TO FULLY DESCRIBE HOW THESE REGISTERS ARE USED TO
SELECT SPECIFIC MESSAGES ON A CANBUS NETWORK
2.6 DEVICE NET
http://www.cse.dmu.ac.uk/~eg/tele/devnet.htm
http://www.cse.dmu.ac.uk/~eg/tele/whatdev.pdf
http://www.ixxat.de/english/knowhow/artikel/devicenet_introduction.shtml
Device Net is a protocol that is used in industrial applications, and operates over a CAN network. It uses
11-bit addressing and runs at 125kHz, 250kHz or 500kHz. By definition the CAN protocol does not
support point-to-point messaging. The Device Net protocol overlays CAN with a higher layer protocol
that creates a point-to-point messaging structure supporting up to 64 nodes. This is achieved by defining
fields within the 11-bit identifier and the 8-byte data packet. Device Net subdivides the 11-bit identifier
field into 4 separate categories known as Group 1, Group 2, Group 3 and Group 4.
CAN IDENTIFIER BITS
10
9
8
7
6
5
4
3
2
1
0
0
Group 1 Message ID
Source MAC ID
1
0
MAC ID (source or destination)
Group 2 Message ID
Group 3 Message Source MAC ID
1
1
ID
1
1
1
1
1
Group 4 Message ID
1
1
1
1
1
1
1
X
X
X
X
HEX
Identity usage
000-3FF Message Group 1
400-5FF Message Group 2
600-7BF Message Group 3
7C0-7EF Message Group 4
7F-7FF Invalid
Group 1
Any identifier in the numeric range 000-3FF is a group 1 identifier. Bit 10 is always 0, bit 9,8,7 & 6 form
a 4-bit Message ID, and the lower 6 bits are the source MAC ID.
Group 2
Any identifier in the numeric range 400-5FF is a group 2 identifier. Bit 10 is always 1, bit 9 is always 0,
bits 8-3 are the 6-bit MAC ID, and bits 2-0 are the message ID.
Group 3
Any identifier in the numeric range 600-7BF is a group 3 identifier. Bit 10 is always 1, bit 9 is always 1,
bits 8-6 are the message ID, and bits 5-0 are the 6-bit MAC ID.
Group 4
Any identifier in the numeric range 7C0-7EF is a group 4 identifier. Bits 10 to 6 are always 1, bits 5-0 are
the message ID.
The purpose of the message ID is to provide a range of CAN addresses that can be used by a specific
node to make multiple connections. i.e. by concatenating the 6-bit MAC ID with the 3/4-bit message ID a
range of different MAC identifiers are created.
Consider Group 1 – this option support the use of a 6-bit Source MAC ID (thus 64 nodes maximum). The
Message ID field s 4-bits, so any node using a group 1 format can issue up to 16 different messages.
In Group 2 the MAC ID field can be either the source or the destination node.
Group 3 is very similar to group 1, in that it has 1 6-bit source MAC field, and a 3-bit message ID field.
This allows any node using a group 3 format to issue 8 different messages.
Group 4 is intended for system management purpose.
A CAN message can only deliver 8 data bytes. If all the data can be stored in one CAN message then the
format used defines the first byte as the Message Header, and the following 7 bytes as the Message Body.
If the data cannot fit into on CAN message then a fragmentation Protocol is used, which will split the
message over multiple CAN message; in this case the first byte is the Message Header, the 2 nd byte holds
the fragmentation Protocol information, and the last 6 bytes hold the data.
We will now consider only non-fragmented data.
The message header byte is broken down as follows –
Bit
7
Meaning Frag
6
XID
5
4
MAC ID
3
2
1
0
Bit 7 is the fragmentation field. If it is a 1 then this message is a fragment. We will not consider
fragmented fields in this discussion.
Bit 6 is the Transaction ID bit. This field is optional, and is used to match a response to an issuing request
– i.e. the responding application simply echoes this bit in its’ reply.
The last 6 bits are used to define the MAC ID. If the CAN identifier field included a SOURCE ID, then
this is the DESTINATION ID (Groups 1 & 3, and optionally Group 2). If the CAN identifier included the
DESTINATION ID, then this field holds the SOURCE ID (optionally Group 2 only).
The Message Body consists of a 1-byte Service Code followed by a 6-byte Service Specific Argument
field.
Bit
7
Meaning R/R
6
5
Service Code
4
3
2
1
0
R/R defines whether this is a request or a response. If the bit is 0 then this message is a REQUEST, if it is
a 1 then this message is a RESPONSE.
The 7-bit service code defines what the rest of the message means. Some of these are defined by the
Device Net standard, other are application dependant.
For example Service Code 07 means STOP, service code 6 means START etc. You are not expected to
remember the service codes
WHAT YOU NEED TO KNOW ABOUT DEVICE NET
Device Net overlays the CAN MAC protocol with an application layer. This layer supports point to
point connectivity by assigning 6-bit MAC SOURCE and DESTINATION codes.
There a 4 message groups, 1, 2, 3 & 4.
Groups 1&3 include the source MAC ID in the 11-bit identifier. Group 2 includes either a source or
destination MAC ID in the 11-bit header. Group 4 is used for systems administration only.
The remaining 6-bits are used to distinguish between the message groups, and to provide a Message
ID field. This field is used by a node to create multiple connections using the same MAC ID.
The data field can be a single entity or fragmented.
The first data byte field contains the other MAC ID that this message is communicating with (i.e. is
a SOURCE ID is the 11-bit identifier then the DESTINATION ID is here, if the DESTINATION ID
is in the 11-bit identifier then the SOURCE ID is here).
The second data byte contains the SERVICE CODE.
The final 6 bytes contain data.
2.7 CANOPEN
CANOPEN was developed as an alternative to DEVICENET for use in motor control systems. An
overview can be found at
http://www.can-cia.org/
These links may help to explain what is happening
http://atlas.web.cern.ch/Atlas/GROUPS/DAQTRIG/DCS/LMB/PROFILE/cano-pdo.htm
http://atlas.web.cern.ch/Atlas/GROUPS/DAQTRIG/DCS/LMB/PROFILE/cano-sdo.htm
It uses 11-bit CAN identifiers, of which the 4 most significant bits are defined as the Function code, the
remaining 7 bits are the Node-ID. The final 11-bit identifier is known as the COB-ID.
This gives us a range of broadcast message types, that are used as follows
Network Management
Synchronisation
Time stamp
And a set of point to point message types
Service Data Objects or SDO
Process Data Objects or PDO
Emergency messages
SDOs are used to read or write to/from the contents of a device object dictionary
PDO's offer real-time transfer of data between peers
The object dictionary is a list of commands that offer every possible parameter that is required for motor
control, such as speed, position, acceleration etc.
An SDO is used to access a node’ setup, using entries from the object library, as defined by the
'command' , 'index' and 'sub-index' fields.
SDOs have the following format:-
COMMAND,INDEX,SUB-INDEX,DATA
The command is 1 byte
The index uses 2 bytes
The sub-index uses 1 byte
The data field uses 4 bytes
The CANOPEN specification defines the meanings of the index fields, thereby creating an open
standard.
It is possible to use SDO’s to communicate with nodes, but this may not be the most efficient approach.
Instead we can use PDO’s to access the data directly. This is achieved by ‘mapping’ SDO data fields into
PDO data fields. PDOs do use the strict layout as defined by the SDOs, instead the user can allocate the 8
data bytes in any means that will be of use. So, for example, an SDO that carries 12 bits of data can be
mapped to the first 12 bits of a PDO. Another SDO data item that is 10 bits long, can be mapped to the
next 10 bits of a PDO.
Here are some web sites relating to CAN-OPEN
CAN_OPEN.pdf
EPOS_Communication_Guide_E.pdf
EPOS-Firmware%20Specification-E.pdf
EPOS-Getting%20Started-E.pdf
EPOS-Hardware%20Reference%20-E.pdf
WHAT YOU NEED TO KNOW ABOUT CANOPEN
It uses 11-bit CAN messages
The 11-bit identifier is split into two fields – a 4-bit function code and a 7-bit node identifier
One group of functions are the Service Data Objects. These are formatted as follows Command, Index,
Sub-Index, Data. They are used to read/write to/from a node’s Object Dictionary. The available objects
are defined by the CANOPEN spec.
It is possible to map data onto PDOs, so that they can be sent real time, and more efficiently than using
SDOs
3 Other Wired Protocols
3.1 LIN BUS
Local Interconnect Network, is a more modern version of KBus and is now finding its way into
industrial applications. A really good article can be found at LINBUS
Or go to the main LIN website at http://www.lin-subbus.org/
I have used part of these article for this section
The full specification, and related documents can be obtained from the main LIN website, or you can get
it here
LINbus uses a similar physical layer to K Bus, in that it uses a single multi-drop half duplex wire. There
is a single master and multiple slaves. Signalling is achieved using a standard 'RS232' concept, in that an
8-bit character is encapsulated between a start bit and a stop bit. This allows you to employ a standard
UART. Synchronisation is achieved by the master issuing a synchronisation field prior to transmission
This gives us a 6-bit identifier field, allowing up to 64 options
The identifiers are split in to four categories:
• Values 0 to 59 (0x3b) are used for signal-carrying frames,
• 60 (0x3c) and 61 (0x3d) are used to carry diagnostic data,
• 62 (0x3e) is reserved for user-defined extensions,
• 63 (0x3f) is reserved for future protocol enhancements.
The 2 bit parity field is constructed using the following equations P0 = ID0 ^ ID1 ^ ID2 ^ ID4
P1 = ! (ID1 ^ ID3 ^ ID4 ^ ID5)
where ! is NOT and ^ is EXCUSIVE OR
The data field follows, and can be between 1 to 8 bytes long; this is application dependent. The following
is an extract from the specification -
"A frame carries between one and eight bytes of data. The number of bytes contained in a frame with a
specific identifier shall be agreed by the publisher and all subscribers. A data byte is transmitted in a byte
field. For data entities longer than one byte, the entity LSB is contained in the byte sent first and the entity
MSB in the byte sent last (little-endian)". Which means that it is up to you to define what the data means.
The last byte is the checksum. The modern, or 'enhanced' checksum uses both the identifier and the data
fields, the older or 'classic' checksum only uses the data field.
Thus we have defined a full LIN frame
An interesting feature of LIN is that the 'frame' is not defined as the information issued by the master to
the slave, but is the complete transaction of
HEADER Master to Slave
RESPONSE Slave to Master
What you need to know about LIN
A complete frame is made of a header issued by the master and a response from the slave device.
A header contains 8-bits of data which are a 6-bit Identifier followed by a 2-bit parity check sum.
The data field contains up to 8 data bytes. The length of the data section is determined by the application.
The enhanced checksum uses all the information in the frame, i.e. the identifier and the data
fields.
3.2 Common Protocols
There are now a number of application layer protocols that can operate over different transmission media.
One example is ISO14229, which is used for vehicle diagnostics. It can be used over CAN, LIN or KBus
and would quite easily operate over RF mediums as well.
We do not need to know much about it, simply that it is an example of a common protocol that will work
over different networks.
All ISO 14229 messages contain the following data
SOURCE ID 8-bits
DESTINATION-ID 8-bits
Packet Length 1 byte
Command 1 byte
Sub-Command 1 byte
Data – various lengths
For example the 29-bit CAN message 18DAC1F1 06 2E 01 DD DD DD DD 00
Has the following meaning
18DA is network management to enable the ISO14229 message to operate on a 29-bit CAN
network
C1 is the source node
F1 is the destination node
06 is the data packet length, in this case 6 bytes
2E is an ISO 14229 command
01 is the sub command
DD DD DD DD is four bytes of data
00 is a NULL padding byte to fill up the 8 byte data section
SEMESTER 2
4 GSM MODEMs
GSM technology has undoubtedly revolutionised personal communications. What is less known is that it
has also made major in-roads into industrial telemetry, after why go to the trouble of developing a new
wireless network, when already exists that operates world-wide using open standards. These standards are
available from ETSI, and can be downloaded from their web-site www.etsi.com.
The Groupe Special Mobile (GSM) set up by the Conference Europeenne des Postes et
Telecommunications (CEPT) in 1982. In 1988 the European Telecoms Standards Institute (ETSI)
was created and laid down a European standard for mobile communications. With the support of the EU,
ETSI piblished a set of European standards for telecommunications, including GSM, DECT phones and
other products. Thus a huge open market was created, and Europe remains today the leading centre for the
development of new mobile phone technology.
There are three methods by which data can be transferred over the GSM network
The voice service can be used with a MODEM in exactly the same way as a land-line uses a Hayes
compatible MODEM
The SMS service can used to send short or multi-part messages (better known as text messages)
GPRS can be used as an always open data connection
To use any of these methods you must employ a specialist GSM MODEM. A range of companies make
these devices, the best known are Sierra Wireless/Wavecom, Siemens, Falcom, & Telit Many PDA’s and
laptops include a GSM ‘engine’ as standard.
4.1 Voice Service
There is no mystery to this technique. Using a GSM MODEM you can connect to another MODEM using
the standard Hayes AT command set. The receiving MODEM can be another GSM MODEM or use a
traditional land-line.
Typical AT commands would be
ATD441162551551
Which would dial up the MODEM that is assigned the telephone number 01162 551 551, which just
happens to be DMU’s main switchboard. Note the use of the international dialing format. Which is
recommended for GSM use, as it is a global service – though national dialing formats will work just as
well.
To answer a call use the HAYES 'answer' command ATA
The two MODEMS will then negotiate the carrier protocol as usual, and enter the CONNECT phase. The
MODEDM usually outputs a message such as CONNECT 9600 to indicate that a connection is now open
that will support 9600 BPS on the local link.
From now on all data entered at one end will be transmitted over the network to the other end.
To hang up enter +++ very quickly, this forces the MODEM to accept local commands. ATH0 will force
the MODEM to go ‘on-hook’ (i.e. you put your telephone handset back onto the hook on the telephone
set), which disconnects the data call.
4.2 Short Message Service or SMS
SMS is available in two formats, Text mode and Protocol data Unit (PDU) mode. You need to be familiar
with both techniques.
Text mode is the equivalent of the well known texting capability of mobile phones. This allows the user
to send a maximum of 160 7-bit characters in a single message. This is supported by all GSM MODEMS
using simple set of AT commands.
AT+CMGS to send a message
AT+CMGR to read a message
AT+CMGD to delete a message
Other useful commands are
AT+CMGW to store an outgoing message on your SIM
AT+CMSS to send a stored message
Please refer to the full ETSI specification for full details.
To send a text message enter
AT+CMGS="+441162551551"
Note the full international dialing code format +44 for the UK, followed by the national dialling code.
When the MODEM is ready to accept the text message it replies with a > prompt
You can now enter up to 160 7-bit characters, using the GSM alphabet, which is slightly different from
ASCII or ISO646/2022 alphabets.
On each carriage return the MODEM sends another > prompt
To terminate the message and send it enter control Z (hex 1A), for end-of-file.
If the message is accepted by the bearer service (orange, O2, vodaphone etc.) you will get a response of
the form AT+CMGR: MSG=nnn where nnn is a local message number assigned by the bearer service.
If the bearer service did not accept the message then the response will be ERROR
It is important to understand that this does not guarantee delivery of the SMS to the recipients mobile
equipment or ME. To achieve a proof of delivery you have to use PDU mode.
What you need to know about SMS Text Services
Text messages are actually transmitted as PDUs, not ASCII text. You are limited to 140 bytes, thus a text
message maximum length is 160 7-bit characters.
SMSs are sent to a logical destination number held by your bearer service. This is the Service
Centre number. They are then relayed on to the destination ME.
When an SMS is acknowledged by the service centre, that does not mean it has been delivered.
To obtain proof of delivery you have to use PDU mode.
How to use the basic SMS commands, CMGR, CMGS, CMGD, CMGL,
How to save and retrieve SMS from the SIM
4.3 PDU Mode
PDU mode is far more complex. see DreamFabric website for a good
explanation http://www.dreamfabric.com/sms/
The PDU is broken down into a number of fields
Length
TP_MTI/RD/VPF Message Type Indicator etc
TP_MR Message Reference
TP_DA Message Destination Address
TP_PID Message Protocol Identifier
TP_DCS Message Data Coding Scheme
TP_VP Message Validity Period
TP_UD Message User Data – this is our data field
LENGTH
The length is the total length of the PDU in bytes
TP_MTI FIELDS
Now consider the TP_MTI byte, it is made up of the following fields bits 0-1 are TP-MTI Message Type Indicator
set to 01 for SMS Submit
bit 2 is TP-RD Reject Duplicates - set to 0 else multiple messages will be rejected by Service Centre
set to 0
bits 3-4 are TP-VPF Validity Period Format
00 = not present
10 = Relative Format 1 octet
01 = Enhanced Format 7 octets
11 = Absolute format 7 octets
set to 10 to select relative format, you can then set a lifetime for the SMS from the time that you issue it.
bit 5 is TP-SRR Status Report Request
set to 1 to obtain a status report, you can use this feature to obtain a 'proof of delivery' to the remote
Mobile Equipment (ME).
bit 6 is TP-UDHI User Data Header Indicator
set to 0 as a UDH is not used for a single part message
bit 7 is TP-RP Reply Path
set to 0 to indicate that there is no reply path
A typical byte would be 00010001 - which means
this is an SMS that is to be SUBMITTED to the system,
do not reject a duplicate message as I might resend it,
use relative format for the determining how long the SMS is allowed to survive if it is not delivered
do not send me a proof of delivery message back again
this is a single part message
there is no reply path open to you so do not try to reply
TP_MR
This is a single byte that you can use to identify your messages, it can take any value between 00 and FF.
TP_DA
This is the destination address, which is the ME that the SMS will be delivered to. The first byte is the
length of the telephone number. The second byte is the type of address use 91 to select International
Dialling Code format, 81 selects National Dialling Code Format.
The telephone number is now inserted using reversed BCD format
For example the telephone number 01162 551 551 is transmitted as
10 61 52 15 55 F1
Where an F is used to pad out the unused nibble.
So the complete TP_DA field, using national dialling, is - 0B 81 10 61 52 15 55 F1
TP_ID
This is the Protocol Identifier which is used to set the protocol used in the SMS; 00 = standard SMS.
TP_DCS
This set the Data Coding Scheme for the encapsulated text message data; use 00 for standard 7-bit data.
TP_VP
This sets a validity period after which the message dies. If we select relative offset in the TP-VPF field,
the next octet giver this offset where >
0 to 143 = (n+1) * 5 minutes
144 to 167 = 12 hours + ((n-143) * 30 minutes )
168 to 196 = (n-166) * 1 day
197 to 255 = (n-192) * 1 week
so 1 week = 173
I do not expect you to remember this!
TP_UD
This is the actual user data, i.e. the text message itself. PDU messages are not restricted to 160 7-bit
characters as a multi-part message option is available. When multi-part messages are used, each message
also includes a user data header; this identifies a specific multi-part message, and informs the ME which
part this message is. It is up to the ME to connect these separate parts together to give the full long
message.
If we assumes that we are not using multi-part messaging then we are restricted to 160 7-bit characters.
However PDU mode sends data as 8-bit bytes, so the 7-bit characters or septeps are compacted into 8-bit
data bytes.
What you need to know about PDU
The generalised format – by this I mean what fields are required, and what order they must be sent in. I do
not expect you know the meaning of the fields down to bit level, as you can look this up.
How to format an ME destination number & the Service Centre number
How to format 7-bit ASCII data into the PDU data field.
4.4 GPRS
The General Packet Radio Service is a dedicated data service that offers the user a permanently open data
connection. A pair of MEs CONNECT to each other, thereafter they can exchange data. However it is
necessary to define the ‘context’ of this data exchange – in effect what higher level protocol do we intend
to use. Currently the following contexts are available – TCP/IP, FTP, EMAIL, M2M
Regardless of what application you wish to run the GPRS protocol is IP based. Therefore you must have
an IP Stack running either within your MODEM or within your terminal. Most modern GPRS MODEMs
are supplied with an in-built IP stack, but they may not conform to a standard. Given below is the outline
of how connect using a terminal based IP stack, and using the AT_OPEN commands supported by the
Wavecom range of GPRS MODEMs.
4.4.1 The Context
The first thing that is required is to set up the ‘context’ that you wish to use – think of this as your
‘session’
We now need to store our context, for example the following command sets up our context store number
1 to be the Orange communication access to the Internet, using IP
The minimal command is as follows
AT+CGDCONT=CID,PDP_TYPE,APN
Where CID is the context ID number
PDP_TYPE identifies the protocol that you intend to use
APN is the Access Point Name that you wish to connect to remotely
AT+CGDCONT=1,”IP”,”orangeinternet”
This sets up context ID number 1 to be an IP connection to the access point called orange_internet.
4.4.2 Using a Terminal Base IP Stack
If you connect your MODEM to a PC then you can use any IP based client such as Internet Explorer.
We need to activate a stored context using the following command
AT+CGACT=1,1
The best way to understand GPRS is to go through the connection process. First the ME (mobile
equipment) has to request Radio Resources – this is achieved with the command
AT+CGATT=1
The response will be of the form AT+CGDREG=1, which indicates that you have successfully registered
your MODEM onto the GPRS data network.
You can now connect to your remote service using the following command
AT+CGDATA=1
You now have an IP link to the remote IP server. However as we do not have any applications setup to
run over the IP connection you cannot do much else. What you will see arriving at the terminal are IP
packets.
In order to use a web browser as your IP peer you must first establish a poit-to-point connection between
your terminal and the MODEM. If you are using windows this requires you to create a new MODEM
device to handle the link, and then to create a new dialler using the networking icon found in the control
panel. The windows dialler was developed for use with old fashioned dial up MODEMs, so you have to
get around some of the limitations of Windows. As you have created a context, the MODEM is already
aware of the password, username and APN, so leave all these fields blank. Windows will not offer you
the AT+CGATT or AT+CGDATA commands, but all GPRS MODEM<s support a special dial out
number that instructs the MODEM to execute these commands. This number is *99***1# which you
enter into the dial out box in the dialler set up window.
Once the dialler icon is created you can connect to the GPRS APN by clicking it. On connection a small
network icon can be seen on the tool bar, and you can now use any IP client of your choice.
4.4.2 Embedded Applications
All modern GSM MODEMS support a C or Java style programming language, which allows you to
develop your own applications. Some common applications are also provided as standard, such as
opening a TCP/IP socket, connecting, and transmitting a file using FTP. One example is the Wacecom
WIPAT command set.
For example to open a TCP/IP socket connection for FTP upload
AT+WIPCFG=1
Start IP stack
AT+WIPBR=1,6
Open GPRS bearer
AT+WIPBR=2,6,11,"....." APN name
AT+WIPBR=2,6,0,"..."
APN Username
AT+WIPBR=2,6,1,"..."
APN Password
AT+WIPBR=4,6,0
Start GPRS bearer
AT+WIPCREATE=4,1,"...","...","..." Create FTP session, fields are FTP URL, FTP Usernam, FTP
Password
AT+WIPFILE=4,1,2,"...", Open a file for FTP upload with full pathname
AT+WIPCLOSE
Close down the FTP peer
AT+WIPBR=5,6
Stop GPRS bearer
AT+WIPBR=0,6
Close GPRS bearer
AT+WIPCFG=0
Stop IP stack
4.5 M2M Connect
This stands for Machine to Machine connect. A traditional distributed network consists of a number of
GSM MODEMs in the field, and a service centre filled with banks of MODEMs that receive the incoming
data. M2M is intended to replace the banks of MODEMs held in the call centre. Instead of directing data
to a real GSM MODEM, information is instead routed to a logical GSM MODEM which is part of the
bearer service architecture. In effect incoming data and SMSs are entered into a database. This database is
accessed using a secure link over the internet.
Messages are made available to a valid user in XML format, which can be downloaded using SOAP.
5 Blue Tooth
Blue Tooth is a much under-rated technology, mainly because it has been unfavourably compared to WiFi
or Wireless LAN technology. Even though they both use the 2.4GHz data band, and are data networks,
they are intended for different markets and purposes.
Perhaps the best known use for Bluetooth is hand-free car kits. This application exploits a major feature
of Bluetooth, in that it includes a PCM analogue interface as standard. Once a connection has been made
to another Blue Tooth device data can be exchanged using one of three different link level standards, a
USB connection, a ‘TTL-RS232’ connection or a PCM analogue connection.
Bluetooth and WiFi are not the only RF devices inhabiting the 2.4GHz band, but they are the most tightly
defined. The 2.4GHz band is split into a series of channels, these are separated in frequency space, so as
to allow multiple connections to be made that are separated by frequency. So what happens if you are
using a certain channel, and another user or protocol starts transmitting on the same channel – WiFi will
die, but Bluetooth survives because it employs a technique known as frequency hopping, which means
that if the channel it is using is broken into then the connected pairs automatically and mutually ‘hop’ to
another channel and start chatting again.
Bluetooth is a protocol that uses the 2.4GHz transmission band. It is tightly controlled, and all Bluetooth
products must be registered and be issued with a serial number that is traceable back to the standards
body. This serial number is known as the Board Address (or BD Address). Users can also add a local
identifier to their modules, known as the ‘friendly name’. Finally all modules contain a special field that
identifies what type of device they are attached to (e.g. mobile phone, laptop, FAX machine etc.).
All Blue Tooth devices come with an RF module, that handles communications between devices, and a
baseband module. The baseband module provides the link between the user application and the RF
module. In general you connect an application to the baseband module by one of three methods
SERIAL (typically 115200 BPS 3V TTL level)
USB
PCM (used for voice/analogue)
The lowest level protocol is called HCI (HOST CONTROLLER INTERFACE). This defines a basic set
of functions such as Discover, Connect and Pair. Higher level protocols exist such a SPP (Serial Port
Protocol) which effectively turns a Blue Tooth connection into a serial port, FAX and Voice (used for
hands free connections to mobile phones).
In order to communicate it is usual that two Bluetooth units ‘pair’. This is achieved by one unit first
entering ‘discoverable’ mode – this means that the unit starts broadcasting its’ existence to the local Blue
Tooth community. Another unit can then enter ‘discover’ mode – this means that it scans the immediate
area to see who is about. Discover mode reports back details of all the discoverable blue tooth units in the
area, in the form of their board address, their function, and their friendly name.
The application can then ‘pair’ with any or all of these devices. Module 1 issues a pair command to a
chosen BD Address, the module that is being paired to can then either accept or reject the request to pair.
Optionally a PIN number or Passkey can be requested to complete the pairing, thus adding a minor level
of security. Once two blue tooth units are paired a connection can be made between them without any
further human intervention!!!
In summary a Blue Tooth connection follows the following sequence
UNIT 1 ENTERS DISCOVERABLE MODE
UNIT 2 ENTERS DISCOVER MODE AND FINDS UNIT 1
UNIT 2 REQUESTS TO PAIR WITH UNIT 1
UNIT 1 ACCEPTS OR REJECTS THIS REQUEST
UNIT 2 MAY OPTIONALLY ASK FOR A PIN NUMBER (PASSKEY)
UNIT 1 USER ENTERS PIN NUMBER
UNITS 1 & 2 PAIR BY EXCHANGING A ‘LINK KEY’
EITHER UNIT CAN REQUEST A CONNECTION
IF LINK KEYS MATCH THEN UNITS CONNECT AUTOMATICALLY
IF LINK KEYS DO NOT MATCH THEN USER IS ASKED TO AUTHORISE CONNECTION
Once two units are paired, they can then run their applications, using the Blue Tooth connection as a
serial carrier.
5.1 BOARD ADDRESS
All Bluetooth modules are assigned a unique Board Address which consists of 12 HEX digits, or 48-bits.
This was considered to adequate to uniquely identify all Bluetooth modules that will ever be
manufactured.
In addition a Bluetooth module contain a 6 hex digit field that defines the type of unit that it is, i.e. a
laptop, or a mobile phone, or a hands free kit etc.
Finally the user can assign a ‘friendly name’ of their choice to their Bluetooth module that contains 18
ASCII digits.
When a unit pairs or connects, it is usual for all these data fields to be exchanged.
5.2 HCI
http://www.palowireless.com/infotooth/tutorial/hci.asp
The above link is a web based tutorial for the Host Controller Interface protocol. HCI is the lowest level
protocol available in the Bluetooth protocol stack. It enables communications between a list computer and
the 'baseband' module of the Bluetooth transceiver. NOTE YOU WILL NOT BE EXAMINED ON HCI
The complete Bluetooth specification is available here.
What you must know about BlueTooth
Blue Tooth assigns all modules a unique 48 bit Board Address
All modules are also assigned a 6 digit Device Class
A user can assign an 18 character Friendly Name
What is the difference between pairing and connecting
5.4 ZigBee
ZigBee is a new open standard operating on the 2.4GHz frequency, it also offers channels on 915MHz
and a single channel on 868 MHz.. The ZigBee Alliance is the main body that is pushing this open
standard forward, and details can be found at http://www.zigbee.org/ or try the overview at
http://www.zigbee.org/documents/ZigBeeOverview4.pdf.
In brief ZigBee offers a low cost, low power, solution to self configuring mesh technology. Unlike
BlueTooth, which offers Piconets as an overlaying application layer, the ZigBee protocol supports self
configuring mesh nets as standards.
ZigBee has been adopted as the preferred standard for Smart Metering, and this will create a
mass market for ZigBee devices.
ZigBee is designed for low bandwidth data transfers, in contrast to BlueTooth which requires
high bandwidths for services such a voice. As a low bandwidth device ZigBee will offer better
power consumption than BlueTooth.
ZigBee uses a Spread Spectrum technique, Direct Sequence Spread Spectrum (DSSS) to improve
noise immunity. (See section below on Spread Spectrum techniques)
Finding non-partisan comparisons of the various RF protocols is hard, but there are plenty on the
web, and you are advised to have a browse.
Ember have a particularly good set of documents
http://www.ember.com/products_documentation.html
Try http://www.ember.com/pdf/120-3021-000_App_Dev_Ref_Manual.pdf for an overview
Here are some key differences
ZigBee
Wi-Fi
10-100 metres
50-100 metres
Range
Ad-hoc
selfHub and spoke
Networking Topology
configuring mesh, peer arrangement
to peer, star, or mesh
Bluetooth
10 – 100 metres
Ad-hoc, very small
networks
2.4 and 5 GHz
Operating Frequency 868 MHz (Europe)
900-928 MHz (North
America)
2.4 GHz (worldwide)
High
Complexity (Device Low
and application
impact)
Power Consumption Very low (low power is High
(Battery option and a design goal)
life)
128 AES plus
WAS for session layer
Security
application layer
and similar, but none
security
at application layer.
Wireless LAN
Typical Applications Smart Metering,
industrial control and connectivity,
monitoring, sensor
broadband Internet
networks, building
access
automation, home
control and automation,
toys.
Typically low
bandwidth,
High bandwidth. 54
Bandwidth
requirements. Up to
MBPS
250 KBPS.
Connection time
Fast typically 30ms
Slow 3-5 seconds
2.4 GHz
High
Medium
64 and 128 bit
encryption
Wireless connectivity
between devices such
as phones, PDA,
laptops, headsets.
Typically high
bandwidth
requirements. 100
MBPS.
Can be very slow for
full pairing process
In addition to supporting the a Personal Area Network (PAN) using a ZigBee Stack Protocol,
there are a number of Application profiles either available or under development. These are
currently





Smart Energy Profile
Commercial Building Automation Profile
Home Automation Profile
Health Care Profile
Telecoms Profile
Zigbee networks are established as follows::A coordinator finds an available channel in the spectrum and sets up the Personal Area Network
(PAN). After the PAN is formed the coordinator can accept requests other Zigbee devices who
wish to join the PAN. Coordinators can also act as routers. Devices finds open networks by
scanning, and if it is running the correct ZigBee Stack Profile (i.e. the the correct version of
ZigBee) and the correct application profile it requests to join the PAN. This request may be
handled by either the coordinator itself, or another node that has already joined and is setup as a
router. Optionally if the application profile is a 'Trust Center' then there will be a further level of
security required before the new device can join the PAN; in which case the request can be
accepted or rejected. Smart Energy Profile requires a high level of security.
Once accepted a new device can operate as either a Router, which means it can relay messages to
other devices and allow them to join the PAN, or it is an End Device.
All devices on the PAN use the same channel frequency, and the same PAN ID. This allows
multiple PANs to share the same frequency.
The network layer is responsible for discovering and maintaining routes between nodes in the
network. Two types of routing are in use, Tree and Mesh. Tree routing means that the network is
divided into deeper and deeper layers, with the coordinator talking a number of routers at the top
of the tree, and each router then allows new nodes to join beneath it, which in turn can become
routers themselves or end devices. This can mean that messages take very long routes between
nodes even if they are physically close to each-other; it does however have a very
comprehensible structure. Mesh network makes use of routing tables in the routers, enabling
routes to be established, and changed as required in any direction. More recent PANs tend to use
mesh rather than tree.
5.5 Z-Wave
A ever popular standard mainly used for home automation operating in the 868 MHz band. More
information can be found here http://www.z-wavealliance.org/modules/AllianceStart/.
Z wave uses a mesh network structure, operating between 868 and 921 depending upon the
country of operation. Thus it avoids the crowded 2.4GHz band used by WiFi, Bluetooth and
ZigBee. 868.42 is used in Europe, and is particular good at penetrating walls, thus its popularity
for use for home automation.
It operates over short distances, typically up to 30m, with a low bandwidth and data transmission
rate, of 9600 BPS or 40,000 BPS. As its purpose is home automation low data rates are more
than adequate.
see http://wiki.zwaveeurope.com/index.php?title=Z-Wave_Network_Layer
Z Wave networks establish a self configuring mesh. When a new device is added to the mesh, it
is 'included'. A Z-Wave controller has a unique factory set 32-bit Home ID which cannot be
changed, as Slave Z-Wave units are included to the mesh they are given this Home ID, and
assigned a Node ID. Other controllers can also be included , but they then adopt the main
controllers Home ID. As some node IDs are reserved the maximum number of included devices
is 232. If a node is removed from the mesh it is 'excluded', and its Node ID becomes available to
be assigned to a new slave node.
The mesh net is established by the controller. Each node discovers what its 6 nearest nodes are,
i.e. its neighbours, and passes that information to the controller. The controller then updates its
routing table. Thus the controller has a route to every node in the mesh. Slave devices cannot
initiate a message, it can only respond to a request from the controller. A 'Routing Slave'
however has some knowledge of the routing table created by the main controller, and can be
given permission by the master to send unsolicited message to selected slaves.
6 LPRF
Low Power Radio Frequency is the generic term for low-cost low-power RF transceivers that use the
licence free bands, 433MHz, 866Mhz and 2.4Ghz
There are no rules associated with the use of these frequencies, so the use of collision avoidance
techniques such as frequency hopping is advisable.
The 2.4Ghz band is also used by WiFi BlueTooth and ZigBee.
LPRF transceivers offer a very simple and quick solution for telematic problems. It is down to you to
develop the software applications that use LPRF transceivers.
7 IRDA
The Infra Red Data Association maintains the protocol standards used by Infra red transceivers.
More information can be found at http://www.irda.org/index.cfm
The most important protocol is the Object Exchange Protocol or OBEX. It defines a packet structure for
passing blocks of data, such as ‘Business cards’ etc. OBEX has been adopted by BlueTooth as an
application layer standard for the movement of data packets across a BlueTooth connection
8 RFID
Radio Frequency Identification is now widely used in many applications. As well as tagging goods in
shops, it is used to locate high value goods, people, to pay for bus and train fares (e.g. Oyster cards) and
identify Nokia Phones.
RFID is usually a passive devcie, meaning that there is no power required by the RFID tag. An
RFID reader radiates power at one of the RFID standard frequencies, and this power is mutually
induced in to the tag. Using the induced power the tag is then able to respond to the reader. Basic
tags offer little more than a serial number, but more modern tags include a processor that has
kilobytes of non-volatile storage.
The range of RFID tags is very short, and depends upon the frequency used, these are >





125 - 134 kHz
13.56 MHz
UHF (400MHx and 860 to 960 MHz)
2.45 GHz
5.8 GHz
The higher the frequency the greater the range. Low frequencies can manage typically a few
cms. High frequencies can manage a metre or so.
9 GPS & Galileo
GPS or global positioning system, is a worldwide tool that allows users to obtain a 'fix' of their longitude
and latitude. The National Marine Electronics Association maintains the standards for GPS data, so it is
often called NMEA data. NMEA however defines a range of different standards (see NMEA ).
The most useful format is GGA
GGA - essential fix data which provide 3D location and accuracy data.
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
Where:
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
1 Fix quality: 0 invalid 1 GPS 2 DGPS 3 PPS 4Real Time Kinematic5 Float RTK
6 estimated (dead reckoning)7 Manual input mode8 Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *
Galileo is the European version of GPS, The Russians maintain the GLONASS system, Compass is the
planned Chinese system.
Other systems are planned by India and Japan. These are known generically as Global
Navigation Satellite Systems (GNSS).
DeMontfort worked with Nottingham Scientific Ltd to develop a generic GNSS receiver that uses data
from all known GNSS constellations. The RF front end
can now be purchased for use with a PC based Software Defined Radio package. A live capture of data
from a trial device can be viewed here.
Some GNNS terms
Alamanac: The almanac is a data file that tells the receiver which satellites are closest to
the receiver. In effect it is a set
of data for each satellite that is used to determine its approximate location in orbit. The
almanac is encoded in the GNSS data , and can be used to
decide which are the most sensible satellites to look for first. It does not have to be
accurate, as the orbits do not change too much
over time.
Ephemeris: The ephemeris data contains information that precisely locates each satellite at that
time.; and it is included in the GNSS downstream data. It is only accurate for a short period of
time, and must be refreshed.
UTC: Coordinated Universal Time is a highly accurate time, that is transmitted by all GNSS
satellites. Using the ephemeris data and the UTC from 4 satellites allows the GNSS receiver to
accurately determine its position in 3D space.
EGNOS: Or European Geostationary Navigation Overlay Service.This is an enhancement to
GNSS, using ground based stations with a know position it is possible to determine small errors
on GNSS broadcast data. These small differences are broadcast using EGNOS satellites, and are
used by GNSS receievers to provide small corrections to their positioning results. Similar
systems are the WAAS in North America and MSAS in Japan and East Asia. The European
EGNOS corrected data was designed to offer 7 metre precision positioning, it is however
claimed that it now offers 1 metre precision. It will support GPS, Galileo and GLONASS
A receiver uses its almanac to decide which GNSS satellites are most likely to be in range. Each
GNSS satellite broadcasts a precise time signal in UTC format, and its position known as the
ephemeris. Using this data from 4 satellites it is possible to use trigonometry to determine a
precise location fix for the GNSS receiver.
To improve the accuracy of the result there are two possible methods that can correct errors. The
receiver's timing signal is not as likely to be as accurate as those used by the satellites, so the
local UTC can be corrected using a method comparable to regression – with 4 satellites there is
an uncertainty related to the result, the local UTC is adjusted to be at the centre of this
uncertainty and the position fix is recalculated. This continues until the local UTC is adjusted to
minimise the uncertainty. The other cause of error is due to errors in the ephemeris data due to
small orbital shifts; this can be overcome by using EGNOS style satellite data. The EGNOS
system uses ground based receivers with known precise positions to determine the current
ephemeris errors, these are then broadcasts from EGNOS satellites in the European area, and can
be used to correct the ephemeris data in GNSS receivers. Similar systems exists in the American
region (WASS) and the Far East (MSAS)
10 Spread Spectrum
If you have reached you then you have seen 3 examples of spread spectrum, all used for different
reasons. What they have in common is that a data stream uses a wider spectrum than it needs for
transmission, either to avoid noise, or because the way it is transmitted requires far more bits to
be transmitted.
Bluetooth uses Frequency Hopping. Bluetooth divides the 2.4 GHz band into 79 evenly spaced
channels of 1 MHz each. When a pair of devices connect they hop from one channel to another is
a pseudo-random way. This is to avoid interference with other devices in the 2.4GHz band – of
which there are many. Thus Bluetooth connections are more resilient to noise and interference.
ZigBee uses Direct Sequence Spread Spectrum (DSSS) to help overcome noise. When
transmitting using DSSS the ZigBee transmitter groups 4 bits together, and instead of
transmitting those 4 bits it instead sends a 32-bit CRC style polynomial. This improves noise
resilience. If a single bit flips in normal transmission then it is impossible to detect, but the 32-bit
patterns are unique – if a single bit flips the other 31 are still OK and that can be correlated to get
a near perfect match to the correct pattern – thus the correct 4 bit sequence can be recovered.
GPS used Code Division Multiple Access (CDMA) , which is an extension of DSSS. CRC style
polynomials have the fascinating mathematical properties that when a bit stream is multiplied by
one polynomial, and 'divided' by the worn polynomial then the resultant bit stream has a
correlation of zero. If however it is 'divided' by the correct polynomial it has a perfect
correlation. This phenomena is used to allow different satellites to share the same transmission
band. Each satellite is given a different polynomial with which to multiply its data. The receiver
captures the bit stream and then 'divides' that data block by all the know polynomials, only one
will work, thus identifying which satellite sent the data and recovering its data.