This blog explores how Counter- (C-UAS) and RADAR systems can be modelled efficiently within CloudRF to optimise siting and improve their effectiveness.

The challenge 

The methodology for operating sensors varies depending on the environment in which they are operating:

In dense urban environments, high-rise buildings reduce Line Of Sight (LOS) and block ultra high frequency signals, creating what are commonly referred to as urban canyons. An example of this effect for a poorly sited sensor at street level is shown in the screenshot below.  In such environments, reliable coverage is limited to areas where a clear Line-Of-Sight (LOS) path exists.

By contrast, in open rural environments, where terrain and structural obstructions are minimal, significantly greater and more consistent coverage is achieved using the same transmitter configuration. This comparison highlights the substantial impact that the environment has upon system performance. 

Similar challenges arise in environments where vegetation screening is present, particularly in forested and jungle regions. Dense foliage, tree canopies, and uneven terrain can significantly obstruct LOS. These factors degrade the performance of C-UAS and RADAR systems by reducing detection ranges and creating coverage gaps. As a result, system effectiveness is biased towards clearings or elevated positions where partial LOS above vegetation can be maintained.  

Operators in obstacle-dense environments are therefore required to invest significant time in identifying suitable siting locations to maximise their equipment’s performance. This can be a challenging task due to access restrictions and the time required to conduct map studies and pre-deployment reconnaissance. These activities are resource-intensive and place additional demands on system operators who may already be operating under tight time constraints. 

Time invested in developing and optimising siting locations can be quickly undermined by the introduction of new obstacles that block LOS. These obstructions may take various forms, ranging from temporary structures erected for events to newly constructed buildings. Such changes can significantly degrade system performance and necessitate reassessment and reconfiguration of established sites. 

An often-overlooked challenge across all operating environments is spectrum noise. Noise levels vary significantly between locations and fluctuate due to changing environmental and human activity. While pre-event site visits and planning can help establish baseline conditions, increased traffic during an event such as a motorsport or a music festival can raise noise levels to unprecedented levels, degrading system performance and detection reliability.  

Another challenge facing teams is whether they are looking to counter the Unmanned Aerial Vehicle (UAV) or the controller. Locating the controller can vary in complexity depending on how the drone is operating. A drone operating on the 2.4GHz ISM band may stand out against the normal radio environment due to its relatively strong and distinctive spiky FSK signal, whereas a drone operated via LTE or 5G SA will be more difficult to distinguish among dense cellular traffic. 

Terrain, buildings, vegetation, and RF noise constrain coverage, making site selection key to system effectiveness. 

The Solution 

Modelling coverage and identifying transmission sites for these systems can be done quickly and effectively using tools which are accessible to not only radio engineers but operators on CloudRF.  

The first step to using the system efficiently is to setup a template. This is how we can save our settings for systems and reference them quickly for future calculations. Templates include information about the transmission and receiving station(s), such as heights, frequencies, power, antennas and environmental factors, some of which are discussed further below.  

Making the Template 

When designing a template for a C-UAS or RADAR system, we should apply additional consideration to the following: 

Height Measurement 

We can specify the height unit to be measured as Above Ground Level (AGL) or Above Sea Level (ASL), in either metres or feet. RADAR systems looking to locate fixed wing platforms are better suited for Feet ASL, whilst UAVs which use “GPS height” reference Metres AGL as their primary height reference, especially for restrictions which are also communicated as AGL. For example, consumer drones are restricted to 120m (400ft) AGL in the UK.

Running calculations in ASL is recommended for experienced users of CloudRF. When the transmitter location is changed, the height will need to be adjusted to consider the ground beneath. If not adjusted correctly, transmitters and receivers can be placed underground by accident resulting in an error.

 Use AGL for UAV operations and ASL for high-altitude RADAR targets to match the domain/system altitude references. 

Model  

When designing a template for a RADAR system, the dedicated RADAR model should be used. This model is more that just line of sight as it uses a Radar Cross Section (RCS) value, allowing operators to define the size of targets they intend to detect where a drone has a smaller RCS (0.04) than a plane ( 6.0 ) which limits it’s detection range compared with a plane. By configuring appropriate RCS values, the model can more accurately represent real-world detection performance. 

For a counter-UAS (C-UAS) system, the recommended model is ITU-R P.1812 with an average context, 50% reliability and diffraction turned off. This combination of model and diffraction will simulate the high frequencies and line-of-sight coverage utilised by C-UAS systems and has been proven to be the most accurate model during our model testing.

Use the RADAR model with RCS values of 0.05 for air-surveillance and ITU-R P.1812 (diffraction off) for UHF C-UAS sensors. 

Environment 

Obstacles affecting system coverage can be configured within CloudRF through the Environment submenu. 

CloudRF provides access to extensive global clutter datasets, including 10m land cover, 2m building data, and, in selected regions, 2m LiDAR and tree canopy height data.  

An interactive map showing the availability of this data can be accessed at the following link – https://api.cloudrf.com/API/terrain 

SOOTHSAYER^TM users can import their own LiDAR in addition to CloudRFs DEM archive. 

For added accuracy, obstacle attenuation can be fine-tuned using clutter profiles, allowing operators to accurately represent real-world conditions. This level of customisation enables precise coverage predictions and improves confidence in system performance assessments especially at lower frequencies where NLOS attenuation needs to be considered as well as LOS.

To deal with temporary or new obstacles not currently in the DEM dataset, users can enable the ‘My Obstacles’ feature to manually draw or upload a KMZ/Geojson of the obstacle(s) to be included in the coverage prediction. 

Noise 

Noise is often an overlooked factor in radio network planning, yet its impact on coverage and performance is significant. By incorporating measured or simulated noise data, the planning environment will more accurately replicate real-world radio conditions.

This enables operators to reflect variations in the operating environment whether accounting for daily commuter traffic patterns or preparing for large-scale events such as concerts and sporting fixtures, where spectrum density and interference levels both increase substantially.  

Noise is a factor within the template’s environment block. This value can either be manually entered eg. -100dBm or referenced from an uploaded dataset from multiple locations, creating a visible noise layer on the map.  

Live noise can also be simulated in calculations by using networked SDRs. We have published an example capability here: https://github.com/Cloud-RF/DORA 

Our recommended default settings are for Landcover and Buildings to be ON with the Temperate clutter profile which represents dense trees. 

If you do not know the noise figure at your receiver, enter -100dBm which is typical of the ISM 2.4GHz band but will vary widely by location. Noise is measured across a channel so should be measured with the appropriate bandwidth. Johnson-Nyquist theory means (channel) noise increases with bandwidth and to a lesser extent, temperature.

Tools & Features 

Once we have created a system template, we can use it with a number of tools to identify a transmission site and then determine the effective coverage from that location. 

Best Site Analysis (BSA) 

BSA is a powerful search tool designed to identify optimal transmitter placement locations defined by a geographical area. It performs hundreds of tests rapidly with a GPU in an area using a full propagation model with transmitter parameters. Positions are graded and then ranked to present the results as a heatmap image.

“The examples used in this document have been generated using KMZ and GeoJSON files. These can be imported into the User Interface (UI) via the Import Menu – Best Site Analysis. This is our recommended way to use the tool, as the simulation can be re-run with the same defined area and speed up the process when comparing a variety of height levels. There are numerous ways of doing this. Numerous software packages can do this; KMZ files can be created in Google Earth, and GeoJSON files can be created via geojson.io” 

BSA is particularly valuable for identifying viable transmitter sites that may be overlooked through traditional planning methods such as “walking the ground” for example. By automating complex visibility analysis, users obtain actionable results within minutes, significantly reducing the time and effort associated with manual studies. 

The recommended locations require interpretation. For example, if you are working with a DSM LiDAR model which contains water, this may be ranked as an efficient site. An operator will likely discount this, but that doesn’t mean that an adversary will as launching a drone from a boat is effective.

BSA ranks the most effective transmitter locations within an area using inter-visibility scoring. 

Area Calculation 

Once suitable candidate sites have been located, we can use the Area endpoint via the UI or API to see the coverage of our system at various heights. The heights chosen for the receiver will depend on the asset that we are looking to target with the C-UAS or radar system, for example 100m AGL.

The heatmaps created by the Area endpoint show the coverage of the transmitter to the receiver using the settings prescribed in the template. Heatmaps are useful for identifying areas with and without coverage and can assist in the decision-making process for the deployment of additional assets to further enhance coverage.  

 Area calculations can show coverage from a candidate site and expose gaps and shadowed airspace. 

Best Server 

Best Server is a feature which can be used with an established network. The Best Server tool will check each node for coverage to the designated receiver location. This allows the coverage from a large network of radios to be checked at various heights quickly, a common requirement when planning C-UAS, Radar or any Ground-To-Air transmission. 

 Best Server identifies which network nodes can affect a target at a given height and location. 

Case Study 1 – C-UAS Site Selection – Texas, USA 

Difficulty: Easy 

This case study evaluates optimal C-UAS siting and coverage performance in the vicinity of a major sports stadium in Arlington, Texas. 

Inputs 

• C-UAS template 

• Defined area of interest 

Process 

• Best Site Analysis to generate and score candidate locations 

Outputs 

• Coverage heatmaps per site (multi-height Area analysis) 

• Identification of coverage gaps and shadowed regions 

Decisions 

• Select primary deployment site(s) 

• Position additional systems for full airspace coverage 

The system represented by the template in this simulation is an omnidirectional C-UAS system, operating at 2.4GHz, with a 3m tall antenna. For the initial survey, the receiver height is set to 150m AGL, this can be reduced for more in-depth planning throughout the planning process.   

The model used for this survey is ITU-R P.1812, with diffraction turned off. Within the city of Arlington, there is 2m LiDAR available, which has been selected by setting the Environment to Surface/DSM (LiDAR), and a resolution of 2m.  

With the template for the C-UAS created, Best Site Analysis can now be used to identify optimal locations for siting the system.  

After defining the desired area of coverage, we are presented with a layer with sites scored according to their intervisibility.  

Using the slider to filter out lower-scoring positions, areas with higher intervisibility can be highlighted on the map. 

Based on the analysis, the highest-scoring sites were located on the roof of the stadium and towards the car parks on the South side of the stadium.  

“For best practice, we recommend evaluating numerous positions. In the above example, the centre of the stadium is the optimal position. However, it is not in a practical sense, i.e. is the stadium roof safe? Other considerations could include access rights, sustainment and logistical requirements.” 

With these positions identified, the Area endpoint can be used to evaluate the coverage.  

Setting the receiver at a height of 150m AGL, there is good coverage within a 5km radius of the transmitter. The weakest areas of coverage are directly overhead of the transmitter, where the null of the dipole has the lowest gain.  

UAVs can operate at different heights so coverage should be evaluated at a variety of receiver heights within the local threat capability. For the next simulation, the height of the receiver is set to 10m AGL. 

The coverage of the C-UAS system is now reduced. Obstacles in the environment, including buildings and trees, have a greater effect on the signal, blocking the line of sight and reducing overall coverage.  

A particular point of focus is the area directly around the transmitter. Due to the curvature of the roof and the relative height of the building compared to the ground, positioning the C-UAS system on the roof creates shadows around 400m away from the stadium, where there is no coverage. 

One chain of thought for solving this issue could be to position the transmitter on the side of the stadium. By changing position and re-running the simulation, there is an improvement in coverage to the South of the stadium, but now the stadium is blocking a large majority of the signal to the North, requiring the deployment of further systems to provide coverage in the area required. 

Having multiple sensors improves system resilience to failure or interference and improves detection.

Alternate locations identified during the initial Best Site Analysis can also be assessed for deployment of the C-UAS system. For example, positioning the transmitter in the car park to the south of the stadium allows us to save a site template and quickly generate 3D airspace coverage using the 3D-Airspace script. This enables rapid visualisation of coverage performance at multiple altitudes. 

This script will create a KMZ showing multiple layers based on the height of the receiver. In this case, with an upper ceiling of 150m, the script will create layers every fifteen meters. 

The script using these requests is available via https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/python/3d-airspace. 

From this analysis, there is greater coverage of the southern side of the stadium, previously in the shadow of the C-UAS site on the rooftop. The stadium itself is still acting as a major obstacle; the deployment of multiple systems would be required to cover the entire stadium area.  

Adding multiple systems into this network and creating a single layer to demonstrate coverage is possible by using the Superlayer tool, allowing commanders and operators to get a clear overview of sensor coverage.  

The Best Server tool can also be used to evaluate a network of C-UAS systems. Using the established network, a UAV can then be added into the simulation, flying at a height of  25m in the example below. This can then show us which C-UAS would be able to have an effect on the UAV. In the example below, the UAV at 25m AGL has a link to the C-UAS systems in the northern area, whilst the systems deployed on the rooftop and in the southern car park are being blocked by obstacles. 

BSA identifies viable deployment positions, and multi-height Area analysis shows where additional systems are required for full stadium coverage. Best Server can be used to quickly identify coverage from selected positions to a central receiver.

Case Study 2 – Finding the Operator – Dartmoor, UK 

Difficulty: Moderate 

CloudRF can be used for simulating both transmitters and receivers in a real-world environment. In this case study the template and tools used will show how the simulation results can be interpreted to understand where the ground control station (GCS) could possibly be located. 

Inputs 

• DF sensor template 

• Sensor height and frequency 

• Line of Bearing (LOB) 

• Measured received power 

Process 

• Path-loss calculation using DF-derived constraints 

Outputs 

• Probable GCS transmitter locations 

• dB error score per location 

Decisions 

• Prioritise ground search locations 

• Assess the control range of the UAV 

DF sensors are essential for a C-UAS team in order to locate both the UAV and the corresponding control station. These systems can come in a variety of formats and may use various methods to determine a Line Of Bearing (LOB) to the transmitter.  

Direction Finding (DF) sensors are typically deployed in multiples to generate several Lines of Bearing (LOBs), enabling triangulation and the establishment of a Position Fix (PF) at the point of intersection. However, this represents an ideal scenario. In practice, operational constraints such as logistics, network limitations, and manpower availability may restrict deployment to a single asset, significantly reducing geo-location accuracy. 

In the following example, CloudRF’s API is being used to help a C-UAS team with a single DF system to identify possible locations of a UAS ground control station (GCS). 

 The methodology for doing this is not dissimilar from the standard way of using the software, with the user creating a template for the asset they are looking to locate. For this example, the height of the DF system was set to 8m, and the ground control station was set to 2m.  Measured units are changed to Path Loss which shows possible signal coverage irrespective of power levels and is recommended when working with unknown power levels or receivers.

By filtering the results of this simulation through parameters collected by the DF system, such as the LOB and received power of the signal, possible transmit sites can be identified on the map, scored with colours representing error in dB.

This result can provide operators with a greater understanding of where a rogue transmitter could be located with just one DF system, increasing the efficiency of a single team. For more on this concept see our DF blog.

 In the screenshot below, a single LOB has been used to evaluate a large area to determine several possible sites. False positives in nearby dead ground are expected which can be quickly discounted using other sources of information.

Once a location has been identified, operators can use the Area endpoint to evaluate the coverage of this transmitter to determine the threat range of the UAS. This can be done within the UI as demonstrated in the screenshot below. 

For evaluating the coverage of the ground station at various altitudes, a 3d-airspace script can be used to recursively model coverage efficiently at ascending heights.

 A single DF sensor combined with path-loss modelling significantly reduces a large search area.

Integrating AI 

An open architecture with published documentation and examples enables Large Language Models (LLMs) to quickly build custom interfaces and tools to leverage the Open API.

Here is an example sensor placement interface built with Claude, which exploits the new Multilink API to show coverage for a UAS. The tool uses pre-defined templates, so it requires no RF engineering skill or training to move the sensors to achieve coverage with high confidence.

Live demo link: https://cloud-rf.github.io/CloudRF-API-clients/slippy-maps/leaflet-drone-detection.html

Conclusion 

Pre-deployment planning for C-UAS and RADAR systems is resource intensive and traditionally required expert input.

By standardising system parameters in reusable templates and using efficient analysis tools powered by open APIs, modern operators can model entire networks quickly and accurately without compromising quality. 

Optimal locations are not always the most obvious or the most practical. A single system rarely provides complete protection in complex environments so a layered, networked approach, validated through high resolution simulation, enables continuous airspace coverage and ensures that assets are positioned for maximum effect. 

The post Optimising drone detection with RF simulation appeared first on CloudRF.

Citizen Band Radio Service (CBRS) has exploded in popularity in the US since 2020 when the FCC allocated 150MHz of bandwidth from 3550 to 3700MHz for public use.

Keen to exploit this opportunity, businesses have marketed compatible LTE (4G) cellular equipment which some like Helium have chosen to label 5G. Unless it’s transmitting a 5G-NR waveform it’s not strictly “5G” but as it shares common components and small cell architecture its plausible and lucrative, to brand it such and most VCs aren’t experienced enough to understand the difference. Whether it’s morally or legally right will likely be determined in the next year with a test case.

One of the market leaders is Chinese firm, Baicells, who like any radio manufacturer have a public listing of FCC approve LTE base stations. This listing includes details needed to precisely model the propagation for these LTE base stations.

FCC has two tiers of power for these private eNodeBs: Category A which is the most conservative at only 1 Watt / 30dBm of power (EIRP) and 10MHz of bandwidth and Category B which offers a generous 50 Watts / 47dBm and 10Mhz of bandwidth.

Baicells Nova846 8x5W eNodeB

This unit supports both FCC power categories and LTE bands 41 and 48 making it popular in the US market. Using the datasheets here we’ve modelled it in an urban environment in New York City.

For comparison, we’ve run each model twice with Cat A and Cat B power limits and 10MHz of bandwidth. Adding a high gain antenna would indeed increase the range but the total Effective Isotropic Radiated Power (EIRP) of the combined system cannot exceed the category limit. To do so would not only be in violation of your CBRS licence but would be illegal.

Spectrum monitoring of the CBRS band is routinely conducted and with the magic of Physics, violators can be passively detected and rapidly geo-located. The largest customer for geo-location market leader CRFS is the US Federal Government.

The eNodeB was 3m above the ground/roof and the receiver was 1m from the ground with 1dBi gain and a threshold of -120dBm RSRP – the limit for LTE.

The model used was the Irregular Terrain Model with a reliability of 99% to account for the increased urban noise.

The Received Signal Received Power colour key measured from -80 (Strong signal) to -120 (LTE limit) RSRP dBm.

On the street – Cat A

With Cat A limits the effective range observed was a modest 200 to 300m where there was line of sight. Little better than a domestic WiFi router due to the high path loss present at 3700MHz. Where buildings were obstructing the signal, no coverage was achieved due to their attenuation of the low power signal.

This modelling is more optimistic than the 100m field measurements conducted on live cells in NYC but more conservative than the 1km hexagons found on Helium explorer.

On the roof – Cat A and B

Taking the same 3m mast to a rooftop bar nearby on Broadway to impress VCs we improve the range by up to 100% as expected but also lose local coverage down on the street due to the urban canyons. We’re still below 400m effective range in most directions.

Cranking the power up to the full 5W makes very little difference if you don’t have line of sight. We’ve improved signal at the places we could already reach but are unable to penetrate new locations. We’re still below 400m effective range in most directions. Some distant rooftops at 600m are touched.

A skyscraper?

Finally we placed the eNodeB on the Empire State Building at 400m above the city with 10 watts(!) of power. The range was then measured in kilometers but not many. The effective coverage was 2-3km and then only to rooftops – not at street level.

Summary

• Line of sight is critical for CBRS.
• Cat A several meters from the ground could get you 300m – if you have line of sight
• Cat B on a rooftop can get you 600m
• A skyscraper can get you 3km only

The post CBRS small cell propagation appeared first on CloudRF.

Key to it’s success is a permissive software license, APIs and a design focused on information standards.

2023 Q2 update: We have a ATAK plugin:

Read this waffle if you want but if you just want a capability on ATAK, get the plugin here:

https://cloudrf.com/atak-plugin

Background: Too many maps

Historically defence procurement has failed to differentiate between standards (eg. KML) and software (eg. Google Earth) resulting in many duplicate apps, especially multi-source maps solving the shortcomings of the previous multi-source map, which is the military implementation of the famous too-many-standards XKCD sketch. The revolving door of senior officers into defence companies didn’t help the situation. This reached a fever pitch during operations in Afghanistan 2006-2014 where at one point, every service, nation and prime contractor were plugging their own “multi-source” map, all of which were trying to solve the same problem, and all of which compounded it. Analysts were motivated to write glue-ware to achieve interoperability, typically with visual basic due to the locked down environment.

In our experience, the enduring military map was none of the above, it was good old Google Earth which could be found at all command levels due to its simplicity and assured interoperability via KML and HTML standards.

ATAK has disrupted a long established pattern of short sighted procurement of incompatible point solutions – which was long overdue and best of all, the IPR is not owned and controlled by a single contractor.

The TAK plugin industry

TAK is produced and owned by the US Government. Despite most of the client source code being available on the Play store and elsewhere a documented SDK for plugin developers, plugins require US Government approval. This approval is more than a bureaucratic hurdle, it is a security, technical and cryptographic approval which requires a code-review and a code signing certificate. There are a limited number of public domain signed plugins and a greater number of private plugins.

Given the cultural change of not just using open source in defence, but publishing and maintaining it, on public app stores it was inevitable there would be a catch to appease committees.

To get US Government approval requires a sponsor aka a contract. There are many firms large and small developing TAK plugins (typically with Java or Kotlin) under contract, including foreign nations under trade agreements. Whilst Android app development might sound a little 2010 (CloudRF started as a Android app in 2011) it’s made lucrative by the exclusivity of needing a Government sponsor – to publish at least.

2010 called, they want Java back..

Java has had its day in our opinion. It created a generation of software developers who exist in a (JVM) bubble of abstraction far away from the processor for whom an opcode is an alien concept and writing a Hello world! demo on a vanilla machine requires a disproportionate amount of IDE massaging and preparation. The effort used to be justifiable because of the security the Java sandbox brings. The recent log4j CVE undid that argument pretty well.

We used Java 10 years ago to make our debut app “RFSignal” during the app gold rush of 2011 along with the Android SDK. It worked well for the first few releases whilst the app was under active development but the cracks showed when the app transitioned to maintenance. We found the “Eclipse” dev environment itself to be a substantial burden and even small one-line changes required an inordinate amount of effort in many places compared with other languages like Python, PHP or C++. Back then Android was evolving rapidly and keeping up with the latest SDK was a task in itself so we were glad to retire the app in 2015 and move to a SaaS model (and not give Google 30% of our sales).

We vowed no more Java, and to date have kept our promise except we did reference 1 line from the old app relating to a PNG hack to achieve Android bitmap opacity which was funny – ten years later.

To be clear we’re not criticising ATAK plugins written in Java – there is a clear need or them, especially interfaces to hardware which is a great value-add for manufacturers. We are proposing a more agile plugin architecture based around standard and network APIs which doesn’t prescribe a programming language – or even an OS.

ATAK source code: https://github.com/deptofdefense/AndroidTacticalAssaultKit-CIV

Standards to the rescue

We came late to ATAK in late 2020 but were no strangers to information standards, reverse engineering and joining distinct systems, at no extra cost, which our founder had previously won a national award for in 2012.

We already had a Google Earth layer (written in PHP) which relied heavily on the KML standard to connect CloudRF to Google Earth. We attempted the same on ATAK 4.1 without success due to limited KML GroundOverlay support back then. We could load on some layer types with a 10 second minimum refresh but advanced network features such as KML’s view based Link were not implemented. We use this feature to fetch the viewer’s bounding box, and center point, in our Google Earth KML interface.

During our research we learnt about the Cursor-on-Target (CoT) XML schema and how it was implemented within ATAK’s Geochat functionality. This allowed us to close the loop and handle a chat message from a client at our own TAK server – without touching Java!! Being able to connect the client to our own server was significant, and exciting, as this is where we could house, and maintain, our code instead of a version-brittle plugin.

An open source TAK server….with a Python bot

Realising we needed a TAK server capable of talking CoT we headed to Github and found two open source projects, FreeTakServer and Taky, both written in Python. We tried both and selected the simpler Taky server which offered a minimal setup necessary for 2 way communication.

You can find an early ATAK capability we published for OSGB coordinates conversion bot over here.

One of the nice features about SaaS models is licensing. You can connect software modules via a common protocol with different licenses. This is why we open sourced our server modifications but kept our Python bot private. You can get a head-start for how to build a bot with our open source geobot.

We extended taky and added some features relating to client authentication, access control, anonymity and CoT. The CoT modification is notable as it extends the namespace (which is permitted in the XML standard) to tag anonymous messages with the originator’s unique ID. These modified messages are exchanged between the chatbot and the server when sharing shapes and are redundant for regular C2 use.

UPDATE: We no longer use Taky since OG TAK server was published!

‘Follow-me’ demo

This early demo was created with a GPS spoofer (visible in corner). When the position updates, ATAK sends a broadcast which our TAKY server receives. The python bot at the server forwards this to the API and a creates a KML layer – a standard feature in CloudRF. On ATAK, a network KML layer pulls back the KML on a periodic cycle which is why it is slow to catch up when the marker moves fast. We have since identified a mechanism to return a KMZ immediately using a data package.

SSL, HTTPS and Data packages

Achieving insecure communication was quick: We published a demo of a CoT + KML script which did this in Nov 2020. Achieving secure communication with TLS certificates, which worked on ATAK and for HTTPS was a different matter and required lots of debugging. A lot of time was spent resolving seemingly trivial issues but the key principle we found which unlocked a lot of happenings was adding the right SAN (SubjectAltName) to our web server certificates.

SAN is used as an optional field in SSL certificates to declare alternative names or IP addresses, and is checked by Android’s SSL client. The open source TAK servers would wrap a script called ROTC.py to generate certificates (without SAN) using a self-signed certificate authority (CA) which despite the manageable security risk involved works well for securing the ATAK server – and even mutual authentication which we have implemented.

When ATAK later makes a request to a HTTPS link to fetch a data package for example, it checks the certificate for a SAN which a third party certificate from a trusted CA typically has. This tiny little attribute is worth big money as they can add lots in an array and call it a “wildcard” certificate. Thankfully LetsEncrypt is disrupting this monopoly.

Data packages are zip archives used in TAK to share files. They require a manifest file and a simple folder structure. When a CoT message is delivered to a End User Device (EUD) describing a data package it will fetch it, unpack it and auto-parse the content. We return KMZ files but you can also return XML map files to add map sources for example.

Self hosted solution?

We have a turnkey server with the CloudRF API, OSM tile server and ATAK interface called SOOTHSAYER. It’s ideal for rescue organisations and first responders who might otherwise be running multiple network services or working areas without internet access.

UPDATE: WE NOW HAVE A PLUGIN

After all this, we went and made a plugin anyway:

https://cloudrf.com/atak-plugin

The post How not to write a TAK plugin appeared first on CloudRF.

Embed code

The easiest way to add a map to your website or blog is with the embed code function. This is a small code (HTML) snippet which you paste into your website, like WordPress, for example. It requires that your blog supports HTML content.

To use this first you must have a layer in your archive. This could be a single area calculation or a large network mesh created from lots of individual calculations. Select it and click the code icon.

You will then be shown your embed code and a notice.

Google Maps Key

The notice says “Replace ‘GOOGLEMAPSKEY’ with your Google Maps key“. This is necessary as you need a key to share an online map as it’s licensed, not a free-for-all. You can get a key at no cost from Google if you visit this link:

https://developers.google.com/maps/documentation/javascript/get-api-key

To test your key works visit a HTML online editor, paste in your embed code and replace GOOGLEMAPSKEY with your long random Google Maps key. If successful you will see your map and your embed code is ready to go on your website!

Self-hosted (Expert mode)

The downside to embed code is the layer must be fetched from a server from Europe. For most users this won’t be a problem but if you are in Australia and your layer is quite large this could result in a blank map for a second or two – not a great advert if you are a business.

To deliver a faster map to your local customers, host the layer yourself. To do this, take the previously described embed code and extract the long link starting https://api.cloudrf.com/…

Paste that into a browser to visit the page directly then view the source code. Here you will find a link to a .png image in your archive as well as the necessary Google Maps Javascript.

Copy that code to your own website and download the PNG image. Upload the PNG image to your server and edit the link so it points to the local copy eg. yourcompany.com/files/yourlayer.png

Copy the code between the html tags.

Terms and attribution

You can host as many of these maps as you like for no extra cost but unless you have written permission, attribution is required. This is already included as a small link on the map but we won’t object if you want to add your own label too.

We will host your data so long as your account is in credit. If your account is not in credit we will retain the data as per the plan limit which is two years in most cases.

If you need your image to be available for lots of website visitors or for longer than 2 years, we strongly recommend self-hosting your PNG layers.

The post Hosting your own network map appeared first on CloudRF.

This long awaited update brings an OpenAPI 3.0 compliant REST implementation with a redesign of public facing architecture so all requests will go to https://api.cloudrf.com and documentation will be at https://docs.cloudrf.com

Human readable requests

The old API grew into an exhaustive list of +43 variables starting from only 10 when it was an Android app. That’s just the public ones. There’s more parameters relating to interfaces. We were adding about a dozen variables a year in the early years of the service and turned down many requests for protocol-specific parameters to keep the number manageable and keep the API signal and technology agnostic.

The new JSON body schema tidies these +40 variables into logical objects which not only align with the interface but can be dropped completely for example in the case of the optional environment object, and defaults used.

New endpoints

The CloudRF API is now at api.cloudrf.com

Documentation is at https://cloudrf.com/documentation/developer/

We’ve got OpenAPI / Swagger documentation at https://cloudrf.com/documentation/developer/

Legacy ../API/ endpoints and old API documentation are still active and will be until October 2021.

New functions

Some previously undocumented interface features are now in the new API. These are exporting user files into GIS formats and uploading GeoJSON features as private clutter. These are now documented in API2.0

New authentication

The days of sending your unique identifier ‘uid’ and your API key in the HTTP request as uid=…key=… and then scrubbing them out of presentations are thankfully finished!!!

Now you have one API key which you must put into a HTTP ‘key’ header. This keeps your sensitive credentials separate from your body which contains site parameters. This also means the path to offline JSON templates is now clear. We’ve offered templates for years but as rows in a private database, now that the private bits are out of the way you can confidently share an API request.

JSON site templates

A nice feature about this new API is because the sensitive authentication parameters have been removed, and the entire site/antenna/environment exists as a single JSON object, you can take this away and share it, save it, reuse it, publish it. We’re going to build on this concept to offer a new style of template system so as well as saving your settings for quick reuse as you can now, you can share your settings.

This will also enable novice API users to create valid requests by fetching a template eg. “VHF radio.json” from the library and dropping it into an API client, along with their ‘key’ to run that template through their account.

Legacy API sunset 1st October 2021

The legacy API will still run in parallel and will be retired on the 1st October 2021. Please move your projects over to the new API soon and see our documentation and client code examples on Postman to do this.

We are publishing more application specific examples to assist with this and will be on hand to help customers migrate.

The post API 2.0 appeared first on CloudRF.