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 NICOLCIOIU
1
, Jnel ARHIP
2
, George CAU
1
1
Military Technical Academy, Faculty of Electonics and Informatics, Bucharest, Romania
2
Seletron 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
MCU
reset
Check
log time
Check SD card space
Free space, if necessary
Create log file
names
Download log files
Save files on SD card
Check
If send FTP
is enabled
Send via FTP
Append daily
status log file
YES
YES
NO
NO

Figure 5 - Log file handling flowchart

MCU
reset
1. Read message names
2. 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