Broadcasting Archives

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

Interference analysis

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

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

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

Enhanced Interference API

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

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

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

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

Presenting interference

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

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

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

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

Demo: Signal jammer (Frequency)

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

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

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

Demo: FM broadcasting (Power)

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

Demo: Microwave link (Bandwidth)

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

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

API demo

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

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

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

Documentation

API reference

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

User documentation

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

Complete Code example

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

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

Planning for noise

The trouble with radio planning software

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

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

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

Spectrum sensing radios

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

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

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

Interference: a growing issue

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

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

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

A solution: The noise API

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

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

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

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

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

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

Demo 1: Motorsport radio network on race day

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

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

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

A look forward to cognitive networks

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

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

References

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

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

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

Posted on 2023-05-082024-04-16 by CloudRF

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.

CloudRF referenced in award winning technical paper

The BBC research and development team published an award winning paper at the 2023 International Broadcasting Convention about the event titled 5G Standalone Non-Public Networks: Modernising wireless production.

In this paper, the 4GHz coverage accuracy was validated using ground truth data. This quote about CloudRF’s accuracy stands out:

The agreement between the predictions and on-the-ground measurements is excellent
BBC Research and Development

You can download the paper at the BBC here.

Posted on 2021-11-122021-11-12 by CloudRF

Enhancing accuracy with environment profiles

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

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

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

Clutter data

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

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

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

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

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

Read more about the codes in the documentation here.

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

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

Custom clutter enrichment

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

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

Demo 1 – The Jungle

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

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

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

Demo 2 – A region without LiDAR

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

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

Demo 3 – A region with 2m LiDAR

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

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

Inspecting a profile

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

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

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

Using and editing a profile

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

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

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

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

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

Using clutter from the API

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

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

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

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

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

What’s next?

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

Posted on 2020-04-172021-05-22 by CloudRF

Keeping motorsport smooth

A motorsport customer invited us to a track day to observe a peculiar RF problem… High resolution ‘dashcam’ video feeds have become standard in motorsport with multiple cameras present on vehicles and drivers. Unlike a consumer dashcam, these real-time video feeds use TV broadcasting radio links to relay a signal from the vehicle to the video processing facility via track-side receivers. The problem is Motorbikes with video feeds were experiencing RF difficulty on bends despite being close to high gain receiving antennas. This issue was investigated with the CloudRF API which revealed the following findings:

Lean angle has a direct impact on signal quality

Adjacent riders will attenuate signals

A bike at full tilt will experience antenna polarisation loss

Mast heights must be wavelength x (distance/4) to compensate for dynamic losses

Low masts, like tight boots, are terrible!

Doppler shift

The system must contend with several challenges; firstly the doppler effect caused by a shifting emitter. This effect is negligible at slower speeds but can cause reception issues as the vehicle increases speed and the frequency appears off tune. A superbike moving at 100mph would result in as much as a 5% shift in frequency which depending on the location of the receiver could be an increase or decrease of 1MHz. The effect can be modelled and managed with frequency tracking receivers designed to overcome this high speed issue.

Lightweight RF links

Weight is critical in maintaining a competitive edge so the RF links employed are low power emitters, using the vehicle’s native electrics. Licensing restrictions also limit the maximum allowed power output. The standard used in this case is ISDB-T which is an MPEG-4 H-264 high definition video stream which at full rate employs QAM-64 modulation. The H-264 quality High Definition (HD) video feeds people are accustomed to require a high signal-to-noise ratio of at least 20dB which is achieved by careful deployment of track-side high gain antennas and dedicated broadcasting spectrum at 2.3GHz. The system uses 7MHz of bandwidth (broken down into sub-carriers) which has an absolute noise floor of -105dBm. Adding the necessary 20dB SNR gives -85dBm which with the addition of 10dB of environmental (7dB) and receiver (3dB) noise gives a target threshold of -75dBm.

The antenna on the motorbike is a shark fin, vertically polarised design mounted on the tail of the bike behind the rider. For the purposes of this investigation the antenna has been modeled with 1dBi gain and and an ERP of 18dBm / 65mW, equivalent to just under a consumer WiFi router. The video broadcast unit is concealed nearby within the bike’s tail with minimal cabling between the antenna for tidiness and maximum efficiency. The track-side antennas would be directional antennas with at least 10dBi of forward gain. These would be positioned at key points on the race track for maximum benefit. The siting of these antennas is where CloudRF is used to test options.

Bends

Using GPS data from races, it was found that there could easily be 8 motorbikes in a tight group on a bend. As the bikes all take the bend, several changes occur which all impair RF propagation, resulting in disruption to the smooth HD feed:

1. Rider attenuation

A significant change to consider is the increase in environmental attenuation caused by the crowd of riders. At 2.3GHz the human body will absorb 3dB of RF power. Assuming there are 3 bikes between the rider and the receiver this could be a substantial +9dB of attenuation – comparable to a brick wall (7dB) at this wavelength.

2. Antenna tilt

As bikes lean on a bend so do their vertically polarised antennas. As an antenna deviates from its optimal polarity (vertical) to horizontal it loses power up to 3dB at full tilt (90 degrees). If a bike is at half tilt, polarisation loss will cost the RF link 1.5dB.

3. Antenna height

Coupled with tilt, the height of the antenna above the earth will reduce from ~100cm to as little as ~50cm. This will reduce its effectiveness as more of the key fresnel zone will be attenuated by the earth. Using a fresnel zone calculator the fresnel zone radius for a 2.3GHz link over 300m is 3 metres. Elevating the track side antennas on masts is one way to overcome this issue but when one end of the link is so near the earth the (tower) elevation must be much higher than the fresnel radius if it is to clear the earth completely as these profile images demonstrate. Modelling using the Irregular terrain model which considers fresnel attenuation shows substantial loss caused by minor reductions in the (bike) antenna height. As you can see in the path profile below, the curved fresnel zone clips the earth which introduces attenuation.

Modelling the problem with the CloudRF API

The customer wondered if the issue might be identified through Monte-Carlo simulations whereby random inputs, in this case bikes, were placed on the track and the coverage mapped for comparison. This type of simulation is possible through the coverage API with custom client scripts and can help identify where to site receive antennas around a given track. After much deliberation it was realised that the benefit of area modelling would be limited in contrast to focusing on the impact of a bend on a single bike which could be adjusted for different lean angles and simulated crowds. For this study the Path Profile (PtP) API was used to focus on a short 300m straight line path between a bike and a mast, with variation to the inputs. The bike’s height was adjusted to simulate lean based upon a starting height of 100cm (Superbike tail height average) down to a minimum of 50cm when at full tilt. The impact of adjacent riders was simulated by adjusting the receiver gain downwards, in this case by 9dB to simulate 3 other riders. The significance of receiver height was demonstrated by adjusting the mast to clear the fresnel zone at this distance.

Results

The following data was generated using the ITM model with transmission heights ranging from 1m (Bike is upright) to 50cm (full lean). The ITM model considers the effect of the obstruction of the fresnel zone which is the cone of power around the path of a signal. Measurements are based upon a mast 300m away, on flat earth, with a 9dBi sectorial panel antenna. The zone grows deeper as it travels so mast height must consider this as well as line of sight clearance.

3m mast

A 3m mast is higher than most vehicles and ground clutter but only for line of sight. At 300m the fresnel zone is 3.12m so this mast height is only high enough up to about 250m before power is lost as the fresnel zone is attenuated by the earth. Results show that without obstructions 3m is borderline as bikes lean and as soon as a bike is obstructed by another it falls below the target threshold, regardless of lean angle.

3 metre mast, unobstructed	3 metre mast, obstructed

6m mast

A 6m mast is a major improvement. Being well clear of the fresnel zone makes it able to handle a full 60 degree lean at 300m. Results show that without obstructions 6m is good for all scenarios and if a bike is obstructed by others it only falls below the target threshold by 5dB which could be recovered with a higher gain antenna or by siting the antenna closer to the bend.

6 metre mast, unobstructed	6 metre mast, obstructed

The results reveal the following common findings:

Lean angle has a direct impact on signal quality with a full 60 degree lean adding more than 6dB of attenuation
Adjacent riders can introduce substantial attenuation with 3dB per rider
A bike at full tilt will lose another 1.5dB in antenna polarisation loss
Receiver height must be at least twice the maximum fresnel zone distance to budget for these issues
Receiver distance must be sufficient to maintain the double fresnel clearance so a distant mast is OK providing it is high enough
Low masts, like tight boots, are terrible!

Ideal mast height

The ideal mast height is relative to the frequency. At 2.3GHz the wavelength is 0.13m which based on the 300m distance used must be multipled by 24 to clear the fresnel zone making the minimum mast height 3.1m. As tests have shown, this height is insufficient to handle dynamic losses from leaning and other riders so should be doubled. Based on data, the recommended minimum height for a mast covering bikes on a bend is wavelength multiplied by distance/4 which gives the following table.

Distance m	Height m
100	3.3
200	6.5
300	9.8
400	13
500	16
600	19.5

Scripts and data

Scripts and data used to generate this study are available here. To use them you will need to enter your CloudRF API credentials into the CSV files and run them as follows:


python3 pathprofile.py pathprofile_3m.csv

For plotting to PNG charts you will need Gnuplot:


gnuplot unobstructed.gnuplot