There are many ways to skin the cat but I believe only 2 ways are more
suitable and we should investigate them.
Option 1 ioio
===========
If we use ioio we need a standard, if I decide to put a button on pin
whatever of ioio I need the programmers to map it to something, as far as I
understand we can't map it using the events file in XCSoar, only HID devices
can be mapped using the XCSoar events file. If we want to use a rotary
switch we can directly connect it to 2 digital inputs of the ioio but again
we need the programmers to code the decode and debounce of the rotary
switch. Once the decode of the switches is done we could imagine that
everyone can assign them to whatever in XCSoar using the events mapping
file.
Some people are working on a solution similar to ioio, I can't say much
about it but it looks really good and I am sure it will be hugely
successful. The issue is that it is a proprietary device, ioio also is
proprietary but it can be sourced commercially from different places.
What I would like to see is a standard being defined for ioio buttons and
another for ioio sensors.
Something like:
Pin 27 Keyboard char X
Pin 28 Keyboard up arrow
Pins 34-35, 90 degree rotary switch encoder
The XCSoar team would have to do a bit of programming but it would be a
flexible system as we can re-map the buttons using the events file.
Like this if I want to make a device with 2 rotary switches to wear on the
leg then I can do it, if someone prefers 8 push buttons on the stick then he
also can.
We would also need something similar for sensors eg: undercarriage, flaps,
temperature etc.. that is another topic but it should be considered when
defining the buttons so we do not run out of inputs on ioio.
Option 2 bluetooth HID
===================
If we use a Bluetooth HID device presenting itself as a mouse or keyboard we
do not need additional programming done in XCSoar, we just assign the event
eg Press key A, to a function in XCSoar. The issue comes if we want to use a
rotary button, to do so we need some form of encoding that the circuits
ready for HID devices do not support. If we use non HID Bluetooth circuit,
it can be programmed but we also need to program all the HID part which is
pretty big job. If the Bluetooth device is not seen as an HID device, then
we need drivers in the Android or some coding in XCSoar.
Options are to cannibalise a mouse and you have 5 or 6 buttons and 1 rotary
switch and all the working logic, nice and simple but this doesn't scale
very well as that model of mice may not be available everywhere and may be
discontinued any time. Another solution is to use some discrete logic in
front of the HID chip and do the encoding and debounce of the rotary switch
in hardware, then feed the code of a key like arrow to the HID Bluetooth
chip.
I think we should be looking at both the ioio solution and the blue tooth
solution but we do need a standard for the ioio pins and decoding.
Cheers
Jax
From: Scott Penrose [mailto:sco...@dd.com.au]
Sent: Friday, 29 June 2012 8:12 AM
To: Kris Cichon
Cc: xcsoar-user@lists.sourceforge.net
Subject: Re: [Xcsoar-user] External buttons for Android platforms
Look .. we don't need to necessarily rediscover a wheel ..
There are some "remote control units" available on the market .. checked in
gliders already ..
check this one out
".....After spending a number of months gathering pilot input regarding
shape and determining a method for accommodating the wide range of stick
diameters, we are in the process of finalizing our design for a machine
carved wooden handle mounting the Remote Control keypad (including an
additional button for PTT) to the stick for convenient in-flight use. We
expect to have the design finalized and to make this part available through
our dealers by July 2009. Retrofitting for the Stick Handle Remote is
possible at any time after installing the ClearNav, and having the backup
handheld remote is recommended to enable use in other gliders or at home
with the power adapter.
OR Remote Control, Stick Mount Module Only
$135.00....
fromTim's Mara Wings&Wheels ......
http://www.wingsandwheels.com/clearnav_nk_clearnav_nielsen_kel.htm
I am sure we can spend eons debating how many button .. knobs etc ... while
we already have something working.
Just a matter of assigning proper function to it .. or BETTER YET ...
providing an INTERFACE WHEN I CAN MAP MY DESIRED FUNCTION to these buttons
... and this is what I would call PERFECT ..;-)
Kris Cichon - KiloCharlie
I have a stick mounted set of buttons. Mine is just 4 buttons, while John
Wharingtons has I think 8, 4 way hat (joystick), up/down etc. But as you
said, there is lots of things you can already buy.
There is three parts to buttons in a Glider
* Physical buttons - these are what you mention above. They are only
buttons, not useful by themselves
* Electronic interface - how you get the buttons into the glider. This can
be done with some electronics already (e.g. I use a Vega, but there are
plenty of other choices). Other choices are a IOIO- this is a good choice if
you have it already since you don't have to buy or run anything else at the
same time.
* Software mappings - the button you pressed gets turned into some form of
code (either NMEA or a HID button) and you have in your software what it
does.
There are people working on the middle bit using the IOIO boards, since they
are so versatile for buttons and serial ports and charging your android
devices. You would then in theory wire in any button.
The last bit, mapping to any function you like, already exists.
Unfortunately it is a text file to edit. Making an interface is possible,
but could be time consuming for limited use. Another way would be to write a
web interface to create the file for you. Or just ask on the list and
someone (like me) can help you write the config file.
Scott
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
