Determining PixHawk FMU version

It appears there are different PixHawks out there with different FMU types.

FMUv2: Single board with STM32427VI processor (Pixhawk 1, HKPilot32, Pixfalcon, DroPix)
FMUv3: Identical to FMUv2, but usable flash doubled to 2MB (Pixhawk 2,Pixhack v3,mRo Pixhawk, Pixhawk Mini (Discontinued))
FMUv4: Increased RAM. Faster CPU. More serial ports. No IO processor (Pixracer)
FMUv4-PRO: Slightly increased RAM. More serial ports. IO processor (Pixhawk 3 Pro)
FMUv5: New processor (F7). Much faster. More RAM. More CAN busses. Much more configurable.(Pixhawk 4,CUAV v5,CUAV V5+,CUAV V5 nano)

Is there a command inside Mission planner that can be used to determine what type of PixHawk you have?

Is there any other way to determine if one has PixHawk 2.4.6 or PixHawk 2.4.8?

I’ve been lucky with both my pixhawks, they are both FMUv3, if you update the bootloader with mission planner or qground control then reflash the firmware it should switch it to FMUv3 if possible, if not it’ll stay as a FMUv2, both mine upgraded.

One is labelled a 2.4.8 and is in the black casing with white edge. The other doesn’t have a version number and is in all black casing (although I just opened it and the board is marked v2.4.8).

From what I understand though it doesn’t really matter, on Nuttx a few features had to be dropped but with the switch to ChibiOS (and also support for F4 boards with 512kb), it allowed all the features to be enabled again (and when I looked I wouldn’t have missed any of them anyway).

Thanks…But there has to be a way to send a command to the FMU via mission planner and get the exact details needed. The guess game is tricky in my opinion.

Some chinese manufacturer have faked 2.4.8 and sold 2.4.6 as 2.4.8 This is what I am trying to nail down. Even if something is written on the PCB board means nothing to me :slight_smile:

The problem we are having is that we can get this feature to work on one pixhawk and the other it doesn’t work. Both Pixhawk look the same from outside.

I guess the test that matters is if your Pixhawk has the 1mb limit or not. Apart from that there’s not much difference and everything should work the same, and Ardupilot should determine the correct FMU version itself.
You could set
BRD_TYPE,0 (auto)
and reboot to see what it detects. It’ll probably change to 2 (Pixhawk).

Yes, when I changed BRD_TYPE to 0 (auto) and reboot, it changed back to 2 (Pixhawk).

Thank you for yr help

I know Mission Planner can determine the FMU. How we humans can check by simple command? There has to be a way. All above solutions are based on not defined and correct electronic methods and subject to errors.

It does matter. If you have a Pixhawk with 1Mb flash it requires a reduced feature set. There are many boards with 1Mb flash. On those boards you will find this in the Hwdef (hardware definition) file:

Dave, I understand it does— matter. I just want to know how to verify this information what FMU is inside PixHawk.

Where do i find this file HAL_MINIMIZE_FEATURES 1?

It DOES matter. Locate your board here and review the hwdef.dat file. That statement is usually near the end.

So this file is stored on the SD card inside Pixhawk?

I tried the “NSH” method using the latest Mission Planner but its not giving me any data back.

Yes actually I think that only worked with Nuttx, sorry.

The only sure method is if you open your PIxhawk and check the revision of the main processor. If it is RevA, RevY and Rev1 then you have an 1M board, other (most likely Rev3) is 2M.


No, not stored on the card, used during the compile process to produce the correct firmware for the hardware present.

Until you update the bootloader both my FMUv3’s were detected as FMUv2. Once they bootloader was updated and I flashed them they were detected properly. The nsh command didn’t seem to work on chibiOS.

Thanks. I surprised that there is no soft command that can retrieve FMU type…oh well

ok. This kind of sucks. Has anyone ever looked into any type of command that can pull FMU type inside the PixHawk…Maybe we need to add this feature once in for all if supported by the FMU’s.

The 1Mb issue has been around for 5yrs or so and it really hasn’t presented a problem. Even before 3DR gave up the ghost making Pixhawk Flight Controllers they had transitioned to the Ver3 chip and all the cheap clones that followed did also. There are some exceptions and I have one. The HobbyKing HKPilot32 board had 1Mb. At least the one I have does. I install the Pixhawk1-1M and lack Lua scripting, Soar functions and Beacon and maybe something else I’m forgetting. Not a big deal. And with the F4/F7 bare type boards you know what you are getting.

1 Like

Why to do that, it only impacts a first couple of batches of and ancient, end of production flight controller.
The new bootloader can detect revision and will update the right firmware.

Regarding to 2.4.8 there is no such version of the pixhawk hw, cheap crappy chinese copies calling themselves 2.4.8 because they left out half of the components that supposed to be in a 2.4.6 hw. If you cut cost and buy a 2.4.8, then don’t be furious if you have to update the bootloader manually.

1 Like

There are three reasons we should have such a feature:

  1. Identify old purchases.
  2. Verify new purchases.
  3. keep my sanity checked when run into problems.

This should be standard feature inside PixHawk just like all other processor based devices.