CSCI 3426 15 credit module -- Telematics

Last updated March 2012

Tutors Eric Goodyer eg@dmu.ac.uk    Brian Bramer bb@dmu.ac.uk

Coursework now available here

sample specification

HAND IN DATES

Thursday December 15^th 2011 - INTERIM BUT MARKS WILL BE AWARDED

Thursday April 26^th 2011 - FINAL

KEY REVISION TOPICS

CAN Lecture Slides Here

GNSS Lecture Slides Here

GNSS Extra Notes Here

GSM MODEM Slides Here

SMS useful website here

GPRS Slides Here

LPRF Slides Here

RFID + IRDA + Spread Spectrum Slides Here

Here are Project Offerings

CAN LAB WORK SHEET1 HERE
CAN LAB WORK SHEET2 HERE
CAN LAB WORK SHEET3 HERE
CAN LAB WORK SHEET4 HERE

GSM LAB WORK SHEET 1 HERE
GSM LAB WORK SHEET 2 HERE
GSM LAB WORK SHEET 3 HERE
GSM LAB WORK SHEET 4 HERE

 I can be contacted on email eg@dmu.ac.uk

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).

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.

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

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 nt 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
 

 
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 high-speed 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

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 27-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 27 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 =     0000 0111 1000 0000 0010 0000 0000 0000
Mask =         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       IDENTIFIER
1111 0000 0000 0000 0000 0000 0000 0000        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.

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 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.

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

The real-time transfer of data between peers is achieved by means of PDOs

 An SDO Is used to access a node’ setup. Configuration and data. 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 data sheets 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 K BUS

K BUS Telegrams

K bus is a multi-drop single-master/multi-slave standard used for vehicle diagnostics. It uses a single wire, in half-duplex mode, that is pulled high to represent a logic level 1. Data is transmitted in packets known as telegrams at 0600BPS. Each byte being very similar to an RS232 transmission, with an 8-bit data byte, with even parity, being encapsulated with a start bit and a stop bit. Contention is managed by the master device, in that a slave can only gain access to the bus in response to a data request from the master. The key to managing  the protocol is to maintain periods of silence, to allow other units to react to and if required respond to the latest telegram.

These delays differ depending upon whether you are a transmitter or a receiver, this is to allow for propagation delays in the network.

For a transmitter -
    The delay between characters within a telegram must be less than 0.8ms
    The delay between telegrams must be more than 1.7ms

For a receiver
    The delay between characters within a telegram must be less than 1.1ms
    The delay between telegrams must be more than 1.1ms

By obeying these rules each telegram can be 'framed' as it will always exist between periods of silence, known as the Idle Time.

A telegram has the following format

    TRANSMITTER     1 BYTE                   Being an 8-bit address that identifies the sending unit
    LENGTH                1 BYTE                   The total number of bytes that follow in this telegram
    RECEIVER             1 BYTE                   Being an 8-bit address that identifies the intended receiver unit
    COMMAND          1 BYTE                    The command (e.g. enable, disable, my data is, set to etc.)
    DATA                     0 TO 32 BYTES       Optional data that is command dependent
    CHECKSUM           1 BYTE                    XOR vertical check byte

Multiple commands can be linked together into a single telegram 

What you need to know about KBUS

KBUS supports a multi-drop bus structure.
Bus arbitration is achieved by applying strict timing rules to the issuing of telegrams
It is a single-master multiple-slave protocol.
The data format is [Tx ID][Length][RxID][Command][Optional Data][Command2][Optional Data]….[CSUM]

3.2 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.3 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 for ETSI, and can be downloaded from their web-site www.etsi.com

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 Wavecom, Siemens, Falcom, Telit and Sony Erricson. 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 dialling format. Which is recommended for GSM use, as it is a global service – though national dialling 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 dialling 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 CONECTION

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.

The complete Bluetooth specification is available here.



The above figure shows the construction of an HCI command.  Each command is assigned a 2 byte Opcode used to uniquely identify different types of commands. The OpCode parameter is divided into two fields, called the OpCode Group Field (OGF) and OpCode Command Field (OCF). The OGF occupies the upper 6 bits of the Opcode, while the OCF occupies the remaining 10 bits.


These are examples of available OGF command groups >
HCI Link Control Commands OGF = 0x01
SPP protocol OGF = 0x30
Vendor specific commands OGF = 0x3f

For example, the HCI command to instruct a module to enter the enquiry mode is 0x4001, where the OGF is 0x01 and the OCF is 0x001. The OGF are the upper 6 bits of the 16-bit command. The rest of the packet contains the command parameters. It is beyond the scope of this module to cover the format of the commands.

The SPP command 'Request Remote Name' is 0xC04D, where the OGF is 0x30 and the OCF is 0x04D. The complete packet is 0x4D 0x30 0x00. Note that the 16-bit values are sent LSB first, and that there are no parameters.

It is usual to encapsulate the HCI packet in a link level frame. If the distance is short then you can use the default lead-in byte 0x01, which is the ISO2022 (ASCII) code for Start of Text.

When a command is issued the baseband module issues a response known as an EVENT,


The event code defines what the event is, the rest of the packet contain event parameters.

Once a unit has connected that the baseband module is able to return data packets.

It is very rare that you will be required to develop code at the HCI level, but an overview of what it is essential to understanding Bluetooth.

What you must know about HCI
It is the lowest level protocol that allows an external host to communicate with a baseband module
All command are based on a 16-bit command, of which the top 6-bits are the OGF, and the lowes 10-bits the OCF. The OGF defines the command group, such as Link Level, or SPP. The OCF defines the command.
The rest of the command packet contains the command parameters, which start with a length counter.
The HCI command is encapsulated in a link-level frame, which can be no more than an STX byte.
The baseband module replies with Event or Data packets.

More common protocols that are used are SPP or Serial Port Protocol, and customised AT command sets.
SPP is an early and effective attempt to provide a more usable protocol than HCI. HCI is mainly concerned with the management of the RF link, and whilst it offers everything that is available with SPP, it is more complex to use. SPP provides a suite of basic commands that are built up form HCI, such as CONNECT, INQUIRE, PAIR etc. A full specification can be found here

For example the SPP connect command is 0x01 0x82 0xC0 0x06 0xBB 0xBB 0xBB 0xBB 0xBB 0xBB


where 0x01 is STX
0xC082 is the SPP command for CONNECT
0x06 is the parameter length
0xBB .... 0xBB are the 12 HX bytes that make up the board address of the module that we wish to connect to
SPP was specifically designed to support pairing, connecting and data transfer usig serial ports.

Even easier are the new range of AT command sets available tha allow you to perform a range of HCI and SPP commands using extensions to the Hayes command set. These are not standardised!! Every manufacturer has developed their own command set. For example you can find the TDK command set here.
Using TDK AT commands the connect command becomes the text string ATDBBBBBBBBBBBB, where BB...BB is the board address.
 
What you must know about BlueTooth, SPP and AT commands
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
Whilst HCI is the lowest level protocol that allows a host to talk to a baseband module, most applications use higher level protocols such as SPP and AT command sets

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

In addition to supporting the a personal Area Network 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 request 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.

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.

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 vert 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 System (GNSS). 
DeMontfort are working with Nottingham Scientific 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 receiever which satellites are closest to the receiever. 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)

9 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.