The Nimble is a tightly integrated radio solution for autonomous robots and unmanned systems. It leverages Doodle Labs’ industrial long-range transceivers and runs the Mesh Rider Lite (MRL) operating system on the robot’s CPU. Mesh Rider Lite includes customized drivers and software, which includes optimized configuration and our proprietary interference avoidance solution, Sense. This optimizes the radio for robotics and unmanned systems use cases and provides compatibility with other Mesh Rider products.
One of the benefits of using MRL is that it is designed to run on a separate, supported computer platform. This approach makes the radio more adaptable and cost-effective as it allows users to take advantage of existing systems, rather than requiring them to adopt Doodle Labs' full-stack Mesh Rider products.
Anti-jamming/Interference Avoidance: The Nimble Radio incorporates Doodle Labs' Sense technology to detect and mitigate interference, enhancing link reliability in congested RF environments. This is particularly beneficial in the 2.4 GHz and 5 GHz bands, where it supports a total of 717 MHz spectrum and 140 non-overlapping channels.
Mesh Rider Radio Ecosystem Compatibility: Nimble seamlessly integrates with other Mesh Rider Radios, including the Nano, Mini, OEM, and Wearable models, promoting network scalability and ease of deployment.
Ultra-Low Latency (URLLC): The URLLC feature segregates video data from the command-and-control signal, ensuring low-latency video streaming, a crucial aspect for real-time applications like drone piloting.
Fast Roaming Networking: This feature enables the Nimble Radio to automatically adapt to changes in network topology, maintaining continuous connectivity in complex environments.
Extended Range & Coverage: Optimized modulation and coding schemes enhance range and connectivity, offering field-proven communication distances of up to 10km.
Host Platform Integration: The Nimble radio is designed to operate with an external host computer, providing flexibility in system design and enabling the use of readily available processing units
Compact Size: The Nimble radio's design prioritizes a small form factor, making it suitable for integration into size-constrained drone platforms
Unmanned Vehicles: Its compact size and resilient communication capabilities make it ideal for drones, UAVs, UGVs, and USVs.
Industrial IoT and Critical Infrastructure: The radio provides reliable connectivity for industrial automation and monitoring systems, ensuring seamless data transmission in demanding environments.
Rugged Military-Grade Applications: The Nimble Radio is built to withstand harsh environments and is compliant with MIL-STD-202G, making it suitable for military-grade applications.
HD Video Surveillance: The radio supports high-throughput data transmission, enabling reliable streaming of high-definition video, even in congested environments.
Autonomous Systems: Its low SWaP characteristics, long-range connectivity, and interference avoidance capabilities cater to the needs of autonomous systems requiring reliable and efficient communication.
The block diagram below shows how the Nimble Transceiver integrates with a single board computer via the PCIe Mini interface.
For an example of how a real system might look, the picture below features the Nimble Evaluation Kit. It consists of UP2 V2 single-board computer (x86) running the Linux distro, Ubuntu. In this evaluation kit a M.2 Key E to mPCIe adapter is used since the compute board did not have a mPCIe port.
The example above has MMCX antenna ports. Nimble has two different hardware connector options for the antenna port adapters, MMCX and U.FL to accommodate a wide range of antenna options.
The Nimble transceiver supports the following modes: AP, Client, and Ad hoc modes for Access Point, PtP, PtmP, and Mesh networks.
One of the two main networking layouts we expect Nimble to operate as is Nimble as Access Point and Client, the photo below is an example of such a layout. The Nimble radio is integrated into a ground control station and acts as an Access Point. The drones are each integrated with a Nimble radio and are configured to be clients.
The other networking layout we expect is for customers to use Nimble in Mesh Rider interoperability mode. This allows Nimble to function as either WDS AP or WDS Client. The Mesh Rider radio must also be configured to operate in the appropriate WDS AP or Client mode. Here is a possible network setup possible with Nimble and Mesh Rider.
The Nimble software solution consists of both kernel space driver and user space applications and libraries packaged into multiple .deb Debian packages. The kernel driver packages for 802.11n are coupled to a specific version of the Linux kernel and is built for x86_64. Below is the list of the software packages in the Nimble Software installation bundle and their use/purpose.
|
File Name |
Description |
|
nimble_config.tar |
Nimble Software Configuration Utility. CLI interface to configure Nimble/Hostapd/wpa_supplicant AP and STA device |
|
nimble_installer.tar |
CLI utility to install and configure binaries, libraries and dependency services of Nimble including acs_multiband. |
|
hostap_0.0-1_amd64.deb |
Provides customized hostapd, hostapd_cli, wpa_supplicant and wpa_cli |
|
iw_5.19-1_amd64.deb |
Provides customized iw utility and dependent libraries |
|
backports-6.5.0-41-generic_6.6.15-1+6.5.0-41.41~22.04.2_amd64.deb |
Provides customized ath9k driver (Kernel version specific) for DoodleLabs 802.11n transceiver. |
The Nimble configuration utility is provided to help users with the most common wireless and networking configurations. To configure the Nimble transceiver, navigate to the nimble_config folder /Nimble/nimble_config/then run the nimble_config shell script as root.
sudo ./nimble_config.sh
The menu items that are available depend on whether you installed the radio in AP or STA (Client) mode. The basic menu structure is as follows:
AP Mode
Wireless AP config
Update SSID
Update Password
Channel and bandwidth
Optimize for P2P
Enable/Disable Hostapd (1/0)
Traffic Prioritization config
Display Rules
Add Rule
Delete Rule
Sense config
Update ACS list
License check
Enable/Disable Sense
IP Address config
Enable/Disable DHCP Server
DHCP server config
Set static IP
Enable/Disable Mesh Rider interoperability in AP
Enable/Disable Mesh Rider interoperability (0/1)
Client Mode
Wireless STA config
Update SSID
Update Password
Update chanbw
Enable/Disable wpasupplicant (1/0)
Traffic prioritization config
Display Rules
Add Rule
Delete Rule
Sense config
Update ACS list
License check
Enable/Disable Sense
IP Address Config
Set Static IP
Enable dynamic IP
Enable/Disable Mesh Rider interoperability in STA
Enable/Disable Mesh Rider interoperability (0/1)
Note: Any changes made in the configuration using nimble_config will be reflected only after ‘exit’ option of that submenu is selected and returned to the parent menu.
A setting of note in the Nimble Configuration Interface is “Optimize for P2P”. Enabling this optimizes the performance for P2P networks and is recommended for P2P UAV applications.
The “Optimize for P2P” setting is only available for the AP node, to access it go to Wireless AP Config (1) -> Optimize for P2P (4) as shown below
The default mode on Nimble is with Mesh Rider Radio interoperability disabled, and it acts as a normal AP/Client. To achieve the Mesh Rider <-> Nimble network architecture as illustrated in the 2nd network diagram above, Mesh Rider interoperability must be enabled using the Nimble Configuration script nimble_config.sh mentioned earlier.
For compatibility with Nimble we recommend Mesh Rider Radios wishing to peer with Nimble to run firmware version 2024-10.0 or newer. This firmware has the internal VLAN partitioning for Sense is disabled by default for compatibility with Nimble.
This will allow the Nimble radio to connect with Mesh Rider radios in WDS AP/Client mode. The Mesh Rider radio also needs to be configured in WDS mode for Nimble to connect. This can be set in the Mesh Rider GUI, inside of the Simple Config page go to ‘Configuration for Mesh Rider Radio’ then ‘Select Scenario’ -> ‘WDS Client on radio0’ or ‘WDS AccessPoint on radio0’. This is highlighted below.
Note: On C-band OEM models such as the RM-5500, radio1 is the MeshRider radio and not radio0 like above.
If Mesh Rider is set as the WDS AP, please note that there are channels and bandwidths that Nimble does not support so a link will not be achievable.
In the 2.4 GHz band, these are the supported frequencies for 2.4 GHz band Mesh Rider radio.
Using the iw list command with the single board computer and Nimble we can see below that Nimble only supports channels 1 to 11 so ensure that when Mesh Rider is the WDS AP, limit the channel usage from 1 to 11.
The supported bandwidths for Mesh Rider is listed below. Nimble currently only supports 5, 10, 20, 40 MHz. (Note: 40MHz bandwidth is not supported when used with Sense) It is imperative to ensure that when Mesh Rider is acting as WDS AP to choose a supported Nimble bandwidth.
Also ensure the SSID, PSK between Nimble and Mesh Rider match.
Traffic prioritization works by filtering packets based on their network port and placing them in one of four different queues - best effort (CS3), command/control and voice (CS6), video (CS5), and background (CS2).
The default traffic prioritization rules are shown below and match the Mesh Rider defaults. Port 2000 is typically for UART and port 14550 is typically for MAVLink.
The example below shows how you can add a traffic prioritization rule for UDP traffic on port 5201 to the “best effort” queue.
We recommend using UDP transport for Command & Control as it does not establish a connection between the server and client. In the event that the drone moves in and out of range, a TCP connection will experience higher latency and significantly higher reconnection time should the connection break.
In both AP and Client modes, the user can enable either a static IP address, or DHCP. In AP mode, the machine acts as a DHCP server while in Client mode, it is a DHCP client.
You can switch modes between AP and Client at any time by re-running the nimble_installer.sh script in the appropriate mode. After which, you need to reboot the devices and re-run nimble_config.sh.
The Nimble software uses a messaging system so that radios in the network can quickly switch from one channel and bandwidth to another. The channels must be in the same band. The syntax is
/usr/sbin/acs_switch.sh manual <channel> <chan_bw>
Where <channel> is the new operating channel, and <chan_bw> is the new channel bandwidth.
Note that if Sense is not running, then it is not advisable to switch the channel bandwidth during a mission or in any actual deployment. If the message is lost for whatever reason, the link will need to be recovered manually.
The Sense protocol monitors the link between two radios and automatically switches to a new channel in the ACS list when it is noisy which you might see with interference. Additionally, if the link is lost as in the case of jamming, the link is automatically recovered.
Sense only supports P2P networks at this time. Sense on Nimble is also compatible with Mesh Rider when Mesh Rider interoperability mode is engaged and the Mesh Rider radio is configured in one of the two WDS modes. (See section above about Mesh Rider Interoperability)
Please note that Sense between Mesh Rider radio and Nimble only works when the Mesh Rider radios operate in the standard 802.11 2.4-GHz and 5-GHz channels. Additionally the only supported channel bandwidths are 5, 10, and 20 MHz.
Sense role
Each Sense node is either the primary node or the secondary node.
The ACS list is configured on the primary node and sent to the secondary node.
ACS List
The ACS list defines the list of channels that the radio will use for automatic channel and bandwidth selection.
You can modify the ACS list on the AP, and it will be automatically sent to the Client.
You can only modify the ACS list if the device’s Sense role is the primary node.
You can get a list of how channels map to frequencies by running iw list.
Sense is a licensed feature that you will have to obtain a license from Sales.
Once a license is obtained, rename it to sense.license and place it in the /opt/licenses folder.
Configuring Sense on the Access Point (Primary sense node)
Go to the Nimble Config folder and run the Nimble config script as shown below
This is the configuration interface for Nimble. Go into Sense Config by choosing Option 3
Here we have the sense config menu
Check the Automatic Channel Selection (ACS) List by pressing 1
This ACS list has already been pre-populated but it can be edited with the delete (2) and add (3) options. Make sure to create the ACS list before you turn on sense. Otherwise you might have to toggle it on and off for the new list to propagate.
Another option for editing the ACS list is to directly edit the sense configuration file at /opt/sense/sense_uci (you will have to edit this as root). Please contact sales to get the advanced guide on how to tweak the sense parameters in the configuration file.
Here is the configuration file for sense
Once you are done configuring the ACS list, choose option 3 to Enable Sense.
Once you exit the sense config menu (option 4), the sense and message-system service will start running. The message-system service is responsible for communicating to the other sense node the ACS list and when it is time to switch channels.
Configuring Sense on the Client
Enable Sense on the Client as shown below by running the nimble_config.sh
For this jamming use-case we will have two nimble devices with a communication link at channel 1.
An iperf3 server was set up on the AP side and an iperf3 client was set up on the client side as shown below. This is to help visualize data transfer.
Here is a spectrum scan of the 2.4 GHz range with iperf3 running. You can see the transfer centered around channel 1 (2412 MHz)
Here is a read-out at the same time from the client that it is on Channel 1 (2412 MHz).
A software defined radio was used to create a jamming signal on channel 1 (2412MHz) to cause the radios to lose connection.
The jamming signal on channel 1 (2412MHz) was generated around 29 seconds into the iperf3 test.
As you can see in iperf3, the transfer was interrupted.
When the link is lost both radios will try channels on the ACS list till they are able to reestablish communication.
After a few seconds the link recovers on Channel 11.
Below you can see the jamming signal is still at channel 1 and the new transfer is happening around channel 11 ( 2462 MHz). This waveform at channel 11 is much denser than the previous at channel 1 as iperf3 is trying to satisfy the rate limit requirement by increasing the throughput.
You can see it took around 12 seconds for iperf3 to continue the transfer. This corresponds to the time for link recovery.
Here is the readout showing the client losing the link on channel 1 then going into link recovery mode and regaining connection on channel 11.
Jamming is the intentional disruption of wireless signals for malicious purposes.Interference, on the other hand, is unintentional signal disruption that can occur in congested environments where multiple devices use the same frequency. To demonstrate interference, I will have both Primary and Secondary Sense nodes communicating on Channel 3 and have a software defined radio intermittently transmitting on the same channel.
For the demo I will be running iperf3 server on the AP and
iperf3 client on the client
Once the nodes are transmitting data, we introduce interference on the same band they are on (Channel 3).
Once Sense detects interference and it meets the threshold, the primary Sense node will message to the secondary node that it is time to switch channels. The channel that it switches to is determined by the ACS list.
Channel 10 is next on the ACS list, so both nodes will switch to channel 10 as illustrated below.
This following readouts updates every one second and as you can see it transitioned from channel 3 to channel 10 seamlessly on both the Access Point and Client.
The following is the iperf3 log when interference on channel 3 was introduced and shows no loss of connection when Sense was activated. The interference source was turned on around the 22 second mark on this log. The channel switched from 3 to 10 around the 27 second mark. As you can see there was no loss of connection during either of those time marks. Iperf3 was run in UDP mode which would cancel the test if the link was lost. This shows that Sense has seamlessly switched channels without link loss when faced with interference.
An advanced user well versed with Ubuntu and Wi-Fi can use the set of config files below to modify and fine tune the radio behavior.
/etc/hostapd/hostapd.conf
/opt/sense/sense_uci
/etc/nimble/rules.conf
/etc/netplan/01-network-manager-all.yaml
/etc/dhcp/dhcpd.conf
/etc/wpa_supplicant/wpa_supplicant-<ifname>.conf
/opt/sense/sense_uci
/etc/nimble/rules.conf
/etc/netplan/01-network-manager-all.yaml
The following is a list of useful commands and an extract of their outputs. The full output is not shown.
Command:
ifconfig
Sample Output:
wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.223.3.1 netmask 255.255.0.0 broadcast 0.0.0.0
inet6 fe80::230:1aff:fe3a:b04f prefixlen 64 scopeid 0x20<link>
ether 00:30:1a:3a:b0:4f txqueuelen 1000 (Ethernet)
RX packets 81912 bytes 114038403 (114.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 90939 bytes 94608456 (94.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Command:
sudo iw <wireless interface> info
Sample Output:
Interface wls1
addr 00:30:1a:4e:f3:00
ssid wireless-hotspot
type managed
channel 40 (5200 MHz), width: 10 MHz, center1: 5200 MHz
txpower 23.00 dBm
4addr: on
Command:
sudo iw <wireless_interface> station dump
Sample Output:
Wireless_interface comes up as wlp3s0 by default in our systems.
Station 00:30:1a:4e:f2:ff (on wlp3s0)
inactive time: 93856 ms
rx bytes: 116988322
rx packets: 81924
tx bytes: 94602927
tx packets: 90898
tx retries: 1264
tx failed: 0
rx drop misc: 36
signal: -30 [-35, -33, -36] dBm
signal avg: -29 [-35, -33, -34] dBm
tx bitrate: 195.0 MBit/s MCS 23
tx duration: 6444164 us
rx bitrate: 104.0 MBit/s MCS 13
Command
rfkill
Sample Output:
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
Command
route -n
Sample Output:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s0
10.223.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlp3s0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0