[time-nuts] Form factor

[Bruce Griffiths]

Chris Albertson wrote:
> I wrote some more ideas, I'm trying here to write what might later,
> after some edits become a "consensous document". that captures what
> most people want.   Edit away, maybe some of this will make it to the
> web site...
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++
> Here is an idea for the top of the web page:
>
> How is the Open Counter project "open".
> 1) The basic design of the counter is open to the addition of new
> modules and new technology.  New modules can be pllugged in or replac
> older modules.  The interface between modules is published, anyone is
> open to design or build a module
>
> 2) The design of each module is open for all to see.  Anyone can
> provide kits or parts or make PCBs.  (There may be some restrictions
> on commercial sales.)
>
> 3) The designs are publishing using open file formats that are industry standads
>
> 4) the design tools, compilers, schematic captures, word processors,
> used to read and modify the design files are available to all wit at
> the most a very modest fee or preferable are Open Source tools
>
> 5) the hardware is designed such that it can be physiclly built by
> anyone with "amateur level" skills. the parts can be build by an open
> group
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Form Factor: One more idea.  I think there is a way to have "all of the above"
>
> Let's say we agree to make all PCBs the same size as a 160-3U Eurocard
> but with four holes in the corners too.  A real Eurocard system is
> expensive but I'm just saying to use the same size rectangle but no
> back plane.   If you do this they will (mechanically, not
> electrically) fit in a Euro card cage they will also fit in those
> Hammond boxes and with four holes people can stack them on threaded
> rods with spacers or mount them in  1U  chassis on standoffs.  They
> could also by mounted with standoffs to a "disk sled" and then go into
> a computer or file server chassis.
>
> The spec is easy to write and understand too:
> "Cards shall be 100mm x 160mm, less than 2mm thick and have 5mm holes
> in each corner spaced 5mm from each edge."
>
> These cards would fit perfectly into a Hammond 1455P2201 box or as I
> said above mounted just about any way that has so far been suggested.
>
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> The next thing to work on is the rear facing edge of the card.  We
> really need to minimize the number of different connectors and signal
> levels.  The smaller the set the better.  I'll take a stabe at it
> below and
>
> This is for the REAR edge:
> 1) power:  four pins on 0.1 inch centers for +12, -12, +5 and ground
>
> 2) frequency reference can be 1Hz, 10MHz or ?? as required but will
> use SMA connector
>
> 3) Data, for command and setup and digital output wiil use a shared
> 100Kbps i2c bus (also called "two wire") Each card is to have two
> connectors so the multiple cards can be diasy chained.  cards shall
> NOT allow there internal components to be visible on this external i2c
> bus.
>    
Using the i2c bus isn't a good idea for anything other than very simple 
applications such as interfacing to serial EEPROMS.
Compatibility issues and other hidden problems (such as when attempting 
to use multiple masters) soon become apparent.
SPI is far less problematic and allows economic use of interesting chips 
like the ACAM TDC-GP2.

> 4) Many cards such as a trigger or pre-scaeler will produce output
> signals that need to to sent point to point to the rear edge of other
> cards I'll suggest SMA for this
>
> (I hope this covers everything.  unless we might need digitized
> signals and these can be very high bandwidth)
>
> The FRONT edage of each card is reserved entirely for signals that the
> user would directly interact with, such as input jacks or status/power
> LED or a data connectors for a computer or network
>
>
> The next level of interface design is the format of the data to go
> over the I2C bus.  Some ideas.
>
> 1) Each card type (trigger, counter,  Interface,...) will have it's
> own unique number.  Each physial card will have it's own "instance
> number"  So if two cards of the same type are in the system each is
> numbered 0, 1, 2,..  Cards in an Open Counter are identified by
> combining the two numbers.  There are many options but all allow for
> over 100 cards in one system.
>
> 2) As a minimum each card must implement one command, that would be
> "Identify yourself".  The card must respond with at least a one bit
> status saying  "present".   By this mmeans any card can find out what
> other cards are present.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> At some point we need to say what is and what is not an "Open Counter"....
> Open Counter System requirements.
>
> 1) An Open Counter system will always require a minimum of two cards
> with one being an "Interface card" and the other some kind of signal
> handing card.  An Interface card connects the data in the 12c system
> bus to a computer, network or to a human operator via a display or
> status LEDs.
>
> 2) Notwithstanding the above, single cards must be usable devices when
> used by themselves.  cards may poll the (disconnected) i2c bus to find
> that they are isolated and then must default to standalone mode.
>
> 3) Cards must allow that multiple instance of their own type may be
> connected on the same system i2c bus, that is, all output data shall
> include the card's instance number. (This allows for a multi channel
> Open Counter)  This requirement applies to Interface Cards too.    A
> large Open Counter system might have multiple input channels and also
> a set of interface cards connecting it to a network and a computer via
> USB and a front panel with a large LCD screen.
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> The above, if accepted has a design implication.  Cards can not track
> the state of the system by simply remembering the set of commands they
> have transmitted.  That is because other cards may have transmitted
> commands.   To make an analogy you should never assume Joe is at home
> because to told Joe to go home.  You must ask Joe his location
> whenever you need to know it.
>
> There are likely 1,000 other implications from the above proposals and
> these need to be worked out.  But in most projects you only find them
> during the first cycle of detail design
> I
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>    
Bruce