Background

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

	Known Power (2W)	Unknown Power (0.1 or 4W)
Best case	0.01	0.03
Worst case	27.33	64.37
Average area	7.93%	31.51%

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

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.

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

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.

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.

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.

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

TBC: 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.

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

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.