FAA NPRM: Effect of remote ID USS on Smart phone Batteries

Preliminary results: Battery drain impact of a Remote ID USS app on a smart phone

Summary: Adding a Remote ID USS data logging app to a smart phone being used to control a quadcopter is likely to increase the battery drain by 10 to 15 percentage points over 30 minutes of flying. The quadcopter control app itself may drain 30-40% of the battery over 30 minutes of flight; adding Remote ID USS mostly adds the power drain of additional GPS usage and cellular data transmissions.

The FAA envisions using a smart phone to relay data about a flight into an Internet-based Remote ID USS (logging database). This data includes information about the operator, including the operator’s location, and for Standard ID, the location of the small UAS. Remote ID only requires operator location and restricts the small UAS to flight within a 400’ radius of the operator.

I created a simple Android app to read the GPS location, once per second, and to transmit data over the cellular connection, once per second (data and destination simulated and not representative of an actual Remote ID USS). This simulates using a control app on the phone to both find the location and relay the data.

This app was run on a Google Pixel 2 phone, outdoors, for ten minutes, and connected to the Internet using T-Mobile service, which in my backyard, is a “2-bar” signal.

In ten minutes, this resulted in 13% of the battery’s capacity drained. A 30-minute logging sequence would presumably represent a 39% battery consumption.

In a second test, I used a Yuneec Breeze, which uses an app as the control interface for the quadcopter. Running this app for ten minutes drained about 10% of the battery, or an estimated 30% in 30 minutes.

In a third test, I intended to run both the remote ID USS simulator and the Yuneec Breeze control app simultaneously. However, the Breeze control app uses a Wi-Fi connection to the Breeze quadcopter, and appears to require that Mobile Data be turned off – hence, it was not possible to test sending data to a simulated Remote ID USS while controlling the Breeze.

UPDATE: The above issue – not being able to have WiFi and Mobile Data on simultaneously in this situation – may be an Android issue. The problem is that when WiFi is On, Android preferentially attempts to use WiFi to send data, instead of Mobile Data. This makes sense – its fast, does not cost anything to use (unlike cell service), and will typically use less power than Mobile Data.

The problem is that the WiFi link, when used to control a quadcopter, is not a regular Internet Access Point – its not connected to the Internet – just the quadcopter!

When an application running on the phone attempts to send Internet data, Android preferentially tries to send it to the WiFi port, which of course, is not connected to the Internet. This occurs even when Mobile Data is turned on – Android prioritizes use of the WiFi port, even if it is not connected to the Internet.

Depending on the version of Android in use, there is likely a setting to request that Mobile Data be used in place of WiFi (there appears to be in Android 10 but I have not yet tested this). In older versions of Android, this option may be hard to find or non-existent, rendering use of some Android phones as Remote ID USS relays as “not possible”. I will test this as soon as I can; today (February 1) however has high winds so I will not be able to conduct this test with my quadcopter in use.

Discussion

Smart phones have a (relatively) long battery life because they employ numerous tricks to keep the hardware powered down as much as possible, and to schedule software such that software is not running all the time. By keeping individual hardware components in a low power or unpowered state, as much as possible, the usable battery life between charges is increased tremendously.

The Remote ID USS, however, requires that the phone be kept in a high-power state, continuously during operation to measure the GPS-provided location once per second and to transmit data over the cellular network, once per second. Simultaneously, the control app is displaying a video feed arriving via WiFi data link, and keeping the display powered on.

The highest power consumption components of a smart phone tend to be the display, the cellular data transmitter when transmitting, Wi-Fi when transmitting, and the GPS receiver. The CPU also puts an increased demand on power, depending on the software that is running, and whether the CPU can run at a reduced clock rate, reduced power consuming state.

Consequently, it is not surprising that battery drain is high when using the phone to control a quadcopter, or when transmitting data to a simulated Remote ID USS.

Unfortunately, because it is not possible to test the Yuneec Breeze control app and the Remote ID USS simulator simultaneously, we do not know the specific power demand when both are running.

A reasonable guess based on these preliminary results is perhaps about 10-15% battery drain per ten minutes of flight time.

While it is tempting to think that battery consumption might be 13% (test app) + 10% (Breeze control app) that is an incorrect assumption. This is because most of the hardware is powered up regardless of which app is running – and adding the additional app does not change the hardware power (except the cellular transmitter and possibly the GPS receiver).

Additional battery consumption also occurred during initial set up linking the phone and the Breeze control app to the craft over WiFi and linking to the handheld flight controller over Bluetooth. You pretty much use up to 5% for the initial set up regardless of flight length.

It is a reasonable guess, at this point, that 30 minutes of flying time, with Remote ID USS underway, will drain 35-45% of the smart phone’s battery, with about 10+ percentage points of that being due to the Remote ID USS.

NOTE – and important – the cellular network controls the transmitter power of the cell phone. With a weaker signal, the transmitter power will be higher and the battery drain, greater. With a strong signal, the transmitter power will be lower, and the battery drain less. In marginal cellular coverage areas (which I hope to test), the Remote ID USS test app might see a much larger power drain.

NOTE – the percentage battery drain also depends on the phone in use. Each phone has different hardware components, different power management strategies and a different battery capacity.

UPDATE: NOTE – if the phone is doing Remote ID logging only, and not running a control app, the battery drain will still be high and similar to if running a control app. Again, whether the phone is running just the control app, or just the remote ID logging app, the battery drain will be similar because both are keeping most of the phone’s hardware powered on.

On “The order of results”

Again, since I can’t run the simulator and the Breeze app at the same time, these should be viewed as preliminary and only an “on the order of” result. Because this is preliminary, please do not quote these results online as a definitive result – this is not a definitive result. This is merely a glimpse. It kind of, sort of, looks like adding Remote ID might additional 10+% battery drain over 30 minutes of flight in the presence of a reasonable cell signal.

And the actual amount will vary depending on the model of phone in use, the model of quadcopter in use and its control app, and the cellular signal strength.

Finally, is it feasible to simultaneously have the phone connected to a charging source? Kind of. Because the phone goes in a phone mount on the controller, connecting a charging cable is a bit cumbersome. A second issue depends on the maximum charge rate of the phone. Several years ago, I found many phones could consume power internally faster than they could accept power through the charging port. Today’s phones may accommodate 2-3 amps (at 5 volts) of charging current, although this may still be less than the amount of power the phone is consuming during these high-power states.

Leave a Reply

Your email address will not be published.