Applications > Seismic Monitoring and Structural Response > CENS Data Communication Controller and Network Timing
The objective is to build a new Linux/radio data communications controller (CDCC) based on the newly developed Intel Stargate hardware platform, the CENS EmStar application framework, CENS' novel time synchronization scheme, and interfaced to the Quanterra Q330 digitizer.
Fabrication of the CDCC
Summary of Design and Fabrication Program
The objective was to construct a low-power, computer-controlled box, that would be ruggedized for geophysical use, would communicate with commercial digitizers, run on the Linux operating system, run the Antelope real-time software package, be capable of backup storage of data, and allow network communication using 802.11 technology and CENS network timing synchronization over distances from 10 meters to ten km.
The initial steps involved porting Antelope software to the Intel Stargate computer and building various breadboard prototypes. The design of the system was finalized the appropriate parts ordered. For the enclosure we required it to be transparent to radio waves, rugged and watertight. We tested 6 different enclosures until we found one that was rugged and did not leak. We chose a heavy duty waterproof fiberglass box that is engineered for internal mounting plates. The box has been custom machined to mount 3 military specification connectors and one antenna connector. The mounted connectors are soldered to a custom-made PC board (PCB). A mounting plate is used for attaching the Stargate boards as well as the brackets for wireless PCMCIA cards (to prevent failure from shaking, vibrations and from breaking pins and connectors). The mounting plate and the PCB were designed and drawn by us and manufactured outside UCLA. The PC board also houses a 3W power adapter (step down to 5V from Q330’s 15V), Ethernet RJ45 jack for data transmission from/to Q330, RJ11 jack for CENS network internal timing, Serial and USB connectors, and many test pins that have already proven to be useful. A CENS timing PC board was designed and fabricated and is attached to the Stargate. All hardware is designed to survive heavy use in a harsh environment and being submersed under water.
To connect to the Q330s and Guralp seismometers we designed and ordered cables from ISC Engineering. We also designed and ordered pigtails (short cables) for connecting external antennas to PCMCIA radios inside the box. We have tested stub antennas inside the box the for small networks (tens m spacing) and Yagi and Parabolic antennas for large networks (10 km spacing). Four fully assembled boxed were successfully tested in April 2004, and have been used for seismic data collection and timing synchronization tests.
We are now ready for a bulk production run. The long lead-time parts have been ordered and delivered for the 60 x CENS Data Communications controllers (Fig. 1). The Antelope software runs on the Stargate and has been interfaced to the Quanterra digitizers.
Fig. 1 Development of the Prototype Stargate Data Communications Controller (left). On the right the seismometer, Q330 digitizer, and CDCC.
Network Timing
The CENS systems software research required in support of our seismic deployments will fall into two major categories: time synchronization and ad-hoc routing. Time synchronization has been our primary area of focus so far, and we expect to significantly ramp up our efforts in routing in the coming quarter. For network time synchronization, we have built, and are characterizing, a system called "LessGPS". LessGPS provides precise timing services via the wireless network in a manner that mimics the service provided by a GPS receiver. LessGPS generates NMEA-format data strings and a PPS (Pulse Per Second) signal, just like a real GPS receiver. Devices that expect time-sync input from a GPS receiver can therefore work, unmodified, with LessGPS.
LessGPS is based on Reference-Broadcast Synchronization, or RBS, first described in [Elson, Girod, and Estrin, OSDI 2002]. RBS is quite flexible, and can be used in a variety of topologies and application areas. LessGPS uses RBS to construct the underlying peer-to-peer clock relationships -- that is, relationships between pairs of neighboring clocks in the system. In wireless networks, RBS has been shown to be up to 10 times more accurate than NTP (Mills' Network Time Protocol), using equivalent hardware and operating system support.
LessGPS adds to RBS a global-time service, synthesizing all of these local timescale relationships into a global clock. It works in two possible modes. The first is "steered time," where the goal is to keep all clocks synchronized to UTC, just as a real GPS receiver would. In this mode the network requires access to a source of the UTC timescale at one or more locations in the network. Time and frequency are propagated from nodes that have a canonical view of UTC to those that do not. The second mode is "unsteered time". If no clock in the system has a reference to UTC (i.e. no real GPS receivers are available), LessGPS can still keep all clocks in the system in relative synchrony. However, the absolute time will not be UTC, and clock frequencies will drift away from the definition of an SI (cesium) second. Of course, steered time mode is preferable, but unsteered mode is a better option than completely unsynchronized clocks. LessGPS is in the final stages of implementation. We have demonstrated the function of "faking" a GPS signal, setting the clock on the Kinemetrics Q330 digitizer -- effectively fooling the Q330 into believing that a GPS receiver was attached. Tests of the system precision are underway but are expected to be on the order of 20 microseconds. The complete system will soon be field-tested in the Four Seasons deployment, as well as UCLA-local test-beds.
Ad-hoc Routing
The second systems research area for the seismic application is scalable, ad-hoc routing. While this problem is well-studied in general, our research has focused on a special case of the general routing problem. In systems such as the Seismic data collection network, arbitrary any-to-any routing is not the common case. Most data travels along a tree between a data collection point (the root) and nodes that generate data (the leaves). This special case of routing has not been extensively studied, and we believe routing performance can be improved significantly by designing an algorithm that leverages this constraint. In this research area, much of our effort so far has been in building test-beds and other infrastructure that will facilitate rapid prototyping and quantitative characterization of new routing algorithms. We use EmStar, the CENS software framework. Many recent additions to EmStar facilitate debugging of routing algorithms, such as an improved visualization program that computes real-time routing-quality metrics, such as average computed path length. The most compelling reason to use EmStar for routing development, however, is EmStar's integration with the "ceiling array" of real radios. Much of the existing literature in ad-hoc routing is analytical, assuming a "unit-disc" model of radio range, or a similar, basic simulator model. Our early deployment experiences have shown us that this is far from the actual case. Real radio behavior is very complex. Packet loss is not binary -- at different locations with respect to the transmitter, different packet loss rates are seen. The loss rate does not even increase monotonically with distance. Even for a fixed location, loss rates vary dramatically over time. The variance is seen over many time scales. These real properties of radios have deep consequences for the design of routing algorithms. Our ceiling array gives us a unique ability to innovate in routing algorithms, as rapidly as in simulation, but staying grounded more firmly in reality.
FACULTY
Paul Davis
Deborah Estrin
STAFF
Jeremy Elson, Post Docs
Igor Stubailo, Engineer
GRADUATE STUDENTS
Allen Husker
Rebecca Harrington
Lewis Girod
UNDERGRADUATES
John Propst