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

Interference analysis

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

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

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

Enhanced Interference API

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

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

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

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

Presenting interference

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

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

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

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

Demo: Signal jammer (Frequency)

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

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

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

Demo: FM broadcasting (Power)

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

Demo: Microwave link (Bandwidth)

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

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

API demo

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

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

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

Documentation

API reference

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

User documentation

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

Complete Code example

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

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

HF Skywave

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

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

Wide area simulation

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

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

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

Link frequency prediction

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

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

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

HF parameters: Time and Sunspots

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

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

Month

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

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

Hour

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

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

Sunspot R12 number

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

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

Sunspot chart © Australian Bureau of Meterology

HF Antennas

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

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

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

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

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

Table of HF antennas and CloudRF antenna codes

Example HF API request

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

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

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

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

HF Calibration

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

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

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

A look ahead

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

This capability will be available with the next SOOTHSAYER release.

Credits

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

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

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

Model and Clutter improvements

Monday 8th July 2024

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

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

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

Dense clutter

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

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

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

CITY

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

SUBURB

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

FOREST

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

ITM model warning

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

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

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

Propagation models and clutter changes

Release schedule

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

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

3D radio propagation API

True 3D multi-path

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

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

Key features include:

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

CloudRF Blender plugin

An open file standard and an Open API

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

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

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

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

Multi-path visualisation

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

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

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

Destructive multipath in the middle of a river.

Viewer agnostic

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

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

Blender plugin

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

For more information on the plugin see here.

3D properties

Coordinates

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

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

Up and Forward

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

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

Materials

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

Reflection loss

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

Transmission loss

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

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

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

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

Diffusion

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

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

Performance

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

Performance tips

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

Documentation

The swagger documentation is located here.

The blender plugin is located here.

Posted on 2023-11-152023-11-15 by CloudRF

An API for Cognitive Radio

Cognitive radio, in it’s present form, describes a spectrum sensing radio which can change channel to avoid noise. This capability is standard now on domestic Wi-Fi routers.

With our modelling API and modern radios with APIs we can do much more. Here we present two demos using a raspberry Pi as the server. By compiling our API for ARM and hosting it on a small computer we negate the need for a network to use the API which means we can develop functions to assist radios which may have fallen off the network.

Dynamic transmit power

Problem

Automatic Gain Control (AGC) is an established concept which uses a feedback loop to adjust power to maintain a desired level. This technology is what makes a mobile phone battery last so long. When the phone is near a tower it radiates a fraction of the power it would if it were far away in the countryside. It’s able to do this as the network infrastructure is fixed and there is a signalling channel to make these adjustments eg. “reduce power 10dB”.

A terrestrial broadcast radio network is a much more dynamic environment and as a result it’s common for radios to transmit more power than they need to as power control is simple (low, medium or high on a dial) and once a radio is set to high, the operator is not incentivised to change it as “it works”. This inefficiency reduces battery life and creates excess spectrum noise.

Solution

Using our “Path” API, we perform tests to a distant station to establish the modelled signal to noise (SNR) ratio. This distant station could be the nearest node or a repeater. With the SNR result, we are able to compute an adjustment to the local radio to meet a desired signal level. This could be -90dBm for example.

In our demo, we fixed a receiver location 5km west and moved our transmitter on a north to south path through mixed clutter. The variance exercised the dynamic power management up until the transmitter was behind a deep forest and could no longer communicate after which the LCD reported a failure.

A button to increase radio battery life

Demo source on Github: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/integrations/AGC%20demo

Best site analysis

Problem

Radio networks have signal dead spots caused by topography like a valley or clutter like buildings and trees. When a VHF/UHF radio operator finds themselves without communication (if they’re aware) they will resort to their training and experience to remedy the issue. These remedies can be technical such as adjusting transmit power, antenna configuration or elevation, all of which will improve a signal, or physical such as moving.

Operators are taught to attempt an initial movement of at least a wavelength (10m at 30MHz) to overcome multi-path effects where out-of-phase reflected signals cause nulls followed by bigger movements. Depending on the scenario, this could easily result in an operator making unnecessary, and potentially risky, movements to acquire a signal. Each movement would be a guess based on local observations of terrain…

Solution

Using our “Points” API, we perform multiple tests in all directions around the radio’s position to a distant station. As before this could be a repeater or a recent neighbour node. The points API is very efficient and takes an array of positions for which it returns an array of simulated values. With this response we can determine the best location to move to.

This search is conducted at an expanding search radius until a signal is found. A signal is defined as being above our desired threshold for the system, in this case -90dBm. This result is presented to the operator as a short message composed of a bearing, distance and expected signal strength.

If the operator wants to take control of the search, they can do this using the keypad and virtually walk around the area as a grid. Results for each grid are presented to the operator via the LCD so they can find out if a hill is worth climbing without climbing it.

A button to find a better location for a radio

A look forward

More radios are featuring APIs which allow for dynamic control of the radio, and eventually the network. APIs are the key to enabling a truly cognitive network and we have the modelling API, 11 years in the making, capable of supporting the scale, speed and accuracy needed which can be installed on ARM via a container. As a look forward, we will be installing this on a Samsung S21 where aside from powering our ATAK plugin, we will be able to do powerful modelling capabilities at the edge without a network – or a heatmap.

If you are a hardware OEM interested in enhancing your product please get in touch.

Posted on 2023-10-152023-10-15 by CloudRF

Planning for noise

The trouble with radio planning software

Radio planning software has a patchy reputation. Regardless of cost, the criticism, especially from novice users, is generally that results “do not match the real world”. The accuracy of modelling software can be improved with training, better data, tuned clutter etc but if you do not plan for the local spectrum noise, it will be inaccurate.

The reason modelling does not match the real world, is the real world is noisy, and noise is everything in digital communications. Spectrum noise will limit your network’s coverage and equipment’s capabilities. A radio that should work miles can be reduced to working several feet only when the noise floor is high enough.

Anyone expecting simulation software to produce an accurate result without offering an accurate noise figure will be forever disappointed as software cannot predict what the noise floor is in a given location at a given moment – you need hardware for that…

Spectrum sensing radios

Modern software defined radios are capable of sensing the noise figure for the local environment. This allows operators, and cognitive radios, to make better choices for bands, power levels and wave-forms as narrow wave-forms perform better in noise than wider alternatives due to channel noise theory where noise increases with bandwidth.

For example, you can have a radio capable of 100Mb/s but it won’t deliver that speed at long range, at ground level, as it requires a generous signal-to-noise margin to function. This is why a speed demo is always at close range.

When spectrum data is exposed via an API, like in the Trellisware family of radios, it provides a rich source of spectrum intelligence which can be used for radio network management, and dynamic RF planning with third party applications. When we integrated this radio API last year, we were focused on acquiring radio locations, not spectrum noise. At the time we could only consider a universal noise floor value in our software so the same noise value was applied for all radios which was vulnerable to error as radios in a network will report different noise values.

Interference: a growing issue

The single biggest communications problem we hear about, from across market sectors, is interference, either deliberate, accidental, or just ambient like in a city. The number of RF devices active in the spectrum, especially ISM and cellular bands, is increasing and in markets which were relatively “quiet”, such as agriculture. Some have always been problematic, such as motorsport, where the noise floor increases significantly on race days.

Spectrum management is a huge problem which won’t be fixed with management consultants or artificial intelligence. Regulators can, and are, restructuring spectrum for dynamic use but to use this finite resource efficiently, hardware and software vendors need to publish APIs and competing vendors need to be incentivised to work to common information standards.

As noise increases, the delta between low-noise RF planning results and real world results has the potential to grow. There’s anecdotal evidence that some private 5G network operators are experiencing so much urban noise they’ve given up on RF planning altogether, and have opted to take their chances using a wet finger and local knowledge. Skipping RF planning is a managed risk when a company has experienced staff (or they get paid for failure), but it does not scale and is a significant risk when working in a new area and/or with inexperienced staff.

A solution: The noise API

To address this challenge, we’ve developed a noise API to eliminate human error, and guesswork for noise floor values which has undermined the reputation of “low-noise” radio planning software.

Manual entry can now be substituted for a feed of recent, or live, spectrum intelligence to enable faster and more accurate network planning. Combined with our real-time GPU modelling, the API can model coverage for moving vehicles, with real noise figures.

There are two new API requests in v3.9 of our API; /noise/create; for adding noise, and /noise/get; for sampling noise. The planning radius is used as a search area so you can upload 1 or thousands of measurements, private to your account. The planning API will reference the data, if requested, and if recent (24 hours) local noise is available for the requested frequency, it will sample it and compensate for the proximity to the transmitter(s).

When no noise is available within the search radius, an appropriate thermal noise floor will be used based on the channel bandwidth and the Johnson-Nyquist formula. The capability can be used by our create APIs (Area, Path, Points, Multisite) by substituting the noise figure in the request eg. “-99” for the trigger word “database”.

{
  "site": "2sites",
  "network": "MULTISITE",
  "transmitters": [
    {
      "lat": 52.886259202681785,
      "lon": -0.08311549136814698,
      "alt": 2,
      "frq": 460,
      "txw": 2,
      "bwi": 1,
      "nf": "database",
      "ant": 0,
      "antenna": {
        "txg": 2.15,
        "txl": 0,
        "ant": 39,
        "azi": 0,
        "tlt": 0,
        "hbw": 1,
        "vbw": 1,
        "fbr": 2.15,
        "pol": "v"
      }
    },
    {
      "lat": 52.879223835785716,
      "lon": -0.06069882048039804,
      "alt": 2,
      "frq": 460,
      "txw": 2,
      "bwi": 1,
      "nf": "database",
      "ant": 0,
      "antenna": {
        "txg": 2.15,
        "txl": 0,
        "ant": 39,
        "azi": 0,
        "tlt": 0,
        "hbw": 1,
        "vbw": 1,
        "fbr": 2.15,
        "pol": "v"
      }
    }
  ],
  "receiver": {
    "alt": 2,
    "rxg": 2,
    "rxs": 10
  },
  "model": {
    "pm": 11,
    "pe": 2,
    "ked": 1,
    "rel": 80
  },
  "environment": {
    "clm": 0,
    "cll": 2,
    "clt": "SILVER.clt"
  },
  "output": {
    "units": "m",
    "col": "SILVER.dB",
    "out": 4,
    "res": 4,
    "rad": 3
  }
}:

In the example JSON request above, two adjacent UHF sites are in a single GPU accelerated multisite request. The sites both have a noise floor (nf) key with a value of “database”. Noise will be sampled separately for each site.

Demo 1: Motorsport radio network on race day

The local noise floor jumps ups significantly on race day compared with the rest of the time making planning tricky.

Demo 2: Importing survey data to model the “real” coverage across a county

By importing a spreadsheet of results into the API, we can generate results sensitive to each location.

A look forward to cognitive networks

Autonomous cognitive radio networks require lots of data to make decisions.
Currently, they can use empirical measurements of values such as noise to inform channel selection and power limits at a single node.
What they cannot do is hypothesise what the network might look like without actually reconfiguring. To do that requires a fast and mature RF planning API, integrated with live network data. Only then can you begin to ask the expansive questions like, which locations/antennas/channels are best for my network given the current noise or the really interesting future noise whereby the state now is known but the state in the future is anticipated.

As our GPU multisite API can model dozens of sites in a second, the future could be closer than you think…

References

API reference: https://cloudrf.com/documentation/developer/swagger-ui/

Hosted noise client: https://cloud-rf.github.io/CloudRF-API-clients/integrations/noise/noise_client.html

GPU multisite racetrack demo: https://cloud-rf.github.io/CloudRF-API-clients/slippy-maps/leaflet-multisite.html

Posted on 2023-04-272023-04-28 by CloudRF

Live noise floor modelling

“I’ve never seen modelling that matches the real world”
Anon

Noise in the RF spectrum is a growing issue. It undermines the performance of systems and requires careful spectrum management and deconfliction to mitigate its impact. Sources of noise can be natural, industrial or man made. Regardless of the source, or intent, the issue needs understanding and dealing with to operate effectively in congested spectrum.

Radio users working in cities know about this problem all too well. They can describe the symptoms but are unable to visualise the full impact, and in doing so realise a solution such as an adjustment, through a lack of tooling. Many organisations have bought receivers for use at the edge, and back office software for planning but the two rarely meet…

Noise floor and SNR

The noise floor describes the average minimum RF power in the spectrum. There are different ways to measure it, and depending on the requirement you may want the peak power but for our purposes we are using the mean dBm value within the channel. A quiet noise floor value is -120dBm, subject to bandwidth. The higher this value, the less range you are communicating.

Signal to Noise Ratio (SNR), measured in dB, describes a signals power above the noise. A good signal might be 20dB above the noise and a weak signal only 3dB. Different signals have different SNR requirements; GPS for example uses a BPSK signal with a very low 2dB requirement so it’s barely visible in the noise whereas a DVB QAM signal needs a prominent 20dB SNR to deliver an error free video signal.

In CloudRF, both noise and SNR can be defined to simulate different environments and different waveforms.

A good guess – Johnson-Nyquist noise

Without the presence of man made signals, the RF spectrum has a natural noise floor called the thermal noise floor. This can be calculated with temperature (noise increases with temperature) and bandwidth (More bandwidth equals more noise).

Noise dBm = -173.8 + 10 log10(Frequency in Hertz)

Calculators exist to compute this value based on the Johnson-Nyquist formula. We use this in our interface so when you change bandwidth the noise floor is set. This is a good start, consider it a 75% guess, but is not the real noise. To get that you need to go to that place and measure it.

Measuring noise with an RFeye Node

To measure the noise floor accurately you need a high quality receiver. Low quality SDR receivers are easy to come by but will not be able to give you a more accurate noise value than the previously mentioned bandwidth formula.

The CRFS RFeye Node is a high performance RF receiver with an excellent dynamic range, industry leading low noise figure, and sensitivity. The API enabled receiver is in use worldwide for remote spectrum monitoring making it an ideal candidate for integration, especially since it has open source client scripts!

Integration with the CloudRF API

We imported the NCP client library into our open source API client so we could query the noise for our target frequency and bandwidth. Every time our script processes a site, the noise is tested and the result spliced into our site request.

In return we get a model which uses a real noise floor value. Typically this is higher than the formula method resulting in reduced coverage.

The beauty of this integration is the receiver can be in another county but the modelling can be conducted with high precision from home. With the scalability of the API it unlocks several possibilities:

Model a spreadsheet for a large network, and sample noise floor from local receivers instead of using a generic best guess value
Model a route for a drone with different noise values along the route. If you’ve ever lost communications with a distant 2.4GHz drone that had LOS this was likely WiFi noise
Model a radio and/or a waveforms performance in a remote location without visiting or deploying equipment which is expensive and time consuming

Demo video

In this video we put it all together to incorporate live noise into our modelling. We’re executing one site at a time, but with a spreadsheet, the API client will automatically process a network of sites.

Dynamic noise floor modelling with a CRFS RFeye receiver

References

RFeye python library https://github.com/CRFS/python3-ncplib

CloudRF python script https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/integrations/CRFS

CloudRF API reference https://cloudrf.com/documentation/developer/

Posted on 2022-12-162022-12-18 by CloudRF

Multisite API

Today we have launched a new GPU accelerated API called “Multisite” which is capable of modelling hundreds of sites in the time we previously would have done one. This exponential increase in capability grew from our Best Site Analysis (BSA) capability which uses a Monte Carlo technique to test hundreds of random locations, and from the intermediate outputs, reduce them to reveal the optimal location(s) for radio communication.

The difference in Multisite is that the locations are not random, they are defined by the client.

A link is not coverage

Following customer feedback on our MANET planning tool which up until now created point-to-point links between nodes we investigated the feasibility of showing all the coverage, or in classic modelling terminology a point-to-multipoint aka a heatmap.

The reason this is important in MANET planning is you need to see the whole network coverage to understand where you are serving and where your gaps are. Links won’t show you coverage gaps unless it involves the node location so you will find out about these when it’s too late. Links are useful for seeing a network’s geometry and overall health but are of limited use for tactical RF planning where the network members are expected to be agile.

A bonus feature is that a heatmap scales better than links which get very cluttered in an interface when many overlap. A heatmap is much easier for a human to digest than a game of radio kerplunk which can overload an operator.

Faster, cleaner more scalable MANET planning

As this is GPU powered it is faster than the previous CPU powered link calculations. By removing the links, the view is less cluttered for busy networks and this can scale to a significant number of nodes in a single request.

During testing we were modelling 100 nodes in under 2 seconds, which includes communication latency to a production server in Europe. We achieved 3.1 seconds for 200 nodes at 10m resolution with 1km radius each and are confident we can do 500 nodes, like BSA does, and reduce the time further with infrastructure adjustments and a local server. Most of the delay is in data preparation and post processing, the actual computation is milliseconds so real-time modelling for multiple fast moving tracks is viable.

The heatmap exists in your archive as a standard layer so can be exported to KMZ, KML, GeoTIFF, SHP, URL or HTML via the normal archive functions.

Urban demo, NYC

In this early demo, MANET nodes are manually placed and adjusted. The coverage heatmap and links automatically update as nodes are added, removed or moved.

Multisite demo with MANET radios in a Urban environment

How do I enable the heatmap?

If you have a Gold account, open the MANET planning tool from the top bar then click the cog on the MANET window which appears. In the tools options, you can select either links, heatmap or both.

Documentation

The capability is available in API and UI version 3.7.

User docs: https://cloudrf.com/documentation/

Developer’s reference: https://cloudrf.com/documentation/developer/

A Gold subscription or a private server is required to use the MANET heatmap and/or the Multisite API which powers it.

This restriction does not apply to the MANET links and the points API which that uses.

Developer’s guide

A multisite request uses the same JSON structure and values as a area request only instead of a single transmitter object, it has an array of transmitters with no upper limit.

Each transmitter can have a different antenna so you could define several omni directional nodes with a single distant directional node, a common MANET design.

In this example, two MANET radios with 20MHz bandwidth in SNR mode are modelled together. The transmitters differ in location and power but the receiver, environment, model and output sections and common.

{
  "site": "TEST",
  "network": "MYNET",
  "transmitters": [
    {
      "lat": 51.773826,
      "lon": -2.403563,
      "alt": 1.5,
      "frq": 1350,
      "txw": 1,
      "bwi": 20,
      "ant": 0,
      "antenna": {
        "txg": 2.15,
        "txl": 0,
        "ant": 39,
        "azi": 0,
        "tlt": 0,
        "hbw": 360,
        "vbw": 360,
        "fbr": 2.15,
        "pol": "v"
      }
    },
    {
      "lat": 51.77450,
      "lon": -2.392245,
      "alt": 1.5,
      "frq": 1350,
      "txw": 2,
      "bwi": 20,
      "ant": 0,
      "antenna": {
        "txg": 2.15,
        "txl": 0,
        "ant": 39,
        "azi": 0,
        "tlt": 0,
        "hbw": 360,
        "vbw": 360,
        "fbr": 2.15,
        "pol": "v"
      }
    }
  ],
  "receiver": {
    "alt": 1.5,
    "rxg": 2.15,
    "rxs": 5
  },
  "model": {
    "pm": 1,
    "pe": 2,
    "ked": 1,
    "rel": 95
  },
  "environment": {
    "clm": 0,
    "cll": 0,
    "clt": "Minimal.clt"
  },
  "output": {
    "units": "m",
    "col": "SNR.dB",
    "out": 4,
    "nf": -100,
    "res": 5,
    "rad": 2
  }
}

A look forward

Now that we’ve published the API, the fun part of making interfaces for it has already started. The first of which is the enhancement to the MANET planning tool. Expect to see more interfaces and demos, at scale, shortly covering moving vehicles, large networks and ATAK integration where we plan to redefine the meaning of “radio check” with a whole network coverage map.

If you are an integrator or developer of a map and are interested in incorporating this unique layer, get in touch and save yourself years of R&D. White labeling options available.

Posted on 2022-11-28 by CloudRF

System updates – 3.6 (Nov 22)

Here’s a roundup of what’s changed since June. As always it’s been a busy period of development which we’ve matched with a focus on maintenance and bugfixes. Our backlog of feature and change requests stands at 28 for the UI and 23 for the API with all priority issues resolved.

The deck is now clear for a dynamic network planning feature which will be integrated in December.

UI changes, June to November

With 19 new features/improvements and 69 bugfixes in this period, the user interface has matured considerably due in large part to user feedback from the community. We’ve said no to a few feature requests also which is necessary to keep the interface technology agnostic and easy to use. That doesn’t mean we can’t support complexity or special waveforms directly in the API.

Radius increased to 400km for aircraft (3.0)
GPU engine integrated with best server and CSV analysis tools (3.0)
New 300m resolution for airborne broadcasting (3.0)
Received Signal Received Power (RSRP) option added to measured units (3.1)
Account information dialog (3.2)
GPU Best Site Analysis (3.2)
Custom WMS and WMTS map sources (3.4)
Satellite database updated (3.4.2)
Multi azimuth antenna patterns (3.5)
Route, multipoint and path path tools updated for all possible measurement units (3.5.1)
JSON templates system (3.6)

The long surviving Google Earth interface lives on and has been given a fresh wind thanks to code compatibility libraries which mean we no longer have to worry about breaking it with new Javascript. Long live Google Earth!

UI Changelog

## Version 3.6.1 (2022-11-28)

- Fix: Layer from archive would not load when clicking on the layer name or selecting "Add tower(s) only to map" button.
- Fix: Processing modal window getting stuck when using the Interference or Super Layer tools.
- Fix: Display the power of items loaded from the archive in the selcted power unit.
- Fix: Dynamically move navigator controls down to make space for imagery layer list.
- Fix: Prevent crash when disabling path profile analysis before calculation completes.
- Fix: Refreshes displayed clutter after deleting all clutter using the clutter manager.
- Fix: Selecting a template in the Google Earth interface crashes.
- Fix: MANET nodes sometimes clipped by the terrain resulting in partially hidden markers.
- Fix: Best site analysis tool sometimes goes into "zombie" state under bad network conditions.

## Version 3.6 (2022-11-10)

- Feature: Templates functionality makes use of the new API endpoints and JSON files.
- Feature: Added button to download the JSON template for both custom and system templates.
- Feature: Added modal to add/remove favourite system templates.
- Feature: Dropdown select of templates indicates if the template is a system or custom template by prepending with either "System" or "Custom" respectively.
- Fix: Styling issues on custom template save/delete modal.
- Fix: Reorganised "My Account" modal as was becoming cluttered. Logout button moved to top and managers split into a single row. API usage moved to the bottom.
- Fix: Some API errors which are returned as an array of values would not be parsed as an array, instead the error displayed would be a generic "Request failed." message which wasn't indicative of the error.
- Fix: Don't fire a GPU request when loading a GPU template.
- Fix: Adjusting the `rxs` field manually would not update the receiver sensitivity slider.

## Version 3.5.1 (2022-10-31)

- Feature: Route, Multipoint and Path tools able to display SNR, dBuV and RSRP units as well as dBm.

## Version 3.5.0 (2022-10-18)

- Feature: Multi-azimuth antenna support by sending a comma-separated list of values, for example, `0,120,240`.

## Version 3.4.2 (2022-09-21)

- Update: Satellite database updated to 2022-09-22.
- Feature: Fly to PPA when loading from the archive.
- Fix: Custom pattern vertical beamwidth not visible in the Google Earth interface.
- Fix: Profile drop down not populated and opening the clutter manager in the Google Earth interface.
- Fix: Sensitivity is loaded when selecting a template.
- Fix: Map attribution interfered with satellite timeline controls.
- Fix: Loading PPA from archive and then hovering over chart would cause a crash.

## Version 3.4.1 (2022-09-14)

- Fix: Template saves coax type.
- Fix: Problem toggling the azimuth mode in the Google Earth interface.
- Fix: Problem loading a template in the Google Earth interface.
- Fix: Switching between templates with engine set to GPU and CPU runs area calculation with incorrect engine.
- Fix: Saving a custom map URL cuts off part of URL after an "&".
- Fix: Suspends error logging when library blocked by client.
- Fix: Handle missing preferences.

## Version 3.4.0 (2022-08-31)

- Feature: Custom WMS and WMTS URLs for imagery layers.
- Feature: Attribution text lists API providers.
- Fix: Pruned dead and unsuitable map sources, such as "Blue Marble".
- Fix: Problems with editing coordinates.
- Fix: Antenna patterns not loading properly in some browsers.

## Version 3.3.0 (2022-08-23)

- Feature: Sets free space model with diffraction off and shows warning for best site analysis.
- Feature: Select last network when opening archive to match the last row.
- Feature: Make clutter go to ground.
- Fix: Improved area calculation error handling.
- Fix: Selecting a network in archive drop down when some items have no network would cause a crash.
- Fix: Legacy colour key images not displayed.
- Fix: Super layer KMZ quick-download button fixed for "Merge network"

## Version 3.2.0 (2022-08-15)

- Feature: Account Information dialog.
- Feature: GPU Best Site Analysis.
- Fix: Updates to colour schemas to match recent changes to colour schema API.
- Fix: Buildings layer cannot be removed.
- Fix: Receiver sensitivity icons missing.
- Fix: Creating a clutter profile does not refresh the list.
- Fix: RSRP breaks MANET.
- Fix: Opacity slider doesn't work.
- Fix: MANET reload by name click and best server for imperial units mi/f.
- Fix: Crash clicking layer checkbox while layer is loading.
- Fix: Default RSRP schema not always selected.
- Fix: Interference tool is trying to map colours to colour key.
- Fix: Crash saving clutter polylines with less than 2 coordinates or polygons with less than 3 coordinates imported from kml.
- Fix: Crash downloading MANET metrics report when node evauation failed.
- Fix: Power unit in MANET node details dialog displayed as undefined.
- Fix: Node percentanges on MANET metrics report sometimes NAN.
- Fix: Points CSV validation no longer works.
- Fix: Entity already exist in collection when disabling MANET.
- Fix: Crash adjusting bsa sliders when result loading failed.
- Fix: BSA images not recoloured on colour schema changed.
- Fix: Custom antenna polar plot not displayed in Google Earth.

## Version 3.1.0 (2022-07-18)

- Feature: Added Received Signal Received Power (RSRP) as an option to the "Measured Units" dropdown.
- Fix: Deleting multiple selected networks will now give the name of the networks rather than the ID.
- Fix: Selecting a PSK/QAM modulation will only show supported PSK/QAM bit-error-rate values, and likewise when selecting a LoRa modulation.
- Fix: Deleting a network from the archive now gives a better modal message rather than a browser `alert()` window.
- Fix: Occasional crash when computing azimuth and tilt for the mouse tootltip for satellite mode when the position has not been computed yet.
- Fix: Can't find variable `Map` in Google Earth interface.
- Fix: Crash in Google Earth when logging error information.
- Fix: Prevents crash in Google Earth interface when changing clutter profiles.
- Fix: Formatting issue in Google Earth.
- Fix: Helper dialog describing channel noise adjustment when changing bandwidth
- Fix: Tx Height AGL and RF Power textboxes extending over unit drop downs.
- Fix: Crash in Google Earth interface when you change properties that would update the map location when in web UI.

## Version 3.0.1 (2022-07-06)

- Feature: Added support for 180m and 300m resolutions.
- Fix: GPU is populated in dropdown of processing engines when GPU isn't available.

## Version 3.0 (2022-07-04)

- Feature: Radius limit now 400km.
- Feature: GPU processing no longer handled through WebSocket, instead goes through the same API as CPU processing for simplicity. Removed button to close GPU processing engine, instead you now just switch back over to CPU mode from the dropdown in the "Output" menu.
- Feature: Integration of GPU engine with other tools including best server and CSV import.
- Fix: Colour schema list gets populated with some empty values when using GPU mode.
- Fix: Prevents failure on area calculation due to invalid input from logging an error.
- Fix: Interference dialog not always populating networks.
- Fix: Duplicate entry for gpu in the engine drop down.
- Fix: Some antenna patterns were not being saved in templates.

API changes, v3.0 June to 3.6 November

With 30 improvements and features and 28 bugfixes, the API has largely remained the same from a developer’s perspective but it now has more consistency between the CPU and GPU engines, more choice with defining antenna azimuths and more useful error messages to help developer’s make better choices and save time.

Under the hood, the ATAK interface has had a major refactor to support customer’s official TAK Server’s with our infamous chatbot. A new chatbot management interface has been especially created which can validate certificate chains using OpenSSL to warn of issue before you get to them eg. “This certificate is invalid” or “This key is incorrect” or “Cannot ping your TAK server”.

GPU integration

The new GPU engine has received several updates throughout this period to add models, gains, antenna patterns, multi-azimuth patterns and output styling inline with the CPU engine, SLEIPNIR.

In September, the powerful Best Site Analysis capability was integrated with ATAK. When the SOOTHSAYER bot is connected to the TAK server, any polygon sent to it will generate a BSA layer.

Due to demand, the maximum radius for the GPU engine was increased to 150km to support broadcasting. During GPU testing we were generating 100 mega pixel (100,000,000 points) heatmaps in a few seconds which is too large for a client. We are working on a scalable solution to visualise images of this resolution as an image pyramid.

SLEIPNIR mods

The SLEIPNIR CPU engine is now at version 1.6.1 and has conditional smoothing of coarse DTM, knife edge diffraction from clutter (note we already do this for surface models) and slightly (3dB) more optimistic diffraction following feedback from a mountain rescue team.

Received Signal Received Power (RSRP) is not native to the engine instead of the API and the reliability variable can now be used for non-ITM models to provide a 10dB tuning margin where 50% is 0dB and 99% is 9.9dB path loss.

The maximum radius has been increased to 400km for airborne platforms. To support the larger radius, we’re also offering a new low resolution of 300m.

API management

The V1 “URL” API will be retired at the end of this year. Users who have integrated with this API should migrate to the new JSON API as soon as possible. The new JSON API has been powering the web interface for almost two years.

Reference: https://cloudrf.com/documentation/developer/

API Changelog

## Version 3.6.0 (2022-11-25)

- Deprecation: Added deprecation message to `v1` API endpoints. The `area` and `path` will be removed on the 31st December 2022. Please migrate any scripts to the new JSON API and see https://cloudrf.com/documentation/developer/
- Fix: Chatbot welcome-storm with other chatbots.
- Fix: Obsolete paths on terrain coverage map and HTML PPA response.
- Fix: Improvements to automation testing.
- Fix: Sending malformed JSON to a `v2` API endpoint now returns a useful error message.
- Fix: Deprecated `v1` API endpoints were incorrectly counting API credits.
- Fix: Power value of 1mW for GPU fails.

## Version 3.5.0 (2022-11-10)

- Feature: Moved from database-driven to JSON-driven templates with new API endpoints to manage custom templates.
- Feature: System templates can be retrieved and saved as a favourite using new endpoints.
- Fix: Race condition on GPU processing files as its so damned fast.
- Fix: Public shares for GPU layers needed reprojecting to EPSG 3857.

## Version 3.4.0 (2022-10-18)

- Feature: Gain support for GPU engine.
- Feature: Antenna support with azimuth and tilt for GPU engine.
- Feature: Multi-azimuth support for antennas by sending a comma-separated list of values in the `antenna.azi` value, for example, `0,120,240`.
- Fix: Path tool on TAK successfully returning only about 50% of the time.
- Fix: Area requests to `v1` API returning colour key data in improperly formed string values.
- Fix: `clutter` command on TAK chatbot working again.
- Fix: Resolved issue with custom colour schemas and low resolution screens.
- Fix: Sanity check ADF files.
- Mod: Default clutter templates adjusted. Urban height reduced to no more than 2m.
- Mod: GPU engine max radius capped at 10km (CPU max = 400km).

## Version 3.3.0 (2022-09-22)

- Feature: Support for TAK server 4.7 through Chatbot and ATAK.
- Feature: Extended response information when executing `id` to Chatbot through ATAK.
- Feature: Support for GPU BSA on Chatbot with the multipoint tool through ATAK.
- Feature: Added new chatbot manager to spin up chatbots on demand which interact between TAK servers and API.
- Feature: Extended preferences functionality to allow for custom imagery.
- Feature: Delete all clutter button added to clutter form.
- Fix: Processing engine saved in templates.
- Fix: Commercial restrictions messages now return HTTP 403 (Forbidden) rather than HTTP 400 (Bad Request).

## Version 3.2.0 (2022-08-15)

- Feature: System colour schemas no longer able to be deleted by a user so that users will always have a list of schemas to choose from.
- Feature: Height ceiling increased to 120km over 60km.
- Feature: When using Greyscale GIS colour schema no longer returns validation error for mixing outputs and schema.
- Feature: Improvements to the PPA KMZ export with fresnel support and new icons for transmitter, receiver and obstructions.
- Fix: Improvements to the functionality of the colour schema generator.
- Fix: Creating a BER colour schema fails with a HTTP 500.
- Fix: Update to `preferences` stripping out underscores from colour schemas.
- Fix: Google Earth layer no longer allows to manage colour schemas. Added notice with workaround instructions.

## Version 3.1.0 (2022-07-18)

- Feature: Improvements to `preferences` to extend to additional values and give information about a users plan.
- Feature: Improvements to precendence of preferences, where in some cases a previous request values will be taken over a users preferences.
- Feature: Colour palette bucket limit increased to 75.
- Feature: Return request to `preferences` as a correct JSON response.
- Feature: Users with a private server will now be indicated when they make a request to `preferences`.
- Feature: Colour pallette creator extended to support Bit-Error-Rate measured units.
- Feature: Bit-Error-Rate modulation extended from 10e-6 to 10e-8.
- Feature: Allowed support for Received Signal Received Power (RSRP) measured units with an `out` value of `6`.
- Feature: Added default RSRP colour key.
- Feature: SLEIPNIR 1.6.1 calculates and returns (LTE) RSRP if selected
- Feature: SLEIPNIR 1.6.1 uses reliability for non-ITM models with a 10dB range. 50% = +0dB, 99% = +9.9dB
- Fix: Successful deletion of networks in the archive are returned with a success `message` rather than `error`.
- Fix: Correct names of plans when making a request to `preferences`.
- Fix: BER colour palette in JSON response was missing unit.
- Fix: Improvements to the default `PATHLOSS.dB` colour key.
- Fix: Hata model high-plateau issue resolved in SLEIPNIR 1.6.1

## Version 3.0.1 (2022-07-06)

- Feature: Resolution supported up to 300m.

## Version 3.0 (2022-07-04)

- Feature: Improvements to GPU processing with the use of remote processing nodes.
- Feature: GPU produced images are now styled in the API based on the specified colour schema.
- Feature: Extended `data` API to retrieve a tile based only on tile name.
- Fix: Logic issue with users mixing credits and plan was incorrectly refusing service to users with expired plans, but spare credits.
- Fix: Custom clutter profiles are created with the list of 101 to 199 clutter codes.
- Fix: Obtaining height data from OpenStreetMaps would sometimes fail.
- Fix: KMZ download failing on equator

That’s all folks.

Posted on 2022-06-222022-06-22 by CloudRF

Dynamic network planning with hardware APIs

Location aware radios

Modern digital radio systems often have Application Programming Interfaces (APIs) for remote management. They also commonly have Global Navigation Satellite System (GNSS) modules for location awareness which enables “network maps” of where the nodes are. These vendor maps are great at showing where nodes are now (provided they are in coverage!) but what they lack is the ability to plan where nodes could be moved to.

When you combine these key features with our open standards modelling API you get a powerful new capability which allows you to observe the network now, and by moving or adding a simulated node, see the network in the future.

Case study – Trellisware

Trellisware^TM are a market leader in Mobile Ad-hoc Networks (MANET) whose versatile radios work where others fail due to their spectrum efficient TSM waveform. It’s currently in service with Government, Commercial and First responder markets.

The radios have a comprehensive API and integrated software services which allows for remote operation on a IP based network.

We were loaned some TW-950 Shadow radios to explore API integration. In a few days we were able to create an API client (in Python) to interface between the Trellisware API and our RF modelling API on SOOTHSAYER 1.3 which has a MANET planning tool.

Our Python client would interface with the radio network via the Ethernet connector on the side of a TW-950 radio from where the API would expose node metadata.

We would fetch this metadata (as JSON) and package it into a JSON document compatible with our Points API, which powers our MANET and route analysis tools. In the interface’s MANET tool, a new ‘play’ button pulls in the network document and models it through our fast API. Each link is tested using the real parameters, with minimal user interaction.

The flowchart is depicted below.

Ethernet adapter for connecting the hardware to SOOTHSAYER

Once the data is displayed in the SOOTHSAYER interface, an operator can choose to move a node by dragging it or add an entirely new node, using settings of their choice, into the mix. This new node will be modelled alongside the rest of the nodes (many-to-many) to visualise what the impact of the new node will be.

Trellisware (Blue) and CloudRF (Yellow) APIs and components

A faster OODA loop

The Observe, Orient, Decide, Act (OODA) planning loop is an established concept which determines success in fast moving communications environments such as a fire or Police incident.

By combining real-time situational awareness with live modelling we can exercise scenarios and reach sound decisions much faster than by either guessing or using trial and error as is often the case in tactical communications in complex environments. The benefit is faster more efficient use of limited resources.

A Trellisware network map enhanced with two planned nodes to the right.

Demo: Do we launch the drone?

Deploying a drone equipped with a radio is a guaranteed way to fix MANET network issues, especially in cluttered urban environments. It’s resource intensive and risky as the drone is valuable, the radio, and network it enables, is arguably more valuable plus the battery life is very limited so this asset must be used sparingly, which is where planning comes in.

Placing a repeater drone “overhead” is not needed, unless you’re using it for observation also. If the drone has a vertical dipole, overhead would actually be the worst place for it due to the donut shaped antenna pattern as some early OEMs learnt the hard way.

A better place for a communications relay drone is at altitude but on the edge of the target network where it will be at less risk (and will present less risk to net members below it in the event of failure) but it will still be able to serve as an effective repeater.

As recent MANET demos have proven, this repeater could be effective from several miles away.

Demo of dynamic MANET planning in SOOTHSAYER with Trellisware radios

Look ahead

Now that we have a simple standards based, repeatable, method for adding live radios we’ll roll this into future SOOTHSAYER releases, the next of which is 1.4, scheduled for Q3 2022.

Customers can make their own plugins in any language to get their hardware data packaged as a JSON document for either SOOTHSAYER’s MANET tool or direct to the points API which powers it. You can find example scripts in various languages on our Github site and we are available to assist with bespoke integrations.

References

API examples: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/APIv2

API specification: https://cloudrf.com/documentation/developer/swagger-ui/

Contact

If you are a hardware manufacturer or integrator looking to add this type of capability into either your own map or ours, get in touch as we know what we’re doing and it will save you years of R&D.

Email support@cloudrf.com for more information on how you can achieve dynamic planning quicker.