We’ve published a series of video tutorials for HF novices to bring to life HF theory around the topics of Frequency selection, Antenna fundamentals and forecasting.
HF communications is very different to terrestrial communications and given the right frequency, time of day, and antenna, you can achieve long range links in excess of 1000km with only a few watts of power on a HF Dipole.
CloudRF’s API uses the proven VOACAP engine to create accurate HF predictions considering a number of factors. Using this tool, you can plan long range resilient links and anticipate the (time based) surprises HF throws up…
Frequency Selection
Time is critical to HF communications. As sunlight changes throughout the day, so does the range of usable frequencies. A common strategy for round the clock communications is to maintain a day and night frequency. These can be identified using the VOACAP powered path tool in CloudRF.
This tool reports the Signal-to-Noise ratio against time for different HF frequencies.
Antenna Basics
Once a frequency has been identified, an antenna must be constructed to the right dimensions.
The antenna of choice for many long range HF links is the half wave dipole. This simple and efficient design uses two fixed length elements and a center feeder to bounce signals off the ionosphere.
To get the wavelength for your frequency divide 300 by the frequency in MHz.
Height
The height of the antenna will change its radiation pattern and the take off angle.
Achieving at least a quarter wavelength is recommended for efficiency (and practicality) as the long HF wavelengths make a half wavelength too high for most masts. For an 11MHz signal, the height would need to be 6.8m for example.
Azimuth
HF patterns are directional and must be orientated towards a distant station. For some antennas, like long end fed wires this is as simple as pointing the wire towards the station.
For a half wave dipole, which has a donut shaped radiation pattern, it must be broadside towards the station as it has nulls where the wire ends are. A bad azimuth can be forgiven at short range but will determine the potential range.
Feeder loss
Using a feeder co-axial cable will reduce the efficiency of your system. The effect increases with length so you should aim for the shortest, low loss, feeder possible. The impact of the feeder can be simulated even if you don’t know the cable type by entering 1 or 2dB into the feeder loss option.
Forecasting
Sunspot R12
The Sunspot index number describes solar activity which follows a 10 year cycle. When the number is high, there is increased solar activity and better refraction. The different between a good and bad year within the cycle is around 6dB which on the S Meter scale is equivalent to two levels, or the difference between success and failure.
This can be predicted and the random element budgeted for using the model’s reliability value.
Simulating indoor radio coverage for first responders has been made simpler thanks to a new capability called Phase Tracing.
The novel design was influenced by the 2017 Grenfell Tower inferno, where radio communication in concrete stairwells was highlighted as a major problem.The Grenfell inquiry highlighted radio and training issues in the report, which had a section dedicated to communications.
During the inquiry, expert witnesses were unable to demonstrate how far a signal would travel within the tower, even with the availability of indoor planning tools. Estimated distances offered to the inquiry were based upon empirical measurements from elsewhere and were at odds with witness statements from firefighters who reported losing communication after only four floors and communicating with paper notes.
Multi-path in a stairwell
The intensive computation required to perform a true 3D simulation with reflections has been made practical through developments in graphics processing. As a result, accurate radio coverage in stairs, tunnels and elevator shafts can be simulated, at the network edge, by an operator with minimal training.
In contrast to legacy indoor planning tools, which use floor plans and images; Phase Tracing is designed for critical communications and industrial markets in challenging and dynamic 3D environments, represented by digital models.
Models not floor plans
Phase tracing in a multi floor open plan office
Phase Tracing represents a leap forward for radio simulation from overlaying images upon a 2D map or floor plan, suitable for an estate agent, to using a digital twin 3D model which considers all floors, and the obstructions in between from stairs, to air ducts and pylons. Simulating reflections is critical for indoor modelling which is a pillar of the design.
There also exists a huge gap in the market between indoor simulation packages and the skill required to use them effectively, and first responders who are left guessing where they will lose communications on a stairwell. This gap has been closed by developments in computation, namely GPU processors, and web technologies which mean this powerful API can be used from a low power touchscreen device.
A little movement…
For RF theory students who are taught the impact of multi-path; they now have a tool to visualise and explore this important concept; so they can see why “a little movement may cure a dead spot”. Better still, they can identify constructive “good” multipath they didn’t know about.
Tarana antenna at a railway station with a bridge and pylons
The GPU accelerated engine reads and writes to open standard glTF models and uses ray tracing techniques from computer games to bounce photons around the model. With the addition of phase, multi-path artefacts such as signal “dead spots”, where out of phase signals on the same wavelength cancel each out, can be modelled.
The number of reflections, material attenuation and scattering properties can be configured. This is essential for modern buildings which are built with materials which disrupt radio communication.
Applications
Phase Tracing has a distinct advantage over 2D modelling for the following 3D obstacles in most wireless industries.
Stairs
Tunnels
Bridges
Towers
Pylons
Dipole in a tunnelClick to aimMicrowave reflectionsAntenna polarisationSubway reflectionsBridge shadowsAntenna modelPhase stripesTowerOfficeStairwellSubway tunnel planning
Design
The Phase Tracing capability is built upon our 3D API which we launched last year with a blender plugin. The API can be called directly to integrate the output into other model based systems, or even viewed in a standalone HTML5 viewer.
Touchscreen interface on a tablet
The interface and API is radically different to our map based Globe. For starters there are no Geographic coordinates, positions are in Cartesian XYZ co-ordinates relative to position 0,0,0. This is so you can work with models which might not have a geo reference or in the case of design, might not even exist yet.
Photons and Phase
The 3D engine is a CUDA accelerated pipeline, like our 2D GPU engine, which processes jobs asynchronously to service multiple users. It creates a voxel model from a glTF file which it then radiates photons around. A photon will reflect from obstacles until it runs out of energy or reaches a reflection limit. Unlike Ray Tracing, a legacy technique for indoor modelling, these photons maintain their phase so multi-path can be simulated in all directions.
Each reflection costs several decibels of power typically so there is a practical limit, depending on the material, after which it will be too weak to be useful and the photon should be killed. The engine can model up to 30 reflections per photon which do not impact performance so much as the number of photons, currently set to 2e6. The required number of photons depends upon the model: If you have a small office and need to decide where best to put a Wi-Fi Access Point you don’t need many.
Reflections in a Microwave oven
If however, you need to model reflections up a stairwell, along a corridor and into a flat you need millions. This isn’t fast, or pretty, but such is the nature of critical communications. We’ve fixed the photon limit on CloudRF to deliver a calculation in under 30 seconds for a large model. A small model will be quicker.
VR/AR support
The cross platform interface uses three.js and the WebXR library which supports Virtual Reality and Extended Reality devices. We have a XR branch we’re playing with on a Meta Quest but are having a headache issue as it is so immersive you get vertigo exploring tall models. Once this is sorted, likely by AR, we’ll merge it. Last year the 3D output was integrated into a third party Hologram interface.
VR controllers in a development emulator
Demo Gallery
We have an interactive demo gallery of 3D models you can explore on our Github pages. To use these demos you will need a WebGL capable web browser like Chrome. You can use your mouse to zoom in and explore the models or download them as GLB to view on your phone using an app like glTF viewer. iPhones support these GLB models natively.
The API and version 1.0 of the interface have been published. The API can be used by Silver and Gold customers and the interface is restricted to Gold only presently whilst we build more infrastructure to support this.
Interference is one of the single biggest issues in radio which limits the potential of a system or network.
There are different types of interference but the problem of interference visualisation is common to all. With simulation software you can model your system, and an interfering system, but understanding the interplay where the coverage of the two overlap is crucial. Like many radio engineering concepts it’s a complex topic so making it simple requires abstraction which our API provides.
Up until now we offered a basic interference capability, capable only of colour promotion. It was unable to consider signal parameters or to show the level of interference.
Enhanced Interference API
The upgraded interference API considers the signal parameters frequency, bandwidth and power. It accepts two arrays of sites, one for the “signal” network and another for the “noise” network so you can compare two sites or scale the concept for two networks.
Frequency is obvious as two local signals on the same wavelength will interfere. This technology agnostic API considers the signal as a constant carrier. This means it does not consider features of the waveform since modern technologies, like 802.11, employ back-off mechanisms in the PHY to manage collisions whereby a transmission will pause momentarily if it detects noise.
Bandwidth is important as even if the signals are on different channels, their bandwidth may overlap. In 802.11, adjacent channels overlap by design when using wide (20MHz) signals but the amount is small enough that the spread spectrum signal can overcome it in error recovery mechanisms. As a result, many signals can operate in a dense slice of spectrum.
Power is harder to plan for in spectrum planning where the focus is normally on frequency management and is the source of most interference reports. Even if two signals are on different channels, with non-overlapping bandwidth, they can still interfere if one of them is sufficiently powerful. This is because a signal produces frequency harmonics at multiples of itself and power in the spectrum appears as a Gaussian function which looks like a bell curve. A powerful signal will bleed power into the spectrum adjacent to it and if a receiver does not have an adequate filter, it will receive this power even if it’s on an adjacent channel!
Presenting interference
We use decibels (dB) as the measurement unit to describe interference along with a special purpose colour key called JS (Jam to Signal). The J/S ratio, as the name implies, shows the interference (Jammer) power over the signal power. A bad JS ratio implying strong interference would be greater than 0 eg. 12dB and a good ratio would be negative eg. -12dB.
The level at which this interference presents a problem to a given waveform varies. Some waveforms are designed to operate within noise such as LoRa and others like WiFi fail gradually with noise: When people say “the WiFi is slow” yet they have a strong signal, the problem is interference which causes sampling errors, and reduces data bandwidth.
Using -3dB as a interference limit in planning is recommended. This is green on our colour key.
Anything higher than this and there will be reduced performance / speeds. An interference ratio higher than 0dB will likely stop you communicating altogether if your signal requires a positive SNR ratio – as most do. For reference, high capacity data waveforms require 20dB SNR and commercial telemetry requires less at 3dB SNR.
Demo: Signal jammer (Frequency)
This high resolution frequency demo shows the impact of a 10W signal jammer against a high powered urban rooftop cell tower radiating ten times more power at 100W EIRP.
Despite being near to the strong, and elevated, cell, the lower powered omni directional jammer is able to overcome the cell in building shadows and coverage nulls caused by the directional antenna pattern.
Where the interference is equal to or greater than 0dB, it is very likely that cell coverage would be disrupted.
Demo: FM broadcasting (Power)
This is a power problem whereby channels have been separated in frequency but there is interference from neighbouring channels. This is because a signal is shaped with a Gaussian function resembling a bell curve and has power either side of it in the spectrum. The stronger the signal, the more power bleeds into neighbouring channels.
Demo: Microwave link (Bandwidth)
A high power microwave link uses parabolic dishes to focus a high bandwidth beam towards a distant point.
On the path of the link is relatively low power 3GHz cellular system separated in frequency by 45MHz. There is no guard channel so the two signals are adjacent to each other. The directional pattern experiences interference at the edge but is not affected on the main beam.
API demo
We have published a new API demo to demonstrate this scalable capability using vehicles using PMR 446 radios which are being interfered with by other vehicles with different technology in the 446 band.
It uses our Multisite API to model each network for the Signal (Blue) and Noise (Red). When a transmitter, or vehicle in this case, moves, the network is updated and the interference simulated.
HF Ionospheric propagation, known as Skywave, has been added to the CloudRF API.
While Satcom offers clear advantages in terms of speed, bandwidth, and the ability to provide real-time, high-quality data transmission, HF remains a crucial alternative where cost, independence from satellites, portability, power efficiency, and resiliency are important.
Wide area simulation
The new /hf/area API endpoint uses the proven VOACAP engine to simulate coverage for a given transmitter at a given time of day. It combines CloudRF’s familiar JSON interface structure (transmitter, antenna, receiver, environment) with VOACAP antenna patterns and temporal parameters (Month and hour).
The maximum range for the simulation is 10,000km which takes several seconds and like other (area) layers it can be exported to KMZ, GeoTIFF and SHP.
The new /hf/prediction API endpoint provides a HF frequency prediction capability, powered by VOACAP, for a given link. It uses the same workflow as the path tool whereby the transmitter is placed upon the map, the path tool is selected and the receiver is placed.
The output is a chart of frequency SNR values for the link across the HF band from 2 to 20MHz and hours of the day. As ionospheric activity varies considerably between day and night, the chart helps select an optimal frequency and can be exported to PNG.
Time is critical with ionospheric communications so the “model” section has been extended to include three new variables.
Diffraction is disabled and the two familiar reliability and context variables can be tuned as with other models to match empirical measurements.
Month
The month is defined as a integer from 1 to 12.
The relevance to HF is that during the summer, solar activity, and therefore refraction, is increased.
Hour
The hour is defined as an integer from 0 to 23 and is in UTC.
The relevance to HF is that during darkness, the lower “D” layer collapses so RF which was previously attenuated is free to reach the higher “E” and “F” layers which increases both noise and global reach.
Sunspot R12 number
Solar activity follows a ten year cycle which can be predicted. The year 2024 is at the peak of this cycle so the “R12” number is high at ~150. In 2030 this will be low at (~25) and equivalent HF links will be more difficult.
Solar activity is subject to random bursts of radiation (Sporadic E) which makes predicting and calibrating HF communications harder than short range terrestrial links. Using empirical live measurements from sounders and crowd sourced networks, the random element can be mitigated but not removed.
HF antenna theory is a complex art form. For example, the same physical antenna will produce very different propagation depending upon its height above the ground where reflection takes place.
The reflection depth varies by terrain so a swamp has a ground level water table but a desert could have a reflection height much deeper so an antenna may not need elevating much at all to achieve a link.
This reflection height determines the “take off angle”, and skip zone, whereby a tall antenna between two tall masts has a lower take off angle, and longer range compared with a waist height antenna which has a steep angle and relatively short range for Near Vertical Incidence Skywave (NVIS), which we have a separate model for.
When selecting the HF model, you will be given a fixed list of VOACAP antenna patterns with which you can manipulate the gain, height and the azimuth. A typical gain figure for a dipole will be between 1 and 2.15dBi whereas a LPA could be 9dBi depending on elements.
Antenna
Description
API code
ITSA-1 Horizontal Dipole
Center fed symmetrical design with arms matched to half a wavelength. Deployed broadside to the target.
2
ITSA-1 Horizontal Yagi
Directional array which can be steered to a target.
3
ITSA-1 Vertical Log Periodic
Highly directional array with a focused beam pointed at a target.
4
ITSA-1 Sloping Vee
Simple directional antenna which only requires one mast. Arms are measured to 1/2 the wavelength and staked out towards the target.
5
ITSA-1 Inverted L
End-fed mixed polarisation antenna capable of local groundwave and distant Skywave. 1/4 wavelength up and 1/2 wavelength along.
6
ITS-78 Inverted L
End-fed mixed polarisation antenna capable of local groundwave and distant Skywave. 1/4 wavelength up and 1/2 wavelength along.
8
ITS-78 Sloping Long Wire
Simple end-fed wire orientated towards the target.
9
ITS-78 Arbitrary Tilted Dipole
Dipole tilted to achieve maximum gain.
10
ITS-78 Terminated Sloping Vee
Simple directional antenna which only requires one mast. Arms are staked out towards the target and terminated with a load.
11
Table of HF antennas and CloudRF antenna codes
Skip zone for a low take off angle
Example HF API request
This simulation request is for a 10MHz half wave dipole, 8m above the ground, radiating 30W of RF power.
The month is November and the time is 8am UTC.
The sunspot R12 number is ~150 for late 2024 based on the solar cycle.
Using crowd sourced link measurements from the amateur Weak Signal Propagation Network (WSPR), the VOACAP engine can be calibrated using our native calibration utility. Data can be filtered by station and processed ready for import to the calibration utility. The data reports Signal-to-Noise (SNR) measurements which reference an unknown noise floor. We recommend an average value of -100dBm for the 10MHz noise as any error in measurement is less than the other variables such as the variable solar radiation and distant station antenna gain for example.
The WSPR data required pre-processing to convert the 6 figure Maidenhead grid squares to WGS-84 coordinates. The maidenhead python library is recommended for this.
Filtering a time window is critical due to the propagation changes which occur throughout the day. For example, you cannot calibrate measurements from day and night together but you can calibrate an hour as a separate file.
Calibrated 10MHz signal from UK across Atlantic at 9am UTC
WSPR data for station G8ORM
HF propagation on 10MHz over 24hrs
A look ahead
Now that we have published an API, we want to integrate it into some systems. ATAK is an obvious candidate for starters but a HF radio which can see into the future or a ALE modem which doesn’t need to radiate to know it can, or cannot, communicate.
This capability will be available with the next SOOTHSAYER release.
Credits
Credit to the many VOACAP developers and maintainers over the years who have maintained this powerful capability. It is arguably one of the most senior pieces of operational software in the commercial world.
We have only put a shell on this incredible engine but hope our API will introduce a new generation of software developers and communicators to the magic of HF.
Following our most recent field testing, we have identified two significant improvements in accuracy:
The first is a new deterministic propagation model; the General Purpose model. This is a frequency agnostic curve which takes its accuracy from high quality reference data. It’s dependency on high resolution clutter sets it apart from legacy cellular models which are more complex empirical curves designed in an era of basic digital models.
The second improvement is better default clutter values which align with ITU-R P.833 recommendations, as opposed to our current light clutter values which have been retro-fitted to tune the ITM model, also designed before clutter data was widely available.
Dense clutter
When input settings are adjusted to match field measurements, the model and clutter parameters are adjusted to achieve the best match, measured by the error where a low score eg. 3dB is best. Previously, the calibration adjustments were weighted towards the model with clutter accounting for a relatively minor change.
With our new dense clutter values, we have referenced the ITU-R P.833 recommendation for vegetation values and other papers for buildings. As a result we have new, dense, clutter profiles which when combined with improved diffraction will improve accuracy.
These templates are optimised for 1GHz. Actual attenuation will vary by wavelength so you are advised to create your own if using a very short wavelength with adjusted attenuation.
CITY
Buildings are very dense (3.0dB/m), with variable heights and trees are short (8m) and light (0.4dB/m)
SUBURB
Buildings are dense (2.0dB/m), with variable heights and trees are taller (10m) and denser (0.5dB/m)
FOREST
Buildings are light (1.0dB/m), with variable heights and trees are tall (12m) and dense (0.6dB/m)
ITM model warning
There is one exception to this which is the ITM model: This is our oldest and most complex model which (uniquely) includes its own Vogler diffraction routine. The new dense clutter will not work with the ITM model which can only be used without clutter or a very light profile such as Minimal.clt.
The following table lists changes to combinations of models and clutter:
Model
Clutter
Comment
ITM
Minimal / Temperate / Urban
No change to coverage
ITM
CITY / SUBURB / FOREST
WARNING: Coverage will be very conservative. Do not use ITM with these profiles.
Others
Minimal / Temperate / Urban
Coverage will be optimistic where clutter is present
Others
CITY / SUBURB / FOREST
Coverage accuracy will be improved where clutter is present
All
NONE
No change to coverage
Propagation models and clutter changes
Release schedule
The updated engines and matching clutter profiles are scheduled to be published on CloudRF on Friday the 12th July 2024.
Our latest field test was focused on drive testing novel antennas by UK SME Far Field Exploits (FFX) around the Somerset countryside with Trellisware radios.
Previously, we validated diffraction models using LTE800 in the Mountains. The outcome of that cold test highlighted Deygout as the most accurate diffraction model when paired with empirical cellular models. For this much warmer antenna drive testing, we used lower frequencies and a lower mast in an area with many trees which presented a challenge for both legacy cellular models and LiDAR.
Testing highlights
Average Root Mean Square Error of 7.4dB
Average Modelling Error of 4.4dB
Automated data collection with ATAK plugin
New “General Purpose” model developed
New “GP” clutter profile for use with GP model
Test setup
The test area was in and around the small town of Somerton in Somerset. This town sits in rolling countryside featuring farms, high hedgerows and blocks of trees. A railway line with road humpback bridges bisects the town. The town has a small housing estate under construction which did not feature in our buildings data.
The base station was a wide-band Omega panel elevated 5m above the ground and connected to a Trellisware spirit radio. The radio was operated across several UHF bands, each with 1.2MHz bandwidth, and live positions observed on WinTAK using cursor on target (CoT).
The antenna testing vehicle was fitted with a roof mounted magnetic antenna bracket which connected to a spirit radio. This mount allowed different antennas to be swapped out. As a result we were able to test both a Hascall Denke MPDP675X4 and a FFX Sigma 3.
Data logging
We know customers and OEMs like to voice opinions about radios, waveforms and antennas but without solid measurement data it’s just noise with a lot of bias and emotion.
Data beats emotions every day!
As an antenna OEM, FFX developed the ATAK spectrum survey app to streamline collection of field measurements for antenna testing in different environments.
The logging application used the Trellisware radio’s API to fetch link metadata from the local radio and save it to the SD card as a CSV file.
The ATAK plugin enabled a large quantity of high quality measurements to be efficiently collected. As a result we were able to execute several test cycles in a short space of time – just as well as it was hot (for the UK) and Harry had no air conditioning…
The CSV files were downloaded from the phone and loaded into the CloudRF calibration utility for analysis.
The survey data was filtered to remove results weaker than the theoretical noise floor at -113dBm.
We were planning to use a measurement error of 2dB for the high quality radios (a cell phone is 3dB) but owing to the high temperate of the mobile radio in the car we used 3dB as receiver performance degrades with temperature.
At first look
The first pass comparison of the data showed a ~15dB delta between modelling and field measurements with LiDAR, prior to tuning. Using the ITM model and a high reliability value (99%) this only reduced several decibels and clearly needed more work. Ideally the model should align within 10dB so clutter tuning can then be used to reduce this towards 6dB.
ITM uses the complex Vogler multi knife edge diffraction model which is accurate for hills but needs tuned clutter to handle soft obstacles. Using cellular models, as we did in LTE800 field tests, didn’t produce the same results due presumably to the lower mast height and frequencies, even when enhanced with Deygout diffraction.
A new model
Through curve fitting we identified alignment with the P.525 reference model and a 20dB constant representing observed system losses. When enhanced with the Deygout 94 diffraction model this produced excellent alignment with the more challenging beyond-line-of-sight areas. Many signal paths on the route had multiple obstructions so a multiple knife edge model (MKED) was essential.
We have created a new model from these settings called the General Purpose Model. It is frequency and height agnostic which makes it ideal for ground and air based links and much more versatile than empirical equivalents which must be operated within a restricted performance envelope. Like all our models it must be used in conjunction with a diffraction model and tuned clutter to deliver accurate beyond line of sight results.
In our opinion, modern developments in processing and clutter data especially have rendered legacy empirical models largely obsolete. The modern way to fit modelling to measurements is to focus on precise clutter data not old path loss curves.
In the screenshot below, the car drove up a hill where it fell off the network behind a prominent knoll before reacquiring the network later on. This knoll was the second of two obstructing hills for this section of the route. The modelling predicted more coverage due to the chosen receive threshold, -107dBm, which was based upon 6dB above the thermal noise floor which was -113dBm at 1.2MHz bandwidth. It is very likely local noise was slightly higher.
ITU clutter values
Without clutter, the General Purpose (GP) model will be optimistic in most ground environments. It will be accurate over bare earth but where obstacles are present, it needs land cover and a clutter profile. Prior to developing the GP model, we did most of the tuning in the model using reliability (%) and only fine tuned with the clutter.
This is why older CloudRF clutter profiles eg. Minimal.clt have low values such as 0.05 dB/m for trees. With the GP model, the model itself is very simple and most alignment takes place within the clutter (profile). As a result, the clutter values used for GP are much denser. Our GP profile, created for this test has trees with a density of ~0.5dB/m, aligning with ITU-R P.833, attenuation in vegetation.
Diffraction logic has been re-balanced to accommodate ITU clutter values. Users using either the default ITM model or models without land cover are not affected. Legacy clutter profiles such as Minimal have not changed but you are advised to try the new GP model and associated GP clutter and see the difference for yourself.
Test parameters
Bandwidth: 1.2Mhz
Feeder loss: 1dB
Receiver height: 1.5m
Receive sensitivity: -107dB (6db above noise)
Noise floor: -113 dB
Model: General purpose / ITM
Reliability: 60% / 90%
Context: Average
Diffraction: Deygout 94 / Vogler (ITM)
Clutter Profile: Buildings 3dB/m, Trees 10m @ 0.5dB/m
Radius: 6km
Resolution: 5m
Results
The following table of results were from measurements conducted with the same base station, vehicle and radios. Only the vehicle antenna, and frequency, were changed in between tests. Once calibration had been achieved the area covered was extracted from the modelling. This is typically inverse to the frequency so a low frequency has better coverage than a high frequency at the expense of bandwidth – and both matter.
There are two standout results from the data: First is the low RMSE accuracy for the new GP model with tuned clutter compared with LiDAR which is satisfying given the challenging terrain and the second is the performance of the Sigma 3 on a frequency it is not officially rated for as it has a bottom end of 350MHz. The best alignment with the same settings was found to be with -5dBi receive gain confirming the antenna can be operated lower, and at range.
Once again, DTM with clutter has proven to be superior to LiDAR.
Antenna test
Model + Diffraction
Clutter profile
DEM
Receive gain dBi
RMSE error
Modelling error
Modelling area covered km2
Modelling area covered %
Hascall Denke MPDP675X4 on 1.4GHz
GP (60%) + Deygout 94
GP
DTM + 10m Land cover + 2m Buildings
2
9.4
6.4
19.2
17
Hascall Denke MPDP675X4 on 1.4GHz
ITM (90%)
N/A
LiDAR
2
15.2
12.2
12.4
11
FFX Sigma 3 on 415MHz
GP + Deygout 94
GP
DTM + 10m Land cover + 2m Buildings
2
6.6
3.6
89.9
79
FFX Sigma 3 on 415MHz
ITM (90%)
N/A
LiDAR
2
18
15
72.7
64
FFX Sigma 3 on 287MHz
GP + Deygout 94
GP
DTM + 10m Land cover + 2m Buildings
-5
6.2
3.2
86.1
76
FFX Sigma 3 on 287MHz
ITM (90%)
N/A
LiDAR
-5
15.1
12.1
63
56
Results table showing ITM+LiDAR compared with General Purpose +Clutter.
The scatter plot for the 1.4GHz data shows the simple GP model to align closer to field measurements than the much more complex ITM model. Our conclusion is that the ITM model, and it’s Vogler diffraction, developed in the 1960s, pre-dates developments in computing and precision clutter so provides good performance across multiple hills, at range, but is inadequate for macro planning at “street level” resolution where density of obstacles must be budgeted for.
ITM continues to be a solid UHF broadcasting model but it was designed for hard obstacles. Retro fitting it with soft clutter, as we have done can improve its performance several decibels but for maximum accuracy, the simple General Purpose model with tuned clutter provides superior results.
Results Gallery
Tuned coverage and survey data is displayed on the same map showing the RMSE and Mean error.
1433MHz tuned415MHz tuned287MHz tuned
Look ahead
The General Purpose model will go live on CloudRF in early July 2024 following more testing and then into SOOTHSAYER 1.8 later in the year.
Following two years of R&D, our new 3D engine and API is live.
It uses an advanced volumetric design to simulate propagation in all directions making it more advanced than 2D engines which can only produce flat images. By design, it supports multi-path and phase tracking to model “fast fading” when signals collide making it well suited to challenging urban and subterranean environments.
Key features include:
3D antenna patterns
Configurable reflections (up to 10)
Configurable material attenuation (dB/m)
Configurable material reflectivity (dB)
Configurable material diffusivity (Metal v Stone)
Multi-site support (n transmitters)
Phase tracking for multi-path effects (Constructive and destructive multipath)
Configurable resolution from 10cm, subject to model size
CloudRF Blender plugin
An open file standard and an Open API
We’ve chosen the growing glTF 3D standard by the Khronos Group for our input and output. It is supported by most devices, GIS software, graphics engines and 3D viewers.
You can transform LiDAR point cloud scans into a glTF mesh using a number of free packages to exploit popular formats like LAS and LAZ.
As per our open architecture and API-first design, the 3D API is available now as an open API. You will require a premium CloudRF account and an API key to use it.
With the API, you can push up a model, perform coverage analysis, and view the output using a hosted viewer supported by popular browsers.
Multi-path visualisation
Everyone talks about multi-path, the behaviour of colliding radio waves but can they visualise it? Signals schools teach students that a “little movement” will cure a dead spot. That’s good but when a little more movement puts them back in a dead spot again it doesn’t solve the real issue, current software cannot practically do multi-path.
There are expensive ray tracing solutions designed for design engineers but not operators deploying equipment, or students even who are taught to move, but don’t know where to!
In the screenshot below, a directional 5G antenna is pointed towards Tower bridge in London. Where there is line of sight on the river Thames the signal is a solid green. Where there are reflections, the signal is patchy and adjacent to the bridge there is a notable area of destructive multipath in the middle of the river. This huge dead spot is caused by strong reflections coming from the south tower of Tower Bridge. The north tower isn’t as affected due to the angle of incidence which creates a longer reflection path, and weaker reflection.
Destructive multipath in the middle of a river.
Viewer agnostic
As an open standards API our mesh output can be consumed by browsers, third party apps and AR viewers. We’ve already integrated it into a Hologram and the popular Blender 3D software and will add it to our web interface soon since we use Cesium which has supported glTF since 2014.
You can add glTF models direct into ESRI’s ArcGIS Maps SDK. Demo code is right here!
Blender plugin
Whilst developing this we used the popular Blender open source 3D platform to create obstacles and inspect output. We developed a plugin for Blender which we have open sourced so you can drive it directly from Blender. The plugin will upload your model and allow you to use it, along with CloudRF radio templates, to simulate RF coverage.
Instead of a geographic projection like WGS-84, this engine uses XYZ coordinates relative to the model origin (x=0,y=0,z=0). This is better for modelling buildings in isolation like architecture designs which don’t exist!
When a building is placed upon the earth, the translation to these values should be performed by the client, such as Blender so ideally the user does not need to know what/where they are – it just looks right.
Up and Forward
Cartesian vector coordinates are more complex to express than latitude and longitude.
This is best left to the client like Blender for example. As a minimum the position is required as XYZ and for advanced usage the API allows “up” or “forward” XYZ directions to be used to express rotation. Different platforms do different things with coordinates so we have opened up our API to support as many as possible.
Materials
We’ve supported configurable clutter for years but with multi-path support we have extended support for both attenuation, reflection and diffusion. The glTF standard supports materials by standard with human readable names eg. “Wood”. You should match the materials you are using with the “Keys” section to capture variants in your model for example: “Wood”, “Oak Wood”, “Timber”.
Reflection loss
Measured in decibels, this is loss incurred by a reflection from a surface. Solid surfaces like Metal reflect most of the energy so have a low loss value of between 1 and 3 dB and softer surfaces like timber absorb more energy so have higher loss values of 3 to 6 dB.
Transmission loss
Measured in decibels per meter, this is absorption loss. These figures will be much higher than what you might have used with our other APIs since those are nominal values based on average attenuation through a house whereas these are the actual value for the material(s) (eg. brick) not the parent obstacle (a brick house).
For example; a brick house measuring 10m wide might have 2 blocking walls at 10dB each for a given UHF frequency.
With the 2D API, this would be represented as a attenuation figure of 20dB / 10m = 2dB. In the 3D API the brick wall would be the simpler 10dB!
The advantage of this is we can now model inside rooms with different materials and furniture – if you have the model…
Diffusion
Radio waves scatter when they hit a wall. The behaviour varies by the material so you can define this behaviour with the diffusion parameter. It’s a randomisation ratio from 0 to 10. At 0 there is no diffusion and you are only considering the input ray. With 0.1 a small amount of randomisation is occurring so the reflection is very predictable like a game of pool.
With 10.0 the reflections are truly random in all directions. This would be suitable for a gravel path for example.
Performance
Modelling a cube is harder than a 2D plane so this takes longer. How long depends upon your model size and resolution and reflections. Increasing reflections doesn’t add as much work as you might expect due to our efficient design but asking for 20cm resolution for an entire neighbourhood will leave you waiting for a few minutes.
Performance tips
Start with 1m resolution and a small model
Keep you input model minimal. If you have every pot plant in the town it will be a big mesh file and will take longer!
Pretty photo realistic 3D tiles are pretty but take a long time to model. Go ugly early with basic models for speed.
Whenever there’s been a major incident involving emergency services in complex urban environments the inquiry report has consistently highlighted radio communications failure despite significant developments in radio communications and 3D technology since the infamous 1988 Kings Cross Fire on the London Underground. The following tragic incidents all featured tunnels, stairs and communications failure:
The 2017 Grenfell tower fire inquiry highlighted inadequate radio communications betweenthe incident control on the ground floor and fire fighters higher up the tower.
Limitations of (2D) radio planning tools
Radio planning tools are not used in emergencies. They’re complicated, slow and require a lot of knowledge to produce an accurate output. Even if a skilled operator were able to model a site before the event, currently they would be expected to model each floor of a multi-story building in isolation due to the “floorplan” design of current software.
The problem is indoor planning tools are built for corporate clients to achieve seamless Wi-Fi in every corner of the office, not to help a fire chief deploy a mesh radio network down stairs and then along a tunnel. The top end tools can do limited multipath, slowly, but not as an API which can be consumed by a third party viewer…
Most radio planning tools on the market, ourselves included, have the following limitations when it comes to complex urban modelling which we will explore in detail:
Using LiDAR as a 2.5D surface model
The abundance of free LiDAR data has made this high resolution data the standard for accurate outdoor RF planning and for several Fixed Wireless Access (FWA) tools, including free LiDAR based path tools, it is their core feature. We started using LiDAR in 2015 and know its limitations well; for example when point cloud LiDAR has been rasterised into GeoTIFF then it’s no longer 3D, it’s a 2.5D surface model which is useful for building heights and unsuitable for bridges, arches and tunnels.
A bridge or arch in a rasterised LiDAR model extends to the ground like a wall. In the screenshot below, a large ferris wheel is blocking line of sight through it as well as the elevated rail bridge across the river which is casting a shadow much larger than it would in reality.
London eye and bridges in LiDAR
Using a floor plan to model a building
Expect us
For indoor Wi-Fi planning tools, the start point is typically a floor plan. This does not scale well with multi-story buildings or support vertical planning as it producesa 2D image of a 2D plan.
Many tools present 2D images in a 3D viewer, as we do, but the output remains 2.5D, as with rasterised LiDAR. The significant Wi-Fi attenuation presented by solid floors makes this simplified 2D floor-by-floor planning viable for corporate clients in offices but not in challenging environments or where a floor plan does not exist.
Direct ray only
Attenuation is good, reflections are better
Modelling multipath, or fast fading, is much more complex than the direct ray. For this reason, most tools only do the more powerful direct ray and even then some cannot do diffraction or obstacle attenuation as we do already. For the previously mentioned Wi-Fi planning tools, the current standard is to model obstacle attenuation only. By doing this a tool is able to simulate most of the coverage quickly for a given floor but for complete accuracy it must be augmented by a walk survey, which isn’t so quick. For some customers, a walk survey is just not possible.
Multipath effects will increase coverage beyond a direct ray simulation and cause phase issues like signal dead-spots and doppler spread where reflections increase bandwidth and overall noise. This effect can be observed indirectly via customer reviews for urban WISPs where people state their once good link quality reduced as more neighbours subscribed.
A 3D multipath API for 2024
We’ve been working on this full 3D capability since the 2022 Grenfell inquiry with valuable input from firefighters, mining experts and MANET radio OEMs. The first version of the engine is done and we’re onto API integration now.
Our GPU based design takes a 3D model, simulates propagation in all directionsirrespective of floors including configurable reflections, surface refractivity, material attenuation and crucially it outputs to the open 3D standard glTF. It scales from small rooms to suburbs and everything in between so will be used for tunnels, multi-story buildings and outdoor multipath.
It will be integrated into our API first so other standards compliant viewers can visualise it and will then be integrated into our own 3D user interface. We can’t say what interfaces people will be using in the future but are confident that by aiming for open standards APIs we will ensure compatibility with phones, glasses and holograms.
Done
Read LiDAR into a 3D volume
Prepare a volume from a LAS/LAZ LiDAR scan.
Done
Direct ray with attenuation
Model direct ray with configurable attenuation in dB/m for obstacles
Done
Reflections
Model reflections accurately based on the wavelength and angle of incidence
Done
Phase tracking
Track the phase to show constructive and destructive interference (fast fading) eg. dead spots, cured by a little movement 😉
Done
BIM / glTF support
Read and write BIM models as the open standard glTF “3d tiles” format.
Under development
API integration
Integrate engine into the CloudRF API so a BIM/LAS model can be uploaded and used via our standard JSON requests.
Under development
3D tiles web interface integration
Add 3D tiles output to 3D web interface. Some interfaces already supported 🙂
To do
Multisite support
Model many sites at once
To do
Antenna pattern integration
Add 3D antenna pattern loss
Commercial plan
The 3D engine API will be a new feature within CloudRF Gold plans and our SOOTHSAYER server at no additional cost. It requires a GPU. We’re aiming to get a beta up on CloudRF in May/June and to ship this with the next major SOOTHSAYER release, currently scheduled for September.
Users will be allowed to upload models within their storage limits and execution time / accuracy will be scaled to fit within a reasonable time. Limits will be relaxed on SOOTHSAYER.
We are partnering with open standards based companies to integrate this into different viewers. One exciting partner we are working with now is Avalon Holographics. Their revolutionary display is able to display our rich engine output in a hologram format so it can be explored in three dimensions for maximum spatial awareness without additional hardware for viewers.
If you would like to get our open standard glTF models into your viewer, get in touch. If you can bring challenging BIM models or LiDAR scans of real tunnels and large buildings we would really like to talk to you.
We have lab tested three different size hardware profiles for running our SOOTHSAYERTM RF planning server to find out how they compare under load. These consumer profiles cater for different setups ranging from an enterprise with rack mounted servers, to a small office to a vehicle.
Enterprise server
This server is a standard Dell Poweredge R740 with an Intel Silver CPU and a 24GB Nvidia A5000 GPU running a Proxmox hypervisor. SOOTHSAYER 1.7 is installed as a virtual machine and LiDAR data is mapped via a network share.
This portable server is an Nvidia Jetson AGX Orin with an ARMv8 64 bit CPU and a 2048 core GPU. The server has 3 variable power settings and was run in the modal 30W mode.
SOOTHSAYER 1.7 is installed as a docker container and LiDAR data is local.
The tests used were designed to benchmark both the hardware and our software’s capability for high performance RF planning. We’ve picked challenges other tools would struggle to compete with, like Bullington diffraction and double digit megapixel resolutions.
High resolution area
The test parameters here were for a 5m resolution coverage heatmap out to 10km radius for a total image size of 16 mega pixels. This was repeated with and without Bullington diffraction and soft clutter data which is computationally expensive to show diffraction with soft clutter versus basic line-of-sight (LOS) speed respectively.
The test parameters here were for a 2m resolution LiDAR path out to a point 10km away. This would test 5000 points and would exercise our Path API.
Ten links at once
The test parameters here were for 10 random transmitters at 3km from a receiver using 2m resolution and Bullington diffraction. All links would be tested in a single API call to our Points API.
The results
All times are in seconds and were taken from the API response, excluding network latency and presentation in an interface.
Test
Server
Mini PC
Embedded PC
Area w/Diffraction (CPU)
26
13
38
Area w/LOS (CPU)
17
10.9
24
Area w/Diffraction (GPU)
6.7
13.1
116
Area w/LOS (GPU)
2.5
3.9
29
Path
0.14
0.05
0.08
Links
0.09
0.05
0.08
Table of results
The times didn’t fail to disappoint and threw up more than a few surprises. Unsurprisingly, cores matter when processing coverage and the fastest compute went to the largest GPU on the server.
When processing links, the CPU is critical and here the Intel i9 on the Mini PC excelled with a 50 millisecond compute time for multiple 2m LiDAR links. This faster-than-human reaction-time speed makes it suitable for dynamic planning with moving vehicles. The enterprise server disappointed with quick links due to the latency with the large data share where the LiDAR GeoTIFF tiles were stored. This latency was only noticeable with very quick calculations however.
The embedded PC performed admirably considering it was seriously under powered compared to the others at only 30W. It was able to model LiDAR links in 80ms and was only about 46% slower than an enterprise server at CPU calcs. Where it was noticeably slower was with processing the GPU area calculation. By increasing the power on the device to the 60W maximum the CUDA cores are doubled and from our testing we expect this would halve the GPU time.
Recommendations
For MANET link planning; an intel i9 CPU with an SSD is extremely fast
For high resolution area coverage; an enterprise grade GPU is unbeatable
For a small form factor host; the HP z2 G9 mini with an A2000 GPU is powerful
For value for money; the HP z2 G9 mini with an A2000 GPU is excellent
For low SWaP; the Nvidia AGX Orin 64GB delivers great economy
More information
For more information on self hosted RF planning, see our SOOTHSAYER page.
No load balancers with arrays of RTX gaming GPUs were used in this testing.We don’t need to do that!
Our latest major release of our private server, SOOTHSAYER, is ready. It includes six months of features, updates and bug fixes from CloudRF and features several customer sponsored capabilities including RADAR and Trilateration.
By popular demand, we now have a Docker enterprise solution so you can build your own containers or use our pre-built AWS template.
Thank you to all who gave feedback and feature sponsorship to help make this feature release. As you can see from the substantial new features and enhancements we continue to model the future of scalable APIs for multiple technologies and verticals such as Aviation and Counter UAS.
New in 1.7
RADAR model
The RADAR propagation model has a RADAR cross section parameter (m2) so you can model the effective range for detection of different sized objects with a RADAR, up to 90GHz, and 500km radius – horizon permitting!
It’s implemented in the API as model #8, both CPU and GPU engines and the user interface.
The noise API was developed from user feedback about the problem with varying local noise figures. Using a universal guessed value eg. -110dBm is not representative of the real world and especially the difference between a quiet rural and loud urban area for example. Now you can push in your own noise readings from radios or other sources either before or during planning. When modelling, live noise can be used by setting the noise value to ‘database’.
The Trilateration API was developed by popular request to accelerate and enable the process of geo-location of an unknown emitter. It will challenge conventional thinking about the accuracy of power based geo techniques by using accurate modelling and clutter data instead of circles. Our modelling has been field tested to below 8dB RMSE.
It requires receivers to be pre-modelled to enable rapid RSSI lookups using live receiver measurements. Using this two step process, results are delivered in milliseconds unless a receiver is moving in which case it’s coverage can be maintained using the fast GPU engine.
Since our inception we’ve used height above the ground as most of our users are land based terrestrial planners. As we’ve gained more aviation, and RADAR, customers, barometric altitudes are now supported by request. The altitude type is specified in the request “output.units” key as before only now there are four possible inputs instead of two. Range is 1 to 120,000 m/f.
Value
Description
m
Meters above ground
m_amsl
Meters above sea level
f
Feet above ground
f_amsl
Feet above sea level
API height measurement units
HF NVIS model
By request we’ve added a HF Near Vertical Incidence Skywave (NVIS) model. This models the first bounce from the ionosphere out to 500km and has an option for three layers (D, E, F) at differing refractive heights. This capability is supported in both our CPU and GPU engines and is particular valuable for teaching HF as it will give students an interactive HF tool to learn dipole patterns, the difference between day and night and critical frequency selection.
We have calibrated our NVIS model to align within 10dB of measurements taken from a 2012 research paper by Marcus Walden using a 5MHz NATO frequency in the UK. From this paper we selected one of the longer links at 210km where we used the median measurement value for August.
HF reliability animation
Bullington and Deygout diffraction models
Our single knife edge diffraction model has served us well for many years but cannot deliver the accuracy we aspire to once multiple obstacles are on the path. We have therefore invested substantial effort to add the much more complex Bullington and Deygout models to both our CPU and GPU engines. These greatly enhance simple propagation models as we proved during our LTE800 field test in the mountains earlier this year.
Deygout diffraction
Automatic CSV processing in UI
From user feedback we created a solution to a problem whereby customers using managed IT systems were not able to install or execute our python API scripts but needed to batch process spreadsheets. We addressed this by adding a form within our web interface where CSV spreadsheets could be uploaded and automatically processed. It uses a much simpler format which combines with the current form settings like environment to execute API calls.
This is a logically more advanced path loss model compared with legacy curves which is designed for terrestrial VHF and UHF planning. It’s conservative so we recommend the optimistic context with Bullington diffraction.
Multisite support for mixed AGL / AMSL units
After we implemented height above sea level for aircraft, we received feedback from customers using our multisite API that they would like to model transmitters above ground level and receivers above sea level. This is a common scenario for a ground-to-air network for example. We extended the multisite API to allow for mixed units so this can all be modelled in a single API call.
Testing
Our testing cycle is six months long, and starts with CloudRF where thousands of users, on every device imaginable, will test our API and interfaces to destruction. By opening it to the public via our free plan, we encourage many concurrent users, with diverse client software, to test our service and in doing so receive much more comprehensive testing than legacy products or GOTS software which only the contractor has tested.
Field testing is essential to validate the accuracy of our software and calibrate radio templates. After we implemented our new diffraction models, we took them to Scotland where we mapped out 22km of mountain LTE800 measurements. This valuable data improved the models and clutter profiles for UHF and validated our investment in improving accuracy.
Our API is regression tested daily and our models have a custom test harness to validate the many permutations of path loss models, environment contexts, diffraction models and parameters. As the number of models and inputs has grown we are relying on automation to ensure outputs are consistent and within parameters for the model(s).
Our user interface on CloudRF is instrumented with third party error handling software which automatically triages bugs for us. Through this we are able to identify issues early before customers are aware. This works especially well with our crowd sourcing strategy since we see a greater variety of clients than legacy or GOTS competitors who do not have the confidence to do genuine crowd sourced testing.
For hardware and hypervisor compatibility we have invested in a wide variety of systems and GPUs ranging from low end consumer GTX cards to enterprise grade devices like the A5000 and A100. We test SOOTHSAYER virtual machines on Proxmox 8 and ESXi 8 with different CPU architectures, network profiles and resource profiles.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
