This is a lot to digest :) A few comments / follow up questions: 1. IIUC, the telemetry from the glider gets sent over your existing RF equipment and magically ends up on the ground. What is the interface which the receiver uses to publish this data? Serial of some sort? 2. All the Android questioned you've raised can be figured out by reading stuff on developer.android.com or searching / asking on stackoverflow. I think that all the things you're trying to do are feasible. 3. With an older Android you'd have to use ADB to talk to the IOIO. This will introduce a little bit more latency (~3-4ms one-way) than OpenAccessory (1-2ms one-way), but should otherwise be fine IOIO-wise. It is possible that some of the other stuff you're trying to do (that things that are not IOIO-related) will be harder or impossible on these devices. Just read the Android docs and notice that they specify for each feature when it was introduced. 4. You had some question regarding an accumulator. I do not know what that is. 5. Regarding the Android not being connected: you should be fine. The IOIO takes maybe 30mA. Just make sure to pull the servo control pins in a way that will make the servos free-wheel as opposed to lock to an arbitrary position. 6. I don't understand your question about cutting the board. The PCB layout is publicly available if you want to take a look. I'd be surprised if you can cut any significant portion of it and keep it working :)
On Fri, Oct 10, 2014 at 10:42 AM, Helmut Stettmaier <[email protected]> wrote: > Hello, > I currently check the feasibility of an Android-IOIO-project and kindly > ask for some assistance. > > *At first some information on the project:* > There is a model glider, equiped with some telemtry (altitude, climb, > energy data, later more) and these data shall be processed and rendered in > several ways: > > - acoustically: a very special climb tone (a novel one, not as usual > today) and few spoken data (e.g. altitude and some alarms), > - haptically: a hardware of this kind exists already (and I like it:) > and shall be renewed and improved, > - optically: Of course reading a display during flight is not a good > idea in most cases, but upcoming data glasses (more adequate for such a job > than Google's) might change this scenario. > > My current module consists of an 8-bit-controller; it reads the data > stream and controls two servos for the haptic rendering, all this inside > the case of the RC-transmitter. I like it but it is outdated and is to be > replaced. At first I thought of a simple replacement by another Cortex-M0 > based hardware. > An alternative replacement could be a small Linux-hardware (smaller than > RasPi) - currently I'm not really convinced by the Intel-Edison but I think > of an Arietta G25 <http://www.acmesystems.it/arietta> and this is still a > real alternative. All but optical rendering is possible with such a > solution. It is by far not simple as I'm new to embedded Linux and would > have to add hardware. > There are, as I know, already few Android apps which render telemetry > data, but they are not closely enough what I want. They use a Bluetooth > connection and cannot send back data (e.g. for the haptic rendering) to the > RC-tranmitter. I also would have to change or complement most of their > rendering software. > > Additionally it could be interesting to design this (new) "render engine" > as an open "platform" for several "applications" for special data analysis > (beginning with a logbook-app and continuing with guidance or recovery apps > based on future GPS data). > > *Now the facts, which caused me thinking positively of Android-IOIO:* > > - I would not have to build new hardware: IOIO can read the data > stream, route the data to the Adroid device, read an extra switch I mounted > onto the RC-tranmitter case, and it could power and control the servos. > - I would NOT like to use a Bluetooth connection and IOIO's USB > solution looks fine, despite the cable. > - Very important: It could also power the Adroid device and prevent it > from depleting its accumulator - the RC-transimmter's accumulator is > powerful enough to do this. > - An Android device could be a good platform for experimenting with > data analysis (e.g. -->when to "say" the altitude automatically). Migrating > the software into proper Android data glasses would be a very fine top on > all that. > > *What makes me doubt a bit is:* > > - I would need an additional device - for some scenarios this is not > ideal or at least uncomfortable. > - Can the Android device do or yield what I would need (see list below) > - I would have to learn writing and debugging Android Apps (I have > programmed a bit with Java-SE and -ME several years ago... :) > > *What do I need from the Adriod device?* > > - Novel climb tone: I would have to mix several tones (sawtooth or > similar) with different frequencies and volumes. The tones change virtually > continuously. Is this easily possible with Android? Which API would I have > to look for? > - Rendering values by speech: Few short phrases are to be spoken ("125 > meter" or so); numbers are to be spoken but I really do prefer to spell > numbers by their digits ("One-two-five" instead of > "one-hundred-twenty-five"). There are at least 3 methods to do so: > Concattenating prerecorded words, text-to-speech and preparing phoneme > strings. > I have tried out phoneme strings with a "SpeakJet", the qualitiy is by > far not brilliant but... hmm... gmpff... just good enough (there are only > few words to be separated distinguished). > As far as I have heard samples I do not think well of text-to-speech. > Which of these techniques is useable as a standard service for Andriot > apps? Is it easy to program? Does it also work on smaller/simpler/cheaper > Android devices? Which API would I have to look for? > - Speed: My variometer sensor is quite fast and rather accurate - I'm > proud of it. > I do not want to loose one of its main advantages, its speed, because > of lengthy or slow data paths out of the RC-transmitter into the android > device and slow data analysis and rendering. > Do you think, it is possible to let the climb tone reflect changes in > the data within 0.05..0.1 seconds? (Of course I cannot influence the speed > of data collection and transmission over the air, but with my RC-brand it > is ok). > > *Which Android device?* > Currently I have an HTC Wildfire S A510e with Android 2.3.5 which was > "lower midrange" 4 years ago (:-D), I would like to use it. > I even think about a very cheap, small extra phone to be used solely as > render engine. Are all current APIs available on all phones (given the > proper Android version)? How can I find out this? > Are such devices suitable for such usage and also for developping > (debugging) such an app? Or do I need "more", e.g. a greater (more > expensive) phone? > > *Moreover...* > Unfortunately the IOIO module is useless when the Android device is > plugged off - this can happen when I fly a motor driven aeromodel and do > not need (most of) the rendering. > Does IOIO draw much current when there is no Android device, but 2 servos > and the UART to the RC-radio are connected? Can I just use the > RC-transmitter without Android device without bothering about the IOIO? > > Changing IOIO's firmwhare to detect that no Andriod device is present and > to do a tiny part of the haptic rendering would need to become familiar > with the PIC, the PIC-IDE and all that and find the APIs in the firmware... > I think I shall not dare to try this the next few years. > > Also the following "intelligence" inside the IOIO module could be of > interest: Reformat the brand specific telemetry data stream into a standard > data format and route data in this format to the Android device. But this > is future music. > > *Last, very simple question:* > I think I can cut off the part of the module with and between the 2 holes > on the opposite side of the connectors? This would help me to place the > module inside the RC-tranmitter case. I must ask this as I do not know the > layout of the PCB in detail, perhaps I would cut some connections. > Is it possible to get a module without soldered connectos (USB and power)? > > If somebody has additional advices which I could help me to find a > decision, please post them too. > > Thank you very much in advnace! > Sincerely, yours > *Helmut* > > -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
