Hi guys, I have an Cube Orange back in last year when it first released, and my friends recently got one too, and we all experience the same problems with copter4.0.2 and MP1.3.7, the problems we have is that every time when we try to change a lot of parameter at once like the PID and such, the cube will flash it self back with the default parameter values when reboot, even the Frame_class will reset to 0, we did reinstall the MP to the latest release to get the new drivers installed, also no matter what we just can’t get the compass calibrated, it all ways says compass inconsistent on the default setup, or sometime it just reset all the parameter to default when compass calibration done and requires reboot, it’s been an problem since back when the Copter4.0 still in beta, and now the problem it’s still there…
please check! and thanks for all the Dev team~
We’ve heard some reports like this (it’s even on our Copter-4.0 issues list) but we’ve had a hard time reproducing the issue.
I just tested myself now by changing 20 of the ATC_xxx parameters at once using MP’s Full Parameter Tree screen, then rebooted the board and all was as expected.
I wonder if you could provide some more detailed steps to recreate the problem?
thanks for replying!
I found that the issue mostly happen when using 3dr radio, but sometimes it still happen when using USB cable too, also I’m using Cube orange with an old Cube Carrier Board, but my friend who was using the ADSB Carrier have this problems too, don’t know if that matters?
and we’re both using the Full Parameter List to change value
I tried reproducing this using MP 1.3.70 and writing about 20 of the ATC_xxx parameters, then disconnected and reconnected the USB cable (to reboot the board) but again, no issues.
Do you think you could come up with a list of detailed steps to reproduce the issue? It may depend upon which version of ArduPilot and MP are being used so if you can tell me that as well that would be great. For example, in my test I used MP 1.3.70 build 1.3.7353.42041 and the vehicle had ArduCopter V4.0.3-rc1.
Ideally if you have an onboard log file from before and then another from after it has been reset to defaults that would be fantastic. It may be necessary to set LOG_DISARMED = 1 in order to create a log while the vehicle is disarmed.
Couple of experiments:
- does it happen only when on USB power or on battery power - or does it not seem to matter?
- does it matter if the radio is actually doing anything? If you set the relevant
SERIALn_PROTOCOLto zero - does the problem go away? - if you increase the streamrates does the problem happen more frequently?
- does it matter which serial port the radio is connected to?
I try to update to copter 4.0.3-RC1 today and everything starts working great, I even passed the compass calibration (it’s still take me two tries to get it works), I will try to downgrade back to 4.0.2 tomorrow and see if the problems really fix by updating, but before updating to 4.0.3 I do notice that if you unplug the USB cables without clicking the disconnect bottom then unplug the battery and then boot it up again it will increase the chances of getting all the parameters resets to default, also discover that my here2 GPS LED will goes dimmer when I plug in the USB cables, don’t know if that’s normal(?
I’m using MP1.3.70 build 1.3.7277.34800
LEDs dimming when USB is plugged in is normal; we found the lights too bright while the autopilots were sitting on our desks.
I’ve had this on a cube orange but can’t reliable replicate the issues.
Seemed to be worse when the cube was installed on a kore carrier board on an aircraft. It was resetting fairly regularly. Now it’s just a cube on my desk I’ve done about 50 Different changes using the full parameters list with a reboot between each one and the issue hasn’t come back. It’s never flown. Kept resetting during initial parameter configuring so the guys using it kinda lost faith and went back to a black.
If @proficnc or anyone else wanted to have a look at this particular cube I’m happy to ship it somewhere in return for a new one. More likely to be a software bug so the hardware probably won’t be any use.
Thanks for trying to reproduce the issue.
Some good news is that we’ve just received a PullRequest which includes a potential fix and a description of how it’s happening. It needs to be reviewed and tested but I suspect this is what’s going on.
thanks @rmackay9, @peterbarker
really looking forward to the next updates!
but if the problems really as the PullRequest describe, why you guys never get the same problems as us 
That is promising!
Not sure if it’s the same issue as there is definitely a functioning SD card installed.
Does the logic explained on the pull request fit for an orange cube? Does the cube and pixracer share the mentioned hardware?
Thanks again for the report. Re:
why you guys never get the same problems as us
We’re definitely not questioning whether the problem exists or not. I’ve seen the parameter reset problem myself and actually and mentioned it here on issue tracking this problem. I think what has slowed us down is reliably reproducing the problem so we can find and fix the issue. Anyway, hopefully we’re close to a fix now.
Hi All,
We have noticed the issue as well. It occurred with an orange cube on a Kore carrier board during setup of a new copter. The parameters were written to the cube while on the bench. The cube was then installed into the aircraft during assembly. On first power-up with batteries it was noticed that all of the parameters had been reset.
Log disarmed was enabled so we have a log file from before and after the even. The second log file has the parameters reset as well as a large gap that is not fully explained. It may have been when we were writing the parameter back onto the aircraft from a saved file.
We will try to reproduce the issue and isolate the steps required. We’ll be standing by to do more testing if there’s anything you’d like us to try as well.
Params Fine:
https://drive.google.com/a/bfdsystems.com/file/d/1KQgFmOq3dXyISp5hLDLZ0f0kEgF-itKo/view?usp=sharing
Params Reset:
https://drive.google.com/a/bfdsystems.com/file/d/1KXqD-c8N9IwvmxxhdatVrQeDGl21IR0u/view?usp=sharing
we really need to find a way to reproduce this so we can track it down. Does your comment imply that happened to you without a kore carrier?
Dan from spektreworks has tried to reproduce this using a Kore carrier but hasn’t had any success reproducing. If anyone who can reproduce it can please try to work out the minimum hardware setup to reproduce that would be appreciated.
I noticed a similar issue the last few days after upgrade to current stable, Orange Cube. Random disconnects, never happened before.
I noticed a similar issue the last few days after upgrade to current stable, Orange Cube. Random disconnects, never happened before.
Random telemetry disconnects or parameter resets? Which carrier board?
USB random disconnects, orange cube,Standard Carrier with ADSB. No parameter resets. Just, disconnects and I have to click connect again. The Cube not rebooting, just disconnecting. I haven’t changed anything in the computer I’m using. There’s now another update out so I’ll try that and if it’s still doing it I’ll report back.
@tridge Appologies for slow reply.
The guys setting up the copter using the kore carrier board were getting re-sets every few hours as they applied parameters during the config.
They swapped the orange for a new black cube on the same kore board and all works fine.
I have tried to replicate the param reset with just the cube on my desk with a USB cable but it is no-longer resetting in this configuration. I have another kore board on a box, I will try and see if I can make it reset again.
So as you may have heard, @tridge with help from UAV Exploration (an ArduPilot Partner) has gotten to the bottom of the parameter reset issue and the fix will be included in Copter-4.0.4 and Plane-4.0.6.
My understanding is the issue is that while the bootloader is active, one of the communication lines to the FRAM is “floating” which, in very rare cases, can lead to garbage data being sent into it which can cause a reset.
The solution is to update the bootloader so we’ve created a wiki page here which shows how you can do this in case you want to do this before the official release go out. We would appreciate some extra testing so if you give it a try please report back here on how it goes. Before you do this I have to warn you that bootloaders are a sensitive bit of code and there is a small possibility that you could “brick” your board.