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.
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.
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.
Recently, we added advanced diffraction models to CloudRF to complement our existing models. To validate the performance of the new Bullington and Deygout models, we took a field trip to the Highlands of Scotland to collect UHF measurements over rugged mountain terrain and through forests.
With these measurements we have validated and optimised our new models for this environment. We already had single-knife-edge diffraction, based on Huygen’s formula, and the Irregular Terrain Model (ITM) which uses Vogler diffraction. The Vogler model is known to be good but single knife edge has its limits which we have pushed.
Summary
The testing validated our investment into the complex multi-obstacle models we have added.
Both new models offer a significant improvement in accuracy, with no loss in performance for Bullington. We were able to model diffraction with higher accuracy over multiple challenging obstacles such as gradual convex slopes, ridges and valleys. Modifications have been made to the CPU and GPU engines which will be updated on CloudRF and SOOTHSAYER in due course.
Our key findings include:
Single-knife-edge was optimistic
Deygout was the most accurate, but slower
Bullington provided the best overall performance
7.6dB accuracy achieved, including receiver error
2.4dB improvement on single knife edge model
Test environment
We selected a famously cold and remote valley in the Cairngorms national park for our test which has cell towers in the valley and a variety of local repeaters for TETRA, VHF and UHF PTT services. The challenging terrain is notoriously difficult for radio communications making it ideal for our purposes.
Using a test phone with 3dB of measurement error attached to the Vodafone 4G network and a portable Rohde and Schwarz spectrum analyser, we collected a variety of VHF and UHF measurements along a 22km circular mountain route covering a wide variety of terrain. From the data collected, the 800MHz LTE measurements proved the best examples of signal failure so we focused our post-analysis on these.
Throughout the LTE testing the phone attached to multiple local cells and experienced prolonged signal failure as expected in a remote mountain valley.
We filtered the results to isolate 634 RSRP readings from a single physical LTE cell, PCI 460, from which we would calibrate modelling. This cell was located at the start of our test route and was a high power LTE band 20 (800MHz) base station with 10MHz of bandwidth.
Trees and attenuation
The first, and last, few miles of the circular route was a mature Scots pine forest. Unlike dense Scandinavian pine forests, this was sparse with a relatively high tree canopy. A lighter tree clutter profile was used to represent the attenuation from these trees which impact UHF propagation.
Convex hill and a loss of signal
Beyond the forest, the route gained altitude into a mountain plateau where line of sight was lost. The shape of the hill meant any diffraction formula would have to model a gradual convex shape versus a simpler knife-edge obstacle.
The ascent and re-acquisition
As the route ascended a spur leading toward the ridge, the signal was reacquired beyond the snowline. This signal gain was gradual, starting as a diffracted signal from the lower convex hill which eventually became a direct signal at the summit, 7km away from the cell.
Summit switcheroo
The route traversed a high ridge which featured many gaps in our cell coverage in the test data. These gaps were because the LTE modem performed a handover to stronger cells which appeared as soon as they were “visible”. Depending upon the position along the ridge, it occasionally reverted to the original “460” cell at over 7km.
Descent into darkness
The steep descent from the ridge entered a obscured valley not visible from the cell.
This resulted in a prolonged loss of signal for several miles until the signal was reacquired toward the trees at the foot of the valley.
Results analysis
The LTE survey data was prepared as CSV and loaded into the CloudRF web interface for use with the coverage analysis tool. This provided live feedback on accuracy with user generated heatmap layers so the correct settings could be identified first visually using a fine colour schema and then numerically by the reported average error in decibels.
Whilst the site location and frequency was known, the power output was not so the first task was to match line of sight positions, such as on the ridge-line, to establish the power without any obstacles. From there, a tree clutter profile was created to match the tree measurements and finally the best model and context were selected. For this task, the generic Egli VHF/UHF model was chosen as a basic model on which to base the diffraction comparison.
As settings matured, the reported Root Mean Square (RMS) error reduced accordingly until it was below 8dB (including 3dB of receiver error). This was slightly better than the 8dB we achieved on our last field test with LTE800 previously and given the extreme context, spanning a diverse mountain range, this was an excellent improvement.
Subtracting receiver error gives modelling error in the range of 4.6 to 7dB; an excellent result for difficult terrain.
Diffraction model
Mean error dB
RMSE error dB
Modelling error dB
Comment
Single knife edge
5.2
10
7
Optimistic. May show false positive coverage.
Deygout
-1.7
7.6
4.6
Good. Can be conservative and is 50% slower but gives high assurance.
Bullington
1.4
8.9
5.9
Good. Can be optimistic but is as fast as KED and relatively accurate.
Calibration results from comparing area coverage with survey data
Coverage results
The scatter plot for the ascent to the ridgeline shows measured and simulated values. The steep drop at 2.5km and gap in results after 3.3km matches closely for the critical beyond line of sight region. The results start again once we ascended toward the ridge where the new models were conservative by 10dB whilst the simple knife edge model tracked the path loss curve – which was to be expected. All models aligned once line of sight was achieved at 6.3km.
The outcome of this testing has improved the accuracy of our diffraction models, identified optimisations for our clutter profiles and proved a simple path loss model can be very accurate beyond line of sight with the right diffraction model.
The API settings we used for the LTE800 cell and RSRP output are here. Note the custom clutter profile and fine colour schema.
Climbing mountains in winter to test radio networks is dangerous, hard work which requires fitness, experience, skill and dedication to RF engineering. Only do this if you are serious about improving accuracy!
Today we launched a new model for ionospheric communication planning with High Frequency Near Vertical Incidence Skywave (NVIS).
It’s available in the interface and directly via the area, path, points or multisite API calls. The powerful GPU accelerated capability offers a modern way of visualising and teaching NVIS propagation. It does not, in it’s present form, do frequency selection so this must be performed prior to using this tool to visualise the coverage.
Background
This form of basic ionospheric propagation is popular with Military, Maritime and rural customers. With a simple horizontally polarised antenna and the right frequency, an operator can establish a link of up to 500km making this a quick and economical method for communicating long distances.
HF is undergoing a renaissance driven by uncertainty of the availability of space systems and the need for secondary communications in emergency PACE planning. Despite the choice available now with consumer grade space based communications, HF is a low cost method which requires no third parties making it immune to business and geo-political changes.
As HF bandwidth is very limited, historically only CW and voice channels were viable although developments in compression, cognitive radio and now MIMO are changing this. Improvements in software especially mean that reliable data channels with improved throughput are possible which makes HF data links a popular low cost, low bandwidth, alternative to satellite communications.
Ionospheric propagation
The ionosphere describes layers of ionised gas between earth and space which vary in height between around 100 and 300km. These layers reflect (HF) radio waves and attenuate others. As the layers are stimulated by sunlight, propagation changes significantly between day and night. Seasons affect propagation also, so a frequency which is good in the day may become unworkable after sunset.
The D Layer is the lowest layer at around 100km and absorbs low frequencies (2-4MHz). This weakens at night so these frequencies become viable. This determines the Lowest Usable Frequency (LUF).
The F layer is the highest layer at around 300km and reflects higher frequencies between 4 and 8MHz. The critical frequency is the Maximum Usable Frequency (MUF) which changes throughout the day, determined by sunlight.
A useful analogy for considering the change in the layers is a car engine; It warms up quickly in the morning and cools gradually at the end of a day driving. HF layers change quickly at dawn and slowly after sunset.
Higher frequencies beyond 8MHz experience less refraction so pass through the layers out into space. Depending on conditions a higher frequency may be possible but the most reliable (for NVIS) are found between 2 and 8MHz.
Using the NVIS model
The HF NVIS model can be selected in the model menu or in the API as code 12. Like other models it has a configurable reliability (aka fade margin) and a “context”. The context here refers to the refraction altitude and not an environmental eg. urban/rural choice with other terrestrial models.
Context 1 is the D layer at 100km – (Day)
Context 2 is the E layer at 200km
Context 3 is the F layer at 300km – (Night)
In the day you should use the D layer and your frequency should be between 4 and 8 MHz.
At night, you will use the F layer and need a lower frequency between 2 and 4MHz.
This HF model is only for use with a pre-determined frequency. It does not do forecasting or LUF/MUF frequency selection. This functionality will follow.
The reliability option provides a 10dB fade margin to tune modelling to match the real world. This was set with 50% reliability aligning to summer predictions with a 5MHz frequency.
HF dipole antenna
The antenna pattern will be a special horizontal dipole. You may set the gain and azimuth only but cannot change the pattern as it has high angle nulls for the skip distance before the reflection hits the earth. This will manifest itself as a cold zone at either end of the dipole where the pattern gain is lowest.
This animation shows a dipole orientated north west. The angle of orientation is measured perpendicular (at a right angle) to the wire so the tips of the antenna will generate the worst coverage, in this case to the north east and south west.
Radius and resolution
The recommended resolution for NVIS is 180m due to the immense size of the problem. Land cover is irrelevant with this mode of propagation. The radius has been limited to 500km in line with API limits. You can go further with NVIS but would run a risk of straying into multi-hop HF Skywave and this capability is focused on one hop only.
Most NVIS communication takes place between 50 and 300km where groundwave ends and the signal fades into the noise floor.
Using the GPU engine we can model a 500km radius with NVIS and terrain in under 3s. Terrain is a small concern to NVIS unless it’s a large mountain several hundred km away. In this case you will experience shadows due to to low angle of incidence but compared with shadows from terrestrial communications, it will be small.
Environment layers such as land cover and buildings should be off. They will be ignored at 180m resolution.
The colour schema can be whatever you like but if you want to align with the ‘S’ meter scale, popular with HF, where a barely workable signal is S1 and the best is S9 (-73dBm) use a max value of -73dBm with 6dB bands for S9 to S1.
Accuracy verification
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 which for August 2009 was lower during the day than VOACAP, a popular open source application for HF forecasting. The median dBW measurement at noon was -120dBW (-90dBm).
Noting that the RMS error between the VOACAP predictions and the measured values was concluded to be 7 to 12dB at 12 noon (Ref table 7 on page 8), and more at night, we have tuned our model so an “optimistic” prediction is 3dB from the noon measurement. The context and reliability options provide sufficient control to allow predictions to align with current and local ionospheric conditions.
The screenshot below shows both the path and the area coverage aligning with a 1dB calibration schema. The link has over 900m of curvature height gain which explains why a flat region of England appears as a mountain!
HF NVIS calibration to 3dB
Ionospheric modelling is less predictable than terrestrial modelling due to unpredictable solar radiation. Predictions generated with this model are useful for training, situational awareness and antenna alignment but cannot provide an accuracy greater than 10dB, assuming the inputs are correct.
Look forward: Space weather and long range HF
HF forecasting tools use lookup tables to set refractivity during both seasons and times of day. Using quality, and current data, improves accuracy but like weather forecasting it cannot offer accurate predictions without live data, in this case space weather which has seen a lot of renewed research recently. Our implementation does not use forecasting data presently so users should not be using it to pick their frequencies, but it will help visualise the coverage and align antennas – which at 500km is important.
For the next phase of HF, long range skywave, we will use a space weather feed to offer high resolution HF predictions. Long range HF uses multiple hops at lower angles so the space weather and time of day must be considered along the route which may be thousands of kilometers….
Radio planning software has a patchy reputation. Regardless of cost, the criticism, especially from novice users, is generally that results “do not match the real world”. The accuracy of modelling software can be improved with training, better data, tuned clutter etc but if you do not plan for the local spectrum noise, it will be inaccurate.
The reason modelling does not match the real world, is thereal world is noisy, and noise is everything in digital communications. Spectrum noise will limit your network’s coverage and equipment’s capabilities. A radio that should work miles can be reduced to working several feet only when the noise floor is high enough.
Anyone expecting simulation software to produce an accurate result without offering an accurate noise figure will be forever disappointed as software cannot predict what the noise floor is in a given location at a given moment – you need hardware for that…
Spectrum sensing radios
Modern software defined radios are capable of sensing the noise figure for the local environment. This allows operators, and cognitive radios, to make better choices for bands, power levels and wave-forms as narrow wave-forms perform better in noise than wider alternatives due to channel noise theory where noise increases with bandwidth.
For example, you can have a radio capable of 100Mb/s but it won’t deliver that speed at long range, at ground level, as it requires a generous signal-to-noise margin to function. This is why a speed demo is always at close range.
When spectrum data is exposed via an API, like in the Trellisware family of radios, it provides a rich source of spectrum intelligence which can be used for radio network management, and dynamic RF planning with third party applications. When we integrated this radio API last year, we were focused on acquiring radio locations, not spectrum noise. At the time we could only consider a universal noise floor value in our software so the same noise value was applied for all radios which was vulnerable to error as radios in a network will report different noise values.
Interference: a growing issue
The single biggest communications problem we hear about, from across market sectors, is interference, either deliberate, accidental, or just ambient like in a city. The number of RF devices active in the spectrum, especially ISM and cellular bands, is increasing and in markets which were relatively “quiet”, such as agriculture. Some have always been problematic, such as motorsport, where the noise floor increases significantly on race days.
Spectrum management is a huge problem which won’t be fixed with management consultants or artificial intelligence. Regulators can, and are, restructuring spectrum for dynamic use but to use this finite resource efficiently, hardware and software vendors need to publish APIs and competing vendors need to be incentivised to work to common information standards.
As noise increases, the delta between low-noise RF planning results and real world results has the potential to grow. There’s anecdotal evidence that some private 5G network operators are experiencing so much urban noise they’ve given up on RF planning altogether, and have opted to take their chances using a wet finger and local knowledge. Skipping RF planning is a managed risk when a company has experienced staff (or they get paid for failure), but it does not scale and is a significant risk when working in a new area and/or with inexperienced staff.
A solution: The noise API
To address this challenge, we’ve developed a noise API to eliminate human error, and guesswork for noise floor values which has undermined the reputation of “low-noise” radio planning software.
Manual entry can now be substituted for a feed of recent, or live, spectrum intelligence to enable faster and more accurate network planning. Combined with our real-time GPU modelling, the API can model coverage for moving vehicles, with real noise figures.
There are two new API requests in v3.9 of our API; /noise/create; for adding noise, and /noise/get; for sampling noise. The planning radius is used as a search area so you can upload 1 or thousands of measurements, private to your account. The planning API will reference the data, if requested, and if recent (24 hours) local noise is available for the requested frequency, it will sample it and compensate for the proximity to the transmitter(s).
When no noise is available within the search radius, an appropriate thermal noise floor will be used based on the channel bandwidth and the Johnson-Nyquist formula. The capability can be used by our create APIs (Area, Path, Points, Multisite) by substituting the noise figure in the request eg. “-99” for the trigger word “database”.
In the example JSON request above, two adjacent UHF sites are in a single GPU accelerated multisite request. The sites both have a noise floor (nf) key with a value of “database”. Noise will be sampled separately for each site.
Demo 1: Motorsport radio network on race day
The local noise floor jumps ups significantly on race day compared with the rest of the time making planning tricky.
Demo 2: Importing survey data to model the “real” coverage across a county
By importing a spreadsheet of results into the API, we can generate results sensitive to each location.
A look forward to cognitive networks
Autonomous cognitive radio networks require lots of data to make decisions. Currently, they can use empirical measurements of values such as noise to inform channel selection and power limits at a single node. What they cannot do is hypothesise what the network might look like without actually reconfiguring. To do that requires a fast and mature RF planning API, integrated with live network data. Only then can you begin to ask the expansive questions like, which locations/antennas/channels are best for my network given the current noise or the really interesting future noise whereby the state now is known but the state in the future is anticipated.
As our GPU multisite API can model dozens of sites in a second, the future could be closer than you think…
“I’ve never seen modelling that matches the real world”
Anon
Noise in the RF spectrum is a growing issue. It undermines the performance of systems and requires careful spectrum management and deconfliction to mitigate its impact. Sources of noise can be natural, industrial or man made. Regardless of the source, or intent, the issue needs understanding and dealing with to operate effectively in congested spectrum.
Radio users working in cities know about this problem all too well. They can describe the symptoms but are unable to visualise the full impact, and in doing so realise a solution such as an adjustment, through a lack of tooling. Many organisations have bought receivers for use at the edge, and back office software for planning but the two rarely meet…
Noise floor and SNR
The noise floor describes the average minimum RF power in the spectrum. There are different ways to measure it, and depending on the requirement you may want the peak power but for our purposes we are using the mean dBm value within the channel. A quiet noise floor value is -120dBm, subject to bandwidth. The higher this value, the less range you are communicating.
Signal to Noise Ratio (SNR), measured in dB, describes a signals power above the noise. A good signal might be 20dB above the noise and a weak signal only 3dB. Different signals have different SNR requirements; GPS for example uses a BPSK signal with a very low 2dB requirement so it’s barely visible in the noise whereas a DVB QAM signal needs a prominent 20dB SNR to deliver an error free video signal.
In CloudRF, both noise and SNR can be defined to simulate different environments and different waveforms.
A good guess – Johnson-Nyquist noise
Without the presence of man made signals, the RF spectrum has a natural noise floor called the thermal noise floor. This can be calculated with temperature (noise increases with temperature) and bandwidth (More bandwidth equals more noise).
Noise dBm = -173.8 + 10 log10(Frequency in Hertz)
Calculators exist to compute this value based on the Johnson-Nyquist formula. We use this in our interface so when you change bandwidth the noise floor is set. This is a good start, consider it a 75% guess, but is not the real noise. To get that you need to go to that place and measure it.
Measuring noise with an RFeye Node
To measure the noise floor accurately you need a high quality receiver. Low quality SDR receivers are easy to come by but will not be able to give you a more accurate noise value than the previously mentioned bandwidth formula.
The CRFS RFeye Node is a high performance RF receiver with an excellent dynamic range, industry leading low noise figure, and sensitivity. The API enabled receiver is in use worldwide for remote spectrum monitoring making it an ideal candidate for integration, especially since it has open source client scripts!
Integration with the CloudRF API
We imported the NCP client library into our open source API client so we could query the noise for our target frequency and bandwidth. Every time our script processes a site, the noise is tested and the result spliced into our site request.
In return we get a model which uses a real noise floor value. Typically this is higher than the formula method resulting in reduced coverage.
The beauty of this integration is the receiver can be in another county but the modelling can be conducted with high precision from home. With the scalability of the API it unlocks several possibilities:
Model a spreadsheet for a large network, and sample noise floor from local receivers instead of using a generic best guess value
Model a route for a drone with different noise values along the route. If you’ve ever lost communications with a distant 2.4GHz drone that had LOS this was likely WiFi noise
Model a radio and/or a waveforms performance in a remote location without visiting or deploying equipment which is expensive and time consuming
Demo video
In this video we put it all together to incorporate live noise into our modelling. We’re executing one site at a time, but with a spreadsheet, the API client will automatically process a network of sites.
Dynamic noise floor modelling with a CRFS RFeye receiver
We field tested our software to improve it for beyond line of sight planning. From analysis of data we have improved diffraction accuracy, clutter profiles and crucially have proven that high resolution LiDAR is not the best choice for beyond line of sight or sub GHz modelling. An RMSE modelling error of 5.2dB was achieved as a result.
Modelling can only be as accurate as the inputs.
Given accurate reference data and accurate RF parameters it can be very accurate but achieving both conditions requires careful and delicate calibration of dozens of variables. Thankfully this time intensive process is only necessary when changing hardware which for most organisations is a cycle measured in years.
The reference data used could be a digital terrain model like SRTM, a digital surface model like ALOS30, high fidelity LiDAR or landcover like ESA Worldcover. As we demonstrate, high resolution does not always translate to high accuracy in beyond line of sight RF.
Calibrating modelling with LiDAR data to match field measurements
LiDAR is great, but it’s not a silver bullet
You can have the most expensive 50cm LiDAR money can buy and still not achieve real world accuracy or a notable gain over 1m or 2m data (unless you’re planning for a model village). LiDAR on its own cannot model beyond line of sight, essential for sub GHz planning, which is a risk we’ll explore when planning tool design is focused on sales and marketing, not actual RF Engineering.
Controversially, you can get better BLOS modelling accuracy with basic terrain data enhanced with calibrated clutter profiles which we’ll demonstrate below.
The best data to use depends on the technology and requirements. LiDAR is unbeatable for line of sight planning, but won’t help you in the woods, or beyond line of sight without a proper physics propagation engine.
Unless your network is composed of static masts eg. Fixed wireless access (FWA), then chances are you are working non line of sight between radios so LiDAR should be used carefully.
Public 1m LiDAR data showing cars, trees and houses
“Line of sight” field testing Feb 2022
Last year we field tested LTE 800MHz in the Peak district and achieved excellent calibration figures for distant hilltop towers looking onto open moorland. This was predictable given the legacy cellular models we used were developed from similar measurements. As the blog described, the harder calibration was inside a wood where the LiDAR data proved unsuitable. Due to the simplistic nature of first return LiDAR, a tree canopy appears as a solid immutable obstacle. You can model the RF as it hits the tree canopy but not where it matters, on the ground inside the trees. This key finding accelerated and matured our developments with tooling to support calibration with survey data in CSV format and user configurable environment profiles.
CSV import utility – developed for analysing field test data
Clutter manager
“Non Line of sight” field testing, Feb 2023
This year we field tested LTE 800MHz again but this time in a old Gloucestershire village, Frampton on Severn, where the tower was deliberately obstructed and the solid stone buildings in the village meant we were measuring diffraction, coming from rooftops of single, double and triple storey buildings. The test data was collected from 2 handheld LTE test devices using a combination of Network Signal Guru (NSG) and CellMapper for Android. This app reports signal values and logs cell metadata with locations to a CSV file which we can analyse.
Some variables were unknown such as RF power, which required us to take measurements on the green in full line of sight. These “power readings” allowed us to reverse engineer the cell power as approximately 40dBm (10W) which would be appropriate for a cell serving a village.
Frampton on Severn. The cell tower is to the far right behind the pub.
Received Signal Received Power (RSRP)
The measured power value is Received Signal Received Power (RSRP) which is a LTE dBm value determined by the bandwidth, in this case 10MHz like most LTE Band 20 signals in Europe.
RSRP is lower than the carrier signal (Received Power) which is agnostic to bandwidth, but also measured in dBm.
Be careful not to confuse the two units of measurement as they can vary by more than 27dB!! A carrier signal of -80dBm might have a RSRP of -108dBm or lower depending on bandwidth. RSRP is usable down to -120dBm.
Received power dBm
Bandwidth MHz
RSRP dBm
-70
10
-97.8
-80
10
-107.8
-90
10
-117.8
Relationship between power, bandwidth and RSRP at 10MHz
Diffraction
Diffraction is the effect that occurs when radiation hits an edge like a rooftop or a hilltop. The wavefront radiates from that edge with resulting power determined by several factors like height and wavelength. Much like a game of pool, the angle of incidence determines the angle of reflection so a tall building will cast a long RF shadow before the diffracted signal is available again beyond the shadow. A proper diffraction shadow has soft edges as the RF scatters in all directions. LiDAR data creates sharp shadows, even when trees have no leaves.
The CloudRF service has two diffraction capable CPU and GPU engines which use a proprietary algorithm based upon Huygen’s formula which considers obstacle dimensions and wavelength.
Exaggerated diffraction caused by solid LiDAR
Which propagation model is best for 800MHz?
Most propagation model curves follow similar trajectories but differ by only a modest amount of dB in relation to the impact of an obstacle. The choice of model is therefore less important, in our experience, than getting the obstacle data right so for a cellular base station, you could choose to calibrate against any empirical or deterministic model which supports that frequency. Each model has a reliability margin to help align and tune it. For UHF the advanced (and default) ITM model is preferable as it was designed for NLOS broadcasting with complex diffraction routines. For this test we picked the simpler Egli VHF/UHF model with basic knife edge diffraction since this features in both our CPU and GPU engines, and we want to calibrate both.
Path loss curves for propagation models
What is “accurate”?
The cellular modem used to record power levels has a measurement error of -/+ 3dB so any reading cannot be more accurate than this. Therefore, if calibration of field measurements returns a Root Mean Square (RMSE) value of 8dB, this can be considered to be composed of measurement error and (5dB of) modelling error.
For Line of sight, a modelling error level of < 10dB is ok, < 5dB is good, and < 3dB is excellent. This is the easy part which for some basic tools is enough.
Line of Sight coverage: Good for above UHF only
For non line of sight (which covers much more complex scenarios), the error doubles so an error level of < 20dB is ok, < 10dB is good and < 6dB is excellent.
For our field testing, we achieved a non line of sight calibration with 5.2dB of modelling error which we were content with. We are confident we can improve upon this with richer clutter data which we are developing presently.
Results
1m LiDAR – It isn’t as useful as it looks
Using 1m LiDAR for the village we generated a sharp heatmap sensitive to chimney stacks and even parked vehicles which made for a very crisp result visually but the first-pass correlation with the field measurements showed it was conservative, which arguably is a safe default if you’re unsure.
The reason was a combination of trees and buildings. The village had trees on the green but due to the season, none were in leaf so signals would travel through them with relatively reduced attenuation. The LiDAR data however, regards a tree as a solid obstacle so results in an overly conservative prediction for measurements beyond the trees. Attenuation through buildings is a weakness of LiDAR in 2.5D RF modelling using this raster data.
You can show RF on the roof and if diffraction is calibrated, beyond the diffraction shadow as the signal hits the ground but not within the shadow itself where through-building signals reside.
LiDAR calibration showing a mean error of -1dB and a total RMSE error of 10dB.
The LiDAR result was improved with positive adjustments to the diffraction routine in SLEIPNIR, our CPU engine. As a result, diffraction is slightly more optimistic and the correlation with field measurements was improved.
The best LiDAR score, subtracting 3dB of receiver error was a modelling RMSE of 7.28dB.
DTM and Landcover – Better than LiDAR?
Using 30m DTM with layered 10m Landcover and 2m buildings, sampled at 5m resolution, higher calibration was achieved despite the loss of resolution. The reason is the Landcover offers through-material attenuation which can be adjusted to match field measurements. In this case, the “trees” and “urban” height and attenuation values were manipulated until coverage matched the results with high accuracy.
The best Landcover score, subtracting 3dB of receiver error was a modelling RMSE of 5.22dB.
Landcover calibration produced a better result – without breaking the bank
A / B comparison – LiDAR and Landcover
Using our calibrated settings, we extrapolated coverage out to 3km radius to model the whole cell. Here you can clearly see differences in coverage between the two data sets. With LiDAR, coverage is bouncing off hard tree canopies and casting sharp shadows on obstacles like hedgerows. With Landcover, we still have diffraction but more attenuation from obstacles which creates major nulls and also softer diffraction shadows, set by our clutter profile.
Lidar coverageLandcover coverage
A look forward
Findings from this field testing will be worked back into the CloudRF service in coming days, followed by SOOTHSAYER in due course, as new releases for our SLEIPNIR CPU engine, GPU engine and better default clutter values. We are developing sharper, and economically viable, global clutter data to improve on these scores, but won’t say how just yet 😉
We use cookies on our website to remember your preferences and repeat visits. By clicking “Accept”, you consent to the use of cookies.
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.