Skip to main content

MA-RTK-AIR-626 for Drone Light Shows — Fix the Skybrush TIMESYNC Warning

The MicoAir MA-RTK-AIR-626 is the low-cost centimeter-level RTK module built for drone swarms and light shows. With the official Skybrush firmware, though, every drone carrying a 626 shows a yellow TIMESYNC warning in Skybrush Live, even though its position and RTK fix are perfect. This page explains why, and gives you free Skybrush 4.6 firmware for 20 flight controllers that fixes it.

Short answer: the 626 never sends the GPS week number, so the flight controller never has a valid GPS time. Install the Robofusion Skybrush 4.6 build for your exact flight controller, keep GPS_AUTO_CONFIG = 0, and the warning goes away. Nothing on the 626 itself changes.

Unofficial firmware — test fly every drone before a show

These builds are made by Robofusion from the public Skybrush source with one published change. The MicoAir743v2 build has been confirmed on a customer's Skybrush fleet. The other targets are build-verified only: they compile, fit in flash and contain the fix, but we have not flown them. Fly a normal test with the new firmware on every drone, and confirm the checks in step 6, before you use it in front of an audience. You use this firmware at your own risk. It is not affiliated with or endorsed by the Skybrush project or ArduPilot.

Who needs this?​

You need this page if all three of these are true:

  • your drones use the MA-RTK-AIR-626 RTK module,
  • they run Skybrush firmware (Skybrush's ArduCopter build, "CMCopter"), or any other ArduPilot setup that needs a valid GPS time,
  • Skybrush Live shows a TIMESYNC warning on those drones.

You do not need it with the MA-RTK-AIR-982 or MA-RTK-AIR-F9P. Both give a valid GPS time on the official firmware.

What the problem looks like​

  • Skybrush Live shows a yellow TIMESYNC (time synchronization) warning for each drone with a 626.
  • The GPS has a 3D fix or an RTK FIXED solution, and pre-arm checks pass.
  • Mission Planner shows a correct position, but the drone's GPS date and time are missing or nonsensical, and logs have no real UTC timestamps.

A light show depends on every drone starting the show clock at the same instant. Skybrush takes that clock from GPS time, so a drone without a valid GPS time cannot be trusted to stay in step with the fleet.

Why it happens​

Diagram: a standard u-blox receiver sends NAV-PVT and NAV-TIMEGPS so ArduPilot gets a valid GPS time; the MA-RTK-AIR-626 sends only NAV-PVT so the GPS week stays 0 and Skybrush shows TIMESYNC; the Robofusion build works out the week from the UTC date in NAV-PVT

A few terms first:

  • UBX is the binary protocol of u-blox GPS receivers. The 626 uses a Unicore UM626N receiver, but it speaks a u-blox-compatible subset of UBX so that ArduPilot treats it as a u-blox GPS.
  • NAV-PVT ("position, velocity, time") is the main UBX message. It carries the position, the time of week and the UTC date and time.
  • GPS time is counted as a week number since 6 January 1980 plus the time of week in milliseconds. A flight controller needs both to know the absolute time.

ArduPilot's u-blox driver takes the time of week from NAV-PVT, but it takes the week number only from two other messages, NAV-SOL or NAV-TIMEGPS. A real u-blox receiver sends those. The 626 sends only NAV-PVT, and its firmware cannot be told to send anything else. So the week is never set, it stays at 0, and the flight controller never reports a valid GPS time. Skybrush sees that and raises TIMESYNC.

Two things that look like fixes but are not:

  • Changing GPS parameters. GPS_AUTO_CONFIG must stay 0 on the 626, as the MA-RTK manual explains: the module ships pre-configured, and letting ArduPilot reconfigure it would overwrite that. And even with auto-configuration on, the module cannot add the missing messages.
  • Updating the 626. The UBX output is fixed in the receiver module's own firmware. There is no user setting or update that adds NAV-TIMEGPS.

That leaves the flight controller side, which is what the Robofusion build changes.

What the fix does​

The firmware is the unmodified Skybrush CMCopter-4.6 source (ArduCopter V4.6.3) with one change in the u-blox GPS driver:

  • If the receiver has never sent a GPS week, the driver works the week out from the UTC date and time inside NAV-PVT.
  • The result is rounded against the receiver's own time of week, so a leap-second difference of a second or two cannot put it in the wrong week.
  • It only acts when NAV-PVT flags its date and time as valid. Until then nothing changes.
  • As soon as a receiver does send NAV-SOL or NAV-TIMEGPS, the driver uses that instead, exactly as before. Other GPS modules are not affected.
  • When it takes effect, the flight controller prints one message: u-blox 1: GPS week XXXX from NAV-PVT date.

It adds about 300 bytes to the firmware. The full source change and build record are published with the downloads; see technical details.

Step 1: Identify your flight controller and Skybrush version​

Every flight controller type needs its own firmware file. Find the exact board name before you download anything.

  1. Connect the drone to Mission Planner with its current firmware.

  2. Open Flight Data → Messages. If the start-up lines have scrolled away, disconnect and connect again.

  3. Look for lines like these (your values will differ):

    ArduCopter V4.6.3 (5263d784)
    ChibiOS: 6a1f2d9c
    MicoAir743v2 0031002A 33335110 35353936
    • The first line is the firmware version. These downloads are for 4.6 (ArduCopter V4.6.x).
    • The line with three groups of eight hex digits is the board line. The word before them is the board name, here MicoAir743v2. That word must match the board name in the file you download.
Running Skybrush 4.5 or 4.7?

The files below are built from Skybrush 4.6. If the first line shows 4.5 or 4.7, ask us for a matching build instead of changing version at the same time. Going from 4.7 back to 4.6 in particular is a downgrade: parameters renamed in 4.7 are not converted back.

Step 2: Download the firmware for your board​

Release r1, built 2026-10-19 to 2026-10-22 from Skybrush CMCopter-4.6 commit 5263d784 (ArduCopter V4.6.3). Use the .apj file. The _with_bl.hex file is only for the DFU fallback in step 4.

Flight-proven means confirmed on a customer's Skybrush show fleet. Build-verified means the file compiles, fits in flash and contains the fix, but has not been flown yet.

Your flight controllerBoard nameBoard IDStatusFirmwareDFU fallback
MicoAir H743 V2MicoAir743v21179Flight-proven.apj_with_bl.hex
MicoAir H743 V2 AIO 45AMicoAir743v21179Flight-provensame file as the H743 V2same file as the H743 V2
MicoAir H743 AIO 35AMicoAir743-AIO1176Build-verified.apj_with_bl.hex
MicoAir F405 V2MicoAir405v21150Build-verified.apj_with_bl.hex
MicoAir F405 MiniMicoAir405Mini1161Build-verified.apj_with_bl.hex
NxtPX4 V2NxtPX4v21159Build-verified.apj_with_bl.hex
Cube OrangeCubeOrange140Build-verified.apj_with_bl.hex
Cube Orange+CubeOrangePlus1063Build-verified.apj_with_bl.hex
Cube Black (Pixhawk 2.1)CubeBlack9 ⚠Build-verified.apj_with_bl.hex
Pixhawk 1 (2 MB flash)Pixhawk19 ⚠Build-verified.apj_with_bl.hex
Holybro Pixhawk 6C / 6C MiniPixhawk6C56Build-verified.apj_with_bl.hex
Holybro Pixhawk 4Pixhawk450 ⚠Build-verified.apj_with_bl.hex
Holybro Pixhawk 4 MiniPH4-mini50 ⚠Build-verified.apj_with_bl.hex
Holybro DurandalDurandal139Build-verified.apj_with_bl.hex
Matek H743 (WING / SLIM / MINI)MatekH7431013 ⚠Build-verified.apj_with_bl.hex
Matek H743, bidirectional DShot buildMatekH743-bdshot1013 ⚠Build-verified.apj_with_bl.hex
QioTek Zealot H743QioTekZealotH7431036Build-verified.apj_with_bl.hex
SpeedyBee F405 V3speedybeef4v31082Build-verified.apj_with_bl.hex
SpeedyBee F405 V4speedybeef4v41136Build-verified.apj_with_bl.hex
Generic FMUv3 boardfmuv39 ⚠Build-verified, ask us first.apj_with_bl.hex
Generic FMUv5 boardfmuv550 ⚠Build-verified, ask us first.apj_with_bl.hex

⚠ = board ID shared with other targets; read the warning below.

Check your download. SHA256SUMS.txt lists the checksum of every file. On Windows run certutil -hashfile <file> SHA256; on macOS or Linux run shasum -a 256 <file>. The result must match the line for your file.

MicoAir AIO boards: 45A and 35A use different files

The H743 V2 AIO 45A uses MicoAir743v2, the same file as the standalone H743 V2. The MicoAir743-AIO file is only for the older H743 AIO 35A. Flashing the 35A file on a 45A board is refused by Mission Planner. If you are not sure which board you have, the H743 AIO manual shows how to tell them apart.

Step 3: Back up your parameters​

In Mission Planner: Config → Full Parameter List → Save. Keep one file per drone, named after the drone, for example drone03-before-626-fix.param. You need it if anything is reset and to roll back.

Step 4: Install the firmware​

  1. Connect the drone by USB. Do not click Connect in Mission Planner, and close Skybrush Live or any other program that is talking to the drone.
  2. Setup → Install Firmware.
  3. Click Load custom firmware (bottom right).
  4. Select the .apj file for your board.
  5. Follow the prompts. Mission Planner may ask you to unplug and re-plug USB. Wait until it reports the upload is complete and the board reboots.

If Mission Planner shows an error, note its exact text. "Board ID mismatch" means the file is for a different board: go back to step 1. "No response from board" usually means a charge-only USB cable, a hub, or another program holding the port.

If the normal method fails: DFU​

Use this only when the normal method keeps failing.

  1. Make sure you have the parameter backup from step 3. A DFU flash can erase parameters.
  2. Hold the BOOT button while plugging in USB. The board appears as an "STM32 BOOTLOADER" device.
  3. Flash the _with_bl.hex file for your board with STM32CubeProgrammer, MicoConfigurator or dfu-util. The Firmware Flashing Guide walks through DFU in detail.
  4. Unplug, re-plug, connect with Mission Planner and restore the parameter file if the parameters were reset.

Step 5: Check the parameters​

  1. Reconnect and open Config → Full Parameter List.
  2. Confirm your parameters are still there. Compare with the backup if in doubt.
  3. Confirm GPS_AUTO_CONFIG = 0.
  4. Confirm the GPS settings are unchanged: GPS1_TYPE (1 = auto or 2 = u-blox), the SERIALn_PROTOCOL and SERIALn_BAUD of the GPS port, and your RTCM / RTK settings.
  5. If anything was reset, Load the backup file and Write Params, then reboot.

Step 6: Verify outdoors​

With the drone outdoors and a GPS fix:

  1. Messages shows, once per boot, a line like u-blox 1: GPS week 2441 from NAV-PVT date. The number is the current GPS week (about 2440 in October 2026).
  2. The yellow TIMESYNC warning is gone in Skybrush Live.
  3. The UTC time the drone reports matches real UTC within about a second.
  4. Position, RTK status and pre-arm checks behave exactly as before.
  5. Fly a normal test flight on every drone before using the firmware in a show.
No GPS-week message after a few minutes with a fix?

The fix only acts when NAV-PVT marks its UTC date and time as valid. If you have a 3D fix for several minutes and the message never appears, contact us with a screenshot of the Messages tab rather than flying a show.

Rolling back​

  1. Setup → Install Firmware and install the official Skybrush firmware for your board again.
  2. Config → Full Parameter List → Load your backup file, then Write Params.
  3. Reboot and check the GPS settings.

Easy to confuse​

Mission Planner will not catch every wrong file​

Every firmware file carries a numeric board ID, and the bootloader on the flight controller refuses a file with a different ID. Some targets share an ID, so the check cannot tell them apart:

Board IDTargets with this ID
9Pixhawk1, CubeBlack, fmuv3
50Pixhawk4, PH4-mini, fmuv5
1013MatekH743, MatekH743-bdshot
1179MicoAir743v2, used by both the H743 V2 and the H743 V2 AIO 45A (the same file, so this one is safe)

A wrong file from the first three groups installs without complaint and then runs with the wrong sensors or outputs. Always match the board name from the Messages tab exactly, and do not use fmuv3 or fmuv5 unless we have told you to.

.apj or _with_bl.hex?​

The .apj contains only the firmware and is what Mission Planner's "Load custom firmware" expects. The _with_bl.hex contains the firmware and the bootloader, and is only for DFU recovery. It overwrites the bootloader, so use only the one for your exact board.

Skybrush and ArduCopter version numbers match​

Skybrush 4.6 is ArduCopter 4.6 with Skybrush's show additions. The first line in Messages tells you which you have.

The firmware version text does not change​

After flashing, Messages still shows ArduCopter V4.6.3 (5263d784). The GPS-week message in step 6 is how you know the fix is installed.

Need a different board or version?​

If your flight controller is not in the table, or your fleet runs Skybrush 4.5 or 4.7, email support@robofusion.net with:

  • a screenshot of the Mission Planner Messages tab right after connecting (you can blank out the serial number),
  • the product name of the flight controller,
  • how many drones, and the date of the show if there is one.

We build from the same source, so a new target is usually quick. Boards with only 1 MB of flash may not have room for Skybrush.

Alternatives that need no custom firmware​

If you would rather stay on official Skybrush firmware, choose a module that sends the GPS week itself:

ModuleWhy time works on official firmwareTrade-off against the 626
MA-RTK-AIR-F9Pu-blox ZED-F9P sends the GPS week natively; PX4 also supportedhigher price per drone
MA-RTK-AIR-982ArduPilot's Unicore NMEA driver takes the date from the NMEA messages; triple-band, dual-antenna headinghigher price and power per drone

For a large fleet the 626 with this firmware is usually the cheapest way to centimeter positioning; one base station serves every drone.

Technical details for developers​

  • Base: Skybrush ArduPilot branch CMCopter-4.6, commit 5263d78433d4ed909f9394c84cf557b32bcdbcb5 (ArduCopter V4.6.3).
  • Change: robofusion-pvt-gps-week.patch, touching only libraries/AP_GPS/AP_GPS_UBLOX.cpp and .h.
  • Week calculation: week = round((unix_seconds + leap_seconds − 315964800 − iTOW_seconds) / 604800), where unix_seconds comes from the NAV-PVT UTC date and time and 315964800 is the GPS epoch (1980-01-06) in Unix time. Rounding to the nearest week makes a leap-second offset harmless.
  • Testing: an independent test of the formula passes 1,305 cases, covering ordinary dates from 2020 to 2099, the seconds around GPS week rollover (Saturday 23:59:42 UTC), receivers whose leap-second count differs by up to ±2 s, and sub-second offsets. In ArduPilot SITL with a simulated receiver that sends only NAV-PVT, the patched driver reports the correct week and a valid UTC time, while the unpatched driver reproduces the missing GPS time. On hardware the fix is confirmed on a customer's Skybrush fleet flying MicoAir H743 V2 and H743 V2 AIO 45A boards.
  • Build record: toolchain, flash headroom per board and checksums are in BUILD_INFO.md; the build script rebuilds any board.
  • License: ArduPilot and Skybrush are GPLv3, and so are these builds. The source folder README has the complete corresponding source and the commands to reproduce a build.

FAQ​

Does the TIMESYNC warning mean my RTK is not working? No. Position and RTK are unaffected. Only the absolute time is missing, and Skybrush needs that to keep a show in step.

Will this firmware change how my drones fly? No. The only change is in how the GPS week is worked out. Flight control, Skybrush show handling and every other part are the unmodified Skybrush 4.6 source.

What happens if I later fit a different GPS? Nothing special. Receivers that send NAV-SOL or NAV-TIMEGPS are handled exactly as in the official firmware, and non-u-blox receivers use their own drivers.

Can I use the 626 with PX4? No. The 626 is supported on ArduPilot only, and this fix is for ArduPilot-based firmware.

Do I need one firmware file per drone? One file per flight controller type. Every drone with the same flight controller uses the same file.

Is there a fix for official Skybrush coming? We have submitted the change to ArduPilot as pull request #34848. Whether and when it is merged, and when Skybrush picks it up, is up to those projects. Until a release includes it, use these builds or a module from the alternatives.

Where to buy​

Buy from the Robofusion store
MA-RTK-AIR-626 — budget RTK for swarms & light shows
View in store →
MA-RTK-BASE Kit — one base station for the whole fleet
View in store →
RTK Complete System Bundle — base + 626 rover + LR900-F radio pair
View in store →
MicoAir H743 V2 flight controller (MicoAir743v2 firmware)
View in store →
MicoAir H743 V2 AIO 45A (MicoAir743v2 firmware)
View in store →

Volume pricing for 10 or more modules is available: email info@robofusion.net with your fleet size. Ships worldwide from the Robofusion Hong Kong warehouse.

Written and maintained by the Robofusion engineering team.

Last updated on