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)

John,
Ok I know the development job is very hard with a lot of rework and time spending.
I will try your basic unit but I hope you will develop a "multiboard" scenario with a single USB to send the real time data to Timelab.
Thank you again to you and the group for what you are doing for us.
Luciano
www.timeok.it

On 12/8/16 7:39 AM, timeok wrote: > > John, > Ok I know the development job is very hard with a lot of rework and time spending. > I will try your basic unit but I hope you will develop a "multiboard" scenario with a single USB to send the real time data to Timelab. > Thank you again to you and the group for what you are doing for us. > Luciano > www.timeok.it > > given how cheap Arduinos are, you're not saving much by stacking multiple $100 boards on a single $15 Arduino. I would say a "multi USB" would be better long term approach, assuming one can "synchronize" multiple boards with some sort of simple interconnect.

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 > On Dec 8, 2016, at 8:40 AM, jimlux <jimlux@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. > 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/>

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

Thanks John. I just placed an order. All the best Mark S VE7AFZ Sent from my iPhone > On Dec 7, 2016, at 11:45 AM, John Ackermann N8UR <jra@febo.com> wrote: > > I'm happy to report that TAPR is now accepting orders for the TICC timestamping / time interval counter. We've placed an order with the contract manufacturer and expect to have finished product ready to ship sometime in February. The TICC system will include the TICC shield mounted on an Arduino Mega 2560 compatible processor, with TICC software loaded. Each system will be tested for function before shipping. > > As I mentioned in my original email, TAPR is going a bit out on a limb to produce the TICC, and we have to make a significant up-front payment to our contract manufacturer. So, early orders are very much appreciated to help recover our cash flow. > > The regular price will be $190 each for the TICC shield with Arduino compatible processor,* but to encourage early orders, we're offering a $10 discount for orders placed on or before December 21 -- that makes the price $180 plus shipping. > > You can order from: http://tapr.org/kits_ticc.html > > Thanks! > John > > * We will provide a Sainsmart version of the Arduino Mega 2560 R3. They seem to be a reliable supplier and we used these boards for TICC development. > > > -------- Forwarded Message -------- > Subject: [time-nuts] New Timestamping / Time Interval Counter: the TICC > Date: Wed, 23 Nov 2016 10:48:57 -0500 > From: John Ackermann N8UR <jra@febo.com> > > Counters with resolution below 1 nanosecond are difficult. > They require either outrageous clock speeds, or interpolators > that are typically a bunch of analog components mixed with black > magic and stirred by frequent calibration. The very best single-shot > resolution that's been commercially available is 20 picoseconds in > the Keysight 53230A and HP 5370A/B. My 5370B has an one-second > noise ADEV of about 4x10e-11. > > With the help of some very talented friends, I've been working on a new > counter called the "TICC" with <60ps resolution and similar jitter, > based on the Texas Instruments TDC7200 time-to-data-converter chip. The > one-second noise ADEV is about 7x10e-11, not much worse than the 5370, > but here's the trick: the TICC is an Arduino shield (mounting on a > Mega 2560 controller) that weighs only a couple of ounces, requires > *no* calibration, and is powered from a USB cable! > > The TICC is implemented as a two-channel timestamping counter. That > means it can measure one or two low-frequency (e.g., pulse-per-second) > inputs against an external 10 MHz reference, or it can do a traditional > time interval measurement of one input against the other. It can also > measure period, ratio, or any other function of two-channel timestamp > data. (And by the way -- multiple TICCs can be connected to yield 4, > 6, 8, or more synchronized channels, though we haven't tested this > capability yet.) > > I've attached a picture of the TICC prototype as well as an ADEV plot > of a 17+ day run of multiple measurements taken by two TICCs, and also > showing the TICC noise floor. The good news behind that plot is that > there are more than 6 million data points behind these results, and > there was not a single glitch or significant outlier among them. > > There's more information available at http://febo.com/pages/TICC > > The software is open source (BSD license) and is available at > https://github.com/TAPR/TICC -- the current version seems be reliable > but there are still features to add and a *lot* of cleanup to do; it's > currently ugly and very much a work in process. > > As always, I'll be making the TICC available through TAPR. We're still > finalizing details, but we expect the price to be less than $200 for a > turn-key system: TICC mounted on an Arduino with software loaded and > tested for basic functionality. We hope to ship the TICC by February. > > I'll post a note in a week or two with final price and ordering > information. As a heads up, we will probably offer a small discoun > for pre-orders. TAPR is a shoestring non-profit group and the up-front > cost to manufacture this unit will frankly be a challenge for us. > Getting pre-orders will help our cash flow significantly, so we ask you > to keep that in mind. > > John > > > > > <TICC_rev_c_photo_small.jpg> > <ticc_rev_c-perf_test_adev.png> > <Attached Message Part> > _______________________________________________ > 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.