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