publishing an intermediate release 3.1.0?

PhracturedBlue wrote: I think we're coming to the end game now.
I believe the trunk is now as good as Rbe's branch was,

me too

and looking through the bugs on bitbucket, I don't see anything that would gate a release.
I'll probably wait for victz's Hisky patch. I don't know if Rbe's work on aborting binding is almost ready or not, but if it is, I'll probably wait for it.

From my point of view, it is ready. It is only implemented for the WK2x01-protocols, but could easily be adapted for others if it makes sense. I actually ran out of time so I can't make some experiments (and I could only test Devo and DSM2).

PhracturedBlue wrote:

vlad_vy wrote: Is it possible to implement auto channels mapping with protocol change? It's frequenly rise questions from beginners.

From my point of view the most safe way to do it will be change model.ini file and reload it.

There is already a function to map channels. It is how the 'templates' work. We could easily call it when changing protocols (though it might be a bit off when switching from Devo to PPM, since you'd lose your current mappings). Or we could have a new button to do a channel reassignment. To remap the channels would also require code to verify they are currently mapped in the 'expected' way to ensure we don't corrupt a custom configuration.
But the reason I didn't do this was that I never expected anyone to take a modle and change the protocol. I always expected that you'd start with the right protocol and load a template. Of course my expectations and reality rarely overlasp it seems.

I have tried this - you may have seen it in my repo but we decided to roll it back due to some strange phenomena, and I have not found any time to try again.
What I have done was to revert the channel mapping for the old protocol and apply the one for the new. It looked good but worked not correct. And there were still the timer sources and gui element sources open, but I think they are a minor problem (for timer and boxes, the channels could be swapped, but what about bars? If bars for all channels are displayed, the should not change... I thought about a confirmation dialog).

I am very impatient to have the new build including all bug fixes and HiSky protocol ...

Bravo guys, you are making a great job ...

PhracturedBlue wrote: It would take me a solid week or more to write the documentation if I need to start from the 3.0 docs, so being soon doesn't mean this week. But I wanted to make sure thatif anyone is sitting on anything they let me know.

As far as I know Whereaswaldo started with the docs but he is working most time of the week and like most not online 24/7 . You know where the screenshots are.

For a big audience a good and easy manual can help a lot. I started some weeks ago with Deviation and I had some problems with reading. Yes really, e.g. already for using the DfuSe. Some more pictures would have been nice for a normal user. For the rest we should open a new thread like wishes for the 3.1? manuals.

PB, do you have a goal where you want to be with the software tomorrow, in 6 months or even a year? Maybe you can point out some development aims. I think this would be helpful for the crowd to concentrate on whatever. Let's say in 2 weeks next release 3.x. Announcing the next final for e.g. 4 months and what's all fixed and working could be included then. etc. And in parallel the manual can be kept actual to this date.

Just m2c from a user....

BTW: If you need help for the manual. I could help for 7e and 10. I do this stuff in my job at least once a month. But please in open-source.

Sorry, I haven't responded sooner. As mentioned before I run and own a small shop and work there about 60+ hours every week, we are open 6 days a week, but I am usually here seven. We are too small to be able to hire anyone to assist me. Still no excuse.

I was never planning to rewrite the entire manual, just update and clarify with more descriptive and accurate text based on the newest beta. Also adding additional graphics to illustrate all the features. There are some easy ways to describe functions then only highlight where there are specific differences between Devo TX's.

I am trying to get up to speed with LibreOffice, as a very long time MSOffice user some things require thinking. If OpenOffice would be easier to learn let me know before dive into the deep end of the pool.

As far as the basis for images, my thinking was to use Devo10 and Devo12 images and only highlight the differences encountered in Devo7 and Devo8. If this is not acceptable let me know.

Well, for the documentation, I can help to format the contents in OpenOffice. Since I do not have much time to help, so if anybody work out a draft in any format, I can help to put thing together and produce a neat and tidy OpenOffice format.

Just go to nightly build and found the version is 3.0.0 ..... Just feel a bit strange, setup problem?

No, the nightlies are not counted up as the betas were formerly. You can compare the build number with these and see the date of the build.

in the latest nightly build (746479c) on a devo7e, when setting the main page config buttons 2 and 3 are no longer working no matter what options i set them at, while buttons 1 and 4 work as usual. can anyone else reproduce this? just to confirm before i file a bug?

PhracturedBlue wrote: The best thing you can do if you are working on something inconsistently is to check it into a mercurial repo so we can see the state and not duplicate work. If you need help with that, I'm sure we can provide it.

Will this repo used for further works: https://bitbucket.org/PhracturedBlue/deviation-manual
If so, I would add for the first step some chapter numbers. Then everybody could post which chapter will be reworked.
@WheresWaldo: I just installed this TortoiseHg the first time no problem at all.

Already using TorroiseHG and have cloned the repo, just need to find some spare time to start working on the docs. Got LibreOffice installed.

I was planning on starting on page 11 with the Menu system, I also think pages 9 and 10 need to be swapped around, keep the emulator stuff altogether, and I really feel the emulator stuff should be an appendix since it has nothing to do with actual field use of a Devo TX. The more information presented unrelated to actually flying a model just confuses the user, just like too many choices leads to indecision.

Does anyone actually build their models in the emulator then swap them to the TX via USB? I can see it more for templates and screen stuff. But I am sure you guys will tell me if I am wrong.

Totally agree with you. K.I.S.: Keep it simple. I only use the USB to back up my models, but all of them build on the TX.

Me too - the only way to see if channels are assigned and servos move correctly. Since I can easily copy the gui config from another model there is not much to do where the emu would help much. But I still think it has its benefit - look at the skin henkerhaus has built. This would be very uncomfortable if you try this only on the real tx.
I use the emus very often while developing and testing and to look at new features PB has implemented (and to get used to the devo7e/10 menus).

I think the structure of the manual has indeed some potential for optimization. Splitting the doc in some chapters which are more or less isolated seems a good idea. Makes it easier to find a volunteer for one of the chapters than for the whole thing...
PB, any opinion?

PhracturedBlue wrote: Ifsomeone can find a way to combine the devo7/10 and 6/8/12 into a single doc, that would save a lot of time too.Having to proof-read everything twice makes it really tedious.

Please correct me if I am wrong: Simple way would be to add a color screenshot from Devo8 to the corresponding Devo 10 picture side by side. The software and naming is identical. Partly describing the differences from 10 to 7e could be done also for 8 to 12. I am not sure: Is this the RTC only?

One suggestion for 3.1.0:

When I sit at home, on the sofa. playing with my Devo and setting up models and testing the latest release, I noticed sometimes I disrupt the WiFi for my fellow housemates. It would be nice to be able to switch off the TX signal completely. I now minimize the signal to 100uW, but sitting next to my partner, browsing the internet, still disrupts every now and then.