Inline
> 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. > > That should be easy to achieve using a Uart. Detecting framing is that only thing that is possibly challenging, if it is indeed time-based as you say, and especially if the gaps between the frames are comparable to the jitter in the IOIO:Android latency. > > 1. 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. > > Every software has bugs. I disagree with your above statement. Most Android APIs are pretty intuitive, reasonably documented and reliable. Sometimes there are corner cases. > 1. 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... > > AudioTrack seems to be what you want. You seem to need it running in streaming mode, so not sure what you mean by "sound is to be repeated". You probably want to set a synthesizer thread that keeps pushing audio data out to the player at a proper rate and with some buffering and have this thread get control events from the thread that knows about the flight parameters. Side note: I was one of the main contributors to OpenSL-ES in my previous life :) > > 1. 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. > > Take into account that if the Android is not fully charged, it will typically draw around 2.5W continuously. May or may not be what you're after. > > 1. 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. > > Yes. Pins are floating when there's no connection and pull resistors is the standard solution for assuming default states. > > 1. 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. > > Ah, yes. There's nothing there but the logo and mounting holes. Wear a mask when cutting! The dust coming out of the PCBs is very nasty for the lungs. > > 1. 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. > > The SparkFun boards have test points underneath the USB connector exposing its signals. You can try soldering wires directly there. Signal integrity might be an issue. As a rule of thumb, keep those wires as short as possible and of the same length. 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]> >> 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. > -- 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.
