New FrSkyX protocol

Since I compile my own build, I've no issues in disabling the telemetry serial out myself. However, I still think it's not a good idea to enable it by default in the general built. For the majority of FrskyX users, I don't think many of them will ever use the telemetry serial out feature. Protocol timing is critical and adding unnecessary serial port handling within the protocol code is kind of wasting system resource, especially when people can't even turn it off (unless they can compile their own source). I remembered I had added some serial logging statements in FrskyX code before, and those logging statements sometimes resulted in dropouts due to they consumed extra CPU cycles. Anyway, that's just my 2 cents.

I appreciate your input and will keep in mind. Wanted you to know why I implemented it as it is.

Another reason it's on by default is that if there's any problems I'd rather know right away. It has to work no matter what other options are turned on. The telemetry serial out is implemented with DMA so the only extra processing is calculating the checksum and setting up the transfer, and a final termination interrupt. The DMA and interrupt are at lower priority than ADC DMA and timer interrupt. The serial output takes about 1.8ms and occurs during the 4ms window for processing the s.port packet. Since it takes 2 over-the-air telemetry packets to receive one s.port packet at least 72ms separates each telemetry serial out packet.

Just quick report:
I have been flying first time outside, using x4r with sbus to betaflighht 3.1 and the u7e build of HappyHarry, flew some lipos and I had no problems to report with this protocol. Telemetry I use the analog port for my battery not used smart port yet.
Do we have some more field reports people flying the x protocol with success? Can we conclude it is stable?

Thanks hexfet and petesmith for the info! I'd like to look into the altered firmware option before I have to pull my quad apart again and build the divider.

As a relative newb wrt coding, could you offer some resources on what I would need to do specially to a firmware file to remove standard GUI and enable s.port telemetry? I didn't see any anything in the test builds section that look like a good jumping off point.

Follow the directions here to set up your build environment. Make sure you can build the unmodified 7e software.

Then edit file deviation/src/target/devo7e/target_defs.h. Where you see HAS_STANDARD_GUI 1, change the 1 to 0. On the line with HAS_EXTENDED_TELEMETRY change the 0 to a 1.

hexfet wrote: Follow the directions here to set up your build environment. Make sure you can build the unmodified 7e software.

Then edit file deviation/src/target/devo7e/target_defs.h. Where you see HAS_STANDARD_GUI 1, change the 1 to 0. On the line with HAS_EXTENDED_TELEMETRY change the 0 to a 1.

OK thanks. So this process will build a firmware file with the FrSkyX protocol currently only available in the Nightlies?

Yes, the default is to build the master branch which is where the nightly build comes from.

hexfet wrote: Follow the directions here to set up your build environment. Make sure you can build the unmodified 7e software.

Then edit file deviation/src/target/devo7e/target_defs.h. Where you see HAS_STANDARD_GUI 1, change the 1 to 0. On the line with HAS_EXTENDED_TELEMETRY change the 0 to a 1.

So I was able to get docker installed and was able to follow all of the steps down to creating the image. When I select "Build" it just creates the image and it looks like any other download of deviation. I do not see a folder for "deviation" in the zip file. How do I access deviation/src/target/devo7e/target_defs.h? If this is something I need to do before i select "Build" how do I do so? Thanks again for the assistance.

The change needs to be made before you build. Tab over to the Shell menu item and select it. That will put you at a linux command line inside the docker container. The deviation directory should be under /git I think (my setup is slightly different).

After you make the changes type "exit" at the command prompt and you'll be back in the menu. Select Build and you know the rest.

hexfet wrote: The change needs to be made before you build. Tab over to the Shell menu item and select it. That will put you at a linux command line inside the docker container. The deviation directory should be under /git I think (my setup is slightly different).

After you make the changes type "exit" at the command prompt and you'll be back in the menu. Select Build and you know the rest.

Im sorry again but i am still not grasping it. i am able to get to the linux command line through shell. i have typed

dir git/deviation/src/target/devo7e/target_defs.h

which is what i think i need to do but it just repeats what i typed and drops me to the next command line. i dont see an option to select or edit a file.

Ignoring all that, can you tell me why it's telling me this
edit: so the above problem is solved by removing the ~/ in front of devo_builds.

Now when I compile there's nothing in devo_builds.

Dockers shell has vim preinstalled. Using that to edit files


P.S.
I really like this docker thing. Thanks mwm
P.P.S getting errors :/

From the recent commit messages for DSM improvements seems like it's already a squeeze for the 7e and dropping standard GUI doesn't get enough memory back to allow extended telemetry. Don't see an easy workaround at the moment.

Bummer. Looks like its time for Plan B. Please update if there are any changes and thanks again.

@petesmith: Do you use a non-ultimate 7e? If so, is there a way you can share the custom build you got working?

LumpyLouis wrote: Bummer. Looks like its time for Plan B. Please update if there are any changes and thanks again.

@petesmith: Do you use a non-ultimate 7e? If so, is there a way you can share the custom build you got working?

I'm using an Ultimate 7e. When you remove standard GUI, you will gain around 5KB space in flash ROM. However, the extended telemetry code are part of the protocol module which resides in RAM (4KB RAM on the Devo 7e is dedicated for loading protocol modules dynamically). It's possible to move the Frksy extended telemetry code (and/or part of its protocol code) to ROM space and allowing it to fit on the 7e. However, this will require code changes and will become very messy to maintain. I don't think any Deviation developer will want to go this route. Sorry to get your hopes up as I didn't realise this until I checked out the source code.

@vlad_vy @petsmith would it be possible to create my own build after rolling back some of vlad's changes (or better yet, disabling the dsm2 compile ) so that I can compile a frsky build with telemetry ?

I understand that the 7e is restrictive but i hope there are workarounds

It's nothing to do with DSM2. You can easily disable extended telemetry for dsm2 and making it fit within 4K. The problem is FrskyX with extended telemetry, it will not fit in 4K RAM space. If you are good at C programming, you can move the FrskyX telemetry code from RAM space to ROM space. It will require some work but it's definitely doable. However, it will also result in messy code and will be hard to maintain in the future, so I don't think any Deviation developer will want to do it.

on my Devo10, is it now possible to have the battery voltage with the XSR ?

okay, I took the time to move the FrskyX Extended Telemetry code from RAM to ROM and created a special version for Devo7e. Pls note the following:

- Standard GUI is removed
- FrskyX with Extended Telemetry
- DSM2 without Extended Telemetry (I suppose we can also support it if needed. We seem to still have enough ROM space for it.)
- it's based on the latest nightly

I don't have a standard Devo 7e to test. Let me know how it works out.

PS. The zip file is too big to be attached in the forum. I uploaded it to some free hosting site.

www.sendspace.com/file/9wwq9z

sfersystem wrote: on my Devo10, is it now possible to have the battery voltage with the XSR ?

Yes, extended telemetry is supported on Devo 10. That is, you can see your model's battery on your Devo 10, provided your FC can supply the battery info to XSR via s.port.