Posted on

Field testing diffraction

Spectrum analyser up mountain

Recently, we added advanced diffraction models to CloudRF to complement our existing models. To validate the performance of the new Bullington and Deygout models, we took a field trip to the Highlands of Scotland to collect UHF measurements over rugged mountain terrain and through forests.

With these measurements we have validated and optimised our new models for this environment. We already had single-knife-edge diffraction, based on Huygen’s formula, and the Irregular Terrain Model (ITM) which uses Vogler diffraction. The Vogler model is known to be good but single knife edge has its limits which we have pushed.

Summary

The testing validated our investment into the complex multi-obstacle models we have added.

Both new models offer a significant improvement in accuracy, with no loss in performance for Bullington. We were able to model diffraction with higher accuracy over multiple challenging obstacles such as gradual convex slopes, ridges and valleys. Modifications have been made to the CPU and GPU engines which will be updated on CloudRF and SOOTHSAYER in due course.

Our key findings include:

  • Single-knife-edge was optimistic
  • Deygout was the most accurate, but slower
  • Bullington provided the best overall performance
  • 7.6dB accuracy achieved, including receiver error
  • 2.4dB improvement on single knife edge model

Test environment

We selected a famously cold and remote valley in the Cairngorms national park for our test which has cell towers in the valley and a variety of local repeaters for TETRA, VHF and UHF PTT services. The challenging terrain is notoriously difficult for radio communications making it ideal for our purposes.

Using a test phone with 3dB of measurement error attached to the Vodafone 4G network and a portable Rohde and Schwarz spectrum analyser, we collected a variety of VHF and UHF measurements along a 22km circular mountain route covering a wide variety of terrain. From the data collected, the 800MHz LTE measurements proved the best examples of signal failure so we focused our post-analysis on these.

Throughout the LTE testing the phone attached to multiple local cells and experienced prolonged signal failure as expected in a remote mountain valley.

We filtered the results to isolate 634 RSRP readings from a single physical LTE cell, PCI 460, from which we would calibrate modelling. This cell was located at the start of our test route and was a high power LTE band 20 (800MHz) base station with 10MHz of bandwidth.

Trees and attenuation

The first, and last, few miles of the circular route was a mature Scots pine forest. Unlike dense Scandinavian pine forests, this was sparse with a relatively high tree canopy. A lighter tree clutter profile was used to represent the attenuation from these trees which impact UHF propagation.

Convex hill and a loss of signal

Beyond the forest, the route gained altitude into a mountain plateau where line of sight was lost. The shape of the hill meant any diffraction formula would have to model a gradual convex shape versus a simpler knife-edge obstacle.

The ascent and re-acquisition

As the route ascended a spur leading toward the ridge, the signal was reacquired beyond the snowline. This signal gain was gradual, starting as a diffracted signal from the lower convex hill which eventually became a direct signal at the summit, 7km away from the cell.

Summit switcheroo

The route traversed a high ridge which featured many gaps in our cell coverage in the test data. These gaps were because the LTE modem performed a handover to stronger cells which appeared as soon as they were “visible”. Depending upon the position along the ridge, it occasionally reverted to the original “460” cell at over 7km.

Descent into darkness

The steep descent from the ridge entered a obscured valley not visible from the cell.

This resulted in a prolonged loss of signal for several miles until the signal was reacquired toward the trees at the foot of the valley.

Results analysis

The LTE survey data was prepared as CSV and loaded into the CloudRF web interface for use with the coverage analysis tool. This provided live feedback on accuracy with user generated heatmap layers so the correct settings could be identified first visually using a fine colour schema and then numerically by the reported average error in decibels.

Whilst the site location and frequency was known, the power output was not so the first task was to match line of sight positions, such as on the ridge-line, to establish the power without any obstacles. From there, a tree clutter profile was created to match the tree measurements and finally the best model and context were selected. For this task, the generic Egli VHF/UHF model was chosen as a basic model on which to base the diffraction comparison.

As settings matured, the reported Root Mean Square (RMS) error reduced accordingly until it was below 8dB (including 3dB of receiver error). This was slightly better than the 8dB we achieved on our last field test with LTE800 previously and given the extreme context, spanning a diverse mountain range, this was an excellent improvement.

Subtracting receiver error gives modelling error in the range of 4.6 to 7dB; an excellent result for difficult terrain.

Diffraction modelMean error dBRMSE error dBModelling error dBComment
Single knife edge5.2107Optimistic. May show false positive coverage.
Deygout-1.77.64.6Good. Can be conservative and is 50% slower but gives high assurance.
Bullington1.48.95.9Good. Can be optimistic but is as fast as KED and relatively accurate.
Calibration results from comparing area coverage with survey data

Coverage results

The scatter plot for the ascent to the ridgeline shows measured and simulated values. The steep drop at 2.5km and gap in results after 3.3km matches closely for the critical beyond line of sight region. The results start again once we ascended toward the ridge where the new models were conservative by 10dB whilst the simple knife edge model tracked the path loss curve – which was to be expected. All models aligned once line of sight was achieved at 6.3km.

Recommendations

The outcome of this testing has improved the accuracy of our diffraction models, identified optimisations for our clutter profiles and proved a simple path loss model can be very accurate beyond line of sight with the right diffraction model.

The API settings we used for the LTE800 cell and RSRP output are here. Note the custom clutter profile and fine colour schema.

{
    "version": "CloudRF-API-v3.9.5",
    "reference": "https://cloudrf.com/documentation/developer/swagger-ui/",
    "template": {
        "name": "Lochnagar LTE800",
        "service": "CloudRF https://api.cloudrf.com",
        "created_at": "2024-01-16T13:15:02+00:00",
        "owner": 1,
        "bom_value": 0
    },
    "site": "Site",
    "network": "LOGNAGAR",
    "engine": 2,
    "coordinates": 1,
    "transmitter": {
        "lat": 57.003155,
        "lon": -3.327424,
        "alt": 15,
        "frq": 806,
        "txw": 15,
        "bwi": 10,
        "powerUnit": "W"
    },
    "receiver": {
        "lat": 0,
        "lon": 0,
        "alt": 2,
        "rxg": 0,
        "rxs": -129
    },
    "antenna": {
        "mode": "custom",
        "txg": 19,
        "txl": 0,
        "ant": 0,
        "azi": 180,
        "tlt": 0,
        "hbw": 120,
        "vbw": 20,
        "fbr": 19,
        "pol": "v"
    },
    "model": {
        "pm": 11,
        "pe": 2,
        "ked": 2,
        "rel": 60
    },
    "environment": {
        "obstacles": 0,
        "buildings": 0,
        "landcover": 1,
        "clt": "SCOT4.clt"
    },
    "output": {
        "units": "m",
        "col": "PLASMA130.dBm",
        "out": 6,
        "ber": 0,
        "mod": 0,
        "nf": -120,
        "res": 10,
        "rad": 8
    }
}

Disclaimer

Climbing mountains in winter to test radio networks is dangerous, hard work which requires fitness, experience, skill and dedication to RF engineering. Only do this if you are serious about improving accuracy!

Posted on

HF Near Vertical Incidence Skywave (NVIS)

HF NVIS coverage

Today we launched a new model for ionospheric communication planning with High Frequency Near Vertical Incidence Skywave (NVIS).

It’s available in the interface and directly via the area, path, points or multisite API calls. The powerful GPU accelerated capability offers a modern way of visualising and teaching NVIS propagation. It does not, in it’s present form, do frequency selection so this must be performed prior to using this tool to visualise the coverage.

Background

This form of basic ionospheric propagation is popular with Military, Maritime and rural customers. With a simple horizontally polarised antenna and the right frequency, an operator can establish a link of up to 500km making this a quick and economical method for communicating long distances.

HF is undergoing a renaissance driven by uncertainty of the availability of space systems and the need for secondary communications in emergency PACE planning. Despite the choice available now with consumer grade space based communications, HF is a low cost method which requires no third parties making it immune to business and geo-political changes.

As HF bandwidth is very limited, historically only CW and voice channels were viable although developments in compression, cognitive radio and now MIMO are changing this. Improvements in software especially mean that reliable data channels with improved throughput are possible which makes HF data links a popular low cost, low bandwidth, alternative to satellite communications.

Ionospheric propagation

The ionosphere describes layers of ionised gas between earth and space which vary in height between around 100 and 300km. These layers reflect (HF) radio waves and attenuate others. As the layers are stimulated by sunlight, propagation changes significantly between day and night. Seasons affect propagation also, so a frequency which is good in the day may become unworkable after sunset.

The D Layer is the lowest layer at around 100km and absorbs low frequencies (2-4MHz). This weakens at night so these frequencies become viable. This determines the Lowest Usable Frequency (LUF).

The F layer is the highest layer at around 300km and reflects higher frequencies between 4 and 8MHz. The critical frequency is the Maximum Usable Frequency (MUF) which changes throughout the day, determined by sunlight.

A useful analogy for considering the change in the layers is a car engine; It warms up quickly in the morning and cools gradually at the end of a day driving. HF layers change quickly at dawn and slowly after sunset.

Higher frequencies beyond 8MHz experience less refraction so pass through the layers out into space. Depending on conditions a higher frequency may be possible but the most reliable (for NVIS) are found between 2 and 8MHz.

Using the NVIS model

The HF NVIS model can be selected in the model menu or in the API as code 12. Like other models it has a configurable reliability (aka fade margin) and a “context”. The context here refers to the refraction altitude and not an environmental eg. urban/rural choice with other terrestrial models.

  • Context 1 is the D layer at 100km – (Day)
  • Context 2 is the E layer at 200km
  • Context 3 is the F layer at 300km – (Night)

In the day you should use the D layer and your frequency should be between 4 and 8 MHz.

At night, you will use the F layer and need a lower frequency between 2 and 4MHz.

This HF model is only for use with a pre-determined frequency. It does not do forecasting or LUF/MUF frequency selection. This functionality will follow.

The reliability option provides a 10dB fade margin to tune modelling to match the real world. This was set with 50% reliability aligning to summer predictions with a 5MHz frequency.

HF dipole antenna

The antenna pattern will be a special horizontal dipole. You may set the gain and azimuth only but cannot change the pattern as it has high angle nulls for the skip distance before the reflection hits the earth. This will manifest itself as a cold zone at either end of the dipole where the pattern gain is lowest.

This animation shows a dipole orientated north west. The angle of orientation is measured perpendicular (at a right angle) to the wire so the tips of the antenna will generate the worst coverage, in this case to the north east and south west.

HF coverage animation

Radius and resolution

The recommended resolution for NVIS is 180m due to the immense size of the problem. Land cover is irrelevant with this mode of propagation. The radius has been limited to 500km in line with API limits. You can go further with NVIS but would run a risk of straying into multi-hop HF Skywave and this capability is focused on one hop only.

Most NVIS communication takes place between 50 and 300km where groundwave ends and the signal fades into the noise floor.

Using the GPU engine we can model a 500km radius with NVIS and terrain in under 3s. Terrain is a small concern to NVIS unless it’s a large mountain several hundred km away. In this case you will experience shadows due to to low angle of incidence but compared with shadows from terrestrial communications, it will be small.

Environment layers such as land cover and buildings should be off. They will be ignored at 180m resolution.

The colour schema can be whatever you like but if you want to align with the ‘S’ meter scale, popular with HF, where a barely workable signal is S1 and the best is S9 (-73dBm) use a max value of -73dBm with 6dB bands for S9 to S1.

Accuracy verification

We have calibrated our NVIS model to align within 10dB of measurements taken from a 2012 research paper by Marcus Walden using a 5MHz NATO frequency in the UK. From this paper we selected one of the longer links at 210km where we used the median measurement value which for August 2009 was lower during the day than VOACAP, a popular open source application for HF forecasting. The median dBW measurement at noon was -120dBW (-90dBm).

Noting that the RMS error between the VOACAP predictions and the measured values was concluded to be 7 to 12dB at 12 noon (Ref table 7 on page 8), and more at night, we have tuned our model so an “optimistic” prediction is 3dB from the noon measurement. The context and reliability options provide sufficient control to allow predictions to align with current and local ionospheric conditions.

The screenshot below shows both the path and the area coverage aligning with a 1dB calibration schema. The link has over 900m of curvature height gain which explains why a flat region of England appears as a mountain!

HF NVIS calibration
HF NVIS calibration to 3dB

Ionospheric modelling is less predictable than terrestrial modelling due to unpredictable solar radiation. Predictions generated with this model are useful for training, situational awareness and antenna alignment but cannot provide an accuracy greater than 10dB, assuming the inputs are correct.

Look forward: Space weather and long range HF

HF forecasting tools use lookup tables to set refractivity during both seasons and times of day. Using quality, and current data, improves accuracy but like weather forecasting it cannot offer accurate predictions without live data, in this case space weather which has seen a lot of renewed research recently. Our implementation does not use forecasting data presently so users should not be using it to pick their frequencies, but it will help visualise the coverage and align antennas – which at 500km is important.

For the next phase of HF, long range skywave, we will use a space weather feed to offer high resolution HF predictions. Long range HF uses multiple hops at lower angles so the space weather and time of day must be considered along the route which may be thousands of kilometers….

Posted on

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

Critical Coronation private 5G network planned with CloudRF

On Saturday 6th May the worlds media descended on London for the Coronation of King Charles, an event last planned before many people had television.

As the national broadcaster, the BBC managed the coverage and worked with Neutral Wireless to deploy an innovative private 5G network, with dedicated spectrum, along the procession route for exclusive use by the media and special cameras with 5G modems.

Using the CloudRF API with UK LiDAR data the team created accurate urban line of sight models for their N77 base stations along the tree lined route. Their model used RSRP units and a custom colour schema to map the 4GHz downlink coverage and key handover regions to ensure smooth subscriber transitions for the dynamic event. 

Antenna patterns

The area to be covered is a linear tree lined boulevard known as “The Mall” which leads to one of the most iconic buildings in the country, Buckingham palace. For this task, high performance Alpha Wireless directional panels were employed above the crowds at only 4m, much lower than a conventional city cellular network where a mast will be on rooftops. The combination of low height and a 4GHz frequency limits the effective range so the direction of the antennas needed to be carefully optimised to provide maximum coverage for broadcasters, strategically positioned along the route for line of sight.

How do you model a parade of horses?

Given the low height of the masts and the significant number of tall horses on parade this presents a challenge to critical line of sight which a LiDAR vendor cannot help with. The same problem applies to temporary structures such as the grandstand erected outside the Palace.

For a challenge such as this we can use custom clutter to simulate a parade of horses at a uniform distribution with a nominal density value. A “brick” clutter type can be customised to 2m height and 0.4dB/m attenuation to simulate loss through the parade to show the low and high risk locations for maintaining a link through the parade.

Our current 2D engine regards all obstacles as extending to the ground so a clutter model for a horse will be conservative since in reality a horse has a substantial gap between its legs sufficient for some RF to travel between it and reflect, and diffuse, off the rough ground to reach a camera beyond it. We’re already working on 3D 😉

In the screenshot below, the formation nearest the mast present no challenge, the formation in the middle show attenuation throughout them making a link difficult potentially depending upon siting of the receiver and the distant formation is blocking the, already attenuated, signal.

Trees

The parade was held in May when the trees along the Mall are coming into leaf presenting a moderate obstacle to the 4GHz frequencies. The temporary masts were therefore erected forward of the trees for optimal coverage but still technically under the canopy which makes planning challenging with a 2D engine since these trees can exist as spikes in the LiDAR profile. To avoid accidentally siting a mast atop a tree/spike in the model the path profile tool can be used to inspect the path profile, to identify where there are tall trees in the underlying surface model. Using the UK Environment Agency LiDAR from 2019, the nearest trees on the Mall are lightly represented in LiDAR with a 6m to 8m average canopy compared to their significant neighbours one row back and beyond in St James Park.

The result

The high resolution coverage map was integrated with official event mapping, printed, and displayed in the event broadcasting operations room as a reference. You can also see it on the BBC.

Despite the challenges expected from such congested spectrum, dynamic obstructions and the unexpected surprise of unscheduled electronic counter measures they were able to deliver accurate coverage, on time and within budget to broadcast a historic event in high definition, in real time.

Victoria Memorial

Posted on

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.

FFT

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

Calibrating beyond line of sight RF modelling with field testing

Summary

We field tested our software to improve it for beyond line of sight planning. From analysis of data we have improved diffraction accuracy, clutter profiles and crucially have proven that high resolution LiDAR is not the best choice for beyond line of sight or sub GHz modelling. An RMSE modelling error of 5.2dB was achieved as a result.

Modelling can only be as accurate as the inputs.

Given accurate reference data and accurate RF parameters it can be very accurate but achieving both conditions requires careful and delicate calibration of dozens of variables. Thankfully this time intensive process is only necessary when changing hardware which for most organisations is a cycle measured in years.

The reference data used could be a digital terrain model like SRTM, a digital surface model like ALOS30, high fidelity LiDAR or landcover like ESA Worldcover. As we demonstrate, high resolution does not always translate to high accuracy in beyond line of sight RF.

Calibrating modelling with LiDAR data to match field measurements

LiDAR is great, but it’s not a silver bullet

You can have the most expensive 50cm LiDAR money can buy and still not achieve real world accuracy or a notable gain over 1m or 2m data (unless you’re planning for a model village). LiDAR on its own cannot model beyond line of sight, essential for sub GHz planning, which is a risk we’ll explore when planning tool design is focused on sales and marketing, not actual RF Engineering.

Controversially, you can get better BLOS modelling accuracy with basic terrain data enhanced with calibrated clutter profiles which we’ll demonstrate below.

The best data to use depends on the technology and requirements. LiDAR is unbeatable for line of sight planning, but won’t help you in the woods, or beyond line of sight without a proper physics propagation engine.

Unless your network is composed of static masts eg. Fixed wireless access (FWA), then chances are you are working non line of sight between radios so LiDAR should be used carefully.

Public 1m LiDAR data showing cars, trees and houses

“Line of sight” field testing Feb 2022

Last year we field tested LTE 800MHz in the Peak district and achieved excellent calibration figures for distant hilltop towers looking onto open moorland. This was predictable given the legacy cellular models we used were developed from similar measurements. As the blog described, the harder calibration was inside a wood where the LiDAR data proved unsuitable. Due to the simplistic nature of first return LiDAR, a tree canopy appears as a solid immutable obstacle. You can model the RF as it hits the tree canopy but not where it matters, on the ground inside the trees. This key finding accelerated and matured our developments with tooling to support calibration with survey data in CSV format and user configurable environment profiles.

CSV import utility – developed for analysing field test data
Clutter manager

“Non Line of sight” field testing, Feb 2023

This year we field tested LTE 800MHz again but this time in a old Gloucestershire village, Frampton on Severn, where the tower was deliberately obstructed and the solid stone buildings in the village meant we were measuring diffraction, coming from rooftops of single, double and triple storey buildings. The test data was collected from 2 handheld LTE test devices using a combination of Network Signal Guru (NSG) and CellMapper for Android. This app reports signal values and logs cell metadata with locations to a CSV file which we can analyse.

Some variables were unknown such as RF power, which required us to take measurements on the green in full line of sight. These “power readings” allowed us to reverse engineer the cell power as approximately 40dBm (10W) which would be appropriate for a cell serving a village.

Frampton on Severn. The cell tower is to the far right behind the pub.

Received Signal Received Power (RSRP)

The measured power value is Received Signal Received Power (RSRP) which is a LTE dBm value determined by the bandwidth, in this case 10MHz like most LTE Band 20 signals in Europe.

RSRP is lower than the carrier signal (Received Power) which is agnostic to bandwidth, but also measured in dBm.

Be careful not to confuse the two units of measurement as they can vary by more than 27dB!! A carrier signal of -80dBm might have a RSRP of -108dBm or lower depending on bandwidth. RSRP is usable down to -120dBm.

Received power dBmBandwidth MHzRSRP dBm
-7010-97.8
-8010-107.8
-9010-117.8
Relationship between power, bandwidth and RSRP at 10MHz

Diffraction

Diffraction is the effect that occurs when radiation hits an edge like a rooftop or a hilltop. The wavefront radiates from that edge with resulting power determined by several factors like height and wavelength. Much like a game of pool, the angle of incidence determines the angle of reflection so a tall building will cast a long RF shadow before the diffracted signal is available again beyond the shadow. A proper diffraction shadow has soft edges as the RF scatters in all directions. LiDAR data creates sharp shadows, even when trees have no leaves.

The CloudRF service has two diffraction capable CPU and GPU engines which use a proprietary algorithm based upon Huygen’s formula which considers obstacle dimensions and wavelength.

Exaggerated diffraction caused by solid LiDAR

Which propagation model is best for 800MHz?

Most propagation model curves follow similar trajectories but differ by only a modest amount of dB in relation to the impact of an obstacle. The choice of model is therefore less important, in our experience, than getting the obstacle data right so for a cellular base station, you could choose to calibrate against any empirical or deterministic model which supports that frequency. Each model has a reliability margin to help align and tune it. For UHF the advanced (and default) ITM model is preferable as it was designed for NLOS broadcasting with complex diffraction routines. For this test we picked the simpler Egli VHF/UHF model with basic knife edge diffraction since this features in both our CPU and GPU engines, and we want to calibrate both.

Path loss curves for propagation models

What is “accurate”?

The cellular modem used to record power levels has a measurement error of -/+ 3dB so any reading cannot be more accurate than this. Therefore, if calibration of field measurements returns a Root Mean Square (RMSE) value of 8dB, this can be considered to be composed of measurement error and (5dB of) modelling error.

For Line of sight, a modelling error level of < 10dB is ok, < 5dB is good, and < 3dB is excellent. This is the easy part which for some basic tools is enough.

Line of Sight coverage: Good for above UHF only

For non line of sight (which covers much more complex scenarios), the error doubles so an error level of < 20dB is ok, < 10dB is good and < 6dB is excellent.

For our field testing, we achieved a non line of sight calibration with 5.2dB of modelling error which we were content with. We are confident we can improve upon this with richer clutter data which we are developing presently.

Results

1m LiDAR – It isn’t as useful as it looks

Using 1m LiDAR for the village we generated a sharp heatmap sensitive to chimney stacks and even parked vehicles which made for a very crisp result visually but the first-pass correlation with the field measurements showed it was conservative, which arguably is a safe default if you’re unsure.

The reason was a combination of trees and buildings. The village had trees on the green but due to the season, none were in leaf so signals would travel through them with relatively reduced attenuation. The LiDAR data however, regards a tree as a solid obstacle so results in an overly conservative prediction for measurements beyond the trees. Attenuation through buildings is a weakness of LiDAR in 2.5D RF modelling using this raster data.

You can show RF on the roof and if diffraction is calibrated, beyond the diffraction shadow as the signal hits the ground but not within the shadow itself where through-building signals reside.

LiDAR calibration showing a mean error of -1dB and a total RMSE error of 10dB.

The LiDAR result was improved with positive adjustments to the diffraction routine in SLEIPNIR, our CPU engine. As a result, diffraction is slightly more optimistic and the correlation with field measurements was improved.

The best LiDAR score, subtracting 3dB of receiver error was a modelling RMSE of 7.28dB.

DTM and Landcover – Better than LiDAR?

Using 30m DTM with layered 10m Landcover and 2m buildings, sampled at 5m resolution, higher calibration was achieved despite the loss of resolution. The reason is the Landcover offers through-material attenuation which can be adjusted to match field measurements. In this case, the “trees” and “urban” height and attenuation values were manipulated until coverage matched the results with high accuracy.

The best Landcover score, subtracting 3dB of receiver error was a modelling RMSE of 5.22dB.

Landcover calibration produced a better result – without breaking the bank

A / B comparison – LiDAR and Landcover

Using our calibrated settings, we extrapolated coverage out to 3km radius to model the whole cell. Here you can clearly see differences in coverage between the two data sets. With LiDAR, coverage is bouncing off hard tree canopies and casting sharp shadows on obstacles like hedgerows. With Landcover, we still have diffraction but more attenuation from obstacles which creates major nulls and also softer diffraction shadows, set by our clutter profile.

A look forward

Findings from this field testing will be worked back into the CloudRF service in coming days, followed by SOOTHSAYER in due course, as new releases for our SLEIPNIR CPU engine, GPU engine and better default clutter values. We are developing sharper, and economically viable, global clutter data to improve on these scores, but won’t say how just yet 😉

Posted on

Multisite API

Multisite network

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.

A link between two very different sites

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.

MANET tool options

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.

You know it’s coming…

Posted on

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

Bandwidth and noise

As communications systems have grown in capacity, they have expanded in physical bandwidth in an increasingly congested RF spectrum.

Effective digital communications planning requires more than knowledge of antennas and propagation fundamentals. It now needs an intimate understanding of bandwidth and noise to co-exist and communicate efficiently.

Unfortunately, this key aspect of modern RF systems is often taught badly, or in some cases not at all, leading to often unwelcome surprises for equipment operators in the field. As a technology and market agnostic platform we’ve observed poor bandwidth knowledge in many markets, but notably MANET and 5G, both of which are accelerating the deployment of wideband systems, often with little to no planning beyond a topographic map study.

Both radio markets are evolving from narrower channel technologies, which in the case of MANET and the VHF Combat-Net-Radio (CNR) it replaces was measured in KHz so they need to update their theory training content and associated software to convey these potentially complex topics to novice students in a digestible manner.

Increasing bandwidth increases noise, which reduces coverage

Teaching noise

As bandwidth increases, so does channel noise. This simple concept might seem easy to remember for a student but without visual aides, and since the demise of analog systems; audible aides, it is hard to demonstrate in practice.

A good teacher may show visual aides like noise charts, FFTs, spectograms and a bad one may show some Johnson-Nyquist formulas buried within an all-day powerpoint which is not helpful except for getting paid.

FFT showing a narrow signal and wideband interference

A student can tick the right box on their exam(s) but spend their career wasting bandwidth and struggling to establish communications because they believe that big is better – it isn’t, or worse still, that bandwidth has no effect on the coverage since that’s a function of transmitted power and/or height. Having an intimate understanding of the interplay between bandwidth, receiver sensitivity and thermal noise will make spectrum users more efficient, effective and considerate.

Bandwidth MHzThermal noise (dBm)
0.1-124
1-114
2-111
4-108
8-105
16-102
32-99
64-96
Bandwidth thermal noise table based on a temperature of 21C

Which waveform is best?

Comparing digital radios is complicated due to the myriad of features, waveforms and software.

Given a particular waveform it will have characteristics such as a minimum Signal-to-Noise Ratio (SNR) value which it requires to achieve a symbol rate necessary to deliver a fast data link for example. This dB value must sit proud of the noise floor so if the noise floor is high at -90dBm, coverage will be reduced and conversely, by taking it to somewhere quiet eg. -110dBm, the coverage will improve by 20 decibels – a huge difference.

To compare waveforms precisely, the same noise floor should be simulated, initially, with fixed values to eliminate random error in field testing. The sensitivity values will be somewhere between 3 and 20dB depending on what the waveform and target Bit-Error-Rate (BER) is.

Bit Error Rate (BER) describes the ratio of errors in a data stream. An ok value is 10-3 or 1 bad bit in a 1000 or 0.1%. This increases with noise until a signal is unrecoverable. For more on BER see an older blog here.

For ground radios designed for noisy environments, a BER of 10-2 (1 error in 100 or 1%) is used here for extracting our planning thresholds from a chart of SNR curves. For an airborne system without obstacles this could be higher, for example 10-5.

Signal to Noise Ratio for different modulation schemas against error rates.

A narrow waveform eg. QPSK gives better coverage and works better in noisy conditions. This is the fallback telemetry mode used in many data radios.

A wide waveform eg. QAM64 is capable of better throughput and delivering high bandwidth streams such as HD video.

The best radio is one which can use different waveforms to satisfy both coverage and capacity.

Modelling bandwidth: A tutorial

Modelling RF Bandwidth and noise

Quick reference guide

A quick reference guide for using bandwidth and noise is available here. For other guides see here.

Conclusion

Bandwidth and noise is essential knowledge for anyone deploying wideband systems or comparing waveforms.

RF theory training can be enhanced (and needs to be) with visual tooling to let students quickly observe the impact of different inputs in a controlled environment with templates to minimise user error.

For information on how SOOTHSAYER can help with signals training see here.

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.