Is a Deviation v4.1 release on the near horizon?

No, I deleted the Roman- from Times-Roman- (note the trailing '-'), then replaced Oblique with Italic. I assume you wrote the devo.style file, so choose those font names. Just to be confusing, my book of typefaces uses Times-Roman-Italic, which neither set has.

Care to try the names that work for me on your system? That Google doesn't find references to Times-Roman-Oblique makes me think that's something specific to your system, not Ubuntu. Or maybe Ubuntu added them to a system-wide font map file for some reason.

And yes, pandoc produces different output. It's a format (mostly markup) converter that can convert to output formats. It's got it's own set of readers and writers.

You'd have to check it to be sure, but it wouldn't surprise me. Sphinx is designed to generate documents from their extended RsT, whereas pandoc is designed to translate between a slew of document formats (including it's extended MD, of course).

On the other hand, LaTeX is pretty pure markup, with the presentation tied to the document type, so the structure of the LaTeX may be so obvious that they wind up being the same.

Ok, a first review of the Devo 10 manual. These are all things that I think need to be changed. Anything I was positive needed to change and new what to plug in has been turned into a pull request.

First, I'm getting a bunch of errors about "Unknown target name". I get the same errors on the Devo8 build.

It seems like all of the bolditalic paragraphs need a newline in front of them.

The list of "other" protocols in the intro is missing a lot of things, but listing them all would make it really long. Maybe change it to say "many other protocols", and then before the list "Some of the most popular are:" I'd add FrSky to the list, and drop Skyartec and HiSky mostly because I have no idea how popular they are.

The third paragraph of legal status & copyright section should probably be merged into the first paragraph of that section. The last paragraph of this section looks odd. Why is it bold/italic? And it also needs a blank line in front of it.

The next-to-last paragraph in the chapter on reporting bugs looks like it should be a bullet list instead of inline.

Second paragraph in the installation chapter says "As a result of memory limitations with the Devo12 firmware, ..." Shouldn't that be Devo7e? Or maybe Devo12E?

I suspect we want to change references to the Devo12 to say Devo12E. Or possibly "Devo12 models" if it's true for all of them.

First image in the main page chapter has the arrow for "Throttle Stick position" pointing to the toggle icon.

The title of the section on navigating with physical buttons should probably be different for this manual. Best would be to just make this section part of the previous chapter. Not much point in having a section 6.1 without a section 6.2 to go with it.

The page that the Main Menu chapter starts on actually starts with the text ":orphan". Looks like an artifact from sphinx. This looks like the source of all the "unknown target" errors, both because the names match text on this page, and because what looks like they should be links are busted.

The name "template" to refer to the None/Simple/Expo&Dual-Rate/Complex choices in the model menu chapter is confusing, considering what's int he template directory.. I tend to refer to the collection of mixers on a channel a "mix", and this as the "mix type". That's an improvement, but not much of one.

Looks like the paragraph about Mux's in the cyclic template section of the model menu chapter should have bullet list, not an inline list. Might also want to point out in the multiply mux that what's multiplied are the percentages, so a multiply mux with a value of 50 would reduce the input value by 50%.

The swash configuration section, next to last paragraph has another list that looks like it should be a bullet list instead of inline.



Orphaned titles: [/b
Generic Settings, Input Monitor, Simple Template, Trims & Virtual Inputs (Adv GUI),
Gyro Sensitivity

Broken References:
"Protocols" in the telemetry monitor section, and Model Setup section under Protocol & Bind/Re-Init
"Mixer" in the third paragraph of the Model menu chapter.
"USB & FIle System" in the Model Setup section, under Icon.
"Model setup ..." in the third paragraph of the Mixer (Adv GUI) section.
"Available Curves" and "Curve editing" in 9.2.6, under Curve.
"Protocol: PPM" and "Model setup..." in the Slave Mode section.

Ok, I've fixed everything I mentioned earlier, except the orphans and references. I reorged the navigation chapter pretty heavily, so that's a pull request.

Given the popularity of the 7E, I think pulling it out as a separate manual would be worthwhile. If you agree, I'd be glad to make a pull request for that.

FDR wrote: Where to post documentation errors

It's a bug, so use the bug tracker link in the menu.

So how are you feeling about the open issues and a release? Do those need more work, or is it just a matter of getting the manual up to snuff?

Actually, it looks like we have a regression in the DSM code. I've got an issue with the AR6210 not connecting properly with the lastest nightly, but working fine with 4.0.1. Since he also had problems with the WK2801 Rx (since fixed), I'm asking for one last bit of details from him, then I'll get a new issue without all the notes take to sort out the WK issue and what was really going on with the AR6210. And hopefully someone with an AR6210 can look into it.

@Mike
Is it Nightly-Build from deviationtx-team? Not Indigo latest test build?
You could not bind / connect when powering on or was it in between (ground)? I may be able to re-test your issue with my AR6210+TM. I also have AR600+TM.

@PhracturedBlue:
Are your plans to do a V4.1 release with the current DSM + telemetry code as of nightly-build (deviationtx-team) which seems to be somehow rocking solid with my AR8000 + TM1000 so far

or

are your plans to already merge in pull request #48 Indigos DSM + WK protocol changes

without

further multiple weeks / months further ground + in-flight tests?


I would like to suggest go the route with small steps (V4.2, 4.3...), that is to rls current code as of V4.1 and have a little bit more time for tests on Indigo's code improvements.

I definitly have to re-test the "Fades A 255->0 number reset" issue which is working fine so far with nightly-build with latest test build.


My feeling is that there are not that many testers with the appropriate Spektrum receiver equipment + time
My understanding is, that ground tests alone with 100uw/300uw/1mw are not enough alone when you are doing bigger protocol code changes as of the test builds.

Thomas

It's "my" issue in that I assigned it to me while I sorted things out. I don't have an AR62010. He also opened a forum thread you replied to. We've sorted out the WK2801 issue.

The current report is with the last nightly build. Once you bind, if you turn on the Tx and then the Rx, the Rx doesn't connect. If you turn them on in the opposite order, it connects. Using 4.0.1, both sequences connects. If you use DSMX instead of DSM2, both sequences connect.

My feeling on the DSM code is that we ought to update whatever the latest code from Indigo is with code from the default, and then build two release candidates for people to test: one from default and then his. We can decide which we want to release later. On the other hand, since I don't think there's anything in the 4.0.1 DSM code that isn't in the current nighly, I'm fine with releasing it as is and sorting out the DSM code later.