Thank you , job not done yet ![]()
Will that ever be done? ![]()
Don’t overlook the documentation. IMHO the biggest fault of mission planner is the lack of up to date documentation that really explores the features. That program has tons of amazing features but so many are all “hidden” or just generally unknown and they go missed by users that could really take advantage of them.
From my own experience with docs, videos are great to start but after a user understands the general workflow the text docs are more useful and faster to use. Also, videos don’t always age well and are harder (or more time consuming) to update.
But these are just free opinions and worth every penny.
Documentation is written while im coding , i leave comments , docs etc.
After i feel we hit some stable version , i will run a script that will build the documentation.
Then i will go through it and review.
But the best documentation is a intuitive ui , nothing is better than that.
Its just im currently packed with feedback and fixes that have to be addressed asap.
And from my experience , loosing focus from that and writing documentation that will 100% change due to feedback and changes in the ui , is a bit wasteful.
But i really feel you and a good documentation is worth a lot. No worries all is planned.
I also need to rollout a website , it feels like the project picks up , so a good tone would be a website where documentation could also find its home ![]()
Github.com pages and a CI job that does markdown linting and link checking are simple and effective
Thats the plan
Sure, will do!
Thank you!
It sure has. I’ll add to the praise; nice job so far after checking out 28. I was going to comment on the PID preset idea, for Ardupilot anyway, but as you say let’s see how the significant things shake out and advance.
![]()
Not to derail the Ardudeck discussion, but I did collect log files for the purpose of inventing some basic PID profiles related to prop size (like the Initial Parameters). Turns out it’s hard to do because of all the different components and how they interact. It gets more difficult as the frame and prop size increases.
I always keep it in the back of my mind and I may restart some work on this.
ArduDeck isn’t seeing the receiver. I’m using ELRS RC over Mavlink. It’s properly configured because it works when I check in Mission Planner. AD will detect switch changes when I make them on the radio. it just doesn’t see the sticks so I can’t try out the calibration.
In order to fix this i really need the deckreport file , could you please attach it here/discord or on gh ?
I was meaning to ask if the bug feature automatically sent them in. ![]()
No no no , nothing is send automatically , no hidden logs , telemetry etc.
Im against it a app has to be transparent and no data collection until the users collects it manually.
Thanks for the file and here is your ticket ELRS over Mavlink not working · Issue #56 · rubenCodeforges/ardudeck · GitHub
You can track progress from there.
Proton seems to be giving some grief with that file. Did it work for you? If not I’ll try github.
Seems to be empty , its a compiled and encrypted file of all your app logs and if included board logs.
Just zip it and attach to gh.
No one can open it but me.
Yup, just did it. Let me know if it worked.
Yes , perfect !
No , I’ve added it after 28 released, it will be in 29
oh ok, thanks!


