Hacking GPS into the Meteor 75 Pro, a tiny FPV drone

Following on from my previous article I added GPS¹ (well, GNSS) to my tiny drone – the Meteor 75 Pro. I wanted to add GPS so I could make use of GPS rescue in betaflight as well as see the altitude, speed and distance in the OSD.

All the terminology mentioned in this article is covered by my previous post if you’re in need of clarification.

GNSS modules

The most common modules are from uBlox, with the latest using the M10 chipset which is in improvement on the M8 for lock speed and number of satellites. They are able to use 4 different satellite networks: GPS, Galileo, GLONASS and Beidou.

For drones, these chipsets are packaged on a small PCB with a ceramic patch antenna with a focus on low weight and size.

Larger modules may have better performance, and may include extras such as power supply filtering plus a barometer/compass. The latter allows for better positioning information.

I chose the RUSHFPV Micro M10 module because it was tiny and using the latest chipset. At around 2.5g, it won’t add anywhere more weight than the 5g extra that the digital Meteor has.

Wiring to the flight controller

Looking at the flight controller on the Meteor 75 Pro, there seemed to be a spare UART2 at bottom right, denoted by T2 and R2.

After the module arrived, I discovered that the T2 pin was a UART, but used to configure the video transmitter (frequency and power). The only other UART was in use with the Express LRS receiver. Frustratingly, other versions of the Meteor come a spare UART as the receiver uses SPI instead.

Despite this, I wondered if there was another option – software serial. This allows the microcontroller to emulate a real UART with some limitations: it will be slower, and also unbuffered meaning the processor has to spend a lot of time synchronously sending/receiving data.

Given flight control relies on a lot of processing and a right loop, combined with so many peripherals, this means it’s easy to end up with an overloaded CPU and stuttering flight performance.

GNSS modules need to operate at a high baud rate for frequent-enough updates to be useful for GPS rescue, so it’s not possible to use a software serial port for GPS with any kind of reliability.

The video transmitter however is far less demanding. If I could find an unused microcontroller pin, I could potentially assign the video transmitter to that instead with software serial assuming there are no resource conflicts.

I re-wired the drone to use the video transmitter on a software serial port, using the unused pin (bottom left) marked LED.

I added the module at 90 degrees to the camera, so that in cruising flight the GPS antenna would be facing straight up at the sky. In the end, 2 bits of VHB tape were required to get the module to stick – applying one to the module, the other to the drone then joining. Else you’re one crash away from a flailing module.

Configuring Betaflight

Betaflight has a resources concept that allows re-assigning pins to different functions, providing the microcontroller has the hardware within to support it.

Generally a microcontroller’s pins are grouped into ports, and each port may have a number of timers, UARTS, DMA controllers etc. This means if you’re using the same port for more functions than available resources (despite having the pins) then you’re in trouble.

To see what resource is mapped to what pin, you can use the resource command in the betaflight CLI. With this command (but strangely not resource show all) it shows that pin A08 has LED_STRIP duty, so I presumed this is the LED pin on the board.

To re-map it to a software serial port, I used the resource command:

resource LED_STRIP 1 none
resource LED_STRIP 1 A08
resource SOFTSERIAL_TX 1
A08  # was B03 save

As above it’s necessary to unbind the previous resource else there will be a conflict.

After this, I couldn’t see a new softserial UART appear in the ports tab, which makes sense, as the UART was already mapped. I had to enable SOFTSERIAL in the Configuration tab, then the new UART appeared. After this is was a simple task of moving the VTX control to SOFTSERIAL1 and choosing GPS as a sensor for UART1.

After enabling GPS and checking the newly added GPS tab, I could see the module was talking to the flight controller. I enabled Galileo support, as well as Ground assistance type auto for increased accuracy.

I also configured the failsafe tab to enable GPS rescue, as well as tweaked the GPS rescue settings according to this article. I assigned a manual GPS rescue mode to a channel corresponding to a switch on my transmitter.

Next I configured the OSD to show the GPS data I wanted: speed, distance, altitude, home position and number of satellites. I also had to change the units with the CLI to read in MPH:

set osd_units = BRITISH save

Great! Or so I thought. After an attempted test flight I realised I couldn’t arm the drone. The error message in the OSD read DSHOT_BBANG. Investigating, I opened the Motors tab and got a strange error message indicating there was no data coming back from the motor controllers: “Mixer mode problem detected.”

After searching around, there were some github discussions around the DSHOT settings. DSHOT is a serial protocol used to communicate with the motor controllers. I gathered this was probably a resource conflict – and indeed unassigning the VTX from the doft serial port fixed the conflict so the drone could fly; however this meant giving up VTX control so I could not change the channel or power, worse yet low power mode on disarm would not work meaning the VTX could overheat more readily.

Said conflict can be seen if you list timers with timer show:

Another post suggested if I disable DSHOT_BBANG (which I’m guessing is a mode that needs a timer to talk to the motor controllers) I could free the conflict:

set dshot_bitbang = OFF save

This, together with re-enabling the VTX control resulted in a working drone again. Despite this, there was another issue. The OST read CPU_OVERLOAD – the new software serial port was causing the CPU to be overloaded apparently. This could result in the control loop pausing, resulting in stuttering flight or worse – crashes.

I figured I would mitigate the issue by overclocking the CPU:

set cpu_overclock = 120MHZ save

This seemed to work, except the gyroscope was broken and the drone wouldn’t arm. So much for that. I could set it to 104MHz, which might be stock – not sure.

Anyway, betaflight was now configured and the drone could fly!

Defeating interference

Unfortunately, even after 20 minutes I couldn’t get any satellites – GPS rescue needs a minimum of 8 to function. There must have been too much interference from the video transmitter.During this time I had to keep a small fan next to the VTX unit to prevent it from overheating.

Later I realised I could just arm the drone to cool the module down, the idle fans didn’t use much power and are effective. If you do this, make sure you don’t accidentally nudge the throttle and cause the drone to fly off into the distance to be lost forever. Ask me how I know…

The next thing I tried was to use some metal shielding to block out interference – I tried some aluminium tape. No satellites. I had to try something different!

I designed a gantry in OpenSCAD that would hold the GPS module at 30 degrees, using 1.7mm self-tapping screws for the first time. The gantry was solid, but I only managed to lock on to 4 satellites.

In a last-ditch attempt, I tried another gantry without any angle, so that module had its back to the VTX. This worked really well! 8 Satellites in 5 minutes.

Following this I noticed the GPS would lock to 9 or 10 satellites about 30 seconds after booting up. This is because the module has a backup battery to remember the last known positioning data.

It was satisfying to see the OSD with much more information. I was able to find I could reach 30mph in a straight line, and to get an idea of altitude and distance was useful.

I also tested the GPS rescue mode, which worked reasonably OK after doubling the maximum speed.

…defeat

Unfortunately the flight performance really suffered with the oversize gantry. It would wobble around quite a lot when maneuvering, and of course it was more difficult to store away and transport.

In a last attempt I mounted the module at the front, hoping it was far enough away from the VTX. Alas, no satellites. I removed the module and undid the hacks.

Nonetheless this was an interesting journey and I now have a bit more experience with GPS and betaflight. GPS would be great on a larger drone, but despite looking good on paper, it’s not a suitable thing for a tiny whoop.

Thanks for reading! If you have comments or like this article, please post or upvote it on Hacker news, Twitter, Hackaday, Lobste.rs, Reddit and/or LinkedIn.

Please email me with any corrections or feedback.