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]<javascript:> > > 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] <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.
