Hello Ytai,
thank you very much at first.
Please understand: I'm new to android as a developer and I'm allone.
Digging the Android documentation is more confusing than helping the first
few weeks (at least for an old man:-). Too many questions remain unanswered
and many tiny bits of information are scattered over MANY help-sites.
1 or 2 ms latency is a very important information YOU could give. Perhaps
another experienced IOIO developer worked on a similar project and knows
how to solve it, I hope.
1. In the model glider there is an RC-receiver which, additionally to
controlling the servos, gathers data from sensor devices. It's part of the
RC-link protocol how to send these data back to ground (my equipment uses
the proprietary "MLink" protocol, other brands of course use other
proprietary protocls).
Data come out of the radio module in the RC-transmitter as a sequence of
blocks: <10 bytes, separated by pauses, proprietary format (other brands...
;), 115.2 kBaud 8N2 without any flow control, only to be listened to, NEVER
send anything on this line.
2. Oh, I did that and, as usual for (Andriod-) beginners, information is
overwhelming...
Currently I am studying the Android issue-threads as NONE of the audio
APIs is free of severe bugs. Moreover the documentation is by far not 100%
clear or complete.
What I'm looking for are hints from practical experience to allow me not
to try out all the sound-APIs (MediaPlayer, AutioTrack, Soundpool,
JetPlayer, OpenSL, any else?) just to learn that it doesn't work:
AudioTrack seems to be buggy when a sound is to be repeated (as
necessary for my project),
SoundPool is said to be broken since Android 4.3, what's wrong with
JetPlayer?
MediaPlayer is too slow and inadequate and
OpenSL is native code and complex.
Latency is an open question - "low latency" is not a strict wording...
3. ADB/OpenAccessory: I shall learn that when I seriously start the
project, thank you.
The non IOOIO related stuff: See above, perhaps another IOIO developper
knows more from experience. Latency seems to be a severe problem.
4. Sorry, a typical German-to-English trap, I thought I know the
important ones: German Akkumulator (short "Akku") -> Englisch (secondary!)
battery, not accumulator. English battery -> Gernman (Primary) Battery
("Batterie") - now I have learned this. This is quite close to the old joke
"Next X-mas I become a bicycle." German bekommen -> Enlish get, not become.
:-D
A very important advantage of IOIO would be to allow to prevent the
Adroid device's ...battery from depletion. My transmitter used the
35MHz-RC-Band (USA: 72MHz-Band) and was upgraded to use the WiFi-Band; this
band needs less power and therefore the ...battery (:-D) of the transmitter
is a bit oversized and can deliver additional energy for the Android device
and the servos.
5. Fine. What is the state of IOIO after power up regarding PWM outputs
(servo control)? Input / High-Impedance? That would be ok or a resistor
would suffice.
6. The question was if the end of the board: |O¯¯¯¯O| (the opposite end
of the one where the connectors are) is "not significant" and can be cut
off. There is not much space available in the transmitter and shortening
the board would help. Ok, I'l digg all I can get and search for the PCB
layout.
Additionally the USB connector on the board definitely cannot be used, I
shall have to use short wires and position another connector in the
transmitter's housing. I soldering skills are ... a bit limited and I'm not
sure not to damage the IOIO when I replace the connector by wires.
Therefore I asked if it is possible to by one without the connectors - but
I can try to solder i.
Again, thank you for your effort and for your patience with my English in
the future :-)
Kind regards, Helmut
Am Montag, 13. Oktober 2014 18:00:11 UTC+2 schrieb Ytai:
>
> 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]
> <javascript:>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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.
