978-1-4799-2385-4/14/$31.00 2014 IEEE

Design and Implementation of a GPRS Remote Data Logger for Weather Forecasting

Andrei KOVACS(Corresponding author)1*, Andreea NICOLCIOIU1, Jnel ARHIP2, George CAU1 1Military Technical Academy, Faculty of Electonics and Informatics, Bucharest, Romania

2Seletron Software and Automation., General Manager, Bucharest, Romania *Corresponding author (E-mail : andreikovacs@mta.ro)

AbstractThis paper presents the design and implementation of a remote data logger based on GPRS connection, used for weather forecasting and statistical deduction of climate. The device presented in this paper is an interface between the weather station and a remote operator. The system is based on a microcontroller, a cellular engine, an SD card and a real time clock and it is able to measure, calculate, store and transmit weather parameters.

Keywords - remote monitoring; GPRS; weather forecasting.

I. INTRODUCTION A weather station is a facility that has instruments and

equipment used to observe atmospheric conditions, to provide information for weather forecasts and to study the weather and climate. The measurements taken include temperature, barometric pressure, humidity, wind speed, wind direction, and precipitation amounts. These measurements are critical in weather forecasting and some must be analyzed at least once daily, some at least once an hour and others once every minute. Analyzing all this reports becomes an issue in hard to reach areas.

Devices able to work around the clock, in any weather conditions, being installed in hard to reach areas came as a solution for this problem. Other constraints imply a cost and power consumption as small as possible.

The product presented in this paper makes the connection between the weather station and a remote operator. It is able to communicate with the weather station, to receive the parameters measured by the weather station, to keep the received data on SD card and also to send the data to a remote FTP server, over GPRS.

The system was designed to meet requirements like very low power usage, dimension constraints and low cost.

II. DESIGN REQUIREMENTS The weather station is able to work in two modes: in report

mode and in service mode. In report mode, the weather station sends a report if an alarm condition occurred and regular reports at every known period of time. In service mode the weather station can receive for upload a new configuration file and offers the option to download binary log files, containing detailed information about the measured parameters. Both the uploaded configuration files and the downloaded log files are transferred over the Zmodem protocol.

A report is an ASCII string containing information about parameters like wind speed, humidity, temperature etc. sent by the weather station. Every report is prefixed by a header that specifies its type; the header is followed by the actual data (the measured parameters) and at the end a CRC is inserted.

The developed device has to be compatible with the weather station, helping a remote operator to receive the reports and the state of the weather station in the same manner as he would be there.

III. SYSTEM DESCRIPTION The block scheme of the device is presented in Figure 1.

The heart of the device is the ATMega64 microcontroller which communicates with all the other peripherals using different standards and protocols.

A cellular engine in conjunction with the SIM card

provides a GPRS connection. The SD card is used to store the reports and the log files. The real time clock provides time and date information to send commands and to change status at precise moments of time. The data logger also embeds two analog inputs, two digital inputs and two digital outputs offering the possibility to extend the data logger capabilities.

A. Communication standards The data logger communicates with the weather station via

RS-232 or via RS 485. It has two physical ports but only one is active at one time. The active port is selected with a jumper. The active port is used by the weather station to send reports to

Figure 1 Block scheme of the device

the data logger and by the data logger to send commands to the weather station. Both the reports and the commands are text strings.

The data logger can initiate a log file download by sending a set of text commands to the weather station. After the weather station acknowledged the commands both the data logger and the weather station switch to Zmodem protocol in order to transfer a log file.

The data traffic between ATMega64 microcontroller and the real time clock is performed via I2C while the communication with the SD card flows through SPI.

For the GPRS interface with the remote server the Siemens MC55i cellular engine was used, communicating with the microcontroller under the T232 standard. The cellular engine is coordinated by the ATMega64 microcontroller using AT commands. The cellular engine sends the report files to the remote server using FTP protocol.

B. Data logger tasks The weather station periodically sends reports containing

the measured parameters. When the data logger receives a report, it creates a new file on the SD card, opens a FTP connection to the remote server and uploads the new file. During the execution of this job the data logger is able to handle another report and save it to the SD card for later transmission.

At a known set time, every day, the data logger initiates a Zmodem file transfer in order to download the log files from the weather station. The log files are stored on the SD card to be sent to the remote FTP server.

The data logger creates its own log files. This files contain all the errors encountered (no network, no log files, errors during file transfer etc.) and all the reports received from the weather station. Every day, at a known set time, the data logger sends its own log files to the remote FTP server.

The weather station can be connected directly to a remote user by a CSD call. The data logger becomes transparent in the connection between the weather station and the remote user, every data received from the weather station is sent to the remote user and vice versa. During a CSD call the data logger parameters can be set like in the configuration mode described in the subchapter III.C.

C. Data logger configuration The data logger can be configured by an operator via the

serial port (the same port used for report handling). To enter in configuration mode, a serial command is sent to the data logger. A help command will display all the parameters that can be configured by the operator.

More than 70 parameters can be configured including

remote server adress and port, messages to be handled, time and date, serial port parameters, data logger identification

code, log files download time, name, extension, GPRS connection parameters, etc.

In configuration mode, the data logger can be set to behave like a modem. The cellular engine will have a transparent connection to the serial port. Using manual AT commands all the services provided by the cellular engine are accessible to the operator (SMS, CSD call, network information, etc.). The data logger can be used to connect as a modem, via CSD call, to another data logger.

IV. HARDWARE DESCRIPTION The product had to comply with a set of hardware

restrictions. The device power consumption had to be reduced as much as possible because the data loggers are powered by solar panels. The complexity of the software would have required a 16 or 32 bit MCU but in order to comply with the power consumption requirement an 8 bit MCU was chosen instead. In order to efficiently use the power, the voltage regulators are switching mode power supplies.

The cellular engine has its own power supply offering the option to be shut down whenever there is not any data traffic. Because the weather stations are positioned in harsh climate zones, all the electrical components have to resist at temperatures between -40C and 80C.

The narrow space inside the weather station panel imposed

using SMD components and implementation of a hardware design that would avoid electromagnetic compatibility problems. Figure 3 presents a picture of the device.

V. SOFTWARE DESCRIPTION As mentioned above, to reduce power consumption, no

operating system was used so the complexity of the designed software was high.

During operation, the data logger executes multitasking actions that are running simultaneously and independently. To assure multitasking operation several state machines were designed and implemented in software with high caution paid to the use of code memory (64kB).

Figure 4 shows the flowchart of the message handling process starting at MCU reset. After the MCU reset, the values of the user configurable parameters are checked. If the reports are configured to be transmitted periodically, the process enters in idle state waiting for a report to arrive.

When the weather station sends a report, the MCU stores the report into an internal buffer and verifies its properties (header, length, parameters, CRC). If report daily log parameter is enabled, the report is written to a log file. If the option to send to a remote FTP server is enabled, the MCU creates a new file (containing only the current report) on the SD card and starts the transmission to the server. The status log file

Figure 2 Connection for device configuration

Figure 3 Images of the device

is updated, logging all the actions completed or failed by the MCU. After successfully sending a report or after repeated fails in sending the report, the system returns to idle state waiting for the next report. If a report is received during the operations described above, the software is optimized to handle it by writing it on the SD card and by sending it only after the current transmission is finished.

The variables size was carefully chosen for an efficient use

of the RAM memory (4 kB data memory and stack memory). The interface between the MCU and the SD card was

designed using [2], [3] and [4] and following the embedded software philosophy. A new FAT32 file system was designed and implemented. The file system was implemented using embedded system restrictions: the SD card should not become corrupt after a power fault and should not block other tasks while reading or writing; the read/write operations are performed as described in [1].

For log file downloading from the weather station the Zmodem protocol was implemented in the MCU software. The tasks performed in Zmodem communication with the weather station are designed to be nonblocking for other processes.

Figure 5 shows the flowchart of handling the log files received from the weather station starting at MCU reset. After MCU reset, the system time is checked. If the system time is ahead of the log file download scheduled time (preset by the configuration parameters) the process enters in idle state checking the time every second.

When the log file download time matches the system time, the SD card available space is checked and if there is not enough memory, the oldest files are deleted. The Zmodem protocol is initiated in order to download the log files from the weather station and save them on the data logger SD card. If the parameter send log files to FTP is enabled, the system initiates the downloaded log files transmission to the FTP server. The data logger status log file is updated logging all the operations described above.

VI. PRODUCT TESTING The first step in product testing was to configure the data

logger. The parameters configuration and the response of the data logger to incorrect values were tested by software running on a machine connected to the serial port of the data logger. The testing software sent over 1000 valid and invalid commands and verified the data logger answers. A log file containing the data loggers answers and the valid answers percent was generated. After the first test, the data loggers valid answer percent was around 50%. A bug correcting process followed.

The second step in product testing was to verify the delivery rate of the reports and log files (data logger and weather station log files) to the remote FTP server. Every report file is expected to be delivered repeatedly to the FTP server after a specific period of time, depending on the type of the report. A testing platform was developed to identify whether a report file

MCUreset

Checklog time

Check SD card spaceFree space, if necessary

Create log file names

Download log filesSave files on SD card

CheckIf send FTP is enabled

Send via FTP

Append daily status log file

YES

YES

NO

NO

Figure 5 - Log file handling flowchart

MCUreset

1. Read message names2. Read header

Read message

Identify message

Save message

Into log file

If message send FTP enabled

Send message via FTP

Append daily status log file

If message received

If message log enabled

YES

YES

YES

NO

NO

NO

Figure 4 Message handling flowchart

arrived on time or arrived later than expected. The testing platform would also detect the delay of any report file.

After the testing process in the laboratory, the devices were installed in the weather stations panels in remote locations. The operation in the harsh climate and the compatibility with the weather station were also put to test.

By testing five data loggers over a period of a month, 16800 reports had to be found on the FTP server but 16787 were found so 13 reports were missing. Based on these numbers, the probability to correctly receive a report is 0.999226 and the probability of missing reports is 0.000774. The maximum delay of the correctly received reports is 236 minutes due to the lack of signal in the area of the data logger and was encountered for one report from one of the five weather stations. For this particular case the repeated failures in connecting to the FTP server were notified in the status log file. Only once, all the reports from all the tested data loggers were delayed for 135 minutes because the FTP server was not available. Eliminating the two cases discussed above, the average delay for a report is approximately 42 seconds. The average delay was calculated as the division of the sum of delays for all the reports in seconds and the number of the received reports (704604/16776). This delay time is inherent in the transmission medium.

VII. CONCLUSIONS AND FUTURE WORK In this paper it was presented the process of designing,

implementing and testing a GPRS remote data logger for weather forecasting. The system offers complex solutions for handling tasks like communicating with a weather station, storing received data, sending data to a remote FTP server, CSD call and modem services. The designing and implementation process takes into account requirements like operation in harsh climate, low power usage, dimension constraints and low cost.

The fact that the MCU communicates with the peripherals using different standards and protocols leads to software implementation of interfaces for Zmodem protocol, SD card communication and AT command set.

The system was validated through tests that verified the correctness of data logger answers to commands, the delivery of reports and log files and the overall execution of tasks and

compatibility with the weather station when installed in the remote location.

Now, five weather stations placed all over the country are equipped with remote data loggers. The five weather stations are now autonomous, sending reports with the measured parameters to a central FTP server. The devices have been running for five months, and no errors have been reported.

In the future, the devices will be improved adding capabilities to communicate through e-mail, http, and socket connections.

REFERENCES [1] Keshava Munegowda, Power fail safe FAT file system, Embedded

Linux Conference, April 11- 13, 2011, San Francisco , CA. [2] Microsoft Extensible Firmware Initiative FAT32 File System

Specification, Version 1.03, December 6, 2000. [3] 2000 SD Group (MEI, SanDisk, Toshiba) - SD-Memory card

specifications Part 1, Phisical layer specification Ver 1.0. [4] F. Foust - Application note - Secure digital card interface for the

MSP430, Michigan State University, 2004. [5] Cinterion, MC55i Hardware Interface Description Ver. 01.003 October

2008. [6] Siemens, MC55i AT Command Set Ver. 01.003, February 2008. [7] Mark Nelson, Serial communications developer's guide, IDG Books

Worldwide, 2000. [8] Chuck Forsberg, The zmodem inter application file transfer Protocol,

http://pauillac.inria.fr/~doligez/zmodem/zmodem.txt. [9] Soyoung Hwang and Donghui Yu, Remote monitoring and controlling

system based on zigbee networks, International Journal of Software Engineering and Its Applications Vol. 6, No. 3, July, 2012.

[10] Afif Jadalla Al Mghawish, A practical approach for mobile-based remote control, European Scientific Journal vol.9, No.18, June 2013.

[11] Zatin Singhal and Rajneesh Kumar Gujral, Anytime anywhere- remote monitoring of attendance system based on rfid using GSM network, International Journal of Computer Applications (0975 8887) Volume 39 No.3, February 2012.

[12] Purnima Reddy, Design of remote monitoring and control system with automatic irrigation system using gsm-bluetooth , International Journal of Computer Applications (0975 888) Volume 47 No.12, June 2012.

[13] B.Ramamurthy , S.Bhargavi, R.ShashiKumar, Development of a low-cost GSM SMS-based humidity remote monitoring and control system for industrial applications, International Journal of Advanced Computer Science and Applications, Vol. 1, No. 4, October 2010

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 200 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 2.00333 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 400 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00167 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles true /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /NA /PreserveEditing false /UntaggedCMYKHandling /UseDocumentProfile /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice