CSCI 3426  -- Telematics

Last updated Dec2017

Tutor
Ronnie Smyth rsmyth@dmu.ac.uk

Module Leader

Eric Goodyer eg@dmu.ac.uk

KEY REVISION TOPICS

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

Bit 14

Bit 13

Bit 12

Bit 11

Bit 10

Bit  9

Bit  8

Bit  7

Bit  6

Bit  5

Bit  4

Bit  3

Bit  2

Bit  1

Bit  0

Add 10

Add  9

Add  8

Add  7

Add  6

Add  5

Add  4

Add 3

Add 2

Add  1

Add  0

Response 

Len  3

Len  2

Len  1

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

Bit 30

Bit 29

Bit 28

Bit 27

Bit 26

Bit 25

Bit 24

Bit 23

Bit 22

Bit 21

Bit 20

Bit 19

Bit 18

Bit  17

Bit 16

Add 28

Add 27

Add 26

Add 25

Add 24

Add 23

Add 22

Add 21

Add 20

Add 19

Add 18

Add 17

Add 16

Add 15

Add 14

Add 13

Bit 15

Bit 14

Bit 13

Bit 12

Bit 11

Bit 10

Bit 9

Bit 8

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

Add 12

Add 11

Add 10

Add 9

Add 8

Add 7

Add 6

Add 5

Add 4

Add 3

Add 2

Add 1

Add 0

Response

reserved

reserved

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

Message Priority Level  0 to 7

Bit 28

Unused

Bit 27

Page Select (usually 0)

Bits 26/25/24/23/22/21/20/19

8-Bit PDU Format

Bits 18/17/16/15/14/13/12/11

8-Bit PDU Specific

Bits 10/9/8/7/6/5/4/3

8-Bit user defined

Bits 2/1/0

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
(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 Drivers 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 ECUs of the current torque mode

TABLE 7
ENGINE/RETARDER TORQUE MODES

Bit States Engine/Retarder Torque Mode 

0000

Low idle governor/no request (default mode)

0001

Accelerator pedal/operator selection

0010

Cruise control

0011

PTO governor

0100

Road speed governor

0101

ASR control

0110

Transmission control

0111

ABS control

1000

Torque limiting

1001

High speed governor

1010

Braking system

1011

Remote accelerator

1100

not defined

1101

not defined

1110

Other

1111

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 Drivers 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 INTERPRETED, you do not need to remember the above example, but you should be able to propose a data format for a variable of your choice.

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

CAN IDENTIFIER BITS

HEX Range

Identity usage

10

9

8

7

6

5

4

3

2

1

0

0

Group 1 ID

Source MAC ID

000-3FF

Message Group 1

1

0

MAC ID (source or destination)

Group 2 ID

400-5FF

Message Group 2

1

1

Group 3 ID

Source MAC ID

600-7BF

Message Group 3

1

1

1

1

1

Group 4 ID

7C0-7EF

Message Group 4

1

1

1

1

1

1

1

X

X

X

X

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 2nd 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

6

5

4

3

2

1

0

Meaning

Frag

XID

MAC ID

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

6

5

4

3

2

1

0

Meaning

R/R

Service Code

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

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.

IMAGE002 

 

IMAGE004

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
PDOs 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 SDOs to communicate with nodes, but this may not be the most efficient approach. Instead we can use PDOs 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 nodes 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 now common inmany behciles and is 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 articles 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. Signaling 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

LIN1

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

LIN2

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 or LIN 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

3.3 Direct Addresable Lighting Interface DALI

There is a WIKI page here that you can also use with the usual caveats about Wikis. DALI is an example of a widely used network protocol that is application specific. It has no links whatsoever to the more pervasive Internet based protocols, and is presented to you to demonstrate that not everything out in the owrld in web based. You will some examples of DALI based systems in Q 1.01, and DMU (via a Knowledge Transfer Programme or KTP) did assist with the development of Gateway to connect a DALI based LAN to a web portal.

You may find this application note from Microchip useful

DALI uses a 2-wire bus for signalling, with 0V +- 4.5V defined as a 0 and 16V +- 6.5V defined as a 1

Data is transmitted as 1200 BPS, using Manchester encoding. Manchester encoding is a widely used layer 1 format, which includes a clock bit embedded withint he data bit. Every bit must include a transition from either 0 to 1, or 1 to 0, in the centre of the bit. So the bit pattern 01 represents a 1 and 10 represent a 0. One way to rememebr this is that the meaning of the bit is given by the second half of the bit pattern - so 1 going 0 is a 0 and 0 going to 1 is a 1.

DALI is a very simple protocol. There is a single controller which communicates with up to 64 lighting devices. Each lighting device is assigned a short address which is 6 bits long. DALI can also support up to 16 groups of light devices, with each group assigned a 4-bit group address

The protocol consist of a 2 byte Forward Frame and a single Byte Backward Frame.

The forward frame format is as follows

BYTE 1 - YAAAAAAS

Where Y indicates if the command is for a specific lighting device 0 or is a group command 1
AAAAAA is either the 6-bit short address for a specific lighting device or a 4 bit group address of the form 00AAAA
S or Selector indicates if the second byte is a command 1 or a power level 0

BYTE 2 is a data or command byte as defined by BYTE 1

The backward frame is an 8 bit response.

What you need to know about DALI
DALI is a 2 wire protocl used to network lighting devices
A DALI network consists of a DALI controller and up to 64 DALI lighting devices
A DALI netowrk can also support up to 16 Groups of DALI devices
The protocol consist of 2-byte forward frame and a 1 byte response
Data rate is 1200 BPS and it used Mancehster Encoding - where 10 means 0 and 01 means 1
The format of a forward frame is YAAAAAAS DDDDDDDD
The format of a backward frame is just an 8 bit reponse

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 all 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) was established 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 published 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 - these IP based protocols now operate over 3G & 4G devices

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 PDAs 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 DMUs 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 MODEM 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.

A key advantage of using SMS is that it is the easiest way for a server to send a data message to a GSM MODEM. This is becuase the majority of GSM devices are not assigned a Statis IP address. In order to establish a connection as Sever sends an SMS to the MODEM reuesting that a connection is established, and the MODEM then connects to the server which does have a STATIC IP address.

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 and 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, 3G and beyond

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

GPRS is an IP based protocol, and i supwards compatible with the growing range of 3G MODEMS now available ont eh market, and will also be compatible with 4G and beyond.

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

4.5 3G and Beyond

Most mobile phones use the 2G bands - being 900MHz and 1800Mhz in Europe, and 850 and 1900 in the North America.

A dual band phone will support pairs of bands such as 850/1800 for Europe and 900/1900 for North America. Quad band phones allow roaming between Europe and America as they support 850/900/1800/1900.

For embedded data communciations 3G MODEM modules are now available, and these operate at 2100 MHz, offering higher data rates. 4G and byond are now also comning to market.

The good news for software developers is that the protocols used for GPRS (sometimes called 2.5G) are the same as those used for 3G

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.

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

Bluetooth

Range

10 100 metres

50 100 metres

10 , 100 metres

Networking Topology

Ad hoc self configuring mesh, peer to peer, star, or mesh

Hub and spoke arrangement

Ad hoc, very small networks

Operating Frequency

868 MHz (Europe)
900 928 MHz (North America)
2.4 GHz (worldwide)

2.4 and 5 GHz

2.4 GHz

Complexity (Device and application impact)

Low

High

High

Power Consumption (Battery option and life)

Very low (low power is a design goal)

High

Medium

Security

128 AES plus application layer security

 WAS for session layer and similar,  but none at application layer.

64 and 128 bit encryption

Typical Applications

Smart Metering, industrial control and monitoring, sensor networks, building automation, home control and automation, toys.

Wireless LAN connectivity, broadband Internet access

Wireless connectivity between devices such as phones, PDA, laptops, headsets.

Bandwidth

Typically low bandwidth, requirements. Up to 250 KBPS.

High bandwidth. 54 MBPS

Typically high bandwidth requirements. 100 MBPS.

Connection time

Fast typically 30ms

Slow 3 5 seconds

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

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 NEW MATERIAL HERE SINCE 2016

Low Power Radio Frequency is the generic term for low cost low power RF transceivers that use the licence free bands, 433MHz, 868Mhz and 2.4Ghz

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.

However the way these bands are uses strictly are regulated, and any developer has to abide by the agreed international standards. For example the 868 band is managed by European Telecommuncations Standards Institute (ETSI). Before we move on you need understand the difference between a Band, a Sub Band and a Channel. A Band is whole block of spectrum that is available, in this case 868.0 to 870.00 MHz. That is then split in to sub bands, each of which is governed by different rules. In the example below we are using sub band 4 which has a frequency range of 868.0 to 868.6 MHz. A radio transveiver will not make use of the whole sub band spectrum, as it is then divided again into narrower channels. In the example given the channels are spaced 50 KHz apart.

BAND The whole spectrum allocated for everyone to use for a specific general purpose
SUB BAND part of the band allocated for a specific use within the scope of that general purpose
CHANNEL a small part of the sub band used by a transceiver for a specific application that comes under the specific use

A good summary can by found on the Anaren data sheet for their 868 RF module. Have a look at Table 6 in this manual, which describes the rules associated with each sub band. One that you might use is band 4 which is defined for non specific use in the frequency range 868 to 868.6 MHz. Note that you are restricted to specific types of modulation, given in table 3, which must operate at specific data rates. Most important is the duty cycle which defines how much time you are allowed to tranmsit with respect to a period of silence. For example one valid set up would be to select Modulation Mode M7. M7 uses Gaussian Frequency Shift Keying (GFSK), which has two frequencies representing a 0 and a 1 (thus Frequency Shift Keying) but shapes the signal through a Gaussian filter to remove high frequency noise. The data rate is 38 KBPS with a channel spacing of 50KHz.

The 915 MHz band is used in the USA, CANADA and Australia, in preference to 868. What is often missed is that whilst 868 marks the base frequency of the 868 band, 915 is the centre of the 915 band in the Americas and operates between 902 to 928 MHz. However in Autralia the band stritctly starts at 915MHz. Care must be taken when designing for Australia, as the base band for a 915 MHz transceiver may be set to be 902 MHz; you will have to use a channel that is offset from the base far enough to be above the 915 MHz point.

For the purpose of standardisation the world is split in to 3 Regions

Region 1 consists of Europe, The Middle East west of the Persian Gulf, Russia and former states of the Soviet Union and Mongolia

Region 2 consist of the Americas, Greenland and some Pacific islands

Region 3 consists of the rest of Asia and Oceania (which includes Australia)

Each region has there own standradistion board, therefore system designed for Europe are unlikely to be suitable for the Far East, India, Australia and the Americas.

6.1 Modulation Techniques

In order to transmit binary data a radio signal needs to be in one of 2 states, a state that represent the data bit 0, and a state that represents the data bit 1. Various methods to achieve this have been developed over the years, and this is a summary.

Amplitude Shift Keying (ASK)
Perhaps the oldest method uses for radio communications, and one that you are unlikely to come across these days. ASK MODEMS operate over a single frequency, and the Amplitude (i.e. the 'volume' level) of the transmitted signal has a threshold, with a High level representing '1' and a low level represnting '0'. It is not used in modern systems, and is included only for completeness of this discussion.

ASK - amplitude shift keying
Copied from http://www.tmatlantic.com/encyclopedia/index.php?ELEMENT_ID=10420

Frequency Shift Keying (FSK)
FSK uses two different frequencies to represent a 1 and a 0. Variations on FSK include Gaussian FSK (GFSK) and Mulitple FSK (MFSK). GFSK passes the transmitted signal through a Gaussian filter in order to smooth out transitions between frequency changes. MFSK has uses multiple (> 2) frequencies in order to transmit more more data per transmitted 'symbol'.

This needs a brief explanation, as the term Baud Rate is often confused with Bit Rate, and they are not the same thing. When data is transmitted the transmission consists of a series of symbols, detrmined by the modultion method. For 2-FSK there are two symbols, as shown, being a short burst at one of two different frequencies. In effect a 2-FSK symbol can only represent 1 bit of data. If however we use 4-FSK which has 4 distinct frequencies then each symbol represents 2 bits of data

Frequency 1 = 00
Frequency 2 = 01
Frequency 3 = 11
Frequency 4 = 10

The rate of change of transmitted symbols is known as the Baud Rate. In the case of 4-FSK as each symbol represents 2 bits the Data Rate is double the Baud Rate.

FSK modulation techniques are widespread in the licence free bands.

FSK - frequency shift keying
Copied from http://www.tmatlantic.com/encyclopedia/index.php?ELEMENT_ID=10422&sphrase_id=38819

Phase Shift Keying (PSK)
PSK transmits data on a single frequency, with dirrent data bits being represetned by a phase shift. The picture below shows the simplest PSK technique, in which a change in phase represents a change in the data bit carried by the transmitted symbol. There are however more complex mechanisms, for example Quadrature phase-shift keying (QPSK) uses 4 phases, each 90 degrees apart, which means that the Data Rate is twice the Baud Rate. Whilst in theory many more divisions can be used, the highest rate in common use is 8-PSK as shown in the images below from Wikipedia.


PSK

http://www.tmatlantic.com/encyclopedia/index.php?ELEMENT_ID=10478&sphrase_id=38820


8-PSK  By Splash - Made by Splash using w:Inkscape., CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=613542

When you select a SUB-BAND in a licenced channel the relevent regulatory body such as ETSI will state what Modulation Techniques are allowed to operate in that band, the maximum power levels and the duty cycle.

What You Need To Know about Modulation Techniques
There are 3 main types of Modualtion. ASK, FSK and PSK. You should be able to describe what each is
FSK can use more than 2 frequencies, and PSK more than two Phases. Thus the actual Data Rate can be higher than the Baud Rate
When using a licence free transceiver you must abide by the rules maintained by the regulatory body, such ETSI or the FCC. These rules will state the following
1) The maximum width of the sub-band
2) The width of the channel within that band
3) The allowed modulation techniques
4) The maximum Baud Rate
5) The maximum duty cycle, e.g. 0.1% means that in any 1 second period the maximum amount of time that you can transmit is 1 ms

6.3 Networking Protocols

If you opt for LPRF rather than a proprietary network standard such as Bluetooth or Zigbee you will have to develop your own Network Protocol. A full discussion of network protocols is beyond the scope of this module; howver here are some basics.

Data Packet Length
Data packets are fixed length or variable length. Regardless of what method is used it is normal practice to make the first byte of any network packet a Length Field. This field contains the length of the following data, so if we are transmitting 32 bytes it will contain the number 31 meaning that 31 bytes now follow

Network Identifier
As more than one radio network could be operating in the same Channel you should include a field that identifies the network. This is similar to the PAN ID used in Z Wave.

Destination Address
As nodes are allowed to join the network they will be assigned a Node ID by the network controller. This is a unique identifier for that node, and is its 'destination address'. Other nodes that wish to send it a message must include the Destination Addres in the Network Packet

Source Address
This is optional depending upon the network strategy. The purpose of this field is to identify where the message came from.

Message Number
As all RF protocols require routers to forward Network Packets through the network it is inevitable that the Destination Address will receieve multiple re-transmissions of the same Network Packet. Therefore each transmitted packet needs to contain a numeric field that is incremented after each transmission. A receiver that receives messages with the same Message Number can then reject them. Similarly a Router should not forward a network packet that it has seen before, otherewise the Network will fill up with multiple and increasing re-transmissions.

Check Sum
The final bytes of any Network Packet should contain a CRC check sum. There are a range of standard check sums such as CRC16 and CRC32, for which code is freely available.


Length
Network Identifier
Destination Address
Source Address
Message Number
User Data
Check Sum


WHAT YOU NEED TO KNOW

A typical Network Packet will be structured like this

LENGTH
NETWORK IDENTIFIER
DESTINATION ADDRESS
SOURCE ADDRESS
MESSAGE NUMBER
DATA FIELD
CHECK SUM

6.4 LONG RANGE LPRF

With the growing demand for low cost wide area radio networks, to handle foe example Internet of Things (Iot) networks, new Lomg Range LPRF devices are coming on to the market. The current competing market leaders are LoRa and SigFox.

LoRa https://www.lora-alliance.org/ is a protocol with Semtech hardware that operates in the ISM bands as follows

LoRa Alliance European EU 863-870MHz
LoRa Alliance US + Canada US902-928MHz
LoRa Alliance Asia AS 923MHz
LoRa Alliance South Korea 920-923MHz

​​LoRa uses a Spread Spectrum technology known as a Chirp (Compressed High Intensity Radar Pulse). Using a range of frequencies from fMin to fMax, a chirp is a signal that either sweeps from Fmin to FMax (an up-chirp) or from fMax to to fMin (a down-chirp). Up and down chirps are used to frame a transmission packet, data however uses chirps that are frequency shifted (some sources call this phase shifting, but that is not really correct). A shifted chirp starts its frquency sweep from the mid-point of fMin and fMax, either sweeping up to fMax and then finishing from fMin to the midpoint, or in the other direction. These shifted chirps carry the data.

A LoRa packet starts with a preamble of 8 up-chirps, followed by two down-chirps which achieves synchronisation and marks the start of the data.

The image below is taken from http://www.sghoslya.com/p/lora-is-chirp-spread-spectrum.html


Here you will see 8 up-chirps , beign the preamble then 2 down-chirps used for receiver synchronisation. Thereafter you will see data symbols, which consist of a single chirp, but with a frequency shift. The amount of the shift determines the what the symbol is. Each symbol carries multiple data bits, dependent upon the number of different symbols supported in each implementation. The data is then followed by a CRC also consisting of symbols.

You will see in the image above that each chirp consists of a sweep over a frequency range of 125 kHz. There are three options available in the LoRa standard, 125kHz, 250kHz and 500 kHz.

SigFox uses a more familiar modulation technique Binary Phase Shift Keying (BPSK), also operating over the 868Mhz band and other ISM bands. SigFox uses an Ultra Narrowband in contrast to LoRa's wide spread specturm CHIRP technique. The Upload Data Packet contains 12 data bytes, whilst the Download Packet has 8 data bytes. The additional restriction is that the maximum upload rate is a maximum of 7 packets an hour and 140 packets a day. Dowload packets can only be issued 4 times a day.

Here are some URLs to sites that offer comparisons between these emerging standards.

https://raed.it/blog/iot-network-sigfox-vs-lora/

https://www.iotforall.com/iot-connectivity-comparison-lora-sigfox-rpma-lpwan-technologies/

http://www.rfwireless-world.com/Terminology/NB-IoT-vs-LoRa-vs-SigFox.html

So which is best? The market is still emerging and there are other comparbale RF products also competing for the opportinuities being delivered by the Internet of Things (IoT)

Both try to present themselves as 'open standards' but in reality LoRa relies on Semtech's RF chip and SigFox is a French company.

LoRa uses a spread spectrum technique, transmitting a CHIRP over a wide band (typically 125kHz), whilst SigFox uses an Ultra Narrow Band with DPSK modulation. Both achieve long range by have low data rates. SigFox requires a Vase Station, but there is a growing network of Base Stations similar to the way that GSM first spread by establishing Cells. LoRa does nto have such an infrastructure, which means it is more complex to establish an IoT network, but it does give you the advantage of any LoRa network that you develop being private. SigFox has strict restriction on the amount of data that can be transmitted per day, typically 12 bytes 140 times a day. LoRa has no restricton other than a requirement to ensure that you do not overload the transmission band as is true for any transceiver using an ISM band. SigFox offers mor Upload data bandwidth than Download - LoRa has no such restriction.

What you need to know about emerging IoT RF transceivers
The market leaders are LoRa and SigFox, but other systems are emerging. Both are presented as 'open' but in reality some aspect of the protocols are owned by a company
LoRa uses a CHIRP, being a sweep of frequencies usually 125Khz wide. SigFox uses an Ultra Narrow Band with Binary Phase Shift Keying
Both are low data rates to achieve range
SigFox requires a Base Station, but there is a growing network of them that you can connect to for a fee. SigFox also limits the data rates to UPLOAD 12 Bytes 140 packets a day and 7 per hour. DOWNLOADS can only be issued 4 times a day.
LoRa allows you to establish your own private network, and offers the ability to select different packet lenghts, but ISM restrictions will apply.

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

One well used protocol that is worthwhile understanding is RC5, which is the Phillips Remote Control protocol used in TV, DVD and similar handsets.

The format is as follows

1 Start Bit
1 Field Bit
1 Toggle Bit
5 Address Bits
6 Command bits

In all the data packet has 13 bits, with a start bit. Each bit is sent Manchester Encoded. This means that a 0 is sent as the binary pattern 10, the a 1 is sent as the binary pattern 01. Thus every bit always has a transition in the middle, which is used to help the receiver establish a clock that is synchronised to the transmitter. An easy way to remember the pattern is that the second bit is always the data level that you wanted   so 0 is 10, and 1 is 01.

The high level is modulated with a 36KHz signal, and the bit width contains 32 narrow pulses. If you do the maths this works out to a data transmission rate of 1125 BPS, where we count each data bit as requiring two transmitted bits due to the Manchester Encoding.

The 5 bit address field identifies the device being commanded. The original 6 bit command filed used to be sufficient for normal use, but with added complexity modern devices require more command, so what used to be a second Start Bit became the Field Bit, effectively doubling the number of commands from 64 to 128.

The toggle bit is used to prevent multiple actions from a single key press. It changes state every time a key is pressed. In normal operation the remote control repeats the key press until it is released, the receiver onyl acts on the received commands if the toggle bit changes state/

Here is a picture taken from Wikipedia that show this quite well

RC5

This website has some good images too, but has loads of adverts.  http://www.pcbheaven.com/userpages/The_Philips_RC5_Protocol/

There are other protocols that extend RC5, for example you could transmit 16 bits, with the first 8 bits being a COMMAND field and the second 8 bits being a DATA field. The receiver could also be required to acknowledge receipt of that command, thus creating a round trip transaction

What you need to know about IRDA
The RC5 protocol format

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 device, 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 >

The higher the frequency the greater the range. Low frequencies can manage typically a few cms. High frequencies can manage a metre or so.

What you need to know about IRDA
RFID tags operate at different frequencies, with higher frequencies offering higher range but needing more power
That RFID tags do not have their own pwoer supply, but obtain it from the transceiver that talsk to itThat more modern devices can be written to
That they are very insecure!

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.038N Latitude 48 deg 07.038 N
01131.000E 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). 
De Montfort 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 receivers 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), these are known as Space Based Augmentation Systems (SBAS).

An alternative to EGNOS is to use EDAS (EGNOS Data Access Service). EDAS offers an ehanced EGNOS data service, but it is accessed using an internat link rather that by satellite. As well as offering the same EGNOS data, EDAs also offers access to the Raw GPS, GLONASS and EGNOS GEO observations and navigation data collected by the entire network of Ranging and Integrity Monitoring Stations (RIMS) and Navigation Land Earth Stations (NLES). This allows local processors to determine a far more accurate fix from the raw GNSS derived satellite data.


What you need to know about GNSS
What are the names of  main satellite constellations
How is a fix obtained
What is the format of an NMEA string
What is the purpose of the SBAS, and how do they correct for GNSS errors
What EDAS is

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.

For really high grades you will be able to explain how Spread Spectrum methods operate, using the above examples.

11 Satellite Communications

http://www.gtc-usa.com/satphone/Coverage_Maps.html

There are
6 main SatCom constellations in operation today

Iridium
Global Coverage
1618.85 to 1626.5 MHz band
66 Sats in low earth orbit

Inmarsat
Global Coverage
Uplink1626.5 - 1660.5 MHz Downlink 1525.0 - 1559.0 MHz
3 Sats High Earth Orbit

Globalstar and SPOT
Partial Coverage
52 sats in low earth orbit
1610-1610.6 MHz

Thuraya
Partial coverage
2 satellites
1626.5-1660.5 MHz

Orbcomm
Partial Coverage
29 LEO Sats
137 to 150 MHZ
Data only services

Hylas

A new constellation intended for use in Europe, the Middle East and Africa
It uses the Ka band (microwave) to deliver fast 2-way digital communications. The Ka band is 26.5 to 40 GHz
It also has a broadcast capability in the Ku band of 12 to 18 GHz
If you are really wealthy, Hylas 3 can steered to a location of your choice to deliver optimum satcom services

Whilst they were originally developed for use in remote areas, offering high bandwidth services such as Satellite Phones and video transmission, there are now coming on stream low bandwidth channels, offering Short Burst Data (SBD). These are configured at a protocol level to look like GSM services.

Thuraya offer satphones and data only services The data services are IP based, so no need to learn any new protocols
Iridium offer similar services  But they do offer a module for embedded applications which opens up their services to OEM M2M applications
Inmarsat are the same. Of interest is their BGAN service launched to address the low bandwidth data market
Globalstar have a comparable range of services and offer a small module for embedded use
SPOT  (as far as I can make out) uses the Globalstar network to transmit a GPS fixed alert
Orbcomm only offer data services

For this module you need to be aware of Satellite Communications, and be able to name the main providers (Thurya, Iridium, Globalstar, Orbcomm & Inmarsat). All of them now offer a modern data only IP service. The also offer SMS style messaging. Some are now providing modules for embedded data applications.

12 Earth Observation

There are a large number of Earth Observation space missions which provide space imagery for use by terestrial systems. The data consists of images taken by the mission cameras, and it is the cameras that determine the purpose of that mission. Quite often the data is available free of charge, and these can be downloaded from data portals made available by the various space agencies.

One example is PROBA-V , whose purpose is to capture data related to Vegetation growth. The data portal website is http://proba-v.vgt.vito.be/

From this site you can enter the Data Access pages, and select data download.

proba

This is the screen that offers the data sets. PROBA-V uses a camera that records data at 4 different frequencies, being Blue, Red, Near Infra Red & Far Infra-Red. These images are processed to determine the Normalised Difference Vegetation Index (NDVI) for each pixel in the picture, with obscuration due to clouds, snow and ice removed.

The spatial resolution is either 100m, 300m or 1km square. TOA means Top of Atmosphere, TOC means Top of Canopy. TOA being above the atmosphere, and TOC being the vegetation cover of the planet. S1 are the daily images, but there are gaps as not all the planet is surveyed in 1 day, S5 are synthesised images, which stitch togther the 1 day strips and remove the cloud, snow & ice. S10 does the same for 10 days worth of data.

Enter the website and explore.

13 Developing your own protocol

Here is a general guide to designing your own protocol, you may not need all of the features given here for your project.

Length:
Data Packets can either be fixed or variable length. Fixed length packets are easier to construct and parse, but you may need to have a variable length protocol, in which case the receiver will need to have this information first. So if a Length Field is included it should be the first one in the packet.

Destination Address:
The first thing that a receiver needs to know is whether or not the incoming data packet is meant for it, or another device. If the network that you are developing requires point-to-point messaging then a Destination Address field is required very early on.

Packet Number:
It is useful to have a packet number field that increments modulo 256 (or similar) to allow a receiver to discard multiple receptions of the same packet.

Source Address:
A source address is required if nodes are able to send messages to each-other. This is not always the case, as many networks have a single controller that interroagtes other devices in turn, in which case a Source Address is not needed. However if your do need to support Pont-to-Point messaging you will need a Source Address Field.

Payload:
It is usual to define a fixed format for your payload, designed to make maximum use of the available bandwidth. So for fixed length messages you shold now define precisely what each bit & byte means. Consider compressing data, e.g. 8 On/Off signals fit into 1 byte not 8. If you have 2 12-bit analgoue signals they can fit into 3 bytes. Then you need to decide if you are going to transmit in Binary or HEX-ASCII. Binrary takes far less space, but HEX-ASCII is easier to read and therefore debug, but takes twice as much space.

Location:
You may need to include location data, whihc is usually the Latitude and Longitude fields found in a GNSS message

Time & Date Stamp:
It is usual to add a time stamp to any message, and a date might also be useful. A full ASCII time & date stamp can look like "DD/MM/YY HH:MM:SS", being date, month year, hour, minute second. Consider if all this data is needed, the server is likely to know the date, and may only need to know the time that the data was transmitted. Do you really need time be resolved to 1 second? e.g. if data is uploaed once an hour you only need to tag the message with the hour, not minutes or seconds. There are also data compression technquies, you can convert HH:MM into a long variable resolved to minutes (HH * 60 + MM) - HH:MM takes 5 bytes if sent as ASCII, whereas minutes sent as binary needs only 13 bits.

Check Sum:
To protect against corruption during transmission it is usual to include some sort of check sum which the receiver can use to test that the data packet was properly received. CRC16 is a very popular algorithm, but there are others.

Here is a simple CRC16 sub-routine that is available on the web ( THIS WILL NOT BE EXAMINED)

// open source CRC16 code

#define POLY 0x8408
// this is the CCITT CRC 16 polynomial X16  + X12  + X5  + 1 - note the bit pattern is reversed as the Least Sig Bit is shifted first

unsigned int crc16(unsigned char *data_p)
    {
    unsigned char packet_len;
    unsigned char i,length;
    unsigned int data;
    unsigned int crc = 0xffff;
    length = 5 ; // 5 bytes to do YOU NEED TO SET THIS TO THE LENGTH OF THE DATA PACKET
    packet_len = *data_p;
    data_p++ ; // skip length byte
    do
        {
        for (i=0, data=(unsigned int)0xff & *data_p++; i < 8; i++, data >>= 1)
            {
            if ((crc & 0x0001) ^ (data & 0x0001)) crc = (crc >> 1) ^ POLY;
            else  crc >>= 1;
            }
        } while (--length);
    return (crc);
    }