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

vlad_vy wrote: I have minor corrections for DSM protocol. With my limited testing it provide much less number of frame losses (without holds) at ground test (AR6210, 30m, 100uW).

Hi Vlad,

what are they in detail?

Have you described it in thread "DSM telemetry support"?

So you do some DSM protocol code changes in parallel to Indigos DSM protocol changes from his test build repository?
Indigo has not your DSM protocol changes in his repository yet, right?
Are they (the protocol changes) really needed for further improvement?

I was aware of your RF scanner changes however.


With AR8000 + TM1000 I could even walk ~63m on 100uw / 300uw / 1mw on nightly-build fcd0669 and got NO holds at all.

My plan was to write down all numbers (e.g FrameLosses), re-test for different meter ranges, video tape, compare to Indigos test build 36cce5c and his latest 103607a from 10 May 2015. Not a thing you can do in only 30-60 minutes...

I've gone through the manuals to bring them up to date with the current nightly builds (well, as of night before last). I've changed what I could and pushed that, and those are what was built last night. However, I'm not comfortable fixing the images, so here's a list of fixes that need to be made:

Devo8 Manual:

• Transmitter menu cycle is missing the Range Test page
• Model menu cycle up/down arrows seem to be misplaced
• Editing page for simple mix types has been re-arranged

Devo10 manual:

• Copy to example seems to be broken
• Mixer page has been reworked to include input channel name
• Transmitter menu is missing Range Test page
• Helicopter setup in model config is missing COL INV setting (2 places)
• Channel monitor title is now Mixer Output, not Channel Output
• USB page now has a blank line at top
• About deviation image may want a real version number
• PPM Channel mode now has good defaults, not shown.

Both

• Channel monitor now shows virtual channels. Maybe include those.

PhracturedBlue wrote: Devo8 manual:

Model menu cycle up/down arrows seem to be misplaced

I'm not sue what you are referringto, can you provide a link to the specific image/manual entry?

This appears to be a problem in the HTML version, not the PDF version. See www.deviationtx.com/manuals/html-devo8/ch_model.html

Devo10 manual:

Copy to example seems to be broken

It looks ok to me. can you provide a link to the specific image/manual entry?

Not an HTML version issue. See www.deviationtx.com/manuals/html-devo10/...el-setup-std-adv-gui , with the two images in the left-hand column, and squished together. The PDF version isn't quite the same, but those two are clearly being treated differently than the rest.

About deviation image may want a real version number

Nope. I don't want to do that. I purposefully removed the version last time I made that image

In that case, the Devo8 manual About/USB page does have a version # on it. My assumption that that was the correct one was wrong.

PhracturedBlue wrote:

mwm wrote: Model menu cycle up/down arrows seem to be misplaced

Could this be a browser issue? That is an svg image. It looks fiune to me in Chrome/Chromium
Perhaps a screenshot

I'm using Chrome/Chromium. I've attached the screenshot. Note that the arrows on the left and right side are just wrong.

PhracturedBlue wrote:

mwm wrote: Model setup on the Devo10 seems wrong.

The html manual has several formatting issues I need to look at eventually. Is it just formatting, or is there some other visual issue?

This is not just an HTML I've attached a screenshot of the PDF version. Note that the "Copy to" and and "Reset" Image aren't left-aligned like the rest. The HTML version is slightly different, but still not left-aligned. Possibly this is intentional.

PhracturedBlue wrote: Yeah. It is harder to fix on the Devo8 image due to the gradient. Intelligent use if the clone brush or some creative c&p would probably fix it. Maybe easier just to hack the code temporarily to take a screenshot

Maybe we need a "Manual Demo" tag to build?

The arrows look right in the PDF version of that manual. This is strictly an HTML problem.

The images look right to me. Just a minor layout issue. Like I said, maybe that's the way you want it.

Ok, I think the manual is ready for a release, at least for the Tx's supported by 4.0.1. Are we going to add to the list for this coming release?

On the code side, I don't believe there are any regressions. I.e. - everything that was in 4.0.1 works as well in the latest nightly as it did in 4.0.1.

Looking through the bug reports and pull requests, there are a number of things we ought to deal with.

1. DSM telemetry fixes from Indigo. My thought is to just leave them out, as they fix problems that have been around since 4.0.1.
2. Hexfet's channel ordering fixes (pull requests #75 & #76). We do see channel ordering issues, and if these fixes those, we should add them. But I haven't been able to recreate them. My suggestion is to add them for the RC.
3. FrSky telemetry fixes. This is a new protocol, but appears to be an important one for people who want telemetry. Four issues:
   
   1. Telemetry names weren't updated when new values were added. This shows up in the emulator if you enable the CC2500 & then look through the possible values you can put in a main page display box or test on the telemetry page. Fix in pull request 83.
   2. Sensor hub voltage display is wrong. I agree based on the docs, but I don't know of anyone who has one to test with. It only changes the display value, so we ought to do it anyway.
   3. FrSky telemetry not connecting. I haven't seen this, but the person reporting it has a proposed fix in pull request 80, which I've been using with no issues.
   4. The existing FrSky RSSI value is documented as RSSI, but isn't. SebyDocky tweaked it to make it "better", but after using it I disagree with that assessment. There are a number of reasons, but the main one is that there is no documentation on how to use the displayed values. What's a good value for an alert? What's a good value in general? Is increasing the value improving the connection? Etc. Using the actual RSSI value reported as in pull request 84 lets you use documentation on the FrSky values, which is what the manual refers people to for telemetry values.

vlad_vy wrote: My changes are independent from Indigo repository, i'm using clone of the main repository. Changes more related to <8Ch Rx with telemetry enabled (1 Tx packet + 2 telemetry packets per 22ms frame). I hadn't any problems with >=8Ch Rx with telemetry enabled.

Hi Vlad,

how is it going with your Spektrum DSMx 6CH receiver code telemetry changes?

Are they on your Bitbucket repository (comitted) or are you only locally developing / testing?


What are the "problems" (only activated telemetry) you are aware on Spektrum 6CH (AR600, AR6210) receivers either on DeviationTX nightly build or Indigos test build with DSMx channel setting (6 or 7CH)?

Any of those (probably previous / temporarily) problems I described in the DSM telemetry support thread with an earlier Indigo test build? e.g:
- Any lock / loss of TX signal / bind?
- Re-reconnect / re-bind problems (re-plugging flight pack) when leaving on TX?
- Any NO MORE telemetry receive packets once out-of-range?
- Telemetry monitor screen black/inverted (delayed?

What are the concrete enhancements with your changes you do expect over Indigos latest test build on 6CH Spektrum genuine receivers?


I believe I would have to re-activate my low-cost foam e-glider with AR6210 to go for Indigos latest test build version??


450 Blade (AR8000) heli grounded.
Blade 200QX (copper antenna) carbon bottom platter still broken. Carbon too thin. Frame not stiff enough.
LED modified StrykerQ with AR600: Not usable for in-air tests with test builds - so only ground range tests possible.

vlad_vy wrote: I think that these test builds are useless, no feedback at all.

Is there any written down receiver / ground range test concept (e.g Excel list) for testing Spektrum TX signal / telemetry?
What are your test / range recommendations?

Looks like all my models are not crash-proof for in-air testing new firmware protocol code


Thomas

Hi,
so... ummm... I mean... really... will there be any 4.1 or 5.0 or whatever released or are we stuck with nightlies?
I am just a user - not able to contribute in any technical way really, apart from model .ini's, so please excuse my urging... but come on! Let's not polish it for ever, there should be a release sooner or later that is what release numbering is for
Cheers
bm

I think we're ready for a release, at least for the older Rx's, even though the last round of changes broke the devo 12 build. That's a simple fix. Otherwise, all the reported bugs on the older Tx's are either fixed, or minor and date from 4.0.1. There are some fixes that it would be nice to pull in, and some changes that need more testing before being pulled in - but they aren't critical. The manual (the one in the links to the left) is up to date for for the nightly builds, or was - the protocol list might need updating.

So the current nightly should be more stable than 4.0.1, but really needs more testing - which probably won't happen until we at least create a release candidate. I think it's time to do that, but I can't do it myself.

Just found a UI bug in the nightly build v4.0.1-39cfdaf. When I create a toggle button in the screen layout, the button cannot be deleted. All other part works but just the toggle button not working properly. I tried the v4.0.1 emulator and it works perfectly.

Please open an issue in the bug tracker for this. The more details you can give, the better.