I have been using this board and switch during years on a quad, having upgraded its bootloader time ago. It is not easily recognized at firmware upgrade, so I use QGC option custom (.apj file). K170725 led flashes, and stays fully on after pressing the safety switch.
Last fully normal use firmware I tried was 4.10 ‘latest’ dated 20210403.
At the field, K170725 led was off, the safety switch warning was heard, and pressing it nothing happened, so I did BRD_SAFETYENABLE=0 for flying.
At home, after changing K170725 and its cable nothing changed (led off), but flashing the previuosly working 4.10 ‘latest’ dated 20210403 the led flashed again, just after QGC finishes flashing, with only the USB cable connected.
On ‘latest’ 4.10 versions after 20210415 the problem persists. After trying any of them, going back to 4.10 ‘latest’ dated 20210403 all is normal again.
It seems there is some problem on this board around pins programming related to Radiolink buzzer/led/switch K170725, unless I miss something.
Great, thanks for testing 4.1 and reporting back. We’ve got one or two of these boards floating around with the dev team so hopefully we can get to the bottom of this.
I don’t have a solution but a question for you. I also have the radiolink but the v1.0 ii.
I can’t get is past the 4.0.3 update, will it be possible for the v1.0ii to upgrade to the newest firmware?
Here (first not working) appears: HAL_ChibiOS: fixed DMA sent calculation on UART DMA timeout
So may be this had a side effect on some pin functioning.
In the beginning I experienced some incompatibilities, which were solved upgrading the bootloader.
If you are familiar with electronics and have the board at hand, you can follow the method described here:
With power off, pull high boot0 pin and power on. This will put the chip in DFU mode.
Use some ST program to flash a mini pix arducopter_with_bl.hex version, through the USB connection (read ST documentation about DFU mode).
After that, for flashing I have always downloaded the arducopter.apj file from https://firmware.ardupilot.org → ArduPilot firmware : /Copter → (version) → mini-pix (or mini-pix-heli), and flashed it with QGC → Vehicle Setup → Firmware → Ardupilot → (connect with USB cable) → Advanced settings → Custom firmware file… → Ok → (navigate to downloaded arducopter.apj)
Let me say that I don’t know the exact version I have and it is mounted heavily buried. It was purchased from Aliexpress on sep. 5 2018, and on the order photo appears “V1.0” as above.
It has been working very well, and I am using it with current MP versions (not the Radiolink one).
You’re lucky - there are two versions of the the Mini-Pix v1.0 - the
original, which has the relatively expensve ramtron module on it, and the
new one, which doesn’t. The latter can run ArduPilot - but you need to
jump through some hoops to do it (and the hoops are on fire, as I
discovered today as I tried to jump through them again).
Honestly - not a great autopilot, but really cheap We’ve had these
things fail catastrophically in some interesting ways, and the vender
hasn’t abided by our license which requires them to supply source code for
binaries on products they ship.
I have got mine on banggood and the same photos was shown but when I received the mini pix the
“V1.0 ii” is printed on the plastic cover. The flight controller is still working fine with the 4.0.3 firmware, would like to have it up to date with latest firmware.
I was thinking just dump the mini pix and buy a new flight controller that is compatible with the firmware.
Although it seems that my version is previous, for flashing there could be no difference, as the two USB data signals should reach the processor directly. Anyhow, for flashing you should disconnect anything that could overload the USB supply pins (GPS/compass, rangefinder, display, etc). Updating the bootloader would be good.
On Ubuntu I have downloaded the latest QGC and tried again. Although other times I had observed (may be with other OS or other QGC version) that the board was not recognized and therefore chose a custom file, this time I observe that QGC recognizes the board and can program any version without manual intervention. This would be the full sequence:
As a side note, at the moment we don’t support the Radiolink MiniPix V1.0 II hardware. This is the manufacturer’s latest hardware that is missing the RAMTRON chip for parameter storage.
Maybe we will add support for the board in the future but there are no guarantees because the manufacturer isn’t cooperative. I’ve updated the warning on the wiki.
477ff7221403e05d7d0820be35ba715a9c073d6e is the first bad commit
commit 477ff7221403e05d7d0820be35ba715a9c073d6e
Author: Andy Piper <github@andypiper.com>
Date: Tue Mar 2 19:02:38 2021 +0000
AP_HAL_ChibiOS: allow dshot rate to be set so as to both regularize the output as well as
allow faster rates synchronized to the loop rate
synchronize 1Khz and use Betaflight definition for prescaler
adjust dshot bitrates
don't allocate IC DMA if already allocated
cancel DMA pulses correctly
try really hard to align pulses with push() by making each dshot pulse event driven
:040000 040000 9d717206bd1e30c6ecc4132408a502ff2a752b37 55cd19cdf821100425dbe61f82ba1651c6bc18f0 M libraries
@andyp1per - any ideas? I think these are just GPIOs, so I don’t understand why your patch would directly break things…
We’ve had these