Diary # 24

EXPLORING SATELLITE OPTIONS

 

There are many places on this earth where no 'terrestrial' wireless (or wired) links to base stations, universities, or the Internet are feasible - or even possible. Some are even impracticable to reach - or service - manually. Yet many such areas need to be the subject of biological scientific or long term environmental research projects. And in the future, with very large scale, real time, comparative analysis of data from nature being made possible by high speed internetworks linking far flung data bases, the need for deploying more data-collection points will go up dramatically. Collecting the information from them will require more and more automation of the task.

One theoretical solution is to use a bi-directional satellite Internet service to reach an independently-powered base station, and then reach out by terrestrial wireless to various data loggers within the radius of range of these data radios.

But satellite Internet services, smack up against the iron limits of the speed of light, introduce latencies that can range from 500 to 2,000 milliseconds when the signal travels up to 44,000 miles up and down, as well as unpredictable delays through network congestion. All of which can affect the interactive timing of data loggers which are not specifically designed to endure variable rates between software. Including one of the most popular and reliable products - Campbell Scientific's PC208W packages and their CR10X, 23X data loggers in the field far away.

Wireless connections, between the data logger and the base of the satellite services, introduce still other variables which have never been examined closely, which we will attempt to do over the next two years of this project.

Of course the object of all this is to use a combination of wireless solutions to get the most reliable, flexible, and useful network at the lowest total cost.

 

First the Satellite Link

The first thing was to install and test a late model Satellite Internet Service under controlled conditions. We chose Tachyon's recent deployment of a 64-256kbps (up) to 300kbps-2mbps (down) service which uses SatMex5 KU band satellites to start with.

Red5, a San Diego based Internet service, which partners with Tachyon provided the installation on our Old Colorado City Communications at 38 degrees 50 minutes 51 seconds North Latitude, 104 degrees 51 minutes, 40 seconds W Longitude, 1873 meters elevation. A one meter dish antenna was installed on the 3d floor roof of our 1891 Victorian Brick building, with the de-icing option installed. Three wires were extended 100 feet down an old chimney as a conduit to our Lab premises. The IDU was installed inside our office space. The system was turned on July 17th, 2000.

Tachyon 1.1 Meter Dish Antenna on Old Colorado City Communication's Rooftop

 

ODU - Outdoor unit - Tachyon Radio

 

IDU - Indoor Unit of Tachyon Satellite in Old Colo City Communication's Lab

 

Old Colorado City Communication Lab

 

The normal installation by Red5 gives the customer 5 IP addresses to use off the 10baseT RJ45 port on the IDU.

The first thing to check was its performance from a Windows machine attached to the IDU. Running standard Explorer Web Browser was quite satisfactory. Which was to be expected, for the whole service seemed to be optimized for the office/browser market. Pinging ICMP packets to various remote destinations - including looping around from the Tachyon base facility in San Diego, through Red5 to the Net, thence back to our Old Colorado City network via Qwest and our Aironet wireless backbone from Qwest to our offices, and into our Linux servers, resulted in measurements from 800 to 1200ms latency.

I observed an odd phenomenon. When pinging the IDU from our Linux systems we noticed an alternating patterns of delays. Every other returned packet would be up to twice the delay of the other. i.e. when pinging the IDU address from our Linux server, over the national Internet results in this typical pattern.

PING 216.7.145.65 (216.7.145.65): 56 data bytes

64 bytes from 216.7.145.65: icmp_seq=1 ttl=235 time=1620.3 ms

64 bytes from 216.7.145.65: icmp_seq=2 ttl=235 time=621.3 ms

64 bytes from 216.7.145.65: icmp_seq=3 ttl=235 time=1305.9 ms

64 bytes from 216.7.145.65: icmp_seq=4 ttl=235 time=892.4 ms

64 bytes from 216.7.145.65: icmp_seq=5 ttl=235 time=1304.9 ms

64 bytes from 216.7.145.65: icmp_seq=6 ttl=235 time=882.7 ms

The pattern was the same from other systems where we have an account, such as one in California that is directly connected by DS3 to the backbone of the network.

We are not sure what causes this, and wondered whether it would cause erratic behavior when the PC208W software was operating. It appears to be specifically a characteristic of the Tachyon satellite portion of the link.

 

Satellite to Server Performance

The next step was to install a small Red Hat Linux powered IBM Laptop as a web server connected directly to the Tachyon IDU.

This configuration might be used in the field, if remote sensors, or data loggers, or even video or audio devices are deployed which send 'back' only as far as the web server their data. While it is becoming possible and sounds very appealing to permit anyone on the Internet to reach, in real time, data loggers and other devices deployed in the field, that may not be a good idea in most cases. Small devices can be overloaded by simultaneous accesses to the small ram onboard. Preliminary screening of data, to reject the obviously bogus data from failed sensors or broken connection, will often be desirable. So permitting near, but not actual, real time access to the data, images or sounds, can be done by programming systems to automatically send, store, and updated by automatic feeds from the end devices - whether they be numerical, video, or audio, becomes possible with a small, low power drawing Linux web server installed at the end of the satellite feed, between it and the data logger or field sensors, such as the Axis cameras we have begun to experiment with.

The web access from the outside, through the satellite feed, set for our purposes at 64kbps up and 300 Kbps downlink (the lowest speed option with Tachyon) was quite satisfactory.

http://168.215.212.132

 

Satellite to Data Logger Performance - NL100 Interface

The big step from just using the satellite Internet for bi-directional web access, or sending receiving email or files, to linking interactive software to data loggers is another matter.

In the first place, almost all Campbell and Sutron, as well as Hobo, Pacom data loggers are designed to be accessed by low speed serial connections, with 9,600 baud being the most ubiquitous. The reason was simple. Numerical data collected over time from sensors attached to the most used data loggers makes pretty small files. Even months of collection result in data files no more than a few megabytes of numbers. Since processing that data - putting it either into a data base, or converting it into graphical charts - takes place in the computers in research centers, and not in the data loggers themselves - the flow of data from the logger to the disk of a computer can be a small serial line task.

But the Internet does not run on serial, or circuit switched, connections. It routinely is based on IP packets and packet switching, and uses Ethernet 10baseT cabling and protocols. Even though a cell phone, with a 9,600 baud serial modem connection to a data logger, can fetch a day's worth of data from a logger in just a minute or so, the traditional Campbell Scientific software for pulling data out of a logger or a storage module, only 'talked to' the serial port on a base computer. PC208W software, up through Version 3.1 operated this way only. So while serial data radios - such as Freewaves, or World Wireless Hoppers or Microhoppers - could be used to link a PC with a remote CR10X or 23X - which is what we have deployed in both Luquillo and Trout Lake LTER field sites, neither remote, Internet connected researchers could access the data logger through the network, nor could higher speed ethernet-connected radios, such as Aironets, YDI's or Teletronics be used. Nor could a Tachyon satellite feed be directly connected to a data logger or set of them - since the data loggers produce single-channel serial, and the satellite feed comes out ethernet and IP packetted. Until now.

Campbell has just started to ship a new version of PC208W software. Version 3.2. With its companion hardware, called NL100. It is a partial solution to the Internet accessible Data Loggers.' Partial, because it was not actually designed and priced to be put at the location of each data logger - which at $500 apiece is rather stiff when a CR10X costs only $1,000 - but in universities and offices where the researchers nay be on a network - ethernet connected. One NL100, which translates an Ethernet/IP connection to a serial connection can be set up at the research base station, run PC208W V 3.2, and access the NL100 by IP routing and ethernet, then come out of the NL100 device by modified RS232 serial (CSI/0) and thence into a serial radio such as the Freewave to reach a data logger.

NL100 is in the foreground, cover off. Ethernet in at the right, CS I/O out to data logger in the rear via serial cable to CS I/O into the CR23X.

This solution DOES contain promise for a different problem which will increase in the future - 'splitting' an IP/Ethernet data radio signal at a small field 'hub' location so that one branch can go into the NL100 and thence into a CR10X or 23X, while the other branch goes into a IP/Ethernet connected device such as the Axis Web Cam - both being at the end point in the field. This is similar to what we need to do at the Poker Flat/Caribou Creek confluence in Alaska. Over one 2Mbps data radio being able to service both the web camera, with its ethernet access and IP number inside, and a serial connected 9,600 baud CR21X.

Then the NL100 also may solve our Satellite IP to data loggers problem. So, in a bench test mode, Dan Withers from Seattle, lately working for World Wireless, but now able to work for our NSF project in various ways, and I got the NL100 and PC208W v3.2 working first in its intended-design mode.

A. The NL100 hardware has three ports - a 10baseT Ethernet port, a 9 pin RS232 port, and a modified RS232 port called 'CS I/O' (which matches the voltages of the corresponding CS I/O port of the Data Logger, and thus require only a serial cable between them, rather than the $175 SC932 DTE/DCE Adapters which are required between standard serial connectors on devices such as Freewave or World Wireless radios)

B. Using a serial cable and Hyperterm running in a Windows PC, pulling up the simple, sequential-settings menu, in the NL100. Setting an IP address in the NL100 - 216.7.45.67, and its associated Subnet Mask number 255.255.255.248 - from our assigned block associated with the Tachyon/Red5 system.

We left all other menu choices at their 'default' settings. Which includes a novel 'Serial Server Port Number' that must be assigned to the NL100 and entered in a corresponding place in the PC208W software setup.

This required 'Port Number' appears to have been put in by Campbell in order to differentiate one NL100 from another one in the same local area network, permitting the same IP number to be used in all NL100s. This may give us problems later if we attempt to use anything other than the NL100 to convert serial to ethernet-IP in a wireless network. There are several low cost OEM devices from Lemos that can convert an IP, Ethernet, signal, to serial. The NL100 costs $500, and has a number of additional capabilities besides the simple conversion of IP to Serial. With future capabilities built in, such as SLIP protocol which eventually will work with later generations of Data Loggers that incorporate IP addressing right into the logger.

But for our purposes, it is clear, at that price, that deploying a substantial number of data loggers - like 5, 10, or 20 - each requiring an NL100 at $500, can be rather costly when the CR10X data logger is only in the $1,000 range.

C. We then configured the PC208W version 3.2 - which has the additional - to 3.1 or earlier - IP functionality. The ability to add a 'Socket' device, and assign an IP number and the port number to it. This version of PC208 software is required for any work with the NL100 - and is sold as part of the NL100 purchase, complete with CD ROM and full PC208W manual, with additional sections on the IP functionality. The NL100 itself has a manual too. With instructions how to remove the device cover, and use a jumper to reset to default the whole device, if one screws up the initial settings and locks oneself out of the device. Which, of course, unfamiliar with the device, and even the choice of terms used by Campbell, we managed to do.

D. The PC208W 3.2 software, of course, can still be used with serial devices, as 3.2 and before were designed to do. So, by default, when one 'Adds Socket' it is called SOC1 (while Add Device would generate a Com port name like COM1). One puts the IP address of the NL100 in it, and the Socket Number, which is this case defaulted in the NL100 to 6783 in the software.

E. We then set up a CR23X Data Logger with a serial ribbon cable between the CS I/O ports on the logger and the NL100. Then we powered it and the Data Logger - 12 volts with a Marine battery of the type we would in the field - with the small adapters Campbell provides. We ALSO, knowing there would be substantial latency in the eventual Satellite link, we put 1,500 milliseconds of delay in the PC208W software configurations for SOC1 and the CR208X screens.

F. Initially, with an Ethernet cable between the PC and the NL100, and the CS I/O ports on the NL100 and the CR23X connected, we then ran the PC208W software, called for the connection, and got the desired 'CONNECT' with the usual date/time of both the Data Logger and the PC displaying. Which we have learned is the acid test of whether the PC software is talking correctly to a data logger. There does not need to be any 'data' in its memory. The little visual icon of two plugs, either plugged in 'connected' or separated with wiggly lines emulating electrical pulses, showing 'attempts' to connect, help inform the user of what is going on, including - importantly - when a drop occurs somewhere in the long chain of connections we are attempting - satellite, wireless, serial.

 

Satellite to Data Logger, Directly Connected

The next step was to test reaching the Data Logger via the Tachyon satellite link from a PC running PC208W 3.2, but with a hard wire between the IDU Ethernet port and the NL100.

In other words, we wanted to see if the latency in the satellite link makes a big difference in reaching the data logger, without even the ADDED consideration of additional terrestrial wireless links.

With the 'delays' set at 1000 milliseconds or higher in the PC208W software, I repeatedly, over several days of intermittent testing, reached the CR23X just fine. And it held the link with only one drop over about 10 tries.

This confirms that, even with 800-1500 ms latency in the satellite link, a reliable connection into the remote field could be expected.

PC w/PC208W,v3.2 <-Internet-><-Tachyon satellite->IDU<-->NL100<->CR23X

 

Satellite to Wireless to Data Logger

But of course there would be few if any occasions where a satellite ground station were placed within Ethernet hard wire distance (2-300 feet) of deployed data loggers. So the final, acid, test of the Satellite <--> Data Logger link would be to add a pair of 1-3Mbs ethernet-equipped Part 15 radios between the base station of the Tachyon Satellite link and its IDU, and the NL100 connected to the Data Logger.

Satellite IDU<-ethernet>Radio<--wireless-->Radio<->NL100<-serial>CR23X

For this I used a pair of Teletronics 2.4Ghz, 2Mbps, Access Point radios, which terminate in ethernet connectors. One to go into the NL100 where it would convert the signal to serial for the CS I/O ports. The other into the Tachyon IDU Ethernet port (or more precisely, a Hub, so more than one device could be used) All this was across the lab room - no long reaches.

'Data Logger/NL100 connected to a Teletronics Radio Access Point (upper right), which talks to a second radio that is then attached to the Satellite Ethernet port.'

 

Well, it works. Not as reliably as the setup without the final pair of radios, but it does connect. The problem seems to be that, whenever there is a long delay, caused by any number of conditions - general Internet congestion, or retries for the satellite link, the 'handshaking' time out latency is exceeded, and the connection drops, only to reconnect quickly (within 5 seconds).

Of course 'drops' like this during a download of data or upload of compiled upgrade code, would be unsatisfactory. Over 3 days of intermittent tests the connection, once established (takes up to 10 seconds) will hold up from 20 seconds to 3 minutes or more.

However we have not had the opportunity to 'tweak' the connections, varying all the possible settable variables - the delays set in the PC208W software, the radio rates and retries, possibly the satellite delays. Or even consider a 'buffering' arrangement.

If you have PC208W v3.2 software running on a network linked to the Internet, you can try setting a 'SOC1' (or whatever) Socket Device, with a CR23X Device, pointed to IP 216.7.145.67 and Port 6783, with 1,500 ms delays, and attempt to connect. (We will leave it up for a month or more from Oct. 1, 2000). See if you get a connection.

 

Implications

We have demonstrated on a 'Dr Watson come here I need you' level of experimentation so far, that the model I propose - a satellite base station placed in a remote area, with independent power operating it, connected to an array of NL100/Data Loggers linked by no license spread spectrum wireless radios out to their range (a few hundred meters to 5-10 miles) each with its own IP number assigned, can work to permit the fetching of CRX10/21/23X collected data by any researcher on the Internet running PC208W v3.2 Campbell Software, and supplied with the requisite IP and Port numbers for each data logger.

If 10 such data loggers and NL100 devices were deployed in a remote area, all connected to the Tachyon base unit by $150 radios, the cost per month (satellite cost) would work out to be about $80 per logger per month - with access 24/7 anywhere in the world.

 

Dave Hughes

Principal Investigator

 

NEXT

PREVIOUS