On Dec 8, 2016, at 8:40 AM, jimlux <jim...@earthlink.net> wrote:
On 12/8/16 6:18 AM, John Ackermann N8UR wrote:
Hi Luciano --
The expanded-channels scenario would use one TICC/Arduino pair for each
set of channels. It would require much redesign to stack multiple TICCs
on a single Arduino, and I don't think one board would have the power to
handle it.
What I envisioned would be a set of TICC/Arduinos each putting their
data on USB, and then something like a RPi receiving the multiple USB
data streams and serving as a control unit that might multiplex the data
onto a single ethernet stream, or do processing/storage itself.
At this point, the TICC board includes the connections to allow multiple
boards to be synchronized but we haven't implemented the full system yet
-- in part because until now there are only 4 working TICCs in the
world, and they are in 3 locations!
This is the strategy I would use. I've been using a lot of Teensy boards (a
small Arduino clone from http://www.pjrc.com) for data acquisition, radar
controls, and the like. (see, e.g. FINDER
http://blogs.mathworks.com/headlines/2016/04/25/how-nasas-microwave-radar-designed-for-space-saved-lives-after-earthquake/)
I went through a variety of approaches - a multichannel data acquisition system
from NI, etc. - this worked out the best - each little processor deals with ONE
thing and one thing only, and streams the data out the serial port (emulated by
USB) to a host processor which collects the data, aligns it, does all the post
processing, etc.
For synchronization among multiple units, there's an input pin on each
processor that I use as the sync input, driven either from a 1pps or from
another of the processors (e.g. with a configuration where I've' got 1
transmitter and 4 receivers, the transmitter sends the sync pulse, and the
receivers all use that to sync their side)
We have been working on using something other than USB to collect the data:
probably a shared RS485 type multidrop interface. Our cumulative data rate
isn't huge and most readily available host processors (PC, RPi, BBB, etc.)
don't have lots of independent interfaces - they tend to have one or two or
three of something.
The other approach we're looking at is making our own "data aggregator" with another
teensy - if that's all it has to do, then even using a "soft UART" off a programmable IO
pin is probably good enough to merge a dozen 10kbps streams into one.
BTW-
USB has all sorts of weird idiosyncracies as you propagate down through the
succession of 4 port hubs, particularly with respect to power management (hubs
can turn downstream ports on and off, but have to be able to be woken up), and
most operating systems don't deal well with it.
Among Linux, Windows, and OS X, they all run into trouble with the OS's model of the
power state of all the downstream hubs not matching the actual state.. it's a *hard*
problem, and in a consumer environment, you tell them to just "unplug and
replug" - that triggers a wakeup and re-enumeration of the tree.
I will add that almost all modern OS versions handle the USB serial number thing so that
devices retain their same identity, no matter where they happen to be in the USB tree,
and what's going on with enumeration. No more do you deal with the the "COM port
number changing capriciously", assuming your serial port supplier is following the
rules.
(Of course, we DO have code that goes out and tries all possible com ports and
probes them for our device, just in case)
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.