How to have good fpv video

For fpv newcomers, getting good video transmission from craft to goggles is often a challenge. Understanding how the different parts work together is important for solving video issues, hence this post.

Video is a system, not one single component

If you want to have good video, you have to plan for the type of flying you want. There is no perfect video solution that fits all flying styles. I am going to focus mostly on long range, an application in which you fly far without obstructions.

Receiver side

For long range you want  a good directional antenna and a decent receiver. I have tried a bunch, too many to name here. As of this post (December 2018) my choice for the goggles is the Eachine Pro58. The best budget antenna I know is the x-air, and if you really want to go far the x2-air is the best I’ve flown. Of course a good directional antenna won’t help if you don’t keep it pointed at your craft as best you can. I have seen many people fly with their antennas pointing to the ground. If you tend to do that, adjust your extension accordingly so that the antenna points towards where you expect your craft to be.

The omnidirectional antenna in your diversity receiver doesn’t matter as much for range, it’s only important when you’re flying behind yourself or to the sides. When you’re flying fast and close, you can’t always adjust your head quickly enough; an omnidirectional antenna has you covered in those situations. As soon as you gain some distance, your angle to the craft does not change that quickly. That’s when you want to make sure to track it with your directional. This takes a bit of practice, it involves gently sweeping your head side to side and up/down until you find the best position.


There are several good options for transmitters. I do not believe anyone should have to pay more than $25 for a 5.8 transmitter capable of ultimate range. I’ve flown 7 miles with a $9 AKK. This transmitter has fixed 600mw power and just the basic features (channel / band selection). If you need bells and whistles like smart audio and different power settings, you can go with other AKK models such as the x2 ultimate. If you want to support TBS, the Unify is an equally good alternative.

If you fly long range, you often want 600mw or (very rarely) more. It’s very important to make sure your transmitter does not overheat. When a VTX overheats, it tends to reduce the power which means you will lose video when far away. There are several ways to achieve this. The easiest is to ensure good airflow, which easy on a quad. On a wing you want to expose one side to the transmitter to an external surface with air flow. If that’s not possible you can dissipate heat with a good heatsink.

Lastly, the antenna and its placement is very important. For an omnidirectional antenna, you want to make sure the radiation pattern is optimally directed towards you as much as possible and free of obstructions. On a plane this is usually easy to accomplish. On a quad it can be hard; it’s easy to put the frame or battery in between you and the antenna when you’re flying in certain directions. The general solution to this problem is to make your antenna as tall and as separated from the airframe as you can. For the typical antennas we use, you want to make sure that they stand vertical when in normal flight position.

There are other subtleties to getting good video but this should be enough for most people to get decent range. Good luck and happy flying!


Design considerations in Betaflight’s GPS Rescue Mode

One of the hardest things in software development is communication. It does not matter how smart you are if nobody understands why you wrote some code, what it does or why. Open source projects are usually not the best in this respect, hence this post.

When Mike Campbell and I designed GPS Rescue mode, we quickly realized that the hardest aspect about flight controller software (as opposed to, say, web development) is the testing. These days, the most popular forms of application development have automated regression tests. If you misplace a comma and break something, this becomes obvious. Not so with flight controllers. You have to flash the software onto a flying thing, charge a battery, take off and test the feature you just changed. Even if your feature works, that doesn’t mean you haven’t broken anything else (more about this later). Because of this, we set out to make GPS Rescue to do exactly one thing as simply as possibly: bring your quad back to LOS range, ideally close enough that you can land it LOS. If not, at least it would come down close to you and you wouldn’t lose it. We did not intend this feature to be a reliable DJI-style Return to Launch, because our quads are not DJI-level hardware.

Some principles:

  • when in rescue mode, the quad always points towards home.
  • if the quad moves, it moves towards home.
  • if a sensor does not increase our chances of saving a quad, we do not use it.
  • the default tuning must work well enough for typical 5″ to 7″ quads (reasonable prop/kv/motor matches).

The idea of Rescue Mode is very simple: when activated, point toward home and try to reach a certain altitude while moving slowly forwards. Once the altitude is reached, speed up and get closer to home. When close enough, descend. Easy, right? What could go wrong?

A lot of things can and did go wrong during the hundreds (thousands?) of Rescue Mode activations I did. Activating an untested change to autonomous navigation takes some faith, as well as quick reflexes. Here are some highlights:

The above happened while trying to test failsafe. Needless to say, it was not working properly yet.

Once Rescue was working fine, it made it into the release candidates for Betaflight 3.4. In late June I received multiple reports of weird behavior: GPS Rescue would send quads into infinite spins. I traced the problem to a completely unrelated change. When working on command smoothing, another developer inadvertently changed Rescue yaw to be a positive only value, so when the quad was trying to turn in the negative direction it would overflow. The result would be an infinite spin in the positive direction. The fix was just removing one character to make an unsigned value signed again.

Another aspect that caused us a fair amount of grief was altitude estimation. Most people who have used GPS know that it was not designed for accurate altitude readings. It is a geometrical issue based on how the satellites are positioned in the sky. Generally the more satellites a GPS unit sees, the better the altitude estimation; however, satellites come in and out of view, and altitude estimation suffers discontinuities. This is why it is a good idea to use other sensors to have a better view of what is happening. The obvious sensors to use on a miniquad are the barometer and accelerometer. Barometers have their own sets of issues, but when used properly (i.e. foam, correct positioning) they usually help. The accelerometer is a different story. Accelerometers using on miniquads have so much variation that we preferred to leave them out of the equation. This led to an insight about position estimation:

When using unreliable sensors, you need to know how much you can trust a given sensor. If a sensor goes bad and you trust it too much, your position estimation can go into dangerous territory.

GPS has an inherent measure of trust called Dilution of Precision. Accelerometers do not. People have suggested using all sorts of sensors or mechanisms to improve our altitude estimation (e.g. “radio pings”). These people usually have not considered that :

  • The more code you rely on (particularly written and updated by different people), the higher the changes of breaking things.
  • Every time you add a potential input to an estimate, you increase the test cases exponentially. For example, say you start using sonar and there are three types of sonar available. Now all your test cases have been multiplied by three. If the driver for Sonar 1 breaks and GPS Rescue stops breaking, it could take multiple hours of field testing to find the source of the problem.

To sum up this post in one paragraph: do not overcomplicate software. Do the simplest thing that works first. If you think you know better than the developers of an open source product, try making your own changes and testing them!



Starter long range setup

Many people have asked me about the best way to start exploring longer distances with miniquads, so I figured I’d write something up as a reference.

  1. Frame: I’d say start with a frame capable of six inch props. Which one? As long as it can fit your electronics of choice, it’s a matter of taste. My personal favorite these days (May 2018) is the iFlight xl6, but this is really the least important aspect. Because we try not to crash often when flying at range, you don’t need a strong and heavy frame. Lighter flies longer. I prefer having the option to bottom mount a battery as to not block the antennas, and this frame fits the bill.
  2. Radio: A month ago I would have said TBS Crossfire, but now you can get a FrSky R9M for under $50 and the R9 Slim receiver for $25. I’ve them, and the performance at a given power is comparable to the full size TBS Crossfire module at a fraction of the price. The only disadvantage is that the power is limited to 1W instead of 2W, but that really should not be a concern for most people. If you find yourself in need of more power, you are either flying in a very noisy environment or would do better with a different control frequency such as 433 Mhz.
  3. Video Transmitter: without a doubt, the best deal out there for “semi long range” is the AKK K31P,  a steal at $9. Cons: the power is fixed at 600mw, which could be a problem if you also want to fly with others. No smart audio, soldered antenna pigtail. You may want to look into other AKK models for the features, but 600-800mw is enough to go pretty far in the right environment.
  4. Video Receiver: I have had excellent results with the Eachine Pro58 flashed with the Achillez Plus firmware. I flew almost five miles with a miniquad using this receiver. You do not need an expensive receiver or a Clearview to fly far, this receiver will do just fine.
  5. Antennas: my favorite antenna by far is the TrueRC x2 Air. It’s not cheap, but it’s an investment. If you want to test the waters with a less expensive directional, try the x-air. From experience, you’ll get about 30% more range with the x2-air but this may not be important at first. On the quad, I prefer the 80mm Pagodas because they stand as far from the frame as possible. You might as well buy two and have one as the omni on your goggles.
  6. Motors, props, batteries: really anything goes here. If you’re going to fly 6″ props you want at least 2206 motors, kv doesn’t matter much because long range is about low and steady throttle. I’ve had good results with HQ 6045 biblades, but try a bunch and find your own favorite. I’ve put all sorts of batteries on 6″ quads, up to 5200 4S. I choose the battery for a particular goal. For example when I flew to Alcatraz I picked a 2300 4S because I wanted to be able to fly for at least six minutes carrying a GoPro.
  7. GPS: you absolutely want one for long range. Here are a couple that have worked well for me: RTFQ Ublox m8n, HGLRC m8n. At $15, you will be happy you invested in one.
  8. Miscellaneous: there are many scenarios in which you may have to look for your quad far away, using the last known GPS coordinates as a starting point. I haven’t tried any of the lost model beacons that have come out recently, but the Tile Sport made it easy to find my quad in tall grass a number of times. I don’t always put it on the quad, but it’s reassuring to have when I’m going to be flying over dense vegetation. Also, having a way to know if the spectrum is 900-Mhz friendly where you’re flying is nice. If you plan to fly a spot often, it may pay to sit there for a while with a laptop and an RTL-SDR dongle to make sure there are no powerful sources of 900 Mhz transmissions nearby.

Lastly, you may want to consider testing the alpha version of GPS Rescue that Mike Campbell and I have been developing for Betaflight. No matter how many precautions you take, you will failsafe or lose video if you push the limits. Having a quad that has a chance of coming back autonomously if everything goes wrong is comforting 🙂

Hope this is useful and happy exploring! If I forgot to mention something , please let me know in the comments.

GPS Rescue Mode for Betaflight – Setup Guide

DISCLAIMER: this is an experimental feature. Use with extreme caution. This documentation WILL change so check this page often. Do not activate this feature unless:

  • You are in a spot with no people or property within a 50m radius of yourself
  • Have little attachment to your quad
  • Have read this document and fully set up all the required parameters

This is a work in progress by Mike Campbell and myself, contact either of us for questions. Void where prohibited.  Do not taunt happy fun gps rescue.

Download binaries here

If you are reading this, you probably have experienced the feeling. Flying far away when all of a sudden your quad failsafes and you see it drop into the Chasm of Oblivion. Or worse, your video is gone and you do not even know where it may have ended up. That is the motivation for GPS Rescue. Want to set it up? Read on.


  • Any F4 flight controller capable of running Betaflight.
  • A GPS unit mounted on your quad (ublox m8n recommended).
  • (optional) barometer.
  • Familiarity with the Betaflight command line interface.

First, back up your quad configuration (e.g. by running “diff” on the CLI and saving the output to a file). Then, flash the corresponding build on your flight controller. Restore your Betaflight configuration, go to the Betaflight Modes tab and add a switch for GPS Rescue Mode. Verify that the mode actually gets activated (of course no props).

Next, configure the following parameters in the cli:

set gps_rescue_initial_alt=[number] (default is 70)

This is the most important parameter. When Rescue Mode is activated, Your quad will point home and try to climb to this altitude relative to your takeoff point. I personally like to make it 70 or 80 meters.

set gps_rescue_ground_speed=[number] (default is 1500)

This is the speed at which your what will try to come back, in centimeters per second. I like 1500 (about 35 mph), but this setting depends on how and where you fly.

set gps_rescue_angle=[number] (default is 30)

This is the maximum allowed tilt angle for your quad when coming home. This setting may prevent it to reaching full speed, so you may have to experiment with it if you change the defaults. Note that the higher the angle, the harder if will be for the altitude controller to keep a stable altitude. When there is a chance of returning into head winds I like to set this parameter to 45 degrees.

set gps_rescue_descent_dist =[number] (default is 200)

This is the distance at which your quad will start descending towards home.

At this point you are ready to test Rescue Mode. We suggest the following procedure:

  1. Wait for your gps to get a good fix.  By default your quad will not arm if you have less than gps_rescue_min_sats. You can decrease this value in the CLI or even make it 0 if you just want to fly near yourself. However, I would not take off with less than 6 satellites if I there is a chance that I may need GPS rescue later in the flight.
  2. Fly in a straight line for at least 100 meters past your descent distance. For example, if your descent distance setting is 150 meters, fly to 250 meters. As you fly, the home arrow should adjust to point towards home. VERY IMPORTANT: if your arrow does not point towards home, DO NOT activate GPS Rescue. Your quad will try to fly in the direction of the arrow if you do.
  3. Activate GPS Rescue. IMPORTANT: be ready to deactivate the mode and take back control if your quad does not point towards you and starts making its way home.
  4. If everything goes well, your quad will come back towards you and start descending. Do not let it get too close to the ground or to yourself because the landing functionality is not included in current builds. Your quad may just crash near your or overshoot you.

You may have noticed that the quad had a hard time keeping a stable altitude. Sometimes this happens when the GPS altitude reading is unstable, so the controller is aiming for a moving target. If you had a very stable altitude reading and the quad still could not stabilize within ten meters of your desired target altitude, you may have to adjust the altitude throttle PID gains. These are the parameters:


We do not expect that most people will have to fine tune the navigation speed gains, but just in case the PID gains are:

gps_rescue_velocity_P = 80
gps_rescue_velocity_I = 10
gps_rescue_velocity_D = 20

After your quad reliably returns home once, you may want to test it at progressively larger distances and directions. When you have a reasonable level of trust in the feature, you may want to set your failsafe to GPS_RESCUE:

set failsafe_procedure = GPS-RESCUE

GPS Tips and Tricks

Many people who followed my gps on Betaflight guide have not had the best experience with gps. Here are some tips for getting the most out of your gps setup.

  • Make sure you have an m8n chip. The reason you want an 8 and not a previous version (i.e. a 7) is that the 8 can do two different satellite constellations at once. Specifically, GLONASS and GPS. You effectively double the number of satellites you can see, which makes the gps lock much faster. The way to check for this: in u-center, go to Messages View. Then select UBX -> MON -> VER.

    Beitian BN 880
  • If your GPS takes a while to lock, you may want to power it up with 5V while you’re driving to your flying spot. Some flight controllers supply 5V when plugged in to USB (the Omnibus F4 does, for example) and others don’t. For the ones that don’t, you could attach a small connector to power it with an external 5V source.
  • Mount your GPS unit such that it has as much line of sight as possible to the sky. If you have a 1.3GHZ video transmitter, get your gps as far as possible from it.
  • It’s possible to use a GPS with only the RX pin of a UART, if it has non-volatile configuration. You have to first configure it via u-center so that it sends all the messages Betaflight needs (see here ). Obviously auto-config from BF won’t work, but that’s fine.
  • If your gps is connected with TX and RX, you can connect u-center directly to it via the flight controller without the need for an FTDI interface. In the Betaflight CLI, type “gpspassthrough” and then disconnect so that the configurator releases the port. Go to U-center and connect to the same port.
  • My two preferred gps modules so far: 1) Beitian BN-880 for 6″ and larger builds. It also has compass. 2)  Ublox m8n for 5″, because it’s small and light.

[more tips to come, check this page once in a while]

Miniquad long range pre-flight checklist – this will save you money and pain

Long range with a miniquad is unforgiving. Make a mistake, lose the craft. This checklist is intended to minimize preventable losses, based on experience.

  1. Flip the quad upside down, check motor screws. You do not want to lose a motor mid-air while flying over a lake or mountains.
  2. Check that all your propellers are in good shape. A bent prop could cause a motor to fail, a damaged prop could explode mid-air.
  3. Check your transmission frequency and power. Specifically, you’re using Crossfire make sure you’re on the right frequency for your region (e.g. 915Mhz in the US), and that your transmission settings are adequate for the flight about to take place.
  4. Plan your flight. Surprises in long range are usually not good. Look around, study the terrain, know where you can and cannot go, have an understanding of line of sight between you and your expected course. Checking the area on Google Maps and having an idea of the distances and landmarks is always a plus.
  5. Make sure DVR is on. If your quad goes down and the battery comes unplugged, DVR is your best hope to find it. I personally DO NOT take off for a long range flight unless I know I’m recording it on my goggles.
  6. GPS not locked = no go.  Same as above. I want gps every time not just for finding the quad, but to make sure I can find my way back. Distance to home is invaluable, don’t leave home without it.
  7. If your receiver / base station is on a tripod, make sure it will not get knocked over. This is actually a good reason to have a spotter. You can have the best video system, yet lose a quad because of a gust of wind.

[more to come]

This is not really part of the checklist, just some learnings from experience:

  • Never go too far on a maiden. Even if you’re the world’s best builder, you never know what components are faulty. Fly around for at least four or five packs before venturing into the distance.
  • A quad that crashed badly is not a long range quad. You never know what hidden damage exists, and you don’t want that damage to become evident as you fly one mile out over water. If you have a bad crash, inspect the quad thoroughly (particularly all the solder joints and wires).
  • Know your battery well. Turn around before it’s half spent.
  • Consider using redundant mechanisms for finding the quad: e.g. gps and a bluetooth beacon such as a Tile. Don’t rely on the battery to remain plugged in.
  • If you can, scan the spectrum. Make sure nobody is using the video frequencies you plan to use.

Miniquads and Safety – Rational Analysis Attempt

Miniquad safety is a murky subject. At first glance it seems obvious that a miniquad is a potential dangerous object, perhaps even lethal. A quadcopter traveling in a straight line at the height of  a person’s head has the potential to seriously hurt or kill somebody. There is a fair amount of offline discussion around this topic, but unfortunately most of it is based on speculation and feelings as opposed to reason and hard numbers. This post is an attempt to do the latter.

It’s important to acknowledge that all of us partake in activities that are dangerous to others. Some are arguably necessary; if you have to drive to work, you are a statistical contributor to the roughly forty thousand road deaths that happen in the US on a given year. But what about the unnecessary driving all of us do? From a statistical perspective, going on a recreational 1000-mile road trip has 1/100,000 odds of resulting in one death. This is very significant, because a large amount of driving in the US is of this type. Recreational driving kills at least hundreds of people each year. Nobody is on a crusade against unnecessary driving, just because we are not robots that think about the public good. We are imperfect, selfish, and get emotional about things that are often not the ones that matter most.

I imagine some people may be put off by the comparison with driving. Driving is accepted and part of our culture, like alcohol and guns. Miniquads are not. They are new and scary. Because they are a recent development, there is not enough data to write a paragraph like the above. How many people die per million miniquad flights? We do not know. The close we could get to this number would be by estimating the number of batteries flown every day, and finding records of all people killed by miniquads. I personally have not found any records of deaths caused by miniquads, but that does not mean they have not happened (I would honestly welcome that information).

It is possible that a miniquad is not as dangerous as some people believe. Let’s consider all the things that need to go wrong for someone to be killed by a miniquad. Here is an example scenario:

Miniquad near road

An operator is flying a miniquad near a road, trying to keep some distance (let’s say no closer than 20 feet). If the operator has no intention of going over the road, some type of failure must occur. The most common failures with fpv miniquads are:

  • power train failure (motor, esc)
  • loss of video
  • loss of control

In the first case, most likely the miniquad will drop. Unless it was traveling relatively fast and in the direction of the road, it is very unlikely that it will land on it. In the second case, the operator has the responsibility to deactivate the miniquad right away (or set it into a mode that would stabilize it and climb out of danger). Video loss should not cause the miniquad to hit a road unless the operator makes a mistake.

Loss of control is the most likely reason the miniquad could impact the road. This is largely preventable. Again we do not have data to back this up, but empirically most control losses in radio control are due to various operator mistakes such as flying out of range or having damaged antennas. Interference is also possible, but this mostly happens when several miniquads fly in close proximity and in a hostile RF environment. Out in the open this is still possible but unlikely, especially if the operator is staying well within the known range boundaries and line of sight.

Let’s imagine the operator has taken all possible precautions for this flight, just like a normal aircraft pilot would. The miniquad is in good shape: no damaged antennas, no questionable components. There is a contingency plan for video loss, control loss is unlikely. There is still an unknown chance that something will go wrong and the miniquad will somehow end up hitting the road. I can only speculate as to what could cause this, but let’s say it happens.

We are now in an uncommon scenario: we got unlucky and the quad is hitting the road. What would need to happen for someone to die? The typical miniquad weighs roughly 600 grams. A miniquad impacting a car cannot change its trajectory. What can it do? It could startle the driver, which in turn could lead to an accident. How likely is this? If we want to know, we would have to dive into statistics of traffic accidents and see how many of those were caused by unexpected hazards startling drivers. We would have to know the total number of events in which drivers were startled, and divide the known accidents by that to find the odds of an accident.

Let’s say that 99 out 100 times, when a car gets hit by an object the driver gets startled but no accident happens. It could be more or less, but the point is that an accident is not the most likely scenario when a driver gets startled. How about a fatal accident? That depends highly on the type of road and the road conditions. A miniquad landing on a car in gridlock traffic at rush hour is likely to cause some property damage, but extremely unlikely to result in a death.

Miniquad in park

When flying in a public place such as a park, the worst possible scenario is hitting an unexpected passerby with lethal force. Let’s examine what would need to happen for someone to die or get seriously injured in this case. Once again, the primary suspects are video loss, control loss and powertrain failure.

Most miniquad pilots make a good faith effort to avoid flying in populated areas. However, we don’t always fly in wide open spaces with no obstacles. Parks with trees are one example of a location where people can unexpectedly appear in the trajectory of a miniquad.

The number one mitigation factor for this type of risk is having a spotter continuously scanning the area for unexpected persons. This is not a protection when flying behind obstacles, as neither the spotter nor the operator would see behind, but it does decrease the odds of a collision. The second mitigating factor is a thorough pre-flight inspection of the miniquad to avoid loss of control, and a knowledge of the RF environment to avoid video loss. The third one is a contingency plan (“if I see a person in front of me I will immediately ground the quad and disarm”). The fourth (and arguably most important one) is speed. Because the energy of an object is proportional to the mass as well as the square of the velocity, a quad going 60 mph will impact with four times the energy of the same quad flying 30 mph. When flying in areas where humans are likely to appear, flying fast is flying irresponsibly in the same way driving above the speed limit is irresponsible.

Conclusion: if we as a community want the activity to be safer (not just appear to be safer, which is in itself a goal but not the point of this discussion), we need to think rationally and critically about the risks posed by miniquads. We need to inform ourselves regarding the likelihood of failures, and we have the responsibility to treat our quadcopters like regular aircraft. Flying a poorly maintained miniquad is irresponsible. Planning a flight adequately, thinking of the risks involved and having contingency plans is something all of us should do at all times.




How to log gps coordinates on the Taranis

[This post is a work in progress, feedback welcome].

In a previous post I discussed how to set up GPS with Betaflight 3.2. If you don’t have telemetry, you have to rely on DVR to locate a lost quad. However, if you have telemetry working on Betaflight you can take full advantage of gps. You can log gps data on the Taranis, have your current location on your telemetry screen (extremely useful for finding a downed quad) and even plot your flights on Google Earth! Here’s how.

If you’re using TBS Crossfire (recommended): First, make sure you connect your Crossfire receiver to the flight controller using CRSF and not SBUS. CRSF is a bidirectional protocol, and includes telemetry. I’m using the Crossfire Micro RX v2. If you already use CRSF, skip to “Discovering sensors.”

[Note: I tested this under firware version 2.0.6, had to revert from 2.0.7 because it didn’t work. Also, I tested this with BF 3.2 rc5 and rc6 only].

How to connect CRSF: you will need to connect your micro rx to the controller like this: gnd and 5v, channel 1 to a uart rx and channel 2 to a uart tx. If you’re connecting ch1 to the sbus uart, make sure you go to the Betaflight command line and type

set sbus_inversion=OFF

On your Crossfire transmitter go to the receiver configuration menu -> Output Map. Set CH1 to CRSF RX. CH2 will automatically switch to CRSF TX:

Go to Betaflight configurator and enable Telemetry under features. Under serial protocol, enable CRSF. Make sure the proper uart is set in ports.

If you can control your quad with CRSF, you are almost there. Next thing set up telemetry.

Discovering sensors

Plug in your quad and go to the Taranis telemetry page. Select the “Discover new sensors” option and wait a few seconds. You should see several new sensor appear on the sensor list. Here comes a surprise: flip your Taranis and look at the Crossfire screen (assuming you have the full size Crossfire). You’ll see something like this:

[if your gps is not locked to the satellites the coordinates will be 0, but at least you’ll know it works].

If you’re using Frsky with Telemetry: all you have to do is discover new sensors (see Discovering sensors in the Crossfire section above).

Enabling black box logging on the Taranis. Here’s a short video than explains it well:

Next up: Plotting flights on Google Earth.




How to add GPS to a miniquad with Betaflight 3.2

With the 3.2 release, Betaflight finally has decent GPS support. Here are some of the navigation features you can have on Betaflight OSD:

  • Latitude
  •  Longitude
  • Distance to home
  • Speed
  • Arrow pointing home

Even better: if you have a telemetry-enabled receiver such as the X4R or XSR, you can send your location to the Taranis in real time. The Taranis will log your position, and keep the last known position available in case of a crash. This means it could save you time and maybe money in the long run.

Interested? Let’s do it.

The first thing you need is an integrated GPS receiver / antenna that’s small enough to fit on a miniquad. The one I have been using is the Micro Ublox M8N that you can buy at RTFQ for $16. It weighs only 6 grams, which is negligible for most miniquads capable of going relatively far.

Ublox M8N gps unit

This unit comes preconfigured and ready to wire to a flight controller. However, if you want to mess with the settings you can configure it via a serial UART and u-center for Windows. This video is still mostly relevant if you need to do that.

Wiring the gps unit is easy: just connect it to a free UART on your flight controller. Make sure that the wires are long enough that you can mount the gps on top of your quad.  If you are running a bottom mounted battery, the top of your HD camera mount is the best spot. I run a top mount, so I prefer heat shrinking the gps to a battery strap so I can have it on top of the battery.

Once wired, configuring the gps is easy.  On the ports tab of Betaflight, select gps as a peripheral for the UART to which it’s wired. In this case I used UART 3.

Then in the configuration tab:

And if everything is wired correctly, when you restart betaflight you should see the GPS indicator light up at the top of the screen.

Now there are two things you can do. If you have Betaflight OSD, you probably want to enable gps coordinates, distance to home and direction to home. I also like having the satellite count and gps speed, even though it’s not very accurate. My screen looks like this:

The home arrow indicates that I’m flying mostly away from myself and 145 meters away. The GPS coordinates show that I am in… [left as an exercise for the reader].

The second thing you could do is set up your Taranis to log gps coordinates (assuming your receiver has telemetry, won’t work with an xm+). I won’t cover that now because this is enough for one post, I’ll save it for a future one. Happy flying and hope this saves you from losing a quad or two!


Diagnosing Quad Issues

So your quad doesn’t fly right. It has strange oscillations, vibrations, falls out of the sky, etc. Here’s what you do:

  • Check that all frame screws are tight.
  • Make sure all standoffs are straight.
  • Check all the screw motors. Make sure they are not touching the windings. Test continuity between screws and leads with a multimeter (there should be no continuity). If there is continuity, use shorter screws.
  • Inspect the frame for cracks. Make sure it’s solid everywhere.

If you have tuned the quad, try the stock tune to rule it out as a cause of vibrations. A quad on stock tune should not vibrate unless it is a very unusual setup.

If none of the above solves it, test individual components. If you have a firmware that allows motor testing, remove the props and spin each motor independently. Hold each arm while spinning its motor and feel the vibrations. If a particular motor vibrates, either try replacing the bearings or just put in a new one.

Quad falls out of the sky

Watch this video by Joshua Bardwell. Most likely it’s a motor and / or an ESCs.