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

Connecting smart cows to moove data

Smart cow

Smart farming

Smart farming is using Internet of Things (IoT) technologies in agriculture to enable efficient use of resources.

For this blog we’re focused on cattle farming on large, fence-less farms in New Zealand. The farms in question are vast and remote so connectivity options are limited. This is why an off-grid sub-GHz LPWAN network is ideal due to its long range and the requirement to only send small, infrequent, packets of data.

For the solution to be cost-effective compared with Satellite, as little infrastructure as possible is needed which in this case is a LPWAN gateway on a pole, some collars for the herd and an app to manage the system via a web service.

Siting the LPWAN gateway(s) properly is critical to achieving not only coverage across the farm(s) but to reduce the number of gateways, which reduces complexity and cost.

Sub GHz LPWAN on the farm

An 868MHz LPWAN signal can go for many miles under the right conditions. We know this well from powering the Helium LPWAN network’s planning tool, Helium Vision, where people can communicate data 50 miles with a fraction of a watt of RF power and an omni directional antenna.

Despite it’s useful diffraction properties which enables it to work non-line-of-sight (NLOS), it’s still sensitive to obstructions so clutter on the farm such as buildings and trees needs modelling accurately. CloudRF has 10m Landcover for New Zealand from the European Space Agency and 10m DSM from the LINZ Geospatial agency.

These data sets are adequate for most outdoor scenarios but are not fine enough to model a farm complex of buildings, such as tall grain silos, metal sheds and seasonal obstacles. For high resolution you could source your own surface model, as our customer Halter did…

Farm buildings and silos

Use case: Halter

Halter are a novel agri-tech startup focused on cattle management with a unique solar powered collar.

They needed accessible RF planning software to help their engineers site LPWAN gateways. Having used and liked Cloud-RF, they needed higher resolution surface models of the farms, and no pesky API restrictions!

They also planned to build their own tools on top of our powerful physics based API which is smart as it allows their R&D team to focus on their primary product, and not waste time reinventing the wheel.

Their options were either buy expensive commercial data or self generate data using a drone and photogrammetry software such as Pix4D. Given the prohibitive cost of high resolution commercial LiDAR, it would only take a few jobs to make a return on the purchase of a decent drone!

https://halterhq.com/

Halter purchased a private Keyhole Radio server from us which included the API they needed. The server runs as virtual machine and crucially, lets them import their own terrain data.

They were quickly able to import high resolution, organic data into their server as GeoTIFF files. This allowed them to work with data which was very current, even hours old, so would be an accurate model of tree heights and man made obstructions.

The terrain format accepted by Keyhole Radio and SOOTHSAYER is GeoTIFF, Int16 resolution and WGS84 (EPSG:4326) projection.

LPWAN coverage on a farm in New Zealand

1m resolution

It wasn’t all plain sailing though, they found that there was a limit to the physical tile sizes our server could use caused by memory. The solution was to reprocess the large tile into smaller tiles to make it digestible.

A 5000 x 5000 GeoTIFF at Int16 resolution will require 50MB of disk space. If this is 5m LiDAR, the physical width is 25km x 25km. Our engine can super-sample, so if you used this tile, but requested 1m resolution, it would create a raster in memory measuring 25,000 x 25,000 pixels which would need 1.25GB of memory.

For 1m resolution however, tiles measuring 1000 x 1000px would only require 2MB of disk and memory. You may need to load in a few, lets say 16, to do your model but that’s still only 32MB.

You could also resolve this by increasing the memory available to the server but it’s recommended to prepare data into smaller parcels. We support 1m resolution in our API but don’t hold a lot of 1m data sets due to their substantial cost and size. If you already have 1m data, a Keyhole Radio or SOOTHSAYER server is the answer.

1m resolution

Summary

Cloud-RF’s powerful API is ideal for efficient smart farming.

Our private servers will let you take it to the next level with terrain data you can source yourself, no API restrictions and as a bonus, they work without an internet connection!

Finally, all our jokes are offal.

Posted on

SOOTHSAYER 1.1b released

soothsayer-1.1b-atak-route-analysis

Today we published a new release for our SOOTHSAYER self-hosted server focused on data management and stability.

It brings the VM up to date with the public service in terms of new features (Route analyis, Multipoint analysis, Mesh by visible, 3D fresnel) and fixes multiple user/data management issues identified through recent testing.

Thank you testers!!!

Software versions in October 2021 release

You can verify your versions from your administration dashboard.

keyholeradio: 1.1b
documentation: 1.4
chatbot: 2.2
sleipnir: 1.4.4
API: 2.3
ui: 2.2

Get the remote update

Login to the console with the account from your administration guide and type the command keyholeradio-update

Download the image

If you want to download a new VMware image contact support from your work email for the 9GB download link. You will need a SOOTHSAYER or KEYHOLE RADIO license to enable the software.

Evaluation licenses are available on request…

route-analysis
route-analysis
3D fresnel zone

SOOTHSAYER changelog

[1.1b 27/10/2021]
Added route analysis in UI
Added merge-by-visible in UI
Added multipoint analysis in UI
Added 3D fresnel zone in UI
Added database reset warning and confirmation
Added authorisation option for external 3D buildings source
Added Admin can change dashboard password
Added support for 1m LiDAR

Fixed legacy opacity tag removed from KML
Fixed remote tile server with global coverage via us.cloudrf.com
Fixed database backup to host / outside VM
Fixed mesh radiocheck to limit parallelism on smaller machines
Fixed SOOTHSAYER bot location to middle of area of operations 
Fixed local map tiles so they no longer create bogus messages when clicked
Fixed custom WMS urls so they can now contain hyphens
Fixed API keys updated in admin dashboard to APIv2 convention
Fixed logging standardised for all services
Fixed even spacing for points along freehand routes & polylines
Fixed database reset now instant when requested
Fixed database integrity & permissions check with auto-repair 
Fixed TAK route analysis as a KMZ data package instead of CoT

[1.0.4b 14/10/2021]
Added clear warning dialog to database reset
Changed database reset to table truncate instead of full factory reset which is in manage_db
manage_db utility now exports to shared data folder for backups
Fixed bug in factory reset which stopped a clean db install
Fixed issue in users table editor where password asterisks were hidden
Fixed issue in users table editor where updated column was not tracking edit times
Fixed issue in users table editor where ATAK UID could not be reset. Can now use #
Factory database reset no longer requires a restart

[1.0.3b]

Added checks during startup and update to ensure 'data' directory is writable.
Added keyholeradio version to admin dashboard.
Added changelog.txt and relevant permission settings during startup.

Fixed issue where banner displayed incorrect WMS URL.
Fixed issue where a user's 'atakuid' failed to update when done manually.
Fixed issue where bot would fail to auth due to NULL value in 'atakuid'.
Fixed issue where no users existed if additionally seats added. New users created upon loading of admin dashboard.