Posted on

Mapping mesh networks

Mesh network

Mobile ad-hoc networks (MANET) are an increasingly popular architecture in emergency services and Defence communications. Unlike classic repeater based networks, MANET radio network communications do not have fixed infrastructure so must form self-healing, self-routing networks.

MANET radio modules are well suited to working either off-grid away in remote areas or for providing resilience and independence in well served cities which may be suffering from power and/or network failure.

The bandwidth requirements and throughput of MANET networks varies substantially by waveform. Some are designed for range, others maximum throughput. For this reason, manufacturers offer a range of frequency modules.

Why RF planning tools don’t get used for emergency networks

RF planning software has evolved substantially in the 30 years it’s been used to build out fixed infrastructure networks. Time sensitive customers such as the emergency services have a difficult relationship with these tools. They need them, and often buy them, but don’t have the time to use them to their full capabilities. As a result they rarely get used on anything except training and exercises. Even then the numbers of staff directly interfacing with them will be very small, even in very large organisations of radio users.

The focus for most RF tools is planning with static sites. Whether that’s clicking on a map or uploading a spreadsheet of hundreds of locations it’s still static. MANET requires dynamic inputs and continuous computation which is where APIs come to the fore…


Cloud-RF’s latest API has a function designed for ad-hoc networks called ‘points’. The points API functions like a point-to-point profile in terms of it’s input and output except it accepts an array of transmitters. This means you can test 10,50 or 500 transmitter nodes back to a single receiver in a single API call. It’s also fast as you’d expect and can model a link every millisecond so the 870 distinct links demonstrated in the video were processed in under a second, every second.

For more information on the points API see our documentation here:

Radio mapping planning

In this video, we demonstrate the Cloud-RF points API to model a MANET network (Mobile Ad-hoc Network). For this demo 30 nodes were moved around a 16km track covering a variety of terrain. Each node was tested against 29 siblings for a total of 870 links per second.

Coloured links denote good (green) average (amber) and poor (red) links between the nodes and map to 5dB, 10dB and 20dB signal-to-noise ratios. Only links exceeding 5dB SNR are shown or it looks like a bad game of kerplunk!

The radio settings used were L band (1-2GHz) with only 1 watt of power. This conservative start setting was chosen to show a dynamic range of links. Later in the video the template is switched at the database to demonstrate the impact or gain of using different bands such as 2.4GHz and 500MHz.

Integrating your data

The demo video used mock data and an unpublished script to present the results as a KML. The source of the data is irrelevant so long as it’s accurate and time sensitive. This could be a radio vendor’s dashboard or database. Many of the leading vendors such as DTC, Harris, Persistent Systems, Silvus and Trellisware have location aware GPS modules and software interfaces to display reported radio positions.

The required format for a point is WGS84 decimal degrees. The height is taken from the template which is defined within the body of the points request. The new APIv2 makes defining a template easy as a JSON object so you can have a local archive of template .json files.

A suggested workflow for API integration for dynamic points is as follows:

  1. Fetch a list of all radio locations as decimal degrees
  2. Choose a template as a JSON object
  3. Make an API request using the data and a client script to
  4. Parse the JSON response to extract the results for each node
  5. Put the results on a map as lines
  6. Style the lines based upon your own local rules for your equipment, QoS and waveform eg. < 5dB is red

Download example client scripts from our Github site:

For assistance with integration and hosting options email

Autonomous vehicles

Where this points API will really add value is in mapping and assisting autonomous vehicles who are invariably fitted with MANET radio modules. Whether it’s a drone or a UGV, this API can be used to rapidly exercise multiple routes to help make better decisions.

Posted on

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-bulletsTM 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


UHF 700MHz

UHF 1200MHz

UHF 2.4GHz

SHF 5.8GHz


  • 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!


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

Modelling the Bit Error Rate (BER)

2400MHz_propagation_models When simulating radio propagation you can choose to model results in a variety of ways: Path loss will show you the attenuation in decibels (dB), Received Power will show you the signal strength at the receiver in dBm and field strength will show you the signal strength in micro-volts (dBuV/m). If you are using a digital modulation schema such as Quadrature-Amplitude-Modulation (QAM) your effective coverage will be dictated by the desired Bit Error Rate (BER) and local noise floor. This blog will describe these concepts and show you how to apply them to model a given modulation schema.

Bit Error Rate (BER)

The Bit Error Rate (BER) is the number of acceptable errors you are prepared to tolerate. This is typically a number between 0.1 (every 10th bit is bad!) and 0.000001 (Only one in a million is bad). This ratio is closely linked to the Signal-to-Noise-Ratio (SNR) which is measured in decibels (dB). A high SNR is required for a low BER. A low SNR will have an increased BER. Put simply a strong signal is better than a weak one and has less chance of errors. The reason error increases with SNR is because of noise. The closer you get to the noise floor for your band (about -100dBm at 2.4GHz), the more unstable and unpredictable things become.
DecimalExponentialLink quality
0.0110e-2Not bad
0.0000110e-5Very good

The noise floor

The noise floor is the ambient power present in the RF spectrum for your location, frequency, temperature and bandwidth. Understanding the noise floor is important when modelling Bit Error Rate as it is subject to change and will determine your SNR. The SNR will determine your BER so if you want good coverage you need to know your noise floor so you can set your power accordingly. There are several factors that influence noise floor:


A lot of noise if man-made so the noise floor is higher in a city than in the mountains. The difference varies not just by city but by country as countries have different spectrum authorities and regulate spectrum usage differently. The difference between a city and the countryside for a popular band like 2.4GHz is huge and can be over 6dB. Using a calibrated spectrum analyser with averaging is a good way to measure the noise floor. Ensure you set the bandwidth to your system’s bandwidth for best results. If you don’t own a spectrum analyser you can use Boltzmann’s Constant (see bandwidth section) and add an arbitrary margin to it depending on your location. This table has some suggested generic values:
LocationSignalNoise floor
Rural / RemoteWiFi 2.4GHz-101dBm
SuburbanWiFi 2.4GHz-98dBm
Urban cityWiFi 2.4GHz-95dBm
Rural / RemoteWiFi 5.8GHz-98dBm
SuburbanWiFi 5.8GHz-95dBm
Urban cityWiFi 5.8GHz-92dBm


Thermal noise is spread uniformly over the entire frequency spectrum but man-made noise is not. The 2.4GHz ISM band is much busier than neighbouring bands for example due to its unlicensed nature. As a result the noise floor is several dB higher than a ‘quieter’ piece of the RF spectrum. Some of the quietest spectrum is co-incidentally the most tightly regulated, which keeps users down, which reduces noise, and improves performance.


Thermal noise increases with temperature so in general you will get slightly more distance for your power in northern Scandanavia than in central Africa. The difference is about 1dB between a cold day and a hot day so can be considered negligible when compared with other factors. Budget for a hot day with an extra dB in your planning.


Bandwidth has a direct influence on noise power because of Boltzmann’s Constant. This simple formula lets you calculate the absolute noise from the bandwidth. There are different ways to apply the formula but if you use dBm then the simplest form is: Noise floor dBm = -114dBm + 10 Log(Bandwidth in MHz) Using this formula you get the following results.
Receiver Bandwidth MHzNoise floorEquivalent system
10-104dBmWiFi 10MHz
20-101dBmWiFi 20MHz
40-98dBmWiFi 40MHz
100-94dBmSpectrum analyser with 100MHz FFT
If in doubt, use a noise floor of -98dBm


A low power 20MHz wide 64QAM signal is being simulated in a city. The noise power is computed from the bandwidth with Boltzmann’s Constant as -101dBm to which we add +3dB for man-made noise putting the noise floor at -98dBm. When selecting a BER of 0.1 / 10e-1 the SNR is 11dB which equates to a receiver threshold of -87dBm.
The difference in propagation between the two error rates is noticeable with 64QAM but what happens if you switch up the modulation to 1024QAM which carries a higher SNR?
Posted on

Multi-resolution modelling

Multi res

12th December 2018

High resolution LIDAR data is great but its also limited in coverage and focused on urban areas generally. What happens when you need to see coverage beyond the city limits where coverage stops? What happens when you live in Cornwall? With the Signal Server propagation engine you can model LIDAR high resolution data but where the data has a void or stops entirely, you will receive an ugly hole in your coverage prediction or even worse a failure if the requested radius far exceeds the available LIDAR. To see wide area coverage without the voids a coarser resolution would need to be used which won’t have the detail of the LIDAR. Customers using CloudRF’s LIDAR capabilities occasionally report terrain data anomalies which upon closer inspection reveal voids. In the UK 2m LIDAR for example, this was flown by light aircraft in strips like mowing a lawn so its not uncommon to see nice coverage around a city but voids out in the country, especially in remote regions like Cornwall. A Cornish customer highlighted a region with some prominent voids which we used to develop a solution to this tricky problem. Previously Signal-Server worked with legacy SRTM DEM converted to the unique SPLAT! SDF raster format and then later ASCII Grid tiles but the two datasets could only be use exclusively. The solution required a fundamental re-design of the engine and its relationship with the data and is one of the biggest changes in the history of CloudRF…


‘Slayp-nir’: The fastest horse in Norse mythology, capable of traversing any terrain on eight legs. Working with senior C++ developer, Gareth Evans, the loading of data was re-designed from scratch to not only make it faster but format and resolution agnostic. By doing this from the outset, different text data sources could be rapidly loaded into memory to form a single, seamless elevation model. For urban LIDAR this means a city tile with voids at the edges can be layered on top of a 100km 30m DSM tile to fill voids. The step between the two formats is indistinguishable to the human eye. This benefits not only city planners frustrated by the unsightly hard edges at city limits but also the emerging DIY Drone LIDAR market where users might submit their own very small tile to CloudRF covering just a forest block for example. With this engine you can backfill the surrounding area to fit your high resolution 1m Drone LIDAR onto some lower resolution DSM like 20m for example. The changes required to make this solution could not be done by adding more code to Signal-Server which as a fork of the much older SPLAT! engine was becoming difficult to maintain and has well documented problems in its public commit history with handling rectangular LIDAR tiles or tiles which span the Greenwich Meridian. CloudRF has a long and proud history of using and supporting open source software, starting with SPLAT! in 2011 but this re-design and re-build from scratch allowed for a fresh licence. Sleipnir will not be open source and for this reason will not contain GPL licensed code from SPLAT! or Signal Server. It has faster, Intel CPU optimised, implementations of the same public domain models found in Signal server (ITM, Hata, COST231, SUI, ECC, Ericsson,ITU-R P.525) except for the ITWOM 3.0 model which has been excluded as its license and provenance is unclear.

Signal-Server LOS model

Sleipnir Free space path loss including LOS
A key difference in how Sleipnir’s models work is line-of-sight (LOS) analysis. With Signal-Server, LOS was an optional mode, comparable to a propagation model which meant basic models like ITU-R P.525 (Free space path loss) would continue to show coverage behind obstacles unless knife-edge-diffraction was explicitly enabled. With Sleipnir, LOS is factored into every model by default so you will always see the impact of obstacles. Beyond obstacle diffraction can also be modelled with optional knife-edge-diffraction. What this means for basic models is that you now get a result which combines line of sight with the model. Perfect for microwave links requiring a high SNR.

Case study #1: Patchy LIDAR, Cornwall

Tregony in Cornwall is served by three datasets presently: 90m DEM, 30m DSM and 2m LIDAR. The LIDAR covers the town but has a void to the north west and a giant vertical strip missing to the east. The 30m DSM covers everything because it was mapped from space but lacks the detail of the 2m LIDAR in the town. Using Sleipnir the town and surrounding area were modelled using the 2m LIDAR resampled to 5m and rural LIDAR voids were (automatically) filled with 30m DSM. Not only were the voids filled but due to the redesigned engine it was executed in a fifth of the time on the same processor.

Case study #2: Localised LIDAR, Sweden

Malmo in Sweden is served by 4m LIDAR but this is limited to the city centre only for now. Beyond the tile coverage falls back to 30m DSM. This scenario is common since LIDAR is expensive and difficult to justify beyond cities. It is also a problem faced by the DIY LIDAR market made possible by Drones and photogrammetry suites like Pix4D which you will see more of in the future.. When your drone has a 15 minute battery life your LIDAR tile isn’t going to take long to upload but as drones and laws improve this potential will grow.
Aside from the obvious difference with coverage beyond the tile limit, you may notice the propagation in the city is different also. This is because the basic models like Hata have all been enhanced to include Line-Of-Sight (LOS) as standard now.

Performance test: Signal-Server vs Sleipnir

Tests were conducted on an a hex core Intel(R) Xeon(R) CPU E5-1650 v2 clocked at 3.50GHz. Signal server used four threads and Sleipnir was limited to eight although can use n threads, hardware permitting. Times include image post processing conducted by the CloudRF service.
TestSignal-Server (seconds)Sleipnir (seconds)
30m DSM, 10km Path Profile1.2s0.1s
30m DSM, 10km radius5s2s
30m DSM, 30km radius34s12s
5m LIDAR, 5km radius29s39s
5m LIDAR + 30m DSM, 5km radius (Multi-mode)N/A44s
30m DSM, 50km radius95s27s
60m DSM, 100km radius8min2min

Integration status

Sleipnir is currently available in CloudRF with the new ‘model’ parameter. For API users, model=1 is Signal-Server and model=2 is Sleipnir. In the web interface the choice is easier in the model section. For now, Sleipnir is available for area coverage only with Signal Server used for path profile but we’re working on Sleipnir path-profile along with new ‘best server’ features to exploit its incredibly fast path profile capability.
Posted on

Uplink and Downlink

A popular question when modelling GSM / UMTS / TETRA / LTE networks is how can I show the coverage from the mobile subscribers (Uplink)? Showing a tower’s coverage (Downlink) is easy but how do you go the other way back to the tower? If you know your equipment capabilities (tower and subscribers) you can calculate link budgets for both the uplink and downlink and then use those values to perform an area prediction. Here’s a simple example with the GSM900 band and without some of the other gains and losses which can complicate this for the benefit of novices. You can always add in your own gains and losses where you like to suit your needs.

1. Calculate the total effective radiated power for the BTS tower by adding the power and antenna gain (Limited to 33dBm in the UK)

2. Repeat for handset (Limited to 23dBm in the UK)

3. Calculate the minimum receive level for the BTS by subtracting the receive antenna gain from the receiver sensitivity eg. -110 – 10 = -120

4. Repeat for handset

5. Calculate the maximum allowed path loss (MAPL) by subtracting the minimum receive level from the ERP.

6. Repeat for handset

A balanced network will have similar values. If your base station can radiate for miles but your handsets cannot you have an unbalanced and inefficient network.

Finally, to see this on a map, use the ‘Path loss (dB)’ output mode in CloudRF along with the ‘Custom RGB’ colour schema. Enter the uplink value into the green box and the downlink value into the blue box and run the calculation. A typical cell site will have a greater reach (blue) than it’s subscribers (green). The system will automatically factor in the effect of terrain, ground absorption, antenna heights to give you an accurate prediction.