|Internet Data Reporting from the Field|
You have a Data Logger in the field and would like an automated Data collection. You do not have a great deal of money to invest and limited resources. You would like to utilize the Internet to distribute the Data.
Usually this required a dedicated telemetry system at both the remote site and at the central office. In addition, the central office needed a polling computer and specialized software to do the data polling. The computer would deposit the information in a data base. The end user could access the data from the data base directly, or if additional software processes were enabled at the collection platform - the Data could be available to the internet. For a system that had multiple sites to support this method was the best solution.
What if you had a single site and wanted this type of automation? Your requirements did not need 'real time' Data - just the ability to get a daily report from the site.
One such solution is to have the Data Logger connected to a Cell Phone, OrbitComm or GOES Radio. The OrbitComm and GOES route gives you access to your Data in a delayed time frame. The Cell Phone route will give your Data on demand. You have to either call the site manually or have some form of automation to call the site on the Cell Phone to get the data.
The standard Data Loggers that most federal agencies use are Campbell Scientific, Handar, Stevens or Sutron. None of the commonly used Data Loggers from these companies give the end user much in the automated reporting arena.
Advances in technology have spawned new products that make automated reporting from remote sites a reality. When integrated into existing systems it is possible to have the Data Logger upload it's daily data to the Internet.
Our solution took an existing site that had a Sutron 8210 Data Logger and Cell Phone connectivity. We added a third party device, a 12vdc MODEM, and special programming to the Sutron 8210. The end result was a stand alone remote site that was capable if Internet Data reporting. Total hardware costs were less than $500 for the hardware components. The software for the Sutron 8210 was developed 'in house' to suit our requirements.
Our local Water Conservation Officer wanted to know if it was possible to have a Data Logger automatically send E-mail containing daily information sent to 'key' personnel. "Nothing fancy", just the contents of the Log. "I want it sent at Midnight to Joe, Bob, Jack, etc."
This amounted to developing a system to generate a Daily Report that emulated the contents of the Log and deliver that Report in the end user's Internet E-mail account. The E-mail Data would be in the same general format as a Log Dump. The delivery of this information would be done automatically after midnight from the previous day's readings. This solution was designed with a Sutron 8210 as the Data Logger. I have no doubt that the same process could be developed to support another vendor's product line. All references to the Data Logger in our example will be to a Sutron 8210 [the Data Logger that we used].
The Data contained in the 8210's Log, in effect, is the type of information contained in the desired Report. Wouldn't it be nice to have the information a little more user friendly format than the Log, and not require specialized knowledge to gain access to it? Data that is easier for the end user to understand.
The normal method of extracting log information from an 8210 is over a Serial cable or Modem connection and requires some amount of technical knowledge. Sometimes, the field person does not have the knowledge nor the means to extract a Log. Sometimes, we don't want them to access the inner workings of the Data Logger. In the case of a multiple distribution to "Joe, Bob, Jack, etc.", we really don't want them 'inside' the Data Logger - changing parameters or doing worse.
Today, Data security is just as important as the Data collection process. The concept of transferring the data 'out' of the box without having someone 'inside' the box making the request becomes more secure.
One common method of getting Data from the remote site is by using the telephone system and using the Sutron Voice Modem to access the Data Logger. If this is the case, the Sutron 8210 requires the caller to make the choice of voice or digital reporting. The voice mode normally gives the caller the current sensor readings. Historical data reporting using the voice mode is not possible without extensive Tiny BASIC programming. Using the digital mode gives the user more flex ability, but requires the caller to use a computer. In addition, the caller must have a greater understanding of the 8210's internal menuing system.
To do this would require a program in Tiny BASIC. Considering the complexity of this task and the limitations of the Tiny BASIC and Speech Modem, this task is not feasible.
The ideal setup would allow the user to call into the 8210 to get voice readings and get the historical data without having to go through several levels of menus to access the data.
Our 'Task' for the generation and distribution of a daily report can be broken down into two simple steps.
Step 1. Build the Report. The generation of a Daily Report can be undertaken by use of a Tiny BASIC Program resident in the 8210. The Program can take the readings, calculate the results, Log and format the Data for the end user. The Report is Software generated by the Data Logger.
Step 2. Send the Report to the recipients. This component required the ability to transmit the report to the Internet. In our case, the component would have to dial up and log into an Internet Service Provider. Once logged in to the ISP the report will be sent to the end users in the form of an E-mail message. The sending of the Report is a Hardware function. The device that makes this happen is an Output type [in much the same role as a Display or a Printer]. The Report is Output to this device as simple RS-232 Serial Data.
The B&B ICaddy
|B&B Electronics has recently introduced a device that makes this task manageable. B&B's ICADDY is designed to accept input data on it's Local Serial Port. The Data is spooled in the ICADDY's 60k buffer memory until an external trigger trips, or by a fixed time interval [programmed into the ICADDY]. Upon the trigger event, the Data can be transferred to an Internet Service Provider [ISP] by the ICADDY, dialing out on the external MODEM using a Dial-up Account.|
|The ICADDY can deliver the Data either by sending E-mail to an SMTP Server with the report as an attachment file. Or the ICADDY can FTP the Data as either a TXT or HTM file to a Web Server or to both Servers.
The Report format will dictate exactly how you want the Data to be received by the end user. For a more detailed explanation click here.
To send the Report, the ICADDY is programmed up with the dialup account information. Telephone numbers, login information and IP Addresses of the Servers it is to access. This information is programmed in the ICADDY's setup. The diagram below shows the relationship of the 8210 to the ICADDY.
Our application is setup to deliver the Data as a Daily Report. This report is Mailed to a list of end users at midnight. Here's how it works:
1. Data is collected by the Sutron 8210. The Data is formatted by the Tiny BASIC program, time stamped and is sent out the 8210's internal Serial port to the ICADDY hourly.
2. The ICADDY receives this Data on it's LOCAL Port from the 8210 and spools the Data into it's internal 60Kb buffer memory. The Data accumulates in the buffer during the day.
3. Shortly after Midnight the 8210 triggers the ICADDY to send it's stored Data to a local internet provider using a dial-up account. When triggered, the ICADDY commands the external MODEM to dial out to the local ISP on the telephone.
4. The ICADDY logs into the ISP user's account. The ICADDY then logs into the SMTP Server at the ISP. Once logged into the Server, the ICADDY sends E-mail to the recipients. The Data is sent as a Text File attachment. Upon completion, the ICADDY hangs up and is ready to receive more Data from the 8210.
5. As a design safeguard, the 8210 is programmed to recycle power on both the ICADDY and MODEM 30 minutes after the trigger was issued. This is used in the event of the ICADDY or MODEM being locked-up.
The physical layout for the ICADDY and MODEM are not critical. I mounted them on an 19 inch rack plate. The system was built, programmed and pre-tested in the shop before deploying the unit to the field.
The Sutron Internal Voice MODEM can not be used in this application as it is integrated into the 8210 and can not be accessed by the ICADDY. The external MODEM that we used is a 33.6K Baud MODEM manufactured by ZOOM. The ZOOM MODEM is ideal for our application as it is powered by +12vdc and uses the time proven 33.6 Rockwell Chip set. This MODEM plays well with both Land-line and Cell Phones.
|Interfacing to existing equipment is reduced to hooking up power and the trigger on the Terminal Strip to the SW'D Power [42-43] and DIGITAL OUT5 . The incoming phone connection goes to the MODEM's Line Input. The MODEM's Phone Output goes to the 8210's Telephone input [16-17]. The external MODEM is programmed to IGNORE incoming calls. All incoming calls are routed to the 8210's MODEM.|
|Users can still dial into the site to get the current readings from the 8210's Voice MODEM. Only during the midnight report is the line seized by the ICADDY and the external Modem.|
1. Sutron 8210 requirements. Programming the Tiny BASIC and setting up the Sutron 8210 to give a suitable Report and to coordinate triggering the ICADDY. A Tiny BASIC program Block Diagram can be found here for instructional purposes. If you use a Data Logger other than a Sutron 8210 - The Data Logger must be able to be programmed to send it's data to the ICADDY. The Data Logger can be 'dumb' and send blind data to the ICADDY. The ICADDY can be programmed to act independent of the Data Logger. The caveat to remember is that the Data will be displayed in the same format as it was - when it left the Data Logger. If you do not program into the report any formatting information - the end result in the E-mail message will have no formatting information. The ability to program output data in a usable format for the end user is very important. The program also coordinates event handling as well. Have the Data Logger do as much of the work as possible.
2. Programming the ICADDY to work correctly for 'local' conditions. Several variables makes this tricky. Selection of a suitable ISP is critical. Providers like AOL or ATT WorldNet [that use propriety software] will not work with the ICADDY. EarthLink may or may not work correctly - depending how the local RAS Equipment is configured. If your Internet Service Provider ISP requires you to access a POP account [reading your E-mail] before sending SMTP E-mail - the ICADDY will not work. Simply put, if your ISP requires any special software and/or procedure[s] to access E-mail - the ICADDY will not work.
3. The local telephone connection. If it is marginal and the MODEM sends/receives junk characters - do not expect good results. By design, the ICADDY expects to be linked up with the ISP within one minute. If the modem takes 45 seconds or more - to negotiate a connection the ICADDY will time out and re-dial the connection [and usually re-connecting with the same results]. Simply put, if the phone connection is bad or marginal - the ICADDY may not work.
If you want Internet based reporting from a field Data Logger this solution may be an option for you. Success of this project will ultimately depend on the your local ISP selection and how well the local phone connection is. Hardware costs for the upgrade will cost around $500 plus monthly Cell Phone charges. Keep in mind that you will only need a single ISP Dial-up Account even though you may have multiple units in the field accessing the account. You need only to have the units access the ISP at different times to 'dump' their data. The B&B ICADDY is pretty versatile. In my application, I programmed it to send E-mail. The ICADDY can also be programmed to FTP the data to the ISP as well. This means that the data can be sent as raw Log data or even as a Web Page. The flex ability for the output format is determined by the Tiny BASIC Program. The ICADDY is just the delivery method.