The Tough Stump Rodeo is an outdoor edge technology demonstration set in rural Montana.
Selected companies collaborate to integrate their capabilities with the ATAK common-operating-picture to complete communications challenges.

CloudRF participated for the first time as a key enabler on the most challenging lane, the sub-terranean, which required participants to communicate and operate within an underground mine set in a steep ravine located 50km from the HQ in mountainous terrain.

With accurate planning, we quickly built a large radio network with less nodes and greater reliability than could be achieved with basic LOS tools.

Data Preparation

Our preparation started early as we needed to acquire high resolution data for the area to ensure accuracy. Prior to the event our data resolution in Montana was only 30m. We sourced 2m accuracy LiDAR from the USGS for the Ruby valley which we enhanced with 2m resolution tree canopy data from Meta.

Based on feedback from previous years about trees around the mine, we knew accurate tree data would be essential.

The data was loaded to the public system, CloudRF, weeks prior to the event and side-loaded to our offline SOOTHSAYER servers as GeoTIFF files within a data package.

Equipment

We deployed with three offline SOOTHSAYER servers of varying size with several phones and tablets as clients:

• A standard HP Z-Book laptop running Windows/Podman (RTX4070 GPU capable of 15.6 TFLOPS)
• A Carnegie Robotics CardShark computer running Ubuntu/Docker powered by a portable USB-C power bank (Jetson Orin NX capable of 3.7 TFLOPS)
• A Solace Communications Global Edge computer running Ubuntu/Docker powered by a larger USB-C power bank (Jetson Orin NX capable of 3.7 TFLOPS)

Additionally, The Global Edge computer was prepared with our Trellisware API script which interfaces directly with a donor radio to model live network coverage.

Site survey, Sunday

As we were headed to a new area, we were keen to know as much as possible about the terrain which for communications means noise as much as topography.
We took a spectrum analyser up to the mine site on a wet Sunday to check out the noise in the L and S bands and after a long insertion hike due to a closed seasonal access road we were satisfied to find there was no RF noise there.

The nearest noise source was a cell tower up the Ruby valley below which due its location was not able to serve the area of interest. We were therefore able to use the Johnson Nyquist formula with high accuracy to predict the expected noise floor for a given bandwidth.

We modelled the Mine location with modest system profiles (low height/power) to see if we could identify any local relay opportunities. The mine was tricky as it was in a steep forest ravine so we stood at the entrance and observed where it could reach. This low tech study confirmed our modelling which highlighted a hill ~750m due west which just overlooked the mine and had excellent views across the Ruby valley to the south.

Using a mean site upon the hill within the painted coverage area we ran a second simulation with an extreme 40km radius to see where this could hit. We were pleased to see coverage on an embankment 35km down the ruby valley which was useful as the valley’s curved shape meant a relay would be required.

Next, we ran a simulation on the distant HQ location which revealed an area of mutual coverage. A plan was forming…

When running long range heatmaps, the resolution becomes diluted. This is necessary to remain within processing limits as whilst 16 million point calculations are available due to the large GPUS we have on CloudRF, they are impractical for a battery powered Jetson which must share its output over a radio network on ATAK. We also observed notable latency with fetching large KMZ files via the radio’s onboard Wi-Fi as it’s running an older 802.11 standard.

We used our plugin’s limit of 4MP which provides a high resolution result in a practical time of several seconds. Our solution to the ‘mountain repeater’ problem whereby a distant tower is serving a remote location is the bounds feature. This API parameter defines a polygon which focuses processing effort to increase speed and accuracy.

As you can see from the images, the difference the bounds feature offers is significant. It allows the simulation of high resolution at long distances which previously would have been impractical with a ‘big heatmap’.

We drove to the relay we wanted to use and were disappointed to find it was on private land which was time well spent none the less. As a result we identified a secondary site on a layby to the north which was the best we could do.

Setup, Monday

Our radio partner trusted our recommendation and deployed a Comrod ETAMs mast to the layby despite it not being recommended as one of the official repeater positions.
The first (15km) link back to the HQ was barely workable which aligned with the fringe heatmaps we had generated. The weak link was immediately made good by climbing the steep hill overlooking the HQ. The additional height cleared the Fresnel zone which was obstructed by trees and buildings in the valley.

With the first link in, focus shifted to the long link to the mine.

We drove up to the mine and headed out on foot to the exposed hillside we had identified from the mine. This was a steep and difficult route, in hot weather, with rattlesnakes and bears, which Alex H from Trellisware made no less than 5 times. Give that man a raise!

On the hill we used ATAK to navigate to the area on the track on the hill we had identified. This zone covered several prominent rocky outcrops which as we found were popular for sunbathing by snakes. Once in the zone, it became apparent that this would work as radios with low gain whips were connecting to the distant 35km relay. This link was boosted from workable to good, and fit for video, with the deployment of a Farfield Antennas APEX directional antenna.

Our relief at establishing communications was short lived as we were challenged to find a better spot. We used SOOTHSAYER on the CardShark server to simulate the midpoint relay to produce an updated layer. This layer was used to identify a better site nearby at a rocky outcrop on the hill. We relocated to the new site and were pleased to confirm a modest improvement to the link SNR. The scale in the change of location was minor given the 35km distance and the fact both sites had equally great views down the valley but the improvement was notable due to the shape of the convex hill and it validated accurate simulation over ‘looks good’.

During the excitement of closing the big one, we forgot to leave behind a radio at the mine to test the next link. This was soon rectified by a party which returned to the mine and confirmed a good link, which did not come as a surprise given the visibility from the mine and close proximity at ~750m.

A very satisfying radio check from the mine was heard at the HQ 50km away around the valley, over 3 links.

With the sites identified, the network was optimised with wired links between co-located relay nodes on alternative frequencies to increase throughput. There were other configuration changes higher up the OSI model also which are not covered here as we’re focused on establishing layer 1 only. The optimisations were designed to increase throughput and reduce latency to support both video and live UAS control.

Live coverage mapping

In our vehicle we kept our Global Edge server which had a higher endurance than the CardShark. This server was connected to a donor radio’s Wi-Fi access point as a client which enabled it to interact with the Trellisware API.

Our Trellisware python script fetches radio metadata to generate coverage heatmaps for the network using live settings including noise. This is presented as a network KML layer which is consumed by clients including ATAK.

We last demonstrated this in our office car park with our own TW-750 radios so it was exciting to use it on a mountain with a diverse network of different radios. We’re pleased to report it worked as designed after a tweak on the mountain to handle output from radios we’ve not worked with before. We’ve even heard a rumour the KML refresh may be lowered this year to support faster refresh rates, nearly 6 years after we requested this.

We also exercised the ATAK plugin’s Co-Opt function. This powerful feature allows any callsign on the map to be given a radio template which follows its position. As the callsign moves, the radio coverage moves. You can see a video of it on our youtube channel.

Show time and interference

The network was scheduled to deliver a live video feed of a drone exploring the mine.

Despite a day of successful testing, leaving radios behind overnight in the mountains with wildlife and the elements meant unexpected issues were encountered which required local input to fix. On demo day an eleventh hour reset for the relay was promptly executed by Josh, who ‘hauled ass’ whilst observing local speed limits to get up the valley and save the day.

The live video was streaming well on schedule via a local radio’s WiFi access point until the production tent filled with observers… At this time, the congestion within the 2.4GHz ISM band increased and the impact became obvious as the video deteriorated and then failed. The irony of engineering a 50km muti-hop data network in the mountains and failing at the last 2m inside the tent was a learning point. In hindsight, a wired connection to the tablet would have been safer and people should listen to Peter.

The WiFi link self restored due to Automatic Channel Selection (ACS) and normal service resumed with live UAS video streamed over the RF link under the direction of the HQ.

Summary

The event stress tested our capabilities to the limit, where it matters, and provided invaluable feedback we would never have found in a dozen trade shows or car park tests. We leave with very high confidence and a list of improvements and feature requests from the many customers and partners who we interacted with.

One of the most significant features will be the ability to expedite the site selection process for operators with a prompt to an LLM which can execute the multi-stage process of site selection using accurate radio templates. A lot of firms are chasing this AI dream but very few indeed have a mature, published, API to build upon.

We came prepared to model the inside of the mine using our 3D engine which was risky as we needed to acquire and then vectorise a large LiDAR scan from a robotics partner under a tight schedule. We acquired the model but hit formatting snags during the conversion to glTF so parked that task for another day. We did however produce a useful glTF to 3D tile script to present 3D models on ATAK which we will publish.

Despite the maturity, we’re still not elite enough to have our open source plugin listed on TAK.gov but as the push for published interfaces grows, we’re confident that sharing, not guarding, interfaces is the superior strategy for vendors serious about integration, more so in the age of AI. As more proof, we were pleased to see a shiny new plugin at this show that used our API with a radio API that was developed rapidly by a vendor without our knowledge.

Finally, for anyone still unsure if SOOTHSAYER works offline because our company has Cloud in the name, we can assure you it does as we do not own a Starlink and there is no cell coverage in the upper Ruby valley.

For more offline field tests see our Youtube channel.

The post Tough Stump Rodeo 2026 appeared first on CloudRF.

Background

In the early morning of the 4th of July 2025, the Australian warship HMAS Canberra sailed down the west coast of the North Island of New Zealand. It had its navigation radar on, surveying the sea for obstacles. At the same time, residents along the coast found their wireless residential and business internet failing. The story soon hit the local news sites which spread across the globe.

For most people, having their Wi-Fi supposedly jammed by a warship isn’t a regular occurrence so it’s not a surprise the story went viral. However, a lot of the explanations were incomplete and didn’t explain the science behind the issue.

Using the tools offered by CloudRF, we can recreate the events and learn how radar and wireless comms interact.

The Radar System: SAAB Sea Giraffe AMB

First, a clarification. Maritime navigation radar is not a monolithic category. Commercially, the most common bands are X-band (~9.5 GHz) and S-band (~3 GHz), both of which are regulated for civilian maritime use and appear on everything from fishing trawlers to container ships. Military vessels frequently also carry C-band systems (~5.5 GHz), which offer a useful engineering trade-off: better range and resolution against small surface targets than S-band, but with less atmospheric attenuation than X-band.

On board the HMAS Canberra, there is only one named C band radar, the SAAB Sea Giraffe AMB. From the brochure “The SEA GIRAFFE AMB is a medium range, multi-role surveillance radar optimized for detecting small air and surface targets with high update rate in all kinds of environments, including the littorals” which is ideal for transiting the rugged coastlines of New Zealand.

Naturally, full information on this system is not publicly available, so we shall have to try and source as much as possible and then estimate the remaining parameters. This will be saved as template in CloudRF and used for multiple calculations:

{
    "site": "SeaGiraffe",
    "network": "HMASCanberra",
    "engine": 1,
    "coordinates": 1,
    "transmitter": {
        "lat": -39.478009,
        "lon": 173.687817,
        "alt": 43,
        "frq": 5550,
        "txw": 25000,
        "bwi": 100,
        "powerUnit": "W"
    },
    "receiver": {
        "lat": 0,
        "lon": 0,
        "alt": 8,
        "rxg": 0,
        "rxs": -64
    },
    "feeder": {
        "flt": 1,
        "fll": 0,
        "fcc": 0
    },
    "antenna": {
        "mode": "template",
        "txg": 30,
        "txl": 0,
        "ant": 1,
        "azi": 0,
        "tlt": 0,
        "pol": "v"
    },
    "model": {
        "pm": 4,
        "pe": 3,
        "ked": 2,
        "rel": 50
    },
    "environment": {
        "elevation": 2,
        "landcover": 1,
        "buildings": 1,
        "obstacles": 0,
        "clt": "Temperate.clt"
    },
    "output": {
        "units": "m",
        "col": "GREEN.dBm",
        "out": 2,
        "nf": -94,
        "res": 60,
        "rad": 120
    }

First, we can estimate the transmission power to be around 25kW which in this case is going to be our peak power.

We will set our bandwidth to be 40MHz which gives us single digit meter range resolution, though this maybe too high for more general surveillance, these types of radars can adjust their bandwidth to help search for specific features.

We shall set our center frequency to be 5550MHz which places us comfortably within the C band range.

Our last two variables relate to our antenna. Radar antennas are naturally placed on a ships mast, and the HMAS Canberra has several. The exact height isn’t available, but we know the tallest point on the Canberra is “45cm below the Sydney Harbour Bridge” which is roughly 49m above sea level. Looking at the vessel, there are two towers which are shorter than the aft tower. We can see from photos of the Canberra that the sea giraffe is in the middle tower. By subtracting a few metres gives a transmit height of roughly 43m.

For the antenna itself, we will use it’s rotation our advantage and model the system as a dipole, giving uniform coverage in all directions. With the template set up, we can make a prediction of the signal strength around the ship and see the radar’s potential coverage which by design is significant.

As we can see from the scale of the image, the HMAS Canberra’s radar signal propagates more than 150Km from the origin. However, as the signal must return to be sensed, we can use the radar model to give a rough indication of received power for a given radar cross section. In the image below an RCS of 10m2 at a height of 10m was used, giving much lower return values demonstrating why radar signals need so much more transmit power compared to regular communications.

5G Fixed Wireless Access

On the other side of this situation, there are several privately owned and operated Fixed Wireless Access (FWA) networks providing rural communities internet access. In New Zealand, many WISPs utilise unlicensed RF spectrum under GURL licences. For a rural area at least, there are enough open channels and limited ranges that networks can dynamically operate around each other without causing significant interference issues.

To develop an understanding how a network provides coverage, a fictional FWA tower is templated in Cloud RF and used to give wireless coverage over the small town of Opunake on the East Coast. We can use Radio Spectrum New Zealand’s licensing requirements to establish reasonable power, frequency and tilt requirements. We set our receiver at 5m to represent a rooftop in the nearby towns.

For frequencies we can implement Radio Spectrum Management New Zealand’s FWA allocation depicted below.

5G FWA template

{


    "site": "Site-A",

    "network": "NZ-WISP",

    "engine": 1,

    "coordinates": 1,

    "transmitter": {

        "lat": -39.283647,

        "lon": 173.810227,

        "alt": 22,

        "frq": 5550,

        "txw": 0.01,

        "bwi": 40,

        "powerUnit": "W"

    },

    "receiver": {

        "lat": 0,

        "lon": 0,

        "alt": 5,

        "rxg": 23,

        "rxs": -105

    },


    "antenna": {

        "mode": "template",

        "txg": 23,

        "txl": 0,

        "ant": 3587,

        "azi": 310,

        "tlt": 1,

        "pol": "v"

    },

    "model": {

        "pm": 4,

        "pe": 2,

        "ked": 2,

        "rel": 50

    },

    "environment": {

        "elevation": 2,

        "landcover": 1,

        "buildings": 1,

        "obstacles": 0,

        "clt": "Temperate.clt"

    },

    "output": {

        "units": "m",

        "col": "LTE.dBm",

        "out": 2,

        "nf": -90,

        "res": 20,

        "rad": 30

    }

}

Selecting channel 110 sets the center frequency to 5.55GHz, and a coverage map can be created for the fictional site.

From the coverage prediction, we can see that the relatively low power WISP is still receivable from nearly 20Km away with a clear line of sight for a 40MHz link. So, for any coast facing towers, there’s a good chance their signal can be detected offshore well past the intended service range.

Dynamic Frequency Selection

As part of the licence requirements, radios using these bands are equipped with Dynamic Frequency Selection (DFS). This is an intentional safety mechanism recommended by the ITU to prioritise and protect Maritime radio navigation systems. The goal is to prevent interference by triggering a shutdown upon detecting radar pulses. The priority is to protect the radar picture which is safety critical.

Above a threshold, a received pulse will cause the wireless device to switch to a different frequency or shutdown it’s radio. It will listen out until it can no longer detect radar pulses before returning to that frequency and transmitting again so is performing automated de-confliction.

For our FWA systems, the threshold is set to -64dBm from a radar, received by a reference dipole with 0 dBi gain which is very easy to set up in Cloud RF by adjusting receiver sensitivity up to -64dBm and then remapping the coverage. In the image below, the areas in green represent a radar signal above the threshold that will trigger DFS.

As we can see, the radar signal easily covers the coastline and extends deeper into the mountainous areas. However, this is just a fixed location and not representative of the dynamic coverage of the moving platform.

Estimating the Full Extent of the Outage.

Rather than picking and analysing a single spot, we can recreate a similar course sailed by the HMAS Canberra and then use points along this track to build a comprehensive understanding of the impacted coastline.                                                                      

We know that the ship sailed down the west coast of the north island before heading into the cook straight on the way to its destination in Wellington. It’s not clear when the ships radar was switched to a different frequency and it is not possible to get historic coordinates like commercial shipping so likely course has been chosen.

Using automatic processing, we can use the radar template to efficiently model coverage for each point and then use Superlayer to combine these results into a single layer.

Using our templated radar, we can see that the entire coastline on the West Coast is a above the power threshold that would trigger DFS. We can also see that northern coastal and mountainous areas of the South Island. This aligns with the reported outages and also shows affected areas which may not have made the news.

On the west coast, we can see that the gentle slope up from the coast towards Mt Taranaki offers little obstruction to the radar signal.

From the coverage maps it is safe to conclude that the outage was caused by the DFS triggers rather than physical interference on the antennas. It was an inconvenience for the affected businesses and customers but an effective demonstration of spectrum co-existence technology working as intended.

For many readers of the subsequent news articles, it was the first time they had learnt that a ship can disable internet access, and it’s a standard baked into radio equipment.

What if there wasn’t DFS?

When viewing these images, it might be tempting to ask the question, “Why does this radar system need protecting? And what would happen to the FWA network if DFS wasn’t required?

To do that, it is necessary need to investigate both emitters to see how the two networks could interfere with each other.

Radar Signal Interference on the WISP.

To establish the interference of one network upon another is a straight forward task with the interference tool. However, before we can jump straight into the analysis, we need to make sure we are comparing apples to apples.

To begin with, radar signals are typically circular polarised. However, our FWA is vertically polarised so we will have some polarisation loss which will be estimated at -3dB.

Additionally, the centre frequency our radar system and bandwidth is not always the same as our radio channels, we will need to compare across the range of channels to see how the radar system affects adjacent channels rather than just co-channel interference.

Referring back to the RSMNZ chart, we can see that many channels are varying bandwidths. For this analysis, we will focus on the 40MHz 802.11 channels.

Using our FWA templates, we can quickly produce coverage maps and then use the interference tool in Cloud RF to see how the ship’s radar will impact connectivity on these channels of interest. Recalling that we are using a 40MHz radar signal centred at 5550MHz, we would expect to see interference within the range of 5530-5570MHz. This would overlap with channels 102 and 100, leaving the rest of the spectrum clear.

By using the interference tool, we can see that the simplistic assumption was only half-right and the relative strength of the radar signal has caused interference outside of it’s 40MHz bandwidth. Adjacent channel interference can still be observed up to 5630MHz before it drops away leaving channels 134 and 142 clear.

Signal power is shaped like a bell and is wider in practice than on paper.

As the radar bandwidth was assumed to be 40MHz, there is a possibility the actual SEA Giraffe could have used a wider bandwidth which would have caused wider adjacent channel interference, leaving none of the 40MHz 802.11 viable. So given the high levels of adjacent channel interreference we can safely say that without DFS, these WISPs would still be dealing with a significant outage until the ship had passed.

WISP Interference on the Radar Screen.

If the radar is so powerful, why is priority given to it compared with low power home networking equipment?

For that reason, it is worth looking at the effect of interference on a radar return. First and foremost, we need to understand the purpose of the radar is to aid navigation. Radio navigation is critical for detecting hazards when visibility is poor. For a military ship, particularly a helicopter carrier, surveillance and coordination of close airspace is also a key task.

Measuring interference is not easy as the exact relationship between the wireless transmission and the radar receiver is complex however we can model some educated assumptions to show the potential effect.

First, not all the power from the coastal signal will be absorbed by the radar antenna due to polarisation and what is makes it to the radar screen will be further attenuated by the receiver’s processing gain as the radar will use spreading codes, beamforming and other techniques to improve selectivity and mitigate interference. To model them, we’d need very detailed information on the Sea Giraffe which is not publicly available.

What we can observe, however, is the rise of the noise floor due to the addition of WISP transmissions around the ship and this will impact the signal-to-noise ratio (SNR) before signal processing.

First, we will use a FWA channel that is entirely within the bandwidth of the radar signal to keep spectral density simple. For this case we will use channel 110 at 5550MHz.

The noise floor is given by the combination of the radar’s thermal noise, the power of the FWA signal and other sources. Noise is computed using the signal power divided by Boltzmann’s constant.

$N_{\mathrm{floor}}=kTB+P_{\mathrm{WISP}}$

$\Delta N_{\mathrm{floor}}\approx \frac{P_{\mathrm{WISP}\left(\mathrm{in-band}\right)}}{kTB}$

$\Delta N_{\mathrm{floor}}\left(\mathrm{dB}\right)\approx 10{log}_{10}\frac{P_{\mathrm{WISP}\left(\mathrm{in-band}\right)}}{kTB}$

As the radar noise floor is relatively constant, by using Cloud RF, we can generate received power predictions and then use the noise database feature to visualise the effect of a changing noise floor on radar return coverage.

We will use another fictional FWA site that is pointing out along the coast, providing coverage to a coastal town. From this tower, the signal propagates beyond it’s intended audience and is received by the ship’s antenna.

To address the change from vertical to circular polarisation, we can factor in a -3dB loss.

At our reference points, we can see that the ship travels through the FWA coverage, which peaks at around -76dBm despite being over 16km away from the receiver. This is because our radar antenna is elevated and it has a high 30dBi gain. As both systems are working on channel 110, all of this received power is in band for the radar and adds to the noise floor.

With a value for WISPs sorted, we can calculate the Radar Thermal Noise Floor at 40 MHz.

N = kTB = 1.38×10⁻²³ × 290 × 40×10⁶ = -108 dBm

And then converting to mW we can see that our new noise value is dominated by our WISP signal due to the orders of magnitude in difference.

For a simple SNR equation, this much noise will lead to a drastic reduction in detection range. In reality, the Sea Giraffe will have front end filtering and signal processing techniques built in to significantly boost it’s signal ratio and maintain a clear picture. It is also important to note that this interference will only be coming from one angle, which makes it’s effect asymmetric.

From the different coverage plots, we can see that varying noise sources change coverage significantly and as RADAR is a directional array, a blind spot can be directional.

We can see that there is potential that increased noise in the C band could lead to a notable reduction in radar picture accuracy which presents a danger to maritime navigation, which has priority.

From the analysis, it is clear that the DFS system functioned as intended. It kept the ship’s navigation systems safe from interference at the cost of a temporary disruption for the coastal communities.

To prevent this happening, visiting warships could be given spectrum assignments clear of civilian infrastructure, or could signal their intentions in advance to local spectrum authorities. Vigilant spectrum surveillance could also provide early warning of anomalies which could be communicated to local spectrum users.

Coastal interference demo

Because we’ve leveraged the Cloud RF API and made templates, we can package our multi-step static analysis into a dynamic and simple tool. Using everybody’s new team member, Claude, we have published a simple tool which can demonstrate the signal strength for a ship’s radar as received by a coastal network.

Explore the tool here: https://cloud-rf.github.io/CloudRF-API-clients/slippy-maps/radar_interference_demo.html

References

HMAS Canberra https://www.dvidshub.net/image/6755556/us-special-operations-australian-navy-accomplish-combined-black-hawk-deck-landings

HMAS Canberra Capabilities, https://www.navy.gov.au/capabilities/ships-boats-and-submarines/hmas-canberra-iii

SAAB Sea Giraffe AMB, https://www.radartutorial.eu/19.kartei/07.naval/karte038.de.html

HMAS Canberra accidentally blocks wireless internet and radio services in New Zealand | RNZ News

Australian navy ship accidentally blocks internet and radio across parts of New Zealand | Australian military | The Guardian

The post How a passing Warship took out a town’s Internet appeared first on CloudRF.

This blog explores how Counter- (C-UAS) and RADAR systems can be modelled efficiently within CloudRF to optimise siting and improve their effectiveness.

The challenge 

The methodology for operating sensors varies depending on the environment in which they are operating:

In dense urban environments, high-rise buildings reduce Line Of Sight (LOS) and block ultra high frequency signals, creating what are commonly referred to as urban canyons. An example of this effect for a poorly sited sensor at street level is shown in the screenshot below.  In such environments, reliable coverage is limited to areas where a clear Line-Of-Sight (LOS) path exists.

By contrast, in open rural environments, where terrain and structural obstructions are minimal, significantly greater and more consistent coverage is achieved using the same transmitter configuration. This comparison highlights the substantial impact that the environment has upon system performance. 

Similar challenges arise in environments where vegetation screening is present, particularly in forested and jungle regions. Dense foliage, tree canopies, and uneven terrain can significantly obstruct LOS. These factors degrade the performance of C-UAS and RADAR systems by reducing detection ranges and creating coverage gaps. As a result, system effectiveness is biased towards clearings or elevated positions where partial LOS above vegetation can be maintained.  

Operators in obstacle-dense environments are therefore required to invest significant time in identifying suitable siting locations to maximise their equipment’s performance. This can be a challenging task due to access restrictions and the time required to conduct map studies and pre-deployment reconnaissance. These activities are resource-intensive and place additional demands on system operators who may already be operating under tight time constraints. 

Time invested in developing and optimising siting locations can be quickly undermined by the introduction of new obstacles that block LOS. These obstructions may take various forms, ranging from temporary structures erected for events to newly constructed buildings. Such changes can significantly degrade system performance and necessitate reassessment and reconfiguration of established sites. 

An often-overlooked challenge across all operating environments is spectrum noise. Noise levels vary significantly between locations and fluctuate due to changing environmental and human activity. While pre-event site visits and planning can help establish baseline conditions, increased traffic during an event such as a motorsport or a music festival can raise noise levels to unprecedented levels, degrading system performance and detection reliability.  

Another challenge facing teams is whether they are looking to counter the Unmanned Aerial Vehicle (UAV) or the controller. Locating the controller can vary in complexity depending on how the drone is operating. A drone operating on the 2.4GHz ISM band may stand out against the normal radio environment due to its relatively strong and distinctive spiky FSK signal, whereas a drone operated via LTE or 5G SA will be more difficult to distinguish among dense cellular traffic. 

Terrain, buildings, vegetation, and RF noise constrain coverage, making site selection key to system effectiveness. 

The Solution 

Modelling coverage and identifying transmission sites for these systems can be done quickly and effectively using tools which are accessible to not only radio engineers but operators on CloudRF.  

The first step to using the system efficiently is to setup a template. This is how we can save our settings for systems and reference them quickly for future calculations. Templates include information about the transmission and receiving station(s), such as heights, frequencies, power, antennas and environmental factors, some of which are discussed further below.  

Making the Template 

When designing a template for a C-UAS or RADAR system, we should apply additional consideration to the following: 

Height Measurement 

We can specify the height unit to be measured as Above Ground Level (AGL) or Above Sea Level (ASL), in either metres or feet. RADAR systems looking to locate fixed wing platforms are better suited for Feet ASL, whilst UAVs which use “GPS height” reference Metres AGL as their primary height reference, especially for restrictions which are also communicated as AGL. For example, consumer drones are restricted to 120m (400ft) AGL in the UK.

Running calculations in ASL is recommended for experienced users of CloudRF. When the transmitter location is changed, the height will need to be adjusted to consider the ground beneath. If not adjusted correctly, transmitters and receivers can be placed underground by accident resulting in an error.

 Use AGL for UAV operations and ASL for high-altitude RADAR targets to match the domain/system altitude references. 

Model  

When designing a template for a RADAR system, the dedicated RADAR model should be used. This model is more that just line of sight as it uses a Radar Cross Section (RCS) value, allowing operators to define the size of targets they intend to detect where a drone has a smaller RCS (0.04) than a plane ( 6.0 ) which limits it’s detection range compared with a plane. By configuring appropriate RCS values, the model can more accurately represent real-world detection performance. 

For a counter-UAS (C-UAS) system, the recommended model is ITU-R P.1812 with an average context, 50% reliability and diffraction turned off. This combination of model and diffraction will simulate the high frequencies and line-of-sight coverage utilised by C-UAS systems and has been proven to be the most accurate model during our model testing.

Use the RADAR model with RCS values of 0.05 for air-surveillance and ITU-R P.1812 (diffraction off) for UHF C-UAS sensors. 

Environment 

Obstacles affecting system coverage can be configured within CloudRF through the Environment submenu. 

CloudRF provides access to extensive global clutter datasets, including 10m land cover, 2m building data, and, in selected regions, 2m LiDAR and tree canopy height data.  

An interactive map showing the availability of this data can be accessed at the following link – https://api.cloudrf.com/API/terrain 

SOOTHSAYER^TM users can import their own LiDAR in addition to CloudRFs DEM archive. 

For added accuracy, obstacle attenuation can be fine-tuned using clutter profiles, allowing operators to accurately represent real-world conditions. This level of customisation enables precise coverage predictions and improves confidence in system performance assessments especially at lower frequencies where NLOS attenuation needs to be considered as well as LOS.

To deal with temporary or new obstacles not currently in the DEM dataset, users can enable the ‘My Obstacles’ feature to manually draw or upload a KMZ/Geojson of the obstacle(s) to be included in the coverage prediction. 

Noise 

Noise is often an overlooked factor in radio network planning, yet its impact on coverage and performance is significant. By incorporating measured or simulated noise data, the planning environment will more accurately replicate real-world radio conditions.

This enables operators to reflect variations in the operating environment whether accounting for daily commuter traffic patterns or preparing for large-scale events such as concerts and sporting fixtures, where spectrum density and interference levels both increase substantially.  

Noise is a factor within the template’s environment block. This value can either be manually entered eg. -100dBm or referenced from an uploaded dataset from multiple locations, creating a visible noise layer on the map.  

Live noise can also be simulated in calculations by using networked SDRs. We have published an example capability here: https://github.com/Cloud-RF/DORA 

Our recommended default settings are for Landcover and Buildings to be ON with the Temperate clutter profile which represents dense trees. 

If you do not know the noise figure at your receiver, enter -100dBm which is typical of the ISM 2.4GHz band but will vary widely by location. Noise is measured across a channel so should be measured with the appropriate bandwidth. Johnson-Nyquist theory means (channel) noise increases with bandwidth and to a lesser extent, temperature.

Tools & Features 

Once we have created a system template, we can use it with a number of tools to identify a transmission site and then determine the effective coverage from that location. 

Best Site Analysis (BSA) 

BSA is a powerful search tool designed to identify optimal transmitter placement locations defined by a geographical area. It performs hundreds of tests rapidly with a GPU in an area using a full propagation model with transmitter parameters. Positions are graded and then ranked to present the results as a heatmap image.

“The examples used in this document have been generated using KMZ and GeoJSON files. These can be imported into the User Interface (UI) via the Import Menu – Best Site Analysis. This is our recommended way to use the tool, as the simulation can be re-run with the same defined area and speed up the process when comparing a variety of height levels. There are numerous ways of doing this. Numerous software packages can do this; KMZ files can be created in Google Earth, and GeoJSON files can be created via geojson.io” 

BSA is particularly valuable for identifying viable transmitter sites that may be overlooked through traditional planning methods such as “walking the ground” for example. By automating complex visibility analysis, users obtain actionable results within minutes, significantly reducing the time and effort associated with manual studies. 

The recommended locations require interpretation. For example, if you are working with a DSM LiDAR model which contains water, this may be ranked as an efficient site. An operator will likely discount this, but that doesn’t mean that an adversary will as launching a drone from a boat is effective.

BSA ranks the most effective transmitter locations within an area using inter-visibility scoring. 

Area Calculation 

Once suitable candidate sites have been located, we can use the Area endpoint via the UI or API to see the coverage of our system at various heights. The heights chosen for the receiver will depend on the asset that we are looking to target with the C-UAS or radar system, for example 100m AGL.

The heatmaps created by the Area endpoint show the coverage of the transmitter to the receiver using the settings prescribed in the template. Heatmaps are useful for identifying areas with and without coverage and can assist in the decision-making process for the deployment of additional assets to further enhance coverage.  

 Area calculations can show coverage from a candidate site and expose gaps and shadowed airspace. 

Best Server 

Best Server is a feature which can be used with an established network. The Best Server tool will check each node for coverage to the designated receiver location. This allows the coverage from a large network of radios to be checked at various heights quickly, a common requirement when planning C-UAS, Radar or any Ground-To-Air transmission. 

 Best Server identifies which network nodes can affect a target at a given height and location. 

Case Study 1 – C-UAS Site Selection – Texas, USA 

Difficulty: Easy 

This case study evaluates optimal C-UAS siting and coverage performance in the vicinity of a major sports stadium in Arlington, Texas. 

Inputs 

• C-UAS template 

• Defined area of interest 

Process 

• Best Site Analysis to generate and score candidate locations 

Outputs 

• Coverage heatmaps per site (multi-height Area analysis) 

• Identification of coverage gaps and shadowed regions 

Decisions 

• Select primary deployment site(s) 

• Position additional systems for full airspace coverage 

The system represented by the template in this simulation is an omnidirectional C-UAS system, operating at 2.4GHz, with a 3m tall antenna. For the initial survey, the receiver height is set to 150m AGL, this can be reduced for more in-depth planning throughout the planning process.   

The model used for this survey is ITU-R P.1812, with diffraction turned off. Within the city of Arlington, there is 2m LiDAR available, which has been selected by setting the Environment to Surface/DSM (LiDAR), and a resolution of 2m.  

With the template for the C-UAS created, Best Site Analysis can now be used to identify optimal locations for siting the system.  

After defining the desired area of coverage, we are presented with a layer with sites scored according to their intervisibility.  

Using the slider to filter out lower-scoring positions, areas with higher intervisibility can be highlighted on the map. 

Based on the analysis, the highest-scoring sites were located on the roof of the stadium and towards the car parks on the South side of the stadium.  

“For best practice, we recommend evaluating numerous positions. In the above example, the centre of the stadium is the optimal position. However, it is not in a practical sense, i.e. is the stadium roof safe? Other considerations could include access rights, sustainment and logistical requirements.” 

With these positions identified, the Area endpoint can be used to evaluate the coverage.  

Setting the receiver at a height of 150m AGL, there is good coverage within a 5km radius of the transmitter. The weakest areas of coverage are directly overhead of the transmitter, where the null of the dipole has the lowest gain.  

UAVs can operate at different heights so coverage should be evaluated at a variety of receiver heights within the local threat capability. For the next simulation, the height of the receiver is set to 10m AGL. 

The coverage of the C-UAS system is now reduced. Obstacles in the environment, including buildings and trees, have a greater effect on the signal, blocking the line of sight and reducing overall coverage.  

A particular point of focus is the area directly around the transmitter. Due to the curvature of the roof and the relative height of the building compared to the ground, positioning the C-UAS system on the roof creates shadows around 400m away from the stadium, where there is no coverage. 

One chain of thought for solving this issue could be to position the transmitter on the side of the stadium. By changing position and re-running the simulation, there is an improvement in coverage to the South of the stadium, but now the stadium is blocking a large majority of the signal to the North, requiring the deployment of further systems to provide coverage in the area required. 

Having multiple sensors improves system resilience to failure or interference and improves detection.

Alternate locations identified during the initial Best Site Analysis can also be assessed for deployment of the C-UAS system. For example, positioning the transmitter in the car park to the south of the stadium allows us to save a site template and quickly generate 3D airspace coverage using the 3D-Airspace script. This enables rapid visualisation of coverage performance at multiple altitudes. 

This script will create a KMZ showing multiple layers based on the height of the receiver. In this case, with an upper ceiling of 150m, the script will create layers every fifteen meters. 

The script using these requests is available via https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/python/3d-airspace. 

From this analysis, there is greater coverage of the southern side of the stadium, previously in the shadow of the C-UAS site on the rooftop. The stadium itself is still acting as a major obstacle; the deployment of multiple systems would be required to cover the entire stadium area.  

Adding multiple systems into this network and creating a single layer to demonstrate coverage is possible by using the Superlayer tool, allowing commanders and operators to get a clear overview of sensor coverage.  

The Best Server tool can also be used to evaluate a network of C-UAS systems. Using the established network, a UAV can then be added into the simulation, flying at a height of  25m in the example below. This can then show us which C-UAS would be able to have an effect on the UAV. In the example below, the UAV at 25m AGL has a link to the C-UAS systems in the northern area, whilst the systems deployed on the rooftop and in the southern car park are being blocked by obstacles. 

BSA identifies viable deployment positions, and multi-height Area analysis shows where additional systems are required for full stadium coverage. Best Server can be used to quickly identify coverage from selected positions to a central receiver.

Case Study 2 – Finding the Operator – Dartmoor, UK 

Difficulty: Moderate 

CloudRF can be used for simulating both transmitters and receivers in a real-world environment. In this case study the template and tools used will show how the simulation results can be interpreted to understand where the ground control station (GCS) could possibly be located. 

Inputs 

• DF sensor template 

• Sensor height and frequency 

• Line of Bearing (LOB) 

• Measured received power 

Process 

• Path-loss calculation using DF-derived constraints 

Outputs 

• Probable GCS transmitter locations 

• dB error score per location 

Decisions 

• Prioritise ground search locations 

• Assess the control range of the UAV 

DF sensors are essential for a C-UAS team in order to locate both the UAV and the corresponding control station. These systems can come in a variety of formats and may use various methods to determine a Line Of Bearing (LOB) to the transmitter.  

Direction Finding (DF) sensors are typically deployed in multiples to generate several Lines of Bearing (LOBs), enabling triangulation and the establishment of a Position Fix (PF) at the point of intersection. However, this represents an ideal scenario. In practice, operational constraints such as logistics, network limitations, and manpower availability may restrict deployment to a single asset, significantly reducing geo-location accuracy. 

In the following example, CloudRF’s API is being used to help a C-UAS team with a single DF system to identify possible locations of a UAS ground control station (GCS). 

 The methodology for doing this is not dissimilar from the standard way of using the software, with the user creating a template for the asset they are looking to locate. For this example, the height of the DF system was set to 8m, and the ground control station was set to 2m.  Measured units are changed to Path Loss which shows possible signal coverage irrespective of power levels and is recommended when working with unknown power levels or receivers.

By filtering the results of this simulation through parameters collected by the DF system, such as the LOB and received power of the signal, possible transmit sites can be identified on the map, scored with colours representing error in dB.

This result can provide operators with a greater understanding of where a rogue transmitter could be located with just one DF system, increasing the efficiency of a single team. For more on this concept see our DF blog.

 In the screenshot below, a single LOB has been used to evaluate a large area to determine several possible sites. False positives in nearby dead ground are expected which can be quickly discounted using other sources of information.

Once a location has been identified, operators can use the Area endpoint to evaluate the coverage of this transmitter to determine the threat range of the UAS. This can be done within the UI as demonstrated in the screenshot below. 

For evaluating the coverage of the ground station at various altitudes, a 3d-airspace script can be used to recursively model coverage efficiently at ascending heights.

 A single DF sensor combined with path-loss modelling significantly reduces a large search area.

Integrating AI 

An open architecture with published documentation and examples enables Large Language Models (LLMs) to quickly build custom interfaces and tools to leverage the Open API.

Here is an example sensor placement interface built with Claude, which exploits the new Multilink API to show coverage for a UAS. The tool uses pre-defined templates, so it requires no RF engineering skill or training to move the sensors to achieve coverage with high confidence.

Live demo link: https://cloud-rf.github.io/CloudRF-API-clients/slippy-maps/leaflet-drone-detection.html

Conclusion 

Pre-deployment planning for C-UAS and RADAR systems is resource intensive and traditionally required expert input.

By standardising system parameters in reusable templates and using efficient analysis tools powered by open APIs, modern operators can model entire networks quickly and accurately without compromising quality. 

Optimal locations are not always the most obvious or the most practical. A single system rarely provides complete protection in complex environments so a layered, networked approach, validated through high resolution simulation, enables continuous airspace coverage and ensures that assets are positioned for maximum effect. 

The post Optimising drone detection with RF simulation appeared first on CloudRF.

Multi link API

This API is designed for mesh and MANET networks and has already replaced the points API for the MANET tool on CloudRF. The Points API will endure for modelling an array of transmitters to a single receiver, like a route, but Multi-link takes it up a gear and tests all radios to each other, at once.

By passing in the entire network in a single API request, this is much more efficient than recursive requests and because of this it is able to model hundreds of bi-directional links in milliseconds without a GPU.

In the example below, 10 S-Band mesh radios around the Isle of Wight were modelled using Bullington diffraction with a single API request in 0.14s.

Multi-link can be called with an array of “radios” which have distinct features and noise levels making this well suited to mixed networks with different systems and antennas. Each radio is tested to the others and antenna patterns and orientation are considered for both the origin and destination.

{
  "site": "Site",
  "ui": 3,
  "network": "test",
  "radios": [
    {
      "lat": 50.67579947194087,
      "lon": -1.5873429660824838,
      "alt": 3,
      "frq": 2220,
      "txw": 2,
      "bwi": 2,
      "nf": "-110",
      "antenna": {
        "txg": 3,
        "txl": 0,
        "ant": 0,
        "azi": 0,
        "tlt": "0",
        "hbw": 360,
        "vbw": 25,
        "fbr": 3,
        "pol": "v"
      }
    },
   {...},
   {...},
   {...},
   {...}
  ],
  "model": {
    "pm": 10,
    "pe": 2,
    "ked": 2,
    "rel": "50"
  },
  "environment": {
    "elevation": 2,
    "landcover": 0,
    "buildings": 0,
    "obstacles": 0,
    "clt": "Temperate.clt"
  },
  "output": {
    "units": "m",
    "out": 2,
    "res": "30"
  }
}

Receiver antenna patterns

Receiver antenna patterns are important when working with directional antennas.

Historically we’ve answered this with receive antenna gain only with the assumption that the antenna is orientated toward the transmitter. This worked for omni-directional antennas and directional antennas which move, but most don’t.

By popular demand we’ve added this capability to the Multi link API but will not be adding another polar plot selector to the web interface as it is complex enough. If you are working with directional antennas the MANET tool will now allow you to model the impact of receive antenna nulls which are not obvious even with a clear line of sight.

Container refactor

We have consolidated 7 containers into 4 to reduce the size, complexity and management of multiple containers. The benefit is immediate from a much reduced download time for only 2GB of packed images (65% reduction) to a faster install and lower overall CVE score when scanned with vulnerability scanners.

The two GPU containers have been absorbed by a new “core” container, which is the largest. It’s logging has had work so you can filter for messages from a component (gpu_engine, 3d_engine, api) like the 3D engine for example:

$ docker logs --tail 100 --follow soothsayer-docker-core | grep 3d

[3d_engine] starting...
[3d_engine] Input path: /data/3D/input/
[3d_engine] Data path: /data/
[3d_engine] Output path: /data/
[3d_engine] Number of CPU workers: 2
[3d_engine] Number of GPU workers: 2
[3d_engine] Checking license...

The two web server containers (API and Frontend) have been consolidated into a single “httpd” container with a single .conf file making configuration changes simpler and improving visibility. Once installed the images are under 7GB.

$ docker image ls

soothsayer-loaded-image.localhost/soothsayer-docker-core:latest             c260a5993051       4.09GB          909MB        
soothsayer-loaded-image.localhost/soothsayer-docker-httpd:latest            e326003d5aff        145MB         36.8MB         
soothsayer-loaded-image.localhost/soothsayer-docker-map-proxy:latest        a1c286f0adb8       1.73GB          388MB   U         
postgres:16.13-bookworm                                                     7858a1a43bb2        616MB          155MB    U  

CVE scan reports

We have integrated automated CVE scanning in our pipeline now to improve security visibility for procurement.

The HTML reports will live in a SBOM folder along with our XML Software Bill Of Materials for third party libraries. We know customers are struggling with approving software so we’re hoping to educate and assist with this process where we can. In the age of AI slop it has never been easier to spin up a 3D map with widgets but it’s much harder to maintain and assure that through the development life cycle.

SOOTHSAYER is built on Linux so it has bugs….but they’re not all ours. Our goal is to detect and fix as many as possible before release and issue regular updates so customers can upgrade their software and remain protected.

For details on CVEs please email support@cloudrf.com

For bug fixes in our own software, see the full change log at the bottom of this blog.

Offline 3D terrain

Go to any industry trade show and you’ll see beautiful 3D maps with 3D terrain and 3D buildings. Very few are running offline and need to stream these layers from a commercial third party service, with third party terms and conditions.

We have invested in our own Quantized mesh generator so we can finally cut the cord with third party providers and offer 3D terrain, on Cesium, offline. We’re able to do this on the fly using local DEM data so if you want to improve the resolution, replace the GeoTIFF data in your folders.

This development is the first of several offline 3D layers with buildings and trees already in production. Keep an eye out for these on CloudRF this year.

Accurate tree canopy data

Last year we processed 2M tiles of tree canopy data from Meta into CloudRF. This is now available on SOOTHSAYER for Europe, the US and other regions on demand either online as streamed data or offline via a data package.

The precision data improves accuracy in areas which previously had only 10m Land Cover data with a mean height for the tree canopy. The screenshot below is from Scotland where previously trees were sampled at a consistent height eg. 10m. Trees are permeable and using the clutter profiles, users can set the density for species and seasons.

For more information on the tree data and Machine Learning model used see this Meta blog post.

For some bedtime reading about vegetation attenuation values see ITU-R P.833

Tree tiles by country

2600 BELGIUM
4560 DENMARK
60360 France
37640 GERMANY
6780 IRELAND
30100 ITALY
8140 LATVIA
520 LUXEMBOURG
4720 NETHERLANDS
63856 NORWAY
33140 POLAND
1530 PORTUGAL
66480 SWEDEN
27560 UK
918080 USA

Simpler licensing

We’ve enjoyed handing out lots of SOOTHSAYER keys over the last year but our edge customers have had difficulty with the pseudo-random device ID for the host changing. The reason this changes is because it was based upon the physical MAC addresses on the host system. When these change, because the customer added a USB Ethernet adapter, the license must be re-issued which is frustrating when SOOTHSAYER has been prepared in one location then connected to a network elsewhere only to then stop.

This issue was becoming a regular ticket for edge users on laptops especially but not users in Cloud environments with a static NIC so we have taken the decision to relax the MAC address requirement.

Users can now use a license key on different computers without fear of the device ID changing. It is still using public key cryptography so they cannot grant themselves extra time or more seats on a server as we’re not completely daft!

A license key now describes a customer, and expiry and a number of permitted seats for that server instance only.

Changelog

1.11.0 03/2026

• Deprecation: Removed debian:bookworm-slim container for testing GPU. Instead now uses the soothsayer-docker-core container.
• Deprecation: Prompt to set database password during install.sh removed. Password is now always automatically set to a randomised string.
• Deprecation: Removes unused and confusing LICENSE_SEATS_LIMIT, LICENSE_EXPIRY and LICENSE_CUSTOMER_ID keys from .env.
• Deprecation: Device ID has been relaxed.
• Feature: Added 3D tree coverage data for several European countries (Belgium, Denmark, France, Germany, Ireland, Italy, Latvia, Luxembourg, Netherlands, Norway, Poland, Portugal, Sweden, UK), and for the USA.
• Feature: Considerably reduced container footprint, reducing to 4 total containers with a total disk size of ~5GB.
• Feature: All containers, excluding database, adjusted to use common ubuntu:24.04 base image.
• Feature: Added SHARED_MEMORY_SIZE option to change the DEM tile cache size.
• Feature: Added optional DB_SHM_SIZE option to allow configurable shared buffer for PostgreSQL database.
• Feature: Added SKIP_SSL_CERTIFICATE_RESPIN option to skip SSL certificate respin.
• Feature: Added a check that the core container can reach the database.
• Feature: Added RAM/disk usage checks to start.sh.
• Feature: Added scripts/install-custom-dem.sh helper script.
• Fix: Phase-tracing made non-interactive in install.sh with ENABLE_PHASE_TRACING variable.
• Fix: Removed dependency for SOOTHSAYER to be installed when executing system-details.sh script.
• Fix: Automatically set data/license directory permissions during each start.
• Fix: Added maximum attempt catch when configuring GPU in install.sh.
• Fix: MapProxy container adjusted to deploy using with production-ready configuration, rather than serve-develop.
• Fix: Renames LICENSE_MAX_RADIUS, LICENSE_MAX_POINTS_LIMIT and LICENSE_MAX_BSA_RADIUS keys in .env to MAX_RADIUS, MAX_POINT_COUNT and MAX_BSA_RADIUS, respectively. This change was made to better reflect their usecase as they are not tied to licensing.
• Fix: Improved error handling within database migration files.
• Fix: Create GPU device nodes by running nvidia-smi in start.sh before bringing the containers up.
• Update: API 3.33.0, UI 3.26.0, CPU Engine 1.20.0, GPU Engine 1.15.0, 3D Engine 0.2.4, Midgard 1.0.0, Bouncyball 0.4.4, AntennaWizard 2.1.1, Analysis Utilities (QRM2, SuperTool & NoiseGen) 1.1.1, Documentation 2.11.0.
• Update: Database container updated to postgres:16.13-bookworm.

API

3.33.0 (2026-03-31)

• Deprecation: Legacy antenna validator and endpoints removed.
• Deprecation: html key no longer included in calculation responses.
• Improvement: Improved error logging for analysis utils.
• Fix: Tilt validation forced as an integer for some calculation endpoints. Should instead be a numeric to allow for floating point values.
• Fix: Missing noise data should return HTTP code 409 not 500.
• Fix: Custom clutter tiles not found by GPU engine.
• Fix: Broken transmitter icon within multisite public links.
• Fix: Fix issues with null noise names and group names.
• Fix: multilink API ignoring multiple azimuths.

3.32.0 (2026-02-11)

• Feature: Added frequency and partial to /noise/clear endpoint.
• Feature: multilink endpoint includes receiver antenna pattern.
• Feature: Added new multilink API for scalable mesh networks.
• Improvement: Replaced public URL Google maps with Leaflet and CloudRF map layer
• Fix: Set output.mod and output.ber to nullable when saving templates or MANET networks.
• Fix: When retrieving a template which is not using BER units, set output.mod and output.ber values to null to avoid them being used and causing issues in subsequent requests.
• Fix: Site and network names with numeric-only values are not being correctly interpreted as string length values.
• Fix: Handle upper-case and lower-case values for antenna polarity.

3.31.0 (2026-01-23)

• Feature: Antenna beamwidth (antenna.hbw and antenna.vbw) for area requests extended to lower limit of 1.0e-11.
• Feature: Improved azimuth validation failure message to highlight both single and multi-azimuth acceptance.
• Feature: Standardised validation messages of area, path, points and bsa.
• Fix: BER colour schema is unable to be used correctly for some area calls.
• Fix: Azimuth validation allows 0 through to 360, when it should be 0 to 359.
• Fix: Improved noise floor data-type casting for path and points requests.
• Fix: Improved points inversion to handle multi-azimuth for MANET requests.
• Fix: Added tilt inversion on points when using MANET requests.
• Fix: PPA calls not correctly appending _PPA to site name.
• Fix: Multisite calculations not applying txl.
• Fix: txl only applied when txg is present fpr path, points, and BSA requests.
• Fix: Fresnel zone incorrect when using imperial units
• Fix: Path calcs erroring without output.rad present in the request.
• Change: Path and points endpoints return an error, rather than a warning, if the receiver is underground.

3.30.1 (2025-12-30)

• Fix: Path API noise floor not handling strings
• Fix: Points API noise floor not handling strings
• Fix: Points API azimuth reversed to align with MANET tool

3.30.0 (2025-12-15)

• Fix: Reduced upper limit of BSA radius.
• Fix: BSA units can incorrectly be used with path and points requests.
• Fix: Removes acceptance of output.rad for path and points requests. Distance between points is used.
• Fix: Using output.out value of 5 (BER) with path and points requests leads to mismatched validations for output.mod and output.ber.
• Fix: Improved validation errors for points requests when missing receiver.lat, receiver.lon and points.
• Fix: Removed support for output.col on points as colour schema is not necessary.
• Fix: Removed required transmitter.lat, transmitter.lon and transmitter.alt values with points requests as they’re not needed.
• Fix: HF skywave endpoint always placing receiver in the eastern hemisphere.
• Fix: Noise endpoint incorrectly applying frequency filter.
• Fix: Public link layer export not centering on calcs with negative values.
• Enhancement: Added SNR21.dB colour key in support of ATAK plugin

3.29.0 (2025-11-10)

• Deprecation: Removes support for output.out, receiver.lat, receiver.lon, and receiver.rxs for BSA. BSA has its own measured units, and the receiver location and some radio settings are not necessary for BSA calculations.
• Feature: P.1546 replaced with P.1812 model.
• Feature: Added TREE tile type to support high resolution 3D trees.
• Feature: Opens up BSA calculations to all propagation and diffraction models, with the exception of FSPL.
• Fix: Using BSA without a colour schema was returning a received power colour schema. Default schema of BESTSITE.bsa is used as a default.
• Fix: Using BSA with an unknown clutter file doesn’t throw a validation error.
• Fix: Give calculation_adjusted message if radius is increased to be able to cover edges.
• Fix: Latitude and longitude values stored in the archive can lose precision in some circumstances.
• Fix: Requesting reprojected images with malformed metadata can result in source images being deleted.
• Fix: ERP is incorrectly calculated on a public link export.
• Fix: Network name always gets stored as BSA in the archive when running BSA. Now uses the network name.
• Fix: Return a 500 if there’s an issue with creating custom clutter.

3.28.0 (2025-09-04)

• Feature: Improved documentation on SOOTHSAYER DEM Manager.
• Feature: Added support for frequency filter on /noise endpoint.
• Feature: Default location updated to Ibiza.
• Feature: SOOTHSAYER system status page now shows services which are online but require a license.
• Fix: Public link export is returning a HTTP 500.
• Fix: SOOTHSAYER system status page is slow to load in offline environments.
• Fix: Increased maximum timeout for /merge and /mesh to be able to handle larger requests.
• Fix: Refreshed the warning message when clicking “Reset Database” in the administrator dashboard for SOOTHSAYER.
• Fix: Antenna favourite button is not obvious in the antenna manager.

UI

3.26.0 (2026-03-31)

• Feature: Add terrain selection to imagery layer selection.
• Feature: Noise manager improvements including a refresh button and a filtered delete.
• Feature: Loading templates with unfavourited antenna patterns will be be automatically favourited.
• Fix: Clear password field after submitting login form.
• Fix: Console error from requesting unavailable imagery levels.
• Fix: Signal tooltip missing for image layers larger than 16MP.
• Fix: Loading a template with a custom antenna pattern sometimes produces an incorrect antenna plot.
• Fix: Loading a calculation with a custom antenna pattern doesn’t change the antenna mode.
• Fix: HF Skywave templates unable to be saved.
• Fix: Loading calculations from the archive didn’t set receiver sensitivity and noise floor correctly.
• Fix: Loading AMSL calculations from the archive set the units to AGL.
• Fix: Very high feeder loss efficiency considered “Good”.
• Fix: Erroneous receiver sensitivity warnings when changing measured units.
• Fix: Missing calculations from network when opening archive.
• Fix: Noise floor and receiver sensitivity are no longer auto-adjusted when bandwidth is changed.
• Fix: Disabling MANET during calculation can result in rogue layers being left on the map.

3.25.1 (2026-02-25)

• Fix: Saving a template with a RCS value of 0 when not using RADAR
• Fix: Elapsed time in console rounded off

3.25.0 (2026-02-12)

• Feature: MANET links now calculated with a single Multilink request.
• Fix: Retrieving a layer from archive with the default colour schema.
• Fix: MANET link sensitivity mismatch when mixing units.
• Fix: MANET using stale values for reports when links disabled.

3.24.3 (2026-02-09)

• Fix: Added spin-lock to calculate button for GPU calculations.
• Fix: RCS value not sent for points API requests using RADAR.
• Fix: Multipoint links and route analysis imperial ASL logic moved to API
• Fix: Loading MANET network from archive reporting missing site.
• Fix: Improved handling of output.mod and output.ber when using BER units

3.24.2 (2026-01-15)

• Feature: Add automatic validation for noise floor input.
• Fix: MANET allows adding nodes with broken settings.
• Fix: API validation failure for output.ber and output.mod when using MANET.
• Fix: View reset working with D.M.S and MGRS

3.24.1 (2025-12-30)

• Fix: MANET marker offset when dragging
• Enhancement: fxaa smoothing applied to 3D terrain

3.24.0 (2025-12-29)

• Fix: Map resolution uses devicePixelRatio to fix aliasing
• Fix: FBR and RCS not being sent for PPA requests.
• Fix: BER and modulation shouldn’t be sent for PPA requests if not using BER units.
• Fix: Receiver sensitivity not necessary for PPA requests if using BER units.
• Fix: BER units not using BER colour schemas.

3.23.1 (2025-12-11)

• Fix: Units other than received power are not allowed with Best Server tool.
• Fix: HF skywave path profile tool ignore reliability and context.

3.23.0 (2025-11-10)

• Feature: Throw warning when receiver sensitivity lower than the selected colour schema.
• Feature: Improved guidance for how to get details of failed calculations during auto-processing.
• Fix: Auto-processing doesn’t support multi-azimuth.
• Fix: Auto-processing not correctly validating non-numerical values.
• Fix: Auto-processing incorrectly attempting to process values which have failed validation.
• Fix: “Antenna ID not favourited” link during auto-processing doesn’t work when using antenna name.
• Fix: Removed a phantom path profile legend entry with buildings, but not landcover, enabled.
• Fix: Separates RSRP and received power in chart as both use dBm

3.22.0 (2025-10-26)

• Feature: Organic 3D quantized terrain for CesiumJS
• Feature: Import noise manager.
• Improvement: Organic Geocoder for CesiumJS
• Fix: Disabling bounds leaves behind small artifacts on the map.

3.21.0 (2025-10-02)

• Improvement: ITU-R P.1546 superseded by ITU-R P.1812.
• Deprecated: Cesium ion data to be removed in October 2025 following hostile ToS update threatening audits
• Deprecated: Removed Cesium ion imagery for a selection of four including two user defined
• Fix: Using altitudes with fractional values on path calls ignores the decimals.

The post SOOTHSAYER 1.11 released appeared first on CloudRF.

A common question for novice planners is which RF propagation model is best for my technology?

We have many different users employing diverse technologies, time constraints and accuracy requirements, so it is not always a quick answer but knowing about the key types of models and where to use them makes a big difference to accuracy. There isn’t a one size fits all approach to model selection for radio planning but there are definitely good defaults…

TL;DR We now recommend ITU-R P.1812 as a default model.

To help answer this question in detail, we’ve decided to explain a little about each propagation model, describe some relevant use cases and then conduct a series of measurable experiments to compare model performance and offer practical recommendations for users who need a clear starting point so they can hit the ground running with their radio planning. In this blog, we will look at model types, when to use them and how to make an educated decision on which model to use for your radio project.

Communications Technologies across the EM spectrum

First it is important to understand there are vastly different use cases for radio technologies across the electromagnetic spectrum. Each of these technologies have their own spectrum requirements, frequency, bandwidth and power limits which have a strong influence over any potential coverage or point to point link. However, more impactful than this, is the environment and the varied ways in which they interact with radio signals.

Terrain, buildings and vegetation all interact differently with radio waves of varying frequency and different propagation models attempt to capture these behaviours in different ways. Older (1960) models pre-date developments in high resolution data so while they may adapt well to situations like their intended use, like downtown Tokyo in the case of Okumura-Hata, they will under perform in other scenarios without adjustments.

Because of this complexity, choosing the right model depends not only on your radio system but also on the environment you’re operating in. Below is a quick overview of common technologies and where they sit in the spectrum. We will look at environment latter.Communications Technologies

VHF (30–300 MHz)

Use case: Wide area voice comms, typically extending to the radio horizon.

Propagation at VHF frequencies is highly effective over long distances due to strong diffraction, good performance over undulating terrain, and relatively low attenuation through vegetation. These characteristics make VHF particularly well-suited to wide area narrow band voice networks and maritime or land mobile radio.

VHF applications can cover both broadcast and two-way communications with the former having significantly bigger antennas mast and transmission power.

LoRa / LPWAN (433 MHz and 868 MHz EU, 915MHz US)

Use case: IoT devices, low power sensors, hobbyist networking

Propagation at these frequencies is general better through vegetation compared to higher frequencies, allowing the signals to penetrate foliage with relatively low attenuation leading to good overall range while supporting modest data rates that are well suited to low power IoT telemetry applications.

L/S Band (1–2 GHz / 2–4 GHz)

Rough equivalent: Wi-Fi, Broadcasting, Tactical radios, Microwave links

Use case: IP based networking, voice, short to medium range data links

These frequencies typically support distances up to several kilometers, depending on antenna height, power, and environmental clutter. Propagation in this range is sensitive to buildings and clutter, which limits range in dense areas but still provides reliable line-of-sight performance for short to medium distance networking. These frequencies support higher data rates than VHF or sub-GHz bands but at the expense of reduced penetration through walls and vegetation. These bands support higher data rate technologies such as Wi-Fi, video streaming or autonomous drones/robots.

LTE / 4G / 5G (700 MHz – 2.6 GHz)

Use case: Mobile phones, tablets, broadband services

Propagation in the LTE bands offers a balanced compromise between range and capacity, allowing signals to travel several kilometres in outdoor environments while still maintaining the bandwidth needed for modern mobile broadband services.

Lower frequency LTE bands propagate further and diffract more effectively over terrain, whereas higher frequency bands are more affected by clutter and require denser cell deployments. This is why the uplink from the low power handset uses the lower bands as it has less path loss.

Because of this, LTE cells can have very different performance characteristics around terrain and clutter which makes choosing the right propagation model important.  

Across all these technologies, the environment is a key factor in determining how far or how well you can communicate. Propagation models attempt to quantify just how much the environment is going to affect the behaviour of a signal to help engineers build out these complex communications systems.

How do Propagation Models work?

Radio Propagation Models provide mathematical formulas to give predictions for the behaviour of radio waves between two points. Typically, each model aims to estimate the path loss along a link. Through recursive testing of adjacent points, a wide area can be studied to produce a signal map.

Prediction of path loss is necessary for radio engineers and operators to create accurate link budgets and generate functional communication systems or sensors. Across all models, there are two principles:

The common principle of free space loss is that path loss increases with both distance and frequency. The plotted curves below demonstrate this well.

The next principle is that each model has a unique path loss for an identical link. These curves are representative of an ideal test case of transmitting to a receiver with line of sight across uniform terrain.  

We can see different models give different results before budgeting for other sources of variation. In order to understand why this occurs we need to look at some of the key features of a model so we know when to select each one and how they work to use them effectively.

Parts of a propagation model

Each model is essentially an attempt to solve a planning problem for a communications problem. Sometimes these are very generic problems and others are tied to a specific technology and frequency range. This gives them very different reasons for existing. Bear in mind that some pre-date consumer computing! That leads researchers past and present to look for practical solutions which can come from theory or from practice to solve a wide range of communications research problems. This has led to two main types of radio propagation models: These are deterministic and empirical models.

Deterministic Models

Deterministic models are formulas which take input variables and consistently produce the same output as to opposed to “stochastic” models which are probabilistic. Researchers derive deterministic models from first principles and other phenomena to give the best possible representation of radio wave behaviour for a given set of assumptions and inputs. Both inputs and assumptions vary from model to model due to the complexity and motivation for the model.

For planners, this means the model always treats input factors consistently. It means that accurate inputs will lead to a high degree of accuracy in the output. The opposite, stochastic models, are more commonly used in fields like finance or weather modelling where there is uncertainty around a given input or future conditions.

Empirical Models

Empirical Models are data driven,built from survey data which is refined to produce a prediction of wave behaviour built on the prior observations. The advantage of these models is that they can act as ‘black‑box’ predictors that do not require describing the internal physics of the system yet still producing outputs that fit observed conditions.

The risk of using an empirical model is if it was made from tower data in a Japanese city and you use it with handheld radios in a desert, it will not perform well at all.

Input Parameters

For both types of models, there are assumed input parameters that planners need to choose for a model to be applicable for their use case. For users, it is often unclear what each setting controls or how to choose an appropriate context

While propagation models provide the mathematical basis for predicting radio performance, their accuracy is ultimately constrained by the quality of the environmental data fed into them. 

Even the most sophisticated model cannot compensate for incomplete or low‑resolution terrain and clutter inputs. This makes environmental data one of the biggest contributory factors in successful RF planning.

Terrain Data

Terrain refers to the physical shape of the earth such as hills, valleys, ridges and slopes. These features directly affect radio propagation through shadowing, diffraction, and reflection. Planning tools represent terrain using tiles sized according to their chosen resolution. In CloudRF, the resolution can be adjusted from the Output section, with higher resolution leading to larger compute times, bigger output files and more accurate representation of the world.

So, when to use a certain resolution? In CloudRF there are resolutions from 1m to 300m, however key thresholds to note are 2m, 10m and 30m which map to our source data.

• 30m global datasets. Suitable for coarse planning or large areas. Limited detail often causes over‑optimistic coverage in built‑up or rugged environments. CloudRF is preloaded with 30m DSM coverage for most of the globe up to 60N with additional high latitude data for Scandinavia and Alaska.
• 10m national datasets and space based land cover (trees etc). The balance between performance and accuracy for tactical and commercial use. Well suited for coverage maps with radii up to 10s of kilometres.
• 2m LiDAR. Highly accurate and excellent for urban, industrial or complex terrain analysis. Particularly beneficial for UHF deployments in cities or complex industrial/agricultural sites. Because most propagation issues occur when line‑of‑sight is obstructed, a high terrain resolution gives a close fit to the real environment.

Clutter Data and Contexts

Clutter describes man‑made or natural surface features that are above the terrain dataset—buildings, trees, industrial areas, bodies of water, or open ground. Different wavelengths interact with clutter in mostly predictable ways:

VHF and lower tend to penetrate vegetation more effectively but are still attenuated by dense structures. UHF, LTE and Wi‑Fi suffer greater attenuation from foliage and urban environments. LoRa and LPWAN rely heavily on clutter accuracy for predicting street‑level performance.

Within CloudRF, clutter is represented as classification layers with associated nominal heights and attenuation values. Selecting the correct clutter model ensures that urban and rural areas are treated appropriately, since the losses applied can vary dramatically between tree canopy, suburban housing, or high‑rise commercial zones. This allows for clutter tuning which can help with fitting survey/calibration data to a prediction.

Instead of clutter, empirical models (Okumura-Hata, COST 231 and Ericsson 9999) use contexts as factors to help tune their attenuation to an environment. These contexts are fixed empirical curves intended to represent the average path loss for a typical environment. These contexts are urban, mixed (suburban) and unobstructed (open ground). Because of this they will often not be terrain aware and in our experience do not adapt well to real clutter. The graphs below show how contexts can vary pathloss in ways that aren’t always intuitive.

Now we know what kinds of inputs our models are expecting, it is worth understanding the differences with the models available on CloudRF.

Model Bios

Irregular Terrain Model (Longley-Rice) 

The Longley-Rice model is an old but trusty general-purpose model developed to meet the needs of television broadcasting during the 1960s. As such, its input parameters have a focus on longer range high-low use cases. The model is named for its ability to account for terrain variations along the signal path. Naturally, ITM requires quality terrain data to achieve best performance. It can be used from 20MHz to 20GHz and has a range of 1-2000km for Antennas 0.5m to 3km in height.

ITU–R P.1812

The P.1812 model covers VHF and UHF bands and is recommended by the ITU since 2007 for terrestrial point‑to‑area services. The model incorporates Bullington multi-obstacle diffraction and is effective from 30 MHz to 3 GHz, making it well suited for modern commercial wireless technologies. Like the ITM, it factors in changes in terrain and incorporates clutter data into its calculations allowing it to perform very well when supplied with high quality terrain and clutter data.

General Purpose

The General-Purpose model on CloudRF is the ITU-R P.525-2 model with an additional 20dB of attenuation. The P.525-2 model is the ITU recommended free space attenuation model. It can be used across all RF frequencies from VHF up into 100GHz. With accurate clutter and land cover data, this model can be tuned to achieve single digit variation from field measurements in rural or suburban environments.  It is well suited to signals where both ends of a link are at ground level, like portable radio networks. This is outside of the comfort zone of typical high-low cellular models.

Okumura-Hata

The Okumura-Hata model is used for path loss prediction in urban environments. It is empirically derived and suitable for use around urban environments.

It assumes that the transmitter is much higher than the receiver. Specifically, 30m- 200m transmitter and 1-10m receiver heights for 1-20km. The frequency range of the original model is 150MHz – 1.5 GHz. These assumptions and range make this model best suited for cellular or broadcast environments. It uses an environment context to set its attenuation.

COST 231-Hata

This model is a popular extension of the Okumura-Hata model which brings the upper frequency to 2 GHz. COST (COopération européenne dans le domaine de la recherche Scientifique et Technique) began the Action 231 project to address the need to accurately model 2G mobile systems like GSM around 1995-1999. It was based data collected from multiple European cities to tune the model for urban environments. Because of this, it is best used in 1500-2000MHz range where the user is looking to model dynamic urban environments where LOS is often obstructed. Like the Okumura-Hata, it uses environmental contexts to be tune its attenuation.

Ericsson 9999

Ericsson extended the Hata model to 1900 MHz with special attention to the 4G and LTE use case in urban environments. Like the COST and Hata models, it’s environmental parameters can be adjusted for account for different scenarios such as rural, suburban or urban environments.

Egli VHF/UHF

The Egli model was developed by John Egli based his research with the US Army Signal Corp Labs in the early 1940s. The old model is empirically derived by capturing real world path loss across irregular terrain with dispersed clutter such as trees, buildings and other structures. The model typically expects 30-300m tall base stations to a mobile station at 1.5-10m height. Egli is suitable for VHF and UHF high-low cases below 1.5GHz. Unlike other empirical models on this list, it doesn’t use environmental contexts, so it is best suited for open rural settings.

Model Bios Quick Reference Table

Propagation Model Bake Off

To help us make an informed model choice, we will conduct a series of tests using real world measurements and comparing model performance to our measured data. From this we will be able to compare results across models and see well that work without diving into clutter tunning. This will lead us to the point where it is possible to make a clear recommendation on what propagation model to choose to start a project.

Defining accuracy

To grade a model, we need to understand what values indicate an accurate model. When collecting measurements from the real world, there is always a hardware measurement error. Expensive test equipment is expensive for a reason and conversely a cheap SDR is unusable for power measurements.

For our tests, we expect a measurement error around 3 dB which would represent absolute accuracy.

A score of 3 – 6 dB would indicate an excellent result, 6 – 9 dB is a good match and up to 12 dB is ok. A score higher than 12 dB would be considered an inaccurate model and/or measurements.

Both the statistical mean and the Root Mean Square (RMS) are compared. Achieving a low mean is easy enough through over fitting results but a low RMS is much harder in an urban environment as high resolution clutter must be tuned to match diverse coverage results.

We will look at 41.5MHz, 200MHz, 800MHz, 1800MHz and 2100MHz which give us a broad frequency range to test across.

VHF (41.5 & 200MHz)

VHF broadcasting is an old and difficult problem where the long range and varying terrain can disrupt line of sight to the receiver. Power ranges are significantly higher and the antennas are mounted on very tall radios.

To test performance of models in the range, we referenced an ITU dataset collected by the ITU’s Study Group 3 which has a VHF broadcast data for various locations around UK, US and Europe. We will be using data from Ashkirk, Croydon and Emily Moor (41.5, 191.25, 196.25). Each area typically has over 1000 data points collected around the broadcast region, measured in field strength (dBμV). Using CloudRF, we can model expected field strength using a selection of models to see which best fits the data.

It should be noted that as this radius, terrain and clutter resolution is reduced on CloudRF due to commercial limits not present on a private server. However, as we have multiple large data sets, we can still be confident in our predictions if we see consistent performance results from case to case.

The first test involves a dataset collected from the Ashkirk broadcasting tower in Selkirkshire Scotland. The VHF antenna sits 192m above the ground, so it is very high compared to cellular or handheld radio use cases. The receive antenna is fixed at 4.3m, which will make it taller than most trees and clutter in the area. The data set contains 534 data points within an 80km radius of the tower.

Ashkirk (41.5MHz)

• ITU-R P1812 (Mean : -3.7 dB, RMS: 7.2 dB)
• General Purpose (Mean: -4.7 dB, RMS: 8.3 dB)
• ITU-R P.P525 (Mean : 9.3 dB, RMS: 11.6 dB)
• Egli (Mean: -11.6 dB, RMS: 13 dB)
• ITM(Mean: -0.5 dB, RMS: 16.5 dB)

Croydon (191.25 MHz)

The second test involves a dataset collected from the Croydon transmitting station in Upper Norwood, London. The VHF antenna sits at 137m above the ground, so it is very high compared to usual use cases. The receive antenna sits at 9.8m, which places it well above most buildings and landcover expect for dense urban areas like London. The data set contains 2000 data points within a 145km radius of the tower.

• ITU-R P.1812 (Mean: -2.1 dB, RMS: 11.1 dB)
• General Purpose (Mean : -0.2 dB, RMS: 12.9 dB)
• Egli (Mean : -11.7 dB, RMS: 17.4 dB)
• ITU-R P.525 (Mean: 13.7 dB, RMS: 18.8 dB)
• Irregular Terrain Model (Mean error: -14.3 dB, RMS: 42.8 dB)

In this second test, we can see that our only acceptable prediction is P.1812 which will require further calibration to be tuned for this environment.

The third test uses data from the Emily Moor transmitter which broadcasts to the Yorkshire area. The data set contains 2000 points within a 100Km radius. The transmit height is 305m and receive height is 10m.  

Emily Moor (196.25 MHz)

• ITU-R P.1812 (Mean: -2.5 dB, RMS: 8.3 dB)
• ITM (Mean: -1 dB, RMS: 10 dB)
• ITU-R P.525 (Mean: -5.2 dB, RMS: 11.1 dB)
• Egli (Mean: 11 dB, RMS: 14.5 dB)
• General Purpose (Mean: -14.8 dB, RMS: 17.7 dB)

From our third data set we can see that P.1812 gives the best prediction again for these conditions. The significant heights involved worked against the ground based GP model but favoured ITM, developed for TV broadcasting.

VHF Conclusion

From our testing, we can see that without calibration, the models produce variable results with the test data sets. However, the one consistent exception is ITU-R-P.1812 which gives a mean measurement error of -2.76 dB with an RMS of 8.8 dB. For this range and complex environment, this is a good result which can be improved further with clutter tuning.

We can also see that our mean and root mean square values are higher than the few dB we would expect in a cellular model eg. 6dB. This is acceptable in this case as we are working over a very large area where the standard deviation of our results will increase as our resolution expands. With a large amount of diverse data points, localised errors can be diluted to establish consistent performance across data sets.

Looking at our selection of models, it is not surprising to see P.1812 outperforming the rest. Egli is a 1950 empirical model for VHF broadcasting, however it is not terrain aware so will tend to under/over attenuate through irregular terrain. Free space (P.525) will tend to be over optimistic over long distances and the added attenuation for General Purpose is better suited for handheld radios amongst clutter. So naturally, for CloudRF uses, we’d recommend starting with ITU-R P.1812 when working with VHF.

800 MHz (LoRa, UHF, Cellular)

For this test, we will be using an LTE band 20 (806MHz) transmission tower with RSRP measurements taken from test handsets located with a 3 Km radius of the antenna. The Antenna itself is sitting at 12m above the ground. This serves as an excellent test of lower frequency LTE, 3G and LoRa (868MHz). Using field measurements, we will make predictions using Cloud RF and then use the calibration tool to see the average and RMS errors to see if we have a good fit between our model and our data.

The models we will test are: General Purpose, Irregular Terrain Model, ITU-R P.1812, Okuma-Hata, Ericsson 9999 and Egli. We won’t be testing COST 231 as the test data is below its intended frequency range of 1.5GHz -2GHz.

The area of interest is located to the south of the village of Wroughton, which is South of Swindon. The site sits in an open field surrounded by fields and a solar farm with good inter-visibility around the former airfield. The village of Wroughton sits to the north in the shadow of a hill, so we would expect to only see a little coverage through diffraction to the north with stronger coverage to the west, south and east being broken up by hedgerows and sparse buildings.

Wroughton (806 MHz)

• General Purpose (Mean : 2.6 dB, RMS: 3.6 dB)
• Egli (Mean : -3.4 dB, RMS: 5.7 dB)
• ITU-R P.1812 (Mean : -6.5 dB, RMS: 7.7 dB)
• Irregular Terrain Model (Mean : 12.1 dB, RMS: 12.7 dB)
• Okumura-Hata (Mean : -37.7 dB, RMS: 37.9 dB)
• Ericsson 9999 (Mean : -37.7 dB, RMS: 37.9 dB)

Results

From the test, we can see that General Purpose and ITU-R P.1812 are good fits for the data, offering single digit variance. The ITM prediction is under attenuating and giving stronger coverage over similar areas to the general purpose and ITU-R P.1812. We can also see that Okumura-Hata and Ericsson 9999 are over attenuating, and we aren’t seeing coverage in the area around our readings at all.

To understand these results, we can go back to their intended use cases: Okumura-Hata and Ericsson 9999 models are intended for built up urban environments and expect more obstacles and chances for diffraction. For the test template, we are using an average/mixed profile which maybe over attenuating our predictions without the environment providing enough paths for diffraction. If we look at the area of the test, we can see there is very few buildings with plenty of open fields and trees. If the context is adjusted to unobstructed, both Okumura-Hata and Ericsson 9999 should yield a better fit to our test data.

• Ericsson 9999 Unobstructed (Mean: 2.4 dB, RMS 3.5 dB)
• Okumura-Hata Unobstructed: (Mean : -6.8 dB, RMS: 7.6 dB)

By changing the context, we can see that both models now fit the data well.

UHF conclusion

CloudRF recommends ITU‑R P.1812 or General Purpose model for modelling the 800 MHz range. Our experiment supports this, demonstrating that both models provide reliable results when paired with quality clutter and land cover data.

As this test shows, empirical models such as Okumura‑Hata and Ericsson 9999 can be difficult to use without reference data because they depend heavily on selecting the correct environmental context. Without field measurements, you must rely on your interpretation of the environment to decide whether a model should be treated as urban, suburban, rural, or unobstructed. This requires time, experience, and careful reading of the model documentation especially when planning in remote or complex areas.

Deterministic models, on the other hand, have shown to perform consistently when supplied with good‑quality terrain and clutter data. As we continue conducting field tests, we are becoming increasingly confident in recommending ITU‑R P.1812 as a robust starting point for modelling LTE Band 20 (800 MHz) and similar low‑frequency systems. Because it is terrain aware and It offers good accuracy even before calibration, which makes them highly useful for time sensitive planning tasks. Additionally, as better LiDAR and DTM data becomes available, these models will increase in effectiveness as legacy empirical models become obsolete.

Snow covered trees

Taking the test up a gear to the Arctic circle, we collected LTE survey data using the RantCell survey app from the top of Finland across multiple bands to investigate the accuracy impact of thick snow on trees.

Snow is a lattice of water which reflects and attenuates RF so is challenging to simulate, especially as it changes!

The field data collected gives us RSRP (Reference Signal Received Power) from two LTE bands (band 1 and band 3) from our tower of interest. This gives us a good opportunity to use one data set to calibrate a model and then use the second set to see if model prediction performance remains consistent across frequency. The frequencies of the two bands do make model selection more limited as band 1 (~2.1GHz) sits above the threshold for Okumura-Hata, its extension COST-231 and Ericsson 9999.

For the data itself we are looking at a small section of coverage near the tower surrounded by large snow-covered trees in undulating terrain. The collection was performed on a ski track under the trees which was often covered by a tree canopy.

The signal RSSI was calculated as 30dB above measured RSRP using the known 20MHz bandwidth and the data fed into our calibration tool to plot the points. From the app’s data, we know the LTE bands for each of our data sets, so we have a centre frequency and bandwidth. Using the photograph of the mast we can approximate its height at 60m. With the mast location set, we can then make two sets of predictions for both 1820 MHz and 2140 MHz down links and compare model performance across both. We will use P.525 as our free space reference model.

1820 MHz

• ITU-R P.1812 (Mean: 2.3 dB, RMS: 6.8 dB)
• Irregular Terrain Model (Mean: -2.8 dB, RMS: 7.1 dB)
• ITU-R P.525 (Mean: -9.3 dB, RMS: 11.3 dB)
• Ericsson 9999 (Mean: -8 dB, RMS: 10.5 dB)
• General Purpose (Mean: -23.3 dB, RMS: 24.2 dB)
• COST-231 (Mean: -43.9 dB, RMS: 48 dB)

When comparing the predictions to the 1820 MHz data sets, we can see that P.1812 and ITM are close predictors of the measured values. Additionally, when Ericsson 9999 is used with an average/suburban context, it gives an okay estimate, but has a much smaller coverage area overall, suggesting that more tuning is required to better match the attenuation caused by the large snow-covered trees. General Purpose is over attenuated which was not surprising given our free space path loss is a close fit and the 20 dB offset was added following tests with ground based tactical radio networks, not 60m masts. COST-231 is unusable which was expected given it is well outside it’s intended environment.

To test consistency, we can now look at the test results at 2140 MHz. Unfortunately, we can’t include Ericsson 9999 or COST-231 as the operating frequency is too high. However, we can test the Stanford University Interim (SUI) model which is rated for above 1.9 GHz.

2140 MHz

• ITU-R P.1812 (Mean: -5 dB, RMS: 9.2 dB)
• Irregular Terrain Model (Mean: -5.1 dB, RMS: 9.6 dB)
• ITU-R P.525 (Mean: -9.4 dB, RMS: 12 dB)
• General Purpose (Mean: -23.4 dB, RMS: 24.6 dB)
• SUI (Mean: -69.3 dB, RMS: 72.9 dB)

From this comparison, we can again see similar results. ITU-R P.1812 is again providing the best prediction, followed closely by ITM. The observation for P.525 and General Purpose remains the same. The SUI model is heavily over attenuating using an unobstructed context. This is not surprising when looking at the generic path loss graphs shown previously shown. SUI has consistently been the most conservative microwave model in our collection and based on the performance in comparison with other models it will be retired from our API in due course.

LTE conclusion

Looking at the two set of predictions, we can see consistency in performance from both P.1812 and ITM with P.1812 giving the best fit. Their coverage maps are generally consistent shapes with themselves and each other and we see more attenuation through the trees at our higher frequency as expected.

Our two models are showing their utility by giving accurate predictions despite heavy snow based on terrain and clutter data alone. The next question for these two models now is how to tune the clutter for each frequency for a better match.

Key findings for choosing a Propagation Model

Having conducted tests across six locations with different datasets and frequencies, we’ve gained insights into how each propagation model performs. The results of those tests have been broadly consistent with deterministic models like ITU-R P.1812 and its legacy predecessor ITM being consistently accurate before calibration and clutter tuning.

The old empirical models can be accurate, but they require the correct context to make an accurate prediction and without test data, it is difficult to tune them to their respective environment due to their fixed path loss curves. This is why we are recommending ITU-R P.1812 as our default model for VHF, LoRa and LTE propagation when using Cloud RF. You can still use Empirical models, but you’ll have to commit to collecting field data for tuning.

To further improve accuracy, users can tune our clutter profiles with variables such as tree heights or average attenuation through buildings. To understand where these values come from, please check out our past model and clutter improvements blogs or if you want to accelerate the process, see our calibration with machine learning demo with sample code on our Github.

What about Machine Learning?

The promise of Machine Learning models to improve accuracy (and speed) is tempting but it depends upon an enormous quantity of accurate training data. In our experience, ML researchers struggle to generate the vast quantity of accurate and expensive test data needed to develop even small demos.

Given enough training data, an ML model could be quicker and just as accurate as physics based simulation or potentially a drive survey.

However, it is naive to criticise the performance of physics based simulation in favour of ML as the model generation relies upon the former to train the model which creates a dichotomy whereby ML developers need to both criticise, and rely upon, simulation tools to develop an accurate model (and secure funding). There is a solution to this which requires academic honesty and a mature and scalable API but one of those requirements is harder to come by than the other.

Further Reading

Fast simulation calibration with Machine Learning

Model and clutter improvements

SG 3 Databanks – ITU

CloudRF model menu

The post Choosing an RF Propagation Model appeared first on CloudRF.

We conducted a field test in the mountains with SOOTHSAYER focused on automation and endurance. The test generated quality data and revealed altitude issues with our plugin we have since fixed.

We conducted a field test in the mountains with SOOTHSAYER focused on automation and endurance. The test generated quality data and revealed altitude issues with our plugin we have since fixed.

During the test we created 925 multi-site coverage heat maps and 4625 links to maintain a live map of the network. We previously established model accuracy on previous field tests so the focus here was on endurance.

Live network mapping is radio planning without user interaction where radio locations and coverage are updated dynamically via an API. It requires fast and economical edge compute like our SOOTHSAYER API to be effective and is not possible with legacy desktop tools.

This offline edge capability is implemented in our ATAK plugin via the Co-Opt feature. This new feature updates network coverage automatically using live map data to provide a current view of communications problems and opportunities, akin to a moving weather layer. It is useful for deploying radio networks into challenging terrain.

Test objectives

• Collect performance data
• Prove software stability
• Test altitude logic

Test setup

Hardware

The edge compute used was a Nvidia Jetson NX 16GB onboard a Cardshark rugged computer with an external Wi-Fi adaptor to provide an access point for the phone client.

The computer was powered by budget USB-C powerbanks rated at 13000mAh and 25000mAh respectively.

The test phone was a Samsung Galaxy S23 connected via the Jetson’s Wi-Fi.

Software

The offline software running on the Jetson’s Jetpack 6.1 OS was SOOTHSAYER v1.10, deployed as Docker containers. The resource intensive 3D engine container was not needed here so was disabled.

Services for a CoT simulator, a low power 5GHz Wi-Fi access point and a performance logging utility were running.

On the phone we ran ATAK 5.6.0.12 (Play store) with our SOOTHSAYER ATAK plugin version 2.7a.

Reference data

The Jetson was pre-loaded with 30m SRTM1 DTM and 10m ESA Land cover data for the mountainous test area. The phone used cached Openstreetmap mapping and 30m SRTM1 terrain data.

Test route

The area chosen was the Glenshee ski resort in the Cairgngorms national park, Scotland during early February where temperatures up the mountain were -10°C (14°F). A 16km circular route was followed which provided challenging conditions to meet the objectives.

Test data

Using the onboard Tegrastats utility we collected detailed data about workload, temperature and power consumption which will inform future designs and recommendations.

The day was split between two test profiles for the morning (0900 to 1300) and the afternoon (1345 to 1600).

Each profile used 0.5 megapixel resolution which for a multi-site request with 5 nodes would require the analysis of 2.5 million points using the ITU-R P.1812 VHF/UHF propagation model which includes diffraction.

In the first test profile, a calculation was triggered if a radio moved more than 200m. This is an economical way of working designed to extend battery life and reduce bandwidth if working across a network.

In the second test profile, a calculation was triggered on a 10 second interval. This is a more intensive way of working which provides regular updates.

Processor load

As expected, the CPU and GPU load was more intense for the fixed interval than the responsive profile. The spacing during the responsive profile in the morning shows our slower progress on the ascent followed by rapid progress as we moved across the plateau and the server worked harder to keep up with us.

SOC Temperature

The internal SOC temperature chart was also predictable as the unit was inside a waterproof bag inside a rucksack. It climbed steadily during the ascent, then dropped sharply as we stopped to make a video where it was removed from the rucksack briefly.

The unit temperature leveled out at 53 degrees Celsius inside the rucksack. It was not an ideal place to achieve cooling but given the winter conditions, quite acceptable judging by the data. A temperature of 80 degrees would be hot.

In the afternoon the unit was attached outside the rucksack in the waterproof bag where it leveled out at 32 degrees Celsius. The moment the rucksack was placed inside the vehicle before 1600 is evident as the temperature climbed steadily. This coincided with it being placed under an intense load during a driving demonstration we have published on our Youtube channel.

Power consumption

The most valuable data was power consumption which showed some interesting features and very encouraging mean values. The afternoon profile was more intense but did not increase peak power consumption which was actually lower than the morning for reasons which were not immediately obvious.

Following inspection of memory consumption (~25%), the reason was assessed to be a GPU memory leak triggered by unplanned “Above Sea Level” (ASL) calculations which occurred on the ascent. A large calculation needs more memory, which draws more power. Unlike the CPU engine which is called on-demand, the GPU engine runs continuously and its memory consumption can grow with use. In this case power consumption grew by 250mW whilst delivering 925 heat maps which we’re happy with.

The afternoon was not affected by the ASL memory leak so we maintained a steady even profile at around 7.5W power consumption, well within the range of a phone power bank.

Test videos

A video of select moments from the edge compute field test has been published on our Youtube channel. Following the field test, we created a bonus video of the drive home as the server was still running in the vehicle. This second video demonstrates the Co-Opt feature running with a 5 second refresh on a vehicle moving at up to 50 mph.

Issues

Plugin altitude logic

During the ascent we noted our own position marker, sourced from GPS, jumped from Above-Ground-Level (AGL) defined within our template to Above-Sea-Level (ASL). This was due to logic inside our plugin designed to handle aircraft.

The logic compares reported (GPS) altitude, measured in WGS-84 Height Above Ellipsoid (HAE), which is known to be inaccurate, with (ATAK) terrain height and if the difference exceeds 120m / 400ft, it uses ASL units and overrides the template’s receiver altitude to the local terrain altitude.

For more information on Height Above Ellipsoid see this article.

// If Height AGL is > 120m / 400ft, this is probably flying so we switch units to meters AMSL and use GPS altitude

if (altitude - terrain > 120.0) {

  marker.markerDetails.transmitter?.alt = altitude.toDouble()

  marker.markerDetails.receiver.alt = terrain + 1

  marker.markerDetails.output.units = "m_amsl"

} else {

  marker.markerDetails.output.units = "m"

}

This risky logic made sense from the comfort of the office with a GPS simulator but was a mess on the mountain with real GPS altitudes. The synthetic CoT markers were unaffected as they report a height above ground level.

As we went on to find, we were comparing an inaccurate GPS altitude with an inaccurate terrain altitude. Not exactly a recipe for success :/

ATAK API inconsistencies

Whilst on the mountain we noted a disagreement between our GPS altitude and ATAK’s reported altitude which warranted a deeper investigation. During the investigation we discovered inconsistencies with ATAK Elevation data.

The ElevationData class we, and no doubt other developers, were using was deprecated and apparently removed in 5.6 despite being in the Hello World demo for that release. We were using this with the getElevation() method which returns the height in meters above the WGS-84 ellipsoid (HAE).

val dtmFilter = ElevationManager.QueryParameters().apply {

  elevationModel = ElevationData.MODEL_TERRAIN

}
val terrain = ElevationManager.getElevation(currentMarker.point.latitude, currentMarker.point.longitude, dtmFilter)

The recommended replacement for ElevationData based upon public source code for 5.5 is the ElevationChunk API. There are no public examples for implementing the recommended alternative at the time of writing although references were noted in documentation before it was deprecated in 5.3 which needs clarification.

DTED or SRTM?

The deprecated method used was evidently returning a value based upon low resolution DTED0 data at 1km resolution. This was less accurate than the 30m SRTM1 (DTED2) data which ATAK tools like the range-bearing elevation profile or cross marker (X) use. SOOTHSAYER uses SRTM1 also.

ATAK 5.6 was found to be referencing different datasets for the same position between its interface tools and programming API which was frustrating. To prove this we pulled both the raster tiles and used GDAL’s location info utility to plot the differences for the route.

At location 56.875932, -3.377869 we experienced a large height error when the plugin fetched a height of 879m HAE yet the GPS reported 997m HAE (visible in the screenshot above). The massive 118m difference is just shy of the 120m needed to trigger our “airborne” logic.

The GPS measurement accuracy in the z-axis was measured to be inaccurate by at least 10m as the real altitude was 1007m ASL so it appears we had an altitude error greater than 120m during the ascent. A notable error which affects other GPS apps.

gdallocationinfo n56.dt0 -wgs84 -3.377869 56.875932
Report:
  Location: (37P,15L)
  Band 1:
    Value: 879

Digging into ATAK’s preferences we found validation for our theory via the “Pull Elevation Mode” option within Elevation Overlays Preferences. The choice between DTED and Highest Resolution suggests this was implemented to support better than DTED data eg. SRTM1. It is not clear if it references DTED0 or SRTM1, which as we’ve shown could be a +100m error.

Some batteries are better than others

Our goal was to use flight-safe USB power banks which can easily provide the 7-8W of power needed to run the capability. We ran soak tests in the office to establish a battery life of 6 hours for the smaller 45wH battery. We expected this to be reduced on the mountain so purchased a larger 92wH battery but it failed after 4 hours despite being kept warm inside an insulated jacket.

The smaller battery proved its worth and ran for two hours with only 35% consumption suggesting it would have lasted longer than the larger battery.

During subsequent charging of the large battery it reported unexpected levels suggesting it was likely defective and under performing.

Our conclusion was that you can live-map a network for more than four hours on a small battery, but it must be a reliable one.

Conclusion

We were happy with the test and the results which showed solid stability and good power economy. It validated the hardware, the SOOTHSAYER API and most importantly the concept of edge coverage mapping.

Given the accuracy issues experienced with GPS data and the deprecated-yet-still-going elevation APIs using low resolution data sources, we have commented out the error prone “airborne” logic in our plugin and will only use the fixed altitude(s) defined within the radio template until further notice.

Plugin users can edit both the transmit and receive altitudes above ground level by selecting the marker then clicking the pencil.

The ATAK plugin has already been updated and pushed to our Github repository and Google Play as version 2.7.1

The post Live network mapping endurance test appeared first on CloudRF.

Radio Direction Finding (DF) is the art of determining the location of an emitter and is used in search and rescue, coastal surveillance, law enforcement and defence. There are different techniques using power and phase but the output for a single sensor is normally a Line of Bearing (LoB) which points towards the emitter.

If you’ve ever seen DF depicted in marketing or an info-graphic, you’ve likely seen three geometrically distributed sensors surrounding an emitter which produce a high accuracy position fix (PF) where their lines of bearing converge.

In the real world, DF systems are expensive and require specialist training so are in short supply. It is far more common for these systems to be used in isolation so operators must determine an emitter’s location with a single LoB and a map study. For powerful signals, the search area could be vast.

Guessing the signal power

For a signal to be tasked for DF, it’s frequency is already known. With signal classifiers increasingly integrated into receivers, and now even open source, the signal type may well be known which helps answer a key question: what is the signal’s transmit power?

When a new signal is detected, it could be in the room next door or in the next county. Knowing the signal type and ideally the hardware is key to estimating the distance, as you can lookup the possible power levels from a data sheet.

A portable radio has variable power levels: For a DMR radio with low and high power at 0.1W and 4W these can be put into a basic path loss model to determine the possible distance. Using the Friis reference model with a detected signal of -80dBm for example, a 1GHz signal could be 2.4km or 15km away in free space.

This significant variation with the possible distance is where modelling can add value to reduce the vast search area.

For the example radio, these power values in Watts must be converted to decibel milliwatts (dBm) for consistency with the path loss modelling and to establish the range in decibels which will inform simulation parameters. In this case, low power is 20dBm (0.1W) and high power is 36dBm (4W) for 16dB of uncertainty.

In an obstructed environment such as a forest, this uncertainty represents a shorter distance than in free space where again, modelling can add value. A counter drone system is an example of a free space problem.

Link reciprocity

A radio link is not symmetrical due to how and where obstacles impact the fresnel zone which is the cone of power an element radiates. Even if you have line of sight (LOS) between two even power stations, you can still get different received power levels from A to B than B to A.

This matters as we cannot model the emitter since we don’t know where it is! We can only model the receiver location.

In our experience, the difference is measured in single digits and is small compared with noise which will make a bigger impact on a link’s viability. If you are operating at the edge of a system’s link budget then the reciprocal difference may be enough to make a link one way only.

For modelling a receiver we need uplink (talk-in) measurements instead of downlink (talk-out) which we normally collect for clutter and model calibration.

Field testing

We conducted several field tests to integrate our API using a budget commercial DF receiver, the KrakenSDR. This compact entry level unit gave us a LoB (with 8 degrees of error) we could work with but as it used 8-bit SDRs, we could not rely upon the received power level as low resolution SDRs can not represent weak signals.

After a false start with a 12-bit SDR designed for the amateur community and interfaced with SoapySDR, we used a professional RFEye receiver which aside from having superior measurement accuracy and sensitivity is a turnkey solution with a web API which we have integrated with our API previously.

Test system

Our test system grew in scope from a Kraken with a Pi to a network in a box with a bespoke management and signal logging interface. Key to this innovation was not creating a budget DF system which we needed to collect data but the employment of an edge modelling capability on a Raspberry Pi 5.

Our goal was to develop a hardware agnostic script which our customers could use to enhance their DF data.

Hardware

• The Line of Bearing came from a KrakenSDR with a circular 5 element array upon a 2m telescopic mast.
• The processor was a Raspberry Pi5 running our test software and SOOTHSAYER v1.10
• The radio traffic was generated by a Tait DMR portable radio equipped with a programming cable connected to a Pi4.
• The power measurements came from a CRFS RFEye connected to an elevated monopole antenna.
• A pair of sensecap meshtastic LoRa trackers were used for GPS tracking.
• A laptop and tablet running ATAK were used to manage the system and observe the output as a KML.

Software

To automate data collection, we developed test software to collect data from the SDR and DF receiver simultaneously and model them using our API. The DMR radio was configured to broadcast telemetry periodically which provided a regular target signal and the out-of-band meshtastic tracker provided a precise location within the trees.

We couldn’t use a second DMR radio to receive the telemetry as bi-directional radio traffic risked spoiling the data.

The modelling came from SOOTHSAYER 1.10 which was installed upon the Raspberry Pi 5. This also provided the map tiles for a web based logging system which displayed live signal readings. Only one (CPU) API call was necessary per test cycle to generate a grey scale Path Loss map in decibels (dB) from which subsequent received power heat maps in decibel milliwatts (dBm) could be rapidly derived using a simple formula.

The path loss simulation needs refreshing if either the location, frequency or height change but is power agnostic. The client script queries this path loss map using known (or assumed) radio power levels.

Results are presented as a network KML which can be consumed on standards based geo-viewers like ATAK.

Challenges

We took our ‘Temu DF system’ out twice but we couldn’t collect as much data as we wanted in the time available due to different constraints such as the weather or just running a small business.

A decision to avoid vehicles and buildings was made to avoid reflections which meant we had to run the equipment from travel batteries. The power budget for the Pi5 (30W), KrakenSDR (12W) and RFEye (5W) was 47W which was more than we normally test with so it reduced our endurance.

We encountered local radio traffic on our licensed channels due to the choice of locations overlooking the city. This was easy to discount at the start of the test when our signal was obvious but became a nuisance as it faded into the trees and ultimately tainted our test data since we were triggering on power.

Old data to the rescue

After several frustrating tests where a lot of time was spent climbing local hills, calibrating DF and chasing false positives, we elected to reuse a rich data set from an antenna field test last year which included bi-directional links for a UHF radio on a moving vehicle.

This data was attractive as it included the uplink and a good variety of obstacles including houses, trees and hills as well as LOS links which are all useful for calibration. Before we could conduct DF analysis with the uplink, we calibrated the local clutter using the downlink, as we do routinely for calibration. This is a standard process we have developed a feature for in the web interface as well as a supporting video tutorial. Using our new 2m tree height data, we were able to improve upon last year’s score.

As we did not collect lines of bearings during that model test, we had to simulate these using the known vehicle location for which we used 10 degrees of azimuth error.

Analysis technique

To compute the effectiveness of this technique we calculated the area of the 10 degree arc where the vehicle could have been, with a radius of 6km representing the maximum range in this test.

This gave us a search area for a given LoB of 3,141,593 m2.

Our analysis script calculated a high resolution grey scale heatmap using SOOTHSAYER’s API which was referenced with collected power readings. To compare path loss (dB) with received power (dBm) we used the known radio power of 2W (33dBm) within a link budget formula to generate received power which was compared with measurements.

RSSI (dBm) = Radio Power (dBm) + Gain (dBi) - Path Loss (dB) - Losses (dB) + Receiver Gain (dBi) - Receiver Loss (dB)

Where the difference between measurements and simulation was within tolerances of our colour key, we styled that pixel, otherwise we eliminate it from the search area and set it to transparent.

The result is an accuracy heatmap defined by a traffic light colour key. The levels we chose for our “known power” assessment were 1, 2 and 3dB. By showing 3dB of error we allow for receiver error and reduce the risk of false negatives where a matching location might be discounted.

When the radio power is known, we can produce more accurate results.

When the radio power is unknown and the hardware/signal is known, we can simulate the minimum and maximum power to generate a dynamic range for the analysis. We used a low power value of 20dBm (0.1W) and a high power value of 36dBm (4W) for a possible power range of 16dB so our “low accuracy” colour key was 14/15/16dB.

We repeated the analysis with known and unknown power levels to compare accuracy.

Results

Analysis of data revealed the simulation heatmap significantly reduced the search area. As expected, knowing the radio power helps greatly but even with unknown power the search area was reduced to 32% of what it could have been for a conventional 6km arc.

Even when radio power is unknown, the search area is reduced significantly

The amount of benefit was relative to the terrain and clutter: For example, where there were no obstacles or a single consistent obstacle such as a forest, the result was a focused band of probability without any false positives.

Where there were multiple obstacles such as a hill and a forest, false positives appeared which depending upon the ground could be discounted by an observer. This was to be expected given the pixel picking which is taking place.

A tight traffic light schema, with tuned clutter, was better than a loose schema with larger error margins. The reason being that it will show much less false positives.

Video and KMZ

This video is a sped-up compilation of time stamped KMZ layers viewed on Google Earth showing the vehicle’s route around the sensor. Where the vehicle disappears, no signal was detected.

The KMZ is available here and works best in Google Earth.

Conclusion

This testing proved that the effectiveness of a single LoB can be improved greatly with modelling but the concept is only an improvement if the analysis is automated as doing this manually would not be faster than a map study.

The reason this analysis isn’t performed regularly by DF systems today isn’t for a lack of LoBs and RSSI measurements but rather a lack of APIs with which to exploit this information. Current RF planning software exists as a user interface which requires manual, and skilled, operation. Furthermore, the capability often exists in the wrong location on a high performance desktop computer, disconnected from edge sensors.

By putting this API at the edge on small board computers (SBCs) such as the Raspberry Pi 5 or Nvidia Jetson, a DF system’s effectiveness can be improved. Through open GIS standards like KML, the result can be consumed on open standard GIS systems like ATAK requiring minimal integration effort to add a powerful capability.

Looking forward, we are speaking with open minded vendors about adding this API to enhance existing systems.

If you’d like to improve your LoBs, get in touch with us or one of our regional resellers.

Links

SOOTHSAYER server: https://cloudrf.com/soothsayer

Kraken SDR: https://www.krakenrf.com/

DF integration demo: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/integrations/DF

API schema: https://cloudrf.com/documentation/developer

The post Enhancing Radio Direction Finding with RF simulation appeared first on CloudRF.

Whether its survey drones, drive test vehicles or a police analyst with a backpack full of phones, the problem is the same: RF propagation surveys are very resource intensive. They’re more accurate than a simulation, but not more efficient.

Survey data is typically a GPS log with signal metadata including a signal strength value. This can be different measurement units but the principle is the same. It is data which shows the signal at a given point.

Surveying is preferred for good reason by some industries, especially for evidential purposes where the variables in simulation open the door to uncertainty which nobody wants in court. Another reason is legacy desktop simulation software is slow and often inaccurate, especially amongst clutter which is more complex than a topographical study.

For example, relying upon a high-low empirical model like Hata which pre-dates developments in clutter will get you ~8dB accuracy whilst calibrated survey equipment can get you ~2dB, or ~3dB for an app on a standard phone.

Manual calibration

Using survey data like the output of Rantcell’s survey app, we can load this into our web interface to perform calibration manually. This process involves adjusting model and/or clutter settings until the error between the simulation and the measurements is as low as possible. It’s an efficient process as you can test thousands of points in a single API call but also repetitive, interface based and requires engineer input to adjust clutter values for example. You can see manual calibration in action here.

A good calibration would be below 8dB. For more on calibration of survey data, see one of our many field test blogs.

Good survey data is thousands of points all around a site of interest. When we’re field testing, we choose our route to ensure we collect a diverse range of data.

The Pizza Problem

The pizza problem is when you only have a slice of data but need to infer the rest. This is very common in the real world where a customer may not be able to collect data all around a site for various reasons:

• Lack of time
• Lack of access
• Lack of resource

This limited data is then used to estimate what the rest of the coverage looks like. For an omni-directional antenna, it’s a good assumption. For a directional antenna, it’s clearly less accurate but crucially, it is about making the best estimate using available data.

If you can get more measurements, then do it. If you don’t have the time/resource, then simulation using calibration offers the best compromise. After all a ~7dB accuracy prediction is much more useful than no coverage at all.

A Machine Learning genetic algorithm

Using a slice of data, we can employ a basic Machine Learning model which uses a genetic algorithm to optimise settings. It works by starting with a range of fixed inputs (tower frequency, location etc) and a range of variables (power, tree height, building thickness etc) which it uses to make pseudo-random requests to our Area API.

The responses are fetched as greyscale open standard GeoTIFF images which are analysed using the rasterio library against the survey measurements. The delta between points is recorded as both mean and root mean square error.

The RMSE error is the key figure which describes the error between two arrays of results. Achieving a low mean is easier to do by over-fitting a model, but lowering the RMSE is harder for a diverse environment as clutter must be tuned to allow for trees, buildings and open ground. The script constantly updates a custom clutter profile at the API with new values in between requests.

Many tools won’t publish performance data as it would make it hard to justify their price tag. Some cannot do diffraction which disqualifies them for signals below 2GHz.

The requests are scored individually using RMSE and ranked. The best scores from the generation are selected to breed the next generation and so on until the (user defined) limit is reached. Therefore, the process can be scaled to offer a quick result for a live map or a thorough result for enumeration of unknowns such as tower height, power or even tower location using a search box.

At the end of the process, the best values for the variables are shown which can either be used to build a custom clutter profile, as we do in the demo video, or scripted further to make a final layer for a third party interface.

Demo video

Conclusion

Developments in data and performance, accelerated by GPUs, means accurate and fast simulation is more viable than ever. By being able to deliver this capability in seconds instead of hours, new integrations and capabilities are possible. Furthermore using a mature API, with public examples, makes an MVP viable in days.

Using a SOOTHSAYER server, this can be done at the edge without internet access.

A few ideas for new integrations which can leverage this concept:

• A spectrum analyser with a living coverage map
• A signal classifier which shows more than metadata
• An app which shows the impact of antenna adjustments in real time
• A robot which maintains a live coverage map which can inform route selection
• An RFPS analyst can be freed up from walking around to do some analysis

Credits

Thank you to Rantcell for providing rich LTE drive test data and our resident Machine Learning guru, AppyBara, for developing our automatic calibration client. If you would like a copy get in touch.

The post Fast simulation calibration with Machine Learning appeared first on CloudRF.

Offline data packs

Since we released pre-built images with 1.9, the setup effort moved from the software installation to the data. SOOTHSAYER uses elevation, landcover and buildings data on the backend and map tiles for the web interface.

Some customers have the luxury of local GIS teams and tile servers and are able to provide their own data but for many, they need help with sourcing and preparing this data. This where our datapacks comes in.

A SOOTHSAYER data pack is a compressed archive available on our support portal which unpacks to the /data/ folder allowing users to easily install pre-prepared multi-layer data from CloudRF.

Ibiza is back

Long time CloudRF users will recall we used to use the island of Ibiza as a start point and sandbox where users could evaluate the software at no cost. Now, data for the island is included to allow quality commissioning tests to take place. The data includes elevation, landcover, buildings and limited map tiles.

Enterprise authentication

When we implemented Active Directory previously, we hoped that the magic of standards, in this case Lightweight Directory Access Protocol (LDAP), would mean that this works with different servers. As it turned out, it only worked with Microsoft’s AD server and didn’t support groups. Some customers are using the open source alternative, FreeIPA, and all were making use of groups for Role Based Access Control (RBAC).

We’ve added support for FreeIPA, groups and Secure LDAP (ldaps) and provide verbose information in the web interface now to help admins quickly resolve issues which may arise with servers and permissions.

Security hardening

SOOTHSAYER is a cut of the CloudRF software, minus commercial restrictions, which receives security testing from the internet every single day, and has done for over 12 years. This public testing gives us a significant level of data and stress testing to improve our API.

One such area is login security which we’ve improved using NIST-800-53 guidance at the application layer to automatically block brute force attacks and lockout accounts. This functionality can also be implemented at the protocol layer with the web server along with rate limiting as we do on CloudRF.

We’ve taken the decision to remove unused third party features to reduce the attack surface, in this case the PGadmin web dashboard for administering the postgres database. This web app presented additional risk, confirmed by a CVE which appeared recently. Users who activated this optional component are advised to disable or upgrade it.

The postgres database can still be administered using third party clients by exposing its port within the docker compose file which should be protected with a firewall. By design, the database can not be accessed remotely.

SBOM

We’ve never been shy about showing off our software and it’s components. We ship a full manifest in an open SPDX JSON format to support risk assessments by smarter customers who make decisions with data not emotions. These tools are good but lack context and will report false positives for development libraries like Browserify and Cypress which are not used in production. If you have a query about a library in SOOTHSAYER, feel free to ask us.

Authentication endpoint

The user interface authentication endpoint has moved from the user interface into the API following a refactor so what used to be /ui/auth? is now just /auth? with the same parameters. This trivial but significant change will affect users of the ATAK plugin who will need at least version 2.1 with this release which is detailed on the plugin release. The endpoint accepts a username and password and returns a UID and API key.

Noise layer

Building upon the noise API we published, the user interface now has a noise layer which can be added to visualise the noise data from the database. The noise floor is visible within the tooltip and noise can be provided direct from cognitive radios, SDRs or spectrum monitoring systems. Several noise API clients are available on our Github page.

The reason for adding all these noise features will become apparent in time when RF heat-maps come alive instead of being frozen in time with an optimistic and common noise value across a city.

Noise is the biggest problem in spectrum management and if you ever find a hardware vendor who will admit this rather than sell you more radios (to compound the problem) stick with them.

Compatibility Matrix

Change log

• Deprecation: Removed pgAdmin (/dbadmin).
• Deprecation: Removed cniVersion host change for Podman versions no longer supported.
• Deprecation: Removed Cesium ion (3D terrain and buildings & Bing map layer) from the UI due to change in TOS.
• Feature: Official support for ARM-64 architecture.
• Feature: Added install-data-pack.sh script to allow installation of provided data packages.
• Feature: Added LDAP FreeIPA support.
• Feature: Added LDAP groups support.
• Feature: Added LDAP TLS option.
• Feature: Brute force protection for user and admin accounts
• Feature: Tile cache for the world to zoom 6 and Ibiza to zoom 14 with local DEM for offline tests/demos.
• Feature: Added PHASE_TRACING_ENABLED option to enable/disable the Phase Tracing engine and interface.
• Feature: Added USER_INTERFACES_ENABLED option to enable/disable user interfaces.
• Feature: Added conf.d directory within config/nginx-frontend to allow extensions of the frontend Nginx container.
• Feature: Added minimum version checking of podman and podman-compose during install.sh and update.sh.
• Feature: Prompt to allow host vm.overcommit_memory when using RHEL with Docker to allow GPU pass-through.
• Feature: Admin dashboard login uses same interface as user login.
• Feature: Throw warning in the UI when accessing from address different to SERVICE_FQDN value.
• Feature: Added maps.cloudrf.com contours cache to mapproxy.yaml.
• Feature: Running SOOTHSAYER update.sh will populate manual_update_steps.txt with any manual stages necessary after an update.
• Feature: Added system-details.sh script.
• Feature: Added MAP_PROXY_CONFIG value to .env to allow override of MapProxy in online and offline modes.
• Feature: SSL certificate is now automatically respun when the SERVICE_FQDN value is updated and contains a SubjectAltName
• Feature: UI uses MapProxy cache by default to address the blue map FAQ
• Feature: Automatic configuration of online and offline mode during install.sh.
• Fix: Get true users IP address in the logs of nginx-frontend container.
• Fix: Build failures when using Podman with some RHEL-based operating systems.
• Fix: UPLOAD_MAX_FILESIZE_MB is not persistent in some long-running environments.
• Fix: Some scripts contain unsupported Podman flags such as project directory
• Fix: Upstream MapProxy tile server fails occassionally when requesting via HTTPS.
• Fix: GPU containers are not starting on some versions of Podman due to lack of support for compose profiles
• Fix: watch.sh script is not working on Podman.
• Fix: GPU containers incorrectly showing as offline on Podman.
• Fix: Password validation during install.sh was incorrectly checking minimum length
• Update: API 3.28.0, UI 3.20.0, 3D UI 1.1.1, CPU Engine 1.17.1, GPU Engine 1.13.1, 3D Engine 0.2.3, AntennaWizard 2.1.0, Analysis Utilities (QRM2, SuperTool & NoiseGen) 1.1.0, Copy Protection 2.0.0, Documentation 2.10.0.
• Update: CUDA 12.1.0 container image deprecated.
• Update: MapProxy container updated to debian:13.0.

API

3.28.0 (2025-09-04)

• Feature: Improved documentation on SOOTHSAYER DEM Manager.
• Feature: Added support for frequency filter on /noise endpoint.
• Feature: Default location updated to Ibiza.
• Feature: SOOTHSAYER system status page now shows services which are online but require a license.
• Fix: Public link export is returning a HTTP 500.
• Fix: SOOTHSAYER system status page is slow to load in offline environments.
• Fix: Increased maximum timeout for /merge and /mesh to be able to handle larger requests.
• Fix: Refreshed the warning message when clicking “Reset Database” in the administrator dashboard for SOOTHSAYER.
• Fix: Antenna favourite button is not obvious in the antenna manager.

3.27.0 (2025-07-31)

• Feature: Terrain map changed to use OSM in dark mode.
• Feature: More LDAP configuration options for SOOTHSAYER, including support for Free IPA.
• Feature: SOOTHSAYER administration dashboard no login uses HTTP basic authentication.
• Feature: added /noise endpoint to allow querying noise in its raw format.
• Feature: Added name and group_name arguments when using /noise/create.
• Feature: Added group_name argument support when using /noise/get and /noise/clear.
• Fix: Noise data no longer expires. Instead it should be deleted if it is outdated.
• Fix: Added maximum limit of 1000 entries when submitting with /noise/create.
• Fix: Improved file efficiencies when deleting entire archive.
• Fix: Best Server with multi-azimuth antenna results in HTTP 500.
• Fix: Incorrect mp value being returned from preferences.php when used against SOOTHSAYER.
• Fix: /points request with a point too close to a receiver results in a HTTP 500.
• Fix: Return error if using bounds with a radius which does not cover the bounds area.
• Fix: Exporting public link for a MANET network has a single transmitter in the wrong location.

3.26.0 (2025-07-03)

• Feature: Added output-bounded CPU calculations.
• Improvement: Engine attenuation/diffraction logic optimised for higher accuracy & GPU speed
• Fix: Saving a MANET network fails with multi-azimuth.
• Fix: Antenna search is case-sensitive.
• Fix: Clutter profiles with spaces and underscores not used in calculations.
• Fix: Saving a colour schema with a name of an integer breaks the colour palette manager.
• Fix: 3D calculations incorrectly proceeding when model metadata is missing from the database.
• Fix: Deleting all data results in a failed rate limit check.

3.25.0 (2025-05-22)

• Feature: Noise maps for Area, path, points, multisite APIs. Use noise:database to activate
• Fix: Retrieving preferences not honouring values which are more recent.

3.24.0 (2025-05-20)

• Improvement: Landcover can be used out to 100km
• Improvement: Landcover can be used up to 60m resolution
• Improvement: SHP file max size doubled to support high resolution calcs

UI

3.20.0 (2025-09-04)

• Feature: Restyle login page.
• Feature: Import noise data.
• Feature: Added an error page for SOOTHSAYER when request host and configured FQDN do not match.
• Feature: Default location updated to Ibiza.
• Feature: Local mapping server added automatically to SOOTHSAYER UI.
• Fix: Coverage analysis not importing data.
• Fix: Saving template fails for environments without a GPU.
• Fix: Imported MANET nodes not rendering immediately.
• Fix: API requests to progress failing authentication.
• Fix: “Stop Processing” button for “Automatic Processing” gets disabled for all instances after pressing one time.

3.19.0 (2025-07-15)

• Enhancement: Rotate antenna template plots to match custom plot behaviour

3.18.0 (2025-07-07)

• Feature: Non-custom antenna plots are updated to show tilt/azimuth.
• Feature: Polygon bounds for area, MANET and BSA calculations.
• Fix: Clutter profile reset after using the custom clutter menu.
• Fix: Importing MANET results in immediate evalution, rather at the point of confirmation.

3.17.0 (2025-06-19)

• Feature: Live noise layer using the noise API
• Feature: Live noise reported on tooltip when data available
• Enhancement: Updating map selection. Default is contours from Thunderforest via maps.cloudrf.com
• Enhancement: Default thresholds when changing bandwidth updated to 5dBuv, 5dB SNR or noise +20 dBm
• Enhancement: Local tile server available as a custom layer vs a separate layer
• Fix: Loading preferences not adjusting receiver sensitivity slider, causing it to sometimes become out of sync with the true sensitivity value.
• Fix: Popup title during validation failure is not set, causing stale title to be used.

3.16.4 (2025-05-21)

• Fix: Adjusting bandwidth changed the noise floor in database mode.
• Fix: Hidden MANET markers can be moved without triggering API calls
• Fix: Marker is changed to Tx when clearing layers in route analysis or multi-point links mode.
• Fix: MANET tool SNR links are wrong way around.

3.16.3 (2025-04-16)

• Fix: HF Skywave endpoint used for other propagation models after switching back.

3D UI

1.1.1 (2025-07-30)

• Fix: Update authentication mechanism to make use of API /auth endpoint.

CPU Engine

1.17.1 – 2025-08-08

• Feature: Added output-bounded calculations.
• Feature: Antenna logic moved into shared library.
• Fix: Improved accuracy of downtilt angle for path calls where the receiver is above the transmitter.

1.17.0 – 2025-06-12

• Feature: Added new clutter diffraction/attenuation logic.
• Improvement: added support for noise geotiffs.

GPU Engine

1.13.1 (2025-08-08)

• Feature: Antenna logic moved into shared library.
• Fix: Improved accuracy of downtilt angle for path calls where the receiver is above the transmitter.

1.13.0 (2025-06-12)

• Feature: Added new clutter diffraction/attenuation logic.
• Improvement: Increased performance.
• Improvement: added support for noise geotiffs.

3D Engine

0.2.3 (2025-09-03)

• Change: Antenna logic moved into shared library.

0.2.2 (2025-04-16)

• Fix: Stability improvement to core algorithm

The post SOOTHSAYER 1.10 released appeared first on CloudRF.

• Dynamic radio coverage visualisation
• Vendor agnostic radio integration via ATAK
• 450 heat-maps delivered without issue
• Sub-second computation via Cardshark computer

Background

Three years ago we developed a “live” simulation capability using location-aware MANET radios which we described as dynamic radio planning which fused real and planned radio positions. This feature required a third party hardware API with restrictive terms, common in commercial radio, so it exists as a video demo only.

We’ve refreshed and field tested this concept, using modern edge compute and open standards.

ATAK as the common API

Using ATAK as a proprietary API broker, we are now able to do the same via our plugin. The technology agnostic capability can be used with any radio, vehicle or marker on the map and by starting with an open information standard, Cursor-on-Target (CoT), it eliminates the commercial friction with NDAs, proprietary APIs and different vendors.

Open standards unlock low-cost cross-vendor interoperability in a way proprietary standards never can. For example, two vendors can achieve compatibility without knowledge of each other’s products. Better still, compatibility with future products, not yet deployed, can be assured.

The field test

We picked a local Forest to field test this concept using a Cardshark computer which is a rugged Jetson Orin with a 1024 core GPU. We need the GPU to efficiently compute our ‘Multisite‘ network heat maps. The ‘Points‘ links are CPU powered. We’ve worked with Jetsons on previous field tests but under manual control. The automation we’ve added here makes periodic API requests and places the computer under a sustained load.

The radio network was a four Tait 9300 DMR portables on a 2W channel, with one donor radio connected via a USB programming cable. GPS locations were fetched using our Tait script which outputs CoT broadcasts to make them appear (and move) upon the map.

The testing went well and produced 450 heat-maps to validate both the concept and the computer. Crucially, our 9Ah battery depleted only by 25% during 2 hours of intensive testing. Our conclusion is that with a reasonable load and refresh rate this edge capability can be scaled to run all day, as we found in Scotland earlier this year.

Speed test!

Five years ago we asked for the ATAK KML refresh rate to be lowered to enable a “follow me” demo we published and our understanding is it was capped by design at 10s (compared with 1s for Google Earth) due to a concern over excessive bandwidth which was understandable – at the time. A lot has changed in five years of software and radios and now we’re doing the compute locally, this concern is obsolete.

Our GPU engine can model a heatmap in under a second so we bypassed the network KML functionality (which is still a valid way of refreshing heatmaps on ATAK as our Tait plugin does) and implemented our own refresh system, designed for fast moving data. During our speed test, we refreshed the heat-map every 5s which both ATAK and the Cardshark handled comfortably. Logs showed each simulation took under a second with another second for pre/post processing and another for communication. The points requests take 150ms and are called for each radio so four radios would be 600ms, excluding communication.

Issues identified

We identified issues relating to USB tethering which weren’t apparent in the office: The Cardshark does not have WiFi which we employed for previous field tests so this made communication more challenging.

We were able to workaround this for the test with a WiFi hotspot to fool the plugin into thinking it was on a network. As we were using dynamic IP addresses provided by the phone and the Cardshark has no interface, we ex-filtrated the IP information we needed via ATAK which is why there is a IP-address-callsign visible in the video.

The Cardshark is a fanless design which requires airflow to cool it. We deployed it in a bum bag / fanny pack where it unsurprisingly became hot during intensive use but still functioned well. For enduring use, this would need to be mounted externally and the workload throttled accordingly.

Our radio template needed work as only afterwards did we note we did not set the DMR template’s noise floor which defaulted to -133dBm based upon the narrow 12.5KHz bandwidth. This was why there were blue 50dB links visible in the video when in reality the noise floor was likely closer to -113dBm and these links were a more realistic 30dB SNR. This issue did not affect the heatmap which used received power units and we’re satisfied from calibrating with large data sets that the modelling is accurate.

Credits

A special thanks to GoTak LLC who helped us develop and test the live Co-Opt feature in ATAK and Carnegie Robotics for producing the Cardshark and providing timely support.

Links

SOOTHSAYER self hosted server: https://cloudrf.com/soothsayer

Cardshark computer: https://carnegierobotics.com/cardshark

SOOTHSAYER ATAK plugin: https://github.com/Cloud-RF/SOOTHSAYER-ATAK-plugin

Tait ATAK plugin: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/integrations/Tait

Fanny pack: https://www.osprey.com/gb/osprey-seral-7-s23?size=One+Size&colour=Black

The post Live RF coverage mapping with ATAK appeared first on CloudRF.