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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
