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.

Whether its survey drones, drive test vehicles or a police analyst with a backpack full of phones, the problem is the same: RF propagation surveys are very resource intensive. They’re more accurate than a simulation, but not more efficient.

Survey data is typically a GPS log with signal metadata including a signal strength value. This can be different measurement units but the principle is the same. It is data which shows the signal at a given point.

Surveying is preferred for good reason by some industries, especially for evidential purposes where the variables in simulation open the door to uncertainty which nobody wants in court. Another reason is legacy desktop simulation software is slow and often inaccurate, especially amongst clutter which is more complex than a topographical study.

For example, relying upon a high-low empirical model like Hata which pre-dates developments in clutter will get you ~8dB accuracy whilst calibrated survey equipment can get you ~2dB, or ~3dB for an app on a standard phone.

Manual calibration

Using survey data like the output of Rantcell’s survey app, we can load this into our web interface to perform calibration manually. This process involves adjusting model and/or clutter settings until the error between the simulation and the measurements is as low as possible. It’s an efficient process as you can test thousands of points in a single API call but also repetitive, interface based and requires engineer input to adjust clutter values for example. You can see manual calibration in action here.

A good calibration would be below 8dB. For more on calibration of survey data, see one of our many field test blogs.

Good survey data is thousands of points all around a site of interest. When we’re field testing, we choose our route to ensure we collect a diverse range of data.

The Pizza Problem

The pizza problem is when you only have a slice of data but need to infer the rest. This is very common in the real world where a customer may not be able to collect data all around a site for various reasons:

• Lack of time
• Lack of access
• Lack of resource

This limited data is then used to estimate what the rest of the coverage looks like. For an omni-directional antenna, it’s a good assumption. For a directional antenna, it’s clearly less accurate but crucially, it is about making the best estimate using available data.

If you can get more measurements, then do it. If you don’t have the time/resource, then simulation using calibration offers the best compromise. After all a ~7dB accuracy prediction is much more useful than no coverage at all.

A Machine Learning genetic algorithm

Using a slice of data, we can employ a basic Machine Learning model which uses a genetic algorithm to optimise settings. It works by starting with a range of fixed inputs (tower frequency, location etc) and a range of variables (power, tree height, building thickness etc) which it uses to make pseudo-random requests to our Area API.

The responses are fetched as greyscale open standard GeoTIFF images which are analysed using the rasterio library against the survey measurements. The delta between points is recorded as both mean and root mean square error.

The RMSE error is the key figure which describes the error between two arrays of results. Achieving a low mean is easier to do by over-fitting a model, but lowering the RMSE is harder for a diverse environment as clutter must be tuned to allow for trees, buildings and open ground. The script constantly updates a custom clutter profile at the API with new values in between requests.

Many tools won’t publish performance data as it would make it hard to justify their price tag. Some cannot do diffraction which disqualifies them for signals below 2GHz.

The requests are scored individually using RMSE and ranked. The best scores from the generation are selected to breed the next generation and so on until the (user defined) limit is reached. Therefore, the process can be scaled to offer a quick result for a live map or a thorough result for enumeration of unknowns such as tower height, power or even tower location using a search box.

At the end of the process, the best values for the variables are shown which can either be used to build a custom clutter profile, as we do in the demo video, or scripted further to make a final layer for a third party interface.

Demo video

Conclusion

Developments in data and performance, accelerated by GPUs, means accurate and fast simulation is more viable than ever. By being able to deliver this capability in seconds instead of hours, new integrations and capabilities are possible. Furthermore using a mature API, with public examples, makes an MVP viable in days.

Using a SOOTHSAYER server, this can be done at the edge without internet access.

A few ideas for new integrations which can leverage this concept:

• A spectrum analyser with a living coverage map
• A signal classifier which shows more than metadata
• An app which shows the impact of antenna adjustments in real time
• A robot which maintains a live coverage map which can inform route selection
• An RFPS analyst can be freed up from walking around to do some analysis

Credits

Thank you to Rantcell for providing rich LTE drive test data and our resident Machine Learning guru, AppyBara, for developing our automatic calibration client. If you would like a copy get in touch.

The post Fast simulation calibration with Machine Learning 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.

We have optimised how our engines model attenuation and diffraction to improve accuracy and performance within forests (and buildings).

Highlights

• 20% accuracy improvement with clutter
• 6.8 dB RMSE error for NLOS simulation (1.6 dB accuracy gain)
• 78% GPU speed increase with clutter
• Better performance for radios within trees

Evolution of attenuation and/or diffraction

When a radio signal hits an obstacle such as a building, it attenuates through the obstacle and diffracts over the obstacle. Depending on the dimensions of the obstacle, a received signal beyond it could be from attenuation, or diffraction or a bit of both. It’s hard to tell. If you can’t get a phone signal behind an obstacle but walking away from it gets you a bar that’s diffraction. If you can improve a signal by walking into the obstacle, that’s likely attenuation.

Since 2020 we have offered configurable clutter and an increasing number of advanced diffraction models such as the fast Bullington approximation and it’s more sophisticated relative, Deygout 94. To address the challenge of simulating both the direct and diffracted rays, we implemented conditional engine logic for obstacle types such as trees and buildings so they would function differently: A forest would diffract and a building would attenuate, for example. This makes sense commercially as there is normally more money and people in a city than a forest.

The conditional logic added complexity and created visual artefacts so was replaced with dominant diffraction as most field measurements, and empirical models, are made on roads with diffracted signals. Our compromise for simulating within and beyond obstacles was to offer a DSM/DTM choice so users can chose to study rooftop LOS (and diffraction) with LiDAR where it’s available or focus on attenuation inside the material, but not both together until now.

Rethinking trees

We chose to make diffraction dominant with attenuation used for the face of an obstacle and in relatively low land cover. This resulted in “hot LiDAR trees” with a good signal across the canopy which is optimistic when your network is under the canopy but the obvious artefact justified the diffraction modelling beyond them. It also made good sense for urban rooftops where static communications equipment is installed.

In 2023 we challenged popular misconceptions that LiDAR is better for accuracy with a DTM/DSM field test where we achieved higher accuracy with calibrated clutter than precision LiDAR. This holds true for NLOS signals.

We proved the accuracy of the design choice with LTE and UHF field tests around mountains, buildings and trees but were conscious that a field test inside a forest would not be as accurate as whilst some RF would scatter from the canopy within a forest, this phenomenon was not nearly as reliable for planning as a nominal value per meter based upon the vegetation type. For example, a wet jungle attenuates more than most.

Now we can model both rays without compromise which for DTM produces visually different results. Previously, a building roof or tree canopy in DTM + Buildings would have been hot but now will be cold, or non-existent, since the receiver is within the obstruction and attenuation is being applied consistently throughout the obstacle (and prior obstacles).

Reverse engineering a forest

There are many historic studies into vegetation and material attenuation which have been summarised within a standard, ITU-R P.833. The ITU recommendation provides a useful reference for appropriate attenuation figures (dB/m) for varying wavelengths but does not prescribe a value for every material in every season. The best way to improve upon this is using field test data with calibrated clutter.

First, find two paths that go through and beside some uniform trees, eg. a wood block, on level ground. Calibrate the model so the clear path (B) beside the trees aligns with simulations and then note the difference of the obstructed path (A) eg. +30dB attenuation loss.

Using the difference in decibels divided by the depth of the trees you can compute a nominal attenuation per meter and adjust your clutter profile accordingly. In our experience, this is the best way to get to an accurate, regional, nominal value that works well for other paths providing the trees are similar. Looks can be deceiving as mature trees often have higher leaf canopies so may permit more RF than you might think!

The expected range for vegetation attenuation is 0.03 to 0.5dB per meter.

Dilution by diversity

Across a wide area there will be different types of vegetation. When using space based land cover data, like ESA Worldcover, the classification is an approximation eg. “Trees” or “Shubland” with the net result that the best overall attenuation value will be lower than the nominal value for a single type. For example, a northern pine forest may have an attenuation value of 0.3dB/m but when used in a larger context with different vegetation types, the best value may be 0.03dB/m.

The key to getting this tree/building figure right for an area is having a large amount of diverse survey data.

Calibrating for success

We used OFCOM spectrum data for the UHF 450 band to prove the accuracy of our refactor and were pleased to improve upon our accuracy scores and speed. The lower UHF band was chosen as it would have the most penetration which is a notably more expensive problem to compute than a LOS viewshed.

The chosen data set is on the outskirts of a coastal city covering hills, forests and has over 10e3 samples taken by vehicle. We load this data into our calibration tool within our web interface and make appropriate clutter adjustments to tighten up the score. In our experience, you can fit the General Purpose model to most frequencies if you focus on adjusting the clutter instead of the model. Recomputing the 16 million point model takes several seconds with a GPU.

Results

The results show a 1.6 dB improvement (20% better than old score) in accuracy and a 78% speedup for GPU calculations with clutter. The CPU refactor is 1.8 dB more accurate but slower when clutter is enabled. Both engines will now show reduced coverage when working with clutter in NLOS regions but will look the same for where there is LOS or no clutter.

Summary

This optimisation will change how heatmaps appear for DTM and clutter, especially around buildings which will change from hot to cold. The improvement to accuracy for both CPU and GPU is notable and we can now offer much better planning for radio users within forests as a result.

All propagation models, including ITM, will be adjusted when clutter is enabled for future calculations only. Legacy calculations are unaffected and users can choose to disable clutter or minimise the amount of change with the Minimal.clt (default) clutter profile.

For simulations using DTM or DSM layers only there will be no difference.

The change does not affect DSM mode so LOS studies of rooftops will be unaffected.

Look forward

Expect to see a field test in a forest.

We’ll buck the trend of collecting data from the comfort of a car and go off-roading to investigate VHF/UHF attenuation in trees. This data will help us refine our clutter profiles so we can offer better defaults.

The post Improving accuracy in the trees appeared first on CloudRF.

Budgeting for noise is critical to achieve desired signal levels. Historically, it was done with a single figure to satisfy all locations, eg. ‘-100dBm’. This simplification is a time/accuracy trade-off and is no longer relevant in the age of dynamic spectrum management and cognitive radio.

Noise varies widely between locations, and changes constantly, so we have invested in developing living noise maps to reflect this dynamic nature. Like a terrain layer that moves, noise data can be used to improve the accuracy and relevance of planning in dynamic environments.

Evolution of simulating noise

A noise figure (2022)

Back when we added Signal-to-Noise (SNR) output units in API v2.7, we needed to express the noise floor as a (dBm) figure to provide a reference for a signal’s quality eg. 15dB. Users interested in SNR enter a single value like -100dBm, hopefully based on the local environment, to describe noise across the entire area, or link. As this guesswork is prone to error, we automatically recommended a conservative value, to budget for high noise.

For example if the thermal noise for a narrow channel is -133dBm, our interface automatically recommends -113dBm as a floor for planning which provides 20dB for unknown noise.

The noise figure could be measured direct from a networked sensor which we published in early 2023.

A Noise database (2023)

Noise varies by location (and frequency) and the previous method didn’t scale so we developed a noise API to store noise data and reference it in calculations. The private data was used on a per-site basis so you could model a network with different noise at each site. A marked improvement on a single figure.

This development represented a leap forward in network planning as each node could be configured for the local environment, which can vary drastically. Two different users might have different needs so it is isolated to the user’s account. A multisite API call accepts different noise values for each site.

A Noise map (2025)

Building upon our Noise API, stored data was used to generate a noise map, specifically a raster layer of measurements, similar to clutter which our API can reference. This noise map describes thousands of noise points across the area or link of interest and provides high resolution noise. Now you can see the real impact of noise with minimal effort at each location covered.

Any calculation requested with the database option versus the legacy single figure method will create and use a noise map at the API. The quality of the noise is determined by the data you can provide and any missing values will be interpolated. The maximum resolution is 12m supporting dense urban planning so you can have different noise levels in adjacent streets, which is common in urban canyons.

Better still, with live noise data, you get live coverage. Ideal for autonomous systems and future spectrum management systems which will need to be automated to remain relevant.

Collecting noise with DORA

DORA (Distributed Open Receiver API) is an open source project sponsored by CloudRF designed to collect noise measurements using various Software Defined Radio (SDR) receivers and mature open source utilities.

It uses consumer grade SDRs via a remote service present on the DragonOS operating system. Designed for SBCs like Raspberry Pis, DORA presents a common API for RF sensing across different radios. Nodes perform a local FFT to measure average power (with configurable bandwidth) and then publish the PSD data via an API endpoint. A server fetches and collates these to present them in an interface to provide spectrum visibility.

When a CloudRF API key is provided, the server sends data to our noise API giving a user live noise data for accurate planning. DORA’s low cost (£200 BOM per node) makes it scalable and cost effective. It won’t give you a pretty waterfall like Government spec hardware but it will provide the scale needed for autonomous spectrum management, powered by the CloudRF API.

If you do want an open source FFT and waterfall we recommend OpenWebRx.

You can contribute to the future of scalable spectrum sensing over on Github with issues, feedback and features.

Summary

This noise map feature is live now and works with any receiver capable of reporting noise as dBm. The benefit of using live noise in planning is improved accuracy but also relevance, and in time confidence, as the simulation will match the environment.

The post Mapping Noise 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.

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

The post Interference analysis appeared first on CloudRF.

While Satcom offers clear advantages in terms of speed, bandwidth, and the ability to provide real-time, high-quality data transmission, HF remains a crucial alternative where cost, independence from satellites, portability, power efficiency, and resiliency are important.

Wide area simulation

The new /hf/area API endpoint uses the proven VOACAP engine to simulate coverage for a given transmitter at a given time of day. It combines CloudRF’s familiar JSON interface structure (transmitter, antenna, receiver, environment) with VOACAP antenna patterns and temporal parameters (Month and hour).

The maximum range for the simulation is 10,000km which takes several seconds and like other (area) layers it can be exported to KMZ, GeoTIFF and SHP.

API reference: https://cloudrf.com/documentation/developer/#/Create/hf%2Farea

Link frequency prediction

The new /hf/prediction API endpoint provides a HF frequency prediction capability, powered by VOACAP, for a given link. It uses the same workflow as the path tool whereby the transmitter is placed upon the map, the path tool is selected and the receiver is placed.

The output is a chart of frequency SNR values for the link across the HF band from 2 to 20MHz and hours of the day. As ionospheric activity varies considerably between day and night, the chart helps select an optimal frequency and can be exported to PNG.

API reference: https://cloudrf.com/documentation/developer/#/Create/hf%2Fprediction

HF parameters: Time and Sunspots

Time is critical with ionospheric communications so the “model” section has been extended to include three new variables.

Diffraction is disabled and the two familiar reliability and context variables can be tuned as with other models to match empirical measurements.

Month

The month is defined as a integer from 1 to 12.

The relevance to HF is that during the summer, solar activity, and therefore refraction, is increased.

Hour

The hour is defined as an integer from 0 to 23 and is in UTC.

The relevance to HF is that during darkness, the lower “D” layer collapses so RF which was previously attenuated is free to reach the higher “E” and “F” layers which increases both noise and global reach.

Sunspot R12 number

Solar activity follows a ten year cycle which can be predicted. The year 2024 is at the peak of this cycle so the “R12” number is high at ~150. In 2030 this will be low at (~25) and equivalent HF links will be more difficult.

Solar activity is subject to random bursts of radiation (Sporadic E) which makes predicting and calibrating HF communications harder than short range terrestrial links. Using empirical live measurements from sounders and crowd sourced networks, the random element can be mitigated but not removed.

HF Antennas

HF antenna theory is a complex art form. For example, the same physical antenna will produce very different propagation depending upon its height above the ground where reflection takes place.

The reflection depth varies by terrain so a swamp has a ground level water table but a desert could have a reflection height much deeper so an antenna may not need elevating much at all to achieve a link.

This reflection height determines the “take off angle”, and skip zone, whereby a tall antenna between two tall masts has a lower take off angle, and longer range compared with a waist height antenna which has a steep angle and relatively short range for Near Vertical Incidence Skywave (NVIS), which we have a separate model for.

When selecting the HF model, you will be given a fixed list of VOACAP antenna patterns with which you can manipulate the gain, height and the azimuth. A typical gain figure for a dipole will be between 1 and 2.15dBi whereas a LPA could be 9dBi depending on elements.

Example HF API request

This simulation request is for a 10MHz half wave dipole, 8m above the ground, radiating 30W of RF power.

The month is November and the time is 8am UTC.

The sunspot R12 number is ~150 for late 2024 based on the solar cycle.

{
    "site": "Tx",
    "network": "HF",
    "transmitter": {
        "lat": "46.3936",
        "lon": "6.8835",
        "alt": "8",
        "frq": "10",
        "txw": "30",
        "bwi": "0.012"
    },
    "receiver": {
        "alt": "1",
        "rxg": "1",
        "rxs": "-125"
    },
    "antenna": {
        "txg": "2",
        "txl": "0",
        "ant": "2",
        "azi": "45"
    },
    "model": {
        "pm": "13",
        "pe": "3",
        "rel": "50",
        "month": 11,
        "hour": 8,
        "sunspots_r12": 150
    },
    "output": {
        "units": "m",
        "col": "HF.dBm",
        "out": "2",
        "nf": "-112",
        "res": "20",
        "rad": "5000",
        "bounds": {
            "north": 89,
            "east": 62.25,
            "south": 1.42,
            "west": -48.49
        }
    }
}

HF Calibration

Using crowd sourced link measurements from the amateur Weak Signal Propagation Network (WSPR), the VOACAP engine can be calibrated using our native calibration utility. Data can be filtered by station and processed ready for import to the calibration utility. The data reports Signal-to-Noise (SNR) measurements which reference an unknown noise floor. We recommend an average value of -100dBm for the 10MHz noise as any error in measurement is less than the other variables such as the variable solar radiation and distant station antenna gain for example.

The WSPR data required pre-processing to convert the 6 figure Maidenhead grid squares to WGS-84 coordinates. The maidenhead python library is recommended for this.

Filtering a time window is critical due to the propagation changes which occur throughout the day. For example, you cannot calibrate measurements from day and night together but you can calibrate an hour as a separate file.

A look ahead

Now that we have published an API, we want to integrate it into some systems. ATAK is an obvious candidate for starters but a HF radio which can see into the future or a ALE modem which doesn’t need to radiate to know it can, or cannot, communicate.

This capability will be available with the next SOOTHSAYER release.

Credits

Credit to the many VOACAP developers and maintainers over the years who have maintained this powerful capability. It is arguably one of the most senior pieces of operational software in the commercial world.

We have only put a shell on this incredible engine but hope our API will introduce a new generation of software developers and communicators to the magic of HF.

The post HF Skywave appeared first on CloudRF.

Following our most recent field testing, we have identified two significant improvements in accuracy:

The first is a new deterministic propagation model; the General Purpose model. This is a frequency agnostic curve which takes its accuracy from high quality reference data. It’s dependency on high resolution clutter sets it apart from legacy cellular models which are more complex empirical curves designed in an era of basic digital models.

The second improvement is better default clutter values which align with ITU-R P.833 recommendations, as opposed to our current light clutter values which have been retro-fitted to tune the ITM model, also designed before clutter data was widely available.

Dense clutter

When input settings are adjusted to match field measurements, the model and clutter parameters are adjusted to achieve the best match, measured by the error where a low score eg. 3dB is best. Previously, the calibration adjustments were weighted towards the model with clutter accounting for a relatively minor change.

With our new dense clutter values, we have referenced the ITU-R P.833 recommendation for vegetation values and other papers for buildings. As a result we have new, dense, clutter profiles which when combined with improved diffraction will improve accuracy.

These templates are optimised for 1GHz. Actual attenuation will vary by wavelength so you are advised to create your own if using a very short wavelength with adjusted attenuation.

CITY

Buildings are very dense (3.0dB/m), with variable heights and trees are short (8m) and light (0.4dB/m)

SUBURB

Buildings are dense (2.0dB/m), with variable heights and trees are taller (10m) and denser (0.5dB/m)

FOREST

Buildings are light (1.0dB/m), with variable heights and trees are tall (12m) and dense (0.6dB/m)

ITM model warning

There is one exception to this which is the ITM model: This is our oldest and most complex model which (uniquely) includes its own Vogler diffraction routine. The new dense clutter will not work with the ITM model which can only be used without clutter or a very light profile such as Minimal.clt.

The following table lists changes to combinations of models and clutter:

Release schedule

The updated engines and matching clutter profiles are scheduled to be published on CloudRF on Friday the 12th July 2024.

The post Model and Clutter improvements appeared first on CloudRF.

Following two years of R&D, our new 3D engine and API is live.

It uses an advanced volumetric design to simulate propagation in all directions making it more advanced than 2D engines which can only produce flat images. By design, it supports multi-path and phase tracking to model “fast fading” when signals collide making it well suited to challenging urban and subterranean environments.

Key features include:

• 3D antenna patterns
• Configurable reflections (up to 10)
• Configurable material attenuation (dB/m)
• Configurable material reflectivity (dB)
• Configurable material diffusivity (Metal v Stone)
• Multi-site support (n transmitters)
• Phase tracking for multi-path effects (Constructive and destructive multipath)
• Configurable resolution from 10cm, subject to model size

CloudRF Blender plugin

An open file standard and an Open API

We’ve chosen the growing glTF 3D standard by the Khronos Group for our input and output. It is supported by most devices, GIS software, graphics engines and 3D viewers.

You can transform LiDAR point cloud scans into a glTF mesh using a number of free packages to exploit popular formats like LAS and LAZ.

As per our open architecture and API-first design, the 3D API is available now as an open API. You will require a premium CloudRF account and an API key to use it.

With the API, you can push up a model, perform coverage analysis, and view the output using a hosted viewer supported by popular browsers.

Multi-path visualisation

Everyone talks about multi-path, the behaviour of colliding radio waves but can they visualise it? Signals schools teach students that a “little movement” will cure a dead spot. That’s good but when a little more movement puts them back in a dead spot again it doesn’t solve the real issue, current software cannot practically do multi-path.

There are expensive ray tracing solutions designed for design engineers but not operators deploying equipment, or students even who are taught to move, but don’t know where to!

In the screenshot below, a directional 5G antenna is pointed towards Tower bridge in London. Where there is line of sight on the river Thames the signal is a solid green. Where there are reflections, the signal is patchy and adjacent to the bridge there is a notable area of destructive multipath in the middle of the river. This huge dead spot is caused by strong reflections coming from the south tower of Tower Bridge. The north tower isn’t as affected due to the angle of incidence which creates a longer reflection path, and weaker reflection.

Destructive multipath in the middle of a river.

Viewer agnostic

As an open standards API our mesh output can be consumed by browsers, third party apps and AR viewers. We’ve already integrated it into a Hologram and the popular Blender 3D software and will add it to our web interface soon since we use Cesium which has supported glTF since 2014.

You can add glTF models direct into ESRI’s ArcGIS Maps SDK. Demo code is right here!

Blender plugin

Whilst developing this we used the popular Blender open source 3D platform to create obstacles and inspect output. We developed a plugin for Blender which we have open sourced so you can drive it directly from Blender. The plugin will upload your model and allow you to use it, along with CloudRF radio templates, to simulate RF coverage.

For more information on the plugin see here.

3D properties

Coordinates

Instead of a geographic projection like WGS-84, this engine uses XYZ coordinates relative to the model origin (x=0,y=0,z=0). This is better for modelling buildings in isolation like architecture designs which don’t exist!

When a building is placed upon the earth, the translation to these values should be performed by the client, such as Blender so ideally the user does not need to know what/where they are – it just looks right.

Up and Forward

Cartesian vector coordinates are more complex to express than latitude and longitude.

This is best left to the client like Blender for example. As a minimum the position is required as XYZ and for advanced usage the API allows “up” or “forward” XYZ directions to be used to express rotation. Different platforms do different things with coordinates so we have opened up our API to support as many as possible.

Materials

We’ve supported configurable clutter for years but with multi-path support we have extended support for both attenuation, reflection and diffusion. The glTF standard supports materials by standard with human readable names eg. “Wood”. You should match the materials you are using with the “Keys” section to capture variants in your model for example: “Wood”, “Oak Wood”, “Timber”.

Reflection loss

Measured in decibels, this is loss incurred by a reflection from a surface. Solid surfaces like Metal reflect most of the energy so have a low loss value of between 1 and 3 dB and softer surfaces like timber absorb more energy so have higher loss values of 3 to 6 dB.

Transmission loss

Measured in decibels per meter, this is absorption loss. These figures will be much higher than what you might have used with our other APIs since those are nominal values based on average attenuation through a house whereas these are the actual value for the material(s) (eg. brick) not the parent obstacle (a brick house).

For example; a brick house measuring 10m wide might have 2 blocking walls at 10dB each for a given UHF frequency.

With the 2D API, this would be represented as a attenuation figure of 20dB / 10m = 2dB. In the 3D API the brick wall would be the simpler 10dB!

The advantage of this is we can now model inside rooms with different materials and furniture – if you have the model…

Diffusion

Radio waves scatter when they hit a wall. The behaviour varies by the material so you can define this behaviour with the diffusion parameter. It’s a randomisation ratio from 0 to 10. At 0 there is no diffusion and you are only considering the input ray. With 0.1 a small amount of randomisation is occurring so the reflection is very predictable like a game of pool.

With 10.0 the reflections are truly random in all directions. This would be suitable for a gravel path for example.

Performance

Modelling a cube is harder than a 2D plane so this takes longer. How long depends upon your model size and resolution and reflections. Increasing reflections doesn’t add as much work as you might expect due to our efficient design but asking for 20cm resolution for an entire neighbourhood will leave you waiting for a few minutes.

Performance tips

• Start with 1m resolution and a small model
• Keep you input model minimal. If you have every pot plant in the town it will be a big mesh file and will take longer!
• Pretty photo realistic 3D tiles are pretty but take a long time to model. Go ugly early with basic models for speed.

Documentation

The swagger documentation is located here.

The blender plugin is located here.

The post 3D radio propagation API appeared first on CloudRF.