Our latest major release of our private server, SOOTHSAYER, is ready. It includes six months of features, updates and bug fixes from CloudRF and features several customer sponsored capabilities including RADAR and Trilateration.

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.

Value	Description
m	Meters above ground
m_amsl	Meters above sea level
f	Feet above ground
f_amsl	Feet above sea level

API height measurement units

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.