Deviation v5.0.0 build with latest protocols

My little English is a can limit to explain but I will try.
On version 4.X and 5.0, to set up a model, simply click on the icon of the model and then move from page to page with the arrow at top/right of the screen.

Since NB versions, with the touch, not only must you leave the model to enter the screen that groups the configurations, but it is necessary to stand out of each configuration page to go back to another page.

I think I summarized the feeling of those who have a devo8 or 12 (if an anglophone can confirm my sayings)

Hello vlad_vy,

I was wondering if there are any changes in the dsm2/dsmx protocols you are posting here.

I ask because when I installed the 4in1 module into my 7e and installed the latest deviation nightly I started having some strange range issues (still testing but so far the good results are pointing toward software and not hardware).

When I reverted back to the 5.0 stable version and then uploaded your dfu and protocol folder I found my dsm2/dsmx range issues have seem to have been resolved (again still testing).

Is there any difference in the protocol files for dsm2/dsmx you are using compared to the nightlys?

Many thanks as your files have helped my devo 7e to gain another step in becoming my favorite tx. AFHDS2A works flawlessly with FSA8S receiver by the way.

EDIT: Just put three batteries through my 250 frames (1 on lemonrx dsmx and 2 on redcon dsmx) and had zero brownouts. When I was on the nightly (2017 Apr) I couldn't get beyond 10 ft on 150mW tx power. I had checked all hardware before reverting the software. So I want to go on a limb here and say that the dsm2/dsmx protocols from the 24Mar2017 devo7e zip file is a solid build. Now even more I'm curious what the differences are between the protocol files here and in the nightly as we can't use protocols from different dfu versions.

vlad_vy wrote: There is not any differences at protocols between Nightly Build and this build, except FrskyX and Q303, they use some features that be lacking at v5.0.0.

Thank you for your confirmation. The only other variable I see is the dfu file. I don't pretend to know how the software works but I do know that the nightly didn't like my setup. And yes, I do know the nightly is even more experimental than the stable but I just thought my experience might help somewhere if any.

Again many thanks for your work here.

vlad_vy wrote: There is not any differences at protocols between Nightly Build and this build, except FrskyX and Q303, they use some features that be lacking at v5.0.0.

I think vlad_vy means that his version is almost the same as 5.0 nightly, not 5.0 release. I remembered that the current nightly should applied some fixes on dsm after 5.0.release.

Am I right, vlad_vy?

richardclli wrote:

vlad_vy wrote: There is not any differences at protocols between Nightly Build and this build, except FrskyX and Q303, they use some features that be lacking at v5.0.0.

I think vlad_vy means that his version is almost the same as 5.0 nightly, not 5.0 release. I remembered that the current nightly should applied some fixes on dsm after 5.0.release.

Am I right, vlad_vy?

I tried looking for the release changes pertaining to the nightly builds in regard to dsm changes and haven't found anything.

I don't mind revisiting the nightly build but now I'm awaiting my new processors for my devo7e tx's (two times) so until then I will stick with the last build from this thread.

vlad_vy wrote: github.com/DeviationTX/deviation/commits...ocol/dsm2_cyrf6936.c

Many thanks! I'm gonna dig around as I didn't see the afhds2a or dsmx protocol files in that source directory.

vlad_vy wrote: DSMX inside DSM2 file, flysky_afhds2a_a7105.c

Many thanks.

So if I understand the source correctly (and I could be wrong as I haven't done any programming long enough to be proficient) the packets are built for dsm2 or dsmx during the bind process based on the protocol selected (dsm2 or dsmx).

Since the code is housed within the dsm2 c file and it checks for dsmx protocol I would assume the reason there is a dsm2 and dsmx mod file in the tx filesystem protocol folder is to allow the specification of dsm2 or dsmx which is used to bind in the selected protocol.

If this is the case...would it be neater to have a single c file (dsm.c) and in the tx protocol menu have the protocol show up as dsm with a sub setting like the orangerx setting to switch between 2 or X and then it should only need the dsm.mod file?

Just thinking out loud. If I am wrong anywhere I am always open to learning.