Best Practices on High Frequency Radar Deployment and Operation for Ocean Current Measurement

High Frequency Radar (HFR) technology refers to land based remote sensing instruments capable of measuring surface currents and ocean waves at ranges up to 200 km or more. HFR technology is widely acknowledged as a cost-efficient tool to monitor coastal regions and has potential use to monitor coastal regions all over the world. Globally, the number of HFR stations is steadily increasing. Regional networks provide real-time data in support of operational activities such as search and rescue operations, fast response in case of maritime accidents and spill of pollutants, and resource management. Each operator needs a general understanding of the working principles in order to ensure that instruments are managed properly. A set of harmonized quality assurance and quality control procedures is recommended, along with an effective approach to HFR data discovery and dissemination, to provide high quality measurements to the end users. Different documents providing best practices for operation and maintenance have emerged in the past years. They are oriented either to Direction Finding (DF) or Beam Forming (BF) systems, or to specific manufacturer’s radar systems. The main objective of this paper is to offer a comprehensive “Best Practices” document in an effort of ensuring consistency between different deployments and harmonized operations of HFR systems. This, regardless of system manufacturer, antenna design and setup. A homogeneous approach is given when possible, general concepts and definitions are introduced in order to provide a framework for both data processing and management steps. Examples are also given from the European HFR users with focus on Near Real Time data flow suitable for operational services.


INTRODUCTION
High Frequency ocean Radar (HFR) systems are cost-efficient tools to monitor coastal regions at a range of up to 200 km or more, with potential to monitor coastal regions all over the world. Oceanographic HFRs are mainly utilized to measure ocean surface current fields (Paduan and Rosenfeld, 1996;Gurgel et al., 1999) for applications such as search and rescue (Ullman et al., 2006), oil spill monitoring (Abascal et al., 2009), marine traffic information (Breivik and Saetra, 2001), calibration and validation of numerical circulation models, and data assimilation (Paduan and Shulman, 2004;Barth et al., 2008). Further applications of the HFR systems include mapping of sea state parameters (significant wave height, wave period and direction; Wyatt, 1990;Gurgel et al., 2006), wind direction mapping (Heron and Rose, 1986;Shen et al., 2012;Kirincich, 2016), tsunami early warning systems (Lipa et al., 2006;Gurgel et al., 2011), and ship detection and tracking (Ponsford et al., 2001;Maresca et al., 2014).
HFR technology relies on the Bragg resonant mechanism, that is a resonant backscatter resulting from coherent reflection of a transmitted radio wave by a particular train of ocean waves with half the wavelength of the transmitted signal. Since ocean waves travel with a non-zero speed, the frequency of the backscattered radio wave is Doppler shifted. For a radar transmitting at a central frequency f 0 , two narrow peaks (Bragg peaks) are theoretically expected in the backscattered spectrum, shifted ± f from f 0 , and associated with the waves traveling toward (right peak) and away (left peak) from the radar, along the radial direction (Crombie, 1955). When ocean waves propagate over a current field, an additional Doppler shift adds up to the one previously described.
Such frequency offset corresponds to the velocity of the component of the current approaching to, or receding from, the receiver, and is referred to as radial velocity vector in the standard operational HFR jargon. Further in-depth analysis of the full spectra of the backscattered signals can also provide information on the sea state, wind, tsunami and discrete targets (e.g., vessels). However, extracting information other than surface currents presents a much greater challenge since these are obtained from much weaker or partial parts of the signal, which are more likely to be corrupted by noise and interference (Barrick, 1977;Wyatt et al., 2006) and require integration times longer than those used for currents (Wyatt et al., 2013). To date, the great majority of HFRs are used to map ocean surface currents; as such, the best practices contained in this document apply to currents if not explicitly mentioned otherwise.
HFR systems need to resolve in range and azimuth their targets, i.e., the ocean patches contributing to the backscattered radio signal, in order to assign them a velocity value. While range gating is commonly used across different platforms to resolve for range, the determination of the direction of arrival (DOA) presents greater challenges. Commonly, HFR systems are classified based on the technique they use for DOA inversion: beam forming (BF) and direction finding (DF) systems.
BF systems, such as for instance the University of Hamburg Wellen Radar (WERA) (Gurgel et al., 1999) and the University of Hawaii LERA (Flament et al., 2016), require a receiving antenna array. They electronically steer the receiving array to the direction of each selected patch of the ocean surface and resolve the Doppler spectrum on a predefined grid (within the angular range and resolution allowed by the array configuration). Radial current velocities are therefore directly associated with each grid cell. Direction-finding (DF) systems acquire the backscattered spectrum as superposition of the echoes generated by all the ocean patches falling within a range ring and resolve the DOA on a polar grid by analyzing the covariance matrix of the complex voltages received by the directional antennas (Emery, 2018). In the latest developments, such as for instance in the SeaSonde systems (Barrick and Lipa, 1997), a tailored version of the Multiple Signal Classification (MUSIC) algorithm (Schmidt, 1986) is applied as DF algorithm.
Two HFR stations are required at least to resolve the twodimensional current field from radial velocity data. The two sites must be adequately spaced and overlook at the same ocean area from two different angles. Separation distance is controlled by the operational range of each HFR system, which in turn depends mainly on its operating frequency. Separation also controls the shape and the size of the HFR domain where currents can be resolved through the geometry of the intersection angles of the radial vectors (geometrical dilution of precision, GDOP; Figure 1).
Other factors controlling range include water salinity, sea state, interference, and integration time. Range resolution typically varies between a few hundred meters to 12 km, while the azimuthal resolution is both platform and algorithm-dependent, with typical values between 5 • and 18 • .
Worldwide, approximately 400 HFR systems have been installed, for the most diverse range of applications (Roarty et al., 2016(Roarty et al., , 2019. In Europe, the number of systems is growing with 64 HFR systems implemented and several others in the planning stage. From the last available survey performed (Mader et al., 2016;Roarty et al., 2019), the most commonly deployed commercial HFRs are SeaSonde systems for DF and WERA systems for BF groups (see Table 1). Therefore, recommendations and examples provided here mostly refer to these specific commercial brands.
Nowadays, HF radar systems are integrated in many European coastal observatories with proven potential for monitoring coastal currents and providing inputs for operational data assimilation and assessment of numerical ocean forecasting models, especially near the coast (Barth et al., 2008(Barth et al., , 2011Marmain et al., 2014;Stanev et al., 2015;Iermano et al., 2016). The growing number of HFR systems, their optimization from installation to maintenance and operation, and the need for standardized data processing and analysis approaches, have driven the HFR community to work at European and international levels toward a coordinated development of coastal HFR technology and its products (Rubio et al., , 2018Roarty et al., 2019).
In response to the need for optimizing operation performance, different documents providing best practices for operation and maintenance have emerged in the past years. A list of guidelines and best practice documents have been used as a basis for the elaboration of this paper (Cook et al., 2008;SeaSonde R Remote Unit Operator's Manual, 2010;Philip, 2012;International Oceanographic Data and Information Exchange, 2016;Corgnati et al., 2018a;Wera Best Practices, 2018;Horstmann et al., 2019). They refer either to DF or BF systems, or to specific manufacturer's radar systems. In this paper, the authors build on the existing documents and rely on direct experience with the aim of offering a comprehensive review of the existing best practices, and complement them with novel recommendations. This paper thus covers planning, setup, operations and data management aspects in order to ensure a broader approach to optimal operation of HFR systems independently from manufacturer or antenna design and setup.
Usually, a network of HFR systems is established in response to specific scientific questions or operational needs. One of the most important criteria in the planning phase of a HFR network is the selection of the desired spatial and temporal resolution, along with maximum range and spatial coverage, that optimize ocean surface current sampling. These parameters will determine the operating frequency, type of system to be used, number of systems and their relative location. Other practical aspects need to be considered, such as available space, infrastructure (power supply, communication, access roads), noise and interference sources (power lines, industry, nearby antennas, metal fences). All these aspects are discussed in the section "New Deployment Requirements and Planning".
A number of factors affect HFR performances during setup and operation with impact on data accuracy or with an interruption of data flow. Environmental factors, such as low sea state or extreme wave conditions, can introduce spatial and temporal data gaps due either to the lowenergy environment or the saturation of the spectrum region delimiting the first order Bragg peaks (1st order region); radio interference may contaminate the 1st order region and bias the radial current maps; failures in the network connectivity can disrupt data flow.
While all the HFRs share the same principles of operation, differences in signal-processing suggest different quality assessment procedures and quality control metrics, along with different metadata or descriptors. Keeping in mind such characteristics, a homogeneous approach, capable of identifying and discussing comparable features, is proposed in the section "Setup and Maintenance, " dedicated to recommendations for site setup and maintenance to enable continuous operation.
Lastly, recommendations for data management and the software tools currently available for data pre-processing/postprocessing, are provided in the "Data Management and Quality Control" section. In addition to data management at local level, a specific example is provided to demonstrate the near realtime Quality Control (QC) application to surface current data, following Corgnati et al. (2017Corgnati et al. ( , 2018a, and their operational ingestion in the European HF radar node (Corgnati et al., 2018b) and dissemination to main European and Global marine data portals.

NEW DEPLOYMENT REQUIREMENTS AND PLANNING
It is important, from both budget and planning perspectives, to consider the efforts required to source site permissions, site access, transmit licenses, and last but not least, intended use of the data.
Complex regulations at the local, national and international level can delay the deployment of the HFR stations. In the worst case scenario, non-compliance with one of the several required permissions may lead to a failure in proceeding with the installation stage. A further important aspect in the planning phase is the determination of the location of each individual site as well as the site-to-site distance. The optimal location and site-to-site distance depend on the utilized system, frequency, salinity and shape of the coastline. This task becomes particularly difficult when the coastline does not offer easy access or any suitable infrastructures (e.g., buildings, roads, electrical power line). In case parameters such as sea state are required, the distance between sites has to be reduced accordingly (Wyatt et al., 2006(Wyatt et al., , 2007.

Site Requirements
The optimal candidate site should match the following characteristics: • located as close as possible to the shoreline but safe from waves and flooding; • protected from unauthorized human access and from damage caused by animals; • located in a flat or slightly sloping area allowing human access without hazards; • accessible by vehicles; • have enough space to accommodate antennas, electronics, and cables; • free of electrically conductive objects (e.g., metallic fences, poles, and containers) in the antenna near-field; • free of radio interference at the operating frequency band; • free of obstacles limiting the field of view toward the ocean; • have nearby access to the electrical grid; • have stable and broadband internet connectivity, either wired or wireless.
Except for compact-type systems that allow co-located receive (Rx) and transmit (Tx) elements, Rx, and Tx antennas should be separated by a minimum distance depending on the operating frequency and the signal processing technique. For instance, optimal separation distance d between Rx and Tx elements for low-frequency SeaSonde systems is one wavelength (λ HF ) at the system's center frequency: λ HF = c/f HF , with c the speed of light in vacuum (m/s), f HF the center frequency (Hz). For instance, d = 67, 57, 32 m at 4.463, 5.2625, and 9.33 MHz, respectively. Typical setups of BF and DF are depicted in Figure 2.
In all cases, antennas should be installed as close to water as possible (see manufacturer's recommendations in Table 2), to avoid unnecessary signal loss for propagation over land.
For DF systems, electrically conductive objects such as metal structures or power lines within the antenna near field should be avoided, as they would couple in an unpredictable way with the receive elements thus compromising data quality. If these conditions cannot be satisfied, the site should not be considered as suitable for the installation.
Cliffs and steeply sloped ground can also affect HFR measurements, by acting as a reflector of the transmitted radio signal or introducing unwanted vertical propagation modes. Preferences should be given to gently sloping or flat terrain. "Many operating HF radar sites do not meet every one of these criteria and still produce acceptable measurements. When an ideal site is not available, consideration should be given to mitigate existing obstructions" (Cook et al., 2008).
FIGURE 2 | Upper panel shows a typical setup of a beam forming system. The photos show the antennas placement of a WERA system on the island of Wangerooge at the German coast of the North Sea. The receive antenna array (Rx) is shown on the left-hand side and the transmit array (Tx) on the right hand side, respectively. The bottom panel shows a typical direction finding HF radar system setup for the low frequency (4, 5, and 9 MHz) bands (left hand side). To the right, the SeaSonde installed at Matxitxako Cape (northern coast of Spain).

Power
Grid power is required at the installation site to feed the control electronics, communication devices, enclosure, and services such as air-conditioning. If grid power is not available, suitable offgrid sources should be used, such as solar panels, wind turbines, diesel generators, or their combination (Statscewich et al., 2011). "Assuming continuous operation, the cost of creating off-grid electricity to power a HF radar site is in the tens of thousands of Euros" (Cook et al., 2008). In continuous operation, the power consumption of most commercial HF radar systems excluding air conditioning is between 300 and 500 W, based on technical specs and direct measurements statistics of SeaSonde and WERA systems. In addition, an air conditioning unit draining between 500 and 2,000 W of power, depending on the climate of the HF radar site, the location of the electronics and the type of enclosure, is required in most cases.
Power outages are a very common downtime cause for HFRs. As such, it is strongly suggested to ensure that the power line setup comply with the state of the art and that properly designed and dimensioned backup power sources are available.

Communication
Remote network connection is considered a prerequisite for any HFR installation. Besides being essential for near real time operational usage, remote communication with the HFR site via a broadband internet connection allows for redundant data backup and for a series of monitoring and management operations that reduce significantly the need of on-site maintenance.
Best results are achieved with a dedicated ADSL connection. If this option is not available, a mobile network data connection should be considered as a second option. With the fast development of broadband cellular networks, data transfer and remote management of HFR stations are now easy tasks at almost no cost. Two or more SIM data cards from different mobile phone companies can be used simultaneously with specific 4G modem-router devices, ensuring backup link and improved data rate. Industrial grade modem-router are strongly suggested as they provide wider operational range with temperature, better protection against humidity and dust, and some extremely useful software features, for instance the continuous check of the connection status, a watchdog timer for automatic reboot in case of prolonged network disconnection, remote reboot via SMS, and MAC address filtering, amongst other options.
Wireless outdoor bridges can be used to link the remote site to a hardwired network connection if this is located over a distance of kilometers, in case of poor or unavailable mobile network connection at the site. Wireless outdoor bridges are implemented in several ways following the IEEE 802.11 recommendations and in most cases they rely on a point-topoint communication that requires free line-of-sight between two directional outdoor antennas.
Satellite internet should be considered as a potential alternative option for remote areas, although its performance is sensitive to weather conditions. Satellite internet companies should be contacted in advance to see if an intended HF radar site falls within their coverage area. Common satellite internet plans offer enough bandwidth and data volume at reasonable costs, allowing remote management and transfer of the most important data.
At minimum, an internet connection for the HF radar site needs to be able to transfer approximately 300 KB hourly (radial velocities files). In case of extremely slow connection, some HF radar systems offer the option of remote management using command line through SSH and/or control panels over HTTP, both requiring less bandwidth than screen sharing programs or graphical remote desktop access (e.g., VNC, Teamviewer).
Power surge protectors on Ethernet data lines is strongly suggested to protect from lightning strikes and power surges.
A protection should be placed also on the coaxial cable of a 3G/4G modem-router if an outdoor antenna is used.

Permissions
A significant amount of time should be allocated to obtain the required permits for operating the HF radar site. As a minimum, this implies authorizations from the local Authorities (e.g., City Councils) and the transmit permits from National Agency for the selected frequency with a sufficient bandwidth. The International Telecommunication Union (ITU) Resolution 612 (2012) allocated dedicated frequency bands to oceanographic radars for radiodetermination purposes, with secondary-type licenses on a basis of non-interferences. Each operator is requested to liaise with the national authorities in order to be granted with the operating frequency, the bandwidth, and a unique call sign that identifies each site. Resolution 612 also defines the separation distances between primary and secondary services so to avoid harmful interferences, and requires international agreements to be in place between neighboring Countries if the distance of the HFR site from the border is shorter than a frequency-dependent limit. In this case, in order to prevent big delays on getting an installation approval, coordination with the neighboring Countries should be undertaken well in advance. As an example, an agreement between Italy, France and Spain is in effect that allows to use the full bandwidth (100 kHz) in the North West Mediterranean area for all the SeaSondes or WERAs, under the requisite that the former operate within the 13 MHz band and the latter operate within the 16 MHz band. Mutual cross interference within the same frequency band is avoided thanks to synchronization techniques.
In addition to the general radio transmission license, some Countries enforce a strict limit on the maximum radiated power. In Europe this threshold is set to 10 W (EIRP, effective isotropically radiated power), and an additional permission is required above this value. For experimental purposes (e.g., testing new deployment sites) HFRs can be operated below this level; potential losses in HFR performances can be partially compensated by optimizing the processing parameters.
Based on the general principles of prevention many Countries define minimum health and safety requirements regarding the exposure of people to electromagnetic fields (European Union, 2013). Although the radiated power of an HF radar is very low and the effect on a person is not well known, it is demonstrated by field measurements that within the distance of few meters from the HFR antennas the electric and magnetic fields intensities may exceed such thresholds. For this reason, the presence of humans in the vicinity of the transmitting antennas should be avoided at least before assessing the level of electromagnetic emissions.
In some countries specific constraints may exist in order to preserve the architectural and natural heritage landscapes, as well as to protect sensitive coastal environments. Even limitations due to archeological and ethnographic concerns and constraints have been faced by the authors and should be foreseen in the general deployment plan. Obtaining permissions often involves different governmental offices and requires professional advice in order to get the final approval.
Other possible limitations imposed by authorities are due to the presence of other facilities using nearby radio frequency bands that could be disturbed by the HF radar.

HF Radar Enclosure and Air Conditioning
The electronics enclosure can be of different nature depending on the available space at the site, cooling, heating and dehumidifying requirements, the number of devices to be hosted, the need of protection against the sun, water, dust.
If a building is available, the enclosure can be located inside a room and a standard rack cabinet can be used. If required, an air conditioning system can be installed in the room.
If a building is not available, the following options can be chosen: • weatherproof, climate-controlled shelter or trailer. This solution allows the operator to work in a small but still comfortable environment, and provides a robust protection against natural hazards (weather, animals) and vandalisms. A trailer has also the advantage that it can be relocated with less effort. • sealed, insulated, air-conditioned, enclosure with minimum fitting size for the electronics. Such compact solutions are less protected and may require specific and tailored air conditioning methods but are very flexible, e.g., can be deployed with very little space needed and relocated.

Data Acquisition
In most commercial HFRs the control of the electronics and data acquisition are performed by x86-based computers ranging from consumer PCs to entry level servers and running Mac OS X or Linux operating systems. They are typically provided in bundle with the HF radar system and already pre-configured with all the needed control and processing software. They only need to be configured for a few parameters such as network settings, site-specific information, processing options. As the lifetime of the computer is typically much shorter than the electronics of the HF radar system, care should be taken with respect to compatibility between the manufacturer's software and newer operating systems. A redundant external data storage system is recommended on-site as a backup for the data acquired and saved on the computer's disk.

Power Line Accessories and Uninterruptible Power Supply
Once a suitable electrical power source is established, a remote HFR station may require additional solutions in order to minimize the need of maintenance on site due to power-related issues. They may include: • a dedicated electrical panel and line, bypassing any preexisting potentially problematic panels or electrical lines. • a dedicated electrical grounding if not already existing or if not reliable (a test is highly recommended), and a separate grounding line for the lightning protection system.
• a circuit breaker with automatic reclosing capability, able to restore the power supply if the cause that triggers the breaker is only temporary. • a smart power strip that can be switched on/off on schedule or by remote control e.g., if a hardware power reset is needed.
An uninterruptible power supply (UPS) should be used to provide near-instantaneous protection and power backup to the HFR system components. UPS acts as surge suppressor and ensures within certain limits stable sine wave (pure or simulated depending on the model) power through over-voltages and brownouts. UPS minimum requirements should include: • an adequate output rating, that in most cases can be equal to 1 KW; • an Ethernet card and a website interface for remote configuration and monitoring; enough battery capacity to ensure 15-20 min of autonomy considering the maximum load, in order to properly shut down the sensitive equipment; • the possibility to expand the battery pack if upgrade is needed; • two or more outlet groups that can be managed separately.
UPS systems should be considered emergency power backup solutions meant to protect the most sensitive electronics components only.

Lightning Electromagnetic Pulse Protection
Lightning is a frequent cause of damage in some geographical regions. The need for lightning electromagnetic pulse protection (LEMP) is also mentioned in Cook et al. (2008): "LEMP should be installed inline on any antenna (i.e., receiver and transmitter channels, GPS, communications) as a safety precaution for personnel and radar electronics. Lightning arrestors provide an alternate path to ground during a high voltage surge from lightning strike. There are a variety of designs, but typically the inline gas discharge types are used for RF communications, including HF radar." At least two levels of lightning protection are recommended for any system: • At the antenna pole, as a protection of the transmission line; • At the container/room cable inlet, as a protection to the electronic components.
Furthermore, Cook et al. (2008) indicates that different devices may require different specifications for lightning arrestors, for instance "the transmitter requires a lightning arrestor with a higher sparkover voltage than the receiver. Typically, common lightning arrestors (such as the Altelicon AL-NFNFB) come with gas tubes rated for 90 V sparkover voltage. In this case, replacement gas tubes with 350 V sparkover voltage can be purchased." To mitigate this risk, special attention should be paid also to the design of the cables path. Wrong cables placement could invalidate indeed the LEMP when distances of protected and unprotected lines are too short, as the overvoltage is transmitted by electromagnetic induction bypassing the lightning arrestor, both on coaxial cables and power line.

Deployment Budget
While the total cost of the initial deployment is mostly affected by the cost of the HFR hardware, a series of non-negligible additional costs should be allocated in the operational budget.
The total cost of a HFR system and its planning and setup is determined by the following items: • cost of the initial equipment purchase (only HFR components, e.g., Rx, Tx, computer, antenna, cables); • cost of additional equipment (e.g., UPS, data storage); • cost of submitting requests for authorization (design of the installation and related work); • cost of electromagnetic impact evaluation if required by authorities; • tax for the license for radio band usage; • cost for rental of land or building hosting the HRF system; • purchasing of the enclosure or the shed or both; • contract with electricity supplier; • contract for internet connection; • cost of working hours of professionals and for site preparation work (electrician, bricklayer); • training courses by the HFR system manufacturer; • cost of the third-party insurance; • cost of insurance for HFR station (e.g., damages from natural events or other causes); • cost of personnel and travels for site survey, installation planning and execution (either if done by the purchasing subject or by the manufacturer or a third company); • cost of IT infrastructure for data processing and archiving.
After the initial deployment, some of the items listed above can be easily identified as regular operating costs.

SETUP AND MAINTENANCE
Following (Pearlman et al., 2019), Quality Assurance (QA) is a series of processes and protocols aimed at ensuring that the best product is delivered. Significant examples of QA guidelines applied to the production of HFR data are provided in the present and in the next section, including not only best practices ensuring the optimal condition for data acquisition (e.g., setup and maintenance of the hardware) but also methods for measuring, examining and testing if the quality standards are satisfied, commonly referred to as Quality Control (QC).

Setup
The setup of the HFR site involves both hardware and software elements. The site selection and description of HFR components are covered in the previous section, together with an overview of the required permissions. Once the design of the HFR station is drafted and all the elements are in place, the setup of the system has to be tailored to the environment and to the intended application.

Long, Medium, and Short-Range Configuration
The HF radar settings and performances (range and radial resolution) depend upon the allocated frequency and bandwidth, as specified by ITU 612 Resolution (Rev.WRC-12) of the Radio Regulations. The number of allowed frequency bands can be grouped in three blocks with effect on HF radar range: long, medium and short range. Typical range values for surface current measurements according to the manufactures of SeaSonde and WERA systems are listed in Table 3. Table 4 summarizes the theoretical maximum range for surface current measurements with respect to salinity. Values are estimates in% of the optimum range utilizing a propagation model (Gurgel et al., 1999).

Antenna Mount and Cables
HF radar systems may have different antenna sizes, numbers, designs and setups depending on the operating frequency, implementation concept and signal processing technique (DF or BF). Antennas can be implemented with fiberglass whips, metal poles, wires or combination of these elements held by rigid structures (Figure 2). In general, the following antenna systems are available: • compact antennas for SeaSonde DF systems; • small antennas used in array configurations in particular for BF systems; • the very small active antenna for receive arrays from BF systems.
Already stated in Cook et al. (2008): structural "stability is maximized when the Rx and Tx antennas are mounted in level concrete pads constructed at the HF radar site (without metal rebar to distort the antenna pattern in case of DF systems). Anchors for the Rx and Tx antenna non-conductive guy wires can be incorporated into the concrete pad as well. Cableways should be trenched from the pads to the electronics enclosure to eliminate exposed above ground wiring or placed in protective tubes. The construction permits, soil disturbance, and additional labor this mounting entails may limit its applicability to many HF radar sites." HF radar systems deployment should be carefully planned with respect to the length and paths of the coaxial cables to the antennas. In case that extensions are needed, additional cables could be purchased on the free market, however, they should match the electrical characteristics of the original cables and should be selected with great care. In case of long paths (e.g., >100 m) from antennas to Tx and Rx units, a better cable should be adopted in terms of signal attenuation at the given frequency. A continuity test should be always performed after connector installation to ensure proper insulation between shield and central pin.
The cable and connector role is often underestimated, while they represent a crucial component of the system and may compromise the quality of the signal. Since they have a low impact on the total cost of HF radar systems, they should match with high quality standards. Moisture penetration inside the cables is the main reason for efficiency loss in time, and should be prevented under all circumstances by using specialized cables (some plastic sheaths are more effective than others). Furthermore, great care should be taken by protecting the connectors from direct exposure, using specific greases and self-fusing insulation tape when connecting them. In general, all cables should be handled with care, not being stressed, twisted or narrow bent. Cables already used in the field should be avoided for new installations. If they are the only option, they must be carefully checked with visual inspection and specific instruments as multimeters and cable fault finders for first insight, and with more advanced instruments for complete testing of electrical characteristics.

Antenna Tuning
Within the theoretical limits given by the chosen operating frequency, the HF radar performances can be significantly reduced in case of a bad tuning of the transmit antenna, i.e., when significant fraction of the power is reflected back to the amplifier due to a mismatch of the impedance (usually 50 ohms) between the antenna and the amplifier at the given frequency. For this reason, it is always recommended to check each antenna after installation in the field. The amount of forward and reflected power is expressed through the Voltage Standing Wave Ratio (VSWR, or alternatively SWR) and can be measured with a battery driven antenna analyzer without amplifier, or via the HF radar's software through the internal circuit board when this feature is available. A VSWR value below 2 is recommended, while a greater value means that reflected power is coming back to the electronic devices which, besides resulting in lower efficiency, can lead to damage of the electronic equipment. Refer to the manufacturer's manual respect to the tuning requirements and possibilities of the transmit antenna. If no tuning possibilities are available, an antenna tuner can be used to minimize the reflected power.
Note that the SeaSonde transmit antenna is tuned by the manufacturer prior to delivery and no tuning by operators is foreseen. However, if required, an approximate and limited tuning can be performed by changing the length of the antenna whips by trimming, and by adding or removing the capacity tophat in the low-frequency band, or optimally matching the length of the transmission line.
WERA systems are pre-tuned by the manufacturer but can be further fine-tuned in the field. After the tuning of each antenna element of the transmit and receive array, an internal calibration of the entire systems is needed, which takes into account the antenna tuning and cable length for each element.
For adjusting the level of the power amplifier, the output power of the transmit antenna should fulfill the following requirements: • to be below the transmit power allowed by the agreement of the local frequency agency. • Not to saturate the receiver (voltage rms values < 7 V along the receive array) For FMiCW systems, the blank delay should be used to adjust the saturation in the receiver.
"Regardless of tuning method, it is important to monitor the transmitted and reflected power to diagnose transmitter health and functionality" (Cook et al., 2008).

Receiving Antenna Calibration
The analysis of the radar signals to resolve the azimuth needs a good knowledge of the receiving antenna specificities. Any HFR system is subject to the influence of the nearby environment, and should be always calibrated once in place (Kohut and Glenn, 2003;Yang et al., 2018), as an important part of the system setup and maintenance, in order to verify the theoretical antenna response and to introduce correction factors if needed. Calibration can be performed with different techniques, among which two are the most common: internal calibration method, commonly applied to BF systems, and farfield calibration method, also known within the HFR community as antenna pattern measurement (APM), usually applied to DF configurations. "While the assumption of an ideal antenna pattern allows to generate maps of radial currents, it does not account for distortions in the real antenna pattern, " which often causes inaccuracies in the measurements (Cook et al., 2008). This is particularly important for compact DF antenna like SeaSonde, where the electromagnetic environment can affect phase and gain more significantly than in case of large antenna array.
For BF configurations, the analytical antenna array response function or antenna manifold is used. It is computed by solving the electromagnetic equations for the waves propagating to the array using the precise positions (less than 0.2 m accuracy) of each antenna element. Phase and gain calibration is required and is performed internally. Furthermore, dedicated software for the BF systems can compensate variations of the antenna characteristic caused by environmental or technical conditions (Helzel and Kniephoff, 2010). For WERA systems, all antenna parameters are automatically monitored, at least once per hour and a warning is automatically generated if any parameter reaches a critical value, which might cause the automatic calibration procedure to fail. In such a case a preventive maintenance should be carried out. In some extreme conditions an APM can be helpful to improve the quality of the BF, in particular when being utilized for wave measurement applications.
For DF systems APM is mandatory and can be performed, following a well established procedure, using a boat equipped with a transponder provided by HFR system manufacturer. The boat moves over a circle around the HF radar antennas while the HFR system acquires the transponder signal and the boat's position is tracked with a GPS device.
Alternative methods recently developed, such as the Automated APM via Automatic Identification Systems (AIS) or APM obtained by drones, can be used. The former uses Doppler echoes from vessels cruising in the area, which in many cases lead to a return signal similar to that of a transponder (Emery et al., 2014), and combining it with the position of the vessels obtained, when available, from the information contained in the automatic identification system (AIS). The latter employs small aerial drones (Washburn et al., 2017) or RC-boats carrying a light radio emitter. Flying drones speed up the APM procedure but in other hands are subject to strict regulations in order to be operated.

Network Setup
Correct network setup is crucial for data retrieval and remote management, which in turn make the HF radar operations more sustainable as the operators do not need to travel often to the sites for data backup and system monitoring. With any kind of network connection at the HF radar site (Ethernet, mobile, satellite etc.) the recommended network configuration should rely on the usage of a router under which a Local Area Network (LAN) can be established.
Proper setup of a LAN is out of the scope of this paper, information on internet services running at the HF radar sites or suggestions on Remote Desktop Management Software can be found in the HFRs operation manuals.

First Order Limits Detection
When setting up a new HF radar system, operators are requested to insert specific configuration parameters such as the identification of the system, the geographical information, the operating frequency and bandwidth, the processing options. One important step in HF radars signal processing chain is the detection, inside the power spectra maps, of the regions containing the first order bragg peaks, i.e., the portion of the spectra containing information on surface currents. Such detection, better known as first order limits (FOLs) determination, is usually performed by the HF radar acquisition and processing software with automatic algorithms that look for the Doppler peaks at one channel (usually the omnidirectional vertical loop for SeaSonde systems) and must be tuned by the operator during the initial period of acquisition through the selection of some parameters and visual inspection of the results.
Improper FOLs identification may introduce large errors or missing values of sea current velocity. Depending on sea state, interferences, presence of other targets (e.g., ships) in the field of view of the radar, the first order region may be partially masked and difficult to detect. This is particularly true in those areas where a high variability in currents and waves regimes leads to an overlap of first and second order Bragg peaks with high variability in time and along the HF radar range. In these circumstances, operators should carefully monitor the performance of their initial setup and optimize it for different sea conditions. When this is not possible, different subset of data should be reprocessed each one with a specific set of processing parameters.
These considerations apply especially for DF systems, where the power spectra contain the contributions from all the azimuthal directions. In some cases the application of advanced methods for FOLs detection can improve the quality of the data (Kirincich, 2017).

Maintenance
As all in situ instrumentation, also HF radar suffers from the normal deterioration, in particular -but not only -of the outdoor components. Besides that, major damages have been experienced due to severe weather events inducing storm surge or lightning, which often lead to electrical damages or antennae breakage. Another not to be underestimated source of damage results from animals (in particular to cables) or human vandalism.
On the other hand, issues may arise from specific hardware or software failures without any external cause, such as data corruption due to storage failure, or software modules and applications unexpectedly freezing. For all these reasons, even if HF radar systems can be considered fully automated acquisition platforms, regular monitoring is necessary to ensure continuous and correct operation.
The first, and more frequent, kind of maintenance can be performed remotely. With an internet connection enabled, the system status as well as its data acquisition process and data themselves can be easily diagnosed and verified by means of web tools, email alerts, screen sharing applications, even on a daily basis.
As a complement, on-site inspection is unavoidable and is recommended on a regular biannual basis, in order to confirm the good status of the equipment and prevent issues, but also to perform scheduled actions such as data backup on external disk, UPS battery replacement. Additional specific on-site inspections are recommended after a severe weather event (e.g., very high winds, hail, ice storms, floods, lightning).
According to Cook et al. (2008), the following actions should be performed regularly as typical on-site maintenance: • for DF systems and directional antennas, ensure that RX antenna compass bearing is reported correctly and no changes occurred; • check if antenna mounting and masts are properly secured and placed, and guy wires are intact and in tension; • inspect electronics, connectors and other metal components for signs of corrosion or humidity; • check if conduit or even cables are damaged; • ensure that air conditioning system is operating properly, filters are clean, all the cooling fans are rotating correctly (no friction or vibrations), components inside the enclosure are not overheated; • perform tests on UPS for battery status and for correct shutdown and reboot sequence; • verify the correspondence between on-site system status and remote diagnostics; • execute an incremental data backup on a portable device.
Other specific items to be checked will be dictated by the diagnostic tools output.
Results of remote and on-site checkings should be included in periodic reports, to help the operator to keep track of maintenance history.

Diagnostic Reporting
Once the HF radar station is deployed, its proper functioning can be assessed by the diagnostic reporting on its performance. HF radar systems, as discussed in the previous sections in this paper, can be implemented with different hardware and software design, and different signal processing techniques. For this reason, they can provide different performance indicators. However, all HF radar systems allow recording common operating parameters like temperature and voltage of subcomponents (e.g., chassis, amplifier), forward and reflected power, and indicators related to Signal to Noise ratio, and provide alert messages when measured values exceed given thresholds. This aspect must be considered carefully, thresholds must be set and software properly configured according to manufacturer's manuals, and every change in those indicators, especially if permanent, should be investigated.
As an example, any significant permanent variation of the reflected power is most likely related to a hardware failure (e.g., antennae, cables, or amplifiers). Signal to Noise Ratio is usually not stable because of environmental conditions and periodically fluctuates with repeated daily pattern, but any significant permanent change in this pattern or in its variation range should be investigated.
HF radar management software often provides diagnostic tools and warning messages.
The SeaSonde Radial Suite generates hardware and software diagnostics that are saved in so called DIAG files. An extension with * .hdt refers to hardware diagnostics and an extension with * .rdt refers to radial diagnostics. Much of this information is reported within the radial file itself, but diagnostic files help to aggregate and show them, through DiagDisplay application, in a bigger picture. Plots of diagnostic parameters over custom time windows can be also exposed in a web page served by the RadialWebServer. Another application, the RadialSiteReporter, is able to perform a scheduled detailed check of all the software and hardware components and to produce and send to the operator detailed email alerts with highly customizable rules. These alerts are also shown by the RadialWebServer, plus are added to an alert log.
The WERA software provides hardware and software diagnostics on all levels of data acquisition or data processing. Automatic status and warning messages ( * .status) will automatically be sent out to defined recipient groups at different intervals depending on defined priority levels. High priority messages will be sent out immediately, lower priority messages only once per day or per week. An anti-spam filter makes sure that no messages within some hours are send out more than once. In case of a detected problem, the message will contain possible solutions for the problem. Plots of time series files for different kinds of parameters, like internal voltages, temperatures, forward and reverse transmit power, hard disk usage, antenna performance, can be accessed by the operator for further analysis and troubleshooting. The described status monitoring system can simply be extended by creating additional * .status files in the defined data format.
In Tables 5, 6 the recommended ranges of diagnostic parameters indicating good health of the system are listed for Codar and WERA HFRs respectively. Alerts should be thrown when these ranges are exceeded because of risk of hardware or operation failures.  (Emery and Washburn, 2007

DATA MANAGEMENT AND QUALITY CONTROL
The main objective of this section is to provide general concepts and definitions in order to formalize the data processing and management steps regardless of the HF Radar system adopted, with focus on Near Real Time data flow suitable for operational services. HF radar data is in situ gridded data sampled at high-frequency that has to be managed according to its peculiarity and complexity, which derives from the fact that it includes diverse data types (radials and totals) and with different kinds of native formats from different HF radar systems.
Different steps in the data life cycle (as schematized in Figure 3) have been defined following the processing levels specified in Table 7.

Data Acquisition and Pre-processing
The first step consists of raw electromagnetic data acquisition and extraction of radial components of the ocean currents performed by each HFR system.
The output, the so-called radial files, must be transferred to a processing station responsible for combination of overlapping radial vectors measured by two or more HF radar systems. The processing station is a generic name for the IT infrastructure that will perform the combination, either at the data-provider level or as third-party competence center (e.g., manufacturer servers, National nodes and data centers, EU HF radar Node). According to the definition of data levels, this flow is summarized in the following scheme: Input product Level 0 (Signal received by the antenna before the processing stage) Output product Level 2A (HF radar radial velocity data without QC defined) Data source HF radar remote stations Data target Central or Processing Station for combination into totals HF radar manufacturers provide software suites for data acquisition and radial velocities production. The two most common commercial software packages for HF Radar acquisition and pre-processing are: • the suite of WERA/Helzel (available for Linux Os only, suggested distribution open SUSE), based, for the signal processing algorithms, on Klaus Werner Gurgel works (Gurgel et al., 1999), and supporting the two HF radar implementations and spectral information processing methods: Beam Forming processed on a regular cartesian grid (or optionally with polar coordinates), and Direction Finding by Least Mean Square developed for compact antenna system. • the Seasonde radial suite (available for Mac Os X only) from Codar Ocean Sensors, based, for the signal processing algorithms, on the works of Lipa and Barrick (1983) and Barrick and Lipa (1997).
Third party software for data acquisition and preprocessing is available under commercial license for beam forming HF radar systems, see Table 8 for more details.
Operators are invited to investigate the license conditions, especially the policy for software updates, which may differ significantly, in order to allocate the correct budget for maintaining the systems.

Data Processing
The combination of radial velocities from two or more remote stations for obtaining total surface current velocity files is covered in this paragraph. According to the definition of data levels, this flow is summarized in the following scheme:

Input product
Level 2A (HF radar radial velocity data without QC defined) Output product Level 3A (HF radar total velocity data without QC defined) Data source Central or Processing Station Data target Post-processing Station The most commonly adopted combination algorithm of radial vectors into total vectors is the unweighted least squares fitting (UWLS) algorithm. The UWLS approach (Lipa and Barrick, 1983;Graber et al., 1997) assumes that, for each grid point, the radial velocities within the search radius are produced by a uniform velocity vector, i.e., the correlation of the current vector is assumed to be one everywhere within the search radius and zero outside.
HF radar manufacturers provide combining suite software under commercial license (Table 9) often as separate product with respect to the acquisition and pre-processing software described in the previous section. Besides those solutions, the international community developed and freely distributes the Matlab R tool "HFR_progs" 1 (Kaplan et al., 2005).

Data Post-processing
Once both radial and total files are produced, it may be convenient or required to post-process them in order to achieve a common level of Quality Control (QC), or a specific file format, or a required variable/attribute naming convention.
Best practices suggest that the NetCDF should be adopted as file format either for radial and total vectors files. This standard is indeed adopted by the US IOOS network, EU community and the Integrated Marine Observing System (IMOS) Ocean Radar Facility Ocean radar Network (ACORN), at least for total vectors. Mandatory, suggested or ancillary variables and attributes and their naming conventions are a matter of discussion. Different conventions/directives are adopted by different communities, however a coordination work is carried on under the umbrella of the Global HF Radar network (Roarty et al., 2019).
As a data post-processing example, the authors want to report here the case of the application of QC tests and their description, according to the definition of data levels and to the European common data and metadata model for surface currents 1 https://github.com/rowg/hfrprogs (Corgnati et al., , 2018a. The flow is summarized in the following scheme:

Input product
Level 2A (HF radar radial velocity data without QC defined) and Level 3A (HF radar total velocity data without QC defined) Output product Level 2B (HF radar radial velocity data with a minimum set of QC) and Level 3B (HF radar total velocity data with a minimum set of QC) Data source Post-processing Station Data target Distribution centers As described by Chapman et al. (1997); Barrick (2002), Kohut and Glenn (2003); Cosoli and Bolzon (2010), Lipa (2013);Forget (2015) and Cosoli and Grcic (2019), even if we assume that the radar hardware is operating correctly, many different sources of uncertainty in the radial velocities can be identified. It is thus highly recommended to provide information about the validity and correctness of HFR measurements via Quality Control (QC) procedures.
The authors selected from the Quality Assurance/Quality Control of Real-Time Oceanographic Data (QARTOD) manual (U.S. Integrated Ocean Observing System, 2016) a battery of QC tests to be always applied to HFR radial and total data. These tests, listed as mandatory in the European common QC model for near real-time HF radar current data and textually reported here from Corgnati et al. (2018a), are:

RADIAL DATA TESTS
• Syntax check: this test will ensure the proper formatting and the existence of all the necessary fields within the radial NetCDF file. • Over-water test: this test labels radial vectors that lie on land with a "bad data" flag and radial vectors that lie on water with a "good data" flag. • Velocity Threshold: this test labels radial velocity vectors whose module is bigger than a maximum velocity threshold with a "bad data" flag and radial vectors whose module is smaller than the threshold with a "good data" flag. • Variance Threshold: this test labels radial vectors whose temporal variance is bigger than a maximum threshold with a "bad data" flag and radial vectors whose temporal variance is smaller than the threshold with a "good data" flag. The 2013 Codar Current Newsletter suggests not to use variance data for real-time QC, due to the fact that the CODAR parameter defining the variance is computed at each time step, and therefore considered not statistically solid. Therefore, this test is applicable only to Beam Forming (BF) systems. Data files from Direction Finding (DF) systems will apply instead the "Temporal Derivative" test reporting the explanation "Test not applicable to Direction Finding systems. The Temporal Derivative test is applied" in the comment attribute. • Temporal Derivative: for each radial bin, the current hour velocity vector is compared with the previous and next hour ones. If the differences are bigger than a threshold (specific for each radial bin and evaluated on the basis of the analysis of one-year-long time series), the present vector is flagged as bad_data, otherwise it is labeled with a good_data flag. Since this method implies a one-hour delay in the data provision, the current hour file should have the related QC flag set to 0 (no QC performed) until it is updated to the proper values when the next hour file is generated. • Median Filter (text reported from U.S. Integrated Ocean Observing System, 2016): for each source vector, the median of all velocities within a radius of <RCLim> and whose vector bearing (angle of arrival at site) is also within an angular distance of <AngLim> degrees from the source vector's bearing is evaluated. If the difference between the vector's velocity and the median velocity is greater than a threshold, then the vector is labeled with a "bad_data" flag, otherwise it is labeled with a "good_data" flag. • Average Radial Bearing: this test labels the entire datafile with a 'good_data" flag if the average radial bearing of all the vectors contained in the data file lies within a specified margin around the expected value of normal operation. Otherwise, the data file is labeled with a "bad_data" flag. This test is applicable only to DF systems. Of course, data files from BF systems will have this variable filled with "good_data" flags (1) and the explanation "Test not applicable to Beam Forming systems" in the comment attribute. • Radial count: test labeling radial data having a number of velocity vectors bigger than the threshold with a "good data" flag and radial data having a number of velocity vectors smaller than the threshold with a "bad data" flag.

TOTAL DATA TESTS
• Syntax check: this test will ensure the proper formatting and the existence of all the necessary fields within the total NetCDF file. • Data density threshold: this test labels total velocity vectors with a number of contributing radials bigger than the threshold with a "good data" flag and total velocity vectors with a number of contributing radials smaller than the threshold with a "bad data" flag. • Velocity threshold: this test labels total velocity vectors whose module is bigger than a maximum velocity threshold with a "bad data" flag and total vectors whose module is smaller than the threshold with a "good data" flag. • Variance threshold: this test labels total vectors whose temporal variance is bigger than a maximum threshold with a "bad data" flag and total vectors whose temporal variance is smaller than the threshold with a "good data" flag. As stated for radial data, this test is applicable only to Beam Forming (BF) systems. Data files from Direction Finding (DF) systems will apply instead the "Temporal Derivative" test reporting the explanation "Test not applicable to Direction Finding systems. The Temporal Derivative test is applied." in the comment attribute. • Temporal derivative: for each total bin, the current hour velocity vector is compared with the previous and next hour ones. If the differences are bigger than a threshold (specific for each grid cell and evaluated on the basis of the analysis of one-year-long time series), the present vector is flagged as "bad_ data, " otherwise it is labeled with a "good_ data" flag. Since this method implies a one-hour delay in the data provision, the current hour file should have the related QC flag set to 0 (no QC performed) until it is updated to the proper values when the next hour file is generated. • GDOP threshold: this test labels total velocity vectors whose GDOP is bigger than a maximum threshold with a "bad data" flag and the vectors whose GDOP is smaller than the threshold with a "good data" flag.
These mandatory QC tests are manufacturer-independent, i.e., they do not rely on particular variables or information provided only by a specific device.
Each QC test will result in a flag related to each data vector which will be inserted in the specific test variable. These variables can be matrices with the same dimensions of the data variable, containing, for each cell, the flag related to the vector lying in that cell, in case the QC test evaluates each cell of the gridded data, or a scalar, in case the QC test assesses an overall property of the data.
The ARGO QC flag scale is applied as flagging scheme (Corgnati et al., 2018a).
For some of these tests, HF radar operators will need to select the best thresholds. Since a successful QC effort is highly dependent upon selection of the proper thresholds, this choice is not straightforward, and may require trial and error before final selections are made. These thresholds should not be determined arbitrarily but based on historical knowledge or statistics derived from historical data.
The software tools for HF radar Real Time data postprocessing into the EU standard, described in Table 10

Data Archival and Preservation
On-site archiving on a separate storage system is recommended as the first step for data preservation. Both the Codar SeaSonde and WERA softwares include scripts and applications for scheduled data archiving.
For Codar systems, at the very least, it is advisable to save all Range Series (.rs) data files, from which radial diagnostic information, Cross Spectra (.cs) files, and all the derived oceanographic variables can be recalculated, allowing also for different reprocessing settings. From a practical point of view, in order to ensure quicker checks of processing settings, it is suggested to save also the Cross Spectra files (at least CSStype averaged files). Another bunch of deployment-specific files must be archived for SeaSonde systems, they are: in the RadialConfigs folder, Header.txt file and MeasPattern.txt files; gps Track data and Time Series files generated during APM, needed for recalculating Antenna Pattern in case of need; the folder/Codar/SeaSonde/Logs/or any equivalent log file containing the operator comments on all the changes performed on the radial site, including periods of validity of one or more Antenna Pattern files; alert and diagnostic files for later troubleshooting of the station behavior.
The WERA toolbox contains a script named "BackupDataFiles.sh, " which is used to automatically create a backup copy of raw data and other data products onto an external backup hard disk. If two hard disks are used for redundancy, the script should be duplicated for optimum performance.
For WERA systems using beam forming software it is not required to save Cross Spectra files. The * .URFI or * .RFI files containing information about radio frequency interference during the measurement and optionally the frequency pre-scan * .RAW files may be archived beside the raw data files * .USORT or * .SORT. The results ( * .CAL) of the automatic direct path test measurements will contain information about antenna health. In addition to the on-site archiving, the HF radar remote stations should backup the most important data in real time to a remote repository through a network connection, as much as the bandwidth allows. The full backup of the data can be executed periodically on-site with a portable storage device. The minimum estimated amount of data to be archived per year and per station is in the order of 100 GB for CODAR systems, and 1 TB for WERA systems.

Data Dissemination
Homogenization of file format, data description and Quality Control procedures are prerequisites for data sharing among data centers and data aggregators through the concepts of data interoperability and machine to machine interaction.
The authors strongly encourage HFR data providers to investigate the state of progress of regional and global HFR standards and infrastructures, and to take advantage of the service provided for enabling a data flow in standard interoperable format toward the community.
The European HF radar Node is an example of a recommended way for channeling HFR standardized data toward European and global data portals ( Table 11).
The Node is responsible for the NRT HFR current data collection from the HF radar operators in Europe, for the application of the standard QC model, for the conversion of the QCed data files into the European standard data and metadata model. It is operational since April 2019 for the Copernicus Marine Service (CMEMS-INSTAC), SeaDataNet (SDN/SDC), and EMODnet Physics data delivery. The connection with US network for reciprocal data exchange is under development.
In US, radial files are collected in near real-time at regional level and then pushed into national nodes for total vector maps production and distribution through a Thematic Real-time Environmental Distributed Data Services (THREDDS) server 2 .
The Australian Ocean Data Network provides open access to real time quality controlled and delayed-mode quality-controlled HF radar derived surface currents, winds and waves through their THREDDS catalog 3 as well as through the data portal 4 . One advantage of the data portal is that it allows for data to be aggregated over a user-defined time window, platform or region. Standard NetCDF format that adhere to the CF-1.6 and IMOS-1.4 conventions are available, either unaggregated or aggregated.
The Global HF Radar network web site 5 shows a map with all of the locations of the HF Radar sites all over the world automatically connected.
In 2017 "the Global HFR Network was recognized by the Joint Technical WMO-IOC Commission for Oceanography and Marine Meteorology (JCOMM) as an observing network of the Global Ocean Observing System (GOOS)" (Roarty et al., 2019). This is expected to help coordinate the effort at international level and hopefully to define a unique global standard within the next few years.
It is worth mentioning that the data management plan for HF radar data should follow other few very general best practices as: • follow the FAIR (Wilkinson et al., 2016) paradigm as part of making research data findable, accessible, interoperable and re-usable. • include, inside metadata and as part of the data management plan, information about data policy, and possibly share unrestricted data, to make them freely available, thus facilitating access to a wider public. Creative Commons license Attribution 4.0 International (CC BY 4.0) 6 is an example adopted by some HF radar data provider. • associate a Digital Object Identification (DOI) to each dataset, and thus helping to make the data discoverable, accessible and citable.
Other general best practices on How to develop a Data Management Plan (International Oceanographic Data and Information Exchange, 2016) are available at the Ocean Best Practices repository.

CONCLUSION
In response to the need for optimizing the operation performance of HF radars, different documents providing best practices for radar systems operation and maintenance have emerged in the past years. Most of them are either oriented to DF or BF systems, or to specific manufacturer's radar systems. In this document we compiled and completed existing documentation with the aim of offering a broad "Best Practices" manual for optimal operation of HF radar systems with independence from manufacturer or antenna design/setup. This "Best Practices" paper, fed with direct experience of the authors on HF radar systems planning, setup, operations and data management and on the recent literature, provides some advancement with respect to the existing documents in several aspects. In particular: • a more general approach to the technology is provided, including other examples of products and suggesting best practices referring when possible only to the antenna design and setup, and to how the spectral information is processed in order to determine the direction of arrival of the received signal (DF/BF techniques). • the latest development in the field of HF radar setup, maintenance and operation, are included. Among them, communication and remote management of the HF radar station, and new calibration (antenna pattern measurement) methods for DF configurations. • a section dedicated to HF radar real time harmonized data management has been developed, from acquisition to postprocessing, archiving, preservation and dissemination, with a look on interoperability at a global level. • the need of distributing standardized and harmonized HF radar files has been highlighted, together with further details on the European common data and metadata model for real time HF radar surface currents and Quality Control Tests and Flags as adopted by CMEMS in situ Thematic Assembly Center for HF radar data distribution since April 2019.
Many details, impossible to list in this paper, can be found in the reference manuals and in the literature. Although this document provides significant improvements and additional information to what is available in the literature, many aspects of HF radar management best practices are under discussion or at an early stage.
Future developments relate to: the description of other types of HF radars currently in use or emerging; other kinds of data measured by HFR systems (like tsunami detection, winds or waves); advanced methods for Quality Control and gap filling (either in real time or in delayed mode); new algorithms for signal processing optimization; a global standard for file format, data and metadata description.

AUTHOR CONTRIBUTIONS
CM coordinated the work and contributed to all the sections. AR, JM, and AG contributed to the introduction and conclusion sections. CQ, JH, and SC contributed to introduction, setup and maintenance sections for beam forming HFR systems. LC and JA contributed to the data management and Quality Control section. ER contributed to Antenna Pattern Measurement, Maintenance and Data Management sections, editing of Figure 3 and acronyms list. All authors contributed to the conception, writing and revising of the work for the final submission.

ACKNOWLEDGMENTS
This paper is based on work carried on within the JERICO-NEXT project (Joint European Research Infrastructure network for Coastal Observatory -Novel European eXpertise for coastal observaTories), funded by the European Union's Horizon 2020 Research and Innovation Program under grant agreement no. 654410. We would like to thank the projects RITMARE (Italian national funds), INCREASE (CMEMS Service Evolution Call for Tenders 21-SE-CALL1), SeaDataCloud (EU-H2020 GA n. 730960), in whose framework the activities of data harmonization and standardization have been carried on. We acknowledge financial support from Copernicus Marine Environment Monitoring Service (CMEMS) through IBISAR (CMEMS User Uptake Call for Tenders 67-UU-DO-CMEMS-DEM4_LOT7) and INSTAC (http://www.marineinsitu. eu/). CMEMS is implemented by Mercator Ocean in the framework of a delegation agreement with the European Union. IMOS was supported by the Australian Government through the National Collaborative Research Infrastructure Strategy and the Super Science Initiative. Thanks to Dr. Charles-Antoine Guerin (Université de Toulon, Laboratoire MIO) for useful discussion on signal processing techniques, and Dr. Mark Otero (Scripps Institution of Oceanography) for reviewing the final draft of the paper. Thanks to Integrated Ocean Observing System and Radiowave Operators Working Group for sharing best practices documents.