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

GPU propagation engine

5G cell

We have developed a fast GPU RF propagation engine.

We’ve been busy behind the scenes designing and developing the next generation of fast radio simulation engines for urban modelling with NVIDIA CUDA technology and Graphics Processing Units (GPU).

The engine was made to meet demand across many sectors for speed and accuracy and to enable an automated best-site-analysis capability, which will accelerate planning and improve efficiency whilst keeping a human in the loop.

Designed for 5G

5G networks are much denser than legacy standards due to 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 coverage is essential for performance.

A dense network means more low power (small) cells are needed, which means more efficient planning is needed.

You can’t just place 5G cells on big hills and crank up the power like it’s the 1990s as the low power handsets would not be able to talk back to them. To achieve an economic and balanced low power urban network requires careful and thorough planning.

Core features

Our GPU engine has several modes, for different use cases. Here’s two we’re focusing on for this quarter.

LOS viewshed

Real time urban analysis

The simplest mode is a fast line of sight “2.5D” viewshed (with a path loss model) which creates a point-to-multipoint heatmap around a given site using LiDAR data. This is comparable to using the current CPU engine with LOS mode – only much quicker. This is up to 50 times faster than our multi-threaded CPU engine, SLEIPNIR.

Demo video: https://www.youtube.com/watch?v=gBrRfwcIhks

ETA: February 2022

Best site analysis

A heatmap of options..

Best Site Analysis (BSA) is a monte-carlo analysis technique across a wide area of interest to identify the best locations for a transmitter. Now we have the GPU speed, this can be done quickly with a new /bsa API call. Presently our GPU based BSA implementation can search a radius around a location, using the 2.5D viewshed technique, to grade locations. The output will identify optimal sites, and just as important, inefficient sites.

This feature will replace the “best site” tool currently in the web interface which is not GPU accelerated

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.

ETA: March 2022

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 “start” button, or even a progress bar! This speed enables API integration with autonomous drones which will need to model propagation to make better decisions, especially when they’re off the grid. It was designed around consumer grade cards like the GeForce series but will scale to enterprise Tesla grade cards due to our design.

Open API

When it goes live, it will be an option in our /area API so you can use it from any 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.

At the time of writing the API integration is undergoing bench testing (see video). This feature is scheduled for public Beta testing in February 2022.

Accessible

Using GPU cards to model Physics, including EM propagation, is an established concept dating back 20 years, despite sales-first businessmen claiming otherwise. Advances in gaming in particular have made ray tracing a mainstream term but there’s a big difference between ray tracing a visual perspective (in view) and modelling a high resolution raster or voxel map to generate a deliverable output. One is pretty and good for games, investors and technology hype-beasts and the other is actually useful for radio engineering.

What is novel here is making this exciting technology accessible to users priced out of premium tools using consumer grade GeForce cards.

Staying true to CloudRF’s accessible and affordable principles, we’ll include it in our service as an optional processing engine this year. Quite what this means for market incumbents and upstarts who currently charge SMEs a small fortune for a basic capability will be interesting. We’ll let the market answer that one.

CloudRF is a member of the free-to-join NVIDIA inception program

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

Helium LPWAN

Helium vision

Helium is a novel crowd sourced LoRa LPWAN network which uses Sub-GHz ISM bands (868MHz for EU, 915MHz for US).

The network nodes, known as ‘hotspots’, are owned and operated by individuals who are incentivised with crypto currency ($HNT). A hotspot will ‘mine’ $HNT when it can see other hotspots, known as Proof-of-coverage (POC).

Put simply, the better your coverage, the more money you make.

As a result, propagation expertise is in high demand which is where we come in 🙂

Helium has been growing for years but 2021 saw a surge in growth (see $HNT price below) which caused us to review the free plan to maintain QoS. A good problem to have all the same..

HELIUM VISION

The excitement around $HNT has been matched with a flurry of Helium hotspot businesses. The most mature of these is helium.vision (HV) owned by USMC vet and professional developer Nick Hough. We partnered with HV to add CloudRF’s API to https://app.helium.vision so HV customers could have everything in one place.

HV used the area API and LoRa templates to generate API requests from their own map. PNG images were then overlaid and stored locally. The beauty of this implementation is if a customer tries the same building, the result loads up instantly as it’s locally cached and no repeat load is sent to the CloudRF API.

Helium vision
Helium vision

We’re working with HV to add more APIs, including our new fast points API. Watch this space..