I like the idea of having some standard pins mapping to standard buttons. In
theory then you can even have the buttons/inputs dual named, e.g. A = Mc+ or
something.
Also need to consider alternative inputs such as Analog, to allow wiring with
restricted pins - but again still can be standard.
As for bluetooth, I started with the game controller, but since then I have
built a number of bluetooth devices for projects, mostly based on the RN-42 -
which cost about $20. One of the best features of this module is that you can
wire up buttons directly to it, means all you need is a battery, some buttons
and the device. Also acts as a HID bluetooth device, so easy to connect to
Android, or even an old iPaq.
The other systems I have built have used AVRs ($10+ for a board) to talk serial
to the RN-42 to do more complicated things.
Scott
On 29/06/2012, at 12:58 PM, Jacques Graells wrote:
> 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
