[time-nuts] TICC Timestamping / Time Interval Counter -- Available to Order

[jimlux]

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)