Fleet Management Services in
GSM-modules
Master thesis
Performed in Electronics Systems Performed for Scania CV AB
by Nils Hellström
LiTH-ISY-EX--07/4025--SE 10th March 2007
Fleet Management Services in
GSM-modules
Master thesis
Performed in Electronics Systems, Dept. of Electrical Engineering
at Linköpings universitet Performed for Scania CV AB
by Nils Hellström
LiTH-ISY-EX--07/4025--SE
Supervisor: Mathias Björkman Scania CV AB Examiner: Kent Palmkvist
Linköpings Universitet Linköping, 10th March 2007
URL för elektronisk version
http://www.ep.liu.se
Publikationens titel
Fleet Management Services in GSM-modules
Författare
Nils Hellström
Sammanfattning
This report studies a low cost hardware platform for Fleet Management Services, FMS. The platform manages vehicle data, positioning and wireless communication. The core of the platform is a new kind of ‘intelligent’ GSM modem, called a GSM module. A GSM module is basically a stripped down mobile phone that allows embedded third party application code and has an IP-stack. The report reviews the modules available on the market today and presents experiences from the implementation of a prototype based on the Aplicom A12 module. The main conclusion is that the concept is feasible though the modules' limited performance must be considered in the design.
Antal sidor: 71
Nyckelord
Fleet Management, GSM Module, Controller Area Network, GPS
Språk
Svenska
X Annat (ange nedan)
Engelska Antal sidor 71 Typ av publikation Licentiatavhandling X Examensarbete C-uppsats D-uppsats Rapport
Annat (ange nedan)
ISBN (licentiatavhandling) ISRN LiTH-ISY-EX--07/4025--SE Serietitel (licentiatavhandling)
Abstract
This report studies a low cost hardware platform for Fleet Management Services, FMS. The platform manages vehicle data, positioning and wireless communication. The core of the platform is a new kind of ‘intelligent’ GSM1 modem, called a GSM module. A GSM
module is basically a stripped down mobile phone that allows embedded third party application code and has an IP2-stack. The report reviews the modules available on the
market today and presents experiences from the implementation of a prototype based on the Aplicom A12 module. The main conclusion is that the concept is feasible though the modules' limited performance must be considered in the design.
Contents
1
INTRODUCTION... 1
1.1 Background ...1 1.2 Project requirements ... 2 1.3 Resources... 3 1.4 Limitations ... 3 1.5 Thesis outline ... 3 1.6 Acknowledgements ... 32
UNDERLYING TECHNOLOGIES... 5
2.1 Wireless communication ... 5 2.2 Internet Protocol ... 92.3 Global Positioning System, GPS ... 11
2.4 Controller Area Network, CAN... 13
2.5 Input/Output ... 18
2.6 Supported programming languages... 19
3.4 Remote update... 25
3.5 Producers ... 26
4
REVIEW OF THE GSM-MODULE MARKET ... 27
4.1 Data table... 27
4.2 Aplicom A12 ... 28
4.3 Siemens TC65 ... 29
4.4 Telit GM862-GPS...31
4.5 Wavecom Q2501B ... 34
4.6 Sony Ericsson GA64... 35
4.7 Motorola G24 ... 37
5
PROTOTYPE IMPLEMENTATION ... 39
5.1 Software... 39 5.2 Hardware ... 42 5.3 Test ... 446
DISCUSSION... 49
6.1 Aspects on selecting a GSM-module... 49
6.2 Future of GSM-modules ... 52
7
CONCLUSIONS AND FUTURE WORK... 55
7.1 Conclusions... 55
7.2 Future work... 57
REFERENCES ... 59
Tables & Figures
Table 2.1 Example of GPRS classes……….………. 8
Figure 2.1 Repeating time slots of a GSM channel.……… 6
Figure 2.2 Rough structure of a GSM network..………. 7
Figure 2.3 Time slot usage of a GPRS channel...……… 8
Figure 2.4 Rough structure of a GPRS network.……… 9
Figure 2.5 IP-stack layers………….………... 10
Figure 2.6 CAN bus signalling...…..………... 14
Figure 2.7 CAN bit ………..……….. 14
Figure 2.8 Fields of a CAN message………... 15
Figure 2.9 CAN bus arbitration …...……….. 16
Figure 2.10 Fields of the CAN message identifier according to J1939..……… 17
Figure 3.1 Siemens TC65 module………... 23
Figure 3.2 Traditional architecture of a device with GSM connectivity………... 24
Figure 3.3 Aplicom A12 test board ….………... 25
Figure 4.1 Data flow of the Siemens TC65 ….………...……… 31
Figure 4.2 Software environment of the Telit GM862-GPS...……….… 33
Figure 4.3 DOTA procedure……….. 35
Figure 4.4 Architecture of the Sony Ericsson GA64.……….. 36
Figure 4.5 Hardware architecture of the Motorola G24..……….……... 37
Figure 5.1 Examples of pentagons and positions……….………... 41
Figure 5.2 Hardware architecture of the project prototype ….………... 43
Figure 5.3 Memory usage………... 46
1 Introduction
This final thesis for a Master degree in Applied Physics and Electrical Engineering was carried out at Scania Fleet Management at Kista, Stockholm Sweden. The aim of the thesis is to study a low cost hardware platform for Fleet Management Services, FMS. FMS demands that the platform manages vehicle data, positioning and wireless communication. In a traditional hardware platform architecture, the core would have been a micro controller controlling different units such as vehicle interface and GSM-modem. During the past three-four years, ‘intelligent’ GSM modems have emerged that allow embedded third party application code. This eliminates the need of an external microcontroller and the GSM unit can work as ‘central intelligence’ of the platform. This project will study the potential of such an architecture and evaluate the GSM modules available on the market today. It is hard to evaluate a concept solely from documentation. A large part of the project time was therefore devoted to putting together a working prototype. Lessons learned from this are discussed in the final chapter.
1.1 Background
The following two paragraphs give some background to the project. 1.1.1 Fleet Management Services
With the increased competition in the hauling business, companies look for ways to improve their efficiency. FMS is an umbrella term for applications that aim at improving the overall performance of a hauler’s fleet in terms of fuel economy, maintenance costs, utilisation level, etc. FMS’ main advantages are better transport coordination, better vehicle and driver follow up, faster and more precise invoicing, and faster assistance in case of a road side breakdown.
One example of a simple FMS application is the logging of fuel consumption over mileage. The transport company can then address drivers that have higher fuel consumption with instructions on more economic driving, or have a bonus system based
on fuel economy. Fuel costs today accounts for about 40 percent of a hauler companies expenses [ref 16]. A decrease in fuel consumption of just a few percent would pay back the investment in very short time. Another application is extending the office Transport Management System so that driving orders can be forwarded wirelessly to the truck. This gives a much more flexible ordering system then if all orders have to be handed out at the beginning of the day. In addition, the invoicing charge can be sent the minute the delivery is completed. With a GPS3 connected to the system, the hauler company also gets a
receipt of that a delivery was at a certain position at a given time. 1.1.2 Hardware foundations for FMS
The FMS applications described in the previous paragraph requires new hardware and software in the truck for monitoring vehicle parameters, positioning of the vehicle and for communication. The Scania offer today is based on a rugged Windows XP Embedded PC that is installed in the truck’s dash board. Apart from standard PC features, it is equipped with hardware to listen to the vehicle communication bus, a GPS, and a GPRS4 modem. The PC monitors the truck and communicates wirelessly with a
Scania server. The server process incoming data and presents it on an internet portal at which the hauler company can monitor truck and driver performance. The PC has a touch screen so that it can also be used for order support, navigation and third party software.
A full-fledged PC is over skilled for many FMS applications that don’t demand a user interface. To only monitor and send in vehicle and positioning data, something much simpler and cheaper could be used. The GSM-module based platform studied in this thesis is a candidate.
1.2 Project requirements
The project was divided into two parts with the following requirements:
Part one of the project should evaluate GSM-modules on the market today to see how suitable they are for an FMS platform. Part two should result in a GSM-module based prototype. The prototype should take requests from, and send data to a server according to a specified protocol. It should handle Controller Area Network, CAN, and Global Positioning System, GPS, data and wireless communication by IP over GPRS.
The results should be described in a report, including a review of evaluated GSM-modules and future prospects for them as hardware platform for FMS. Particularly the implementation of a connection to the CAN-bus should be investigated. An outline of the prototype implementation should be given. The report should also include a brief introduction to technologies used
3 Global Positioning System
1.3 Resources
This thesis has a focus on product development so the investigating part of the thesis concerns product review and evaluation. Therefore, much of the resources have been data sheets and product specifications, rather than scientific articles.
GSM-module documentation has been acquired as PDF files from web pages of hardware manufacturers. Apart from the usual methodology of smoothening over a product’s weaknesses and stressing its powers, these sources could be considered to be accurate. Notes have also been taken from meetings with sales representatives for every studied GSM module except Sony Ericsson and Motorola. The art of glorifying is even more present here than in product specifications.
The technologies studied in the project are all mature and in wide use. A vast literature exists for each of them. They are not breakthrough news to be very sceptic about, but more standards documentation.
1.4 Limitations
This thesis will study the GSM module concept. No comparison to other types of hardware platforms will be made.
Only the GSM module unit of the suggested FMS hardware platform will be evaluated. No evaluation will be done on platform peripherals, e.g., CAN interface and GPS.
The main aim is to study the strengths and weaknesses of the GSM module concept, not to find a winning candidate among the modules available.
The chapter on underlying technologies gives an orientation to help the reader understand possibilities and limitations of the studied task. It is not meant to be a complete description.
1.5 Thesis outline
Chapter two of this thesis report gives a brief introduction to technologies used in the project. This chapter can be skipped by readers already familiar with the technological background. See the reference list for a more thorough background survey. Chapter three covers the concept of a GSM-module. Chapter four is a review of GSM-modules on the market today. Chapter five deals with the prototype implementation and lessons learnt from it. Chapter six discusses key features to examine when selecting a GSM-module. Finally, chapter seven gives some conclusions and suggestions on future work.
1.6 Acknowledgements
I am grateful to many people at Scania Fleet Management for their support with my thesis, especially my instructor Mathias Björkman and my supervisor Peter Madsen. I would also like to thank my examiner at Linköping University, Kent Palmkvist.
2 Underlying technologies
This chapter will explain the fundamentals of technologies used by the project prototype. It is not meant to be a complete description, but rather an orientation to help the reader understand possibilities and limitations of the studied task. Readers already familiar with the technological background can skip this chapter. For a more thorough study, see the references at the end of the report.
2.1 Wireless communication
[Paragraph 2.1 is based on ref 1]
When data needs to be sent from a moving target, or from remote locations, wireless communication is desirable. There are a number of techniques available with different focuses regarding range and bandwidth. The application of this project has low demands on bandwidth, but requires country wide coverage. For this type of applications GSM/GPRS is the most suitable candidate today.
2.1.1 GSM
The Global System for Mobile telecommunications, GSM, standard was developed in the eighties to address the problem of compatibility between numerous telecommunication systems that had emerged. A first version of the standard was completed in 1990. Since then, the system has been adopted around the world, and new versions of the standard have been released, allowing higher data rates and new features in the networks.
The basic GSM network is circuit switched, just like an ordinary land line telephone network. When a call is established between two nodes, the link in-between is busy, regardless of anything is being said/transmitted or not. To allow many simultaneous calls over the radio link, GSM uses multiple frequency channels around its basic working frequency, 900 MHz. One set of frequencies is used for uplinks and one set for downlinks. These frequency channels, in turn, use Time Division Multiple Access,
TDMA to further increase the number of parallel lines. TDMA means that a channel is chopped up into a set of repeating time slots. Each (cell phone) connection has its own repeating time slot in a channel. (see figure 2.1) The cell phone samples some speech, compresses it and sends it in its next slot. For this to work, the time to transmit one second of compressed speech has to be much shorter than one second.
Figure 2.1: Repeating time slots of a GSM channel.
The GSM network is divided into cells, with each cell having its own Base Station System, BSS. The BSS contains a radio transceiver and a controller. The controller handles the radio channels and forwards calls in the cell to a switching centre in the network. The switching centre in turn routes the call onwards to the target BSS or to another network. The GSM network also contains a set of data bases which contains information about attached cell phones, their rights and statuses. See figure below.
Figure 2.2: Rough structure of a GSM network. 2.1.2 GPRS
An extension to the GSM standard called General Packet Radio Services, GPRS, was released in 1997. GPRS allows packet based data to be sent in the GSM network and onwards through gateways to the internet using standard internet protocols. This also implies that computers connected to the internet need no special hardware to communicate with a GPRS device.
Data to be sent is first divided into small pieces, packets. The individual packets are then sent as soon as there is a time slot available in the network. Finally, transmitted data is reconstructed from the packets at its destination. See figure 2.3. No user ‘owns’ a repeating time slot, as in the basic GSM network. This allows a more efficient use of the bandwidth. When user A doesn’t need any time slots, user B can have them and vice verse. Both users can still be constantly attached to the base station, much like an internet broadband connection, ready to send or receive. Network operators often employ a tariff scheme where users pay for the data actually sent, not the time period he is connected. The pay-per-byte nature of GPRS makes it ideal to use with remote devices that need to be constantly connected to other devices, or to a central server, but only exchanging small amounts of data spread over long periods of time.
Figure 2.3: Time slot usage of a GPRS channel.
A GPRS device can only send at one frequency at a time (use one channel), but it can use more than one slot in each time slot cycle of that channel to increase its bandwidth. GPRS devices are divided into classes according to the number of time slots they can make use of. Performances range from utilising one slot in each direction in class one, to four slots in one direction and one in the other (4+1 or 1+4), in class 12. See table 2.1. The theoretical data rate, when using one slot, is 13,400 bits per second, giving 53,600 bps for class 12. These 53,6 kbps is the “raw data” rate; up to 25 percent thereof is used for error correction and redundancy, leaving about 40 kbps for user data.
Table 2.1: Examples of GPRS classes. ‘Active slots’ gives the maximum number of simultaneously utilized slots. For example class 11 supports up to four slots for the uplink and up to three slots for the downlink,
but it can only use a total of five slots simultaneously.
A GSM network needs new software and hardware to handle GPRS. For example, the base station controller needs software to manage new coding schemes. GPRS data is sent from the BSS to GPRS support nodes in the network. They have roughly the same functionality as the switching centre in GSM. The routing to and from other IP based networks (internet) is done through gateways. See figure 2.4.
GPRS class Uplink slots Downlink slots Active slots 2 2 1 3 4 3 1 4 6 3 2 4 8 4 1 5 11 4 3 5 12 4 4 5
Figure 2.4: Rough structure of a GPRS network.
Assignment of an IP address to a unit is done dynamically by the network operator, i.e. a unit’s IP address will change over time. This means that there is no way for a server that wants to contact a unit to know its IP address for sure. Lately specialised operators utilize a Domain Name System, DNS, to give a unit a static public IP address. The operator then routes incoming requests to the public IP address through the DNS server to the unit’s current dynamic IP address.
2.1.3 Alternative communication technologies
One of the requirements of the FMS platform is “real time” positioning. This condition disqualifies any solution with logging of data for later transfer via e.g. WLAN5 at a depot.
The only alternative today and for years to come, that support packet based transmission country wide, is 3G6. The data rates of 3G are not needed by the FMS platform’s current
specifications and the price of a 3G module is approximately three times that of a GSM module. An advantage of 3G is that network operators tend to have lower prices per mega byte of transferred data.
2.2 Internet Protocol
[Paragraph 2.2 is based on ref 2]
The Internet Protocol Suit, IPS, has been used since the beginning of the eighties for communication between remote computer systems. With the introduction of GPRS in the GSM network, GSM devices could adopt the same suit of protocols to communicate with computers on the internet.
Data to be sent from a device over the internet faces an elaborate scheme. It needs to be packed and wrapped before it can be transmitted, and control mechanisms are needed to
5 Wireless Local Area Network
make sure it reaches its destination. An application sending data usually needs not to worry about all this. The required functionality is provided at a lower level by the IPS. IPS has a layered architecture. The bottom layer handles the physical link; sending and receiving of raw bits. The top layer provides an interface that applications can use. Each layer in between handles its own part of the transmission. A layer only serves the layer immediately above and only makes requests to the layer immediately below. With well defined interfaces between the layers, this makes for a flexible and easily maintained architecture. This approach is promoted in the more general Open Standards Interconnect, OSI, model and is often called a protocol stack, in this case an Internet Protocol stack, IP-stack. The layers of the IP-stack are a subset of those defined in the OSI. The IP-stack layers are outlined in figure 2.5.
Application Layer Provides means for an application to access and configure the communication stack to send and receive data. This type of interface is generally called Application Programming Interface, API. Transport Layer Provides data delivery services, containers to send and receive data in. Two different protocols can be used in this layer; User Datagram Protocol, UDP, or Transmission Control Protocol, TCP.
Routing Layer Establishes connections and routes data between systems. The Internet Control Message Protocol, ICMP, is used by this layer to fulfil its tasks.
Physical Layer Handles flow control of data between systems and has a direct connection to the physical transfer medium.
Figure 2.5: IP-stack layers.
The main option for the application programmer when configuring an IP-stack is, apart from the targets addresses, the use of either TCP or UDP. TCP provides a controlled channel to the target. It makes sure that everything that is sent is delivered to the recipient, and that it is delivered in the right order and without errors. To handle this, TCP contains sequence numbers and timers to control sent data and retransmit when data get lost. UDP lacks all this. There are no guarantees that data sent by UDP arrives correct at the destination, or that it arrives at all. The control mechanisms of TCP create a lot of overhead to the ‘useful’ data. In some applications, the security of TCP can be traded for the lower bandwidth demanded by UDP. A relevant and illustrative example: a truck is to send in its position to a server every minute via GPRS. Firstly, GPRS bandwidth is limited and expensive, so we want to keep data sent to a minimum. Secondly, the positioning data is of the kind “fire and forget”. If one positioning message would get lost in the transfer, it would almost be outdated before it was resent, and the lost data would have a marginal impact on the system. The choice here is UDP. Some data integrity and flow control checks are usually implemented in higher level protocols when using UDP.
2.3 Global Positioning System, GPS
[Paragraph 2.3 is based on ref 3]
The Global Positioning System, GPS, was developed by the United States Department of Defence during the seventies and eighties and became operational in 1993. The system works in two parallel modes; one with higher precision that is encrypted and reserved for US military, and one with less precision that is free to use by the public. An ordinary civilian GPS has an accuracy of about 15 meters. The core of the GPS infrastructure consists of 24 satellites in orbit (plus three used for backup) and a set of satellite tracking stations around the world. The satellites send positioning data and system information to users on earth. Each satellite transmits at two frequencies, one for civil and one for military use.
2.3.1 Triangulation
GPS positioning is based on triangulation. A GPS receiver on earth first measures its distance, R1, to one of the GPS satellites, S1. The receiver has then pinned its position
down to a sphere with radius R1 around S1. By repeating this procedure for two more
satellites the receiver has three spheres that intercepts in two points. One of these two points can be discarded as being to far from the earth; the other interception point is the receiver’s location. There is a fourth variable added to the three ‘room’ dittos: relative time of the clocks in the satellites and receivers. Therefore a fourth satellite is required to solve the equation. The reason for is described in more detail in the next paragraph. 2.3.2 Technical issues
For the positioning to have a meaning, the receiver must know where the satellites are relative to the earth. The receiver also has to have some accurate way to measure distance. The first problem is not so hard. Orbits of the satellites are stabile and can be predicted with high accuracy by mathematical formulas. In addition to this, tracking stations around the world monitor the satellites positions and update them when they are off course. The satellites in turn, send correction data to the GPS receivers. The receivers store the positions of the satellites and can then calculate satellite positions for the coming time intervals, until the satellites send the next position update.
To measure distance, a given predefined pseudo random code is transmitted by the satellite starting at a given time. At the same time, the receiver starts to generate the same code. By correlation, the receiver then measurers the time offset between its own code and that received from the satellite. The signal from the satellite is an electromagnetic wave with finite speed, c. Multiplying the time offset, ∆t, of the two codes with c gives the distance between satellite and receiver. Additional techniques, including measuring the phase of the signal carrier, can be used to enhance precision.
The critical part of the distance measurement is timing, which must be extraordinarily precise. If the two clocks of a satellite and a receiver are off by just 1 microsecond, the error in distance measurement will be 300 m. The satellites use highly accurate atomic clocks that keep the system ‘GPS-time’. To equip a receiver with an atomic clock would make it very expensive. Instead, the receiver hosts an ordinary quartz clock which is continuously set by the atomic clocks of the satellites. As mentioned above, three dimensional positioning requires three ‘visible’ satellites, if all parts keep the same time.
In practice, there is a fourth variable; the offset between the receiver clock and GPS-time. To solve the equation, a total of four visible satellites are required. Four variables and four equations, one for each satellite, gives a definite solution.
The requirement of four visible satellites is fulfilled 95 % of the time in all places around the world. The probability is better in populated areas where usually six to eight satellites can be spotted. Each satellite is called a channel. “Number of cannels” is a marketing feature for GPS- receivers. A 6-channel receiver can monitor six satellites simultaneously, making more precise positioning possible.
2.3.3 Error sources
The main limitation of GPS accuracy used to be the Selective Availability, SA. This was a random bias applied to the civilian satellite signal by the US Department of Defence to limit non-military accuracy. The SA was turned off in the year 2000, enhancing GPS accuracy by a factor of 10. The main limiting factors of GPS accuracy today are path errors. The satellite signal bounces on atmosphere and items in the receiver’s vicinity, making the path travelled longer then the straight line assumed. A more severe limitation is that the satellite signal can be completely blocked by buildings in “city canyons” or in tunnels. The GPS signal, coming form a satellite in orbit, is very weak compared to, for example, a GSM signal, making it very sensitive to blocking. This error can be partly worked around with “dead reckoning” by use of accelerometers.
2.3.4 NMEA protocol [Paragraph 2.3.4 is based on ref 4]
The de facto standard communication protocol to get positioning data from a GPS receiver is developed and controlled by the US National Marine Electronics Association, NMEA. The standard is aimed at marine electronics, and GPS communications is a subset of it. The most common version, NMEA 0183, is quite simple and allows one talker (in this case the GPS receiver) to send ASCII character ‘sentences’ to one or more passive listeners, for example a navigation device.
Apart from the physical matters the standard defines a set of sentences to declare, for example; position, current time, system status, etc. These are transmitted in a loop by the talker. The sentences can be decoded by a compatible listener, (computer, PDA) which can then process the data further. Below is an example of the NMEA sentence GLL, Geographic Position – Latitude/Longitude.
1 2 3 4 5 6 7 8 | | | | | | | | $--GLL,llll.ll,a,yyyyy.yy,a,hhmmss.ss,a,m,*hh Field Number: 1) Latitude 2) N or S (North or South) 3) Longitude 4) E or W (East or West)
5) Universal Time Coordinated (UTC)
6) Status A - Data Valid, V - Data Invalid 7) FAA mode indicator (NMEA 2.3 and later) 8) Checksum
2.3.5 Competing positioning systems
A global navigation system similar to GPS was developed in Russia in parallel with the US development. The Russian system is called GLONASS, Global'naya Navigatsionnaya Sputnikovaya Sistema. It was fully operational for a while in the mid nineties, but declined along with Russian economy. The system is again gaining momentum, with planned world coverage by 2010.
The European Union is developing their own navigation system, Galileo, with partners including China and Israel. Galileo is planned to be operational in 2008. Both of these systems provide roughly the same accuracy as GPS, but it will be some time after their launch dates before the market for receivers is as developed as that for GPS. Because of this, these systems will not be real competitors to GPS for a long time.
A different approach to positioning which is under development, is through GSM-networks. It is based on a number of techniques involving radio frequency signal strength from different GSM base stations. Coverage of the system is limited to GSM-network coverage, and accuracy today is about 200 m in urban areas, decreasing to 4 km in rural zones, compared to about 15 meters for an ordinary GPS.
The conclusion is that as of today and coming years, there are no real competitors to GPS.
2.4 Controller Area Network, CAN
[Paragraph 2.4 is based on refs 5, 7 and 8]
The Controller Area Network, CAN, is a standard for a communication bus. It has focus on robustness and communication with high message rate but only a few bytes of data per message. This makes it ideal for embedded system with distributed intelligence, may it be in a truck or a automated production line. The CAN bus’s wide use in (automotive) industry today is also biased by the availability of very low cost protocol chips.
2.4.1 Physical layer
The CAN standard supports different physical layers for different bus speeds and different levels of fault tolerance, with bit rates up to 1 Mbit/s. As for the wiring, it is most common to use two balanced wires, called CAN_High and CAN_Low. The signal level is defined as voltage difference between the two wires. This setup is more tolerant to electromagnetic disturbances, EMC, than if the signal level would be measured with respect to ground, see figure 2.6. Non-Return-to-Zero, NRZ, signalling is used, see figure 2.6. The standard does not use a central clock, instead each node synchronises on signal level flanks. To ensure proper synchronization, that is, enough flanks to synchronize on, bit stuffing is used to avoid long trains of equal bits in the NRZ coding scheme. The bus has to be properly terminated by a resistor at each end to avoid reflections. The standard does not specify any connectors to be used, but the 9-pin DSUB7 is very common.
7 A type of electrical connector
Figure 2.6: CAN bus signalling.
Each bit of the CAN message is divided into segments. The resolution of the bit segments is called quanta. The segments of the CAN bit is shown in the picture below. Propagation delay compensates for propagation delay on the bus. Sync gives the node clock time to resynchronise on low-to-high toggle. The synchronisation is done by adjusting the lengths of Phase buffer 1 and Phase buffer 2 by an integer number of quanta. The sampling of the bit is done after buffer one, then remains a margin, buffer two, of the bit. This is outlined in the picture below.
Figure 2.7: CAN bit
2.4.2 Protocol layer
The basic data unit is called a message. A message roughly consists of an identifier plus data. All messages are broadcast on the bus. Each node reads the identifier of all messages and determines if the data is relevant to it or not. All nodes are obliged to perform error checks and send 'Acknowledge'/'Not acknowledge' on all incoming data, not just on messages that are relevant to the specific node. The error handling included in the standard is extensive in order to attain robustness. It can silent erroneous nodes or make them go off bus completely.
There are two versions of the CAN standard in use; CAN2.0A and CAN2.0B. The main difference is in the length of the message identifier. 2.0A supports 11 bit identifiers, giving 2000 unique message types, and 2.0B supports 29 bits giving 512 million message types. 2.0B CAN controllers can handle 2.0A identifiers, but not the other way around. Sending a message with a 29 bit identifier to a 2.0A device will generate errors. 2.0B allows a more complex system at the price of more data overhead.
Four kinds of messages can be sent over the CAN bus. Data is carried by Data Frames, consisting of identifier and data. The Remote Frame is used to request data from another node. It consists of an identifier but no data. The node ‘owning’ the identifier of a Remote Frame will send a Data Frame which the requesting node can pick up. If a node detects an error in a message it will send an Error Frame to notify all the other nodes. The sender of the erroneous node will then try again. The Overload Frame is rarely used by any CAN devices today. It was needed by the very first CAN-controllers available, to signal that they need additional time to process the last message. CAN controllers of today have better performances.
The CAN message is composed of different fields which are shown in figure 2.8. Start of Frame - indicates the beginning of a message.
Message ID – Unique identifier for each type of message, also used for bus arbitration. Remote Transmission Request – is used to distinguish between remote- and data frame.
Control Field - contains bits to indicate properties of the message. Data Field - zero to eight bytes containing the actual data.
CRC sequence - contains a checksum of the message. This is part of the error handling. Ack - indicates that the transmission was successful.
End of Frame - indicates end of message.
Intermission Field – separates one message from the next.
The low bit is dominant on the CAN bus and the high is recessive. This means that if two nodes start to transmit at the very same time with one node transmitting high, and one low, the bus value will be low. This is used for bus arbitration. One of the most appealing properties of the CAN standard is the non-destructive bus arbitration. When two nodes want to transmit over the bus at the same time, arbitration determines who gets to send. Each node transmitting on the bus is also listening to it at the same time. Suppose the bus is available. Node A and node B start to transmit their identifiers at the same moment. If node A sends a low bit and node B sends a high, the bus will go low since low is dominant. Node B will sense that the bus value differs from the value it transmits. B will immediately stop transmitting and become a listener. Node A will continue to transmit as if nothing had happened. In this way, no time is wasted. This arbitration scheme differs from for example an Ethernet network. When a collision is detected in an Ethernet network, all nodes will go silent and then try to retransmit after an arbitrary period of time. CAN bus arbitration is shown in the picture below.
Figure 2.9: CAN bus arbitration. Node 1, 2 and three starts to transmit at the same time,
As mentioned earlier, the error handling of the CAN standard is extensive. The standard uses an elaborate scheme which gives points to erroneous send and receives of a node, and submits points when successful. If a node gets more points for erroneous receives than a given value, it will go error passive and not signal any errors it detects. This is to avoid an erroneous node to destroy the bus traffic completely. If the node keeps detecting errors after this it will go off line completely. The same thing will happen to a node that sends to much erroneous data.
2.4.3 Higher layer protocols
If a more sophisticated system is to be interconnected with a CAN bus, higher level protocols are desired on top of what is described in the previous paragraph. These could for example provide methods for sending data blocks larger then 8 bytes, passing of node parameters, transmission mechanisms etc. Instead of developing a new protocol for every new application, a few standards have been passed. The two major protocols for automation are CANopen, mainly used in Europe, and DeviceNet, mainly used in North America. For commercial vehicles, the Society of Automotive Engineers, SAE, J1939 standard is in most widespread use. It does not only specify transmission control but also
the content of messages to be sent. All variables relevant to a commercial vehicle are defined with range, resolution, transmission rate and priority. J1939 utilise 29 bit identifiers. The identifier is built up of a number of bit-field forms. These fields give the properties of the following data field and at the same time determine arbitration. A flag in the identifier signals if the message is aimed at a specific node. In that case the subsequent bits give the address of the destination node. In this way, proprietary messages can be sent on the bus to specific node(s) without the risk of being misinterpreted by others as J1939 specified data. The J1939 identifier is shown in figure 2.10.
Figure 2.10: Fields of the CAN message identifier according to J1939.
Priority An eight level (0 high, 7 low) priority of the messages. CAN arbitration continues with the rest of the identifier.
r Reserved Bit, must be set to zero.
DP Data Page bit, serves as extension to the following PF field. PF PDU Format specifies communication services.
DA Destination Address, used if the (proprietary) message is aimed at a specific node.
GE Group Extension, additional specification of broadcast messages. SA Source Address, address of sending node.
2.4.4 Fleet Management Services CAN standard
To promote the use of vehicle performance parameters in fleet management, the major commercial vehicle manufacturers have agreed on a standard set of CAN data that should be made available to third party developers. The messages of the standard are a subset of the J1939. Parameters made available by the standard include odometer and fuel consumption.
The ‘FMS Interface’ is the hardware part of the FMS standard and is specific to each make of truck. It is a gateway between the CAN bus of the truck and third party devices. The gateway has two tasks. The first is to transform whatever CAN protocol that the manufacturer might use internally, so that the output complies with FMS standard. Its second task is to work as a ‘diode’, or firewall, to prevent an external device from sending data on the CAN bus. This could otherwise interfere with the systems of the truck and cause fatal accidents. Third party devices may only listen to CAN data, never transmit. To connect an external device to the CAN bus without an FMS gateway will void the warranty.
2.4.5 CAN hardware
The timing constraints of the CAN standard are very strict. The low level of the protocol must be implemented in hardware. CAN controllers come from a number of producers at very modest prices. The low price of a CAN controller has a substantial part in the wide spread use of the standard. CAN controllers come with various levels of ‘intelligence’ from only moving data on and off the CAN bus, to producing memory mapped mail boxes for specified messages. CAN controllers are also embedded into microcontroller chips.
2.5 Input/Output
The following paragraphs gives a description of different input and output, IO, standards supported by the modules that are relevant to the project.
2.5.1 RS232
[Paragraph 2.5.1 is based on ref 6]
The EIA232 standard, generally called RS-232, defines electrical and mechanical properties of a serial data link. The standard does not define character encoding or bit rates; these can be chosen by the application. Feasible bit rates do not exceed 256 kBit/s due to the large voltage swing requirements of the signal. The first version of the standard was released in 1969, and an RS-232 port was standard equipment on PCs until the nineties. USB8 has now replaced RS-232 in the PC area because of its higher bit rate
and ability to supply current to the peripheral unit. An advantage of RS-232 is that it requires less software support than USB, making it a good option for devices with limited resources, where it is still in wide use. One case could for example be to connect a GPS to a PDA. As mentioned above, a set back of the standard is that it defines a large voltage swing. -15 ÷ -3 V for logic one and 3 ÷ 15 V for logic zero. This large swing limits the maximum bit rate due to limited slew of the signal generator. Also, an ordinary TTL9 or
CMOS10 circuit can not produce these levels, so external level converters are required to
such a circuit. The standard defines 20 signals, but more common is a four signal plus ground subset. It allows a full duplex link with flow control. A two signal plus ground full duplex link without flow control is also common. The remaining signals are defined for, for example, common clock and secondary data lines.
For historical reasons, the signals of the standard are labelled by a Data Terminal Equipment, DTE, sending data to a Data Communicator Equipment, DCE. The DTE is referring to a computer and the DCE is referring to a modem, which was the set up that the standard was originally intended for. The 4 +1 signal sub set is:
8 Universal Serial Bus
TD Transmitted Data from DTE to DCE. RD Received Data from DCE to DTE. RTS Request To Send.
CTS Clear To Send.
In half duplex mode, RTS and CTS make a full handshake. In full duplex mode, DCE transmits whenever RTS is high and DTE transmits whenever CTS is high.
GND Common Ground (this might not be true if the signalling cable is long). The two plus one signal implementation consists of TD, RD and GND.
2.5.2 Buses
Many of the GSM modules support Inter Integrated Circuit, I2C, and Serial Peripheral Interface, SPI, buses. These buses are mainly intended for on-PCB, Printed Circuit Board, use. They could come into practice in a design with a dedicated PCB to connect e.g. a GPS receiver to the GSM-module and will therefore be describe briefly.
I2C is a multi-master bus invented by Philips. It features a simple flow control
mechanism. Signalling is done over two bidirectional wires for clock and data, and can in the latest revision transfer data in rates up to 3.4 Mbit/s, with 100 and 400 Kbit/s being more common. The standard uses 10 bit addressing, enabling up to 1000 unique nodes to be pointed out on the bus, as long as the total bus capacitances don’t exceed 400 pF. Since capacitance of a wire is proportional to its width and length, 1000 nodes might not be possible in practice. The capacitance restriction also shows that the bus is not optimal for off PCB communication, since cables tend to have relatively large capacitance.
SPI is another simple serial bus intended for use on PCB. It is a single master bus with chip select instead of addressing. This makes it suitable for longer data streams from one or a few slaves, rather then reading and writing many addressed nodes. SPI allows higher data rates than I2C, 10 Mbit/s and more. SPI does not specify any acknowledgement or
flow control, so higher-level protocols have to be implemented by the user. 2.5.3 General input/output pins
All modules have a range of pins that can be used as either digital inputs or outputs. The direction of the pins can also in some cases be configured in application software. This is called General Purpose Input Output, GPIO. Digital pins could for example be used to connect an alarm button to the module, or some indication Light Emitting Diodes, LED’s. An output pin, in general, does not supply much current, so additional driving is needed to drive the external item, e.g. LED.
2.6 Supported programming languages
[Paragraph 2.6 is based on refs 11 and 12]
Of the GSM-modules available, two support Java, one supports Python, one C and one C++. Example code for the different modules can be found in appendix B. The following paragraphs gives a short description of the supported programming languages. This is to give the reader an idea of their characteristics. A vast literature exists for deeper study.
2.6.1 Java
The first public version of Java was released in 1995. It is a modern language which in many ways simplifies the life of the programmer. It has automatic memory management, garbage collection, so the programmer needs not to worry about memory leakage. It also features good exception (error) handling. All this care of the programmer takes a lot of system recourses though. Java code can not be as efficient as for example C, but is easier to learn and write descent Java code.
Java Virtual Machine, JVM, is an environment for the Java code to run in. It makes a standardized interface between java byte code and the hardware resources of a platform. The JVM is custom made for each operating system and CPU that is to support Java. Through this, any Java code will run on any platform, with some exceptions.
The JVM contains an interpreter that makes machine code out of the Java byte code at run time. This could seem like a slow solution, but modern interpreters can perform as well as for example C++ machine code, because the interpreter knows the target CPU. This equal performance is true for desktop PC’s, but not completely the case for limited resources platforms.
Java comes in different editions. Standard Edition, SE, for desktop PC environment, Enterprise Edition, EE, for distributed execution, and Micro Edition, ME, for limited resources platforms. The main difference to the programmer is in the Application Programming Interface, API. Java ME only provides a fraction of the functionality built into Java SE. Different profiles of the micro edition exist that specifies minimum hardware recourses, for example the Connected Limited Device Platform, CLDP.
2.6.2 Python
The first version of Python was released in the early nineties. It is now developed by The Python Software Foundation as an Open Source project. Although used for some popular programs like the original BitTorrent tracker, Python is not as widely adopted as the other languages in this review. Python is an interpreted language, meaning that it is compiled at runtime. Unlike most mainstream languages, it is dynamically typed with no predefinition of variables. Therefore, values, not variables carry type. This enables shorter code, but is also a great error source. The feature takes some time to get used to if one is used to for example Java programming. Python is designed with the intention of being highly readable. To attain this it has a simple visual layout, English keywords instead of punctuation, and fewer syntactic constructs than for example C. White space is used as delimiter instead of brackets. Python is the only major language with this approach. This enforces the indentation convention used in many other languages with the motivation of making the language more readable. An example of this can be seen in Appendix B, ‘Example Code’. Space and tab indentations are interpreted differently at runtime. If they are mixed they will generate errors. Since space and tab are visually similar, these errors can be hard to detect when debugging.
The Python language is multi-paradigm, permitting several programming styles; object-, functional- or structural- orientated. Exception handling is supported.
2.6.3 C
C was developed in the early seventies. It is a low level language which gives the programmer good control over the hardware recourses of a platform. It gives freedom and responsibility, allowing optimized routines but also presents many pitfalls. More than Java, it rather trusts than protects the programmer. C consists of the core language and the standard library, which add additional functionality. In addition to the standard library many free libraries exist which can be included to a project to prevent the wheel from being reinvented. The source code is compiled to machine code that the CPU can execute. C has low demands on the compiler, so it’s relatively easy to write a compiler for a new platform. The features described here have made C popular for embedded systems. Programming language development has progressed a lot since the seventies. Measured by today’s standards, C is a primitive language which lacks for example automatic garbage collection. It has therefore been abandoned for desktop application development where processing power isn’t really an issue. For low level programming it still has a large role to fill.
2.6.4 C++
C++ development begun in the early eighties as an extension to C and can be regarded as a superset to it. Although the compatibility is not complete, most of what is true for C applies to C++ as well. New features of C++ include support for object orientated programming which facilitates the development of larger software projects. The many other additions make C++ a vast language which can be hard to grasp.
2.6.5 AT-command
AT-command is not a general purpose programming language, but a way to control and configure the baseband CPU of a GSM device. AT-commands are a set of Assembler looking commands originally created to control dial-up point-to-point modems in the late seventies. The transmitter in a GSM phone can be looked at as a modem communicating over the GSM-network. The command set for the transmitter is regulated by the GSM standard. The standard set is usually extended with additional commands that are device specific. AT-commands are used to make and accept calls, manage the phonebook, send SMS’es and a lot more. Some AT commands take very long time to execute because they include the baseband CPU to poll the network. This should be considered when programming a GSM-device with AT-commands.
3 GSM-modules
GSM-modems have been around for some 10 years. A GSM-modem is simply speaking a mobile phone that has been stripped of its display and keyboard, leaving only the actual radio device, control circuits and IO. The device can then be embedded into a product as a communication link to cell-phone networks and onwards to the internet
During the past three-four years, an enhanced type of GSM-modem has emerged. They will be called GSM-modules in this report11. The difference to an ordinary modem is that
the module allows the running of third party application code within the unit, eliminating the need of an external controller. The GSM-modules also host internal IP-stacks, making Internet access very easy. As of today there are modules available from half a dozen producers. An example of what a GSM-module looks like is shown in figure 3.1.
Figure 3.1: Siemens TC65 module, original size [ref Siemens]
11 The GSM-module definition of this report is not widely agreed on. Some producers call simple modems
modules as well. There is no standardised name for a modem that allows embedded application software. The term ‘GSM-module’ will be used for an embedded application modem in this report.
3.1 General applications
GSM modules allow highly integrated embedded systems with Internet connectivity, where component count can be kept to a minimum. They target products that need connectivity with each other or a central server from remote locations. The main property to keep in mind when designing a system where the intelligence is embedded into a GSM-module is the limited CPU power and memory. Since the modules have limited resources, their tasks should be kept simple and non-time-critical. Possible applications include collecting and sending positioning information from a vehicle, reporting stock of a vending machine, weather data from a weather station, etc.
In addition to the stand-alone mode, all modules evaluated in this report can also be controlled by an external CPU, like a traditional GSM-terminal. The two different architectures are shown in figure 3.2.
Figure 3.2: Traditional architecture of a device with GSM connectivity, compared with a GSM-module.
3.2 Hardware
A GSM module contains a baseband CPU that maintains the GSM/GPRS protocols. The CPU communicates with a high frequency radio transceiver that modulates the signal from the baseband CPU and transmits it into the ether. In difference to a GSM-terminal, the module also provides means to execute third party application code. The application could either be run on spare capacity in the module’s baseband CPU, or in a dedicated application CPU.
The target applications of GSM-modules often include positioning. To meet this demand, GSM-modules with internal GPS have been released. The GPS receiver chip is fitted into the module and connected to the application CPU. In all released implementations, the link in between the CPU and GPS is a RS-232 line and it decreases the number of external serial ports of the module by one, compared to the respective models without GPS.
The connector of the modules is either a ball grid array, BGA, or a multi pin board-to-board connector. A dedicated Printed Circuit Board, PCB, is then needed to use the module. The PCB should contain proper IO connectors, peripheral circuitry such as RS-232 level converters, and power supply. A GSM device has some particular powering demands. Though its average power consumption is rather low, the unit can need up to two ampere when transmitting in its time slot. This should be accounted for in the power supply design.
Developing a PCB takes time. To speed up prototyping, and to allow parallel hardware and software development, all GSM-module producers provide test boards for their models. These boards offer complete support for a module, so that the application programmer can start to work at once. The test board of Aplicom A12 is shown in figure 3.3 as an example.
Figure 3.3: Aplicom A12 test board [ref Aplicom]
3.3 Software
Programming languages supported in GSM-modules studied in this report are Java, C, C++ and Python. Some language characteristics are presented in paragraph 2.6 and example code for the different modules can be found in appendix B. All standard API’s of the different languages have been modified to some extent. Features have been removed due to the small recourses of the GSM-module platform, or features have been added to adapt to the module hardware.
The main characteristic of the modules programming environments is the limited recourses. Execution performance is not real time but rather quite slow and program size and memory utilization must be kept to a minimum to fit in a module. Both single threaded and multi threading application environments exist, depending on the device. Many manufacturers also provide a PC emulator for their modules. This enables software debugging on a PC which facilitates the development process.
3.4 Remote update
Remote update is a way to update application code from a remote location by downloading new code and replacing the old one. In the case of GSM-modules, this is also called Over The Air, OTA update, since the new code is downloaded wirelessly. Most modules of the review of this report support remote update of application code. An update could be required to change the use of the module, or to correct a bug in the application code. To update a large fleet of trucks spread over a vast geographical area by ‘cable’ is very costly. Remote update could be risky though, if the device accidentally ends up in some deadlock state and can’t be accessed. Mechanisms for the remote update
procedure differ between the modules. A significant difference is whether the data bearer is CSD or GPRS. CSD requires a GSM modem at the update administrator, while GPRS uses standard internet connection.
3.5 Producers
Producers with GSM-modules available in sample- or production- quantities today [060131] include: Aplicom, Telit, Siemens, Sony Ericsson and Wavecom. In addition to this, Motorola claims to have a module ready in sample quantities by the end of 2006. Sagem have GSM terminals with an internal IP-stack, but no embedded execution at the moment. There is also one or two smaller actors on the market. With the market for machine-to-machine, m2m, communication gaining momentum, it is likely that more cell phone producers, or their partners, will launch GSM-modules in the years to come. In contrast to this, the market is also open for consolidation. This is discussed further in chapter 6.
4 Review of the GSM-module market
Chapter 4 will review GSM-modules on the market with respect to the requirements of this project. The review was made in early 2006. Modules released later than this have not been studied. An update of available modules today [061218] is given in paragraph 6.2.1. The descriptions of the different modules depend on how extensive the respective module documentation is, and how easy it has been to acquire additional info from the sales and support organisations. Therefore, not all modules are covered to the same extent, and not always on the same issues. The focus has been on parameters relevant to the requirements of this project in order to get a more condensed report. Features like noise reduction of speech (which all modules have support for) have therefore been left out. Readers interested in these aspects are referred to the modules documentation. The documents that this review is based on are listed in the references. They can be acquired either from the respective manufacturer’s web pages or their sales agents.
4.1 Data table
A standard table of key features has been have put together for fast comparison of the modules. The outline is as follows:
Programming language: The supported language for embedded applications. Program- and data-
memory for embedded software: All models in the review use combined data and program memory.
RAM for embedded software:
Supported protocols: UDP, TCP etc.
Interfaces: Number of RS-232, I2C, etc.
Temperature range [°C]: Since the modules will be used in automotive environment, their temperature working range is critical.
Supply voltage [V]:
GSM band: Supported frequency bands
All modules are of size about 5*7*0.5 cm or less. Size has not been considered size a critical parameter for this project. All modules except Wavecom Q2501B comply with the EU RoHS directive, Restriction of Hazardous Substances in Electrical Equipment. (Commercial vehicles are exempted from this restriction for the time being)
4.2 Aplicom A12
Aplicom is based in Espoo, Finland, with Data Respons as Swedish sales agent. Aplicom started as a spin-off from Nokia in 1990. They specialise in vehicle telematics and m2m platforms. When Nokia decided not to continue their m2m branch, Aplicom bought the rights of Nokia’s N12-module and renamed it A12.
4.2.1 Data table
Programming language: J2ME IMP
Memory available for embedded software: 1 Mbyte combined DM and TM
(Application size is limited to 128 Kbyte) RAM available for embedded software: 256 Kbyte
Supported protocols: TCP, UDP, CORBA, NMEA
Interfaces: 3x RS232, one general purpose, one for NMEA and one for programming, 17* GPIO
Temperature range [°C]: +15 ÷ +35, normal -25 ÷ +55 extreme
Supply voltage: 3.6 ÷ 4.0
GSM band 900/1800
GPRS class 10
4.2.2 Software
A12 has an integrated runtime environment for Java 2 Micro Edition, as described in paragraph 2.6.1. Aplicom has added platform specific tasks, like GPS interface, to the J2ME API. The Java engine is run on an ARM7 core CPU. It allows multiple threads and has no explicit limitation on the number, but the amount of RAM will limit it.
The A12 has 1 MB of memory, but no application on the module can be bigger then 128 Kbyte. Instead, the module can store multiple applications, but only one application can be running at any given time. Start/stop of applications is done either by the application itself or from a server.
The A12 has an implementation of CORBA. This is an interpreter interface standard that wraps an object written in one language with additional info, so that it can be called by code written in some other (supported) language. It is used on the A12 instead of AT-commands to provide services to set and get different properties of the module. This set up allows both the module itself and a remote part to control the features of the module. The performance of the module is dependent on the data transmission activity. Aplicom does not provide any ratings of module performance; they only state that resources are limited. Since Java is not intended as a real time language it is not suitable for time critical tasks.
Ports and wireless connections can be configured either via a PC by a provided graphical interface, in application code or over the air. New software can be downloaded to the module either through an RS232 link or over the air by CSD as bearer.
The A12 comes with an SDK that includes an emulator. The emulator simulates most of the A12’s features on a PC. It uses the PC’s IP-stack and serial port as if they were on the A12, making software debugging possible without the necessity to download the code to a physical module. The emulator has no execution control, i.e. no possibility to single step code.
4.2.3 GPS
As stated in the project requirements, a primary task for the project module is positioning with use of a GPS. NMEA sentence handling is therefore a key feature. The A12 has a specific Java interface for the NMEA protocol. A dedicated serial port can be configured for GPS data and is then connected to an internal NMEA interpreter. In this configuration, GPS data can be conveniently collected by an application through a GPS data object. For example, to get the modules latitude in degrees from a GPS data object, the following syntax is used:
String lattitude = gpsData.position.lat.degrees;
The internal handling of GPS data to the Java module is done with a CORBA interface.
4.3 Siemens TC65
The German industrial giant Siemens also has a division for mobile communication, Siemens Wireless Modules, which has been developing m2m products over the past years. Siemens has some modules of interest in their product range. The TC65 is a module supporting Java embedded applications. It is Siemens second generation GSM-module, successor of the TC45, which is being phased out. Siemens also has a module with internal GPS, XT55, but this module does not support any embedded applications but requires an external controller. For this project, the TC65 will be studied.
4.3.1 Data table
Programming language: Java micro edition Program and data
memory for embedded software: 1.7 Mbyte RAM for embedded software 400 Kbyte
Supported protocols: TCP, UDP, HTTPS
Interfaces: 2x RS232, 10x IO, I2C, SPI, USB 2.0
Temperature range: -30 ÷ +70 normal / -40 ÷ 85 storage
Supply voltage: 3.2 ÷ 4.5 V
GSM band 850/900/1800/1900
4.3.2 Hardware
The Java engine and embedded application is run in an ARM7 core CPU. It should be mentioned that the USB port of the module is only a slave. The module could not be used to control e.g. a USB memory.
4.3.3 Software
TC65 has an integrated runtime environment for Java 2 Micro Edition as described in paragraph 2.6.1. Siemens has added API for AT-commands, IO and file system. The file system is flash based and can be viewed from Windows Explorer when the module is connected to a PC. GPIO, SPI and I2C are controlled by AT-commands through a parser
interface. All other features are controlled by ‘real’ Java methods. The data flow of software running in the module is shown in figure 4.1.
The API for AT-commands are of the kind;
atc.send(string, connect_list)
string is the AT-command to be sent. If the connect_list argument is omitted,
execution of the Java code is interrupted until the command has been processed by the baseband processor and it has returned a response. With the connect_list argument, the AT-command is non-blocking. Execution of Java code continues until the baseband CPU returns a response to the AT-command. The user specified methods of connect_list contains code that then deals with the response, like a call-back. This feature is good for AT-commands that take some time to execute, and the execution of Java code can’t wait. Much of what can be done by AT-commands can also be done by standard Java API, but GPIO, SPI, I2C and trigging of OTA update, can only be done by AT-commands.
The Java code is compiled just-in-time, with the most frequently executed parts transferred into machine code and stored in RAM. This feature increases execution speed but takes up space in the 400 KB of RAM available to embedded applications. The Java engine allows multiple threads.
Performance of the module while connected to the network is about 45000 jPS, java statements per second. This value was obtained by Siemens for specific test cases and should only be considered an estimate. Siemens has measured maximal throughput RS232 -> GPRS to 20 Kbit/s, using three parallel GPRS channels (compared to a theoretical max of 36 Kbit/s over three channels).
The module comes with a software development toolkit that can be integrated into common java development environments, like Eclipse. It contains an emulator for on-device debugging. A TC65 module is connected to a PC by either RS-232 or USB. The program to be debugged is executed on the TC65 module and the emulator allows execution control from e.g. Eclipse.
New software can be downloaded to the module either through a RS232- or USB-cable, or over the air. TC65 implements a Java standard for remote update. The update
