Scott White

Want to connect two ground control stations (GCS) to a single drone? Or trying to control multiple drones from a single GCS? The RFD900x enables this with a multipoint capability — but getting it set up and working is not straightforward. This post, we show you how to connect two Mission Planner nodes to a single MAVLink-based vehicle (in our case a PixHawk controller running ArduPlane).

The RFD900x is a 900MHz, ISM band radio modem covering the 902 – 928 MHz frequency band. It is designed for long-range serial communications applications. In particular, it popular for telemetry on MAVLink based drones. The most common application is connecting your drone to a ground control station (GCS).

Each radio mode is enabled by loading firmware on the box. Currently, there are three firmware types available: SiK compatible (Peer to peer), asynchronous mesh and multipoint.

Unfortunately, the mesh and multipoint modes are poorly documented and are unsupported by the RFDesigns Radio Tools. The predecessor radio the RFD900+ also supports multipoint mode. However, the two firmware (and radios) are similar but incompatible. This creates more confusion when forum posts or documentation generally refer to the RFD900. This article tries to clear up some confusion and serve as a guide to configure the RFD900x with multiple ground stations or multiple drones.

Peer-to-Peer (SiK)

The factory default is the SiK compatible firmware that enables peer-to-peer communication. This firmware is well supported and documented. Most MAVLink-based software packages (e.g. Mission Planner) offer in-application configuration support for SiK radios.

Asynchronous Mesh

The manual describes the asynchronous mesh mode as:

The asynchronous mesh firmware offers a straight forward communication option that allows the user to quickly transmit and receive data between two or more nodes. If all the nodes are within range and have compatible parameters, communication between them will succeed.

All nodes are equal with no master node to set timing. This means data collisions and retries with variable latency. For Mavlink telemetry this does not work well. In our tests, we had 20% of bad MAVLink packets.The burst timing causes some problems for our toolset. In particular, the Mission Planner tended to time out when downloading params. Mission Planner expects the latency between packets to be consistent and the nature of the asynchronous mode caused lots of problems.

The mesh firmware includes a store and forward capability to extend the range of radios, but with other limitations we did not explore this capability.

Multipoint Mode

In the multipoint mode, we successfully connected two GCS nodes to a single ArduPilot based drone.

Loading the RFD900x Multipoint Firmware

Download the firmware from RFDesigns. We used RFD900x-MultipointRelease_V2.75MP.bin.

Setting up your RFD900x Network

The radio network requires one master radio and the rest are nodes on the network. The remaining of the nodes are configured the same — except for the node id which is unique per radio.

For larger networks, it is easy to mess up one parameter while configuring the RFD900x. We created a python script to help speed up the process. It uses a config file to load all the radio parameters.

To load the parameters manually, use serial terminal application and connect to the radio. The default serial port settings are as follows:

57600 baud rate

No parity

8 data bits

1 stop bit

To enter command mode hit “+++” and wait. The radio should respond with “[1] OK”. The number inside the bracket is the node id of the radio. It will change as you configure each radio to be different.

Once in command mode, you are ready to set the radio parameters. The screenshot below shows how to verify the firmware version and view the other radio settings.

Frequency Range and Power Output

The legal frequency limits and power output vary by region. You are responsible to make sure you use the frequency and power limits for your locale. The settings in this document were used in the United States.

Setting up the Master

The master node is always 1.

We set “S22:MASTERBACKUP” to 1 for our radios to work. We did not find any documentation on this setting!

Finally, set the number of nodes in the network. AT&M0=0,3 where 3 is the number of radios you are using.

ATS18=1 [1] OKATS22=1[1] OKAT&M0=0,3[1] OK

Network Settings

We found this setup the most stable. We tried many other settings including a faster baud rate and with encryption enabled, but those settings resulted in a higher error rate at the MAVLink packet level.

Troubleshooting Tips

When upgrading from the RFD900+ to the RFD900x, we made the mistake of trying to integrate directly on the drone. This wasted lots of time changing settings while trying to debug with a PixHawk and ArduPilot in the loop.

Start simple

First, connect all the radios in your network to a single computer. We used a powered USB hub and several USB FTDI cables.Use a serial terminal application and setup the simplest case:

disable encryption: ATS15=0

no MAVLink encoding: ATS6=0

broadcast to everyone: ATS19=255

Once you can send text and see it on all the screens you have a multipoint network working!

Wow! 2018 has been a banner year for opensource-centric companies. RedHat one the original open source companies was acquired by IBM for $34B. Github — the developer platform built around the open source tool git — was acquired by Microsoft for $7.5B. Gitlab – a company built on open source products raised $100m and is now valued over $1B.

At Orange Robot we leverage the awesomeness of open source projects to build new software projects faster. The huge breadth and quality open source projects are always amazing. In fact, the free software often amazes/confuses my non-technical clients (“Why would anyone give this away?”).

This list does not include fundamental projects such as Linux, git, and Python that are critical to custom application development. Instead, here are some our most used/loved projects in 2018.

More Features less Fuss

Django makes it easier to build better Web apps more quickly and with less code. More than just Django, the entire ecosystem is fast, secure and scalable. I am often amazed how fast you can build sophisticated REST API with Django and Django Rest Framework. Django dumped Python 2 support in 2.0 and is an awesome reason to migrate legacy projects to Python 3.

ReactJS is a JavaScript library for building user interfaces. It is wildly popular which means there is a lot of great packages (e.g. Create React App, Material-UI), a growing base of knowledgeable developers. ReactJS is our default tool for building user interfaces in web applications.

PostgreSQL, the self-proclaimed “world’s most advanced open source relational database”. In fact, Postgres is older than many of the devs these days, with over 30 years of active development; however, it is still rocking along. The great GIS support, JSON capability, broad support, and multiple SAAS offerings make it a great database choice.

Putting the Dev in DevOps

Kubernetes is an open source container orchestration platform that can automatically scale, distribute, and handle faults on containers. Its popularity is boon to companies as they can now run services in all the major cloud providers: Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes (Amazon EKS), Azure Kubernetes Service (AKS) using Kubernetes. Even upstart cloud providers like DigitalOcean have a Kubernetes offering. Kubernetes gives customers more choices and saves development and deployment dollars.

Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy. Developers need “glue” to connect everything together in cloud-native architectures built on top of multiple services. Ansible is a great glue layer.

Developer Tools

Prettier is an opinionated code formatter. Code formatting seems simple — but style guides can lead to holy wars and an inconsistent code base is just yucky and confusing to developers. Prettier takes all the opinions and EFFORT out of code formatting. Prettier is my favorite new (to me) tool of 2018. For the reason, A simple but excellent tool that saves time and sanity. Let’s be real no ONE likes formatting code.

Black – Same as Prettier but for Python. See above☝️. Python formatting is way easier than Javascript, so Black is not quite as revolutionary as Prettier.

Atom is a hackable text editor for the 21st Century. We spend all day editing files and Atom makes it easy.

Psst, Your S3 is showing!

Your application security might not be as good as you think. S3 security breaches are in the news way too often. These breaches are not the result of sophisticated hacks, but simple misconfigurations akin to not locking your front door.

Having private moments exposed can be embarrassing. Leaving all your sensitive files open for all to view is more than embarrassing. It is a publicity nightmare with legal ramifications. More than ever, application security is critical for application development.

Cloud providers have great solutions for file storage – AWS S3, Google Cloud Storage and DigitalOcean Spaces.
These tools allow unlimited storage of your files, fast access, and an affordable price. The systems use on-disk encryption and access over https.

With all these security features your files are safe and sound, right?

Maybe, maybe not. If your development team is not up to speed they can press the ‘easy button’ and allow all your files to be publicly readable. Instead of properly implementing security they rely on obscurity.

“There are millions of files on Amazon Web Services they will never find ours.” — said many embarrassed developers

Of course, your rockstar development team would never do that — right?

Obscurity never works for long. There are numerous public tools that scan Amazon for public S3 buckets with hidden data (e.g. DigiNinja Bucket Finder).

S3 leaks are not new but have been happening at an alarming rate recently.

It started as a simple request.

It was a cold, lazy day and my wife asked me to move furniture from room A to room B. Easy enough I can get that done in a couple of hours — I foolishly thought.

Initial estimate: 3 hours.

As with any project, initial estimates are highly speculative.

After removing the first desk, the scope creep starts. The wall behind the desk was a mess. It needed to be repainted.

“How about Accessible Beige?” New paint color — more scope creep.

Luckily, it was still early in the day. I could prep the walls, make a paint run, and get the walls painted today. Right?

New estimate: 1 day.

“Those are soooo ugly.”
Issue #2 (or is it 3?) The desk was hiding two vintage outlets that matched the old wood paneling. Even worse, outlet boxes were metal and stuck out from the wall slightly as a holdover from the original wood paneling design. (Technical debt is everywhere!)

At this point, we had to make a decision to fix it right or ignore the problem.
Adding electricity and legacy technology into the mix kills any schedule.

New estimate: Unknown.

Given there no hard deadline (i.e. company coming over), we pushed ahead to fix it the right way.

Removing, the old outlets I found that one of them was black inside where it had shorted against the metal outlet box. Bonus points: fixing fire hazard!
At the end of the day, the electricity issue was closed. The next day, we got the room painted and it looks great.

You are ready to get your app built, but where do you start? How do you find the right mobile app developer? There are lots of options to choose from large mobile app development agencies to freelance mobile developers and everything in between.

When you find your mobile app developer, how do you know they are the right one? This guide gives a few fundamental questions to help weed out the pretenders from the contenders.

Let’s start with the basics.

Version Control.

How do you store and share source code?

👍 Answer:

We share a Github (or BitBucket, etc) repo with you, so you can access and review our work at any time. We follow industry standard best practices for source control.

😱 When to run:

Version what?
We will send code to you anytime you ask….
We do not need version control — we backup our machine nightly.

Bottom line on Version Control.

Awesome source repositories are available for free or close to it. There is no reason for any developer not to use version control for mobile app development. Your app source code is your a critical business asset. We suggest signing up for an account at Bitbucket (or Github) and inviting your development team to your repo. This way you never lose control of your code.
A non-technical product manager, may not understand the source code, but it is critical to have control of in case something happens to your developer.

Yikes! Why you need Version Control.

Collaboration

How will you collaborate with our product team?

👍 Answer:

We provide regular weekly updates via video conference, are available via chat, email, etc as needed. We use _________ (Trello, SmartSheet, Basecamp, et al.) to manage our backlog of work. To start we will work with you on initial scope and priority of tasks to match your budget and schedule. Ongoing, you have access to this tool to monitor progress and reprioritize remaining work for your mobile app development.

😱 When to run:

We will send you the product when it is complete.

Bottom line on collaboration

Regular, scheduled updates are critical to success. Doing the wrong work will kill your schedule (and budget) faster than most technical roadblocks.

Work backlog (todo list) needs to be managed in a tool; otherwise critical items can get dropped and no-core features can creep up costing you time and money. There are tons of good tools and something as simple as a Google Sheet works for simple projects.

Collaboration is a two-way street, the best mobile app developer will fail to deliver if the Product Owner is not engaged and providing regular feedback. Make sure your in-house team is ready to support

Security

How do you mitigate the OWASP Top Ten Mobile Security Risks?

👍 Answer:

We take security seriously at ________ and is huge subject. Here are five basic things we do make sure all our applications have a secure foundation.

We use prefer to build natively on Android and iOS. This removes an unneeded layer and vector for attacks.

Start new projects with the latest (stable) version of tools.

Encrypt all data moving off the phone.

Store as little data as possible.

Request as few mobile permissions as needed. Less permissions also ease the app approval process.

😱 When to run:

🤔 O-What?

Bottom line on Securty

Application security is big deal and it is a dangerous world out there. The risk is a function of your applications and business. For high-risk applications (very large footprint to attack or very sensitive data), security and compliance are problems best left to a team of experts. For the rest of us, use well known supported and secure tool chains and follow development best practices.

Testing

How do you plan to test the new mobile application?

👍 Answer:

As features are built out during mobile application development, we build automated tests to make sure everything stays working! We will roll new versions of the application from internal testing, to external beta testing and finally to general availability. We also instrument our code, to watch for problems that crop up in the wild because they will.
In most cases, we do rely on you, the product owner, to provide domain expertise to validate the desired functionality.

😱 When to run:

🤔 We click on few buttons but depend on you to test most of the functionality.

Bottom line on Testing

It is often said that👇

An untested line of code is a broken line of code.

Ok, maybe this is not said that often but it should be! Testing may add some work at first, but in the long run, it makes any project easier to build features that delight your customers instead of spending money fighting bugs.
At this point, both XCode and Android Studio have provided so much framework around unit testing and ui testing that it is no longer reasonable to claim it takes too long to generate tests.

Listening

How would you attack this problem? (after you explain what you are trying to do)

👍 Answer:

Do you have a whiteboard? I can show you…

😱 When to run:

🤔 Buzzword. Buzzword. Buzzword. Trust us.

Bottom line on Listening

If you can not explain your problem and the mobile app developer reflect back an understandable plan of attack — then things are not going to work out. This plan will be wrong and incomplete, a good developer can draw you a map of where the hard things live and what features are easy. This on-the-fly plan will not have a price attached and may have black boxes that need to be filled in by other experts, but it should make you comfortable that your development team can listen to you AND speak in a language you can understand.

Is that it?

What about technical chops? Red Black Trees? Bloom filters? Data compression? Technical skills are important, but projects are often killed by the simple things, so make sure you get that right first.