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.

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.

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.

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.

Offline by default

With pre-built images, offline install is now enabled by default.

This was developed to both speed up the install, ensure all dependencies are present and correct and automatically assign the domain name / IP address. IP networking in particular was noted as common support issue so we’ve put effort into helping users get this right early on in the setup.

We use a lot of open source libraries in our stack and there is no guarantee they will be available or compatible at the point a user decides to build. This stung us after we launched 1.8 when a third party “npm install” command later failed causing us to release a patch (1.8.1).

A build-your-own option is available to users who wish to generate their own images using our compose script.

HF Skywave

Rather than reinvent the wheel, we integrated the popular VOACAP engine into our API as a new model option. You can use VOACAP via the web interface and API to make HF heatmaps or frequency predictions.

We incorporated feedback from VOACAP experts about the critical relationship between antenna height, take off angle, and the subsequent antenna pattern. The engine uses HF antenna patterns which are built on-demand by our API dynamically so you will get the corrected pattern for a given dipole height above the ground.

The HF model was calibrated against published papers and crowd sourced sounding data. You can read more about this in the HF blog.

ARM-64 support

Support for ARM-64 architecture has been officially added now. We field tested this portable edge server concept up a mountain and were very pleased with the power economy of the Nvidia Jetson.

Read more about the field test from earlier this year.

Phase Tracing interface

A new 3D interface with BYO models designed for urban simulations with multi-path, material properties, phase tracking and support for the glTF 3d model format.

This builds upon the 3D API which shipped with 1.8 last year.

Read more about Phase Tracing in the blog.

Enhanced interference analysis

Interference analysis had a significant upgrade in December to enable support for co-site interference and network analysis.

Now you can compare entire networks to see how they might interfere and get a visualisation of the impact of bandwidth and power on adjacent channels.

Read more in the interference blog.

Deprecated features

As a small software company we cannot add features indefinitely. We have therefore retired the following interfaces in line with CloudRF:

Google Earth desktop interface

This was getting harder to support with every new Javascript feature as it’s Webkit browser was frozen in time since they focused effort on the web based version. You can still export to KMZ and open in Google Earth.

TAK chatbot

We made this in 2021 to avoid writing an Android app as we have scars from Android development going back to 2012. The first version used the taky TAK server which was then rewritten for the OG TAK server. As a result we ended up learning a lot about TAK and our open source setup script became one of the most popular non-DoD TAK Server repos on Github.

We now have a signed ATAK plugin which does not need a TAK server so is much easier

Product Flyer

Security

Anchore compatible SPDX-2.3 SBOM available upon request.

SHA1 Checksum:

411f309d9e228b0238e6918d15bc4e5bd7803a93  SOOTHSAYER-1.9_OFFLINE.zip

SOOTHSAYER Changelog

1.9.0 04/2025

• Update: API 3.23.1, UI 3.16.2, 3D UI 1.1.0, CPU Engine 1.16.0, GPU Engine 1.12.0, 3D Engine 0.2.1, AntennaWizard 2.0.5, Bouncyball 0.4.3, Analysis Utilities (QRM2 & SuperTool) 1.0.0, Documentation 2.9.0.
• Update: pgAdmin container updated to 8.14.
• Update: PHP updated to 8.4.
• Feature: Support for HF Skywave.
• Feature: Added binaries for new processing of interference and superlayer.
• Feature: Added new 3D UI – available at /phase-tracing.
• Feature: Added new install.sh, start.sh, stop.sh, and watch.sh scripts to simplify management.
• Feature: Added support for importing pre-built containers for offline environments.
• Feature: Improved automatic assistance with setting FQDN during install.
• Feature: Improved conditional logic for GPU and non-GPU environments.
• Feature: Reduced size of soothsayer-network from /24 to /28 to reduce opportunity for network subnet overlap.
• Fix: Removed use of Docker hello-world for checking Docker permissions.
• Fix: Improved timeout delays when serving cached tiles from MapProxy.
• Fix: /dbadmin endpoint not working for non-standard HTTP/HTTPS ports.
• Fix: Changing database password in the admin dashboard doesn’t change password within /dbadmin.
• Fix: Updated default TLE_CATALOG_URL value.

API

3.23.1 (2025-04-03)

• Fix: Points data endpoint failed when using legacy colour keys.

3.23.0 (2025-03-18)

• Fix: BSA restricted receiver sensitivity unnecessarily.
• Fix: BSA forced to FSPL and no diffraction for all requests.
• Fix: Terrain data map throws a 400 at low zoom levels.

3.22.0 (2025-02-27)

• Deprecation: Removed v1 API endpoints (key=value), deprecated since Dec 2022
• Deprecation: TAK chatbot removed now we have an ATAK plugin
• Feature: Added colour schema to URL export.
• Feature: Added favourite sorting to antenna database.
• Fix: Empty colour schema file being written to archive when requesting KMZ files.
• Fix: Added handler to prevent creation of clutter profiles with system profile names.
• Fix: Unable to delete clutter profiles which contain certain characters.
• Fix: Improved validtions when creating a bad clutter profile.
• Fix: Improved error message for GPU engine over ocean.

3.21.0 (2025-02-18)

• Improvement: Increase maximum reflections limit to 25.
• Change: Uploaded model textures are compressed on upload
• Feature: Credit-based purchases removed from API.
• Feature: Users on free plan can upload 3D models.
• Feature: Added “Raw Request” to KMZ balloon.
• Feature: Improved system clean-up of stale files.
• Improvement: Increase maximum reflections limit to 25.
• Improvement: Show “No LOS” with PPA PNG chart if LOS blocked with LOS model
• Change: Uploaded model textures are compressed on upload
• Fix: Improve validations on edges for BSA requests.
• Fix: Custom colour schema support for negative step sizes.
• Fix: Custom colour schema step size of 0 triggers a loop.

3.20.0 (2025-01-22)

• Fix: Added restriction to /mesh and /merge endpoint where sites must be within 40 degrees of each other.
• Fix: Input model filenames with spaces would fail 3D calculations.
• Fix: 3D calculations sometimes incorrectly returning previous responses.
• Fix: HF NVIS calculations not working.
• Fix: Incorrectly translating hex code of ff to RGB value of 254 for red and green channels when creating a custom colour key.
• Fix: Downloading greyscale calculations as SHP alters the source file which causes other analysis tools to fail.
• Fix: Sending a request to /area without an output.out value results in a HTTP 500.

3.19.0 (2024-12-30)

• Improvement: Better handling of streaming large files.
• Feature: Added /3d/models and /3d/model/delete endpoints.
• Feature: Antenna file uploading moved into Antenna Wizard.
• Fix: MANET tool reporting validation errors with RCS, even when RADAR mode isn’t used.
• Fix: Favouriting antenna patterns sometimes is not always reflected with the favourite button.
• Fix: Uploading of some 3D models incorrectly failing validation.
• Fix: Improved validation when uploading small and large models.
• Fix: Some requests fail where a user agent header is not sent to the API.
• Fix: Antenna database filters now reset the page number.
• Fix: Some environment values not persisting after multisite or satellite calculations.
• Fix: Validation error when using database noise on multisite requests.

3.18.0 (2024-12-12)

• Enhancement: Allow custom per-bucket colour when creating custom colour schemas.
• Enhancement: Upgraded /inteference to show JS ratio instead of just which site is strongest.
• Improvement: Increased the speed of the /mesh endpoint, and added an alias /merge.
• Improvement: Added controls to Antenna Wizard.
• Fix: Colour schema editor doesn’t give warning if name is invalid.
• Fix: Colour schema buckets will style the label according to the brightness of the background.
• Fix: Some CPU calculations failing if input files contained spaces.

3.17.0 (2024-11-25)

• Improvement: Added support for compressed glTF models
• Improvement: Extended noise API to handle array of values.
• Fix: Fixed points kmz url.
• Fix: Landcover and buildings always returned as enabled from preferences.
• Fix: Differing logic relating to noise limits.
• Fix: SNR units reporting as BER when sensitivity out of range.

3.16.0 (2024-11-11)

• Feature: Added HF Skywave APIs /hf/area and /hf/prediction

UI

3.16.2 (2025-04-03)

• Fix: Maximum altitude of 120,000 to align with API.
• Fix: Disable engine toggle when loading in a flight path.
• Fix: Calibration mode has redundant button to enable multipoint links.
• Fix: Download report failing on some browsers. Moved the report within a modal window.

3.16.1 (2025-03-31)

• Deprecated: Google Earth layer removed.
• Feature: Added example long format CSV file to help for automatic processing.
• Fix: Antenna not set during interface load or during selection of a template.
• Fix: Automatic processing fails if colour schema name is only numeric.
• Fix: Clearing layers changes radius after HF Skywave model has been used.
• Fix: BSA mode removes Tx marker to avoid confusion.
• Fix: BSA mode disables adjustment of model and diffraction to avoid confusion.
• Fix: Mesh download title was undefined.
• Fix: Loading calculations from the archive didn’t set colour key correctly.

3.16.0 (2025-02-27)

• Feature: Added “Select all” to archive.
• Improvement: Give modal warning when deleting a network from the archive.
• Improvement: Show “No LOS” with PPA chart if LOS is blocked and LOS model is selected.
• Improvement: Show calculation_adjusted messages for interference tool.
• Improvement: Clicking success/error icon with “Automatic processing” shows debug info.
• Fix: No feedback when using archive functions without selecting a calculation.
• Fix: ‘invalid’ metrics entries.
• Fix: Environment values not set from template.
• Fix: Gain from a template gets replaced after loading a template.
• Fix: Retrieving a null antenna upon load.
• Fix: Satellite mode does not reference API.
• Fix: Colour key replaced with a dBm equivalent after using “Manage My Colours”.
• Fix: Operator mode is giving option for custom antenna patterns.

3.15.0 (2024-12-12)

• Improvement: Intereference analysis lets you compare two networks
• Improvement: Colour picker lets you define full custom values and colours
• Fix: Interference analysis docs link updated
• Fix: Loading some layers from archive throw antenna validation error when “Custom pattern” is selected.
• Fix: Coverage analysis values have overly high precision.

3.14.0 (2024-11-11)

• Feature: Added HF Skywave propagation model

3D UI

1.1.0 (2025-04-03)

• Feature: Added GLB export menu.
• Feature: Added a toggleable scale indicator.
• Feature: Wireframe mode improved by removing interaction with light sources which create strange effects.
• Fix: Wireframe mode is broken on some models.
• Fix: Saving scene is not correctly loading from cached values.
• Fix: Antenna pattern rendering not depth-checked.
• Fix: Loading models from cache not working.

1.0.0 (2025-01-30)

• Initial release.

CPU Engine

1.16.0 – 2025-03-19

• Fix: Pathloss colour bins were offset.

1.15.0 – 2025-01-30

• Fix: Opening a .ter file did not update its atime.

1.14.0 – 2024-12-12

• Improvement: Antenna pattern interpolation.
• Improvement: Write a .json file with metadata
• Change: Write RGBA images so as to reduce post-processing

GPU Engine

1.12.0 (2025-03-19)

• Feature: Added CUDA fast math flag to release builds.
• Deprecation: Removed CUDA architecture 87.
• Improvement: Calibration against CPU engine for different units.
• Improvement: Values between the colour key and rxs are output as black.
• Fix: SNR colour keys with negative numbers are now handled correctly.

1.11.0 (2025-01-30)

• Improvement: Increase per-thread sleep to reduce power consumption.

1.10.2 (2024-12-12)

• Fix: Removed antenna pattern artifact at azimuth 0 and 90.
• Improvement: More accurate area/coverage calculation.

3D Engine

0.2.1 (2025-03-19)

• Improvement: Refraction attenuation is now per meter
• Fix: Fixed overflow resulting in random hot spots
• Fix: Reflection attenuation was applied before the incident
• Build: Added cuda fast math flag to release builds
• Build: Removed cuda architecture 87
• Build: Commented-out unused code to reduce binary size

0.2.0 (2025-01-17)

• Performance: Only generate photons on collisions, not along the whole path
• Improvement: Photons can be exported as a GLB for debug purposes
• Improvement: Material refraction coefficient can be set
• Fix: Photons were invalidated when the movement distance was to small, preventing refracting through more than one voxel
• Fix: AllInRadius mode was summing all the photons that didn’t belong to a given transmitter ID, rather than all the ones that did
• Fix: Refraction loss was not scaled by voxel size

0.1.1 (2024-11-12)

• Improvement: Draco compressed models are now supported
• Fix: Diffusion was not being passed on correctly
• Improvement: Antenna pattern model size can be changed
• Fix: Engine was not restarted on fatal cuda error
• Fix: Idle CPU usage was too high

The post SOOTHSAYER™ 1.9 released appeared first on CloudRF.

Key findings

• Offline operation for over 6 hours
• Average 4W power consumption
• Fan draws most power over a day
• Nvidia Jetson power profile recorded
• Phones are tricky to operate with gloves

Test setup

An Nvidia Jetson Orin nano 8GB processor was paired with a 10AH 12v battery in a portable case.

This was assembled and demonstrated earlier in January with this video.

The following software and services were installed to provide a representative stack:

• TAK server 5.3 with PostgreSQL 15.11
• Hostapd for a WiFi AP service
• DNSmasq for a DHCP service
• SOOTHSAYER 1.8

Instrumentation was performed using the onboard tegrastats utility every second. This provided load data at a 1Hz refresh rate throughout the test. Two ATAK end user devices (Samsung S21 and S23) were associated with the WiFi AP and SOOTHSAYER server via the open source soothsayer plugin with distinct accounts for parallel processing.

Each phone was associated with the TAK server using TLS authentication. This served no purpose other than to show us a green light in the corner of the phone to prove IP connectivity which would be needed to use the (IP) plugin.

The last time we went field testing up a mountain we struggled with sound and wind so bought a lapel microphone so we could provide a detailed narrative whilst on a windy summit. This detail helped immensely with post analysis as we were able to identify details from the video which weren’t noted at the time.

Test results

A rugged 20km Scottish mountain route was selected over a period of 6 hours on a relatively mild day with still air temperatures in single digits celsius. Tests were performed periodically after long intervals to simulate real use with increasing difficulty: The first test being a single area calculation at 1MP resolution.

This was followed by a 4MP calculation which was later followed by a intensive stress test with two clients performing concurrent multi-site calculations. A multi-site calculation simulates several sites in a single API call and requires a GPU.

A final test was concluded at the car park where we were pleased to discover 2 of the 4 LEDs were lit on the battery. This video contains more detail of our hardware craftsmanship than we chose to share and is available upon request.

System startup

The server was prepared en-route and required it’s clock to be set manually since it had no internet access. This clock setting was necessary for both test results and SOOTHSAYER’s rate limiting which uses time stamps to ensure each user is waiting at least one second between API calls. Unlike the public system, SOOTHSAYER has no upper API limit.

The OS was ready after a minute and the software services ready after approximately another minute. The first, and largest (7W) power spike in the data was the first test from the plugin prior to departure at the car park. This was assessed to be larger than others due to Just In Time (JIT) compilation of the GPU kernel. The SOOTHSAYER GPU engine is noticeably slower for the first calculation for this reason, which is expected behaviour.

Test 1 – VHF handheld, 1 million pixels

This test was conducted an hour after startup whilst walking along. The template used was a VHF handheld radio with 10km radius and 20m resolution for a total of 1 million points. As you can see from the video it concluded quickly.

Test 2 – VHF repeater, 4 million pixels

This test was conducted after 2.5 hours after climbing up to the snowline. A VHF repeater template with 20km radius and 20m resolution was used for a 4 million point calculation. This was noticeably slower than the previous test due to the increased computation required.

Test 3 – Multi client stress test

This test was conducted on a cold summit after 3.5 hours of operation. This time, two clients were used to stress test the server with concurrent requests. The requests were more complex multi site API calls which models an entire network versus a single site. As well as GPU heatmaps, the CPU was employed to create links between the radios. Due to the steep topography and random test locations, not many viable links were displayed.

Power consumption

The 1Hz data was collected with tegrastats and showed good power economy. The jetson fan kicks in around 43C and spins up then slows which is visible throughout the data as a saw tooth pattern.

The 3 degree temperate spike during the ascent at 2 hours occurred in a sheltered ravine. Our assessment is that the simple case was suitable for the winter conditions but would require a case with improved cooling for use elsewhere.

The notable temperate drop occurred on a mountain top during filming of test 3 when the box was exposed.

Summary

The test exceeded expectations on power economy and performance and showed that a (budget) portable battery could easily provide up to 12hrs of operation. At the end of our expedition there were 2 out of 4 LEDs still lit on our battery.

It validated the client-server design since the phone batteries were only slightly depleted throughout the test. Both phones finished with more than 75% battery capacity. Performing simulation on a phone is convenient but a poor choice for battery endurance especially and scalability due to the dependency on reference data such as LiDAR and antenna patterns which are provisioned on the server. Note that phone 2’s mapping was unprepared during test 3 but was able to render high resolution topography, sourced via the server.

Of note, the stability and power economy of both ATAK 5.2, TAK server 5.3 and our own plugin was good. We experienced no crashes or connection issues throughout the day which was welcome.

CPU calculations

In the first video, CPU tests were mentioned which we did plan to do. We tested CPU area calculations the day before and were pleased to find they can be almost as fast on a (6 core) Jetson for single sites which was a nice surprise. Compared with a GPU calculation, they use more power so are not as efficient. We did employ the CPU for link simulation on the mountain but elected to focus on the GPU compute capability and power economy.

Lapel Mic

We were stunned by the sound quality on the mountain as the wind was intense for test 3 and we were using an iPhone with a wireless lapel microphone. We recommend this microphone for field testing.

Look ahead

Applications for this network capability include Search and rescue, Mining, Agriculture, Government and Emergency services. Crucially, The edge concept challenges historic ways of working, whereby an expert with a powerful computer produces a plan which is later rendered obsolete by changing events.

With edge compute, planning becomes dynamic which is important since no plan survives contact with reality. Having the ability to redesign a communications plan locally reduces the planning cycle, saves bandwidth and improves spectrum awareness.

For autonomous systems, having integrated communications planning improves their chance of success and supports decision making beyond topographical route selection.

More information

SOOTHSAYER is a self hosted RF planning server with interfaces for different systems such as ATAK.

The software is available as containers for x86-64 and arm64 architectures and can be hosted in the cloud, on a laptop or an Nvidia Jetson. For more information see here or email sales@cloudrf.com

The post RF planning at the Edge appeared first on CloudRF.

3D API

A new full 3D API and GPU engine designed for urban simulations with multipath, material properties, phase tracking and support for the glTF 3d model format.

The REST API can currently be interfaced with directly using scripts or via our Blender plugin. A new indoor/outdoor/underground interface to use this new API is under active development…

3D API documentation

3D API gallery

3D API Blender plugin

Satellite API

Improving upon our legacy Satellite route analysis capability, we can now model the entire coverage footprint using our GPU engine. This exceptionally hard problem required a rewrite of our GPU engine to achieve the “bounding box” capability needed to model a small area at high resolution from a transmitter 35,000km(!) away.

Satellite API documentation

General Purpose Model

Following field testing in the summer, we concluded empirical cellular path loss models are unfit for modelling UHF handheld radios. As a result we created a hybrid model from ITU-R P.525 which is frequency and height agnostic. The simple model is made accurate by the Deygout 94 diffraction model and tuned clutter which we support with new profiles.

You can read more about the testing and the model improvements here.

API change log

3.15.3 (2024-10-08)

• Fix: Restored missing values to path and points endpoints.
• Fix: Trilateration not working with GPU in some scenarios.

3.15.2 (2024-10-04)

• Improvement: Admin pages improved for support of SOOTHSAYER 1.8.
• Improvement: Tighter zoom restrictions on terrain map to reduce response size.
• Improvement: Better default preferences eg. colours
• Fix: /API/terrain does not load in some environments.
• Fix: Resolved antenna rotation edge cases
• Fix: Trilateration broken by numpy update. meh

3.15.1 (2024-09-30)

• Improvement: 3D engine calculations are locked for a maximum of 30 seconds.
• Fix: Stale locking of 3D engine calculations in the event of system crashes would prevent immediate calculation reattempt.

3.15.0 (2024-09-26)

• Improvement: Added DEM Manager to the admin dashboard.
• Improvement: Reorganized data folder.
• Improvement: Refreshed the terrain and clutter map.
• Fix: Removed Chart image and Network KML from network API response as they are not used.
• Fix: Missing megavoxel from products SQL table.
• Fix: GPU calculations with imperial units exceeded the radius.
• Fix: Some antenna patterns being incorrectly interpreted as vertically aligned.
• Fix: Deletion of uploaded files upon system errors.
• Fix: GPU calculation failure when using user-defined clutter profile.
• Fix: Processing engine is not stored as a value when logging requests.
• Fix: Custom ant minimum value dropped from -50dB to -100dB to fix vertical patterns

3.14.2 (2024-09-10)

• Improvement: Network API search radius increased to 0.5 degs for mountain WISPs .
• Fix: Antenna elevation plane wrong for some patterns.

3.14.1 (2024-09-05)

• Improvement: Include Altitude type when retrieving PPA JSON from archive.
• Improvement: Clutter manager supports custom building density.
• Improvement: Custom antenna patterns are smoother.
• Fix: Fix mesh endpoint was ignoring blue and alpha.
• Fix: Antenna downtilt inverted by recent change.

3.14.0 (2024-08-14)

• Feature: Added output-bounded GPU calculations.
• Feature: Added /satellite/area endpoint.
• Fix: Fix antenna wizard plotting tilt direction and handle all valid ADF gain values.

3.13.0 (2024-08-01)

• Improvement: Multipoints KMZ improved to show signal strength making use of bubbles along the route.
• Improvement: 3D endpoint accepts ‘output.megavoxels’ as an alternative to ‘output.res’.
• Improvement: SLEIPNIR 1.13 has black alpha background like GPU for easier GIS styling/analysis

3.12.0 (2024-07-12)

• WARNING: ITM will be conservative with new clutter profiles.
• Feature: General Purpose Model (#10)
• Enhancement: Landcover trees now support up to 1.5dB/m for jungle
• Enhancement: New ITU clutter profiles for CITY, SUBURB and FOREST
• Enhancement: Refactored CORS header handling
• Enhancement: 3D engine version and megavoxels added to admin page
• Fix: Handle SNR 0 in templates
• Fix: 3D API materials validation
• Fix: KMZ PPA network link restored

3.11.0 (2024-06-19)

• Feature: Added 3D engine processing endpoints: /3d, /3d/model/upload, /3d/viewer.
• Fix: Error message if license ID has changed.
• Legacy: Removed colour schema value of 8.

3.10.6 (2024-05-30)

• Fix: ITM model cannot be used with altitudes above 3000m
• Fix: Path KMZ metric heights were missing TxH
• Gift: GPU enabled for Silver plans

3.10.5 (2024-05-17)

• Fix: Multisite antenna tilt inversion.
• Fix: Stop Google Earth UI opening clutter/antenna forms.

3.10.4 (2024-05-10)

• Improvement: Recommend CPU engine for Ocean planning / no tiles.
• Improvement: Optimised Ocean planning.
• Fix: Handles when BSA Tx equals Rx.
• Fix: Handle P.525 optimistic context (aka circles mode) with GPU.

3.10.3 (2024-04-26)

• Improvement: Memory allocation improvements.
• Fix: Super layer KMZ metadata was missing some values.
• Fix: MANET network fails to save if it has unachievable links.
• Fix: MANET KMZ would always be produced using dBm units.
• Fix: MANET KMZ draws links which are below the sensitivity threshold.
• Fix: MANET KMZ assigns black to links which sit on the colour bucket.
• Fix: MANET KMZ links were not floating at altitude of nodes.
• Fix: Default to 1m2 RCS value for multisite RADAR requests
• Fix: multisite antenna template/custom logic aligned with area
• Fix: multisite model.rcs only validated if using RADAR
• Fix: Mesh PNG alpha bug.
• Fix: Can save templates with AMSL height units.
• Fix: Template name capped at 30 character length.
• Fix: Antenna Pattern Import Tool fails if OEM already exists.
• Fix: Downloading ADF pattern from ADF wizard broken.
• Fix: Mesh PNG alpha bug
• Fix: Can save templates with amsl heights
• Fix: Template name capped at 30 chars

UI change log

3.13.4 (2024-10-08)

• Fix: CPU engine unusable if interface loaded in GPU mode by default.

3.13.3 (2024-10-04)

• Improvement: Better default preferences for model, clutter and colours.
• Fix: GPU calculate unresponsive when reloading the UI after a GPU session.

3.13.2 (2024-09-30)

• Fix: Disable MANET tool when using route analysis with mixed altitudes (flight path).
• Fix: Loading imperial ASL path from archive doesn’t properly populate on the PPA chart.
• Fix: Google Earth layer calculations returning “Bad API key” for some environments.
• Fix: Remove broken window when clicking on a best server link.
• Fix: “My Account” modal doesn’t load if the API returns an error.
• Fix: Colour schema changing when enabling/disabling MANET tool even if the schema exists for the measured unit.

3.13.1 (2024-08-20)

• Fix: MANET marker alt aligns with plumb line alt with imperial units
• Fix: Engine selection no longer adjusted when enabling/disabling MANET tool
• Fix: PPA appearing in air when reloaded from archive.
• Feature: Added dropdown selection for bandwidth in operator mode rather than an input box. Input box is still valid in engineer mode.
• Feature: Extended lower limit of bandwidth on input box down to 0.001MHz (1KHz) to match the allowed value in the API.

3.13.0 (2024-08-01)

• Feature: Route analysis import supports CSV as per coverage / calibration etc.
• Feature: Route analysis import supports altitude/height from CSV/KML/KMZ. Uses ‘points’ vs ‘area’.
• Fix: Auto-processing CSV warns when mixing short and long format fields.
• Fix: Fixed Auto CSV typo on example re Gain_dB which is now Gain_dBi.
• Fix: Added missing “KML + PPA” option to quick download list.
• Fix: Buildings value not persisting between interface reloads.
• Fix: Noise floor value not persisting between interface reloads.
• Fix: Auto CSV processing bandwidth supports 1KHz (Previously 100KHz)

3.12.1 (2024-07-16)

• Feature: Engineer template mismatch with operator mode modal changed to go into console window.
• Fix: Importing KML/KMZ polyline into “Coverage Analysis” fails.
• Fix: Multipoint links button missing from engineer mode.
• Fix: Custom antennas in templates ignored for operator mode

3.12.0 (2024-07-12)

• Feature: Operator/Engineer mode select
• Feature: General Purpose Model
• Enhancement: Models list sorted into categories

3.11.5 (2024-06-08)

• Improvement: No longer truncating long antenna filenames in pattern input box to make automated processing simpler.
• Improvement: Automatic CSV processing accepts antenna ID as well as name.
• Improvement: Include URL in error message when failing to load layer.
• Fix: Marker and label disappear when image layer is hidden.
• Fix: RSOD when importing MANET network.
• Fix: MANET import when MANET mode enabled will disable MANET mode.

3.11.4 (2024-06-01)

• Improvement: Updated Cesium to 1.106 (June 2023)
• Fix: Applied 5 months of Cesium bug fixes

3.11.3 (2024-05-27)

• Improvement: Bandwidth changes now adjust receiver sensitivity as well as noise
• Fix: Imported MANET nodes were getting processed twice
• Fix: Imported MANET nodes context menu didn’t open

3.11.2 (2024-05-21)

• Fix: Custom antenna plots update after archive reload
• Fix: Tx marker moves after archive reload to match site marker

3.11.1 (2024-05-14)

• Fix: Imported MANET nodes from KML were not tracking 3D terrain
• Fix: Can import a KML route and then a KML for MANET w/coverage analysis

3.11.0 (2024-05-07)

• Improvement: Selection of “use case” on the “Import Data” dialog. Support for kml placemarks with routes
• Fix: Uploading KML/KMZ to “Coverage Analysis” with a Placemark and LineString
• Fix: Uploading KML/KMZ with more than one LineString would fail.
• Fix: Uploading KML/KMZ with LineString coordinates closer than interpolation distance

3.10.2 (2024-04-29)

• Improvement: BER uses SNR colours for consistency with API.
• Improvement: Interference tool hides colour key.
• Improvement: Restyled MANET links.
• Fix: Best site analysis output sometimes does not get cleared when “Clear all layers” is clicked.
• Fix: Marker labels are hidden when the view is tilted and hard to read.

3.10.1 (2024-04-10)

• Improvement: CSV processing supports GPU
• Fix: CSV processing power_dBm label should be power_W

SOOTHSAYER change log

• Feature: Add update.sh script.
• Feature: Added Rocky OS support for scripts.
• Feature: Improved OS detection for scripts.
• Feature: Removes satellite container as all is now supported within the API and database.
• Feature: Set DNS entry of containers which call out to the Internet to install packages. This can be overridden
  with the DNS_RESOLVER value in .env. Default of Google 8.8.8.8 is used.
• Feature: Documented all of the .env values in the README.
• Feature: 4326 map tiles are now cached rather than reprojecting 3857.
• Update: API 3.15.4, UI 3.13.4, GPU 1.10.1.
• Update: Changed 3D container to use docker.io/debian:12.5 rather than docker.io/nvidia/cuda:12.
  2.2-runtime-ubuntu22.04 to support CentOS Podman and reduce number of dependencies.
• Update: pgAdmin container updated to 8.12.
• Fix: Some containers missing network assignment which was create secondary Docker network.
• Fix: Remove hello-world from list of stopped container after testing with docker run hello-world.
• Fix: Increase timeout of frontend Nginx container to 10 minutes to match that of the API Nginx container.
• Fix: Display administration dashboard login during setup.sh script.
• Fix: Set port number for SERVICE_API environment value when using Podman during setup.sh script.
• Fix: Commenting out values in .env with # can cause errors with some parts of the system.
• Fix: Some endpoints fail to load with or without trailing slash.
• Fix: Non-standard HTTP/HTTPS ports redirecting incorrectly on some endpoints.
• Fix: OSM.xml updated to use the FQDN of the server.
• Fix: Disabled execution of setup.sh after first time execution.
• Fix: Nvidia containers respinning at fast rate if there are issues with nvidia-smi
• Fix: TAK Server Chatbot directory permissions
• Fix: ca.crt download location updated.

More information

For more information on SOOTHSAYER, our self hosted server, see here.

The post SOOTHSAYER 1.8 released appeared first on CloudRF.

Enterprise server

This server is a standard Dell Poweredge R740 with an Intel Silver CPU and a 24GB Nvidia A5000 GPU running a Proxmox hypervisor. SOOTHSAYER 1.7 is installed as a virtual machine and LiDAR data is mapped via a network share.

Datasheet.

Mini desktop PC

This small form factor desktop PC is a HP z2 G9 mini with an Intel i9 CPU and a Nvidia A2000 GPU running Ubuntu 22 server.

SOOTHSAYER 1.7 is installed as a docker container and LiDAR data is local.

Datasheet.

Embedded PC

This portable server is an Nvidia Jetson AGX Orin with an ARMv8 64 bit CPU and a 2048 core GPU. The server has 3 variable power settings and was run in the modal 30W mode.

SOOTHSAYER 1.7 is installed as a docker container and LiDAR data is local.

Datasheet.

The tests

The tests used were designed to benchmark both the hardware and our software’s capability for high performance RF planning. We’ve picked challenges other tools would struggle to compete with, like Bullington diffraction and double digit megapixel resolutions.

High resolution area

The test parameters here were for a 5m resolution coverage heatmap out to 10km radius for a total image size of 16 mega pixels. This was repeated with and without Bullington diffraction and soft clutter data which is computationally expensive to show diffraction with soft clutter versus basic line-of-sight (LOS) speed respectively.

This would exercise our Area API.

Long range path profile

The test parameters here were for a 2m resolution LiDAR path out to a point 10km away. This would test 5000 points and would exercise our Path API.

Ten links at once

The test parameters here were for 10 random transmitters at 3km from a receiver using 2m resolution and Bullington diffraction. All links would be tested in a single API call to our Points API.

The results

All times are in seconds and were taken from the API response, excluding network latency and presentation in an interface.

The times didn’t fail to disappoint and threw up more than a few surprises. Unsurprisingly, cores matter when processing coverage and the fastest compute went to the largest GPU on the server.

When processing links, the CPU is critical and here the Intel i9 on the Mini PC excelled with a 50 millisecond compute time for multiple 2m LiDAR links. This faster-than-human reaction-time speed makes it suitable for dynamic planning with moving vehicles. The enterprise server disappointed with quick links due to the latency with the large data share where the LiDAR GeoTIFF tiles were stored. This latency was only noticeable with very quick calculations however.

The embedded PC performed admirably considering it was seriously under powered compared to the others at only 30W. It was able to model LiDAR links in 80ms and was only about 46% slower than an enterprise server at CPU calcs. Where it was noticeably slower was with processing the GPU area calculation. By increasing the power on the device to the 60W maximum the CUDA cores are doubled and from our testing we expect this would halve the GPU time.

Recommendations

For MANET link planning; an intel i9 CPU with an SSD is extremely fast

For high resolution area coverage; an enterprise grade GPU is unbeatable

For a small form factor host; the HP z2 G9 mini with an A2000 GPU is powerful

For value for money; the HP z2 G9 mini with an A2000 GPU is excellent

For low SWaP; the Nvidia AGX Orin 64GB delivers great economy

More information

For more information on self hosted RF planning, see our SOOTHSAYER page.

No load balancers with arrays of RTX gaming GPUs were used in this testing. We don’t need to do that!

The post SOOTHSAYER server performance testing appeared first on CloudRF.

By popular demand, we now have a Docker enterprise solution so you can build your own containers or use our pre-built AWS template.

Thank you to all who gave feedback and feature sponsorship to help make this feature release. As you can see from the substantial new features and enhancements we continue to model the future of scalable APIs for multiple technologies and verticals such as Aviation and Counter UAS.

New in 1.7

RADAR model

The RADAR propagation model has a RADAR cross section parameter (m2) so you can model the effective range for detection of different sized objects with a RADAR, up to 90GHz, and 500km radius – horizon permitting!

It’s implemented in the API as model #8, both CPU and GPU engines and the user interface.

RADAR documentation: https://cloudrf.com/documentation/02_web_interface_intro.html#radar

Noise API

The noise API was developed from user feedback about the problem with varying local noise figures. Using a universal guessed value eg. -110dBm is not representative of the real world and especially the difference between a quiet rural and loud urban area for example. Now you can push in your own noise readings from radios or other sources either before or during planning. When modelling, live noise can be used by setting the noise value to ‘database’.

Noise CREATE API schema: https://cloudrf.com/documentation/developer/#/Manage/noiseCreate

Noise GET API schema: https://cloudrf.com/documentation/developer/#/Manage/noiseGet

Trilateration API

The Trilateration API was developed by popular request to accelerate and enable the process of geo-location of an unknown emitter. It will challenge conventional thinking about the accuracy of power based geo techniques by using accurate modelling and clutter data instead of circles. Our modelling has been field tested to below 8dB RMSE.

It requires receivers to be pre-modelled to enable rapid RSSI lookups using live receiver measurements. Using this two step process, results are delivered in milliseconds unless a receiver is moving in which case it’s coverage can be maintained using the fast GPU engine.

Trilateration API demo: https://cloud-rf.github.io/CloudRF-API-clients/slippy-maps/leaflet-trilateration.html

Height AMSL

Since our inception we’ve used height above the ground as most of our users are land based terrestrial planners. As we’ve gained more aviation, and RADAR, customers, barometric altitudes are now supported by request. The altitude type is specified in the request “output.units” key as before only now there are four possible inputs instead of two. Range is 1 to 120,000 m/f.

HF NVIS model

By request we’ve added a HF Near Vertical Incidence Skywave (NVIS) model. This models the first bounce from the ionosphere out to 500km and has an option for three layers (D, E, F) at differing refractive heights. This capability is supported in both our CPU and GPU engines and is particular valuable for teaching HF as it will give students an interactive HF tool to learn dipole patterns, the difference between day and night and critical frequency selection.

We have calibrated our NVIS model to align within 10dB of measurements taken from a 2012 research paper by Marcus Walden using a 5MHz NATO frequency in the UK. From this paper we selected one of the longer links at 210km where we used the median measurement value for August.

Bullington and Deygout diffraction models

Our single knife edge diffraction model has served us well for many years but cannot deliver the accuracy we aspire to once multiple obstacles are on the path. We have therefore invested substantial effort to add the much more complex Bullington and Deygout models to both our CPU and GPU engines. These greatly enhance simple propagation models as we proved during our LTE800 field test in the mountains earlier this year.

Automatic CSV processing in UI

From user feedback we created a solution to a problem whereby customers using managed IT systems were not able to install or execute our python API scripts but needed to batch process spreadsheets. We addressed this by adding a form within our web interface where CSV spreadsheets could be uploaded and automatically processed. It uses a much simpler format which combines with the current form settings like environment to execute API calls.

Documentation: https://cloudrf.com/documentation/05_web_interface_import_data.html#automatic-processing-process-a-spreadsheet

ITU-R P.1546 VHF/UHF model

This is a logically more advanced path loss model compared with legacy curves which is designed for terrestrial VHF and UHF planning. It’s conservative so we recommend the optimistic context with Bullington diffraction.

Multisite support for mixed AGL / AMSL units

After we implemented height above sea level for aircraft, we received feedback from customers using our multisite API that they would like to model transmitters above ground level and receivers above sea level. This is a common scenario for a ground-to-air network for example. We extended the multisite API to allow for mixed units so this can all be modelled in a single API call.

Testing

Our testing cycle is six months long, and starts with CloudRF where thousands of users, on every device imaginable, will test our API and interfaces to destruction. By opening it to the public via our free plan, we encourage many concurrent users, with diverse client software, to test our service and in doing so receive much more comprehensive testing than legacy products or GOTS software which only the contractor has tested.

Field testing is essential to validate the accuracy of our software and calibrate radio templates. After we implemented our new diffraction models, we took them to Scotland where we mapped out 22km of mountain LTE800 measurements. This valuable data improved the models and clutter profiles for UHF and validated our investment in improving accuracy.

Our API is regression tested daily and our models have a custom test harness to validate the many permutations of path loss models, environment contexts, diffraction models and parameters. As the number of models and inputs has grown we are relying on automation to ensure outputs are consistent and within parameters for the model(s).

Our user interface on CloudRF is instrumented with third party error handling software which automatically triages bugs for us. Through this we are able to identify issues early before customers are aware. This works especially well with our crowd sourcing strategy since we see a greater variety of clients than legacy or GOTS competitors who do not have the confidence to do genuine crowd sourced testing.

For hardware and hypervisor compatibility we have invested in a wide variety of systems and GPUs ranging from low end consumer GTX cards to enterprise grade devices like the A5000 and A100. We test SOOTHSAYER virtual machines on Proxmox 8 and ESXi 8 with different CPU architectures, network profiles and resource profiles.

More information

Get in touch for a demo and pricing today at support@cloudrf.com

The post SOOTHSAYER 1.7 released appeared first on CloudRF.