I do the same with Tek 500/500series instrumentation plugins. You can get
the TM504 mainframe for < $50 on ebay and scrap grade modules for < $10.
Plus you get a linear power supply, backplane and already RF rated
enclosure.

On Tue, Dec 21, 2010 at 11:12 AM, EWKehren@aol.com wrote:

You can't plan a project like this around eBay junk.  How would you assemble
100 kits if each kit requires that you find a specific HP instrument on eBay?

If cost is a big issue then I'll go back to my first idea.  Make your PCB about
the size os a disk drive.  Then yu get a llength od 1 x 1/4 inch aluminum L
and bend it into a three sided "U" and attach it to three sides of the PCB.

The finished assembly should fit into any enclusre designed to hold SATA
disk drives.  A PC case could work but there are nicer looking boxes, rack
mount and diesktop

This trades a bit of metal working for the cost of a Hammond box.  But
the metal work requires only a hack say and drill.

On Tue, Dec 21, 2010 at 8:35 AM, Bob Bownes bownes@gmail.com wrote:

--

Chris Albertson
Redondo Beach, California

I agree about the ebay finds. Bad to design the boards form factor around
old chassis.
Maybe the thing is to find out from the electronic design how big the
board(s) will have to be or what the electronic footprint is, then go from
there? If the boards are designed so that idiosyncratic mounting is
possible, we can all mount them according to our own taste?

Don

Chris Albertson

--
"Neither the voice of authority nor the weight of reason and argument are
as significant as experiment, for thence comes quiet to the mind."
R. Bacon
"If you don't know what it is, don't poke it."
Ghost in the Shell

Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com

Another factor to consider is that ps stability requires using coax
connectors that are mechanically stable to within a few microns ie no BNCs.

Bruce

Don Latham wrote:

That would all depend upon the interconnect strategy, which hasn't reached consensus either.

Based on the early module list, a bus probably isn't necessary, and individual ribbon cable and/or coax will do if speeds stay low.

On Dec 21, 2010, at 2:34 PM, Bruce Griffiths bruce.griffiths@xtra.co.nz 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.

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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Tue, Dec 21, 2010 at 11:05 AM, Don Latham djl@montana.com wrote:

--

Chris Albertson
Redondo Beach, California

Chris Albertson wrote:

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.

Bruce

The use of i@c that I proposed was ONLY for module-to-module
communication.  I wrote that none of the internal chips in a module
were to be exposed to the i2c bus.  A module may very well have it's
own internal bus but that design detai needs to be hidden from the
rest of the system.

In an open system built with modules yu realy, have to be careful to
never expose the inner working on a module.  Else other modules come
to depend on the internal design of other modules and then you can
never upgrade of replace any of them because you have a circular
dependency loop or likely even multiple loops.  So we have to be
carfull to never expose the kind of chip or it's internal bus address
between modules.

So in the proposel I wrote i2c is used ONLY between the external
interfaces of modules.  A module would be free to use a SPI internally
and TDC-GP2 chip if it wants.

I just read up on  SPI.  There are a few problems with it for this application

1. No in-band addressing.  You need to run select lines. This means
   you have to know in advance what "slave" devices you will be
   connecting.  This Open Counter is going to be "open" in that we will
   be plugging devices in and out and do not know the final list of
   devices in advance.

2. A bigger problem is that SPI is not "multi-master".  An open system
   is much easier to construct if no module is "special" and all are
   equal on the bus.  An example is  the desktop PC is the "master".
   That works until you want to control it via a front panel switch or
   remotely over the network.  OK you can build both slave and master
   interfaces to each module and have some command to switch modes but
   then complexity is far to high

I don't care is I2C is used or not but I thing the bus needs several attributes

1. Reasonable speed, say about 100K bps
2. No "master", all nodes are peers
3. The number of wires remains constant is the number of nodes on the
   bus varies.  In other words in-band addressing, no select lines.

On Wed, Dec 22, 2010 at 10:37 AM, Bruce Griffiths
bruce.griffiths@xtra.co.nz wrote:

--

Chris Albertson
Redondo Beach, California