## About
Out of PX4 supported boards, Matek H743-mini offers a benefit of small… size, meanwhile providing powerful computation power and RAM, and FLASH space. However, is quite experimental (and not documented), and thus I wanted to compile list of things I noticed were wrong with the board in this issue to keep record.
## Things that are not working
- [ ] Default board when connected to QGC shows up as "PX4 DurandalV1"
- [ ] Firmware flashing with "PX4 DurandalV1" detected isn't possible due to board ID mismatch
- [ ] After flashing the bootloader, upon reboot board is recognized as "PX4 FMU V6U" (to be confirmed)
- [ ] Flashing of the board isn't possible with default 57600 flightstack baud rate
- [ ] IMUs onboard are different from Manufacturer website's speficiation
I will explain each problems in detail in separate chapters.
### Board recognized as "PX4 DurandalV1"

This is happening because the USB connection (which supplies Vendor ID and Product ID) is returning **12642 and 75** each, which matches the "PX4 DurandalV1":
https://github.com/mavlink/qgroundcontrol/blob/a07c4c257db1147e2eaa24608304642870cabcdf/src/comm/USBBoardInfo.json#L27

And I can confirm this, because the `lsusb -v` shows that the Vendor ID and product ID of the board is detected like so.
:crossed_fingers: **Solution**: we need to fix the prodcut ID and vendor ID of the CDACM config in the `defconfig` of the bootloader here:
https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/nuttx-config/bootloader/defconfig#L33-L37
Note, however that after I changed that CDACM settings, I actually suffered from not being able to connect to the board for some reason, and had to revert those changes (maybe I didn't flash bootloader correctly :shrug:).
### Firmware flashing not possible due to board ID mismatch
```bash
Found board id: 139,0 bootloader version: 5 on /dev/ttyACM0
WARNING: Firmware not suitable for this board (Firmware board_type=139 board_id=1013)
```
This is occuring as we don't have the match between the "board_id" in the `firmware.prototype` setting (which gets baked into .px4 file), and configuration of the Board ID that gets baked into the bootloader in `hw_config.h`.
That is, these two files:
https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/firmware.prototype#L2
https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/src/hw_config.h#L99
**Solution** therefore is to change that `BOARD_TYPE` value, however, we need to figure out if 1013 is truly the correct value we should settle for (discussion below).
### After flashing the bootloader, upon reboot board is recognized as "PX4 FMU V6U"

This is happening because after reboot of flashing the new bootloader, vendor ID and product Id is now recognized as **7052 and 54** for some reason, which matches PX4 FMU V6U:
https://github.com/mavlink/qgroundcontrol/blob/fa9bf8a00fb064a8f4f9770894e1e019a581f72a/src/comm/USBBoardInfo.json#L17
The debug console of QGC shows the following info, which matches the assumption:

And it is really puzzling, as the steps are like following:
1. I re-flash the bootloader, and re-connect to QGC
2. QGC shows the board as "PX4 DurandalV1", and allows me to load .px4 firmware
3. After flashing and rebooting, when the board connects, the QGC detects the board as "PX4 FMU V6U" all of a sudden
This most likely means that during the .px4 binary flashing process, the Vendor ID and Product ID gets somehow re-written. And it does actually match the Product Id of the `nsh` (debug console), so I probably should test again the steps above with debug console disconnected, to make sure that QGC isn't detecting the debug console USB device first accidentally.
### Flashing of the board isn't possible with default 57600 baud rate
As noted in https://github.com/PX4/PX4-Autopilot/issues/21925, the board upload command:
`make matek_h743-mini_default upload` doesn't work, and I must call the script manually with 115200 baud rate setting:
`python3 Tools/px_uploader.py --port /dev/ttyACM0 --baud-flightstack 115200 build/matek_h743-mini_default/matek_h743-mini_default.px4`
This seems to just change the baud rate of the initial MAVLINK_REBOOT command being sent. However, I found that even with default flightstack baud rate, the reboot command seems to be received by the FC (shown on debug console), so not sure how this setting actually affects the flashing behavior :thinking:
### IMUs are different than the specification
According to manufacturer's website, the ICM42688-P (SPI1) and ICM42605 (SPI4) should have been included:

However, when I check the board, I found that it simply had two ICM42688P sensors :disappointed:.

Therefore I had to change the `rc.board_sensors` to:
```
# Internal SPI bus ICM-42688P (SPI1), PITCH180
icm42688p -R 12 -b 1 -s start
# Internal SPI bus ICM-42688P (SPI4), PITCH180_YAW90
icm42688p -R 26 -b 4 -s start
```
For which, figuring out the rotation enum was quite a pain haha
## Discussions
From the findings above, we arrive at some discussion points, which are:
### What is the correct Vendor ID and product ID of CDACM of Matek H743 Mini V3?
Currently, the [bootloader](https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/nuttx-config/bootloader/defconfig#L33-L37) has 0x3162 and 0x004b for each, and the [nsh](https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/nuttx-config/nsh/defconfig#L76-L80) (I guess this is for debug console, so doesn't really matter for user facing case?) has 0x1B8C and 0x0036 each.
The problem is that Matek doesn't officially have it's USB vendor ID registered in the USB database, like [holybro](https://the-sz.com/products/usbid/index.php?v=0x3162) has. So then it is both unclear which value it should really have.
There were some [discussion](https://github.com/PX4/PX4-Autopilot/issues/19443#issuecomment-1164559494) that vendor Id should be 0x120A (same as Matek GNS-M8N), and product ID 0x03f5 (1013, in decimal).
### What is the correct board ID for the Matek H743 Mini V3?
Assuming we decide on setting Board ID as 1013 for Matek H743 mini (as suggested [here](https://github.com/PX4/PX4-Autopilot/issues/19443#issuecomment-1164559494)), we then face problem of all other Matek H743 variants having the same board ID, for example:
https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743/firmware.prototype#L2
This is not ideal, as each unique board with unique firmware should have a different board ID, which is documented in [QGC](https://github.com/mavlink/qgroundcontrol/blob/a07c4c257db1147e2eaa24608304642870cabcdf/src/VehicleSetup/FirmwareUpgradeController.cc#L51-L56) as well as in [PX4-Bootloader](https://github.com/PX4/PX4-Bootloader/blob/3b381f660490aabfe9885323ce2fb4b0f7f622e6/board_types.txt#L1-L6).
So we should make decision on whether the MATEK H743 boards truly share the same board ID or not :shrug: