Stick as Encoder

[MikeB]

I'm experimenting with the use of one of the sticks to navigate round the menus. Without a rotary encoder, moving round the menus can be quite tedious.
The idea is moving the stick right simulates pressing the right button, the further you move the stick the faster the button gets pressed. Similarly, moving the stick left/up/down simulates the left/up/down buttons.
This obviously only works in the editing menus, not on the main screen(s).
At first testing it seems to work quite well.
Currently I'm using the right stick (I fly mode 2) as it centres both ways.

I thought of this as I find the controls available on the new FrSky radio a bit less easy to use than the 9X, due to the position and labelling of them.

Mike.

[jhsa]

Maybe when changing values, the further we move the stick from center the faster the values scroll..
Just an idea.
Unfortunately the Turanus radio doesn't have an encoder. It's a turn off and one of the reasons I ain't getting one..
The stick idea will probably help a little bit

[Kilrah]

That's exactly what he said.

I've used stick navigation with OSDs etc, IMO it can be great to edit a value, but menu navigation was actually slower (press/release is quicker than move out and back to center, and getting the timing right to stop on the desired item when going faster isn't easy). Will be interesting to test in this case.

[jhsa]

Yes, I see now.. that's what he said.. It just proves that great minds think alike
Or probably that I'm getting old too fast and can't read anymore..

[Clivew]

Fillock

Sounds a good idea Mike

[MikeB]

Since it emulates left/right/up/down button presses it does edit values as well. It will need some "tuning" to get stick movement and repeat rate working well.

With my testing, you can, for example:
Press long left to get to radio setup, then moving the stick left or right moves between menus.
Stopping on a menu, you can move the stick up or down to select an item.
If a multi-item row, moving the stick left or right selects between them, if a single item, moving the stick left or right edit the value.

Mike.

[Rob Thomson]

I have used similar systems on Futaba radios.

Essentially the stick postition can do things like moving the offset values quickly to end locations.

I like this idea for the taranas!

[jhsa]

Mike what about when programming the dual rate values for both sides of the stick?
If I remember well at the moment we must move the stick to the side we want to edit, right? could that not cause some conflict??

João

[MikeB]

Quite possibly! There is also the "ANA" screen and the "CALIBRATION" screen.
The first part of the stick movement does not move anything, so this would set the direction. It will need looking at carefully.

Mike.

[MikeB]

I'll release a version of both ersky9x and er9x with this in, probably tomorrow. I've blocked the stick scrolling in those screens mentioned in the last few posts.
On er9x, if stick scrolling seems useful, I'll probably remove the pot scrolling as it is wastful of flash to have both. I might make two different version of the FrSky version, one with pot scrolling and one with stick scrolling. The NMEA version might need the same, both are using a lot of the flash.
I may look into re-writing the expo/dr editing to allow stick scrolling, when time permits.

Mike.

[kaos]

I think that is the biggest mistake Frysky made designing the Taranis. If they put a wheel encoder like the DX6i on one side would be great. we will see if the X12D will make that change.
Looks like the Taranis is a pass for me. Hale to Sky9x!
I also see some one is coming out a way to put a encoder on the Taranis already. That may get me interested in oe.

[MikeB]

FrSky didn't specifically leave an encoder out, they are using a case already available. Tooling costs for case mouldings can be quite high, so they chose to keep the end user cost down.

Mike.

[Rob Thomson]

I think you may well be tempted.

Even without the encoder, it is good and quite usable. I would not be surprised if some enterprising chaps start swapping pots for encoders to

Sent from my Nexus 7 using Tapatalk 2

[ReSt]

The NMEA version might need the same, both are using a lot of the flash.

Mike.

My actual NMEA version is 1551 bytes smaller than the FrSky version
The basic version with Heli and templates is 62389 bytes versus 63935 bytes.

Reinhard

[Kilrah]

I would not be surprised if some enterprising chaps start swapping pots for encoders to

The easiest would be one of these things that are not "real" quadrature encoders but rather 2 switches (turning one way clicks one switch, turning the other clicks the other). This would be directly connectable to the +/-/enter key connections, and most of the navigation is already adapted to it.

[MikeB]

My actual NMEA version is 1551 bytes smaller than the FrSky version
The basic version with Heli and templates is 62389 bytes versus 63935 bytes.

The "official" builds are:
FrSky (no templates) 61938
NMEA 62378

Mike.

[jhsa]

The easiest would be one of these things that are not "real" quadrature encoders but rather 2 switches (turning one way clicks one switch, turning the other clicks the other). This would be directly connectable to the +/-/enter key connections, and most of the navigation is already adapted to it.

That's what I have on my ancient Graupner mc-16

João

[ReSt]

The "official" builds are:
FrSky (no templates) 61938
NMEA 62378

Mike.

Don't know how that happens, but my locally compiled versions (r788) are

FrSky (NoT) 61548
NMEA (NoT) 60066
NMEA (NoH) 61310
NMEA (NHT) 59574

And I verified, the NMEA version is working, with Heli setup menu, GPS, voice and 7 Gvars in the menu.

I have only two minor mods in menus.cpp that finally will increase the size by a few bytes and a mod in the templates that either takes up 200 bytes or saves 500 bytes, depending on your compile options.

I'm using avr-gcc 4.7.2. 20120917

Reinhard

[MikeB]

The "official" NMEA version includes H and T I believe. Same compiler used.
I curious your FrSky(NoT) version is around 400 bytes smaller. Have you got some extra compile option set? The googlecode repository includes the make.log file from the build. Perhaps you could have a look and compare with your build output.

Mike.

[kaos]

I would not be surprised if some enterprising chaps start swapping pots for encoders to

The easiest would be one of these things that are not "real" quadrature encoders but rather 2 switches (turning one way clicks one switch, turning the other clicks the other). This would be directly connectable to the +/-/enter key connections, and most of the navigation is already adapted to it.

that is all needed, as far as I am concerned with a wheel encoder. a wheel to change numbers or different/multiple display screen and selection of menu choices. whether it is a round wheel or a roll bar does not matter. It is the usability/ ease of use matters.