Posted on 2025-08-072025-08-07 by CloudRF

Live RF coverage mapping with ATAK

Highlights

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.

Mapping live radios in the SOOTHSAYER ATAK plugin

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.

Live RF coverage mapping with ATAK

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

Posted on 2025-05-232025-05-23 by CloudRF

Mapping Noise

Noise is the single biggest factor in determining the quality of a communications link. It’s also the reason why there is low confidence in the accuracy of (RF) simulation in complex environments as it’s rarely done well, if at all.

Budgeting for noise is critical to achieve desired signal levels. Historically, it was done with a single figure to satisfy all locations, eg. ‘-100dBm’. This simplification is a time/accuracy trade-off and is no longer relevant in the age of dynamic spectrum management and cognitive radio.

Noise varies widely between locations, and changes constantly, so we have invested in developing living noise maps to reflect this dynamic nature. Like a terrain layer that moves, noise data can be used to improve the accuracy and relevance of planning in dynamic environments.

Using SDRs and APIs to improve simulation accuracy with live noise

Evolution of simulating noise

A noise figure (2022)

Back when we added Signal-to-Noise (SNR) output units in API v2.7, we needed to express the noise floor as a (dBm) figure to provide a reference for a signal’s quality eg. 15dB. Users interested in SNR enter a single value like -100dBm, hopefully based on the local environment, to describe noise across the entire area, or link. As this guesswork is prone to error, we automatically recommended a conservative value, to budget for high noise.

For example if the thermal noise for a narrow channel is -133dBm, our interface automatically recommends -113dBm as a floor for planning which provides 20dB for unknown noise.

The noise figure could be measured direct from a networked sensor which we published in early 2023.

A Noise database (2023)

Noise varies by location (and frequency) and the previous method didn’t scale so we developed a noise API to store noise data and reference it in calculations. The private data was used on a per-site basis so you could model a network with different noise at each site. A marked improvement on a single figure.

This development represented a leap forward in network planning as each node could be configured for the local environment, which can vary drastically. Two different users might have different needs so it is isolated to the user’s account. A multisite API call accepts different noise values for each site.

A Noise map (2025)

Building upon our Noise API, stored data was used to generate a noise map, specifically a raster layer of measurements, similar to clutter which our API can reference. This noise map describes thousands of noise points across the area or link of interest and provides high resolution noise. Now you can see the real impact of noise with minimal effort at each location covered.

Any calculation requested with the database option versus the legacy single figure method will create and use a noise map at the API. The quality of the noise is determined by the data you can provide and any missing values will be interpolated. The maximum resolution is 12m supporting dense urban planning so you can have different noise levels in adjacent streets, which is common in urban canyons.

Better still, with live noise data, you get live coverage. Ideal for autonomous systems and future spectrum management systems which will need to be automated to remain relevant.

Collecting noise with DORA

DORA (Distributed Open Receiver API) is an open source project sponsored by CloudRF designed to collect noise measurements using various Software Defined Radio (SDR) receivers and mature open source utilities.

It uses consumer grade SDRs via a remote service present on the DragonOS operating system. Designed for SBCs like Raspberry Pis, DORA presents a common API for RF sensing across different radios. Nodes perform a local FFT to measure average power (with configurable bandwidth) and then publish the PSD data via an API endpoint. A server fetches and collates these to present them in an interface to provide spectrum visibility.

When a CloudRF API key is provided, the server sends data to our noise API giving a user live noise data for accurate planning. DORA’s low cost (£200 BOM per node) makes it scalable and cost effective. It won’t give you a pretty waterfall like Government spec hardware but it will provide the scale needed for autonomous spectrum management, powered by the CloudRF API.

If you do want an open source FFT and waterfall we recommend OpenWebRx.

You can contribute to the future of scalable spectrum sensing over on Github with issues, feedback and features.

Summary

This noise map feature is live now and works with any receiver capable of reporting noise as dBm. The benefit of using live noise in planning is improved accuracy but also relevance, and in time confidence, as the simulation will match the environment.

Posted on 2025-04-162025-04-16 by CloudRF

The art of HF

We’ve published a series of video tutorials for HF novices to bring to life HF theory around the topics of Frequency selection, Antenna fundamentals and forecasting.

HF communications is very different to terrestrial communications and given the right frequency, time of day, and antenna, you can achieve long range links in excess of 1000km with only a few watts of power on a HF Dipole.

CloudRF’s API uses the proven VOACAP engine to create accurate HF predictions considering a number of factors. Using this tool, you can plan long range resilient links and anticipate the (time based) surprises HF throws up…

Frequency Selection

Time is critical to HF communications. As sunlight changes throughout the day, so does the range of usable frequencies. A common strategy for round the clock communications is to maintain a day and night frequency. These can be identified using the VOACAP powered path tool in CloudRF.

This tool reports the Signal-to-Noise ratio against time for different HF frequencies.

Antenna Basics

Once a frequency has been identified, an antenna must be constructed to the right dimensions.

The antenna of choice for many long range HF links is the half wave dipole. This simple and efficient design uses two fixed length elements and a center feeder to bounce signals off the ionosphere.

To get the wavelength for your frequency divide 300 by the frequency in MHz.

Height

The height of the antenna will change its radiation pattern and the take off angle.

Achieving at least a quarter wavelength is recommended for efficiency (and practicality) as the long HF wavelengths make a half wavelength too high for most masts. For an 11MHz signal, the height would need to be 6.8m for example.

Azimuth

HF patterns are directional and must be orientated towards a distant station. For some antennas, like long end fed wires this is as simple as pointing the wire towards the station.

For a half wave dipole, which has a donut shaped radiation pattern, it must be broadside towards the station as it has nulls where the wire ends are. A bad azimuth can be forgiven at short range but will determine the potential range.

Feeder loss

Using a feeder co-axial cable will reduce the efficiency of your system. The effect increases with length so you should aim for the shortest, low loss, feeder possible. The impact of the feeder can be simulated even if you don’t know the cable type by entering 1 or 2dB into the feeder loss option.

Forecasting

Sunspot R12

The Sunspot index number describes solar activity which follows a 10 year cycle. When the number is high, there is increased solar activity and better refraction. The different between a good and bad year within the cycle is around 6dB which on the S Meter scale is equivalent to two levels, or the difference between success and failure.

This can be predicted and the random element budgeted for using the model’s reliability value.

Posted on 2025-01-302025-02-04 by CloudRF

Phase Tracing interface

Simulating indoor radio coverage for first responders has been made simpler thanks to a new capability called Phase Tracing.

The novel design was influenced by the 2017 Grenfell Tower inferno, where radio communication in concrete stairwells was highlighted as a major problem. The Grenfell inquiry highlighted radio and training issues in the report, which had a section dedicated to communications.

During the inquiry, expert witnesses were unable to demonstrate how far a signal would travel within the tower, even with the availability of indoor planning tools. Estimated distances offered to the inquiry were based upon empirical measurements from elsewhere and were at odds with witness statements from firefighters who reported losing communication after only four floors and communicating with paper notes.

The intensive computation required to perform a true 3D simulation with reflections has been made practical through developments in graphics processing. As a result, accurate radio coverage in stairs, tunnels and elevator shafts can be simulated, at the network edge, by an operator with minimal training.

In contrast to legacy indoor planning tools, which use floor plans and images; Phase Tracing is designed for critical communications and industrial markets in challenging and dynamic 3D environments, represented by digital models.

Models not floor plans

Phase tracing in a multi floor open plan office

Phase Tracing represents a leap forward for radio simulation from overlaying images upon a 2D map or floor plan, suitable for an estate agent, to using a digital twin 3D model which considers all floors, and the obstructions in between from stairs, to air ducts and pylons. Simulating reflections is critical for indoor modelling which is a pillar of the design.

There also exists a huge gap in the market between indoor simulation packages and the skill required to use them effectively, and first responders who are left guessing where they will lose communications on a stairwell. This gap has been closed by developments in computation, namely GPU processors, and web technologies which mean this powerful API can be used from a low power touchscreen device.

A little movement…

For RF theory students who are taught the impact of multi-path; they now have a tool to visualise and explore this important concept; so they can see why “a little movement may cure a dead spot”. Better still, they can identify constructive “good” multipath they didn’t know about.

Tarana antenna at a railway station with a bridge and pylons

The GPU accelerated engine reads and writes to open standard glTF models and uses ray tracing techniques from computer games to bounce photons around the model. With the addition of phase, multi-path artefacts such as signal “dead spots”, where out of phase signals on the same wavelength cancel each out, can be modelled.

The number of reflections, material attenuation and scattering properties can be configured. This is essential for modern buildings which are built with materials which disrupt radio communication.

Applications

Phase Tracing has a distinct advantage over 2D modelling for the following 3D obstacles in most wireless industries.

Stairs
Tunnels
Bridges
Towers
Pylons

Design

The Phase Tracing capability is built upon our 3D API which we launched last year with a blender plugin. The API can be called directly to integrate the output into other model based systems, or even viewed in a standalone HTML5 viewer.

The interface and API is radically different to our map based Globe. For starters there are no Geographic coordinates, positions are in Cartesian XYZ co-ordinates relative to position 0,0,0. This is so you can work with models which might not have a geo reference or in the case of design, might not even exist yet.

Photons and Phase

The 3D engine is a CUDA accelerated pipeline, like our 2D GPU engine, which processes jobs asynchronously to service multiple users. It creates a voxel model from a glTF file which it then radiates photons around. A photon will reflect from obstacles until it runs out of energy or reaches a reflection limit. Unlike Ray Tracing, a legacy technique for indoor modelling, these photons maintain their phase so multi-path can be simulated in all directions.

Each reflection costs several decibels of power typically so there is a practical limit, depending on the material, after which it will be too weak to be useful and the photon should be killed. The engine can model up to 30 reflections per photon which do not impact performance so much as the number of photons, currently set to 2^e6. The required number of photons depends upon the model: If you have a small office and need to decide where best to put a Wi-Fi Access Point you don’t need many.

If however, you need to model reflections up a stairwell, along a corridor and into a flat you need millions. This isn’t fast, or pretty, but such is the nature of critical communications. We’ve fixed the photon limit on CloudRF to deliver a calculation in under 30 seconds for a large model. A small model will be quicker.

VR/AR support

The cross platform interface uses three.js and the WebXR library which supports Virtual Reality and Extended Reality devices. We have a XR branch we’re playing with on a Meta Quest but are having a headache issue as it is so immersive you get vertigo exploring tall models. Once this is sorted, likely by AR, we’ll merge it. Last year the 3D output was integrated into a third party Hologram interface.

VR controllers in a development emulator

Demo Gallery

We have an interactive demo gallery of 3D models you can explore on our Github pages. To use these demos you will need a WebGL capable web browser like Chrome. You can use your mouse to zoom in and explore the models or download them as GLB to view on your phone using an app like glTF viewer. iPhones support these GLB models natively.

Demo Gallery

Roadmap

The API and version 1.0 of the interface have been published. The API can be used by Silver and Gold customers and the interface is restricted to Gold only presently whilst we build more infrastructure to support this.

Interface login

June 2024 – 3D API

Upload glTF model
Perform multi-site simulation using transmitter parameters
Configurable material attenuation
Configurable reflections and attenuation
Blender plugin
1e6 photons
Mega voxel limits

Jan 2025: Phase Tracing 1.0

Cross platform web interface
GLB Model management (Add, Remove)
Local model caching
3D antenna models built from user’s antennas
Click to aim
Configurable reflections, resolution and default material density
2e6 photons
Save/Load settings as JSON

Mar 2025: Phase Tracing 1.1

Official VR/XR support
GLB download
Material manager for construction materials
Biasing for speed boost
Configurable photon limits – linked to plan

Sample GLB models

Upload these glTF binary models into the interface or another tool such as this handy free viewer.

You can validate your models with another free tool here.

cube_10m Cube 10m x 10m

Railroad Rail station with bridge

Open-plan-office Multi-storey open plan office

Posted on 2024-12-162024-12-16 by CloudRF

Interference analysis

Interference is one of the single biggest issues in radio which limits the potential of a system or network.

There are different types of interference but the problem of interference visualisation is common to all. With simulation software you can model your system, and an interfering system, but understanding the interplay where the coverage of the two overlap is crucial. Like many radio engineering concepts it’s a complex topic so making it simple requires abstraction which our API provides.

Up until now we offered a basic interference capability, capable only of colour promotion. It was unable to consider signal parameters or to show the level of interference.

Enhanced Interference API

The upgraded interference API considers the signal parameters frequency, bandwidth and power. It accepts two arrays of sites, one for the “signal” network and another for the “noise” network so you can compare two sites or scale the concept for two networks.

Frequency is obvious as two local signals on the same wavelength will interfere. This technology agnostic API considers the signal as a constant carrier. This means it does not consider features of the waveform since modern technologies, like 802.11, employ back-off mechanisms in the PHY to manage collisions whereby a transmission will pause momentarily if it detects noise.

Bandwidth is important as even if the signals are on different channels, their bandwidth may overlap. In 802.11, adjacent channels overlap by design when using wide (20MHz) signals but the amount is small enough that the spread spectrum signal can overcome it in error recovery mechanisms. As a result, many signals can operate in a dense slice of spectrum.

Power is harder to plan for in spectrum planning where the focus is normally on frequency management and is the source of most interference reports. Even if two signals are on different channels, with non-overlapping bandwidth, they can still interfere if one of them is sufficiently powerful. This is because a signal produces frequency harmonics at multiples of itself and power in the spectrum appears as a Gaussian function which looks like a bell curve. A powerful signal will bleed power into the spectrum adjacent to it and if a receiver does not have an adequate filter, it will receive this power even if it’s on an adjacent channel!

Presenting interference

We use decibels (dB) as the measurement unit to describe interference along with a special purpose colour key called JS (Jam to Signal). The J/S ratio, as the name implies, shows the interference (Jammer) power over the signal power. A bad JS ratio implying strong interference would be greater than 0 eg. 12dB and a good ratio would be negative eg. -12dB.

The level at which this interference presents a problem to a given waveform varies. Some waveforms are designed to operate within noise such as LoRa and others like WiFi fail gradually with noise: When people say “the WiFi is slow” yet they have a strong signal, the problem is interference which causes sampling errors, and reduces data bandwidth.

Using -3dB as a interference limit in planning is recommended. This is green on our colour key.

Anything higher than this and there will be reduced performance / speeds. An interference ratio higher than 0dB will likely stop you communicating altogether if your signal requires a positive SNR ratio – as most do. For reference, high capacity data waveforms require 20dB SNR and commercial telemetry requires less at 3dB SNR.

Demo: Signal jammer (Frequency)

This high resolution frequency demo shows the impact of a 10W signal jammer against a high powered urban rooftop cell tower radiating ten times more power at 100W EIRP.

Despite being near to the strong, and elevated, cell, the lower powered omni directional jammer is able to overcome the cell in building shadows and coverage nulls caused by the directional antenna pattern.

Where the interference is equal to or greater than 0dB, it is very likely that cell coverage would be disrupted.

Demo: FM broadcasting (Power)

This is a power problem whereby channels have been separated in frequency but there is interference from neighbouring channels. This is because a signal is shaped with a Gaussian function resembling a bell curve and has power either side of it in the spectrum. The stronger the signal, the more power bleeds into neighbouring channels.

Demo: Microwave link (Bandwidth)

A high power microwave link uses parabolic dishes to focus a high bandwidth beam towards a distant point.

On the path of the link is relatively low power 3GHz cellular system separated in frequency by 45MHz. There is no guard channel so the two signals are adjacent to each other. The directional pattern experiences interference at the edge but is not affected on the main beam.

API demo

We have published a new API demo to demonstrate this scalable capability using vehicles using PMR 446 radios which are being interfered with by other vehicles with different technology in the 446 band.

It uses our Multisite API to model each network for the Signal (Blue) and Noise (Red). When a transmitter, or vehicle in this case, moves, the network is updated and the interference simulated.

Link: https://cloud-rf.github.io/CloudRF-API-clients/slippy-maps/leaflet-interference.html

Documentation

API reference

https://cloudrf.com/documentation/developer/#/Analyse/interference

User documentation

https://cloudrf.com/documentation/04_web_interface_functions.html#interference-analysis

Complete Code example

https://github.com/Cloud-RF/CloudRF-API-clients/blob/master/slippy-maps/leaflet-interference.html

Posted on 2024-11-122024-11-12 by CloudRF

HF Skywave

HF Ionospheric propagation, known as Skywave, has been added to the CloudRF API.

While Satcom offers clear advantages in terms of speed, bandwidth, and the ability to provide real-time, high-quality data transmission, HF remains a crucial alternative where cost, independence from satellites, portability, power efficiency, and resiliency are important.

Wide area simulation

The new /hf/area API endpoint uses the proven VOACAP engine to simulate coverage for a given transmitter at a given time of day. It combines CloudRF’s familiar JSON interface structure (transmitter, antenna, receiver, environment) with VOACAP antenna patterns and temporal parameters (Month and hour).

The maximum range for the simulation is 10,000km which takes several seconds and like other (area) layers it can be exported to KMZ, GeoTIFF and SHP.

API reference: https://cloudrf.com/documentation/developer/#/Create/hf%2Farea

Link frequency prediction

The new /hf/prediction API endpoint provides a HF frequency prediction capability, powered by VOACAP, for a given link. It uses the same workflow as the path tool whereby the transmitter is placed upon the map, the path tool is selected and the receiver is placed.

The output is a chart of frequency SNR values for the link across the HF band from 2 to 20MHz and hours of the day. As ionospheric activity varies considerably between day and night, the chart helps select an optimal frequency and can be exported to PNG.

API reference: https://cloudrf.com/documentation/developer/#/Create/hf%2Fprediction

HF parameters: Time and Sunspots

Time is critical with ionospheric communications so the “model” section has been extended to include three new variables.

Diffraction is disabled and the two familiar reliability and context variables can be tuned as with other models to match empirical measurements.

Month

The month is defined as a integer from 1 to 12.

The relevance to HF is that during the summer, solar activity, and therefore refraction, is increased.

Hour

The hour is defined as an integer from 0 to 23 and is in UTC.

The relevance to HF is that during darkness, the lower “D” layer collapses so RF which was previously attenuated is free to reach the higher “E” and “F” layers which increases both noise and global reach.

Sunspot R12 number

Solar activity follows a ten year cycle which can be predicted. The year 2024 is at the peak of this cycle so the “R12” number is high at ~150. In 2030 this will be low at (~25) and equivalent HF links will be more difficult.

Solar activity is subject to random bursts of radiation (Sporadic E) which makes predicting and calibrating HF communications harder than short range terrestrial links. Using empirical live measurements from sounders and crowd sourced networks, the random element can be mitigated but not removed.

Sunspot chart © Australian Bureau of Meterology

HF Antennas

HF antenna theory is a complex art form. For example, the same physical antenna will produce very different propagation depending upon its height above the ground where reflection takes place.

The reflection depth varies by terrain so a swamp has a ground level water table but a desert could have a reflection height much deeper so an antenna may not need elevating much at all to achieve a link.

This reflection height determines the “take off angle”, and skip zone, whereby a tall antenna between two tall masts has a lower take off angle, and longer range compared with a waist height antenna which has a steep angle and relatively short range for Near Vertical Incidence Skywave (NVIS), which we have a separate model for.

When selecting the HF model, you will be given a fixed list of VOACAP antenna patterns with which you can manipulate the gain, height and the azimuth. A typical gain figure for a dipole will be between 1 and 2.15dBi whereas a LPA could be 9dBi depending on elements.

Antenna	Description	API code
ITSA-1 Horizontal Dipole	Center fed symmetrical design with arms matched to half a wavelength. Deployed broadside to the target.	2
ITSA-1 Horizontal Yagi	Directional array which can be steered to a target.	3
ITSA-1 Vertical Log Periodic	Highly directional array with a focused beam pointed at a target.	4
ITSA-1 Sloping Vee	Simple directional antenna which only requires one mast. Arms are measured to 1/2 the wavelength and staked out towards the target.	5
ITSA-1 Inverted L	End-fed mixed polarisation antenna capable of local groundwave and distant Skywave. 1/4 wavelength up and 1/2 wavelength along.	6
ITS-78 Inverted L	End-fed mixed polarisation antenna capable of local groundwave and distant Skywave. 1/4 wavelength up and 1/2 wavelength along.	8
ITS-78 Sloping Long Wire	Simple end-fed wire orientated towards the target.	9
ITS-78 Arbitrary Tilted Dipole	Dipole tilted to achieve maximum gain.	10
ITS-78 Terminated Sloping Vee	Simple directional antenna which only requires one mast. Arms are staked out towards the target and terminated with a load.	11

Table of HF antennas and CloudRF antenna codes

Example HF API request

This simulation request is for a 10MHz half wave dipole, 8m above the ground, radiating 30W of RF power.

The month is November and the time is 8am UTC.

The sunspot R12 number is ~150 for late 2024 based on the solar cycle.

{
    "site": "Tx",
    "network": "HF",
    "transmitter": {
        "lat": "46.3936",
        "lon": "6.8835",
        "alt": "8",
        "frq": "10",
        "txw": "30",
        "bwi": "0.012"
    },
    "receiver": {
        "alt": "1",
        "rxg": "1",
        "rxs": "-125"
    },
    "antenna": {
        "txg": "2",
        "txl": "0",
        "ant": "2",
        "azi": "45"
    },
    "model": {
        "pm": "13",
        "pe": "3",
        "rel": "50",
        "month": 11,
        "hour": 8,
        "sunspots_r12": 150
    },
    "output": {
        "units": "m",
        "col": "HF.dBm",
        "out": "2",
        "nf": "-112",
        "res": "20",
        "rad": "5000",
        "bounds": {
            "north": 89,
            "east": 62.25,
            "south": 1.42,
            "west": -48.49
        }
    }
}

HF Calibration

Using crowd sourced link measurements from the amateur Weak Signal Propagation Network (WSPR), the VOACAP engine can be calibrated using our native calibration utility. Data can be filtered by station and processed ready for import to the calibration utility. The data reports Signal-to-Noise (SNR) measurements which reference an unknown noise floor. We recommend an average value of -100dBm for the 10MHz noise as any error in measurement is less than the other variables such as the variable solar radiation and distant station antenna gain for example.

The WSPR data required pre-processing to convert the 6 figure Maidenhead grid squares to WGS-84 coordinates. The maidenhead python library is recommended for this.

Filtering a time window is critical due to the propagation changes which occur throughout the day. For example, you cannot calibrate measurements from day and night together but you can calibrate an hour as a separate file.

A look ahead

Now that we have published an API, we want to integrate it into some systems. ATAK is an obvious candidate for starters but a HF radio which can see into the future or a ALE modem which doesn’t need to radiate to know it can, or cannot, communicate.

This capability will be available with the next SOOTHSAYER release.

Credits

Credit to the many VOACAP developers and maintainers over the years who have maintained this powerful capability. It is arguably one of the most senior pieces of operational software in the commercial world.

We have only put a shell on this incredible engine but hope our API will introduce a new generation of software developers and communicators to the magic of HF.

Posted on 2024-07-082024-07-08 by CloudRF

Model and Clutter improvements

Monday 8th July 2024

Following our most recent field testing, we have identified two significant improvements in accuracy:

The first is a new deterministic propagation model; the General Purpose model. This is a frequency agnostic curve which takes its accuracy from high quality reference data. It’s dependency on high resolution clutter sets it apart from legacy cellular models which are more complex empirical curves designed in an era of basic digital models.

The second improvement is better default clutter values which align with ITU-R P.833 recommendations, as opposed to our current light clutter values which have been retro-fitted to tune the ITM model, also designed before clutter data was widely available.

Dense clutter

When input settings are adjusted to match field measurements, the model and clutter parameters are adjusted to achieve the best match, measured by the error where a low score eg. 3dB is best. Previously, the calibration adjustments were weighted towards the model with clutter accounting for a relatively minor change.

With our new dense clutter values, we have referenced the ITU-R P.833 recommendation for vegetation values and other papers for buildings. As a result we have new, dense, clutter profiles which when combined with improved diffraction will improve accuracy.

These templates are optimised for 1GHz. Actual attenuation will vary by wavelength so you are advised to create your own if using a very short wavelength with adjusted attenuation.

CITY

Buildings are very dense (3.0dB/m), with variable heights and trees are short (8m) and light (0.4dB/m)

SUBURB

Buildings are dense (2.0dB/m), with variable heights and trees are taller (10m) and denser (0.5dB/m)

FOREST

Buildings are light (1.0dB/m), with variable heights and trees are tall (12m) and dense (0.6dB/m)

ITM model warning

There is one exception to this which is the ITM model: This is our oldest and most complex model which (uniquely) includes its own Vogler diffraction routine. The new dense clutter will not work with the ITM model which can only be used without clutter or a very light profile such as Minimal.clt.

The following table lists changes to combinations of models and clutter:

Model	Clutter	Comment
ITM	Minimal / Temperate / Urban	No change to coverage
ITM	CITY / SUBURB / FOREST	WARNING: Coverage will be very conservative. Do not use ITM with these profiles.
Others	Minimal / Temperate / Urban	Coverage will be optimistic where clutter is present
Others	CITY / SUBURB / FOREST	Coverage accuracy will be improved where clutter is present
All	NONE	No change to coverage

Propagation models and clutter changes

Release schedule

The updated engines and matching clutter profiles are scheduled to be published on CloudRF on Friday the 12th July 2024.

Posted on 2024-07-012024-07-01 by CloudRF

Antenna drive testing

Our latest field test was focused on drive testing novel antennas by UK SME Far Field Exploits (FFX) around the Somerset countryside with Trellisware radios.

Previously, we validated diffraction models using LTE800 in the Mountains. The outcome of that cold test highlighted Deygout as the most accurate diffraction model when paired with empirical cellular models. For this much warmer antenna drive testing, we used lower frequencies and a lower mast in an area with many trees which presented a challenge for both legacy cellular models and LiDAR.

Testing highlights

Average Root Mean Square Error of 7.4dB
Average Modelling Error of 4.4dB
Automated data collection with ATAK plugin
New “General Purpose” model developed
New “GP” clutter profile for use with GP model

Test setup

The test area was in and around the small town of Somerton in Somerset. This town sits in rolling countryside featuring farms, high hedgerows and blocks of trees. A railway line with road humpback bridges bisects the town. The town has a small housing estate under construction which did not feature in our buildings data.

The base station was a wide-band Omega panel elevated 5m above the ground and connected to a Trellisware spirit radio. The radio was operated across several UHF bands, each with 1.2MHz bandwidth, and live positions observed on WinTAK using cursor on target (CoT).

The antenna testing vehicle was fitted with a roof mounted magnetic antenna bracket which connected to a spirit radio. This mount allowed different antennas to be swapped out. As a result we were able to test both a Hascall Denke MPDP675X4 and a FFX Sigma 3.

Data logging

We know customers and OEMs like to voice opinions about radios, waveforms and antennas but without solid measurement data it’s just noise with a lot of bias and emotion.

Data beats emotions every day!

As an antenna OEM, FFX developed the ATAK spectrum survey app to streamline collection of field measurements for antenna testing in different environments.

The logging application used the Trellisware radio’s API to fetch link metadata from the local radio and save it to the SD card as a CSV file.

The ATAK plugin enabled a large quantity of high quality measurements to be efficiently collected. As a result we were able to execute several test cycles in a short space of time – just as well as it was hot (for the UK) and Harry had no air conditioning…

The CSV files were downloaded from the phone and loaded into the CloudRF calibration utility for analysis.

The survey data was filtered to remove results weaker than the theoretical noise floor at -113dBm.

We were planning to use a measurement error of 2dB for the high quality radios (a cell phone is 3dB) but owing to the high temperate of the mobile radio in the car we used 3dB as receiver performance degrades with temperature.

At first look

The first pass comparison of the data showed a ~15dB delta between modelling and field measurements with LiDAR, prior to tuning. Using the ITM model and a high reliability value (99%) this only reduced several decibels and clearly needed more work. Ideally the model should align within 10dB so clutter tuning can then be used to reduce this towards 6dB.

ITM uses the complex Vogler multi knife edge diffraction model which is accurate for hills but needs tuned clutter to handle soft obstacles. Using cellular models, as we did in LTE800 field tests, didn’t produce the same results due presumably to the lower mast height and frequencies, even when enhanced with Deygout diffraction.

A new model

Through curve fitting we identified alignment with the P.525 reference model and a 20dB constant representing observed system losses. When enhanced with the Deygout 94 diffraction model this produced excellent alignment with the more challenging beyond-line-of-sight areas. Many signal paths on the route had multiple obstructions so a multiple knife edge model (MKED) was essential.

We have created a new model from these settings called the General Purpose Model. It is frequency and height agnostic which makes it ideal for ground and air based links and much more versatile than empirical equivalents which must be operated within a restricted performance envelope. Like all our models it must be used in conjunction with a diffraction model and tuned clutter to deliver accurate beyond line of sight results.

In our opinion, modern developments in processing and clutter data especially have rendered legacy empirical models largely obsolete. The modern way to fit modelling to measurements is to focus on precise clutter data not old path loss curves.

In the screenshot below, the car drove up a hill where it fell off the network behind a prominent knoll before reacquiring the network later on. This knoll was the second of two obstructing hills for this section of the route. The modelling predicted more coverage due to the chosen receive threshold, -107dBm, which was based upon 6dB above the thermal noise floor which was -113dBm at 1.2MHz bandwidth. It is very likely local noise was slightly higher.

ITU clutter values

Without clutter, the General Purpose (GP) model will be optimistic in most ground environments. It will be accurate over bare earth but where obstacles are present, it needs land cover and a clutter profile. Prior to developing the GP model, we did most of the tuning in the model using reliability (%) and only fine tuned with the clutter.

This is why older CloudRF clutter profiles eg. Minimal.clt have low values such as 0.05 dB/m for trees. With the GP model, the model itself is very simple and most alignment takes place within the clutter (profile). As a result, the clutter values used for GP are much denser. Our GP profile, created for this test has trees with a density of ~0.5dB/m, aligning with ITU-R P.833, attenuation in vegetation.

Diffraction logic has been re-balanced to accommodate ITU clutter values. Users using either the default ITM model or models without land cover are not affected. Legacy clutter profiles such as Minimal have not changed but you are advised to try the new GP model and associated GP clutter and see the difference for yourself.

Test parameters

Bandwidth: 1.2Mhz

Feeder loss: 1dB

Receiver height: 1.5m

Receive sensitivity: -107dB (6db above noise)

Noise floor: -113 dB

Model: General purpose / ITM

Reliability: 60% / 90%

Context: Average

Diffraction: Deygout 94 / Vogler (ITM)

Clutter Profile: Buildings 3dB/m, Trees 10m @ 0.5dB/m

Radius: 6km

Resolution: 5m

Results

The following table of results were from measurements conducted with the same base station, vehicle and radios. Only the vehicle antenna, and frequency, were changed in between tests. Once calibration had been achieved the area covered was extracted from the modelling. This is typically inverse to the frequency so a low frequency has better coverage than a high frequency at the expense of bandwidth – and both matter.

There are two standout results from the data: First is the low RMSE accuracy for the new GP model with tuned clutter compared with LiDAR which is satisfying given the challenging terrain and the second is the performance of the Sigma 3 on a frequency it is not officially rated for as it has a bottom end of 350MHz. The best alignment with the same settings was found to be with -5dBi receive gain confirming the antenna can be operated lower, and at range.

Once again, DTM with clutter has proven to be superior to LiDAR.

Antenna test	Model + Diffraction	Clutter profile	DEM	Receive gain dBi	RMSE error	Modelling error	Modelling area covered km2	Modelling area covered %
Hascall Denke MPDP675X4 on 1.4GHz	GP (60%) + Deygout 94	GP	DTM + 10m Land cover + 2m Buildings	2	9.4	6.4	19.2	17
Hascall Denke MPDP675X4 on 1.4GHz	ITM (90%)	N/A	LiDAR	2	15.2	12.2	12.4	11
FFX Sigma 3 on 415MHz	GP + Deygout 94	GP	DTM + 10m Land cover + 2m Buildings	2	6.6	3.6	89.9	79
FFX Sigma 3 on 415MHz	ITM (90%)	N/A	LiDAR	2	18	15	72.7	64
FFX Sigma 3 on 287MHz	GP + Deygout 94	GP	DTM + 10m Land cover + 2m Buildings	-5	6.2	3.2	86.1	76
FFX Sigma 3 on 287MHz	ITM (90%)	N/A	LiDAR	-5	15.1	12.1	63	56

Results table showing ITM+LiDAR compared with General Purpose +Clutter.

The scatter plot for the 1.4GHz data shows the simple GP model to align closer to field measurements than the much more complex ITM model. Our conclusion is that the ITM model, and it’s Vogler diffraction, developed in the 1960s, pre-dates developments in computing and precision clutter so provides good performance across multiple hills, at range, but is inadequate for macro planning at “street level” resolution where density of obstacles must be budgeted for.

ITM continues to be a solid UHF broadcasting model but it was designed for hard obstacles. Retro fitting it with soft clutter, as we have done can improve its performance several decibels but for maximum accuracy, the simple General Purpose model with tuned clutter provides superior results.

Results Gallery

Tuned coverage and survey data is displayed on the same map showing the RMSE and Mean error.

Look ahead

The General Purpose model will go live on CloudRF in early July 2024 following more testing and then into SOOTHSAYER 1.8 later in the year.

Posted on 2024-06-192024-06-19 by CloudRF

3D radio propagation API

True 3D multi-path

Following two years of R&D, our new 3D engine and API is live.

It uses an advanced volumetric design to simulate propagation in all directions making it more advanced than 2D engines which can only produce flat images. By design, it supports multi-path and phase tracking to model “fast fading” when signals collide making it well suited to challenging urban and subterranean environments.

Key features include:

3D antenna patterns
Configurable reflections (up to 10)
Configurable material attenuation (dB/m)
Configurable material reflectivity (dB)
Configurable material diffusivity (Metal v Stone)
Multi-site support (n transmitters)
Phase tracking for multi-path effects (Constructive and destructive multipath)
Configurable resolution from 10cm, subject to model size

CloudRF Blender plugin

An open file standard and an Open API

We’ve chosen the growing glTF 3D standard by the Khronos Group for our input and output. It is supported by most devices, GIS software, graphics engines and 3D viewers.

You can transform LiDAR point cloud scans into a glTF mesh using a number of free packages to exploit popular formats like LAS and LAZ.

As per our open architecture and API-first design, the 3D API is available now as an open API. You will require a premium CloudRF account and an API key to use it.

With the API, you can push up a model, perform coverage analysis, and view the output using a hosted viewer supported by popular browsers.

Multi-path visualisation

Everyone talks about multi-path, the behaviour of colliding radio waves but can they visualise it? Signals schools teach students that a “little movement” will cure a dead spot. That’s good but when a little more movement puts them back in a dead spot again it doesn’t solve the real issue, current software cannot practically do multi-path.

There are expensive ray tracing solutions designed for design engineers but not operators deploying equipment, or students even who are taught to move, but don’t know where to!

In the screenshot below, a directional 5G antenna is pointed towards Tower bridge in London. Where there is line of sight on the river Thames the signal is a solid green. Where there are reflections, the signal is patchy and adjacent to the bridge there is a notable area of destructive multipath in the middle of the river. This huge dead spot is caused by strong reflections coming from the south tower of Tower Bridge. The north tower isn’t as affected due to the angle of incidence which creates a longer reflection path, and weaker reflection.

Destructive multipath in the middle of a river.

Viewer agnostic

As an open standards API our mesh output can be consumed by browsers, third party apps and AR viewers. We’ve already integrated it into a Hologram and the popular Blender 3D software and will add it to our web interface soon since we use Cesium which has supported glTF since 2014.

You can add glTF models direct into ESRI’s ArcGIS Maps SDK. Demo code is right here!

Blender plugin

Whilst developing this we used the popular Blender open source 3D platform to create obstacles and inspect output. We developed a plugin for Blender which we have open sourced so you can drive it directly from Blender. The plugin will upload your model and allow you to use it, along with CloudRF radio templates, to simulate RF coverage.

For more information on the plugin see here.

3D properties

Coordinates

Instead of a geographic projection like WGS-84, this engine uses XYZ coordinates relative to the model origin (x=0,y=0,z=0). This is better for modelling buildings in isolation like architecture designs which don’t exist!

When a building is placed upon the earth, the translation to these values should be performed by the client, such as Blender so ideally the user does not need to know what/where they are – it just looks right.

Up and Forward

Cartesian vector coordinates are more complex to express than latitude and longitude.

This is best left to the client like Blender for example. As a minimum the position is required as XYZ and for advanced usage the API allows “up” or “forward” XYZ directions to be used to express rotation. Different platforms do different things with coordinates so we have opened up our API to support as many as possible.

Materials

We’ve supported configurable clutter for years but with multi-path support we have extended support for both attenuation, reflection and diffusion. The glTF standard supports materials by standard with human readable names eg. “Wood”. You should match the materials you are using with the “Keys” section to capture variants in your model for example: “Wood”, “Oak Wood”, “Timber”.

Reflection loss

Measured in decibels, this is loss incurred by a reflection from a surface. Solid surfaces like Metal reflect most of the energy so have a low loss value of between 1 and 3 dB and softer surfaces like timber absorb more energy so have higher loss values of 3 to 6 dB.

Transmission loss

Measured in decibels per meter, this is absorption loss. These figures will be much higher than what you might have used with our other APIs since those are nominal values based on average attenuation through a house whereas these are the actual value for the material(s) (eg. brick) not the parent obstacle (a brick house).

For example; a brick house measuring 10m wide might have 2 blocking walls at 10dB each for a given UHF frequency.

With the 2D API, this would be represented as a attenuation figure of 20dB / 10m = 2dB. In the 3D API the brick wall would be the simpler 10dB!

The advantage of this is we can now model inside rooms with different materials and furniture – if you have the model…

Diffusion

Radio waves scatter when they hit a wall. The behaviour varies by the material so you can define this behaviour with the diffusion parameter. It’s a randomisation ratio from 0 to 10. At 0 there is no diffusion and you are only considering the input ray. With 0.1 a small amount of randomisation is occurring so the reflection is very predictable like a game of pool.

With 10.0 the reflections are truly random in all directions. This would be suitable for a gravel path for example.

Performance

Modelling a cube is harder than a 2D plane so this takes longer. How long depends upon your model size and resolution and reflections. Increasing reflections doesn’t add as much work as you might expect due to our efficient design but asking for 20cm resolution for an entire neighbourhood will leave you waiting for a few minutes.

Performance tips

Start with 1m resolution and a small model
Keep you input model minimal. If you have every pot plant in the town it will be a big mesh file and will take longer!
Pretty photo realistic 3D tiles are pretty but take a long time to model. Go ugly early with basic models for speed.

Documentation

The swagger documentation is located here.

The blender plugin is located here.

Posted on 2024-05-012024-05-01 by CloudRF

3D simulation roadmap

The problem with tunnels and stairs

Whenever there’s been a major incident involving emergency services in complex urban environments the inquiry report has consistently highlighted radio communications failure despite significant developments in radio communications and 3D technology since the infamous 1988 Kings Cross Fire on the London Underground. The following tragic incidents all featured tunnels, stairs and communications failure:

The 1988 Kings Cross Fire report highlighted radio communications only worked when they were in line of sight.
The 2007 London underground bombings report highlighted that radio communications from trains to network control were inadequate or non-existent.
The 2017 Grenfell tower fire inquiry highlighted inadequate radio communications between the incident control on the ground floor and fire fighters higher up the tower.

Limitations of (2D) radio planning tools

Radio planning tools are not used in emergencies. They’re complicated, slow and require a lot of knowledge to produce an accurate output. Even if a skilled operator were able to model a site before the event, currently they would be expected to model each floor of a multi-story building in isolation due to the “floorplan” design of current software.

The problem is indoor planning tools are built for corporate clients to achieve seamless Wi-Fi in every corner of the office, not to help a fire chief deploy a mesh radio network down stairs and then along a tunnel. The top end tools can do limited multipath, slowly, but not as an API which can be consumed by a third party viewer…

Most radio planning tools on the market, ourselves included, have the following limitations when it comes to complex urban modelling which we will explore in detail:

Using LiDAR as a 2.5D surface model

The abundance of free LiDAR data has made this high resolution data the standard for accurate outdoor RF planning and for several Fixed Wireless Access (FWA) tools, including free LiDAR based path tools, it is their core feature. We started using LiDAR in 2015 and know its limitations well; for example when point cloud LiDAR has been rasterised into GeoTIFF then it’s no longer 3D, it’s a 2.5D surface model which is useful for building heights and unsuitable for bridges, arches and tunnels.

A bridge or arch in a rasterised LiDAR model extends to the ground like a wall. In the screenshot below, a large ferris wheel is blocking line of sight through it as well as the elevated rail bridge across the river which is casting a shadow much larger than it would in reality.

Using a floor plan to model a building

For indoor Wi-Fi planning tools, the start point is typically a floor plan. This does not scale well with multi-story buildings or support vertical planning as it produces a 2D image of a 2D plan.

Many tools present 2D images in a 3D viewer, as we do, but the output remains 2.5D, as with rasterised LiDAR. The significant Wi-Fi attenuation presented by solid floors makes this simplified 2D floor-by-floor planning viable for corporate clients in offices but not in challenging environments or where a floor plan does not exist.

Direct ray only

Attenuation is good, reflections are better

Modelling multipath, or fast fading, is much more complex than the direct ray. For this reason, most tools only do the more powerful direct ray and even then some cannot do diffraction or obstacle attenuation as we do already. For the previously mentioned Wi-Fi planning tools, the current standard is to model obstacle attenuation only. By doing this a tool is able to simulate most of the coverage quickly for a given floor but for complete accuracy it must be augmented by a walk survey, which isn’t so quick. For some customers, a walk survey is just not possible.

Multipath effects will increase coverage beyond a direct ray simulation and cause phase issues like signal dead-spots and doppler spread where reflections increase bandwidth and overall noise. This effect can be observed indirectly via customer reviews for urban WISPs where people state their once good link quality reduced as more neighbours subscribed.

A 3D multipath API for 2024

We’ve been working on this full 3D capability since the 2022 Grenfell inquiry with valuable input from firefighters, mining experts and MANET radio OEMs. The first version of the engine is done and we’re onto API integration now.

Our GPU based design takes a 3D model, simulates propagation in all directions irrespective of floors including configurable reflections, surface refractivity, material attenuation and crucially it outputs to the open 3D standard glTF. It scales from small rooms to suburbs and everything in between so will be used for tunnels, multi-story buildings and outdoor multipath.

It will be integrated into our API first so other standards compliant viewers can visualise it and will then be integrated into our own 3D user interface. We can’t say what interfaces people will be using in the future but are confident that by aiming for open standards APIs we will ensure compatibility with phones, glasses and holograms.

Done

Read LiDAR into a 3D volume

Prepare a volume from a LAS/LAZ LiDAR scan.

Done

Direct ray with attenuation

Model direct ray with configurable attenuation in dB/m for obstacles

Done

Reflections

Model reflections accurately based on the wavelength and angle of incidence

Done

Phase tracking

Track the phase to show constructive and destructive interference (fast fading) eg. dead spots, cured by a little movement 😉

Done

BIM / glTF support

Read and write BIM models as the open standard glTF “3d tiles” format.

Under development

API integration

Integrate engine into the CloudRF API so a BIM/LAS model can be uploaded and used via our standard JSON requests.

Under development

3D tiles web interface integration

Add 3D tiles output to 3D web interface. Some interfaces already supported 🙂

To do

Multisite support

Model many sites at once

To do

Antenna pattern integration

Add 3D antenna pattern loss

Commercial plan

The 3D engine API will be a new feature within CloudRF Gold plans and our SOOTHSAYER server at no additional cost. It requires a GPU. We’re aiming to get a beta up on CloudRF in May/June and to ship this with the next major SOOTHSAYER release, currently scheduled for September.

Users will be allowed to upload models within their storage limits and execution time / accuracy will be scaled to fit within a reasonable time. Limits will be relaxed on SOOTHSAYER.

We are partnering with open standards based companies to integrate this into different viewers. One exciting partner we are working with now is Avalon Holographics. Their revolutionary display is able to display our rich engine output in a hologram format so it can be explored in three dimensions for maximum spatial awareness without additional hardware for viewers.

If you would like to get our open standard glTF models into your viewer, get in touch. If you can bring challenging BIM models or LiDAR scans of real tunnels and large buildings we would really like to talk to you.

Demo video

3D simulation engine demo video