I will do as suggested and try the simplest solution - only adding more complexity if it doesn't scale. Thanks again for your assistance!
On Thursday, February 20, 2014 6:44:51 PM UTC+2, Ytai wrote: > > MCU choice is really a matter of taste. I think that even if you go SPI to > a separate MCU you might have to do some IOIO firmware work in order to > meet the high bandwidth requirements that you have. At this point, you're > probably better off just doing the whole thing on the IOIO rather than > adding additional complexity. Doing something 128K times a second on a > 16MHz micro, while still having some spare for other tasks is a challenge, > but might be doable. It is certainly worth a try IMO, since it is still > relatively simple compared to other options. Another not-too-hard > possibility is to look at some of the ADK-type boards. Some of these have > faster micros than the IOIO's (for example Microchip's PIC32 based board or > the Pinguino). The main drawbacks compared to the IOIO: > > - Only works on Android 4.x (requires OpenAccessory support). > - Provides a rather low-level interface, where you'll need to do a lot > of what the IOIO does yourself, in terms of getting data from side to side > using some communication protocol. Might not be terribly hard in your case > as you have very specific requirements. > > > > On Wed, Feb 19, 2014 at 10:10 PM, Colin Webber > <[email protected]<javascript:> > > wrote: > >> Thanks for your response Ytai. >> >> Yes, there are a lot of 16ch muxes but at these levels it remains cost >> effective for the application. I had considered that the long wires might >> be an issue but did not consider the noise created by passing through >> multiple mux levels. However for this particular application I only need >> to detect large and sustained changes in value so small spikes will be >> ignored. >> >> I think your latency question ties in with my original query about >> needing something similar to the Motor Control API but it seems that MC >> only allows synchronization of output signals. My concern was that I would >> address a set of mux channels using digital outputs then read the 16 input >> values, but that the inputs would not yet have transitioned from the >> previous values. Getting the values mixed up would be disastrous so I need >> to be certain that this will work at 2Hz. I could read in the inputs as >> late as possible, i.e. directly before changing the outputs to address the >> next set. There is no need for real-time detection - a delay of a several >> seconds (with transmission to the Internet etc.) is fine, but accurate >> addressing is critical. >> >> Your custom firmware suggestion is something I hadn't considered... >> shift, sample, send would avoid the above problem. Also the SPI and faster >> micro are great ideas. Do you have any suggestions of micros that would >> meet these requirements, preferably one that you have personally hooked up >> to IOIO using SPI? >> >> Much appreciated. >> >> >> On Tuesday, February 18, 2014 6:44:16 PM UTC+2, Ytai wrote: >> >>> That sounds interesting and challenging for various reasons: >>> >>> - If you use, say 16x muxes, you'd need >4000 of them. Lots of $$ >>> and a complicated assembly. >>> - At this fan-out, the depth is going to be at least 4 (i.e. 4 muxes >>> to go through before getting to the ADC) - meaning that it may be a >>> challenge to avoid excessive noise on the signals. Probably the wires >>> are >>> going to be long as well, which is yet more susceptible to noise. >>> - At 2Hz we're talking about 128Ksps, which is a non-trivial data >>> rate to handle with the IOIO and over USB, but might be doable with some >>> effort. Do you have any strict latency requirements? >>> - Having said that, I would either go with custom firmware on the >>> IOIO, which does just that (shift, sample, send over USB) or with a >>> separate (possibly faster) micro. If you want the data to go to Android >>> eventually, you can probably use a SPI link between a IOIO and that >>> micro. >>> >>> >>> >>> On Tue, Feb 18, 2014 at 6:20 AM, Colin Webber <[email protected] >>> > wrote: >>> >>>> I would like to read 65536 analog signals and be able to identify the >>>> source. Note that the analog signals do not change rapidly, i.e. this is >>>> not audio, however reading each signal twice per second would be desirable. >>>> >>>> My plan was to use a stages of analog multiplexers driven by >>>> daisy-chained shift registers, which are in turn driven by three digital >>>> outputs on the IOIO-OTG. The digital outputs will essentially act as a >>>> counter, indexing which 16 analog signals should be routed to the IOIO >>>> inputs. >>>> >>>> Would it be possible and/or advisable to use the new Motor Control API >>>> in order to ensure that the signals are correctly indexed, or is this an >>>> unnecessary complication? >>>> >>>> -- >>>> 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/groups/opt_out. >>>> >>> >>> -- >> 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/groups/opt_out. >> > > -- 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/groups/opt_out.
