In message 45DFB8F9-3595-4A5D-8DCC-FD731798845E@jks.com, John Seamons writes:

As one of the Beta-testers I can highly recommend this, it really gives
your HP5370 a kick into the next millenium.

The potential for future improvements is also virtually unlimited:

How about hooking up an LCD display and calculate and show allan
variance in real time ?

Thanks a LOT John!

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi,
I browsed the page and the GitHub repository for a while, and read the
readme and read-more documents, but I still don't know what it
actually adds.

Perhaps it would be a good idea to document this?

Cheers,
D.

On Mon, Feb 24, 2014 at 9:38 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:

Hi

Very cool. Glad I kept that stack of 5370’s….

Bob

On Feb 23, 2014, at 10:56 PM, John Seamons jks@jks.com wrote:

Yes indeed I received my board quite quickly. And now it sits in its
rapping.
Curses that evil work stuff.
Physically it  looks excellent
Regards
Paul.
WB8TSL

On Mon, Feb 24, 2014 at 7:35 AM, Bob Camp lists@rtty.us wrote:

An very impressive achievement. I particularly like the elegant use of the
PRU to overcome the non-real time nature of the Angstrom distribution.

Congratulations John!

Didier KO4BB

On Sun, Feb 23, 2014 at 9:56 PM, John Seamons jks@jks.com wrote:

As an early adopter/beta tester, I highly recommend this board!

As yet, the board is only giving a glimpse of its potential, and
yet it is completely replacing the original 6800 processor board.

I am using a 5370A, with emulated 5370B firmware, and my A appears
to now function as B in all important respects.  It runs quite a
bit faster than it originally did... and the Beagle Bone Black that
has taken over the 6800's duties, isn't even breaking a sweat.

At this point in time, the BBB single board computer is doing a
software emulation of the original 6800 microprocessor, and is
running a copy of the original firmware of either a 5370A, or B,
model counter.  The BBB is configured to step between the emulated
code and the 5370's front panel, so you can add functions to the
front panel at will.  Currently, the front panel allows you to
set things like RESET, halt, IP addresses, masks, etc...

In the future, I can foresee replacing the 6800 firmware with
custom C language routines and making the 5370 really sing!

Your limit is pretty much your imagination.

Oh, did I mention?  It is on the ethernet with a full linux IP
stack and firewall!  Plug it into your router, and you can load,
read, fiddle, and do just about anything far away from the actual
5370.  I routinely send upgrades to my 5370 from clear across the
building!

-Chuck Harris (a very satisfied customer)

John Seamons wrote:

Just a side note on running ethernet in your 'lab'.

If your doing any low noise work you may want to pay a bit extra and get
the shielded cables and make sure the RJ45 like sockets are of the shielded
type.

Example

http://www.pchcables.com/cashstpnecaw.html (just a local supplier nothing
else)

-pete

On Mon, Feb 24, 2014 at 6:28 AM, Chuck Harris cfharris@erols.com wrote:

On 02/24/2014 08:04 AM, Pete Lancashire wrote:

Amen to that.  And don't use any old coax for distributing 10 MHz
if you wish to hear WWV.  Use some multiple shielded coax with
high quality connectors.

--
Chuck Forsberg WA7KGX  caf@omen.com  www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc      "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231  503-614-0430

What has me also interested is I have a 5370A with its front panel pretty
much destroyed.

BB has recently released a 7" touch screen LCD w/daughter board for $119.

I see a project for next winter on the horizon.

-pete

On Sun, Feb 23, 2014 at 7:56 PM, John Seamons jks@jks.com wrote:

Goto one of the places selling the BB Black and look up  BB View.

Not pushing this disty just one that has a decent image

http://www.element14.com/community/docs/DOC-55844/l/element14-bb-view-lcd-cape-for-beaglebone-family-boards

On Mon, Feb 24, 2014 at 1:50 AM, cheater00 . cheater00@gmail.com wrote:

D
I can give you some insights here. Others will be more effective. We all
agree that the 5370 frequency counters are great devices from 1980. Right
there is the first issue. The old micros are getting old and failing. I
have lost both 6800s and eproms.
Thank heavens stuff is still available.
But this board replaces those items completely. Welcome to 2014. Now we
just have to worry about big fat capacitors.

In addition it gives you remote control other then GPIB. We all love GPIB,
but us lazy types like Ethernet better. Cables are easier to manage.

Finally the crazy thing is it gives you web services. Wow for a 1980s box.
All while leaving the front panel operation intact for simple quick
applications.

The only thing that can be annoying is there is a shut down procedure for
the unit now. It used to be power off.

All of the above for $90.
Hope that helps you.
Regards
Paul
WB8TSL

On Mon, Feb 24, 2014 at 12:16 PM, Pete Lancashire
pete@petelancashire.comwrote:

Thanks for the info.

It could still be power off... just add a large capacitor as voltage backup
and make the unit sense when power is off. It should be able to shut down
quickly enough. That's how it works most of the time. Alternatively add
some 1.5v batteries and a charger. That should never run out.

Running a PC without backup power is asking for trouble. A few 1.5v
batteries and a charger and buck-boost cost only 10 bucks.

D.
On 24 Feb 2014 18:57, "paul swed" paulswedb@gmail.com wrote:

In message CAD2JfAhdZGNFWnZKYO7SFJ4pQVNusSy8ns9u3SdJyF+vYmtUbg@mail.gmail.com
, paul swed writes:

That should be fixable, given enough Linux-clue.

(I could trivially do it on FreeBSD, but don't know the incantations for Linux)

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Going to leave the battery comment alone. Most people with HP and other
gear of age have experienced the dreaded leaking batteries from really
poorly designed charging circuits. Even HP did the resistor diode thing.
Regards
Paul.

On Mon, Feb 24, 2014 at 1:24 PM, cheater00 . cheater00@gmail.com wrote:

Thats exciting to hear
Thanks

On Mon, Feb 24, 2014 at 6:59 PM, John Seamons jks@jks.com wrote:

On Feb 25, 2014, at 12:59 PM, John Seamons jks@jks.com wrote:

From the latest documentation:

"One solution to the annoyance of having to halt the BBB before the instrument is
powered off is simply to keep the BBB running by providing it a secondary source
of power via the USB-mini port. The BBB already understands how to select
between two sources of power: the USB-mini and +5V barrel connectors (the latter
of which is actually being delivered from the 5370 via the board expansion
connectors). The app detects when the instrument has powered down and resumes
running when power is restored. USB power could come from an external USB hub or
charger. You may have to obtain a longer USB cable than the one supplied. Be
certain to only use the USB-mini connector that is adjacent to the Ethernet RJ45
connector. Do not use the USB-A connector on the other end of the board as that
port will not accept input power.

Some of you might even figure out how to derive +5V for the USB-mini cable from
the 5370 oven power supply card that is always powered if the instrument is off
but the line cord is plugged in. But beware of the potential problem of
conducting noise from the BBB to the reference oscillator over such a
connection. Some experimentation and measurement is necessary. The planned
USB/Ethernet connector card that replaces the current HPIB one at the back-panel
could host a voltage regulator. Aligator clip connections to the '+25V UNREG'
and GND test points on the oven power supply would alleviate the need for any
soldering."

That fix presumes that the power line never quits at
inappropriate times.  This winter has provided me with
ample reminders that power can go out anytime.

I think a better solution would be to find a very large
"super cap" and power the BBB from that while giving it
a power fail interrupt to quickly sync the file system.

-Chuck Harris

John Seamons wrote:

If having a battery in the device makes some of you queasy, you could
always put it outside, on the back. But I seriously believe there are ways
to make battery backup which will not leak.

D.
On 27 Feb 2014 06:52, "Chuck Harris" cfharris@erols.com wrote:

In message CA+9GZUhJLqQ7K-cNXsSzPMgSOH6Oyd774SM_e0=ykLJgYD4cxA@mail.gmail.com
, "cheater00 ." writes:

Seriously:  Keeping the computer alive and eating power is
silly.  We just need to find out how to get the Linux configured
correctly.

(Or port it all to FreeBSD, which I'm considering, because there
I know how to do it :-)

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Do you have experience with FreeBSD on ARM processors?

The simple solution, which may not be possible, is to
make all software on the flash disk RO, and put any part
of the file system that needs to be written onto a RAM
disk... probably should be the /var directory.

The only time the flash disk must be written is when some
configuration parameter must be changed, or the linux/program
image must be changed.

The routines that make those changes could be fashioned
so that they flush the caches immediately after they are finished.

From observation, the BBB keeps operating for several seconds
after power is removed.  If a power failure interrupt is
created that will notify linux instantly on power failure, it
would be possible to forbid configuration changes that take
longer than a couple of seconds.

-Chuck Harris

Poul-Henning Kamp wrote:

On Thu, Feb 27, 2014 at 12:03 PM, Poul-Henning Kamp phk@phk.freebsd.dkwrote:

This is a solved problem.  I don't understand why this discussion is
dragging on.
E.g liveCD, ramdisk, Linux routers, thin (diskless) clients.
The relevant variables are the distribution and if you want to use a
network disk.

I will say the underlying concerns are valid.  I have two Raspberry Pis and
three Beable Bone Blacks.  I've had four SD cards fail among the group and
they're not even on most of the time.  CompactFlash is much better.

At 11:03 AM 2/27/2014, Poul-Henning Kamp wrote:

Exactly. We use the PC-Engines ALIX x86 single board computer stuff
at work, and even I didn't have too much trouble getting a pretty
much stock Debian installation 'adjusted' to run with the CF card
mounted as read-only. I've yet to see a problem with power cycles.
(But I've only done the power cycle bench test a few hundred loops.)

--
newell  N5TNL

There is a spin of FreeBSD called NanoBSD, little light on the
documentation but the name pretty much says what it is about.

Either way it looks like the BBB is opening up quite a few minds. Finally a
good combination of power, i/o etc. and not to mention
the two PRU's .. just read up on them last night, very interesting.

-pete

On Thu, Feb 27, 2014 at 9:21 AM, Chuck Harris cfharris@erols.com wrote:

On Thu, Feb 27, 2014 at 6:03 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:

Oh, of course it's not about keeping the computer on at all times,
it's about having a contingency for the 0.1% case when your computer
does not shut down in the assumed time. Unless you develop your system
and everything running in it as hard real time, you cannot escape the
fact that sometimes the thing will take longer than expected to shut
down. And at some point that will cause data loss. A suitable battery
costs $5. Is your time worth so much less than $5 that you actually
consider the task of building your own Linux distribution for this
case, or even just finding one that will work relatively problem-free?

D.

On 27 Feb 2014 16:55, "cheater00 ." cheater00@gmail.com wrote:

Two batteries, each with a diode and bought to a common point seems logical
to me. It only needs one present so either one can be changed with no loss
of power. Guarding against battery faulty batteries that leak prematurely
probably needs a physical barrier, but I can't believe it is rocket science

Backup batteries don't make me queasy.  The easiest,
cheapest backup battery would be a small 6V 3AH sealed
lead acid battery.  It is trivial to make a good float
charger using a 3 terminal regulator and a diode, and
they do not leak, vent, or anything problematic.  The
little 6V 3AH packs are used in emergency lighting, so
they are readily available.  Float them at 6.9V, and
they will last at least 5 years.

I suggested a super cap because they are cheap, and tend
to last a very long time without leaking.  100F will
keep a BBB up for quite a while if it isn't driving the
network, or usb devices.

Regardless of the power safe mechanism, it would be
best that the BBB get an interrupt at the moment power is
deemed bad, and starts an orderly shutdown.  To guard
against power bouncing, it should be prevented from
restarting until several seconds after shutdown is
completed... some sort of timer should be part of
the power safe mechanism.

-Chuck Harris

cheater00 . wrote:

On Thu, Feb 27, 2014 at 6:22 PM, Scott Newell newell+timenuts@n5tnl.com wrote:

My assumption is that, unlike an embedded computer which is
plug-and-forget, this thing will get modified, developed on, played
around with, etc, all of which includes userland software (= possibly
long shutdown times) and disk access (= possibly long shutdown times).
It's trivial to run a read-only system but that's limiting and takes
out the fun of tinkering with the BBB to make your own applications
and other stuff.

You might say that we could run the stock system RO and add any
user-supplied stuff to RW media and just say that it isn't going to
survive a power-down. But that's not really a comfortable situation.

D.

On 27 February 2014 17:31, Chuck Harris cfharris@erols.com wrote:

I thought there was an issue with even "sealed" lead acids of them
emitting small amounts of sulfuric acid, which is not great in a bit
of test equipment.

Dave

Hi Brian,
it's less about caching pending writes to file handles that are
waiting inside the system. That's most likely to work well within a
short period of time.

The issue is if you're using the system to its full extent. Among
others you'd like to write applications for the BBB that enhance the
5370's capabilities. You don't want to bother with hard real time,
compilation, memory layout, etc, all of them problems each of which
will make your development time 10x longer and your fun time 20x
shorter. So instead you use something like Python or Java. Then, you
also don't really bother to ensure that your program can be
interrupted at any time, since that's another level of complexity.
Coroutines? Continuation passing style? Reactive programming? Why
bother? Then you make a few other decisions that make your program
easier to make and more difficult to shut down immediately in a clean
manner.

So let's say it's running and it is collecting data which is crucial
to you. Maybe you again didn't bother to make sure that if the program
crashes it will not corrupt its data.

So now your BBB gets the power loss interrupt, sends kill -15 to all
processes and most of them exit. Your program doesn't so likely Linux
tries to send signals 2, then 1, then 9 at which point your program
will certainly crash (sig 9 means "crash now"). So your program will
likely eat all the data.

Note that all of the shortcuts I mentioned above are fairly reasonable
defaults that save days of work per project for no improvement in
reliability, since, after all, a suitable battery only costs $5.

Cheers,
D.

On Thu, Feb 27, 2014 at 7:47 PM, Brian Lloyd brian@lloyd.com wrote:

In message 530F740A.7030906@erols.com, Chuck Harris writes:

A little bit, I just started playing with it again recently.

That's exactly what NanoBSD does, with a few more wrinkles
to boot:

https://www.freebsd.org/doc/en/articles/nanobsd/

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message CA+9GZUjtzoN9+uxg1r1BrxX8zYV4wnjq22QpsBitYako20wHjg@mail.gmail.com
, "cheater00 ." writes:

You're missing the point:  If all the "permanent" filesystems are
mounted read-only, and only ram-disks are mounted read-write, you
don't even need to shut down, you can just yank the power.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

There you have the problem in the above sentence from Poul-Henning. It
needs to be yank the power proof. Because that is the way the 5370 shuts
down.

That said the board and software thats been created by one person is simply
amazing and well done.

We are discussing a fine adjustment. Batteries are an incredible mess. I
suspect we need a fast detect interrupt from the incoming power supply. My
experience with other Linuxes is that they waste way to much time flushing
stuff. So the comment about making the file system RO after you have added
the IP makes great sense.
The ability to upload and then re-download also is good I can do that on my
routers and believe actually this board can easily do the same.

Its just at the end of the day when I am tired I will hit the off switch.
Ooops lucky me I get to reload everything.
Regards
Paul
WB8TSL

On Thu, Feb 27, 2014 at 2:21 PM, Poul-Henning Kamp phk@phk.freebsd.dkwrote:

In message CA+9GZUgrLw05f=Pvh5tJi+VLKfsTWatibcpE1T3xFgWQ2+S4qg@mail.gmail.com
, "cheater00 ." writes:

Lets just say that I seem to use "fairly", "resonable", "save",
"improvement" and "suitable" in a different way than you do.

The easiest way to do the kind of stuff you're talking about, is to
NFS mount a filesystem on the BBB.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

I have worked on lots of equipment that was sealed with
a SLA inside, and I have never seen any sign of corrosion.
Only times I have seen a problem is in the case of UPS's that
were left discharged in unheated warehouses... the electrolyte
froze and the battery cases bulged greatly, but still no leakage.

-Chuck Harris

Dr. David Kirkby wrote:

Totally agree with Chucks comment I have opened many system that have been
in service at least 5 years virtually no evidence of corrosion.
I have however opened system that do not manage the batteries correctly and
they are a mess.
But we really are drifting away from the main thread. Just want to turn the
5370 off at the end of the day and back on the next. No think-um.
Regards
Paul

On Thu, Feb 27, 2014 at 4:26 PM, Chuck Harris cfharris@erols.com wrote:

Yes, indeed. It's time to wrap up the operating system and file system tangents and get back to time & frequency.

Those of you with positive suggestions for improvements of the 5370 processor mod kit can email them to John Seamons directly. He has done an incredible job and the direction this thread has taken is unfortunate.

/tvb