Posted on

Keeping motorsport smooth


A CloudRF motorsport customer invited us to a track day to observe a peculiar RF problem… High resolution ‘dashcam’ video feeds have become standard in motorsport with multiple cameras present on vehicles and drivers. Unlike a consumer dashcam, these real-time video feeds use TV broadcasting radio links to relay a signal from the vehicle to the video processing facility via track-side receivers. The problem is Motorbikes with video feeds were experiencing RF difficulty on bends despite being close to high gain receiving antennas. This issue was investigated with the CloudRF API which revealed the following findings:

  • Lean angle has a direct impact on signal quality
  • Adjacent riders will attenuate signals
  • A bike at full tilt will experience antenna polarisation loss
  • Mast heights must be wavelength x (distance/4) to compensate for dynamic losses
  • Low masts, like tight boots, are terrible!

Doppler shift

The system must contend with several challenges; firstly the doppler effect caused by a shifting emitter. This effect is negligible at slower speeds but can cause reception issues as the vehicle increases speed and the frequency appears off tune. A superbike moving at 100mph would result in as much as a 5% shift in frequency which depending on the location of the receiver could be an increase or decrease of 1MHz. The effect can be modelled and managed with frequency tracking receivers designed to overcome this high speed issue.

Lightweight RF links

Weight is critical in maintaining a competitive edge so the RF links employed are low power emitters, using the vehicle’s native electrics. Licensing restrictions also limit the maximum allowed power output. The standard used in this case is ISDB-T which is an MPEG-4 H-264 high definition video stream which at full rate employs QAM-64 modulation. The H-264 quality High Definition (HD) video feeds people are accustomed to require a high signal-to-noise ratio of at least 20dB which is achieved by careful deployment of track-side high gain antennas and dedicated broadcasting spectrum at 2.3GHz. The system uses 7MHz of bandwidth (broken down into sub-carriers) which has an absolute noise floor of -105dBm. Adding the necessary 20dB SNR gives -85dBm which with the addition of 10dB of environmental (7dB) and receiver (3dB) noise gives a target threshold of -75dBm. The antenna on the motorbike is a shark fin, vertically polarised design mounted on the tail of the bike behind the rider. For the purposes of this investigation the antenna has been modeled with 1dBi gain and and an ERP of 18dBm / 65mW, equivalent to just under a consumer WiFi router. The video broadcast unit is concealed nearby within the bike’s tail with minimal cabling between the antenna for tidiness and maximum efficiency. The track-side antennas would be directional antennas with at least 10dBi of forward gain. These would be positioned at key points on the race track for maximum benefit. The siting of these antennas is where CloudRF is used to test options.


Using GPS data from races, it was found that there could easily be 8 motorbikes in a tight group on a bend. As the bikes all take the bend, several changes occur which all impair RF propagation, resulting in disruption to the smooth HD feed:

1. Rider attenuation

A significant change to consider is the increase in environmental attenuation caused by the crowd of riders. At 2.3GHz the human body will absorb 3dB of RF power. Assuming there are 3 bikes between the rider and the receiver this could be a substantial +9dB of attenuation – comparable to a brick wall (7dB) at this wavelength.

2. Antenna tilt

As bikes lean on a bend so do their vertically polarised antennas. As an antenna deviates from its optimal polarity (vertical) to horizontal it loses power up to 3dB at full tilt (90 degrees). If a bike is at half tilt, polarisation loss will cost the RF link 1.5dB.

3. Antenna height

Coupled with tilt, the height of the antenna above the earth will reduce from ~100cm to as little as ~50cm. This will reduce its effectiveness as more of the key fresnel zone will be attenuated by the earth. Using a fresnel zone calculator the fresnel zone radius for a 2.3GHz link over 300m is 3 metres. Elevating the track side antennas on masts is one way to overcome this issue but when one end of the link is so near the earth the (tower) elevation must be much higher than the fresnel radius if it is to clear the earth completely as these profile images demonstrate. Modelling using the Irregular terrain model which considers fresnel attenuation shows substantial loss caused by minor reductions in the (bike) antenna height. As you can see in the path profile below, the curved fresnel zone clips the earth which introduces attenuation.

Modelling the problem with the CloudRF API

The customer wondered if the issue might be identified through Monte-Carlo simulations whereby random inputs, in this case bikes, were placed on the track and the coverage mapped for comparison. This type of simulation is possible through the coverage API with custom client scripts and can help identify where to site receive antennas around a given track. After much deliberation it was realised that the benefit of area modelling would be limited in contrast to focusing on the impact of a bend on a single bike which could be adjusted for different lean angles and simulated crowds. For this study the Path Profile (PtP) API was used to focus on a short 300m straight line path between a bike and a mast, with variation to the inputs. The bike’s height was adjusted to simulate lean based upon a starting height of 100cm (Superbike tail height average) down to a minimum of 50cm when at full tilt. The impact of adjacent riders was simulated by adjusting the receiver gain downwards, in this case by 9dB to simulate 3 other riders. The significance of receiver height was demonstrated by adjusting the mast to clear the fresnel zone at this distance.


The following data was generated using the ITM model with transmission heights ranging from 1m (Bike is upright) to 50cm (full lean). The ITM model considers the effect of the obstruction of the fresnel zone which is the cone of power around the path of a signal. Measurements are based upon a mast 300m away, on flat earth, with a 9dBi sectorial panel antenna. The zone grows deeper as it travels so mast height must consider this as well as line of sight clearance.

3m mast

A 3m mast is higher than most vehicles and ground clutter but only for line of sight. At 300m the fresnel zone is 3.12m so this mast height is only high enough up to about 250m before power is lost as the fresnel zone is attenuated by the earth. Results show that without obstructions 3m is borderline as bikes lean and as soon as a bike is obstructed by another it falls below the target threshold, regardless of lean angle.

3 metre mast, unobstructed

3 metre mast, obstructed

6m mast

A 6m mast is a major improvement. Being well clear of the fresnel zone makes it able to handle a full 60 degree lean at 300m. Results show that without obstructions 6m is good for all scenarios and if a bike is obstructed by others it only falls below the target threshold by 5dB which could be recovered with a higher gain antenna or by siting the antenna closer to the bend.

6 metre mast, unobstructed

6 metre mast, obstructed

The results reveal the following common findings:
  • Lean angle has a direct impact on signal quality with a full 60 degree lean adding more than 6dB of attenuation
  • Adjacent riders can introduce substantial attenuation with 3dB per rider
  • A bike at full tilt will lose another 1.5dB in antenna polarisation loss
  • Receiver height must be at least twice the maximum fresnel zone distance to budget for these issues
  • Receiver distance must be sufficient to maintain the double fresnel clearance so a distant mast is OK providing it is high enough
  • Low masts, like tight boots, are terrible!

Ideal mast height

The ideal mast height is relative to the frequency. At 2.3GHz the wavelength is 0.13m which based on the 300m distance used must be multipled by 24 to clear the fresnel zone making the minimum mast height 3.1m. As tests have shown, this height is insufficient to handle dynamic losses from leaning and other riders so should be doubled. Based on data, the recommended minimum height for a mast covering bikes on a bend is wavelength multiplied by distance/4 which gives the following table.
Distance mHeight m

Scripts and data

Scripts and data used to generate this study are available here. To use them you will need to enter your CloudRF API credentials into the CSV files and run them as follows: python3 pathprofile_3m.csv For plotting to PNG charts you will need Gnuplot: gnuplot unobstructed.gnuplot
Posted on

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.


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.


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.


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

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 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 MHzAttenuation dB/m
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.


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.
MaterialAttenuation dB/m
at 1GHz
Attenuation dB/m
at 10GHz
Ceiling board110
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


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.
Posted on

Modelling the Bit Error Rate (BER)


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

Simulating Jamming

Jamming is a form of electronic attack which uses a stronger signal to disrupt target wireless devices. DISCLAIMER: It is an offence to intentionally interfere with someone else’s use of the wireless spectrum in the UK. The mention of its name also disrupts rational thinking amongst otherwise intelligent people and its common for spectrum planners and event managers to ignore signal theory when discussing its impact and revert to hollywood instead. Originally used in warfare, it’s now commonly used in civil emergencies such as event protection, bomb disposal or hostage negotiation. This blog uses modelling evidence to demonstrate the impact of jamming in a city and in the process, debunk popular jamming myths. The target band in all models is the 2.4GHz ISM band which is easily the busiest unlicensed band in the world and home to WiFi, Bluetooth, CCTV, Locks, Sensors, Drones and phones. The chosen location is Regent’s Park in London which is a large open area in the busiest part of London, surrounded by tall town houses. The antenna used is Omni-directional to visualise the effect in all directions.

Jamming thresholds

IEEE standard protocols such as 802.11 have defined thresholds for Energy Detection (ED) above which they will not transmit. If you can hit this threshold then devices will refuse to transmit and can be considered ‘jammed’. For 802.11 the energy detection threshold is -62dBm which is a strong wireless signal. You would need to be in the same room as the wireless router to see a signal this strong so to be effective you must be close or just be very very powerful like a military airborne jammer.

Power limits

In Europe the power limit for 2.4GHz is 0.1 Watt or 20dBm which is what a domestic Wi-Fi router radiates. This is low by design to minimise interference, conserve battery and enhance privacy against eavesdropping. In the US it’s higher at a generous 1 Watt / 30dBm which still works since everyone is even when competing for channel access, just on a bigger scale. Jamming someone within this limit is hard. You either need to get very close (~10m) or use a directional antenna. For jamming of a wide area like the whole park and beyond you would need hundreds of watts of power. You can deliver this efficiently with a directional antenna and reduce collateral damage in the process but jamming a wide area with a ground based jammer requires an enormous amount of power.

Simulating jamming

The key setting for simulating the effect of jamming is the receiver threshold. Creating a radio coverage map with a ‘normal’ threshold like -90dBm would not be useful unless you were intent on producing a misleading result to support an argument against using jamming. For an accurate map of jamming ‘effect’ you need to see the coverage at the ED threshold (-62dBm). Within the web interface this is under the ‘Receiver’ menu and in the api it is the ‘rxs’ parameter.

10 Watts

At 10 watts EIRP, the signal is contained within the park in a localised 500m bubble and is able to reach a few of the surrounding buildings owing to their elevation above the park’s clutter (trees etc).

100 Watts

With ten times more power the increase in effect is disappointing. This is due to the way RF power decays logarithmically so most of the power is lost in the first few metres and the loss scales as the power increases. This time the signal has left the park and is impacting buildings within a kilometre but only where there is line of sight. Most buldings are unaffected due to material attenuation of the short wavelength signal which struggles to penetrate anything other than interior walls.


With a 1000 watts, the disappointment theme continues. The 500m park is still not fully covered due to undulating terrain and clutter which the 2.4GHz signal doesn’t diffract into so sheltered pockets of ‘no signal’ are present even right near the jamming source. More buildings have been touched but most are shielded from the effect behind the first row of houses. A hill (Hampstead heath) several kilometres to the north with line of sight to the park experiences a large amount of interference.

People won’t die, but they will get confused

The greatest fear with collateral damage is disruption to ISM medical devices such as wireless implants. If you jammed inside a hospital where ISM band equipment is used, you could disrupt medical equipment but to influence it from beyond the hospital walls would require several kilowatts of RF delivered very nearby to penetrate the walls with enough power to still exceed the ED level. Wireless medical devices are designed for failure. They are after all used in the busiest spectrum in the busiest cities in the world and have back-off and interference coping mechanisms built in to the standard, like 802.11’s -62dBm ED level and random back-off timer to manage channel contention.

Vehicles won’t crash, but they might stop playing music

The 2.4GHz band is a healthy distance from 1.5GHz where GPS resides. Jamming one to target data communications does not influence the other unless your equipment is really poor. Even if you did interfere with vehicles navigation systems, they are distinct, again by design, from control systems since the spectrum is shared and prone to interference. The most likely impact would be on Bluetooth which uses the entire 2.4GHz band and is commonly used in vehicle infotainment systems which would suffer interference.

Posted on

Multi-resolution modelling

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

Process data from a spreadsheet

Using the CloudRF API, you can process an entire spreadsheet of site data in one go to make a complete network coverage map. This tutorial assumes you are a Windows or Mac user with minimal programming experience. It uses the free Python scripts available here.

Install Python and the requests module

Python is already present on a Mac but for Windows you need to install Python 2.7. Download the right package for your operating system from You will also need the python requests module which you can install once python is installed with this command: python.exe -m pip install requests

Get the CloudRF python scripts

Download the python scripts as a ZIP archive: . The script we will use is called ‘’ which uses several different API calls to process each row in a spreadsheet under a unique group name (network name), then it performs a mesh operation to merge the sites into a single coverage layer.

Prepare your spreadsheet

Your data needs to be in a basic comma separated CSV spreadsheet (known as MS-DOS CSV format in Microsoft Excel). The top row should be column headers defined at You can find an example CSV file called ‘demo_network.csv’ along with the python scripts. Your UID and KEY values are unique to your CloudRF account and can be obtained once logged in at the ‘my balance’ page.

Process your data

Run the python script with one argument which is the name of CSV spreadsheet. You will see results appear in your terminal for each row. The final result will be the consolidated mesh. For the demo script and data, each run of the script will generate a new network name. This is necessary to stop you meshing lots of old files belonging to the same network when you might only want to mesh 10 new sites. python demo_network.csv

Use your results

Everything you do is stored on the server. The demo script also pulls down a KMZ file for each calculation but if you want to see your finished result, login to the web interface at and open your archive. You will find your spreadsheet has become a coverage map. You can use the data either in the web interface, download it from there as a KMZ, SHP or TIFF file. If you want to publish or share the data you can get a URL or HTML embed code to host the layer on your own website.

Change and repeat

Once you’ve got your result its quite common to wonder what effect a different parameter might have. To change a value for all columns, change it for the first row eg. set txw (Transmitter power in Watts) to 2 then copy that value into all the rows below. Save the CSV file and reprocess with the command as before. You will get a new network because the script uses a unique network name each time. In your web archive you can then go and select the network with the old parameters and delete it by checking the box and clicking the trash can icon.

Alternative languages / scripts

The simple API can be used with any other language. You can find examples of Javascript forms from the API clients downloaded in the example above and more languages over at Expert users don’t even need a desktop as you can use CURL from a shell environment: curl --request POST --url --header 'Content-Type: application/x-www-form-urlencoded' --data 'uid=21531&key=a8ec44b5ad85e0ab626e55f20e3cb5da111999a2&lat=50.355108&lon=-4.152938&txh=8&frq=868&rxh=2&dis=m&txw=0.1&aeg=2.14&rxg=2.14&pm=1&pe=1&res=30&rad=6&out=2&out=2&rxs=-95&ant=38&azi=0&cli=5&file=kmz&nam=DRAKES_ISLAND&net=DEVON&pol=v&red=-60&ter=15&tlt=0&vbw=0&col=10'
Posted on

Adding antenna patterns

You can use ADF / NASM (TIA/EIA-804-B standard) and ANT patterns in CloudRF. These basic text formats are open and easily edited and will display a patterns azimuth (Horizonal plane) and elevation (Vertical plane), typically as 360 rows of data each. ADF pattern data is generally in dBd and ANT is a normalised range with 0 as peak power. ADF is the primary pattern format and all ADF patterns are public (accessible to all users). ANT is the secondary format and is private (accessible only to the uploader).
Azimuth360 rows360 rows
Elevation360 rows360 rows
MetadataName, OEM, DescriptionName
FrequencyDefined range ONLYAny
GainDefined gain onlyAny
PolarisationDefined onlyEither
TiltAt time of useAt time of use
RotationAt time of useAt time of use

In summary: ANT gives greater freedom but is risky. ADF ensures correct inputs.

Finding a pattern

There are thousands of antennas from over 21 OEMs. To find the ones you need/want, use the database search feature by firstly typing in your frequency eg. 100 (MHz) and clicking search to filter the results and finally typing into the search box eg. Dipole to find the closest match. You can sort results by any of the columns by clicking it. Next click the hear to add it to your favourites. It will then become available in the interfaces in your selection. This is unrelated to the API which will let you use any pattern if you know the ID number (in the table). If you can’t find your pattern you can source it from the manufacturer in ADF / NASM format.
Kathrein Antenna Patterns
Antenna Pattern Files

Upload a public ADF pattern

Method 1: Login to the web interface then click the antenna database icon within the ‘Antenna’ input menu. Method 2: Login to the web interface then visit Click the ‘Add public .ADF pattern’ link to access the form and then upload your ADF pattern. Any formatting errors will cause a failure which you will be notified of. Ensure your ADF data contains valid metadata in the header eg. gain, name, description. Any data deemed erroneous or inappropriate will be removed from the system without warning.

Upload a private ANT pattern

Method 1: Login to the web interface then click the ‘My Patterns’ button in the Antennas menu Method 2: Login to the website then click ‘Antenna patterns’ on the homepage Click the ‘Add private .ANT pattern’ link to access the form and then upload your ANT pattern. Any formatting errors will cause a failure which you will be notified of. Ensure your ANT data contains 720 rows of data (Azimuth followed by Elevation). Do NOT apply rotation or tilt as this is done dynamically at the time of use. Any data deemed rotated, tilted, erroneous or inappropriate will be removed from the system without warning.

Using patterns

Your uploaded pattern won’t appear in the web interface immediately. You must reload the list with the reload button next to it, especially if you’ve just updated your favourites.

Old ANT patterns

Don’t worry they didn’t get deleted. You can find a list of them here.
Posted on

Exporting to QGIS with SHP

Exporting your data to a GIS platform such as ESRI Arcmap or QGIS allows you to tightly integrate RF coverage layers with other business intelligence such as customer locations.
The TIFF and SHP export formats offered by the expert plan will let you open the layers in a GIS platform. For maximum control over styling you can choose a greyscale colour key called ‘Greyscale GIS’ within the interface or API (col=9) which has a different numeric value for each dB level. This high level of granularity means you can style your shape file to the nearest dB.

Styling CloudRF shape files in QGIS 2.18

  1. Create your coverage layer using the greyscale GIS colour schema.
  2. Download the layer as an ESRI shape file (SHP) and open in QGIS
  3. Right click the layer and open its properties, then ‘style’
  4. Change the type to ‘Graduated’ then pick a colour schema or define your own
  5. Click classify to load in the dB/dBm values. Note that a negative -60dB value will be (+)60 due to the way the levels are represented as positive grey pixel values.
Posted on

Google earth and TLSv1.0

We love Google Earth™ (GE) and have been taking advantage of its advanced network KML features for years now so have got pretty familiar with what’s underneath.
The network capabilities of Google earth are made possible through the open source QT framework which is how you can handle HTTP/S KML content or browse the web within GE.
Linux power users of GE will be aware of it’s https problem – it doesn’t do SSL because the .so libs it ships with aren’t compiled for SSL which is quick to fix by replacing them with libs which are.
Windows users have until now enjoyed seamless SSL compatibility with GE but that has changed recently as we discovered.

In the last year the extremely popular OpenSSL software has found to be to the extent that web browser vendors have taken the extreme measure of blocking websites running unsafe instances of SSL like SSLv3. Read more here. Unfortunately Google earth 7.1.x is compiled for TLSv1.0/SSLv3 so if your web server has been updated to address the security issues you may be in for nasty surprise as your Google earth network layers may stop working – without a useful error message. The reason is the encrypted handshake fails because Google earth expects TLSv1.0, now widely regarded as unsafe and old. The solution is either to re-enable legacy ciphers like TLS1.0 on your SSL configuration OR roll back to plain old HTTP which isn’t ideal.

Affected versions:
Google earth free edition
Google earth Pro
Google earth Pro