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

jimlux jimlux at earthlink.net
Thu Dec 8 20:39:05 EST 2016


On 12/8/16 3:34 PM, Don Latham wrote:
> Hi Jim:  From a hardware multi drop viewpoint, the CAN Bus seems on paper to be simplest…
> 2 120 ohm resistors and a twisted pair…
> Don
>
except no PC has a CAN interface, so debugging is a pain.  One advantage 
of USB is that pretty much every computer in the world has a USB.

Serial over USB is a pretty simple interface - and it's "very" fast in 
these emulated schemes - megabits/second.

There's been more than one occasion where we had just the sensor modules 
and i just plugged them into any PC, loaded and ran our Python code, and 
we were off and running.

So that's why we haven't really jumped to something else  - CAN and 
RS-485 are pretty similar - a shared twisted pair.

And there are USB-CAN pods and USB-RS485 pods that are fairly 
inexpensive (<$100).




>> On Dec 8, 2016, at 8:40 AM, jimlux <jimlux at 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 at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
> Felix qui potuit rerum cognoscere causas.
> Lucky is he who has been able to understand the causes of things.
> Virgil
> -------------------------------
> "Noli sinere nothos te opprimere"
>
> Dr. Don Latham, AJ7LL
> Six Mile Systems LLC, 17850 Six Mile Road
> Huson, MT, 59846
> mailing address:  POBox 404
> Frenchtown MT 59834-0404
>
> VOX 406-626-4304
> CEL 406-241-5093
> Skype: buffler2
> www.lightningforensics.com <http://www.lightningforensics.com/>
> www.sixmilesystems.com <http://www.sixmilesystems.com/>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



More information about the time-nuts mailing list