[time-nuts] Form Factor and such, Big Picture

[Bob Bownes]

Comments inline. Hopefully I've edited this enough to prevent it being
overwhelming.


On Wed, Dec 22, 2010 at 7:40 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> I think I'm missing the big picture.  What sort of things are people
> interested in building?  Will they all be a reasonable fit with a single Form
> Factor, Bus, and whatever?

The overarching goal is to build a time interval counter similar to an
HP 5370 with performance better than a PICTIC II.


> I've been thinking of something like a mother board with FPGA that would fit
> in something like the Hammond boxes.  The idea is that the FPGA is the part
> that's hard for me because I can't handle soldering BGAs.  All the front-end
> analog stuff would go on a daughter card.

I've been thinking similarly. FPGA is one possibility for part of the
core function.  FPGA's are quite available in in BGA footprints,
though most are fine pitch QFP packages.

Everything ends up in one box no larger than a 5370, preferably much
smaller. But module definitions and overall design will dictate the
final box form factor. Form follows function and all that.

> The hardware interface between the mother/daughter cards is just a row (or 3)
> of pins/sockets for 0.1 inch connectors.  (or anything similar)   Software
> interface is TBD.  It might make sense to publish a "standard" interface for
> some application so the same firmware on the motherboard would work for
> various front ends.

Again, my thinking. Main board has 2, possibly 4 input daughtercard
connectors. Internal interconnect pinout is well defined, though, as I
said earlier, some pins may be 'designated for future use' and simply
run to spare pins on a microcontroller or FPGA.

> It might make sense to put an ARM next to the FPGA.  You can get a lot of CPU
> for $10-20.

ARM or other general purpose CPU is interesting, but at what cost for
complexity and/or software development? It would require RAM, IO
support, and boot rom at the very least. Not insurmountable, but at a
cost to complexity.

I have a stack of Domino microcontrollers that I use in similar
project. Great, but expensive. All rolled up with ram. rom, serial
port, and a BASIC interpreter in a module a bit bigger than a 40 pin
DIP. But not really suitable (or commonly available anymore) methinks.

> I'm not sure what the back end sould look like.  I'd be happy with USB or
> Serial.  They are dumb/simple and don't require massive protocol stacks.  I
> could live with Ethernet, but it really raises the bar for getting off the
> ground.   (I'm not interested in running a web server on my toys.  All I want
> is simple command/response.  I'll put the web server on a PC that has access
> to all the archived data.)

My suggestion of TTL serial was based on the thinking that you can
terminate that in four different COTS chipsets that will convert it to
rs232, USB (which appears to the host as a COM port), ethernet (simple
serial<->telnet on a chip solution), or ethernet (single module with
serial inputs and a web server). The builder can select any of the
above, buy the appropriate pcb, populate it, and plug it in.

> It might make sense to have a back-end daughter card.

That was my expectation. It could be as simple as a level shifter or a
standalone controller/web server/whatever else you want to cram in
there. Similar for a front end control panel. V1 might be a few LEDs
and switches. V2 might be an LCD panel, a microconroller and a bunch
of switches. Connector to a front panel i/o module probably ought to
have plenty of pins. :)

We could also put in a big connector on the main board to plug in a
later, bigger, better, more powerful controller. That leads to a
discussion of separating the core counter from the controller.

> With that sort of setup, I think I could build a 5370 class box that I could
> use for long term data collection.  Does that seem reasonable?

See aforementioned goal. Sounds good to me.

> I don't need the full flexibility of the 5370 front end.  I'm willing to use
> jumpers or a soldering iron for things like AC vs DC coupling and 50 ohm
> termination.

Hence the joy of several possible input modules. Personally, I'd like
a module with the flexibility to change the termination and
attenuation via a front panel switch, much like a Tek DC5010 counter.
Those features might or might not be something that the main
controller might want to be aware of or have control over. In a
simplest version, they are all local to the input board. If I want to
do the SW dev, the control and status could be passed back to the
controller via a few pins on the daughter board connector.  So V1 of
the input board is not much more than maybe a buffer and some clamping
diodes. V8 might have a microcontroller in it that autosenses the
input signal and spits out a full description to the main board, where
it is displayed on the VGA monitor connected to the FPGA. (ok, I'll
put down the crack pipe now...)

> On the other hand, how much board space would a spectrum analyzer take?
> Should we be discussing 2 sizes of projects?

Spec An would be out of scope for this project. But is also an
interesting project. Let's finish this one first. :)