This proved two key principles; Grid-search is a viable geo-location technique if a simulation API can scale to it in a practical time and publishing APIs enables easy future integrations.

Integration features

• Battery powered Jetson server running SOOTHSAYER
• Python script with SignalHound library which logs signal power measurements
• Offline web interface to display live survey data and control analysis
• Analysis tools to perform a grid-search of a user defined polygon
• Rapid simulation of hundreds of survey points against grid squares
• Configurable grid resolution

Test results

• A VHF tower on a distant hill was successfully geo-located using drive survey data from 2km away
• A short 1.5km circular route was selected around some large buildings
• The route only covered 10 degrees of deviation from the target
• The buildings provided evidence of the tower’s direction
• The statistical analysis revealed the tower’s likely grid square
• The high resolution simulation of many grid-squares took less than 5 seconds

A video of the field test is on youtube.

Source code

We have open sourced the capability within our Brutal Sauron demo here.

https://github.com/Cloud-RF/BRUTAL-SAURON/tree/main/signalhound

The post SignalHound integration field test appeared first on CloudRF.

The Tough Stump Rodeo is an outdoor edge technology demonstration set in rural Montana.
Selected companies collaborate to integrate their capabilities with the ATAK common-operating-picture to complete communications challenges.

CloudRF participated for the first time as a key enabler on the most challenging lane, the sub-terranean, which required participants to communicate and operate within an underground mine set in a steep ravine located 50km from the HQ in mountainous terrain.

With accurate planning, we quickly built a large radio network with less nodes and greater reliability than could be achieved with basic LOS tools.

Data Preparation

Our preparation started early as we needed to acquire high resolution data for the area to ensure accuracy. Prior to the event our data resolution in Montana was only 30m. We sourced 2m accuracy LiDAR from the USGS for the Ruby valley which we enhanced with 2m resolution tree canopy data from Meta.

Based on feedback from previous years about trees around the mine, we knew accurate tree data would be essential.

The data was loaded to the public system, CloudRF, weeks prior to the event and side-loaded to our offline SOOTHSAYER servers as GeoTIFF files within a data package.

Equipment

We deployed with three offline SOOTHSAYER servers of varying size with several phones and tablets as clients:

• A standard HP Z-Book laptop running Windows/Podman (RTX4070 GPU capable of 15.6 TFLOPS)
• A Carnegie Robotics CardShark computer running Ubuntu/Docker powered by a portable USB-C power bank (Jetson Orin NX capable of 3.7 TFLOPS)
• A Solace Communications Global Edge computer running Ubuntu/Docker powered by a larger USB-C power bank (Jetson Orin NX capable of 3.7 TFLOPS)

Additionally, The Global Edge computer was prepared with our Trellisware API script which interfaces directly with a donor radio to model live network coverage.

Site survey, Sunday

As we were headed to a new area, we were keen to know as much as possible about the terrain which for communications means noise as much as topography.
We took a spectrum analyser up to the mine site on a wet Sunday to check out the noise in the L and S bands and after a long insertion hike due to a closed seasonal access road we were satisfied to find there was no RF noise there.

The nearest noise source was a cell tower up the Ruby valley below which due its location was not able to serve the area of interest. We were therefore able to use the Johnson Nyquist formula with high accuracy to predict the expected noise floor for a given bandwidth.

We modelled the Mine location with modest system profiles (low height/power) to see if we could identify any local relay opportunities. The mine was tricky as it was in a steep forest ravine so we stood at the entrance and observed where it could reach. This low tech study confirmed our modelling which highlighted a hill ~750m due west which just overlooked the mine and had excellent views across the Ruby valley to the south.

Using a mean site upon the hill within the painted coverage area we ran a second simulation with an extreme 40km radius to see where this could hit. We were pleased to see coverage on an embankment 35km down the ruby valley which was useful as the valley’s curved shape meant a relay would be required.

Next, we ran a simulation on the distant HQ location which revealed an area of mutual coverage. A plan was forming…

When running long range heatmaps, the resolution becomes diluted. This is necessary to remain within processing limits as whilst 16 million point calculations are available due to the large GPUS we have on CloudRF, they are impractical for a battery powered Jetson which must share its output over a radio network on ATAK. We also observed notable latency with fetching large KMZ files via the radio’s onboard Wi-Fi as it’s running an older 802.11 standard.

We used our plugin’s limit of 4MP which provides a high resolution result in a practical time of several seconds. Our solution to the ‘mountain repeater’ problem whereby a distant tower is serving a remote location is the bounds feature. This API parameter defines a polygon which focuses processing effort to increase speed and accuracy.

As you can see from the images, the difference the bounds feature offers is significant. It allows the simulation of high resolution at long distances which previously would have been impractical with a ‘big heatmap’.

We drove to the relay we wanted to use and were disappointed to find it was on private land which was time well spent none the less. As a result we identified a secondary site on a layby to the north which was the best we could do.

Setup, Monday

Our radio partner trusted our recommendation and deployed a Comrod ETAMs mast to the layby despite it not being recommended as one of the official repeater positions.
The first (15km) link back to the HQ was barely workable which aligned with the fringe heatmaps we had generated. The weak link was immediately made good by climbing the steep hill overlooking the HQ. The additional height cleared the Fresnel zone which was obstructed by trees and buildings in the valley.

With the first link in, focus shifted to the long link to the mine.

We drove up to the mine and headed out on foot to the exposed hillside we had identified from the mine. This was a steep and difficult route, in hot weather, with rattlesnakes and bears, which Alex H from Trellisware made no less than 5 times. Give that man a raise!

On the hill we used ATAK to navigate to the area on the track on the hill we had identified. This zone covered several prominent rocky outcrops which as we found were popular for sunbathing by snakes. Once in the zone, it became apparent that this would work as radios with low gain whips were connecting to the distant 35km relay. This link was boosted from workable to good, and fit for video, with the deployment of a Farfield Antennas APEX directional antenna.

Our relief at establishing communications was short lived as we were challenged to find a better spot. We used SOOTHSAYER on the CardShark server to simulate the midpoint relay to produce an updated layer. This layer was used to identify a better site nearby at a rocky outcrop on the hill. We relocated to the new site and were pleased to confirm a modest improvement to the link SNR. The scale in the change of location was minor given the 35km distance and the fact both sites had equally great views down the valley but the improvement was notable due to the shape of the convex hill and it validated accurate simulation over ‘looks good’.

During the excitement of closing the big one, we forgot to leave behind a radio at the mine to test the next link. This was soon rectified by a party which returned to the mine and confirmed a good link, which did not come as a surprise given the visibility from the mine and close proximity at ~750m.

A very satisfying radio check from the mine was heard at the HQ 50km away around the valley, over 3 links.

With the sites identified, the network was optimised with wired links between co-located relay nodes on alternative frequencies to increase throughput. There were other configuration changes higher up the OSI model also which are not covered here as we’re focused on establishing layer 1 only. The optimisations were designed to increase throughput and reduce latency to support both video and live UAS control.

Live coverage mapping

In our vehicle we kept our Global Edge server which had a higher endurance than the CardShark. This server was connected to a donor radio’s Wi-Fi access point as a client which enabled it to interact with the Trellisware API.

Our Trellisware python script fetches radio metadata to generate coverage heatmaps for the network using live settings including noise. This is presented as a network KML layer which is consumed by clients including ATAK.

We last demonstrated this in our office car park with our own TW-750 radios so it was exciting to use it on a mountain with a diverse network of different radios. We’re pleased to report it worked as designed after a tweak on the mountain to handle output from radios we’ve not worked with before. We’ve even heard a rumour the KML refresh may be lowered this year to support faster refresh rates, nearly 6 years after we requested this.

We also exercised the ATAK plugin’s Co-Opt function. This powerful feature allows any callsign on the map to be given a radio template which follows its position. As the callsign moves, the radio coverage moves. You can see a video of it on our youtube channel.

Show time and interference

The network was scheduled to deliver a live video feed of a drone exploring the mine.

Despite a day of successful testing, leaving radios behind overnight in the mountains with wildlife and the elements meant unexpected issues were encountered which required local input to fix. On demo day an eleventh hour reset for the relay was promptly executed by Josh, who ‘hauled ass’ whilst observing local speed limits to get up the valley and save the day.

The live video was streaming well on schedule via a local radio’s WiFi access point until the production tent filled with observers… At this time, the congestion within the 2.4GHz ISM band increased and the impact became obvious as the video deteriorated and then failed. The irony of engineering a 50km muti-hop data network in the mountains and failing at the last 2m inside the tent was a learning point. In hindsight, a wired connection to the tablet would have been safer and people should listen to Peter.

The WiFi link self restored due to Automatic Channel Selection (ACS) and normal service resumed with live UAS video streamed over the RF link under the direction of the HQ.

Summary

The event stress tested our capabilities to the limit, where it matters, and provided invaluable feedback we would never have found in a dozen trade shows or car park tests. We leave with very high confidence and a list of improvements and feature requests from the many customers and partners who we interacted with.

One of the most significant features will be the ability to expedite the site selection process for operators with a prompt to an LLM which can execute the multi-stage process of site selection using accurate radio templates. A lot of firms are chasing this AI dream but very few indeed have a mature, published, API to build upon.

We came prepared to model the inside of the mine using our 3D engine which was risky as we needed to acquire and then vectorise a large LiDAR scan from a robotics partner under a tight schedule. We acquired the model but hit formatting snags during the conversion to glTF so parked that task for another day. We did however produce a useful glTF to 3D tile script to present 3D models on ATAK which we will publish.

Despite the maturity, we’re still not elite enough to have our open source plugin listed on TAK.gov but as the push for published interfaces grows, we’re confident that sharing, not guarding, interfaces is the superior strategy for vendors serious about integration, more so in the age of AI. As more proof, we were pleased to see a shiny new plugin at this show that used our API with a radio API that was developed rapidly by a vendor without our knowledge.

Finally, for anyone still unsure if SOOTHSAYER works offline because our company has Cloud in the name, we can assure you it does as we do not own a Starlink and there is no cell coverage in the upper Ruby valley.

For more offline field tests see our Youtube channel.

The post Tough Stump Rodeo 2026 appeared first on CloudRF.

We conducted a field test in the mountains with SOOTHSAYER focused on automation and endurance. The test generated quality data and revealed altitude issues with our plugin we have since fixed.

We conducted a field test in the mountains with SOOTHSAYER focused on automation and endurance. The test generated quality data and revealed altitude issues with our plugin we have since fixed.

During the test we created 925 multi-site coverage heat maps and 4625 links to maintain a live map of the network. We previously established model accuracy on previous field tests so the focus here was on endurance.

Live network mapping is radio planning without user interaction where radio locations and coverage are updated dynamically via an API. It requires fast and economical edge compute like our SOOTHSAYER API to be effective and is not possible with legacy desktop tools.

This offline edge capability is implemented in our ATAK plugin via the Co-Opt feature. This new feature updates network coverage automatically using live map data to provide a current view of communications problems and opportunities, akin to a moving weather layer. It is useful for deploying radio networks into challenging terrain.

Test objectives

• Collect performance data
• Prove software stability
• Test altitude logic

Test setup

Hardware

The edge compute used was a Nvidia Jetson NX 16GB onboard a Cardshark rugged computer with an external Wi-Fi adaptor to provide an access point for the phone client.

The computer was powered by budget USB-C powerbanks rated at 13000mAh and 25000mAh respectively.

The test phone was a Samsung Galaxy S23 connected via the Jetson’s Wi-Fi.

Software

The offline software running on the Jetson’s Jetpack 6.1 OS was SOOTHSAYER v1.10, deployed as Docker containers. The resource intensive 3D engine container was not needed here so was disabled.

Services for a CoT simulator, a low power 5GHz Wi-Fi access point and a performance logging utility were running.

On the phone we ran ATAK 5.6.0.12 (Play store) with our SOOTHSAYER ATAK plugin version 2.7a.

Reference data

The Jetson was pre-loaded with 30m SRTM1 DTM and 10m ESA Land cover data for the mountainous test area. The phone used cached Openstreetmap mapping and 30m SRTM1 terrain data.

Test route

The area chosen was the Glenshee ski resort in the Cairgngorms national park, Scotland during early February where temperatures up the mountain were -10°C (14°F). A 16km circular route was followed which provided challenging conditions to meet the objectives.

Test data

Using the onboard Tegrastats utility we collected detailed data about workload, temperature and power consumption which will inform future designs and recommendations.

The day was split between two test profiles for the morning (0900 to 1300) and the afternoon (1345 to 1600).

Each profile used 0.5 megapixel resolution which for a multi-site request with 5 nodes would require the analysis of 2.5 million points using the ITU-R P.1812 VHF/UHF propagation model which includes diffraction.

In the first test profile, a calculation was triggered if a radio moved more than 200m. This is an economical way of working designed to extend battery life and reduce bandwidth if working across a network.

In the second test profile, a calculation was triggered on a 10 second interval. This is a more intensive way of working which provides regular updates.

Processor load

As expected, the CPU and GPU load was more intense for the fixed interval than the responsive profile. The spacing during the responsive profile in the morning shows our slower progress on the ascent followed by rapid progress as we moved across the plateau and the server worked harder to keep up with us.

SOC Temperature

The internal SOC temperature chart was also predictable as the unit was inside a waterproof bag inside a rucksack. It climbed steadily during the ascent, then dropped sharply as we stopped to make a video where it was removed from the rucksack briefly.

The unit temperature leveled out at 53 degrees Celsius inside the rucksack. It was not an ideal place to achieve cooling but given the winter conditions, quite acceptable judging by the data. A temperature of 80 degrees would be hot.

In the afternoon the unit was attached outside the rucksack in the waterproof bag where it leveled out at 32 degrees Celsius. The moment the rucksack was placed inside the vehicle before 1600 is evident as the temperature climbed steadily. This coincided with it being placed under an intense load during a driving demonstration we have published on our Youtube channel.

Power consumption

The most valuable data was power consumption which showed some interesting features and very encouraging mean values. The afternoon profile was more intense but did not increase peak power consumption which was actually lower than the morning for reasons which were not immediately obvious.

Following inspection of memory consumption (~25%), the reason was assessed to be a GPU memory leak triggered by unplanned “Above Sea Level” (ASL) calculations which occurred on the ascent. A large calculation needs more memory, which draws more power. Unlike the CPU engine which is called on-demand, the GPU engine runs continuously and its memory consumption can grow with use. In this case power consumption grew by 250mW whilst delivering 925 heat maps which we’re happy with.

The afternoon was not affected by the ASL memory leak so we maintained a steady even profile at around 7.5W power consumption, well within the range of a phone power bank.

Test videos

A video of select moments from the edge compute field test has been published on our Youtube channel. Following the field test, we created a bonus video of the drive home as the server was still running in the vehicle. This second video demonstrates the Co-Opt feature running with a 5 second refresh on a vehicle moving at up to 50 mph.

Issues

Plugin altitude logic

During the ascent we noted our own position marker, sourced from GPS, jumped from Above-Ground-Level (AGL) defined within our template to Above-Sea-Level (ASL). This was due to logic inside our plugin designed to handle aircraft.

The logic compares reported (GPS) altitude, measured in WGS-84 Height Above Ellipsoid (HAE), which is known to be inaccurate, with (ATAK) terrain height and if the difference exceeds 120m / 400ft, it uses ASL units and overrides the template’s receiver altitude to the local terrain altitude.

For more information on Height Above Ellipsoid see this article.

// If Height AGL is > 120m / 400ft, this is probably flying so we switch units to meters AMSL and use GPS altitude

if (altitude - terrain > 120.0) {

  marker.markerDetails.transmitter?.alt = altitude.toDouble()

  marker.markerDetails.receiver.alt = terrain + 1

  marker.markerDetails.output.units = "m_amsl"

} else {

  marker.markerDetails.output.units = "m"

}

This risky logic made sense from the comfort of the office with a GPS simulator but was a mess on the mountain with real GPS altitudes. The synthetic CoT markers were unaffected as they report a height above ground level.

As we went on to find, we were comparing an inaccurate GPS altitude with an inaccurate terrain altitude. Not exactly a recipe for success :/

ATAK API inconsistencies

Whilst on the mountain we noted a disagreement between our GPS altitude and ATAK’s reported altitude which warranted a deeper investigation. During the investigation we discovered inconsistencies with ATAK Elevation data.

The ElevationData class we, and no doubt other developers, were using was deprecated and apparently removed in 5.6 despite being in the Hello World demo for that release. We were using this with the getElevation() method which returns the height in meters above the WGS-84 ellipsoid (HAE).

val dtmFilter = ElevationManager.QueryParameters().apply {

  elevationModel = ElevationData.MODEL_TERRAIN

}
val terrain = ElevationManager.getElevation(currentMarker.point.latitude, currentMarker.point.longitude, dtmFilter)

The recommended replacement for ElevationData based upon public source code for 5.5 is the ElevationChunk API. There are no public examples for implementing the recommended alternative at the time of writing although references were noted in documentation before it was deprecated in 5.3 which needs clarification.

DTED or SRTM?

The deprecated method used was evidently returning a value based upon low resolution DTED0 data at 1km resolution. This was less accurate than the 30m SRTM1 (DTED2) data which ATAK tools like the range-bearing elevation profile or cross marker (X) use. SOOTHSAYER uses SRTM1 also.

ATAK 5.6 was found to be referencing different datasets for the same position between its interface tools and programming API which was frustrating. To prove this we pulled both the raster tiles and used GDAL’s location info utility to plot the differences for the route.

At location 56.875932, -3.377869 we experienced a large height error when the plugin fetched a height of 879m HAE yet the GPS reported 997m HAE (visible in the screenshot above). The massive 118m difference is just shy of the 120m needed to trigger our “airborne” logic.

The GPS measurement accuracy in the z-axis was measured to be inaccurate by at least 10m as the real altitude was 1007m ASL so it appears we had an altitude error greater than 120m during the ascent. A notable error which affects other GPS apps.

gdallocationinfo n56.dt0 -wgs84 -3.377869 56.875932
Report:
  Location: (37P,15L)
  Band 1:
    Value: 879

Digging into ATAK’s preferences we found validation for our theory via the “Pull Elevation Mode” option within Elevation Overlays Preferences. The choice between DTED and Highest Resolution suggests this was implemented to support better than DTED data eg. SRTM1. It is not clear if it references DTED0 or SRTM1, which as we’ve shown could be a +100m error.

Some batteries are better than others

Our goal was to use flight-safe USB power banks which can easily provide the 7-8W of power needed to run the capability. We ran soak tests in the office to establish a battery life of 6 hours for the smaller 45wH battery. We expected this to be reduced on the mountain so purchased a larger 92wH battery but it failed after 4 hours despite being kept warm inside an insulated jacket.

The smaller battery proved its worth and ran for two hours with only 35% consumption suggesting it would have lasted longer than the larger battery.

During subsequent charging of the large battery it reported unexpected levels suggesting it was likely defective and under performing.

Our conclusion was that you can live-map a network for more than four hours on a small battery, but it must be a reliable one.

Conclusion

We were happy with the test and the results which showed solid stability and good power economy. It validated the hardware, the SOOTHSAYER API and most importantly the concept of edge coverage mapping.

Given the accuracy issues experienced with GPS data and the deprecated-yet-still-going elevation APIs using low resolution data sources, we have commented out the error prone “airborne” logic in our plugin and will only use the fixed altitude(s) defined within the radio template until further notice.

Plugin users can edit both the transmit and receive altitudes above ground level by selecting the marker then clicking the pencil.

The ATAK plugin has already been updated and pushed to our Github repository and Google Play as version 2.7.1

The post Live network mapping endurance test appeared first on CloudRF.

Radio Direction Finding (DF) is the art of determining the location of an emitter and is used in search and rescue, coastal surveillance, law enforcement and defence. There are different techniques using power and phase but the output for a single sensor is normally a Line of Bearing (LoB) which points towards the emitter.

If you’ve ever seen DF depicted in marketing or an info-graphic, you’ve likely seen three geometrically distributed sensors surrounding an emitter which produce a high accuracy position fix (PF) where their lines of bearing converge.

In the real world, DF systems are expensive and require specialist training so are in short supply. It is far more common for these systems to be used in isolation so operators must determine an emitter’s location with a single LoB and a map study. For powerful signals, the search area could be vast.

Guessing the signal power

For a signal to be tasked for DF, it’s frequency is already known. With signal classifiers increasingly integrated into receivers, and now even open source, the signal type may well be known which helps answer a key question: what is the signal’s transmit power?

When a new signal is detected, it could be in the room next door or in the next county. Knowing the signal type and ideally the hardware is key to estimating the distance, as you can lookup the possible power levels from a data sheet.

A portable radio has variable power levels: For a DMR radio with low and high power at 0.1W and 4W these can be put into a basic path loss model to determine the possible distance. Using the Friis reference model with a detected signal of -80dBm for example, a 1GHz signal could be 2.4km or 15km away in free space.

This significant variation with the possible distance is where modelling can add value to reduce the vast search area.

For the example radio, these power values in Watts must be converted to decibel milliwatts (dBm) for consistency with the path loss modelling and to establish the range in decibels which will inform simulation parameters. In this case, low power is 20dBm (0.1W) and high power is 36dBm (4W) for 16dB of uncertainty.

In an obstructed environment such as a forest, this uncertainty represents a shorter distance than in free space where again, modelling can add value. A counter drone system is an example of a free space problem.

Link reciprocity

A radio link is not symmetrical due to how and where obstacles impact the fresnel zone which is the cone of power an element radiates. Even if you have line of sight (LOS) between two even power stations, you can still get different received power levels from A to B than B to A.

This matters as we cannot model the emitter since we don’t know where it is! We can only model the receiver location.

In our experience, the difference is measured in single digits and is small compared with noise which will make a bigger impact on a link’s viability. If you are operating at the edge of a system’s link budget then the reciprocal difference may be enough to make a link one way only.

For modelling a receiver we need uplink (talk-in) measurements instead of downlink (talk-out) which we normally collect for clutter and model calibration.

Field testing

We conducted several field tests to integrate our API using a budget commercial DF receiver, the KrakenSDR. This compact entry level unit gave us a LoB (with 8 degrees of error) we could work with but as it used 8-bit SDRs, we could not rely upon the received power level as low resolution SDRs can not represent weak signals.

After a false start with a 12-bit SDR designed for the amateur community and interfaced with SoapySDR, we used a professional RFEye receiver which aside from having superior measurement accuracy and sensitivity is a turnkey solution with a web API which we have integrated with our API previously.

Test system

Our test system grew in scope from a Kraken with a Pi to a network in a box with a bespoke management and signal logging interface. Key to this innovation was not creating a budget DF system which we needed to collect data but the employment of an edge modelling capability on a Raspberry Pi 5.

Our goal was to develop a hardware agnostic script which our customers could use to enhance their DF data.

Hardware

• The Line of Bearing came from a KrakenSDR with a circular 5 element array upon a 2m telescopic mast.
• The processor was a Raspberry Pi5 running our test software and SOOTHSAYER v1.10
• The radio traffic was generated by a Tait DMR portable radio equipped with a programming cable connected to a Pi4.
• The power measurements came from a CRFS RFEye connected to an elevated monopole antenna.
• A pair of sensecap meshtastic LoRa trackers were used for GPS tracking.
• A laptop and tablet running ATAK were used to manage the system and observe the output as a KML.

Software

To automate data collection, we developed test software to collect data from the SDR and DF receiver simultaneously and model them using our API. The DMR radio was configured to broadcast telemetry periodically which provided a regular target signal and the out-of-band meshtastic tracker provided a precise location within the trees.

We couldn’t use a second DMR radio to receive the telemetry as bi-directional radio traffic risked spoiling the data.

The modelling came from SOOTHSAYER 1.10 which was installed upon the Raspberry Pi 5. This also provided the map tiles for a web based logging system which displayed live signal readings. Only one (CPU) API call was necessary per test cycle to generate a grey scale Path Loss map in decibels (dB) from which subsequent received power heat maps in decibel milliwatts (dBm) could be rapidly derived using a simple formula.

The path loss simulation needs refreshing if either the location, frequency or height change but is power agnostic. The client script queries this path loss map using known (or assumed) radio power levels.

Results are presented as a network KML which can be consumed on standards based geo-viewers like ATAK.

Challenges

We took our ‘Temu DF system’ out twice but we couldn’t collect as much data as we wanted in the time available due to different constraints such as the weather or just running a small business.

A decision to avoid vehicles and buildings was made to avoid reflections which meant we had to run the equipment from travel batteries. The power budget for the Pi5 (30W), KrakenSDR (12W) and RFEye (5W) was 47W which was more than we normally test with so it reduced our endurance.

We encountered local radio traffic on our licensed channels due to the choice of locations overlooking the city. This was easy to discount at the start of the test when our signal was obvious but became a nuisance as it faded into the trees and ultimately tainted our test data since we were triggering on power.

Old data to the rescue

After several frustrating tests where a lot of time was spent climbing local hills, calibrating DF and chasing false positives, we elected to reuse a rich data set from an antenna field test last year which included bi-directional links for a UHF radio on a moving vehicle.

This data was attractive as it included the uplink and a good variety of obstacles including houses, trees and hills as well as LOS links which are all useful for calibration. Before we could conduct DF analysis with the uplink, we calibrated the local clutter using the downlink, as we do routinely for calibration. This is a standard process we have developed a feature for in the web interface as well as a supporting video tutorial. Using our new 2m tree height data, we were able to improve upon last year’s score.

As we did not collect lines of bearings during that model test, we had to simulate these using the known vehicle location for which we used 10 degrees of azimuth error.

Analysis technique

To compute the effectiveness of this technique we calculated the area of the 10 degree arc where the vehicle could have been, with a radius of 6km representing the maximum range in this test.

This gave us a search area for a given LoB of 3,141,593 m2.

Our analysis script calculated a high resolution grey scale heatmap using SOOTHSAYER’s API which was referenced with collected power readings. To compare path loss (dB) with received power (dBm) we used the known radio power of 2W (33dBm) within a link budget formula to generate received power which was compared with measurements.

RSSI (dBm) = Radio Power (dBm) + Gain (dBi) - Path Loss (dB) - Losses (dB) + Receiver Gain (dBi) - Receiver Loss (dB)

Where the difference between measurements and simulation was within tolerances of our colour key, we styled that pixel, otherwise we eliminate it from the search area and set it to transparent.

The result is an accuracy heatmap defined by a traffic light colour key. The levels we chose for our “known power” assessment were 1, 2 and 3dB. By showing 3dB of error we allow for receiver error and reduce the risk of false negatives where a matching location might be discounted.

When the radio power is known, we can produce more accurate results.

When the radio power is unknown and the hardware/signal is known, we can simulate the minimum and maximum power to generate a dynamic range for the analysis. We used a low power value of 20dBm (0.1W) and a high power value of 36dBm (4W) for a possible power range of 16dB so our “low accuracy” colour key was 14/15/16dB.

We repeated the analysis with known and unknown power levels to compare accuracy.

Results

Analysis of data revealed the simulation heatmap significantly reduced the search area. As expected, knowing the radio power helps greatly but even with unknown power the search area was reduced to 32% of what it could have been for a conventional 6km arc.

Even when radio power is unknown, the search area is reduced significantly

The amount of benefit was relative to the terrain and clutter: For example, where there were no obstacles or a single consistent obstacle such as a forest, the result was a focused band of probability without any false positives.

Where there were multiple obstacles such as a hill and a forest, false positives appeared which depending upon the ground could be discounted by an observer. This was to be expected given the pixel picking which is taking place.

A tight traffic light schema, with tuned clutter, was better than a loose schema with larger error margins. The reason being that it will show much less false positives.

Video and KMZ

This video is a sped-up compilation of time stamped KMZ layers viewed on Google Earth showing the vehicle’s route around the sensor. Where the vehicle disappears, no signal was detected.

The KMZ is available here and works best in Google Earth.

Conclusion

This testing proved that the effectiveness of a single LoB can be improved greatly with modelling but the concept is only an improvement if the analysis is automated as doing this manually would not be faster than a map study.

The reason this analysis isn’t performed regularly by DF systems today isn’t for a lack of LoBs and RSSI measurements but rather a lack of APIs with which to exploit this information. Current RF planning software exists as a user interface which requires manual, and skilled, operation. Furthermore, the capability often exists in the wrong location on a high performance desktop computer, disconnected from edge sensors.

By putting this API at the edge on small board computers (SBCs) such as the Raspberry Pi 5 or Nvidia Jetson, a DF system’s effectiveness can be improved. Through open GIS standards like KML, the result can be consumed on open standard GIS systems like ATAK requiring minimal integration effort to add a powerful capability.

Looking forward, we are speaking with open minded vendors about adding this API to enhance existing systems.

If you’d like to improve your LoBs, get in touch with us or one of our regional resellers.

Links

SOOTHSAYER server: https://cloudrf.com/soothsayer

Kraken SDR: https://www.krakenrf.com/

DF integration demo: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/integrations/DF

API schema: https://cloudrf.com/documentation/developer

The post Enhancing Radio Direction Finding with RF simulation appeared first on CloudRF.

• Dynamic radio coverage visualisation
• Vendor agnostic radio integration via ATAK
• 450 heat-maps delivered without issue
• Sub-second computation via Cardshark computer

Background

Three years ago we developed a “live” simulation capability using location-aware MANET radios which we described as dynamic radio planning which fused real and planned radio positions. This feature required a third party hardware API with restrictive terms, common in commercial radio, so it exists as a video demo only.

We’ve refreshed and field tested this concept, using modern edge compute and open standards.

ATAK as the common API

Using ATAK as a proprietary API broker, we are now able to do the same via our plugin. The technology agnostic capability can be used with any radio, vehicle or marker on the map and by starting with an open information standard, Cursor-on-Target (CoT), it eliminates the commercial friction with NDAs, proprietary APIs and different vendors.

Open standards unlock low-cost cross-vendor interoperability in a way proprietary standards never can. For example, two vendors can achieve compatibility without knowledge of each other’s products. Better still, compatibility with future products, not yet deployed, can be assured.

The field test

We picked a local Forest to field test this concept using a Cardshark computer which is a rugged Jetson Orin with a 1024 core GPU. We need the GPU to efficiently compute our ‘Multisite‘ network heat maps. The ‘Points‘ links are CPU powered. We’ve worked with Jetsons on previous field tests but under manual control. The automation we’ve added here makes periodic API requests and places the computer under a sustained load.

The radio network was a four Tait 9300 DMR portables on a 2W channel, with one donor radio connected via a USB programming cable. GPS locations were fetched using our Tait script which outputs CoT broadcasts to make them appear (and move) upon the map.

The testing went well and produced 450 heat-maps to validate both the concept and the computer. Crucially, our 9Ah battery depleted only by 25% during 2 hours of intensive testing. Our conclusion is that with a reasonable load and refresh rate this edge capability can be scaled to run all day, as we found in Scotland earlier this year.

Speed test!

Five years ago we asked for the ATAK KML refresh rate to be lowered to enable a “follow me” demo we published and our understanding is it was capped by design at 10s (compared with 1s for Google Earth) due to a concern over excessive bandwidth which was understandable – at the time. A lot has changed in five years of software and radios and now we’re doing the compute locally, this concern is obsolete.

Our GPU engine can model a heatmap in under a second so we bypassed the network KML functionality (which is still a valid way of refreshing heatmaps on ATAK as our Tait plugin does) and implemented our own refresh system, designed for fast moving data. During our speed test, we refreshed the heat-map every 5s which both ATAK and the Cardshark handled comfortably. Logs showed each simulation took under a second with another second for pre/post processing and another for communication. The points requests take 150ms and are called for each radio so four radios would be 600ms, excluding communication.

Issues identified

We identified issues relating to USB tethering which weren’t apparent in the office: The Cardshark does not have WiFi which we employed for previous field tests so this made communication more challenging.

We were able to workaround this for the test with a WiFi hotspot to fool the plugin into thinking it was on a network. As we were using dynamic IP addresses provided by the phone and the Cardshark has no interface, we ex-filtrated the IP information we needed via ATAK which is why there is a IP-address-callsign visible in the video.

The Cardshark is a fanless design which requires airflow to cool it. We deployed it in a bum bag / fanny pack where it unsurprisingly became hot during intensive use but still functioned well. For enduring use, this would need to be mounted externally and the workload throttled accordingly.

Our radio template needed work as only afterwards did we note we did not set the DMR template’s noise floor which defaulted to -133dBm based upon the narrow 12.5KHz bandwidth. This was why there were blue 50dB links visible in the video when in reality the noise floor was likely closer to -113dBm and these links were a more realistic 30dB SNR. This issue did not affect the heatmap which used received power units and we’re satisfied from calibrating with large data sets that the modelling is accurate.

Credits

A special thanks to GoTak LLC who helped us develop and test the live Co-Opt feature in ATAK and Carnegie Robotics for producing the Cardshark and providing timely support.

Links

SOOTHSAYER self hosted server: https://cloudrf.com/soothsayer

Cardshark computer: https://carnegierobotics.com/cardshark

SOOTHSAYER ATAK plugin: https://github.com/Cloud-RF/SOOTHSAYER-ATAK-plugin

Tait ATAK plugin: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/integrations/Tait

Fanny pack: https://www.osprey.com/gb/osprey-seral-7-s23?size=One+Size&colour=Black

The post Live RF coverage mapping with ATAK appeared first on CloudRF.

Key findings

• Offline operation for over 6 hours
• Average 4W power consumption
• Fan draws most power over a day
• Nvidia Jetson power profile recorded
• Phones are tricky to operate with gloves

Test setup

An Nvidia Jetson Orin nano 8GB processor was paired with a 10AH 12v battery in a portable case.

This was assembled and demonstrated earlier in January with this video.

The following software and services were installed to provide a representative stack:

• TAK server 5.3 with PostgreSQL 15.11
• Hostapd for a WiFi AP service
• DNSmasq for a DHCP service
• SOOTHSAYER 1.8

Instrumentation was performed using the onboard tegrastats utility every second. This provided load data at a 1Hz refresh rate throughout the test. Two ATAK end user devices (Samsung S21 and S23) were associated with the WiFi AP and SOOTHSAYER server via the open source soothsayer plugin with distinct accounts for parallel processing.

Each phone was associated with the TAK server using TLS authentication. This served no purpose other than to show us a green light in the corner of the phone to prove IP connectivity which would be needed to use the (IP) plugin.

The last time we went field testing up a mountain we struggled with sound and wind so bought a lapel microphone so we could provide a detailed narrative whilst on a windy summit. This detail helped immensely with post analysis as we were able to identify details from the video which weren’t noted at the time.

Test results

A rugged 20km Scottish mountain route was selected over a period of 6 hours on a relatively mild day with still air temperatures in single digits celsius. Tests were performed periodically after long intervals to simulate real use with increasing difficulty: The first test being a single area calculation at 1MP resolution.

This was followed by a 4MP calculation which was later followed by a intensive stress test with two clients performing concurrent multi-site calculations. A multi-site calculation simulates several sites in a single API call and requires a GPU.

A final test was concluded at the car park where we were pleased to discover 2 of the 4 LEDs were lit on the battery. This video contains more detail of our hardware craftsmanship than we chose to share and is available upon request.

System startup

The server was prepared en-route and required it’s clock to be set manually since it had no internet access. This clock setting was necessary for both test results and SOOTHSAYER’s rate limiting which uses time stamps to ensure each user is waiting at least one second between API calls. Unlike the public system, SOOTHSAYER has no upper API limit.

The OS was ready after a minute and the software services ready after approximately another minute. The first, and largest (7W) power spike in the data was the first test from the plugin prior to departure at the car park. This was assessed to be larger than others due to Just In Time (JIT) compilation of the GPU kernel. The SOOTHSAYER GPU engine is noticeably slower for the first calculation for this reason, which is expected behaviour.

Test 1 – VHF handheld, 1 million pixels

This test was conducted an hour after startup whilst walking along. The template used was a VHF handheld radio with 10km radius and 20m resolution for a total of 1 million points. As you can see from the video it concluded quickly.

Test 2 – VHF repeater, 4 million pixels

This test was conducted after 2.5 hours after climbing up to the snowline. A VHF repeater template with 20km radius and 20m resolution was used for a 4 million point calculation. This was noticeably slower than the previous test due to the increased computation required.

Test 3 – Multi client stress test

This test was conducted on a cold summit after 3.5 hours of operation. This time, two clients were used to stress test the server with concurrent requests. The requests were more complex multi site API calls which models an entire network versus a single site. As well as GPU heatmaps, the CPU was employed to create links between the radios. Due to the steep topography and random test locations, not many viable links were displayed.

Power consumption

The 1Hz data was collected with tegrastats and showed good power economy. The jetson fan kicks in around 43C and spins up then slows which is visible throughout the data as a saw tooth pattern.

The 3 degree temperate spike during the ascent at 2 hours occurred in a sheltered ravine. Our assessment is that the simple case was suitable for the winter conditions but would require a case with improved cooling for use elsewhere.

The notable temperate drop occurred on a mountain top during filming of test 3 when the box was exposed.

Summary

The test exceeded expectations on power economy and performance and showed that a (budget) portable battery could easily provide up to 12hrs of operation. At the end of our expedition there were 2 out of 4 LEDs still lit on our battery.

It validated the client-server design since the phone batteries were only slightly depleted throughout the test. Both phones finished with more than 75% battery capacity. Performing simulation on a phone is convenient but a poor choice for battery endurance especially and scalability due to the dependency on reference data such as LiDAR and antenna patterns which are provisioned on the server. Note that phone 2’s mapping was unprepared during test 3 but was able to render high resolution topography, sourced via the server.

Of note, the stability and power economy of both ATAK 5.2, TAK server 5.3 and our own plugin was good. We experienced no crashes or connection issues throughout the day which was welcome.

CPU calculations

In the first video, CPU tests were mentioned which we did plan to do. We tested CPU area calculations the day before and were pleased to find they can be almost as fast on a (6 core) Jetson for single sites which was a nice surprise. Compared with a GPU calculation, they use more power so are not as efficient. We did employ the CPU for link simulation on the mountain but elected to focus on the GPU compute capability and power economy.

Lapel Mic

We were stunned by the sound quality on the mountain as the wind was intense for test 3 and we were using an iPhone with a wireless lapel microphone. We recommend this microphone for field testing.

Look ahead

Applications for this network capability include Search and rescue, Mining, Agriculture, Government and Emergency services. Crucially, The edge concept challenges historic ways of working, whereby an expert with a powerful computer produces a plan which is later rendered obsolete by changing events.

With edge compute, planning becomes dynamic which is important since no plan survives contact with reality. Having the ability to redesign a communications plan locally reduces the planning cycle, saves bandwidth and improves spectrum awareness.

For autonomous systems, having integrated communications planning improves their chance of success and supports decision making beyond topographical route selection.

More information

SOOTHSAYER is a self hosted RF planning server with interfaces for different systems such as ATAK.

The software is available as containers for x86-64 and arm64 architectures and can be hosted in the cloud, on a laptop or an Nvidia Jetson. For more information see here or email sales@cloudrf.com

The post RF planning at the Edge appeared first on CloudRF.

Previously, we validated diffraction models using LTE800 in the Mountains. The outcome of that cold test highlighted Deygout as the most accurate diffraction model when paired with empirical cellular models. For this much warmer antenna drive testing, we used lower frequencies and a lower mast in an area with many trees which presented a challenge for both legacy cellular models and LiDAR.

Testing highlights

• Average Root Mean Square Error of 7.4dB
• Average Modelling Error of 4.4dB
• Automated data collection with ATAK plugin
• New “General Purpose” model developed
• New “GP” clutter profile for use with GP model

Test setup

The test area was in and around the small town of Somerton in Somerset. This town sits in rolling countryside featuring farms, high hedgerows and blocks of trees. A railway line with road humpback bridges bisects the town. The town has a small housing estate under construction which did not feature in our buildings data.

The base station was a wide-band Omega panel elevated 5m above the ground and connected to a Trellisware spirit radio. The radio was operated across several UHF bands, each with 1.2MHz bandwidth, and live positions observed on WinTAK using cursor on target (CoT).

The antenna testing vehicle was fitted with a roof mounted magnetic antenna bracket which connected to a spirit radio. This mount allowed different antennas to be swapped out. As a result we were able to test both a Hascall Denke MPDP675X4 and a FFX Sigma 3.

Data logging

We know customers and OEMs like to voice opinions about radios, waveforms and antennas but without solid measurement data it’s just noise with a lot of bias and emotion.

Data beats emotions every day!

As an antenna OEM, FFX developed the ATAK spectrum survey app to streamline collection of field measurements for antenna testing in different environments.

The logging application used the Trellisware radio’s API to fetch link metadata from the local radio and save it to the SD card as a CSV file.

The ATAK plugin enabled a large quantity of high quality measurements to be efficiently collected. As a result we were able to execute several test cycles in a short space of time – just as well as it was hot (for the UK) and Harry had no air conditioning…

The CSV files were downloaded from the phone and loaded into the CloudRF calibration utility for analysis.

The survey data was filtered to remove results weaker than the theoretical noise floor at -113dBm.

We were planning to use a measurement error of 2dB for the high quality radios (a cell phone is 3dB) but owing to the high temperate of the mobile radio in the car we used 3dB as receiver performance degrades with temperature.

At first look

The first pass comparison of the data showed a ~15dB delta between modelling and field measurements with LiDAR, prior to tuning. Using the ITM model and a high reliability value (99%) this only reduced several decibels and clearly needed more work. Ideally the model should align within 10dB so clutter tuning can then be used to reduce this towards 6dB.

ITM uses the complex Vogler multi knife edge diffraction model which is accurate for hills but needs tuned clutter to handle soft obstacles. Using cellular models, as we did in LTE800 field tests, didn’t produce the same results due presumably to the lower mast height and frequencies, even when enhanced with Deygout diffraction.

A new model

Through curve fitting we identified alignment with the P.525 reference model and a 20dB constant representing observed system losses. When enhanced with the Deygout 94 diffraction model this produced excellent alignment with the more challenging beyond-line-of-sight areas. Many signal paths on the route had multiple obstructions so a multiple knife edge model (MKED) was essential.

We have created a new model from these settings called the General Purpose Model. It is frequency and height agnostic which makes it ideal for ground and air based links and much more versatile than empirical equivalents which must be operated within a restricted performance envelope. Like all our models it must be used in conjunction with a diffraction model and tuned clutter to deliver accurate beyond line of sight results.

In our opinion, modern developments in processing and clutter data especially have rendered legacy empirical models largely obsolete. The modern way to fit modelling to measurements is to focus on precise clutter data not old path loss curves.

In the screenshot below, the car drove up a hill where it fell off the network behind a prominent knoll before reacquiring the network later on. This knoll was the second of two obstructing hills for this section of the route. The modelling predicted more coverage due to the chosen receive threshold, -107dBm, which was based upon 6dB above the thermal noise floor which was -113dBm at 1.2MHz bandwidth. It is very likely local noise was slightly higher.

ITU clutter values

Without clutter, the General Purpose (GP) model will be optimistic in most ground environments. It will be accurate over bare earth but where obstacles are present, it needs land cover and a clutter profile. Prior to developing the GP model, we did most of the tuning in the model using reliability (%) and only fine tuned with the clutter.

This is why older CloudRF clutter profiles eg. Minimal.clt have low values such as 0.05 dB/m for trees. With the GP model, the model itself is very simple and most alignment takes place within the clutter (profile). As a result, the clutter values used for GP are much denser. Our GP profile, created for this test has trees with a density of ~0.5dB/m, aligning with ITU-R P.833, attenuation in vegetation.

Diffraction logic has been re-balanced to accommodate ITU clutter values. Users using either the default ITM model or models without land cover are not affected. Legacy clutter profiles such as Minimal have not changed but you are advised to try the new GP model and associated GP clutter and see the difference for yourself.

Test parameters

Bandwidth: 1.2Mhz

Feeder loss: 1dB

Receiver height: 1.5m

Receive sensitivity: -107dB (6db above noise)

Noise floor: -113 dB

Model: General purpose / ITM

Reliability: 60% / 90%

Context: Average

Diffraction: Deygout 94 / Vogler (ITM)

Clutter Profile: Buildings 3dB/m, Trees 10m @ 0.5dB/m

Radius: 6km

Resolution: 5m

Results

The following table of results were from measurements conducted with the same base station, vehicle and radios. Only the vehicle antenna, and frequency, were changed in between tests. Once calibration had been achieved the area covered was extracted from the modelling. This is typically inverse to the frequency so a low frequency has better coverage than a high frequency at the expense of bandwidth – and both matter.

There are two standout results from the data: First is the low RMSE accuracy for the new GP model with tuned clutter compared with LiDAR which is satisfying given the challenging terrain and the second is the performance of the Sigma 3 on a frequency it is not officially rated for as it has a bottom end of 350MHz. The best alignment with the same settings was found to be with -5dBi receive gain confirming the antenna can be operated lower, and at range.

Once again, DTM with clutter has proven to be superior to LiDAR.

The scatter plot for the 1.4GHz data shows the simple GP model to align closer to field measurements than the much more complex ITM model. Our conclusion is that the ITM model, and it’s Vogler diffraction, developed in the 1960s, pre-dates developments in computing and precision clutter so provides good performance across multiple hills, at range, but is inadequate for macro planning at “street level” resolution where density of obstacles must be budgeted for.

ITM continues to be a solid UHF broadcasting model but it was designed for hard obstacles. Retro fitting it with soft clutter, as we have done can improve its performance several decibels but for maximum accuracy, the simple General Purpose model with tuned clutter provides superior results.

Results Gallery

Tuned coverage and survey data is displayed on the same map showing the RMSE and Mean error.

Look ahead

The General Purpose model will go live on CloudRF in early July 2024 following more testing and then into SOOTHSAYER 1.8 later in the year.

The post Antenna drive testing appeared first on CloudRF.

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.

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!

The post Field testing diffraction appeared first on CloudRF.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

The post Calibrating beyond line of sight RF modelling with field testing appeared first on CloudRF.

Modern digital radio systems often have Application Programming Interfaces (APIs) for remote management. They also commonly have Global Navigation Satellite System (GNSS) modules for location awareness which enables “network maps” of where the nodes are. These vendor maps are great at showing where nodes are now (provided they are in coverage!) but what they lack is the ability to plan where nodes could be moved to.

When you combine these key features with our open standards modelling API you get a powerful new capability which allows you to observe the network now, and by moving or adding a simulated node, see the network in the future.

Case study – Trellisware

Trellisware^TM are a market leader in Mobile Ad-hoc Networks (MANET) whose versatile radios work where others fail due to their spectrum efficient TSM waveform. It’s currently in service with Government, Commercial and First responder markets.

The radios have a comprehensive API and integrated software services which allows for remote operation on a IP based network.

We were loaned some TW-950 Shadow radios to explore API integration. In a few days we were able to create an API client (in Python) to interface between the Trellisware API and our RF modelling API on SOOTHSAYER 1.3 which has a MANET planning tool.

Our Python client would interface with the radio network via the Ethernet connector on the side of a TW-950 radio from where the API would expose node metadata.

We would fetch this metadata (as JSON) and package it into a JSON document compatible with our Points API, which powers our MANET and route analysis tools. In the interface’s MANET tool, a new ‘play’ button pulls in the network document and models it through our fast API. Each link is tested using the real parameters, with minimal user interaction.

The flowchart is depicted below.

Once the data is displayed in the SOOTHSAYER interface, an operator can choose to move a node by dragging it or add an entirely new node, using settings of their choice, into the mix. This new node will be modelled alongside the rest of the nodes (many-to-many) to visualise what the impact of the new node will be.

A faster OODA loop

The Observe, Orient, Decide, Act (OODA) planning loop is an established concept which determines success in fast moving communications environments such as a fire or Police incident.

By combining real-time situational awareness with live modelling we can exercise scenarios and reach sound decisions much faster than by either guessing or using trial and error as is often the case in tactical communications in complex environments. The benefit is faster more efficient use of limited resources.

Demo: Do we launch the drone?

Deploying a drone equipped with a radio is a guaranteed way to fix MANET network issues, especially in cluttered urban environments. It’s resource intensive and risky as the drone is valuable, the radio, and network it enables, is arguably more valuable plus the battery life is very limited so this asset must be used sparingly, which is where planning comes in.

Placing a repeater drone “overhead” is not needed, unless you’re using it for observation also. If the drone has a vertical dipole, overhead would actually be the worst place for it due to the donut shaped antenna pattern as some early OEMs learnt the hard way.

A better place for a communications relay drone is at altitude but on the edge of the target network where it will be at less risk (and will present less risk to net members below it in the event of failure) but it will still be able to serve as an effective repeater.

As recent MANET demos have proven, this repeater could be effective from several miles away.

Look ahead

Now that we have a simple standards based, repeatable, method for adding live radios we’ll roll this into future SOOTHSAYER releases, the next of which is 1.4, scheduled for Q3 2022.

Customers can make their own plugins in any language to get their hardware data packaged as a JSON document for either SOOTHSAYER’s MANET tool or direct to the points API which powers it. You can find example scripts in various languages on our Github site and we are available to assist with bespoke integrations.

References

API examples: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/APIv2

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

Contact

If you are a hardware manufacturer or integrator looking to add this type of capability into either your own map or ours, get in touch as we know what we’re doing and it will save you years of R&D.

Email support@cloudrf.com for more information on how you can achieve dynamic planning quicker.

The post Dynamic network planning with hardware APIs appeared first on CloudRF.