Clutter Archives

Posted on 2026-06-302026-06-30 by CloudRF

3D Tiles at the edge

Visualising the physical environment has never been easier, thanks to powerful end-user devices running mapping software with hardware acceleration. The latest step in the evolution of mapping is the shift from “2.5D” representations to full three-dimensional terrain and models. The OGC standard for this novel format is called 3D Tiles.

Making the jump from 2D to 3D has two key challenges: creating a rich 3D model and delivering it efficiently across bandwidth-constrained networks. Solve both, and the reward is a step change in situational awareness, especially for indoor or subterranean environments.

Creating models can be done in a variety of ways. Architects and Engineers have long used CAD software to produce precise design models. For smaller budgets, open source suites like Blender (which we have a 3D plugin for) allow users to build detailed 3D models which can be exported to open standards like glTF.

Beyond LiDAR

The start point for model generation is often a LiDAR scan. The entry price to this once exclusive technology has plummeted, and is now available on most smartphones with free apps. By converting large point-cloud data into mesh models, users can create models which represent the physical environment, including complex features that a map cannot convey, like tunnels, bridges, arches and mines.

Adding a vertical dimension makes this a cubed problem versus squared, which exponentially increases both the computational requirements and file size. This is a challenge found at every stage of 3D model creation and display. Working at the edge means pushing low(er) power hardware to the limit as processing LiDAR data demands intense computational effort. Once converted, the large model must be shared efficiently across a constrained network.

Advances in edge compute, resilient data networks, and open-standards have made creating, displaying, and sharing 3D models at the edge a practical reality, not just a possibility.

File formats

The integration of LiDAR sensors into commercial off-the-shelf (COTS) systems, including smartphones and UAVs, has greatly reduced the barriers to entry for LiDAR scanning.

The ability to capture LiDAR produces an accurate representation of the environment, something that is difficult to achieve with user-designed 3D models. For radio engineers interested in obstacles, high-resolution LiDAR scans often include unwanted clutter such as wires crossing a street or mine, which must be filtered out with post-processing, else they will compromise a 2.5D digital surface model.

Regardless of how a 3D model is created, it should be shared in an open standard.

Proprietary vendor formats place an unnecessary burden on operators, requiring specialist software, licence fees, or post-processing before a model can even be viewed, let alone used to solve a problem. Open standards remove that friction so a user doesn’t need to know how the model was produced; they simply receive something that works.

Examples of open LiDAR formats include OGC LAS/LAZ and e57.

3D model formats have evolved. Older standards such as OBJ and b3dm were designed for specific workflows and pipelines, not for streaming, distribution, or interoperability at scale. Styling is often separate from geometry.

GLB, the binary form of the open glTF 2.0 standard, solves all of this. Geometry, textures, and materials are packed into a single binary file, making models compact, self-contained, and ready to stream.

Side-loading a model

Models can be side-loaded as the older B3DM format and newer GLB format as well as 3D Tiles. If you come across 3TZ in the wild it’s just a zipped folder containing OGC 3D Tiles and can also be left as .zip. Side loading 3D Tiles allows the structure to be read locally from the phone’s SD card instead of a remote web server.

Streaming a model

Pre-loading models locally onto the End-User-Device (EUD) has been the de facto standard for years, but it comes with several limitations; First, the local model is limited to the device it is stored on, so sharing a large model over the network to every client that needs it would be impractical.

To share 3D models reliably in a contested or bandwidth-limited radio environment, a client-server model is used, which mirrors how mapping is distributed with WMS and WMTS tile pyramids with zoom levels set by a user’s viewport.

Our investigation into the subject of creating 3D tiles started with the work produced by Bert Temme (https://github.com/bertt/cesium_3dtiles_samples/tree/master), whose work has explored the various open standards of 3D models and their compatibility with a 3D tiles pyramid as used and defined by the popular Cesium 3D globe.

Getting 3D models to render correctly within ATAK using 3D tiles involved plenty of trial and error, as the implementation and standards involved are complex and feedback on issues is minimal. The tileset.json file is the critical index that tells a 3D Tiles client what to load, where to place it, and how to present it.

Without a correctly structured tileset.json, a standards compliant GLB will not render in ATAK. Check your tileset.json

Through testing, it was found that ATAK’s 3D Tiles client requires the asset version to be declared as 1.0. Tilesets structured to the newer 1.1 specification were observed to be unreliable at the time of writing despite being supported in desktop viewers such as CesiumJS. This is assessed to be a temporary issue as 3D tiles in ATAK is under active development. An update was provided at the 2025 TAK offsite.

The minimal tileset.json that produced consistent results within ATAK consisted of three key components:

An asset declaration at version 1.0
An ECEF transform matrix to position the model correctly on the globe
A sphere bounding volume defining the spatial extent of the content

Throughout this entire process, no licensed software or paid tools were required. By building exclusively on open source software, the workflow can be replicated by anyone.

Case Study – Photogrammetry 3D Model

The model used for this first example is a model from David Fletcher, https://sketchfab.com/artfletch, which is a photogrammetry model containing 1.4 million training images, 716.9 thousand vertices, and a file size of 71MB.

The GLB model was processed into 3D tiles with this Python script:

python3 GLB-to-3DT.py brathwaite.glb ./output/ --lat 51.523076 --lon -0.075226 --centre --compress --hag 60 --ground-snap

This model has no geographic references anchoring it to a specific area. Therefore, when processing the model, we had to manually assign it’s posistion on the map. This can be done through the script through the -lat and -lon flags for WGS84 co-ordinates. The elevation above the ground in meters is assigned with the –hag variable.

The original model’s origin was offset from the model, using the script, the origin in all planes can be centralised. This was done with the –centre flag. The ground-snap flag is then used to place the origin at ground level. For obstacles such as tunnels, it is recommended to place them above the terrain on the map. A mine floating above the mountain is easier to explore than beneath the map!

The –compress flag enables Draco compression, a relatively new and powerful feature supported by ATAK. By using the tiling process, sub-tiles measured in Kilobytes are created and are only rendered when required.

Stream 3D tiles to ATAK

A common web server can host 3D tiles. The hardware required is minimal, like a small board computer (SBC). They can be dropped into a folder within the web root (public_html/www/) so HTTP clients can access them. For our testing, we used Python’s built-in web server.

Navigate to the output directory created by the 3D Tiles pipeline script and run the following command:

python3 -m http.server 8080

This starts a simple HTTP server on the computer which can be accessed over the network.

The 3D Tiles folder can now be accessed from a web browser from any connected device, confirming that the tiles are being served correctly. The server’s terminal will show GET requests from web clients.

From within ATAK, select Maps.

On the bottom ribbon of the plugin menu, select the Map Source to Online, then expand the drop-down menu next to this. Press the Add (Cross) icon and enter the full URL to the tileset.json file. If your server’s IP address is 192.168.1.3 the URL would look like http://192.168.1.3:8080/tileset.json

ATAK will query the link and ask to confirm adding the new layers to the map. To confirm the tile source, check the checkbox next to the tileset.json then press OK.

Navigate to where the model is located within ATAK. When the area the model is located in is viewed, the model will begin to load at various zoom levels.

Imported models are listed in the models section within ATAK’s layer manager and can be toggled. It’s worth noting that local and remote models are indistinguishable here, so you may accidentally generate network traffic when you do not intend to.

At the web server, GET requests from the EUD will be visible and follow a predictable pattern: First the tileset is queried, then the top “leaf” levels are fetched, followed by root.glb and then mid zoom levels as a user explores into the model.

Case Study – Third Party 3D Tiles

Tiles which are already geographically referenced, like Google Maps 3D Tiles, require less processing to function as a mapping layer in ATAK.

For this capability demo, we streamed third-party hosted 3D Tiles using the BLOSM plugin in Blender, which can export directly to GLB.

The GLB to 3D tiles pipeline is run with the following command:

python3 GLB-to-3DT.py data.glb ./output/ --bbox 60.15184 24.91442 60.17965 24.96386 --compress

With a Geo-referenced GLB source like this, there is no need to declare latitude and longitude explicitly, as the bounding box used in BLOSM is passed directly to the pipeline. The same approach applies regardless of where the 3D tiles were sourced; as long as you have a valid bounding box, the pipeline handles the rest.

This method uses open source tools throughout.

To use commercial map tiles as a mapping source, you will likely need an API key for the vendor, and care should be taken to respect the Terms of Service, which may prohibit data scraping and hosting. Check if unsure.

Case Study – LiDAR scan for a mine

The next model is a LiDAR scan captured on an exercise lane at the Tough Stump Rodeo 2026.

Part of the challenge for the lane was to map the tunnel and communicate it back to a remote HQ. This was not easy given the very limited bandwidth. It was clear that edge processing would be needed, so only key information like dimensions and some highly compressed video could be shared, not all the raw scan data.

The LiDAR scan was generated using the Cleo Robotics Dronut, which exported to the open e57 point cloud format. A point cloud contains an extreme amount of information, which makes it a very large file.

Point cloud data needs to be meshed to make a model with a process known as triangulation, which involves noise removal and smoothing of surfaces. This was especially challenging given the old mine’s rough earth walls and supporting beams.

When working with point cloud data, the first step is to visualise the point cloud in a tool such as CloudCompare, developed by Daniel Girardeau-Montaut. Visualising the data first allows you to assess its quality before committing time and compute to processing.

Point cloud data commonly contains noise and outliers, and LiDAR scans in particular can carry multiple returns per pulse, dust, or secondary surfaces that add unwanted complexity to the dataset. By assessing the data upfront and stripping out spurious points and unnecessary returns, you can significantly reduce processing overhead and improve the quality of the final mesh.

Point cloud scan reviewed in CloudCompare

Once the point cloud has been assessed and cleaned, it can be meshed. There are several ways to approach this, depending on your environment and requirements.

For users who prefer a graphical interface, tools like Blender and CloudCompare allow the user to be hands-on throughout each stage of the process. The trade-off is scalability, GUI-based workflows are manual by nature, well suited to one-off conversions or exploratory work, but difficult to integrate into an automated pipeline.

For users operating at the edge where time, attention, and compute are all limited, an automated pipeline that runs in the background offers a clear advantage, freeing the operator to focus on other tasks while processing runs unattended.

After evaluating a range of tools, Open3D SDK was selected for meshing the mine dataset. Open3D operates without a GUI and supports two meshing algorithms: Poisson surface reconstruction, which produces smooth, watertight meshes suited to enclosed environments, and Ball Pivoting, which stays closer to the raw point data and preserves sharper detail but can struggle with uneven point density.

The script used for processing the mine data is available below. Features that also made it into the script included flexibility with declaring the max number of points to be processed, as we encountered issues with integer limits.

These variables can be adjusted by the user to find good variables to get the best results from their point cloud data with the hardware i.e. LiDAR camera, processors, and time and network restrictions.

For reference, the point cloud data used for this model is 243MB and contains no fewer than 22e6 points.

The low-resolution model used the following command:

python e57_to_mesh_glb.py input.e57 output.glb --max-points 500000 --depth 8 --density-pct 10

The process was completed on a laptop with an Intel Core i7-1255U CPU on battery power within a minute. The script has been built to use CPU only to cater for the large number of edge devices which have no or limited access to a GPU.

The GLB model shown above was generated using the lightweight processing settings, tuned to run within the constraints of edge hardware. The GLB model is 742kB in size, a large decrease from the original scan. Whilst the reduced point count and lower Poisson depth introduce some gaps in the surface geometry, particularly in areas of lower scan density, the model still conveys a clear and usable representation of the mine’s layout.

For the tactical user, this level of fidelity is sufficient to support meaningful pre-mission planning. The tunnel structure, directional changes, and spatial dimensions of the environment are all discernible, allowing operators to identify key decision points such as choke points, junctions, and viable radio relay positions before entering the environment.

The ability to generate even a lightweight 3D model at the edge, without dependence on cloud infrastructure or high-end workstations, represents a significant capability step. A basic understanding of an underground environment, derived from autonomous scan data streamed over a MANET network, can meaningfully reduce the unknowns facing a team preparing to operate in a GPS-denied, comms-constrained space.

A high-resolution model was also created. The command used for the script was as follows:

python3 e57_to_mesh_glb.py scan_fixed.e57 output.glb   --max-points 22000000   --depth 12   --normals-nn 30   --density-pct 5

This was processed on a server with a higher spec, including an Intel Xeon Silver 4116 CPU. The process to convert the e57 to a mesh GLB took just under two hours. The GLB produced from the script has a file size of 286MB, significantly larger than the lower resolution model!

Cross section of the mine converted at high resolution

The higher resolution model captures the interiors of the mine to a much finer degree of detail, with overhead supports and the carved out walls being visible. This detail will present a lifelike representation of the mine and allow operators to do a virtual walkthrough and identify physical obstacles such as debris and the ground underfoot.

Comparison of low and high resolution models

Comparing the two models, we can see that the overall geometry of the model is consistent between both, with the layout and structural features being present. The higher resolution model has a greater level of detail, retaining the full extent of the mine shaft where the lower resolution model loses definition towards the extremities.

The GLB to 3D tiles we used were produced in the following way to produce the tiles and place them appropriately:

python3 GLB-to-3DT.py mine-scan-compressed.glb tiles/ --lat 45.49836 --lon -112.04337 --hag 50 --ground-snap --compress --centre --height-ramp

LiDAR scan-derived model viewed in ATAK with FPV controls

The –height-ramp flag has been used in this command to aid in visualising the uncoloured LiDAR scan.

Scripts

The following scripts have been published to assist with data processing. All are available for free to advance progress in this exciting space, which we stand to exploit with our 3D engine. If you find any of these helpful, please consider giving them a star on Github 🙂

Link: https://github.com/Cloud-RF/3D-tiles-blog

LiDAR e57 to GLB script

Converts an e57 standard LiDAR point cloud file to a GLB model (Triangulation)

Link: https://github.com/Cloud-RF/3D-tiles-blog/tree/main/e57toGLB

GLB to 3D Tiles

Converts a GLB model to OGC 3D Tiles for use with ATAK.

Link: https://github.com/Cloud-RF/3D-tiles-blog/tree/main/GLBto3DT

3D Tunnel builder

Developed as a contingency tool to make a clean model using limited information in the event point cloud data is unavailable.

Link: https://github.com/Cloud-RF/3D-tiles-blog/tree/main/Tunnel-builder

Demo data

These demo files work with ATAK.

3D Tiles for an urban tunnel:

https://github.com/Cloud-RF/3D-tiles-blog/tree/main/GLBto3DT/output

Mine model with Draco compression:

https://github.com/Cloud-RF/3D-tiles-blog/blob/main/files/mine-scan-compressed.glb

Summary

Through this journey into new standards, we have implemented our own OGC 3D Tiles 1.1 endpoint for terrain and clutter, which dynamically renders terrain and obstacles from local data. This takes us from 2.5D to true 3D without dependencies on third party providers or a network connection.

Initially, the endpoint will be used in our next cross platform interface for RF planning, but as an OGC standards based layer, it can be used on third party apps.

The two trending open standards which make this possible are glTF for rich textured models and 3D Tiles for streaming large models to clients.

Posted on 2025-07-032026-01-20 by CloudRF

Improving accuracy in the trees

Summary

We have optimised how our engines model attenuation and diffraction to improve accuracy and performance within forests (and buildings).

Highlights

20% accuracy improvement with clutter
6.8 dB RMSE error for NLOS simulation (1.6 dB accuracy gain)
78% GPU speed increase with clutter
Better performance for radios within trees

Evolution of attenuation and/or diffraction

When a radio signal hits an obstacle such as a building, it attenuates through the obstacle and diffracts over the obstacle. Depending on the dimensions of the obstacle, a received signal beyond it could be from attenuation, or diffraction or a bit of both. It’s hard to tell. If you can’t get a phone signal behind an obstacle but walking away from it gets you a bar that’s diffraction. If you can improve a signal by walking into the obstacle, that’s likely attenuation.

Since 2020 we have offered configurable clutter and an increasing number of advanced diffraction models such as the fast Bullington approximation and it’s more sophisticated relative, Deygout 94. To address the challenge of simulating both the direct and diffracted rays, we implemented conditional engine logic for obstacle types such as trees and buildings so they would function differently: A forest would diffract and a building would attenuate, for example. This makes sense commercially as there is normally more money and people in a city than a forest.

The conditional logic added complexity and created visual artefacts so was replaced with dominant diffraction as most field measurements, and empirical models, are made on roads with diffracted signals. Our compromise for simulating within and beyond obstacles was to offer a DSM/DTM choice so users can chose to study rooftop LOS (and diffraction) with LiDAR where it’s available or focus on attenuation inside the material, but not both together until now.

Rethinking trees

We chose to make diffraction dominant with attenuation used for the face of an obstacle and in relatively low land cover. This resulted in “hot LiDAR trees” with a good signal across the canopy which is optimistic when your network is under the canopy but the obvious artefact justified the diffraction modelling beyond them. It also made good sense for urban rooftops where static communications equipment is installed.

In 2023 we challenged popular misconceptions that LiDAR is better for accuracy with a DTM/DSM field test where we achieved higher accuracy with calibrated clutter than precision LiDAR. This holds true for NLOS signals.

We proved the accuracy of the design choice with LTE and UHF field tests around mountains, buildings and trees but were conscious that a field test inside a forest would not be as accurate as whilst some RF would scatter from the canopy within a forest, this phenomenon was not nearly as reliable for planning as a nominal value per meter based upon the vegetation type. For example, a wet jungle attenuates more than most.

Now we can model both rays without compromise which for DTM produces visually different results. Previously, a building roof or tree canopy in DTM + Buildings would have been hot but now will be cold, or non-existent, since the receiver is within the obstruction and attenuation is being applied consistently throughout the obstacle (and prior obstacles).

Coverage through and beyond trees and buildings with attenuation and diffraction

Reverse engineering a forest

There are many historic studies into vegetation and material attenuation which have been summarised within a standard, ITU-R P.833. The ITU recommendation provides a useful reference for appropriate attenuation figures (dB/m) for varying wavelengths but does not prescribe a value for every material in every season. The best way to improve upon this is using field test data with calibrated clutter.

First, find two paths that go through and beside some uniform trees, eg. a wood block, on level ground. Calibrate the model so the clear path (B) beside the trees aligns with simulations and then note the difference of the obstructed path (A) eg. +30dB attenuation loss.

Comparing two radio paths to identify vegetation attenuation

Using the difference in decibels divided by the depth of the trees you can compute a nominal attenuation per meter and adjust your clutter profile accordingly. In our experience, this is the best way to get to an accurate, regional, nominal value that works well for other paths providing the trees are similar. Looks can be deceiving as mature trees often have higher leaf canopies so may permit more RF than you might think!

The expected range for vegetation attenuation is 0.03 to 0.5dB per meter.

Dilution by diversity

Across a wide area there will be different types of vegetation. When using space based land cover data, like ESA Worldcover, the classification is an approximation eg. “Trees” or “Shubland” with the net result that the best overall attenuation value will be lower than the nominal value for a single type. For example, a northern pine forest may have an attenuation value of 0.3dB/m but when used in a larger context with different vegetation types, the best value may be 0.03dB/m.

The key to getting this tree/building figure right for an area is having a large amount of diverse survey data.

Calibrating for success

We used OFCOM spectrum data for the UHF 450 band to prove the accuracy of our refactor and were pleased to improve upon our accuracy scores and speed. The lower UHF band was chosen as it would have the most penetration which is a notably more expensive problem to compute than a LOS viewshed.

The chosen data set is on the outskirts of a coastal city covering hills, forests and has over 10e3 samples taken by vehicle. We load this data into our calibration tool within our web interface and make appropriate clutter adjustments to tighten up the score. In our experience, you can fit the General Purpose model to most frequencies if you focus on adjusting the clutter instead of the model. Recomputing the 16 million point model takes several seconds with a GPU.

Results

The results show a 1.6 dB improvement (20% better than old score) in accuracy and a 78% speedup for GPU calculations with clutter. The CPU refactor is 1.8 dB more accurate but slower when clutter is enabled. Both engines will now show reduced coverage when working with clutter in NLOS regions but will look the same for where there is LOS or no clutter.

Test	Old	Refactor
GP model with Deygout 94 diffraction 16MP resolution DTM, Landcover, Buildings GPU Engine (RTX3050)	Elapsed: 11.7s RMSE: 8.4dB Coverage: 82%	Elapsed: 2.6s RMSE: 6.8dB Coverage: 56%
GP model with Deygout 94 diffraction 16MP resolution DTM, Landcover, Buildings CPU Engine (Ryzen 9, 8 threads)	Elapsed: 24.1s RMSE: 9.2dB Coverage: 84%	Elapsed: 33.7s RMSE: 7.4dB Coverage: 71%
GPU Multisite DTM, Landcover, Buildings 4MP resolution, x3 sites	Elapsed: 4.3s	Elapsed: 1.6s
CPU path, 20km DTM, Landcover, Buildings	Elapsed: 0.133s	Elapsed: 0.142s
CPU path, 20km DTM	Elapsed: 0.07s	Elapsed: 0.07s

Table of results

Summary

This optimisation will change how heatmaps appear for DTM and clutter, especially around buildings which will change from hot to cold. The improvement to accuracy for both CPU and GPU is notable and we can now offer much better planning for radio users within forests as a result.

All propagation models, including ITM, will be adjusted when clutter is enabled for future calculations only. Legacy calculations are unaffected and users can choose to disable clutter or minimise the amount of change with the Minimal.clt (default) clutter profile.

For simulations using DTM or DSM layers only there will be no difference.

The change does not affect DSM mode so LOS studies of rooftops will be unaffected.

Look forward

Expect to see a field test in a forest.

We’ll buck the trend of collecting data from the comfort of a car and go off-roading to investigate VHF/UHF attenuation in trees. This data will help us refine our clutter profiles so we can offer better defaults.

Posted on 2023-02-202023-02-20 by CloudRF

Calibrating beyond line of sight RF modelling with field testing

Summary

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

“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.

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.

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.

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 😉

Posted on 2022-06-152022-06-15 by CloudRF

System updates – June 2022

We’ve been busy as always improving our service. Here’s a visual roundup of updates we’ve pushed recently for API version 2.9 and UI version 2.8, current as of the 13th June 2022.

For the latest updates click the versions in the corner of the interface.

New features

Variable building heights

Our global building data has had a lot of attention recently from 5G operators and (counter) drone companies.

Previously you could use a mixture of sources to define a building from manipulating your clutter profile values to adding your own as GeoJSON or KML. Our third party buildings which we offer as an enrichment option in the Landcover menu were lacking height data so we used a user defined value from the clutter profiles. For many users on default settings, this resulted in buildings at 6m height, adequate for a suburb with similar architecture but no use for a vertical city like Chicago.

Our building data now has unique heights and we’ve modified our clutter system to match it. Our SLEIPNIR engine could already handle user defined height data due to previous modifications around custom clutter.

In the CloudRF UI, you can define the 9 system codes and only 9 custom codes.

Customers with private servers can define up to 255 clutter codes in clutter files on their system.

Diffraction for 3D clutter

Previously we modelled single knife edge diffraction only for the surface model, and considered through building attenuation for the clutter but now we can do it for clutter.

In the screenshot below, the COST model is used with 3D clutter for a suburb with a treeline along a train track. Both the buildings and trees are displaying diffraction, recognised by a shadow beyond an obstacle which gradually comes back into coverage as the obstacle angle decreases.

DTM option instead of LiDAR

We’ve worked with LiDAR in modelling for years and its great but has its limitations, especially with non line of sight communications where LiDAR will show a strong signal for the roof of a building and produce a very conservative “shadow” immediately behind an obstacle until knife edge diffraction kicks in.

Being conservative in RF planning isn’t a bad thing but with proper building height data we can enable more accurate through-building attenuation in cities, worldwide.

Nothing beats LiDAR for LOS analysis so we’ll still consider requests for uploading public LiDAR but for most of the world where there isn’t LiDAR, we now have an improved solution.

For rooftop planning, we recommend LiDAR but for through building/tree modelling at ground level use calibrated clutter instead. You can enable this option in the Clutter menu.

You can access this mode in the interface “Clutter” menu or in the JSON API with {clm: 2} in the environment object.

Delete-all custom clutter

API users can now delete all their custom clutter by requesting to delete id=0. This will soon be added to the UI with a button.

Added my-metrics endpoint for API usage

We’re now logging metrics for all the analytics APIs which count against your API use. We have an API to generate charts and will soon add client side charts so you can see how your API use breaks down by tool and time.

Automated testing

Testing is a critical part of maintaining our quality of service which is becoming increasingly complex. We’ve added automated workflows to our development environment to help catch bugs earlier and complement the manual interface testing.

This is implemented for the API and UI repositories at the code function level as well as our regular regression testing at the API level and now third party automated exception handling.

Improvements

Conditional terrain smoothing

We’re smoothing terrain for those super sampled locations. For example if you went to Africa which is mostly 30m DTM, and requested a 2m plot, we would be super-sampling the DTM by a factor of 15 which used to result in ugly artefacts on hillsides. We’ve fixed that and are able to have smooth hills and precision 2m clutter in remote areas 🙂

Rwanda with super sampled 30m DTM and 2m buildings with diffraction

Up to 255 clutter codes

In the CloudRF UI, you can define the 9 system codes and only 9 custom codes but the backend system supports up to 255 unique classes of clutter. You set the height and density for each so this could be skyscrapers for a city or crops.

Customers with private servers can define up to 255 clutter codes in clutter files on their system.

Diffraction loss adjusted down by 3dB

Following feedback from Mountain rescue teams using our service who were surprised to find coverage in modelled dead spots, we investigated our diffraction model and found it was too conservative by at least 5dB. We’ve adjusted the loss it applies down by 3dB so it’s now more optimistic, but still cautiously conservative.

Extended southern limit to -89N

You can model on Antarctica now. We don’t have DTM there so it’s flat as far as our service is concerned but if you are using the Satellite tool, this now works on the continent for testing for the horizon on a route etc.

Fixes

Replaced source for 3D buildings from a commercial supplier to Openstreetmap.org
Points requests was failing to handle some responses from the engine
Returning correct HTTP status codes for errors now
Template list is returned as JSON in the UI
Template authentication has been upgraded to the header “key”
Credits balance was reported incorrectly for some API calls
Remote tile fetching was corrupting some local tiles
Sanity check unworkable paths before passing into engine (eg. 1m or 1000km)
Some JSON responses malformed
Splicing of points near the Rx in a points request works better for a figure of 8 route.
Preferences was breaking if no lat or lon set
Performance improvements to “sea tiles” used for offshore planning.
Changed noise floor validation to -130 to -50dBm
Fixed issue with some interference API calls missing id values

Posted on 2021-11-122026-01-29 by CloudRF

Enhancing accuracy with environment profiles

In radio planning, accurate terrain data is only half the story.

The other data you need, if you want accurate results, is everything above the surface such as buildings and trees.

This is known as land cover or in radio engineering; clutter data.

Clutter data

In October 2021, the European Space Agency released a global 10m land cover data set called WorldCover with 9 clutter bands.

In our opinion, the ESA data is a sharp improvement on a similar ESRI/Microsoft 10m land cover data set also published this year.

The land cover can be used to enhance coarse 30m data sets to distinguish between homes and gardens, or crops and rivers. It’s space mapped so has every recent substantial building unlike community building datasets which can be patchy outside of Europe.

This data was previously very expensive. A price reflected in the eye watering pricing of legacy Windows^TM planning tools.

The data has 9 bands which have been mapped to 9 land cover codes in Cloud-RF^TM. Combined with our recent 9 custom clutter bands, we have 18 unique bands of clutter which you can use simultaneously.

Read more about the codes in the documentation here.

Explore the data we have on the ESA WorldCover viewer application here:

https://viewer.esa-worldcover.org/worldcover/

Custom clutter enrichment

We have integrated the 10m data into our SLEIPNIR^TM propagation engine which as of version 1.5, can work with third party and custom clutter tiles simultaneously, in different resolutions.

This is significant as it means you can have a 30m DSM base layer, enhanced with a 10m land cover layer, enriched further with a 2m building which you created yourself. Effectively this gives you a 10m global base accuracy with potential for 2m accuracy if you add custom obstacles. The interface will let you upload multiple items as a GeoJSON or KML file.

Demo 1 – The Jungle

Always a tricky environment to communicate in, and model accurately due to dense tree canopies. In this demo, a remote region of the Congo has been selected at random for a portable VHF radio on 75MHz with a 3km planning radius.

This area has 30m DSM which out of the box produces an unrealistic plot resembling undulating flat terrain. This is because the thick tree canopy is represented as hard ground and the signal is diffracting along as if it were bare earth. The result therefore is that 3km is possible in all directions.

By adding our “Tropical.clt” clutter profile, calibrated for medium height, dense trees, we get a very different view which shows the effective range through the trees to be closer to 1km, or less, with much better coverage down the river basin, due to the lack of obstructions.

Demo 2 – A region without LiDAR

Scotland has very poor public LiDAR compared with England which has good coverage at 1m and 2m.

For this demo, Stirling was chosen which has 30m DSM only. A cell tower on a hill serving the town produces an optimistic view of coverage by default but when enhanced with a “Temperate.clt” clutter profile, calibrated for solid and tall town houses and pine forests (eg. > 50N, Northern Europe, Northern USA) we get a much more conservative prediction. As a bonus, the base resolution has improved three fold to 10m.

Demo 3 – A region with 2m LiDAR

You might think if you’ve got high resolution LiDAR data that’s enough. Wrong. Soft obstacles like trees especially will produce excessive diffraction as if they were spiky terrain. This manifests itself as optimistic ‘great’ coverage due to the diffraction coverage. By adding our “Temperate.clt” profile again we make trees absorb power and see where there are nulls in our coverage – beyond the houses and woods.

Despite our land cover being only 10m resolution, we are able to benefit from the full LiDAR resolution with 2m accuracy.

Inspecting a profile

The path profile tool will now show you colour coded land cover as well as custom clutter and 3D buildings. Crops are yellow, grass is green(!), Trees are dark green, built-up areas are red, 3D buildings are grey, water is blue…

The most significant feature in this image isn’t the coloured land cover, or the custom building (as both are features we’ve done before), or the fact we know the tidal river Severn sits lower than the man-made Canal beside it, It’s the fact that both are being used in the same model at the same time. They are different sources, different resolutions, different densities…

Path profile for 860m link showing 2m LiDAR, 10m Land cover and 2m custom building

Using and editing a profile

Once you’ve got the hang of switching profiles you may find it needs optimising for your region. With the clutter manager in the web interface, premium customers can create their own profile based on field measurements for highly accurate predictions. After all no two forests or neighbourhoods are the same density.

Create your perfect profile and save it to your account. The system has 5 regional profiles ready for all users and you can add your own.

To use them, pick from the Clutter > Profile menu and ensure “Landcover” is set to “Enabled”.

If you have created custom clutter and want to use that, set Custom clutter to “Enabled” to blend it in.

For more see the web interface clutter section in the documentation.

Using clutter from the API

We played with a few designs before settling on this very simple template method where you set a profile within the environment menu as follows. This is a new value “clt” and you can still use the existing “cll” and “clm” values to manage the system clutter and custom clutter layers.

JSON request excerpt for a temperate “European” profile, with custom clutter, with 3D buildings and a 3D building density of 0.25dB/m

  "environment": {
        "clt": "Temperate.clt",
        "clm": 1,
        "cll": 2,
        "mat": 0.25
    },

Example for Jungle profile, without custom clutter, without 3D buildings.

  "environment": {
        "clt": "Jungle.clt",
        "clm": 0,
        "cll": 1,
        "mat": 0
    },

What’s next?

Now that we have highly configurable environment profiles. it’s time to tune them with field testing. We’ve bought a heap of comms equipment and will be using it to optimise these profiles with real world measurements.

Posted on 2021-06-112021-06-13 by CloudRF

RF penetration demonstration

During infantry training, soldiers are shown firsthand the impact of different weapons upon different materials to help them make better decisions about good cover versus bad cover. Spoiler: The railway sleeper doesn’t make it 🙁

As tactical radios have moved several hundred megahertz up the spectrum from their cold-war VHF roots, material attenuation is a serious issue which needs demonstrating to enable better route selection and siting. Unlike shooting at building materials it’s hard to visualise invisible radio signals, and therefore teach good siting, but equally important as ground based above-VHF signals are easily blocked in urban environments.

This blog provides a visual demonstration of the physical relationship between different wavelengths and attenuating obstacles only. It does not compare modulation schemas, multi-path, radios or technologies.

Bricks and wavelengths

Clutter data refers to obstacles above the ground such as trees and buildings. Cloud-RF has 9 classes of clutter data within the service which you can use and build with. Each class (Bricks +) has a different attenuation rate measured in decibels per metre (dB/m). This rate is a nominal value based upon the material density and derived from the ITU-R P.833-7 standard and empirical testing with broadcast signals in European homes.

A signal can only endure a limited amount of attenuation before it is lost into the noise floor. In free space attenuation is minimal but with obstacles it can be substantial. This is why a Wi-Fi router in a window can be hard to use within another room in the house but the same router is detectable from a hill a mile away.

The attenuation rate is an average based upon a hollow building with solid walls.

Common building materials attenuate signals to different amounts based on their density and the signals wavelength.

A higher wavelength signal such as L band (1-2GHz) will be attenuated more than VHF (30-300MHz) for example.

A long wavelength signal like HF will suffer minimal attenuation making it better suited to communicating through multiple brick walls.

The layer cake house

A brick house is not just brick. It’s bricks, concrete blocks, glass, insulation, stud walls, furniture and surfaces of varying absorption and reflection characteristics. Modelling every building material and multi-path precisely, is possible, given enough data and time due to the exponential complexity of multi-path but wholly impractical.

A trade-off for accurate urban modelling is to assign a local attenuation value. It’s local since building regulations vary by country and era so a 1930s brick house in the UK has different characteristics to a 1960s timber house in Germany. Taking the brick house we can identify the nominal value by adding up the materials and dividing it by the size.

For example, 2 x solid 10dB brick walls plus a 5 dB margin for interior walls and furniture would be 25dB. Divide this by a 10m size and you have 2.5dB/m. Using some local empirical testing you can quickly refine this for useful value for an entire city (assuming consistent architecture) but in reality the *precise* value will vary by each property, even on a street of the same design, due to interior layouts and furniture.

Range setup

We created nine 4 metre tall targets using each of the 9 clutter classes in attenuation order from left-to-right, measuring 10x10m and fired radio-bullets^TM at them from a distance of 300m using the same RF power of 1W.

The following bands were compared: HF 20MHz, VHF 70MHz, UHF 700MHz, UHF 1200MHz, UHF 2.4GHz. SHF 5.8GHz.

The ITU-R P.525 model was used to provide a consistent reference.

Only the stronger direct-ray is modelled. Multipath effects mean that reflections will reach into some of the displayed null zones, with an inherent reflection loss for each bounce, but these are nearly impossible to model accurately and in a practical time.

Here are the results.

HF 20MHz

VHF 70MHz

UHF 700MHz

UHF 1200MHz

UHF 2.4GHz

SHF 5.8GHz

Findings

Dense materials, especially concrete, attenuates higher frequency signals more than natural materials like trees
Lower UHF signals perform much better than SHF with the same power
Higher frequencies with low power can be blocked by a single house, even after only 300m
HF eats bricks for breakfast!

Summary

Modern tactical UHF radios, and their software eco-systems, are unrecognisable from their cold-war VHF ‘voice only’ ancestors in terms of capabilities but have an Achilles heel in the form of material penetration. To get the best coverage the network density must be flexed to match the neighbourhood.

This is obvious when comparing rolling terrain with a urban environment but the building materials and street sizes in the urban environment will make a significant difference too. Ground units which communicated effectively in a city in one country may find the same tactics and working ranges ineffective in another city with the same radios and settings. Understanding the impact of material penetration will help planning and communication.

Posted on 2020-01-202021-05-22 by CloudRF

DIY clutter

In this video, a Port in west Africa poorly served by high resolution data is enhanced with DIY clutter. The result shows substantial attenuation from the shipping containers which due to their dynamic nature would not be current in commercial data.

Summary

High quality clutter data is necessary for accurate radio planning but it’s not always available when and where you need it. Using the new ‘My clutter’ feature at CloudRF you can define your own and use it in seconds. The data can be layered on top of existing data, regardless of resolution, to enhance accuracy with material attenuation conforming to ITU standards for forests.

Clutter data

Clutter data in modelling refers to objects on the earth’s surface. In radio this is typically buildings and trees which attenuate signals. These must be factored in to deliver accurate predictions. It’s normally very expensive and the market for this data is worth billions due to demand by global telecommunications firms. This puts it out of reach of most small businesses and organisations.

Material attenuation

Different materials attenuate RF in different ways. The impact depends upon the wavelength (eg. WiFi can’t go through thick walls) and the material (concrete absorbs more RF than wood). For more on this subject see the land cover blog here.

How

Use the form in the ‘Model’ menu to either define your own polygons and lines or upload your own bulk clutter as a KML file containing polygons.

Why

Here’s a few reasons why DIY clutter is necessary:

Based on market pricing it would cost over a billion dollars to purchase ‘commercial’ clutter data for the earth.
Based on experience, the lead time for clutter in Africa can be 6 weeks.
The expensive clutter data is out of date by the time you buy it. Shipping containers, construction, transport will change and they affect RF coverage.
Commercial clutter data doesn’t let you model future construction projects eg. a new building

Posted on 2020-01-182021-05-22 by CloudRF

Modelling trees and buildings

Land Cover or ‘clutter’ data describes obstacles on the earth’s surface a radio wave will have to negotiate like trees or buildings. The Land cover data is layered on top of the terrain data which can be either a smooth(er) Digital Terrain Model (DTM) or a rougher ground-with-clutter ‘Digital Surface Model’ (DSM) . For DTM and DSM this will allow you to simulate attenuation from a forest or city where it might not otherwise be represented in the data resulting in much more accurate results. It also means you can enhance basic coarse terrain data with fresh high resolution land cover to reflect recent construction developments.

Obstacles and attenuation

Radio waves are attenuated differently by different materials like vegetation and man-made buildings. The impact varies by frequency with very short wavelength signals like WiGig at 60GHz struggling to penetrate a paper wall whilst a long wavelength VHF signal can breeze through multiple brick walls. For accurate modelling its essential that land cover is considered otherwise you run a risk of an unrealistic prediction which will bear little resemblance to real world results.

Trees

Trees attenuate differently with dense coniferous pine forests attenuating the most. An ITU standard, ITU-R P.833-7 “Attenuation in Vegetation” exists to describe the impact of a forest of different signals. There have been many academic studies into this subject but the summary of this standard for a mixed deciduous/coniferous forest is as follows:

Frequency MHz	Attenuation dB/m
106	0.04
466	0.12
949	0.17
1852	0.3
2118	0.34

No two forests are the same but if you err on the side of caution you can budget for their impact with a rule of thumb that 10m of mixed forest is equivalent to 2dB of attenuation at 1GHz, 4dB at 2GHz and 8dB at 4GHz. Trees are defined in the Land cover used by the system with attenuation values aligned to ITU-R P.833-7 which scale with wavelength so the same forest block will attenuate a WiFi signal more than a PMR446 signal. The resolution varies by region with 30m for CONUS, 100m for Europe and 500m for the rest of the world.

Buildings

Man-made buildings are even less predictable due to the variety in size, density and materials used. Many studies have been conducted into building attenuation but they are region specific due to construction materials and designs. A good reference is a UK paper by OFCOM which merges multiple research papers and has a useful table of attenuation by material and frequency on page 39.

Material	Attenuation dB/m at 1GHz	Attenuation dB/m at 10GHz
Concrete	24	>50
Brick	32	32
Plasterboard	11	>50
Wood	5	>50
Glass	3	44
Ceiling board	1	10
Chipboard	22	>50
Floorboard	4	>50

The system currently has four classes of building attenuation for high to low intensity developments. The attenuation rate is 1% of the solid material attenuation rate (eg. Brick is 32dB/m so a brick house in CloudRF is 0.32dB/m) since most buildings are largely hollow.

Land cover data

To enhance DTM and DSM models with 3D clutter, Land Cover data can be layered on top of the terrain to apply representative attenuation. This Land Cover data has been sourced from a variety of sources with up to 30m resolution. The total possible resolution possible is determined by the highest resolution data so if you are in New York City for example where there is 2m LIDAR / DSM data available, your effective resolution will be 2m.

30m Digital surface model	30m Digital surface model plus 30m land cover
2m Digital surface model (LIDAR)	2m Digital surface model (LIDAR) plus 30m land cover

Propagation models

Propagation models vary in complexity from the simple ‘one liners’ like the free-space-path-loss model to the incredibly complex Irregular Terrain / Longley Rice model. Most models are simple and must be used within their parameter limits (especially with empirical ‘measured’ models) otherwise you could get wildly inaccurate results. A good example is the well known Hata model which was designed for elevated cellular base stations serving mobile subscribers which were lower than it. If you use this model at the bottom of a hill you can get some incredibly unlikely results as the simple model has no concept of terrain only A to B. By using Land cover, the output from these simple models can be enhanced greatly to provide a result which is sensitive to changes in the terrain along a given path, similar to how the ITM model works.

	A UHF repeater at the foot of some hills with 20m DSM only. By default the Sleipnir engine will restrict coverage to line-of-sight for simple models like Hata.
	With knife-edge-diffraction enabled, the Hata coverage is free to roam beyond line-of-sight. The coverage becomes very optimistic to the west up in the hills as Hata has no concept of terrain and expects a clear shot from the base station to the mobile station.
	With knife-edge and 30m Land cover enabled, the optimistic Hata coverage is still free to roam beyond line-of-sight but is now severely constrained by the dense forests and urban developments without modifying the model itself.

Forest example

Modelling little forest blocks far away from your tower is easy with accurate DSM data but modelling a huge forest where your tower is within it is a harder problem. Heights are all defined as relative to the ground so if you have a 10m tall forest which is represented as raised earth in a DSM model and your tower is 12m tall you will end up with a tower which is in fact 22m above the ground – not ideal! Instead, when working with the 30m DSM you should define your height as the height above the canopy which is 2m. Here’s a comparison using 30m DSM and 30m Land cover in west Virginia.

Free space path loss prediction for an outdoor WiFi router, 30m DSM.

30m DSM plus 30m Land cover.

Urban example

To demonstrate the attenuation of buildings, this example has an emitter (LTE eNodeB on 800MHz) equidistant between a city and some countryside. The attenuation of the urban land cover becomes obvious once applied which contrasts with the open fields and water.

Free space path loss prediction for an LTE eNodeB, 30m DSM

Free space path loss prediction for an LTE eNodeB, 30m DSM with 30m Land cover

Summary

Land cover is essential for accurate planning and is now supported at 30m resolution. Coupled with high resolution data like 2m LIDAR, you can now accurately model attenuation of different materials in a cluttered environment. More land cover data is planned for the near future along with an upgraded ‘my clutter’ interface to allow you to define your own forests or housing developments for areas where data may not be available.