<aside> 💡 Use this template to create guidelines for all of the engineers on your team. Add a table of contents by typing /table of and pressing enter.

</aside>

Requesting an ad-hoc test at HCRO

All tests at HCRO must first go through a test request process. The test request process is initiated and tracked via email. Email [email protected] and [email protected] for initial processing (additional stakeholders will be looped in as applicable). You will be guided through the process from there.

[email protected] provides feedback on the validity of the test and the test design and will approve or deny the test. [email protected] schedules and runs the test and is responsible for getting you access to your data in a timely manner after the test has completed.

Provide sufficient background on why test resources should be allocated for the test (specifically, address why the test could not be completed at CU, etc). A survey request email can look as follows:

Subject: RFS Test Survey Request

Purpose of survey (what you hope to accomplish)

[Include a screenshot of your test parameters loaded into the GUI if you can. If you can't include a screenshot of your test parameters in the GUI, just describe the test you want to run and feel free to add information about what you expect to see/hope to accomplish, the urgency of the test, any other relevant info, etc.]

Organization/site name:

Standard survey or a sweep? _____________________________

Number of RPi (which sensors do you need?): _____________________________

Bandwidth: _____________________________

Center Frequency or Frequency Sweep Range: _____________________________

Receive Gain in db: _____________________________

Desired length of each recording: _____________________________

Time between recordings: _____________________________

Are you interested in randomizing the time between recordings for statistical purposes?

Scheduling:

Give your desired survey length (eg 10 minutes? 1 hour, 24 hours? 1 wk, 2 wks?) and reason for choosing that length.

Desired Data Collection Start (time and date): _____________________________

Desired Data Collection End (time and date): _____________________________

Your survey might not be approved if the request is not specific enough, so it is recommended to initiate a compelling and specific survey request. If your survey is not approved, feedback will be given as to why and if applicable, further testing at CU will be recommended by the lead engineer.

Initiate an RF Survey at HCRO

Tests at HCRO are developed in HCRO Bi-Weekly Meetings (Tuesday at 12pm MST) with all stakeholders present. An initial test plan document should be filled out based on the results of the meeting. The test will undergo a test design review with the Lead Engineer. This should all be done in writing via email. Other stakeholders are looped in as needed.

If the test is deemed to be valid for the mission and is deemed compelling, i.e. the test cannot be performed anywhere else (e.g. the Denver metro area, CU campus, or the CU testbed, etc.), then the test will be submitted for pre-testing.

Pre-testing is as follows:

CU Testbed:

  1. RF Survey code updates are run on the CU Testbed and CU Server.
  2. A copy of the desired test is loaded in the GUI and emailed for approval to the Lead Engineer.
  3. Upon approval, the test is initiated on the CU Testbed and runs for the necessary amount of time.
  4. The results of the test are evaluated by [email protected] and [email protected]. Follow-up and additional testing is performed as needed (i.e. steps 1-4 will be repeated as needed).

HCRO RFS System:

  1. As needed: RFS code updates are run on the HCRO RPi and HCRO server by [email protected] and [email protected].
  2. As needed: Pre-testing may be additionally required to ensure readiness. The HCRO system is not an exact one-to-one copy of the CU testbed: in particular, HCRO utilizes a network drive for storage and CU utilizes rsync for backup.
  3. Checks are performed on the HCRO RFS system by [email protected] and [email protected].
  4. A copy of the desired test is loaded in the GUI and sent for final approval to the RFS Lead Engineer.
  5. Upon approval, the test is initiated on the HCRO system. In the first hour of the test, initial checks are done to ensure the test is running properly on all systems.
  6. An email must be sent to all stakeholders alerting them that the test is underway and initial checks were passed.
  7. A Daily Status Report is created for the test following the guidelines in this document. See “HCRO Daily Status Checks” for how to initiate this document.

HCRO Daily Status Checks

While a test is running at HCRO, Daily Status Checks will be completed by a trained HCRO RFS site admin. Current trained site admins are [email protected] and [email protected].

Daily Status Reports are the product of Daily Status Checks. A Daily Status Report Template can be found here and are saved here. Both links point to the dedicated HCRO Google Drive directory. If you don’t have access, request it by contacting one of the administrators.

The guidelines for completing Daily Status Checks are:

  1. Open this Google Drive directory and go to File > Make a Copy; save to Daily Status Reports folder, rename file > Save. Follow the guidelines in Row 1 and Row 2 of the cells.
  2. In an internet browser:
    1. Log into [email protected]. Review any alerts and investigate as needed.
    2. Review the daily temperature logs.
      1. The temperature logs should decrease during the night and increase during the day. The temperature should ideally not go above 70 degrees Celsius. Anything above 80 degrees Celsius is considered critical.
    3. Review any unknown logins to the RPi.
      1. The RFS GUI logs into the RPi when a test is started or interrupted. Therefore unknown RPi logins should be investigated as they could indicate that a test was somehow interrupted or compromised.
  3. On each RPI:
    1. Check the stream file for the previous day:
      1. cd /home/pi/logs;ls -la
      2. grep -E ‘CRITICAL|ERROR|WARNING|DEBUG' stream-YYYY-MM-DD.log