Tested several time a cube Orange (stand alone, no GNSS …). Powering on and off via USB from Laptop. Done some parameter changes for a quadcopte. After sometime doing powering off/on all the changed parameter values are set back to standard quadcopter. This issue accurs two times during one day.
I think fix was to update boot loader.
Does the Cube ask you to re-calibrate in Mission Planner?
By the way, the most common cause of the problem is bytes from the telemetry radio flowing into the autopilot as it is booting up. In very rare cases these bytes can cause the wiping of the eeprom.
Yes, he does - starting with selecting the right frame class and so on …
Thanks a lot to all for the help
How long does it takes to update the bootloader? In my cases immediately after clicking “Bootloader update” the message “Uploaded bootloader” occurs. Is that correct?
Would setting TELEM_DELAY,2 help?
I thought about this while typing, and figure the FC needs to be fully booted up before any params take effect anyway - so I guess not.
As you guessed, setting the telem_delay parameter won’t help. In fact, the main ArduPilot flight code isn’t even running yet when the troubles happen. It’s all in the bootloader. The fix is for the bootloader to hold one of the eeprom chip’s pins high so that it doesn’t listen to the bytes arriving in on the serial port. I can’t quite remember how the bytes from the serial port reach the eeprom chip…
Didn’ fix at 100% I had again a parameters reset in a cuble black after update boot loader with 4.0.4 rc3
Randy, can it help, when I turn on the plus pole of the telemetry parts with an external switch after the cube has booted?
@Axel_Weckschmied, it could help but we think the bootloader change already resolves the parameter reset issue caused by the external telemetry point receiving data during startup. It is likely that there are a number of different ways that parameter resets can happen. We’ve resolved the causes that we know about but as @Agridroni has reported we have had (a smaller number of) resets even with this fix in place (I’ve had one myself).
One of the real challenges of this parameter reset issue is that it’s quite rare. Once someone can regularly reproduce the issue we can work with them to fix it… but most often the person sees the issue one or twice and then doesn’t see it again for months.
I too have had this issue while testing a hexacoppter with a cube black.
Fortunately we would record all parameters after a change and could reload the desired settings.
I would notice some odd behaviour like poor handling so would land and look at the param and compare to find a lot of default settings Re applied. As Randy mentioned, after many flights ( and rechecking Params before taking off) it hasn’t reoccurred for a long time.
I had this issue today, in my case it was a cube orange with the ADSB carrier board, arducopter 4.0.3 after power on with a USB cable. Before that (yesterday), after a marginally succesful flight I recalibrated the IMU with the solex app on my herelink (because the drone was drifting a little too much in non gps modes) and rebooted the cube, everything was looking normal. Then I disconnected the batteries and went to sleep. So I guess the parameter reset happened this morning after I plugged the USB cable.
Do we know if this happens with USB connection only? or is it possible to have the parameters reset while powering on the cube with the power module?
Also I would like to know if I will have to calibrate IMUs or compasses again if I upload the bootloader and then go back to arducopter 4.0.3.
I would very much appreciate your help with these questions.
Did you updated the bootloader like described on this page below ?
Not with that one, but I had the same issue today, another set of the same hardware, running arducopter 4.0.5. I thought the bootloader update was included in arducopter 4.0.4 and higher.
Has this issue with Cube Orange and arducopter 4.0.5 yestersay (11-16-2020). It’s worrying. What can I do to prevent this from happening in the future?