January 2003
Abstract
A collection of design notes, diagrams, and documentation for the radar archive and display development. The development intends to upgrade the hardware and software for the EDLORA display and archiving components. It is also hoped that much of the design and software can be shared among similar components needed for Rapid DOW (R-DOW).
This and other documentation should be available on the ATD web site: RADD web directory.
Table of Contents
As part of ELDORA's longer term improvement plan, one of the first stages will be a replacement of its archiving and display subsystems, both hardware and software. Meanwhile, there is an initiative to find some common ground among ATD's radar processors in general, in both hardware and software. Charlie and Eric have been cooperating on the hardware side of a radar processor spec which could be shared between ELDORA and MAPR and eventually SPOL. Eventually ELDORA and SPOL will be based on PIRAQ 3, MAPR is presently based on PIRAQ 2 but someday will be PIRAQ 3, and Rapid DOW is based on PIRAQ 3. (Is WARDS also?) This confluence of hardware technology among ATD radars and the devlopment of a new display and archiver for ELDORA seems an appropriate opportunity (to attempt) to consolidate the software also. This software development is an opportunity to reduce the number of similar-but-different radar archive and display implementations among ATD radar systems. Rich, Gary, and Joe are designing and implementing the ELDORA archive and display components and an underlying software framework; the immediate goal is to upgrade ELDORA, and an ulterior goal is to share the development and components between both ELDORA and R-DOW.
The (eternal) hope, as usual, is that it will be worth the effort to specify a data interface and software components flexible enough for multiple radars to share, so that similar components like archiving and display can be written to that one interface and shared between radar systems. Developing and maintaining one data interface and one set of radar processing tools should be more efficient than developing and maintaining several, especially if the interface can increase the consistency and dependability of the data stream seen by all of the downstream radar data analysis and processing tools.
This document describes the design and development of new ELDORA display and archive systems, including the hardware systems and software framework on which those systems will be based. It is a work-in-progress, meant to be accessible, updated, critiqued, and extended as needed by everyone. If anyone has corrections or ideas to pass on, you can send them to Gary or Rich.
Rich talks about the existing setup for ELDORA in general and the display and archive components in particular.
Existing graphics hardware is obsolete, lacks spares, and has been a major point of failure.
The MCPL communication hardware is obsolete and has been a major point of failure.
Current recording to DLT lacks realtime dual recording for robustness and slows the post-processing of collected data.
By using COTS components, we will be able to obtain spares easily, reduce rack volume and costs for maintenance.
Provides part of a larger, incremental advance towards to an ATD-wide radar (and lidar?) architecture.
Minimize the impact on the existing ELDORA system.
Use only COTS hardware.
Open source software components. (AKA Farewell VxWorks.)
Flexible stepwise development, allowing for future integration of evolbin design changes, while minimizing short term risks.
Cross-platform compatibility.
We are trying to define more exactly what the performance requirements for the radar will be and how they impact the choice and design of hardware and software components. Our current guestimate for ELDORA is that the minimum dwell time is 10 milliseconds, meaning 2 beams of data are generated at most every 10 ms, one beam for each radar, fore and aft. Each beam has on the order of 300 gates. There are usually three parameters in the ELDORA data stream, velocity, reflectivity, and normalize coherent power. In the DORADE parameter blocks, parameter data are 16 bits per gate. So one gross estimate for the data rate which ELDORA software must support: (2 bytes/param/gate * 3 params * 300 gates * (2 beams / 10 ms)) equals 360 KB/second. The display needs to render at least (1 beam / 10 ms) or 100 beams/second.
In the case of ELDORA, the data bandwidth will not push against the limits of the network, hardware, or software. The realtime display is the most demanding, since video graphics historically have been slow. Consequently it has received much of the focus so far, and the solution of using accelerated OpenGL seems to be more than adequate for the required performance.
For Rapid DOW, the plan for 2003 is to support 6 frequencies, 1000 gates, and 200 beams/second. With 12 bytes/gate, that totals to about 15Mbyte/second. The realtime display does not need to render all of the gates in a full sweep, since that exceeds the useful resolution of the graphical monitor. Instead the beams can be averaged down to 500 gates, rendering at a rate of 100 beams/second.
The following figure outlines the components of the current ELDORA system which will be replaced. Only the interfaces which cross the partition boundary will need to be modified.
The Rapid DOW development is happening concurrently with the ELDORA upgrade development. Since both R-DOW and ELDORA have similar architectures and needs, there should be an opportunity to share design and software components between the two systems. So one of the design goals is that the components be general enough to be applicable to both R-DOW and ELDORA. Not only might this save some development effort, in the long run it should make both systems more maintainable.
Right now the most significant shared component is the display. The prototype performs fast enough to handle both ELDORA and R-DOW data.
The archiving component also has the potential to be shared since both R-DOW and ELDORA will be using removable disks as the archive medium. However, right now R-DOW already has a Windows-based prototype, so there may be no need to use ELDORA's.