Posted on

Dynamic network planning with hardware APIs

Dynamic MANET network planning

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

TW-950 Shadow

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

Posted on

System updates – June 2022

Clutter not LiDAR

We’ve been busy as always improving our service. Here’s a visual roundup of updates we’ve pushed recently for API version 2.9 and UI version 2.8, current as of the 13th June 2022.

For the latest updates click the versions in the corner of the interface.

Software change log shortcuts

New features

Variable building heights

Our global building data has had a lot of attention recently from 5G operators and (counter) drone companies.

Previously you could use a mixture of sources to define a building from manipulating your clutter profile values to adding your own as GeoJSON or KML. Our third party buildings which we offer as an enrichment option in the Landcover menu were lacking height data so we used a user defined value from the clutter profiles. For many users on default settings, this resulted in buildings at 6m height, adequate for a suburb with similar architecture but no use for a vertical city like Chicago.

Our building data now has unique heights and we’ve modified our clutter system to match it. Our SLEIPNIR engine could already handle user defined height data due to previous modifications around custom clutter.

In the CloudRF UI, you can define the 9 system codes and only 9 custom codes.

Customers with private servers can define up to 255 clutter codes in clutter files on their system.

Variable building heights

Diffraction for 3D clutter

Previously we modelled single knife edge diffraction only for the surface model, and considered through building attenuation for the clutter but now we can do it for clutter.

In the screenshot below, the COST model is used with 3D clutter for a suburb with a treeline along a train track. Both the buildings and trees are displaying diffraction, recognised by a shadow beyond an obstacle which gradually comes back into coverage as the obstacle angle decreases.

Clutter not LiDAR
This image does not use LiDAR. It is 10m landcover with 2m buildings on a 30m DTM.

DTM option instead of LiDAR

We’ve worked with LiDAR in modelling for years and its great but has its limitations, especially with non line of sight communications where LiDAR will show a strong signal for the roof of a building and produce a very conservative “shadow” immediately behind an obstacle until knife edge diffraction kicks in.

Being conservative in RF planning isn’t a bad thing but with proper building height data we can enable more accurate through-building attenuation in cities, worldwide.

Nothing beats LiDAR for LOS analysis so we’ll still consider requests for uploading public LiDAR but for most of the world where there isn’t LiDAR, we now have an improved solution.

For rooftop planning, we recommend LiDAR but for through building/tree modelling at ground level use calibrated clutter instead. You can enable this option in the Clutter menu.

You can access this mode in the interface “Clutter” menu or in the JSON API with {clm: 2} in the environment object.

Clutter on DTM
LiDAR DSM

Delete-all custom clutter

API users can now delete all their custom clutter by requesting to delete id=0. This will soon be added to the UI with a button.

Added my-metrics endpoint for API usage

We’re now logging metrics for all the analytics APIs which count against your API use. We have an API to generate charts and will soon add client side charts so you can see how your API use breaks down by tool and time.

Automated testing

Testing is a critical part of maintaining our quality of service which is becoming increasingly complex. We’ve added automated workflows to our development environment to help catch bugs earlier and complement the manual interface testing.

This is implemented for the API and UI repositories at the code function level as well as our regular regression testing at the API level and now third party automated exception handling.

Improvements

Conditional terrain smoothing

We’re smoothing terrain for those super sampled locations. For example if you went to Africa which is mostly 30m DTM, and requested a 2m plot, we would be super-sampling the DTM by a factor of 15 which used to result in ugly artefacts on hillsides. We’ve fixed that and are able to have smooth hills and precision 2m clutter in remote areas 🙂

Rwanda with super sampled 30m DTM and 2m buildings with diffraction

Up to 255 clutter codes

In the CloudRF UI, you can define the 9 system codes and only 9 custom codes but the backend system supports up to 255 unique classes of clutter. You set the height and density for each so this could be skyscrapers for a city or crops.

Customers with private servers can define up to 255 clutter codes in clutter files on their system.

Diffraction loss adjusted down by 3dB

Following feedback from Mountain rescue teams using our service who were surprised to find coverage in modelled dead spots, we investigated our diffraction model and found it was too conservative by at least 5dB. We’ve adjusted the loss it applies down by 3dB so it’s now more optimistic, but still cautiously conservative.

Extended southern limit to -89N

You can model on Antarctica now. We don’t have DTM there so it’s flat as far as our service is concerned but if you are using the Satellite tool, this now works on the continent for testing for the horizon on a route etc.

Fixes

  • Replaced source for 3D buildings from a commercial supplier to Openstreetmap.org
  • Points requests was failing to handle some responses from the engine
  • Returning correct HTTP status codes for errors now
  • Template list is returned as JSON in the UI
  • Template authentication has been upgraded to the header “key”
  • Credits balance was reported incorrectly for some API calls
  • Remote tile fetching was corrupting some local tiles
  • Sanity check unworkable paths before passing into engine (eg. 1m or 1000km)
  • Some JSON responses malformed
  • Splicing of points near the Rx in a points request works better for a figure of 8 route.
  • Preferences was breaking if no lat or lon set
  • Performance improvements to “sea tiles” used for offshore planning.
  • Changed noise floor validation to -130 to -50dBm
  • Fixed issue with some interference API calls missing id values

Posted on

4D Satellite visibility tool

Satellite route

Satellite communications are readily accessible, unless you live in a polar, mountainous or dense urban area.

Using our modelling API and third party satellite data courtesy of CELESTRAK, we are able to determine if a chosen satellite is visible from a given point on earth. Unlike “satellite finder” apps, we can provide a lot more than a location in the sky. Our tool can:

  • Show if the view is obstructed or not
  • Show the azimuth and elevation toward the satellite upon a 3D map
  • Consider ground clutter such as buildings and trees
  • Consider the fresnel zone clearance based upon the frequency (A UHF signal can have a 50m fresnel zone at 10km)
  • Consider the location at a given time for LEO satellites (Starlink, OneWeb etc)

Route analysis

Satellite_norway
Route analysis in Norway for a equatorial satellite

Points analysis

Points analysis in Norway for a equatorial satellite

Time based analysis for LEO

Low Earth Orbit satellites move fast at a relatively low altitude. For this we can select a time.

LEO satellite
LEO satellite

Searching for a satellite

The CELESTRAK database has every satellite, going back to Sputnik 1 in 1957. We have filtered active satellites which you can search by name or NORAD designator.

Satellite database
Satellite database

Urban?

We have global 3D buildings and 10m Landcover so you can model obstacles. You can also draw your own obstacles using the custom clutter tools.

Urban satellite
Urban satellite

More information

Instructions for using the tool are in the documentation.

A premium (Silver or Gold) plan is required to use this functionality. If you are an integrator and would like to build your own interface using our powerful modelling API this is encouraged, and will save you years of R&D and expensive hosting.

You can get the satellite TLE data over at CELESTRAK.

API schema is here: https://cloudrf.com/documentation/developer/swagger-ui/

Posted on

GPU propagation engine

5G cell

Our fast GPU engine is perfect for modelling wireless coverage

We have developed the next generation of fast radio simulation engines for urban modelling with NVIDIA CUDA technology and Graphics Processing Units (GPUs).

The engine was made to meet demand across many sectors, especially FWA, 5G and CBRS for speed and accuracy.

As well as fast viewsheds, it enables a new automated best-site-analysis capability, which will accelerate site selection and improve efficiency whilst keeping a human in the loop.

Designed for 5G

5G networks are much denser than legacy standards due to the limited range of mmWave signals, necessary for high bandwidth data. The same limitation means these signals are very sensitive to obstructions, and Line of Sight (LOS) coverage is essential for performance.

With 1 metre accuracy and support for LiDAR, 3D clutter and custom clutter profiles, you can model rural and urban areas with high precision.

Area coverage

The simplest mode is a fast “2.5D” viewshed (with a path loss model) which creates a point-to-multipoint heatmap around a given site using LiDAR data. Ours has better Physics than some of the “line of sight” eye candy on the market and doesn’t have trouble with Sub-GHz frequencies which are harder to model accurately.

This is up to 50 times faster than our multi-threaded CPU engine, SLEIPNIR.

GPU demo January 2022

In this mode we can do diffraction and material attenuation with our custom clutter classes.

Best site analysis

Best Site Analysis (BSA) is a monte-carlo analysis technique across a wide area of interest to identify the best locations for a transmitter. This can be done quickly with a new /bsa API call. The output will identify optimal sites, and just as important, inefficient sites.

This feature is powerful for IoT gateway placement, 5G deployments and ad-hoc networking where the best site might presently be determined by a map study based on contours as opposed to a LiDAR model.

Best Site Analysis on ATAK

High speed

Our GPU engine is up to 50 times faster through the API than the current (CPU) engine SLEIPNIRTM

By harnessing the power of high performance graphics cards, we are able to complete high resolution LiDAR plots in near real time, negating the need for a “go” button, or even a progress bar. This speed enables API integration with vehicles and robots which will need to model wireless propagation quickly to make better decisions, especially when they’re off the grid. It was designed around consumer grade cards like the GeForce series but supports enterprise Tesla grade cards due to our card agnostic design.

Economical

Our implementation is efficient by design. We want speed to model wireless coverage but not if it requires kilowatts of power. During testing we worked with older GeForce consumer cards and were able to model millions of points in several milliseconds with less than 50W of power. Or in other words, the same power as flicking a light bulb on and off.

Any fool can buy large cards and waste electricity, but we’re proud to have a solution which is fast and economical. This also means it can be run on a laptop as it’s available now as our SOOTHSAYER product.

Open API

The GPU engine is an “engine” parameter in our /area API so you can use it from any interface (or your own custom interface) by setting the engine option in the request body. The OpenAPI 3.0 compliant API returns JSON which contains a PNG image so for existing API integrations using our PNG layers there will be no code changes required to enable it.

Self-hosted GPU server

Instead of buying milk every month you can buy the cow. We also sell SOOTHSAYER which is a self-hosted server with our GPU engine onboard. It supports NVidia GPU cards from Maxwell architecture onwards and most enterprise Hypervisors like ESXi and Proxmox. You get to use your existing LiDAR data too, so you’re not buying it twice.

To see how easy it is to setup a GPU card with SOOTHSAYER we’ve made a video:

SOOTHSAYER GPU setup

Accessible

Using GPU cards to model Physics, including EM propagation, is an established concept dating back 20 years, despite businessmen claiming otherwise. What is novel here, is making this exciting technology accessible to users priced out of premium tools.

Staying true to CloudRF’s accessible and affordable principles, we’ve included it in our service as an optional processing engine.

CloudRF is a member of the NVIDIA inception program

Posted on

Enhancing accuracy with environment profiles

Clutter profile manager

In radio planning, accurate terrain data is only half the story.

The other data you need, if you want accurate results, is everything above the surface such as buildings and trees.

This is known as land cover or in radio engineering; clutter data.

Clutter data

Clutter manager with 18 bands

In October 2021, the European Space Agency released a global 10m land cover data set called WorldCover with 9 clutter bands.

In our opinion, the ESA data is a sharp improvement on a similar ESRI/Microsoft 10m land cover data set also published this year.

The land cover can be used to enhance coarse 30m data sets to distinguish between homes and gardens, or crops and rivers. It’s space mapped so has every recent substantial building unlike community building datasets which can be patchy outside of Europe.

This data was previously very expensive. A price reflected in the eye watering pricing of legacy WindowsTM planning tools.

The data has 9 bands which have been mapped to 9 land cover codes in Cloud-RFTM. Combined with our recent 9 custom clutter bands, we have 18 unique bands of clutter which you can use simultaneously.

Read more about the codes in the documentation here.

Explore the data we have on the ESA WorldCover viewer application here:

https://viewer.esa-worldcover.org/worldcover/

Custom clutter enrichment

We have integrated the 10m data into our SLEIPNIRTM propagation engine which as of version 1.5, can work with third party and custom clutter tiles simultaneously, in different resolutions.

This is significant as it means you can have a 30m DSM base layer, enhanced with a 10m land cover layer, enriched further with a 2m building which you created yourself. Effectively this gives you a 10m global base accuracy with potential for 2m accuracy if you add custom obstacles. The interface will let you upload multiple items as a GeoJSON or KML file.

Demo 1 – The Jungle

Always a tricky environment to communicate in, and model accurately due to dense tree canopies. In this demo, a remote region of the Congo has been selected at random for a portable VHF radio on 75MHz with a 3km planning radius.

This area has 30m DSM which out of the box produces an unrealistic plot resembling undulating flat terrain. This is because the thick tree canopy is represented as hard ground and the signal is diffracting along as if it were bare earth. The result therefore is that 3km is possible in all directions.

By adding our “Tropical.clt” clutter profile, calibrated for medium height, dense trees, we get a very different view which shows the effective range through the trees to be closer to 1km, or less, with much better coverage down the river basin, due to the lack of obstructions.

Demo 2 – A region without LiDAR

Scotland has very poor public LiDAR compared with England which has good coverage at 1m and 2m.

For this demo, Stirling was chosen which has 30m DSM only. A cell tower on a hill serving the town produces an optimistic view of coverage by default but when enhanced with a “Temperate.clt” clutter profile, calibrated for solid and tall town houses and pine forests (eg. > 50N, Northern Europe, Northern USA) we get a much more conservative prediction. As a bonus, the base resolution has improved three fold to 10m.

Demo 3 – A region with 2m LiDAR

You might think if you’ve got high resolution LiDAR data that’s enough. Wrong. Soft obstacles like trees especially will produce excessive diffraction as if they were spiky terrain. This manifests itself as optimistic ‘great’ coverage due to the diffraction coverage. By adding our “Temperate.clt” profile again we make trees absorb power and see where there are nulls in our coverage – beyond the houses and woods.

Despite our land cover being only 10m resolution, we are able to benefit from the full LiDAR resolution with 2m accuracy.

Inspecting a profile

The path profile tool will now show you colour coded land cover as well as custom clutter and 3D buildings. Crops are yellow, grass is green(!), Trees are dark green, built-up areas are red, 3D buildings are grey, water is blue…

The most significant feature in this image isn’t the coloured land cover, or the custom building (as both are features we’ve done before), or the fact we know the tidal river Severn sits lower than the man-made Canal beside it, It’s the fact that both are being used in the same model at the same time. They are different sources, different resolutions, different densities…

Path profile for 860m link showing 2m LiDAR, 10m Land cover and 2m custom building

Using and editing a profile

Clutter menu with 3D buildings enabled

Once you’ve got the hang of switching profiles you may find it needs optimising for your region. With the clutter manager in the web interface, premium customers can create their own profile based on field measurements for highly accurate predictions. After all no two forests or neighbourhoods are the same density.

Create your perfect profile and save it to your account. The system has 5 regional profiles ready for all users and you can add your own.

To use them, pick from the Clutter > Profile menu and ensure “Landcover” is set to “Enabled”.

If you have created custom clutter and want to use that, set Custom clutter to “Enabled” to blend it in.

For more see the web interface clutter section in the documentation.

Using clutter from the API

We played with a few designs before settling on this very simple template method where you set a profile within the environment menu as follows. This is a new value “clt” and you can still use the existing “cll” and “clm” values to manage the system clutter and custom clutter layers.

JSON request excerpt for a temperate “European” profile, with custom clutter, with 3D buildings and a 3D building density of 0.25dB/m

  "environment": {
        "clt": "Temperate.clt",
        "clm": 1,
        "cll": 2,
        "mat": 0.25
    },

Example for Jungle profile, without custom clutter, without 3D buildings.

  "environment": {
        "clt": "Jungle.clt",
        "clm": 0,
        "cll": 1,
        "mat": 0
    },

Further reading:

CloudRF API on Postman: https://docs.cloudrf.com/

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

What’s next?

Now that we have highly configurable environment profiles. it’s time to tune them with field testing. We’ve bought a heap of comms equipment and will be using it to optimise these profiles with real world measurements.

Posted on

Adding radio coverage to LeafletJS or Openlayers

Leaflet ImageLayer demo

LeafletJS (32k stars on Github) and it’s predecessor Openlayers (8k stars) are very popular web mapping libraries in use with companies and organisations the world over. They provide powerful, fast and easy client side 2D maps written in Javascript which can show almost any type of data…

Whilst typically used on public facing web maps with public tile servers like OpenStreetMap, the libraries are versatile enough to be used on private networks with private WMS or TMS tile servers.

Adding the CloudRF API is made possible through our open standards such as JSON, PNG, EPSG:3857, EPSG:4326 and HTTP. In this post we show two new examples for integrating the Area API.

LeafletJS Area API integration

The workflow for Leaflet is as follows:

  • Fetch the selected location, in this case a cursor click and transform to EPSG:4326 co-ordinates (Latitude, Longitude)
function onMapClick(e) {
    addRFLayer(e.latlng.lat,e.latlng.lng);
}
map.on('click', onMapClick);
  • Take a pre-built JSON object containing a complete request representing “a radio”. Replace the transmitter lat and lon fields with our latitude and longitude.
  • Send the full request as a HTTP POST along with an API key in the header to https://api.cloudrf.com/area
  var xhr = new XMLHttpRequest();
  xhr.withCredentials = false;
  xhr.addEventListener("readystatechange", function() {
    if(this.readyState === 4) {
      AddLayerToMap(this.responseText);
    }
  });
  xhr.open("POST", "https://api.cloudrf.com/area");
  xhr.setRequestHeader("key", key);
  xhr.send(request);
  • When the response returns, parse the JSON to extract the PNG_Mercator URL and bounds array.
  • Using Leaflet’s imageOverlay method, place the image upon the map, tweaking the opacity to 50% in the process, with the bounds rearranged in [SOUTH, WEST], [NORTH, WEST] order.
var bounds = json.bounds; // CloudRF uses NORTH,EAST,SOUTH,WEST
var  imageBounds = [[bounds[2], bounds[3]], [bounds[0], bounds[1]]];
L.imageOverlay(json.PNG_Mercator, imageBounds).setOpacity(0.5).addTo(map);

Openlayers Area API integration

The workflow for Openlayers is as follows:

  • Fetch the selected location, in this case a cursor click and transform to EPSG:4326 co-ordinates (Latitude, Longitude)
map.on('click', function(evt){
  var pt = ol.proj.transform(evt.coordinate, 'EPSG:3857', 'EPSG:4326');
  addRFLayer(pt[1],pt[0]);
});

  • Take a pre-built JSON object containing a complete request representing “a radio”. Replace the transmitter lat and lon fields with our latitude and longitude.
  • Send the full request as a HTTP POST along with an API key in the header to https://api.cloudrf.com/area
  •   var xhr = new XMLHttpRequest();
      xhr.withCredentials = false;
      xhr.addEventListener("readystatechange", function() {
        if(this.readyState === 4) {
          AddLayerToMap(this.responseText);
        }
      });
      xhr.open("POST", "https://api.cloudrf.com/area");
      xhr.setRequestHeader("key", key);
      xhr.send(request);

  • When the response returns, parse the JSON to extract the PNG_Mercator URL and bounds array.
  • Using openlayers’ Image method, place the image upon the map, tweaking the opacity to 50% in the process, with the bounds rearranged in [WEST,SOUTH,EAST,NORTH] order.
  • var imageLayer = new ol.layer.Image({
    opacity: 0.5,
    source: new ol.source.ImageStatic({
    url: json.PNG_Mercator,
    projection: map.getView().getProjection(),
    imageExtent: ol.proj.transformExtent(boundsWSEN, 'EPSG:4326', 'EPSG:3857')
    })
    });
    map.addLayer(imageLayer);

    Source code

    Get examples for both slippy maps at https://github.com/Cloud-RF/CloudRF-API-clients

    API reference

    API documentation and examples are at https://docs.cloudrf.com

    A Swagger OpenAPI3.0 specification is at https://cloudrf.com/documentation/developer/swagger-ui/

    Other uses

    Beyond heatmaps here are a few suggestions:

    1. Draw a polyline to simulate a link with the /path API
    2. Draw a freehand route to test a route with the /points API
    3. Draw a sectorial antenna as a polygon with an azimuth and beamwidth and send to the /area API
    4. Use the Trilateration colour schema to model a detected signal or a distant handset with the /area API
    Posted on

    Mapping mesh networks

    Mesh network

    Mobile ad-hoc networks (MANET) are an increasingly popular architecture in emergency services and Defence communications. Unlike classic repeater based networks, MANET radio network communications do not have fixed infrastructure so must form self-healing, self-routing networks.

    MANET radio modules are well suited to working either off-grid away in remote areas or for providing resilience and independence in well served cities which may be suffering from power and/or network failure.

    The bandwidth requirements and throughput of MANET networks varies substantially by waveform. Some are designed for range, others maximum throughput. For this reason, manufacturers offer a range of frequency modules.

    Why RF planning tools don’t get used for emergency networks

    RF planning software has evolved substantially in the 30 years it’s been used to build out fixed infrastructure networks. Time sensitive customers such as the emergency services have a difficult relationship with these tools. They need them, and often buy them, but don’t have the time to use them to their full capabilities. As a result they rarely get used on anything except training and exercises. Even then the numbers of staff directly interfacing with them will be very small, even in very large organisations of radio users.

    The focus for most RF tools is planning with static sites. Whether that’s clicking on a map or uploading a spreadsheet of hundreds of locations it’s still static. MANET requires dynamic inputs and continuous computation which is where APIs come to the fore…

    An API for MANET

    Cloud-RF’s latest API has a function designed for ad-hoc networks called ‘points’. The points API functions like a point-to-point profile in terms of it’s input and output except it accepts an array of transmitters. This means you can test 10,50 or 500 transmitter nodes back to a single receiver in a single API call. It’s also fast as you’d expect and can model a link every millisecond so the 870 distinct links demonstrated in the video were processed in under a second, every second.

    For more information on the points API see our documentation here: https://docs.cloudrf.com

    Radio mapping planning

    In this video, we demonstrate the Cloud-RF points API to model a MANET network (Mobile Ad-hoc Network). For this demo 30 nodes were moved around a 16km track covering a variety of terrain. Each node was tested against 29 siblings for a total of 870 links per second.


    Coloured links denote good (green) average (amber) and poor (red) links between the nodes and map to 5dB, 10dB and 20dB signal-to-noise ratios. Only links exceeding 5dB SNR are shown or it looks like a bad game of kerplunk!

    The radio settings used were L band (1-2GHz) with only 1 watt of power. This conservative start setting was chosen to show a dynamic range of links. Later in the video the template is switched at the database to demonstrate the impact or gain of using different bands such as 2.4GHz and 500MHz.

    Integrating your data

    The demo video used mock data and an unpublished script to present the results as a KML. The source of the data is irrelevant so long as it’s accurate and time sensitive. This could be a radio vendor’s dashboard or database. Many of the leading vendors such as DTC, Harris, Persistent Systems, Silvus and Trellisware have location aware GPS modules and software interfaces to display reported radio positions.

    The required format for a point is WGS84 decimal degrees. The height is taken from the template which is defined within the body of the points request. The new APIv2 makes defining a template easy as a JSON object so you can have a local archive of template .json files.

    A suggested workflow for API integration for dynamic points is as follows:

    1. Fetch a list of all radio locations as decimal degrees
    2. Choose a template as a JSON object
    3. Make an API request using the data and a client script to https://api.cloudrf.com/points
    4. Parse the JSON response to extract the results for each node
    5. Put the results on a map as lines
    6. Style the lines based upon your own local rules for your equipment, QoS and waveform eg. < 5dB is red

    Download example client scripts from our Github site: https://github.com/Cloud-RF/CloudRF-API-clients

    For assistance with integration and hosting options email support@cloudrf.com

    Autonomous vehicles

    Where this points API will really add value is in mapping and assisting autonomous vehicles who are invariably fitted with MANET radio modules. Whether it’s a drone or a UGV, this API can be used to rapidly exercise multiple routes to help make better decisions.

    Posted on

    RF penetration demonstration

    During infantry training, soldiers are shown firsthand the impact of different weapons upon different materials to help them make better decisions about good cover versus bad cover. Spoiler: The railway sleeper doesn’t make it 🙁

    As tactical radios have moved several hundred megahertz up the spectrum from their cold-war VHF roots, material attenuation is a serious issue which needs demonstrating to enable better route selection and siting. Unlike shooting at building materials it’s hard to visualise invisible radio signals, and therefore teach good siting, but equally important as ground based above-VHF signals are easily blocked in urban environments.

    This blog provides a visual demonstration of the physical relationship between different wavelengths and attenuating obstacles only. It does not compare modulation schemas, multi-path, radios or technologies.

    Bricks and wavelengths

    Clutter data refers to obstacles above the ground such as trees and buildings. Cloud-RF has 9 classes of clutter data within the service which you can use and build with. Each class (Bricks +) has a different attenuation rate measured in decibels per metre (dB/m). This rate is a nominal value based upon the material density and derived from the ITU-R P.833-7 standard and empirical testing with broadcast signals in European homes.

    A signal can only endure a limited amount of attenuation before it is lost into the noise floor. In free space attenuation is minimal but with obstacles it can be substantial. This is why a Wi-Fi router in a window can be hard to use within another room in the house but the same router is detectable from a hill a mile away.

    The attenuation rate is an average based upon a hollow building with solid walls.

    Common building materials attenuate signals to different amounts based on their density and the signals wavelength.

    A higher wavelength signal such as L band (1-2GHz) will be attenuated more than VHF (30-300MHz) for example.

    A long wavelength signal like HF will suffer minimal attenuation making it better suited to communicating through multiple brick walls.

    The layer cake house

    A brick house is not just brick. It’s bricks, concrete blocks, glass, insulation, stud walls, furniture and surfaces of varying absorption and reflection characteristics. Modelling every building material and multi-path precisely, is possible, given enough data and time due to the exponential complexity of multi-path but wholly impractical.

    A trade-off for accurate urban modelling is to assign a local attenuation value. It’s local since building regulations vary by country and era so a 1930s brick house in the UK has different characteristics to a 1960s timber house in Germany. Taking the brick house we can identify the nominal value by adding up the materials and dividing it by the size.

    For example, 2 x solid 10dB brick walls plus a 5 dB margin for interior walls and furniture would be 25dB. Divide this by a 10m size and you have 2.5dB/m. Using some local empirical testing you can quickly refine this for useful value for an entire city (assuming consistent architecture) but in reality the *precise* value will vary by each property, even on a street of the same design, due to interior layouts and furniture.

    Range setup

    We created nine 4 metre tall targets using each of the 9 clutter classes in attenuation order from left-to-right, measuring 10x10m and fired radio-bulletsTM at them from a distance of 300m using the same RF power of 1W.

    The following bands were compared: HF 20MHz, VHF 70MHz, UHF 700MHz, UHF 1200MHz, UHF 2.4GHz. SHF 5.8GHz.

    The ITU-R P.525 model was used to provide a consistent reference.

    Only the stronger direct-ray is modelled. Multipath effects mean that reflections will reach into some of the displayed null zones, with an inherent reflection loss for each bounce, but these are nearly impossible to model accurately and in a practical time.

    Here are the results.

    HF 20MHz

    VHF 70MHz

    UHF 700MHz

    UHF 1200MHz

    UHF 2.4GHz

    SHF 5.8GHz

    Findings

    • Dense materials, especially concrete, attenuates higher frequency signals more than natural materials like trees
    • Lower UHF signals perform much better than SHF with the same power
    • Higher frequencies with low power can be blocked by a single house, even after only 300m
    • HF eats bricks for breakfast!

    Summary

    Modern tactical UHF radios, and their software eco-systems, are unrecognisable from their cold-war VHF ‘voice only’ ancestors in terms of capabilities but have an Achilles heel in the form of material penetration. To get the best coverage the network density must be flexed to match the neighbourhood.

    This is obvious when comparing rolling terrain with a urban environment but the building materials and street sizes in the urban environment will make a significant difference too. Ground units which communicated effectively in a city in one country may find the same tactics and working ranges ineffective in another city with the same radios and settings. Understanding the impact of material penetration will help planning and communication.

    Posted on

    Crunch a spreadsheet on Windows

    Windows CSV

    Using the CloudRF API 2.0, you can process an entire spreadsheet of site data in one go to make a complete network coverage map. This tutorial assumes you are a Windows user with minimal programming experience. It uses the free scripts available to download as a ZIP from

    https://github.com/Cloud-RF/CloudRF-API-clients

    Power users can use the Python clients to integrate into their back-end system(s) for a light but powerful upgrade to your workflows. Trust us when we say our 32C servers are more powerful than yours!

    1. Prepare your data

    Your data needs to be in a basic comma separated CSV spreadsheet (known as MS-DOS CSV format in Microsoft Excel). The top row should be column headers defined at https://docs.cloudrf.com but can be whatever names you like so long as they map to the JSON request template.

    You can find example CSV files called ‘area.csv’ and ‘path.csv’ in the examples or download them from here:

    Sites template

    The CSV file is used for variables like location.

    https://github.com/Cloud-RF/CloudRF-API-clients/blob/master/Windows/3sites.csv

    Hardware/request template

    The JSON file used for fixed values like power. Note it has placeholders which map to variables in the CSV…

    https://github.com/Cloud-RF/CloudRF-API-clients/blob/master/Windows/drone.json

    2. Setup your configuration file

    Open a console in the ‘windows’ folder (Shift right click to open the power menu) in the folder you unzipped and run area.exe with no arguments. This will create a blank ‘cloudrf.ini’ file. Edit this file in a text editor so it contains your credentials and a destination folder for files, relative to your location:

    [user]
    key = 101-IBIZA.DEMO.KEY
    
    [api]
    strict_ssl = True
    base_url = https://api.cloudrf.com
    
    [data]
    dir = data
    
    

    3. Process your data

    Open a console in the ‘windows’ folder in the folder with the .exe files. Call the program followed by the CSV file and an output format eg. KMZ.

    area.exe -i 3sites.csv -t drone.json
    

    Or for the Path Profile API with PNG chart images…

    path.exe -i link.csv -t drone.json

    If your data is well formatted, you will see results appear in your terminal for each row. Any errors will report the offending line from the JSON which normally means a missing or misspelled column name in the CSV.

    points.exe -i route.csv -t drone.json

    Use your results

    Everything you do is stored on the server. The demo script also pulls down a KMZ file for each calculation but if you want to see your finished result, login to the web interface at https://cloudrf.com/ui and open your archive. You will find your spreadsheet has become a coverage map! You can use the data either in the web interface, download it from there as a KMZ, SHP or TIFF file. If you want to publish or share the data you can get a URL or HTML embed code to host the layer on your own website.

    Create a super layer

    You can merge all your sites into one layer for convenience with the ‘mesh’ API.

    Create a super layer by visiting this URL in any browser with your UID and network name. The layer can be named whatever you like but will belong to the ‘mesh’ network group within you archive. If you have lots of large sites this can take a minute a site so be patient and check your archive later.

    https://api.cloudrf.com/mesh?uid={your UID}&network={your network}&name={superlayer}

    Change and repeat

    Once you’ve got your result its quite common to wonder what effect a different parameter might have. To change a value for all columns, change it for the first row eg. set txw (Transmitter power in Watts) to 2 then copy that value into all the rows below. Save the CSV file and reprocess with the command as before. You will need a new network name (net) to keep your new files separate. In your web archive you can then go and select the network with the old parameters and delete it by checking the box and clicking the trash can icon.

    Alternative languages / scripts

    The simple API can be used with any other language. You can find examples of Javascript forms from the API clients downloaded in the example above and more languages over at https://api.cloudrf.com. Expert users don’t even need a desktop as you can use CURL from a shell environment:

    Posted on

    Exporting to QGIS with SHP

    Exporting your data to a GIS platform such as ESRI Arcmap or QGIS allows you to tightly integrate RF coverage layers with other business intelligence such as customer locations.
    The TIFF and SHP export formats offered by the expert plan will let you open the layers in a GIS platform. For maximum control over styling you can choose a greyscale colour key called ‘Greyscale GIS’ within the interface or API (col=9) which has a different numeric value for each dB level. This high level of granularity means you can style your shape file to the nearest dB.

    Styling CloudRF shape files in QGIS 2.18

    1. Create your coverage layer using the greyscale GIS colour schema.
    2. Download the layer as an ESRI shape file (SHP) and open in QGIS
    3. Right click the layer and open its properties, then ‘style’
    4. Change the type to ‘Graduated’ then pick a colour schema or define your own
    5. Click classify to load in the dB/dBm values. Note that a negative -60dB value will be (+)60 due to the way the levels are represented as positive grey pixel values.