Development post 5.0

consistency is important, but i'd use the devo 12's larger screen to display the first and the second row of selections on one page, that should be easier to navigate.

other than that, any improvements on the button handling for the 6/8/12 is welcome, i rarely use the buttons on mine, they feel disconnected from the ui.

I welcome a way to navigate the 6s more efficiently than the stylus as my fat fingers are no substitute. I have been planning to use the buttons other ways, but since I regularly swap between the 7e and the 6s, I like this new approach.

I think the point of having a touch screen is to not use the buttons as much...I rarely use the buttons on my 12 and 8s it is much easier to use the stylus and removing any of the touch screen features would defeat the purpose of having a touch screen...

One issue you might look at while doing this is that - on the 6S at least - button support is, um, "incomplete". In particular, using the Up/Down buttons to work through a list of things long enough that it has a scroll bar won't scroll, but bounces back to the top. It's a minor annoyance, but still an annoyance. If you need more details, let me know.

I like your choice of words, MWM. I do like the freedom of the touch screen, yet I find it awkward to navigate menus in the field. The stylus is the only option, and it is easy enough to lose. Any improvement is welcome.

What are your plans to test / integrate Indigos DSMx protocol test-build rewrite / RX-TX error checking, telemetry packet filters, etc.

How do you plan to bring (e.g part of test build changes/enhancements) code changes to 5.x.x?
Pull Request which merges only into master?
Pull Request which merges into branch 5.x? Is that even possible? Only manual merging?
Pull Request to both Master and Branch 5.x?
Creating further releases (tags) 5.x.x from branch 5.x instead master?

Indigos created pre-existing Pull Request was from BitBucket default repository so would be back merged into default.
He was working on default...not branch 5.x.

So many changes in 1 year...vlad DSM protocol changes (not sure how they relate to Indigos code)...new thread about DSM protocol compression.
Code changes by developer who can not even test their DSM code themself (OMG)...if ever approved would need for sure an intensive DSM protocol 5.0.x RC testing...

All my DSM support thread questions unanswered

Interesting for me to see if you find any concept.
I already fear Indigos code will be just a throwaway and frozen forever??
How can we make a progress?
Maybe just try to focus on DSM test build code parts (e.g RX error checking, telemetry filter packets) which might actually be accepted to be merged.


Who is alpha/beta testing Indigos DSM test-build (with the proper models)?

For me: Still no proper final quad electronics and crash-proof planes for giving Indigos test build a rough weeks test

Thomas

Any reason why the DSM protocol switch for telemetry on/off on the 7e does not work since 8/2014?
Indigo reintroduced this within his test builds but it never managed to be in the nightly or master build.
For the lack of code space (4K) on this transmitter or for what reason?
How about switched off by default?

Getting slightly off topic I know, but I'm of the belief that DSM is a MAJOR thing in the Deviation world, primarily because (a) there are no module hacks required, and (b) there is an abundance of dirt-cheap recievers available. Or diamond-expensive if that floats your boat.

Though there seems to be a gradual shift towards frsky's stuff, DSM is still by far THE major protocol(s) in RC flying, and as such I think it deserves / requires a serious solution.

While obviously Spektrum won't want to talk to us, I think Orange and especially Lemon may be very willing to work together to ensure things connect correctly. I believe Lemon reps are active on rcgroups last I saw, but that was a while ago that I checked.
Redcon also seem to have suddenly become a serious player / supplier, so they may or may not be willing to assist? Seems there are a few native Chinese here with connections to the RC development industry there, anyone willing to put up their hand?

I'd be willing to donate a proper spektrum sattelite (or possibly an rx if a sattelite isn't enough to work with) to any of the protocol developers if it will be of any use? iirc I have a few sattelites and ar6100e, ar6210 and ar7000 recivers, all proper spektrum stuff, though they are all only dsm/dsm2. i do have dsmx stuff as well but it's mostly all lemon brand receivers and sattelites, I have a few orange sattelites of unknown heritage as well, some may be dsmx but i'd need to test them. if any of the above items are useful to help on the dsm* protocol hacking just let me know and I'll get it in the mail

I like this maybe because I use the 10 and 7E for such a long time, I recently bought a 6S and I realy miss the way I navigate in the menus with the former two.

I am considering using the Devo10 menu system for the Devo6/8/12

Since this probably fits better here than in the FrskyX thread:
Can you provide a means to get the current TXID, PB?
Write it to the tx.ini or something.
I'm wanting to swap the CPU on my main 7e, but it'd save me a ton of trouble if I could keep the bindings to all my receivers. Also would be nice for people who have to replace a broken transmitter.

]Edit your hardware ini.

This is mine. Change the number after txid=

;Only useful for transmitters with an after-market vibration motor
;enable-haptic=1
;
;switch_types: 3x2, 3x1, 2x2
;extra-switches=
;
txid = 86668963
[modules]
; there is no need to enable the cyrf6936 module unless
; it is wired to an alternate port. It is Enabled automatically otherwise
; enable-cyrf6936 = B12
; has_pa-cyrf6936 = 1
enable-a7105 = A13
has_pa-a7105 = 1
; enable-cc2500 = A14
; has_pa-cc2500 = 1
enable-nrf24l01 = A14
has_pa-nrf24l01 = 1
; enable-multimod = A13


Give each tx the same number.

This will only work when you rebind the rx's afterward. It replaces the "standard tx id". This kan not be found as far as i know.

Tom

I'm aware of that option, and is why I was hoping for a way to read the TXID. There's code to calculate the ID and it's used in binding, so there's no reason not to be able to export it to a textfile.. it just hasn't been done. I'm no coder myself, so my lame attempt at getting it to do that failed so far.