NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Electronics > RfiGroup > RfiDataBase

Changes | Index | Search | Go

RFI Database Project

• Project Proposal
  • Deliverables
  • Need & Benefit
  • High Level Requirements
  • Assumptions and Risks
  • Resources
  • Signatures
• Project Planning Sandbox
  • Out-of-Scope Deliverables
  • Implementation Options

Project Proposal

Deliverables

1. An easily accessible database that will serve the Observers and GB Staff as a central, searchable repository for knowledge about interference at Green Bank.

2. A data entry interface that the RFI group can use to manually enter content.

3. A data entry interface that Observers and GB Staff can use to report RFI.

4. A query interface that allows query storage.

5. A graphic visualization tool for frequency information.

6. User Documentation for Deliverables 2, 3, 4, & 5.

Need & Benefit

RFI Group: When RFI is reported at Green Bank, the RFI group gathers frequency and other signal characteristics and then consults allocation tables, FCC databases, the NRQZ database, and possibly also monitors and DFs (direction finds) the interference in order to identify it. If identification is successful, we may approach the responsible party for either legally required compliance or voluntary cooperation. After that, all we have learned from this considerable effort is filed in one of several disconnected and loosely organized formats (email records, NRQZ database, spreadsheets living on individual PC's, etc.) where it is not readily accessible nor easily searchable. Deliverables #1, #2 and #4 would provide us with a central, searchable repository for this knowledge.

Observers: Deliverables #1 and #2 are prerequisite for Deliverable #5 as well as a number of easily imaginable out-of-scope deliverables that would be useful to observers, particularly integration/use with/by the Dynamic Scheduling project software.

Deliverable #5 This tool would allow observers, in advance of observing, to easily identify coordinatable sources and give them the opportunity to request a fixed window from Dynamic Scheduling and Coordination from the RFI group. An IDL graphical visualization tool to enable this process has already been prototyped. (See KnownSourcesDisplayIdLprogram) If properly integrated into the observing experience, this same tool could be simply an IDL function like "Molecule" that overlays database content on IDL spectral displays, or it could be two seperate tools, TBD.

Both the Observers and the RFI Group: Deliverable #3 would steer observers to the proper channels for reporting RFI and communicate to them what information our group needs in order to begin the identification process. It also ensures that reported RFI is formally documented, and spares duplication of effort.

High Level Requirements

• Database (deliverable #1) must be accessible to different types of interfaces from machines that may run different operating systems.
• Deliverables must meet the requirements of their end user-groups.
• Deliverable #3 must include a notification mechanism of some kind (email?/status page?/helpdesk?).
• Security concerns must be addressed:
  • Fields containing sensitive contact and history information must be READ protected.
  • Fields pertaining to known sources must be WRITE protected.

Assumptions and Risks

• Future maintenance: Different user groups will likely have different priorities assigned to their requests. For instance, a request that originates with the Observers is likely to receive a higher priority than one that originates from the RFI group. Therefore:
  • It is HIGHLY DESIRED that deliverables #2 and #4 are easily user-modifiable. If they are not, this poses an unacceptable risk to the RFI group. Certain kinds of flexibility could be designed into a GUI at the planning stage to mitigate against this risk; alternatively, a user-modifiable GUI could be developed.
  • It is LESS IMPORTANT for deliverable #3 to be easily user-modifiable. It is important to preserve the features required by the RFI group, but these requirements are not likely to change.

Resources

• A prototype MySQL RFI database (prototype of Deliverable #1) exists.
• A prototype IDL application exists which uses the prototype MySQL RFI database structure (This is an Out-of-Scope deliverable).
• Preliminary documentation exists for the database structure (Deliverable #1).
• Preliminary documentation exists to define the information flow in the RFI Data Entry Interface (Deliverable #2).
• Possibly there are examples of how local RFI source information is documented and distributed at other observatories?

Signatures

AUTHORIZED: I acknowledge the need for and benefits of the deliverables, and am willing to authorize the creation of a Project Charter.

Written	- C. Beaudet - 10/10/07
Approved by Scientist Sponsor	- J. Harnett - 11/27/2007
Approved by RFI Sponsor	- C. Beaudet - 10/10/07
Approved by Software Division Head	- AmyShelton - 22 Oct 2007
Approved by Project Manager	- KarenONeil - 29 Nov 2007

Symbols:

• Use %Y% to indicate approval (will display )
• Use %X% to indicate disapproval or need for more information (will display )

Project Planning Sandbox

Out-of-Scope Deliverables

• Possible integration/use with/by the Dynamic Scheduling project software
• IDL function for obtaining parameters to determine "harmfulness index"
• A tool for making it easier to visualize GBT data on a spectrum analyzer
• A Helpdesk Utility may be out-of-scope (feasibility of building one into Deliverable #3 TBD by software engineer)
• ArchivalMonitoring

Implementation Options

Deliverable #5 could be implemented as two tools:

• Polishing/finishing/adapting the IDL graphical visualization tool
• IDL function like "Molecule" (written by BobGarwood?) to overlay database content on IDL spectral displays

Collaborator Comments, Pros/Cons:

Observers: (need more input)

FrankGhigo "Observers don't want to spend a lot of time reporting RFI."

RFI:

CarlaBeaudet (in order of preference)

• Option #4 would be my choice for several reasons:
  • The GUI is fully user-modifiable, and modification would not require further Software resources after the completion of this project.
  • The Observer will have to use GBTIDL anyway, to generate at least one topocentric "snapshot" of the interference.
    • GBTIDL already has a function, "TOPO", and marker functions to extract the requisite topocentric frequency.
    • GBTIDL will already have some information about the project #, so that's one less thing for the observer to type in.
• Option #3 may be acceptable if:
  • the GUI could be accessed off a "Report RFI" button somewhere in the GBT user interface (again, see Frank's comment).
• Option #6 may be acceptable if:
  • Certain kinds of flexibility are designed into the GUI at the planning stage to mitigate against the risk of future maintenance.
• Option #5 may be acceptable if:
  • the GUI could be accessed off a "Report RFI" button somewhere in the GBT user interface (again, see Frank's comment).
  • Certain kinds of flexibility are designed into the GUI at the planning stage to mitigate against the risk of future maintenance.
• Option #2 is unacceptable because:
  • Observers wouldn't use a MS Access GUI to report RFI (too much cross-platform hassle - see Frank's comment)
• Option #1 is unacceptable because:
  • An Access Database can't be accessed (name irony intentional) directly by the IDL utility or web-based GUIs.
  • Observers wouldn't use a MS Access GUI to report RFI (too much cross-platform hassle - see Frank's comment)

Software:

LihongYao

• Options #1-#4 Why Microsoft Access Is Not the Best UI for RFI DB?
  1. User unfriendly, e.g. Lots of steps before one can link to the database existing in the server through the network; multiple clicks for field selection; no casecade menu selection, therefore more buttons and forms are needed; buggy.
  2. Limited development potential: MS Access can be applied to small project but scale poorly to larger projects involving multiple concurrent users because it's a desktop application, not a true client-server database.