LibrePilot Forum
Users => Vehicles - MultiRotors => Topic started by: thedeadlink on November 25, 2018, 11:41:36 pm
-
Hi everybody,
I´m new here and I´m building my first quadro copter. Since the drone crashed while the first test flight in the garden it didn´t start anymore. One motor didn´t spin up anymore.
I decided to buy everything new to have spare parts. (the CC3D flight controller, the ESCs and the motors).
But now I have issues with configuring the new CC3D (I still do not know if the first one has a defect - I´m still figuring out what could be wrong).
I tried to use the wizard to configure the new CC3D - when I try to save the configuration it hangs.
Even when I try to configure everything by hand it doesn´t let me save the setting.
I checked the armed state in the systems tab in "flight status" - it says "Disarmed".
Is there anything I can do?
-
CC3D firmware version must match GCS version. You must Upgrade and Erase. Did you do that to start with?
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab
Once you have the same version running in both places and you have done Erase, a simple test is to change one setting, save it (did that work with no error?), power CC3D off and on, and check the setting to see if it is still what you changed it to.
-
Hi. Sorry for the late reply. I didn´t had the chance to look after this issue until now.
Yes. I first did an "upgrade & erase" and it worked fine.
Then I also tried to change just one setting and then saved it - but it did not work.
I recorded a short video about this issue:
(cliff changed this to youtube.com so it would display here in forum)
https://www.youtube.com/watch?v=NYoMmW8yh48
-
Be aware that the fast LED blinking is gyro init (bias) and 16.09 and higher will automatically wait for the CC3D to be completely motionless (in a rotation sense) before the init will complete.
Two things come to mind. I am not an expert on CC3D, but these at least won't hurt:
- You may need to update the bootloader. Be aware that after updating the bootloader by using a bu* file you must reflash the firmware (Upgrade and Erase) starting by using Manual method.
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab
- It may be that setting the arming is not allowed until you have other things set up correctly. For instance, there is no throttle channel defined, so it can't do "low throttle and pitch up" for arming. Setting the arming is the last thing you do in setup. Try some simple changes on the Hardware page.
-
Looks like the board have a issue with external flash memory, the flash erase process after a Upgrade&Erase will take more time with blinking led one time per second. This Erase/Formatting step seems not done in your case.
When you save a setting, the save button shows a red cross so at this time GCS already report a problem while saving setting.
Take a magnifier and look if you can see a bad solder join around the chip (8 pins) located between Main and FlexiPort.
-
Try flashing the firmware attached :
- Rescue button
- Connect board
- Load firmware attached
- Flash
- Disconnect board
After reconnecting the board, you will see a blink sequence (one per second) for around 20s.
If this sequence is done, try again after updating the firmware using the GCS and Upgrade button, as usual.
-
Is there a problem with 16.09 "Erase Settings" that maybe Rescue -> EraseSettings -> WaitFor30Seconds does not fix?
Just CC3D? Or other FC's too? Is it related to "Wait until the board Is steady"? Watchdog?
-
There seems to be an issue there.
My CC3D has been originally used with 15.09 then upgraded to 16.09. I had some issues then (which were due to the PC side), and tried erasing and downgrading back to 15.09. The downgrade didn't work at all, so I switched to 16.09 again.
Now my CC3D is not able to save it's config in many key areas. Simple repro for my board:
1) Update&Erase (clean 16.09)
2) Go to Configuration -> Hardware
3) Switch Receiver Port to Disabled+OneShot
4) Save -> red "X" shows and change does not persist on reboot
Attached is my settings file - can be uploaded to CC3D but many key attributes are lost on reboot.
Michal
-
"CC3D worked OK in 15.xx but not in 16.09" is often a Bootloader version issue.
What is your Bootloader version?
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab#FirmwareTab-Updatebootloader
If not Bootloader, did saving work with 15.09? Is it possible that it is crash damage? :)
-
The 15 vs 16 thing was the other way around. First 15.09 worked flawlessly, then I tried 16.09 and downgraded to 15.09. Upon downgrade, 15.09 didn't even start (one LED on, the other off). So I tried 16.09 once more - and since then, I can no longer save my config (or at least key parts of it).
My BL is now v3 but I v4 was no different.
Oh, and the CC3D is brand new, never crashed :)
Michał
-
Could it be a USB cable or a bad PC? Try others for a test.
Some PCs have weak USB power. Some can't produce enough voltage. Does it work better when powered from USB or from flight power though ESC/BEC? Measure the voltage at the FC to make sure it is close to 5V. When flashing, try connecting fligth power to make sure it has enough voltage. Generally, all 4 ESC/BEC should be left unmodified so that they can all power the FC. Don't cut the red servo wire on any of them. Don't disconnect the black servo wire on any of them.
You need v4 bootloader for everything to work in 16.09. After flashing bootloader, you MUST reflash firmware since bootloader updater (bu) overwrites firmware. Flash bootloader v4 then 16.09 firmware. Does that all complete successfully?
Has it been rewired and maybe something is wrong? Have you tried unplugging all accessories like OSD, GPS, aux mag, RC receiver from the FC and see if it runs then?
Are you sure this is a CC3D?
No crash damage? No wrong voltage plugged in at some time?
Have you tried flashing the firmware posted by @f5soh a few posts above this? After flashing, reboot FC it and run it for 30 seconds and then reflash normal firmware.
Was this a ready to fly quad? When it worked, were you running the firmware it came with? Unlikely, but it could be that the mfg made a special version of firmware for it.
-
Got a fresh CC3D from the same supplier and loaded the same config file. No issues this time - every change was committed successfully. Same PC, same cable etc.
The faulty CC3D has basically no history at all - never really flown before the issues started. The alarms page lights up on SYS/BOOT indicating that it has found some issues with configuration data. I'm looking for a way to really-really factory clean it. I tried the @f5soh firmware file with no results. Followed the process except this didn't happen:
> After reconnecting the board, you will see a blink sequence (one per second) for around 20s.
> If this sequence is done, try again after updating the firmware using the GCS and Upgrade button, as usual.
There was only one steady LED for a few minutes, so I gave up and flashed normal BL/firmware.
If it's a big issue to fix this I'm OK with throwing the faulty CC3D out (it's $15 anyway), but was hoping there could be a nicer solution.
Michal
-
First 15.09 worked flawlessly, then I tried 16.09 and downgraded to 15.09. Upon downgrade, 15.09 didn't even start (one LED on, the other off). So I tried 16.09 once more - and since then, I can no longer save my config (or at least key parts of it).
So it worked OK in 15.09 to start with, but now nothing works.
Suggestions:
- take the board out of the quad. Did you use metal mounting hardware or was it mounted touching metal or carbon fiber?
- it may be just the external memory chip. CleanFlight / BetaFlight only use this for flight logs? LibrePilot requires it because LP uses it for settings storage. You might be able to use CF/BF/etc with this board.
-
My CC3D is in plastic casing and I never opened it. The moment things stopped working was exactly upon downgrading 16.09 to 15.09 so I doubt if there was any electrical/mechanical event that could have caused damage.
Thanks for the BF/CF tip!
Michal
-
Hello Michal!
I had the same problems that you reported and I managed to normalize this way:
1 - Download Firmware Cleanflight V 1.10.
2 - Install the drivers indicated for your card
3 - Connect with Cleanflight
4 - At the command line of the CF Type "flash_erase"
5 - Return to LibrePilot and do the normal process of installing the firmware
With me it worked
Good luck!
Albert
-
I have a similar problem and I am a rookie. I am using CC3D with sbus and a x4r sb frsky receiver that is bound to my new Taranis 7xq....I have not changed any settings on the radio, only bound to proceed into vehicle set up. My ESCs are Emax simon k programable 12 amp. They will not spin up the motor unless i choose the 50hz rate in the ESC page of the wizard. They will not initialize with the default 490hz or the one shot ESC choices. If I choose 50hz Then the escs power up and calibrate and motors all spin in that section but the configuration will not save to the board. I've looked all over for the solution. Any help would be a blessing.
-
I suggest that you set (Output page) all your output min to 1000 and your output max to 1900 and use either PWMSync or PWM@490.
Starting with that, do ESC calibration and Neutral setting as described here:
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/12058743/ESC+Calibration
-
Thanks for the response. My firmware and BL are up to date and the GCS sees the board. Following your instructions I went to the outputs tab and found that I could not move any of the sliders. The settings were 50hzpwm; these could be changes but changing them didn't affect the rest of the page in terms of allowing me to move anything. I unplugged and replugged the board to reboot. no change. On the firmware page it shows I have the version 4 bootloader and firmware 16.09. It identifies the board as copter control. I cannot manually change and save anything on any tab. Do remember that running the wizard, i got all the way through to the esc calibration successfully but then after choosing a set of stock settings that matched my 250quad, it would not save. I had to lower my esc rate to 50hz to get that far and spin up the motors.
It is worth mentioning that there is a yellow flag (error flag) in the firmware information panel in the center of the firmware page. Hovering over this produces no result.
My input and output show an error state in the flight dat tab. The error state in output is Servo Output Critical...one of the servos failed to update....the input error is just that my transmitter hasn't been set up. My receiver is bound, but I havent set up the transmitter yet.
I've ordered a new F3 board. If I can't get this worked out, I'll switch and see how that goes...hope you guys can deal with a high maintenance rookie .
-
I recall the orange triangle is just because we didn't mark the 16.09 release with the special mark so it knows it is an official release. That is documented in the wiki and is not a problem.
FYI: if you unplug the board, go to Firmware page, press Rescue, then plug board in, it will show you Firmware Tag, "git commit hash", and CRC for both the onboard firmware and the firmware bundled with the GCS. If all these match, then you are already running exactly what the GCS expects. At that point, press Erase Settings (then OK) and within 25 seconds, it will reconnect and FlightTime will start counting (from about 23) again. Wait till it gets up to at least say 120 (to make sure the erase is complete) and disconnect the board. (Waiting this long should not be necessary under normal circumstances.) This should erase the settings and there should be no error messages.
After that, go to Configuration -> Hardware. Change GPS Speed to 38400 and press Save. The Save button should turn into a Save button with a green check mark. Unplug the CC3D and plug it back in. When it connects in a few seconds (less than 10 for me) you should see that GPS Speed is still 38400. If it is 38400, you have proven that you can save and remember settings.
After Erase Settings, you might also try simply doing File -> ExportUAVSettings to a temp file, then File -> ImportUAVSettings from that same temp file (and press Save To Board Flash). Save To Board Flash takes a little less than 1 minute on my setup but you can see it count up during that minute.
-
Even my CC3d could not save. I performed the albertferraz procedure:
1 - Download Firmware Cleanflight V 1.10.
2 - Install the drivers indicated for your card
3 - Connect with Cleanflight
4 - At the command line of the CF type "flash_erase"
5 - Return to LibrePilot and do the normal process of installing the firmware
To be precise, I used the Cleanflight configurator version 1.10 and showed the Gyro and Accel icons in red. The cc3d has now saved the configuration. Thank you
-
I now have 6 'not saving' CC3D's! Four of them brand new! Bought from 2 different suppliers. All of them initially worked. Until I upgraded them to BL4 + LP16.09! Now all 4 of them refuse to save. They're all 'always unarmed', but behave like 'Always armed'. The 2 others have been in airplanes for at least a year, but probably longer, and were working fine, until I upgraded to 16.09. Now they also refuse to save.
One failing? OK, could be hardware. But all 6 of them failing after upgrading to 16.09 must be a BL or FW issue.
I read the Cleanflight-method, but can't get CF to work. Is there any other way to completely wipe a CC3D? And why isn't the 'Erase' option in LP doing the job? Why doesn't LP have a way to REALLY erase the board? Because I'm convinced, after searching the internet about this issue, that it's an LP problem. Something written in (probably) extended mem is causing this problem!
-
There are a few problems with tracking this down. The big most important ones:
- As far as I know there are no developers that have this problem.
- We don't have a simple set of instructions to recreate the issue starting with a completely erased CC3D. I suspect that you could take two sets of "exported UAV settings", (defaults.uav and completelyinstalled.uav) and do Import UAV settings alternating one and the other several times over (with NO erases) until all the flash memory blocks were used. Then it must be erased and maybe the LP erase would fail. If someone with the problem (that can fix it using CleanFlight) could document how to break it, perhaps like this, then a developer could possibly get it to break and we could understand it.
Other important things that cloud the issue:
- The erase procedure must be followed exactly. During the erase, the board looks locked up for over 20 seconds and you MUST NOT power it off till the SystemTime counter starts counting again so it might be a user error.
- It sounds like it is a problem that started with 16.09, but there are only a finite number of flash memory blocks. Changing a setting or two only uses a small number of blocks. Installing a new version uses a lot, so it would use them up sooner, making it look like the new version is the problem. Successfully erasing settings makes the blocks all available again. I think I recall a user that went back to e.g. 15.xx still had the problem which fits with it being a problem with 15.xx all along.
- It's possible that your USB port doesn't produce enough current or your long thin cable doesn't allow enough current. It might be that adding power from your ESC/BEC after connecting USB, but before erasing, (or using a computer instead of a laptop, or a different laptop with better USB power) helps.
- It may be an issue that only happens on one OS and not another. Most users have Windows OS. I think firmware developers tend to use Linux; at least I do.
- I would bet that of the users that have this issue, all their CC3D's exhibit the issue. I recall hearing some say that they had some good ones that later turned out to be "bad". This implies either - that there is something about that user's setup that causes the issue - or that devs that can't recreate the issue just have never used all the flash blocks up (at least that may be true for me).
- If someone with a broken CC3D (won't erase with LP but will erase with CleanFlight) would be willing to send it to a dev to see if they can successfully erase it with LP, the answer would either be: yes and so the user setup has an issue (possibly not the user's fault, like doesn't work on Windows 10 Vxxxx) or no in which case the dev has a CC3D with the issue and can debug it.
- There are probably other factors that I forgot to mention while writing this.
I read the Cleanflight-method, but can't get CF to work
This sounds important. Try a different computer and different cable. CF 1.10 should work.
-
As I re-read my own post, I realized my frustration was shining through. That was not my intend.
- As far as I know there are no developers that have this problem.
Maybe devs don't work with chinese copies? Could be a combination of the right (wrong) hardware with 16.09 or specific settings.
Question: What type of craft do ppl with this problem have, heli, drone or fixed wing? I use my CC3D's in airplanes only (I'm a bad pilot). Maybe Devs (almost) never setup for fixed wing?
-If someone with the problem (that can fix it using CleanFlight) could document how to break it, perhaps like this, then a developer could possibly get it to break and we could understand it.
When I get CF running and if CF-Erase works, I'll try to break it again. Can take a while, I'm rebuilding our bathroom, so I'm pretty busy and often too damn tired after.
- The erase procedure must be followed exactly.
Done. Doesn't work.
- It sounds like it is a problem that started with 16.09, but <cut> I think I recall a user that went back to e.g. 15.xx still had the problem which fits with it being a problem with 15.xx all along.
Last shipment, I had 2 CC3D's that were 'blancs', so there never was a version 15 on them untill after the problem appeared.
I will try out the possible power issues. But all my other CC3D's (10-12pcs) work fine (on 1A USB ports).
I will try Linux. Have a PC running it. Never thought of running LP on it.
- I would bet that of the users that have this issue, all their CC3D's exhibit the issue.
Then you would loose that bet, because I have at least a dozen other CC3D's that work fine with either version of LP. The eldest at least for 6-7 yrs. All but one have been up/downgraded before.
- If someone with a broken CC3D would be willing to send it to a dev
Well, if I can't get it to work, it's not much use having it, so in principle I would be willing. Any capable (for this problem) dev in The Netherlands?
Strange thing: My board is recognized as CopterControl, but when fiddling with BL's, it didn't accept the CC-BL. I needed to use the CC3D-version
I read the Cleanflight-method, but can't get CF to work
This sounds important. Try a different computer and different cable. CF 1.10 should work.
Been there, done that. Using all proven cables and computer setup. It's just me. Tired, can't sleep -> Can't focus.
Thanks for thinking with me/us about this problem!
-
If someone has some CC3Ds that they think are good and some that they think are bad
The aforementioned "import uav settings over and over till all flash blocks are used" is a lengthy procedure because it kind of assumes that the problem is not with the CC3D hardware. A simpler procedure (that assumes the CC3D is the problem) is:
- erase with CF
- use GCS to verify that it has default values
- make one change with GCS and save it
- reboot the CC3D and use GCS to see if the change is still there (and assuming it is)
- try to erase with GCS and it fails (prove with GCS that the "one change" setting is still "changed")
- try to erase with CF and it works (prove with GCS that the "one change" setting has gone back to default value)
If someone has some CC3Ds that they think are good and some that they think are bad then this test will work differently on the good ones than on the bad ones. "Try to erase with GCS" will work with good ones and fail with bad ones. That will prove that the problem is related to a difference in CC3Ds.
At this point, I am guessing that the flash chips in the "bad" CC3Ds (if it is the CC3Ds) need to be "erased longer". As I recall you hold the chip erase signals active for a certain length of time. The chips in these "bad" clones might need longer erasing. The longer time could be the fault of the flash chips being not to spec, the flash chips having a new spec that needs to be coded into LP's erase flash code, or LP code that was not written to spec, but written to "this works".
-
Question: What type of craft do ppl with this problem have, heli, drone or fixed wing? I use my CC3D's in airplanes only (I'm a bad pilot). Maybe Devs (almost) never setup for fixed wing?
I doubt that it is related to the type of vehicle.
Last shipment, I had 2 CC3D's that were 'blancs', so there never was a version 15 on them untill after the problem appeared.
I recall a different user where 15 worked, 16 failed, then 15 failed.
But all my other CC3D's (10-12pcs) work fine (on 1A USB ports).
... I have at least a dozen other CC3D's that work fine with either version of LP. The eldest at least for 6-7 yrs. All but one have been up/downgraded before.
I am guessing these all have 16.09 on them and you use the same PC on all your CC3Ds?
Strange thing: My board is recognized as CopterControl, but when fiddling with BL's, it didn't accept the CC-BL. I needed to use the CC3D-version
My CC3D says CopterControl on the Firmware page.
On Firmware page: Device ID should be 402 and HW Revision should be 2 for CC3D. It's important to have the correct bootloader. It is possible to get the wrong one on. The procedure you use to put a bootloader on when there is none will do it. This sounds promising enough that I will try putting the wrong bootloader on to see if that makes erase settings fail.
CC vs CC3D: CC is really old but you did say 6-7 years. Everything now is CC3D. You can tell CC vs. CC3D by the chips.
-
- The erase procedure must be followed exactly.
Done. Doesn't work.
I'm really sorry to ask this. Really :) but did you do the "erase settings" from the firmware page and wait a long time while the LED was blinking regularly until finally the FlightTime started counting again? Usually at about 23 seconds of FlightTime.
I wonder if the LED blinking regularly looks like I am done, when you actually need to wait until the FlightTime counter starts counting. At that time the LED will be blinking like a normal startup.
-
You can ask me anything (related to RC :) ). I have the same thing with ppl asking me advice with PC's. You try helping them for an hour by phone, finally go over there to find the power plug on the floor. So, I know. Just ask. I do wait 'till stabilized again
I recall a different user where 15 worked, 16 failed, then 15 failed.
Sounds just logical to me. If you change tyres on your car, one blows out and damages your rims, you can put your old tyres back on, but the rim stays damaged.
I use a PC and two laptops. One laptop is old, barely runs W7 and is for outdoor use. All FC's run 1609, except for one. It's the second plane (a 1.55m Eagle-like) I built and I can't get to the FC without taking the plane apart. Never appeared to me that that was ever going to be be necessary :) It still runs OpenPilot and not even the last version :) If it ain't broke......
I've attached a pic of the device info as displayed by GCS. As you can see it's called CopterControl, but everything else fits CC3D.
I finally managed to get BetaFlight running. CF is still refusing cooperation :o At least I have 5 revived CC3D's. Number 6 stays in Limbo for now.
So, the CleanFlight/BaseFlight Erase method works for me too.
I had to do two of them twice to get it working and one reverted back to locked state again while it was setting up mixes during the Setup Wizard. After CF/BF-Erasing it again, I ran several test setups and it works OK now.
I've attached a nude pic of one of the devices (without it's casing), so you can see the numbers on the chips.
-
I had to do two of them twice to get it working and one reverted back to locked state again while it was setting up mixes during the Setup Wizard.
That sounds even more like "it needs to be erased longer/more than the spec calls for". I have wondered if erasing multiple times on LP GCS would eventually really erase it and this makes that sound reasonable. It may need 10x 100x or more LP erases though, so it's not a test that really needs doing.
If you change tyres on your car, one blows out and damages your rims, you can put your old tyres back on, but the rim stays damaged.
I doubt that LP is damaging the CC3Ds like a blowout damaging a rim on a car (but it's not impossible), especially since good CC3Ds haven't done this over long use in the past. More likely is that cheap flash chips are out of spec or become out of spec quickly with normal use or that there is another issue like bad power regulator chips or CPU... What I actually wondered about when I said that is that it was never actually being erased (even with 15.xx) and finally filled up after 15 then 16 and was still full when going back to 15.
So we think you definitely have good and bad CC3Ds (bad is not intended to mean that we know the problem is actually with the CC3Ds, but the word is understandable :) ).
Would you mind doing this with both a good one and a bad one?
- erase using CF (enough to know it is really erased)
- use GCS to see that it looks like default settings and make one change (I change Hardware page GPS baud rate from 57600 to 38400 for my test) and Save
- unplug/replug USB to power CC3D off/on
- verify that the change you make is still changed
- unplug USB
- go to Firmware page and press Rescue; then plug CC3D USB in
- press Erase Settings and follow the directions
- after erase, unplug/replug USB to power CC3D off/on
- verify that the change you make is erased (good) or still there (bad)
The last line will probably act differently for good versus bad CC3Ds. This will help to prove that there are good and bad CC3Ds and that a bad one is even bad before the flash blocks are used up. It will also provide a very simple way to know for sure if any particular CC3D is bad.
-
I doubt that LP is damaging the CC3Ds like a blowout damaging a rim on a car
Oh, but we agree on that. I do not mean permanent damage, but more that LP makes some change it can not erase itself. Whether because it's erase time is too short or any other thinkable reason. Changing Version (15/16) doesn't change that. And that's also what bugging me. An erase that doesn't erase .. OK, could be too short, but if I put another FW on, then there shouldn't be anything else on after. But it does! Something's still there, blocking saves. But after CF-erase I can change all settings and erase them with LP without any problem
If you say that CF probably erases longer, then why doesn't LP up it's erase time? It's not like it takes an hour to erase. If it solves the problem ...
Ofcourse I realise cheap parts are very likely to be the actual cause. And I'm under the impression Chinese stuff is getting worse by the day. TP Servo's that used to be pretty reliable, have become unusable lately. It looks like they run the molds for too long, slack everywhere. I've switched to more expensive parts a few times now, because the better parts are getting worse too. I think I'm spending about 20-25% more on electronics than I used to a year ago.
I will run the tests, but can't say when. I'm still very busy rebuilding my bathroom. RC time is limited :(
-
But after CF-erase I can change all settings and erase them with LP without any problem.
If this is true, it is extremely important and why I asked for the above test:
(the test will) help to prove ... that a bad one is even bad before the flash blocks are used up.
which is not true from what you say, and to me implies that all CC3Ds are "bad"; actually that there is an LP firmware bug such that LP erase will fail after all the flash blocks are used up.
So please try that test with a bad CC3D ... you are saying that LP GCS can erase the one setting, but not once all the flash blocks are used up. This cause (there is a a problem only after all blocks are used up) is one of the possible causes.
(Programmer Note: flash open fails because all blocks are used up and then it can't even be erased because the open failed? I haven't been in that code in a while. I also wonder if they are coming with a modified bootloader that still calls itself version 4.)
-
And then number 6 worked too! They all work now. I was trying some things I thought of (hadn't read your msg yet).
- I flashed BF1041-fw on the last bad CC3D from GCS then replugged.
- Erased from BF's CLI using 'Flash_Erase' command and replugged.
- Went back to LP1609 and used U&E to reflash LP1609 and replugged.
- Changed attitude roll to 180, saved and got a green tick (for the first time with this one), then replugged.
- Attitude roll was still 180 and unplugged.
After I read your msg, I ran your grocery list on all of them.
I've done the tests:
V- use GCS to see that it looks like default settings and make one change (I change Hardware page GPS baud rate from 57600 to 38400 for my test) and Save
V- unplug/replug USB to power CC3D off/on
V- verify that the change you make is still changed
V- unplug USB
V- go to Firmware page and press Rescue; then plug CC3D USB in
V- press Erase Settings and follow the directions
V- after erase, unplug/replug USB to power CC3D off/on
V- verify that the change you make is erased (good) or still there (bad)
They all passed! They work flawlessly now.
I wonder, I presumed the CC3D was a blanc when I got it, because it didn't boot. But could there have been some (remains of) corrupted fw on? Something that didn't boot, but did interfere with LP? Does a CC3D have something like 'restricted/protected area' in memory? Or some mem location LP doesn't use and might be written by another fw, whether intended or not (corrupt). But still, LP should erase completely. I still think CF/BF does erase some memory location LP doesn't, because after U&E the initially 'blanc' CC3D, everything works. You can run the wizard and the servo's will move, motor will run ... untill you get to wizard setting up mixes. Then it hangs. If you manually change things, it's the same, but you can't save anything. You get a red cross every time. All would support your idea of the longer/deeper erase. But what's nagging me is that -IMHO- if caused by a low spec/faulty mem chip, I'd expect random errors. It wouldn't work in exactly the same way on every 'faulty' CC3D, would it?
-
So now, even your "bad" CC3Ds work correctly ... and LP EraseSettings does erase?
Maybe there is only a problem if the CC3D flash chip is allowed to become completely full so that it can't save more settings? This may imply that all CC3Ds are "bad" (it would probably actually mean there is an LP bug in this use case).
Maybe you are doing something differently than before? :) Maybe Rescue Erase works where the way you used to erase doesn't?
Did you flash the bootloader and that made them work?
Maybe some clone flash chips get better after a few erases.
Does a CC3D have something like 'restricted/protected area' in memory? Or some mem location LP doesn't use and might be written by another fw, whether intended or not (corrupt). But still, LP should erase completely.
There are several kinds of memory on the CC3D. This kind of memory is like a thumb drive and doesn't have "protected areas".
I still think CF/BF does erase some memory location LP doesn't, because after U&E the initially 'blanc' CC3D, everything works. You can run the wizard and the servo's will move, motor will run ... untill you get to wizard setting up mixes. Then it hangs.
This is best explained by that initial LP erase not erasing (maybe did you U instead of U&E?), and like a used computer drive that you didn't format, it is already partly full and so the program installation fails part way through. Once it is properly erased, (reformatted) everything works fine. Your comment makes me wonder if the erase part of Upgrade And Erase doesn't work, at least sometimes, but Rescue Erase does work.
But what's nagging me is that -IMHO- if caused by a low spec/faulty mem chip, I'd expect random errors. It wouldn't work in exactly the same way on every 'faulty' CC3D, would it?
It's quite possible for the chip's internal erase circuit to not work well and the rest of the flash chip to work fine.
-
So now, even your "bad" CC3Ds work correctly ... and LP EraseSettings does erase?
Yes, they do. They work and LP-Erase works too. It really looks like CF does erase something LP doesn't.
maybe did you U instead of U&E?
No. I always use U&E. Might miss-click sometimes, but not with 6 FC's in a row. I'm not thát old ;D
<cut> if the erase part of Upgrade And Erase doesn't work, at least sometimes, but Rescue Erase does work.
Maybe, but not likely. I only started using RE once I had this problem. But I certainly did try RE before I used the CF-Erase method.
It's quite possible for the chip's internal erase circuit to not work well and the rest of the flash chip to work fine.
But then all 'bad' -not saving- CC3D's would have exactly the same defect? On the other hand; CF doesn't use ext mem, except for logging. LP does use ext mem for it's main program, am I right? So, CF erases ext mem while itself active in main mem and LP erases ext mem while itself being (partly) active on it. So CF-erase can completely wipe ext mem, but LP can only wipe settings area and not everything in ext mem, because it's active in ext mem and would wipe part of itself?
Did you flash the bootloader and that made them work?
Can't say. I flashed BF because BF could not connect to CC3D with LP on it (failed to open port). So I flashed BF to get it to connect. Which worked. With BF on, it connected immediately. Then I erased through CLI, replugged to check if CC3D worked, unplugged, switched to LP, U&E and plugged CC3D in. Replugged and it worked, but some of the other CC3D's had no problem connecting with BF while LP was on it and were erased from BF without flashing BF on. After CF-Erase (some twice, the last one even 5 or 6 times) they all work fine with LP, Erase included.
-
CF uses external flash for logging. LP uses it for settings. Neither use it for program. There is special internal memory for program storage.
Besides UpgradeAndErase and RescueErase there is HaltErase.
But then all 'bad' -not saving- CC3D's would have exactly the same defect?
Not the same defect... the same "junk data" that partially fills the "disk" so that install fails part way through, or completely fills the "disk" and the first time (mixer settings?) you try to write the settings from memory to flash it fails.
I flashed BF to get it to connect. Which worked. With BF on, it connected immediately. Then I erased through CLI, replugged to check if CC3D worked, unplugged, switched to LP, U&E and plugged CC3D in. Replugged and it worked
Either BF puts it's own LP compatible bootloader on (and that is a possible problem) or it just uses the bootloader that is there because you would have to do special things to put an LP bootloader on if CF/BF overwrote it. The fact that you could use LP GCS to UpgradeAndErase indicates there was an LP (compatible) bootloader on it.
By your own comments, if LP needed something special erased, then the first time you erased with CF/BF the special area would be erased.
Where there any "bad" CC3D's that you know that all you did was BF/CF flash_erase several times (no BF/CF firmware). What did you use (BF or CF) (flash_erase or flash and run BF/CF firmware) in this last go round that seems to have fixed them all? Any best guess?
Is there anything you can think of that you did that finally made the bad ones good?
- Flashing BF vs. CF firmware
- Booting BF/CF firmware.
- Using BF vs. CF to flash_erase
- Waiting longer for the BF/CF flash_erase before powering off
- Old version bootloader that got upgraded when you were doing BF/CF flashing stuff. LP updates the bootloader code to V4 and then BF/CF does and finally (maybe never) the CC3D cloners do so it could have had an old LP or LP compatible BF/CF bootloader on it.
- Bad flash chip that gets better after being erased several times.
- Finally waited long enough before power off with CF flash_erase. I don't know how long it takes.
I can tell you that a few years ago there was a known issue that installing and running CF/BF firmware would format the flash to be used for CF/BF logging and that would mess it up where LP would not boot (until you erased the flash). I also wrote a change for the LP firmware (I don't think we included CC3D) to automatically unbrick this particular case. I can tell you that a complete unbricking took 10's of seconds the way we do the erase flash.
-
Where there any "bad" CC3D's that you know that all you did was BF/CF erase flash several times (no BF/CF firmware). What did you use (BF or CF) (erase flash or flash and run BF/CF firmware) in this last go round that seems to have fixed them all? Any best guess?
Yes, one of 'em only needed one "CLI: Flash_Erase". It connected with BF without the need to flash BF on and a single Flash_Erase was enough. Problem is, all devices look the same and I don't number them ( :-[ ), so I have no idea which one.
I still have a feeling that it has to do with arming. Don't know why, it's just a feeling, but the CC3D's behave like they are 'Always Armed'. The whole way they react is the same as if you try to change something while armed.
Is there anything you can think of that you did that finally made the bad ones good?
- Flashing BF vs. CF firmware
- Booting BF/CF firmware.
- Using BF vs. CF to erase flash
- Waiting longer for the BF/CF erase flash before powering off
I really can't tell. You see, You started out trying to identify the exact problem, while I was only trying different internet found solutions (in between working on my bathroom) to try to get some (some already refunded) 'defective FC's' working, as a way of taking my mind off the bathroom for a while. I was not systematically searching. I've done all of the above, but I don't know what I did to which one. After ev'ry 'session' with the CC3D's I just put them all back in a drawer. It's only when you started asking things that I really started to pay attention.
- Old version bootloader that got upgraded when you were doing BF/CF flashing stuff. LP updates the bootloader code to V4 and then BF/CF does and finally (maybe never) the CC3D cloners do so it could have had an old LP or LP compatible BF/CF bootloader on it.
I remember two I bought last summer, that 'functioned' out of the box, but the last two seemed to have nothing on it. If I remember correctly, they only had a weak, slow blinking blue led. To get them to do anything, I U&E'd them by pressing U&E on fw-tab (1609) and then connect device. When they came to live,they all had BL4.
- Bad flash chip that gets better after being erased several times.
Until they fail completely probably.
- Finally waited long enough before power off with CF erase flash. I don't know how long it takes.
I always wait for Atti & Stab to turn green. That should be long enough?
-
Damn! I was fiddling with a 'revived' CC3D just now and I'm really sorry, but it seems I've been 'lying' to you the whole time. I used a 'bad' CC3d in a new plane and found that though it looks like it is Armed, it is NOT! I get a green tick when saving 'Always Armed', and when rebooted, it says it's Armed, but my motor doesn't run! I tried 'Test Outputs' in Output-tab before to check and it all worked fine. I stupidly never checked if, after arming, my motor would run. Guess I was just too happy with a Green Tick after only seeing Red Crosses 'till then.
So, I have a booting, working CC3D, that at first wouldn't save any settings, that now -after erasing with BF (I only use BF. CF doesn't connect) does save settings, but though it seems to arm normally (green tick), in reality doesn't. But 'Test Outputs' does arm the motor! So it says it's armed, but isn't???
I have tested the other one of the last shipment and it's the same! It says it's armed, but the motor doesn't run. Again, Test Outputs makes it spin like a .. cat?
I think I'm ready to throw the towel and send them back/ask for a refund.
-
Yes, one of 'em only needed one "CLI: Flash_Erase". It connected with BF without the need to flash BF on and a single Flash_Erase was enough.
This info helps. It says that you did not have to flash any firmware to "fix" at least one.
I remember two I bought last summer, that 'functioned' out of the box, but the last two seemed to have nothing on it. If I remember correctly, they only had a weak, slow blinking blue led. To get them to do anything, I U&E'd them by pressing U&E on fw-tab (1609) and then connect device. When they came to live,they all had BL4.
Weak slow blinking (fades on and off) LED says that it has a bootloader, but does not have any flight firmware.
At this point, I wonder if the cloners use a version of BL4 that is not the same as LP's BL4. I forget, have you flashed LP's BL4 onto any of them?
-
It says it's armed, but the motor doesn't run. Again, Test Outputs makes it spin like a .. cat?
By "like a cat" I guess you mean spin correctly. :)
If you post the CC3D settings (File->ExportUAVSettings with CC3D plugged in), we can look at it and see what might keep the throttle from working.
I wouldn't give up. The motor(s) run(s). It should be a simple thing to figure out at this point. Forgive me for being very complete in the following descriptions. I've undoubtedly included things you already know and do.:
- Flight battery needs to be plugged in (or RC receiver doesn't get powered). ;)
- With flight battery and USB/GCS plugged in, and transmitter on you can go to Input (->RC Input) page and see the sliders move according to the transmitter sticks. Make sure the throttle slider moves when you move the transmitter stick.
- Are you using "Always Armed"? This is a minor pain because any change you want to make, you must first turn off "Always Armed", then make the change, then turn on "Always Armed".
- If not using Always Armed but using "Throttle off and X" then you must be able to get to absolutely 0 throttle and full "X". A little bit of transmitter trim or dual rate or channel offset, etc. might keep you from getting zero throttle and full "X". And you must hold the "Throttle off and X" for a whole second.
- It won't arm if there is an alarm or you have GPS Assist or AltitudeVario or AltitudeHold or some cases of AlwaysStabilizeWhenArmed, etc.
- Some ESCs require a zero throttle, full throttle, zero throttle cycle each time you plug a battery in. Not usable for a quad, but maybe you have one of these in an airplane?
Some of these don't apply to CC3D, but trying to enable them would still cause arming problems.
Is all your stuff airplanes using AlwaysArmed?
-
By "like a cat" I guess you mean spin correctly.
I forgot, cats don't spin in English, they purr ;D In Dutch cats's purring sound is called 'spinnen'. So I meant the motor runs smooth. It purrs like a cat.
I found the culprit. RX plug wasn't seated properly. Motor(s) running now!
Is all your stuff airplanes using AlwaysArmed?
Yes! All except for my drone. It has a 10-ch RX and has plenty of CH's to spare for an Accessory-Arm. Which works for drones, but with planes one uses long periodes of full rudder/elevator frequently and I don't want to shut down my motor mid air ::) I have some that glide pretty well, but not all do and I regularly fly above a city lake nearby. Foamies don't sink easily, but it takes forever to get them back ashore. I don't own a 1:1 boat and my rc hydroplanes have no reverse, so most times they're pretty useless as a tow ;D Using 6-CH RX's for my planes, I use my spare CH for flaps or a (tow) hook.
At this point, I wonder if the cloners use a version of BL4 that is not the same as LP's BL4. I forget, have you flashed LP's BL4 onto any of them?
Yes, I think I did them all, because I wanted to rule out a bad BL or fw. I used 'bu_CC3D-20120620_f44b9d3.opfw' and followed the instructions on the Wiki page ( https://opwiki.readthedocs.io/en/latest/appendices/bootloader.html ). But it didn't solve the problem. At least I didn't notice any difference, but that doesn't say there were none.
-
At this point, I wonder if the cloners use a version of BL4 that is not the same as LP's BL4. I forget, have you flashed LP's BL4 onto any of them?
Yes, I think I did them all, because I wanted to rule out a bad BL or fw. I used 'bu_CC3D-20120620_f44b9d3.opfw' and followed the instructions on the Wiki page ( https://opwiki.readthedocs.io/en/latest/appendices/bootloader.html ). But it didn't solve the problem. At least I didn't notice any difference, but that doesn't say there were none.
So, even after making sure it was running LP BL4 you still had the problem. Thank you. This is good information.
When CC3D was "bad" and you tried erasing with LP Erase or UpdateAndErase, did you get any error message or other indication of error? Sorry if you answered this before and I forgot.
-
Nope, no indication, no errors. I remember hooking up the first of the last two and getting the slow pulsing blue LED. I clicked U&E in FW-tab and it said it couldn't get device in bootloader mode (not unusual) and to do a manual update, so I disconnected USB, closed LP, restarted LP, clicked Rescue, then U&E and connected USB. All went as expected. After U&E finished, I dis- and reconnected and all seemed well. I ran the setup Wizard and up 'till setting mixes it all ran fine, then GCS got stuck. I rebooted and my settings were gone. So I hooked up the other one and got exactly the same results. That's when I started looking for a way to get the CC3D's working and I found the CF/BF method.
I wouldn't give up. The motor(s) run(s). It should be a simple thing to figure out at this point.
I never do. I get frustrated and to prevent great damage to things around me, I quit! For a while at least, but I always get back on it.
-
Let me say to anyone that has this problem to please just try LP Erase again, but make sure that after clicking that OK button, that you wait for the board to actually reboot itself and connect itself back to GCS, before doing anything else. It should take less than a minute. Do NOT just wait a little while, see that the blinking is not changing, and unplug the board.
I bought a CC3D Atom from eBay ($9 shipped) recently and thought I would try to recreate this issue.
https://www.ebay.com/itm/Openpilot-Mini-CC3D-Atom-Nano-CC3D-Flight-Control-for-FPV-QAV-ED/122116570993
Short version: I did not Erase Settings and I did have a very similar sounding problem with it with LP 16.09, but LP Erase Settings fixed the problem.
It came with this firmware on it:
Firmware version: 20150512 23:55 (29b92655-ffca2cd6)
Device ID: 402
HW Revision: 2
Flash access: RW
BL version: 4
Max code size: 118684
RELEASE-15.02.02
CRC: 1160622165
I copied off the old firmware using Firmware->Retrieve and flashed 16.09 on it and did NOT Erase Settings. I verified (in System->AccelGyroSettings->accel_bias) that the level calibration was all zeros. I did a level calibration on it, Saved (OK), verified the calibration numbers were not zeros, and exported it. It exported OK.
I made a copy of the settings file and modified a number in each UAVO. When I tried to import these modified settings it locked up at 2%. After 5-10 minutes of it sitting at 2% (green LED on, blue LED slowly fading on and off), I rebooted and exported the settings and found that nothing had changed. It was all defaults except for the leveling calibration I made. So note that the first Save (after leveling calibration) did appear to work OK (was indeed saved permanently).
I erased settings (Halt, Erase Settings) normally with GCS and now everything is working. I can say that the erase took longer than I expected (probably less than a minute though, and it had been a while since I had done an Erase Settings), but I didn't time it. I was getting tempted to just unplug the board when it finally booted and connected to GCS.
I imported settings: stock, modified, stock, modified, ... etc. a total of 16 imports with no problems, so I gave that up.
I put the old firmware back on it, Erased Settings, and booted it; then put 16.09 back on it and repeated my initial steps (level calibration, save, etc., export, import) and had zero problems, so at least for me it was something strange on the flash (settings storage) that got fixed with a standard 16.09 LP GCS Erase Settings (Halt, Erase Settings).
I know that the flash "file system format" changed, maybe between BL3 and BL4. I wonder if this is what happens when you have the old flash file system? 16.09 / BL4 writes the new format. In BL4 at least the firmware is asked to reboot in safe mode and format the flash with format code in the firmware.
I'm thinking of buying another of these Atoms, and writing some code to save/restore all of the flash device.
Update: I bought another Atom from the same place, and started by reading the whole settings EEPROM, but I could not recreate the issue at all. There are some kinds of garbage data that would cause this "settings file system corruption", so that is my current working theory. :) LibrePilot "Erase Settings" should fix any "settings file system corruption".
-
Bathroom finished :D
I'll try the LP Erase again next time. Did the CF/BF trick again a few days ago. Controller came from a crashed plane, so I had to set it up for it's next 'home' ( http://www.aero-news.net/images/content/general/2013/Velocity-V-Twin-0413a.jpg ) and it didn't save again. I'm not a very patient person anymore, so could be that I don't wait long enough.
You actually bought a Chinese CC3D to experiment? 8) KUDOS for your effort!
-
You actually bought a Chinese CC3D to experiment?
;D I bought the Atom as a cheap controller to experiment with a small fast plane and I thought I would try to recreate the issue.
-
THANK YOU SO MUCH! yes I'm using uppercase because your post saved my CC3D
Good fly! ;D ;D ;D
-
Did you use LibrePilot or did you use Betaflight? The answer can help others in the future.
-
If you're asking me? I use Beta Flight 10.4.0
-
Sorry, I was asking solmer, but your information that recent Betaflight works is also helpful. 8) Initial posts talked about using old versions.
-
Have you found any difference in how both programs erase flash mem and have you been able to replicate the problem?
-
I haven't looked at the CF/BF source code.
I bought an Atom and I was able to recreate at least a very similar issue just one time. I put in some debug code to dump the settings memory, dumped it, did not find any data that I <thought> would cause it. Used LP Erase Settings and that fixed it, and never could re-create it.
I immediately bought a second Atom from the same seller and didn't have any problem with it at all.
-
Murphy! ;D
My best for Xmas and 2020
-
Hello all,
I'm "happy" to see that others are having the same issue as me. After searching for 2 days I can't understand how this issue is fixed.
My story is the same as yours, I'm using 16.09, the first vehicle wizard setup worked without any issues. The second attempt "stuck" at "preparing mixer settings" and I can't continue from there. I tried to go in Configuration and click "Save" but the red X symbol is always there.
I tried all possible solutions in this thread with erase, upgrade, rescue, re-flashing. Everything. I tried in Mac and Windows. I tried both 15 and 16 Librepilot versions.
Is there any solution after all?
Thank you!
-
After a lot of testing and reading the whole thread again it worked for me too:
1) Download "cleanflight_CC3D.bin" from here https://github.com/cleanflight/cleanflight/releases/tag/v1.10.0
2) Follow the steps here to flash it https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab#FirmwareTab-Bootloader+firmwareupdateexample
3) Install Cleanflight to your PC (I added the chrome app)
4) Connect CC3D to PC and click Connect in Cleanflight
4) At the command line window (CLI) that will appear type "flash_erase" (without quotes) and press enter
5) Close Cleanflight and return to LibrePilot
6) Download the latest CC3D firmware from here https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab and re-flash the board following the steps in step 2
7) Enjoy!
You need specifically "cleanflight_CC3D.bin" from v1.10.0, otherwise it won't work. I was trying with other most recent firmware versions and this is why it wasn't working for me.
Thanks!
-
Almost all of the people I have talked to about this have just disappeared. I don't know if their problem was fixed or whether they gave up and did the CleanFlight/BetaFlight erase method.
Has anyone fixed it with something besides the CleanFlight/BetaFlight erase method?
Has anyone fixed it by using a different computer?
We have a case where it happens on an international MacOS 10.14 (and a Windows VM, probably hosted on the Mac) and international Windows 10. Has anyone had it on a USA version operating system?
Has anyone that had the problem tried reinstalling the CC3D bootloader (even if you already have BL4) and then the firmware like here?
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab#FirmwareTab-Bootloader+firmwareupdateexample
(Another unlikely possibility is that it is related to the LP setup wizard.)
(Another unlikely possibility is that having multiple old versions of OP/LP on your computer causes problems. I would guess a fix in that case would be to completely uninstall all the old versions of OP and LP and install just the version you want.)
-
I know of 2 club members that have permanently changed to Beta/Clean.
Has anyone fixed it by using a different computer?
I didn't.
Has anyone that had the problem tried reinstalling the CC3D bootloader (even if you already have BL4) and then the firmware like here?
Yes, I did. I tried ev'ry BL to no avail.
(Another unlikely possibility is that it is related to the LP setup wizard.)
Well first sign something is wrong, is always the moment the wizard tries to calculate Mix. It stays there forever. Can only reboot by pulling the plug.
(Another unlikely possibility is that having multiple old versions of OP/LP on your computer causes problems. I would guess a fix in that case would be to completely uninstall all the old versions of OP and LP and install just the version you want.)
I could try on another PC. This puter has 4 or 5 versions of GCS on, because if a plane/CC3D combo is good, I don't touch them anymore. My oldest foamy is still running an ancient version of OPEN-Pilot and if it ain't broke .......
(edited by Cliff to move your statements outside of the quote block so they don't look like I said them and to uniformly bold your statements inside the quote. :) )
-
I could try on another PC. This puter has 4 or 5 versions of GCS on, because if a plane/CC3D combo is good, I don't touch them anymore. My oldest foamy is still running an ancient version of OPEN-Pilot and if it ain't broke .......
If you can still recreate the problem, then it would be great if you could test on a clean PC with a single install of only LP to see if the problem goes away. :)
-
I will test this, but you'll have to be patient. But seeing you're still exploring this problem, I guess you're one of the most patient ppl I know :)
My (81yr old) dad's in the hospital, so I don't have much time in between normal life, visits to my dad and keeping an eye on my mother.
-
Sorry TOC, but it won't happen anytime soon. Still parent-health problems and the COVID19 virus doesn't help :(
-
No hurry. We have been dancing with this issue for years now. :) And there are work arounds (generally use CleanFlight / BetaFlight to erase the board settings, then put LP back on it).
I have a feeling that a lot of us will soon have plenty of time for the hobby because of CoVid-19 lockdowns. We should start a general thread for respectful random discussions about CoVid-19 and life these days.
Be safe!
-
Thank you for replying back.
Has anyone fixed it with something besides the CleanFlight/BetaFlight erase method?
I didn't, I can reproduce a lot of times but I wasn't able to solve with another method.
Has anyone fixed it by using a different computer?
I used 2 computers, 1 windows 10 desktop (in and out of a VM) and 1 Mac laptop, in all of my tests it failed.
Has anyone that had the problem tried reinstalling the CC3D bootloader (even if you already have BL4) and then the firmware like here?
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669026/Firmware+Tab#FirmwareTab-Bootloader+firmwareupdateexample
I'm following this all the time, even in the cleanflight solution. It works only with cleanflight solution.
-
Please post your settings from the board that has this problem, so I can put them in my CC3D. :)
How many versions of OP/LP (and what versions) do you have on each computer / VM?
- Win 10 native
- Win 10 VM
- Mac OS
Is it true that each computer has had several versions installed, even if they are removed now?
Do you have any other OP/LP boards (like more CC3D / Revo / OpLink) plugged in when you do this?
Are you using Bluetooth on these computers?
Here is a link to a post another user that has this problem made. It has a video of the GCS and clearly shows that "after pressing OK, the CC3D reboots and connects to GCS almost immediately. 2 seconds after pressing OK, FlightTime starts counting, beginning with FlightTime=2"
https://forum.librepilot.org/index.php?topic=4847.msg32441#msg32441
The next post after that has a GCS video that I made where it works normally (on Linux though, not Windows/MacOS). "it takes 20-30 seconds for CC3D to reconnect to GCS. 23 seconds after pressing OK, FlightTime starts counting, beginning with FlightTime=23" MacOS people have already replied to this post, so no need to reply to it.
https://forum.librepilot.org/index.php?topic=4847.msg32442#msg32442
My question is whether yours acts like the first video (comes back quickly, 2 seconds after pressing OK) or like the second video (takes 20 to 30 seconds to come back after pressing OK) or if it acts like something else.
Thanks for your help in trying to track this down.
-
Just cleaning up a little. This issue has been found and fixed.
https://forum.librepilot.org/index.php?topic=4912.0