time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

HP Z3805A com port and monitoring questions

MD
Magnus Danielson
Mon, Oct 22, 2012 9:31 PM

On 10/22/2012 07:13 AM, Tom Van Baak wrote:

Trimble and HP took different approaches on their GPSDO's.
Trimble lets you get into things and fiddle around. HP is much more a black box.
I have never seen anything that lets you "fiddle' with one of the HP units.

Hi Bob,

I'm glad you asked. True, the Trimble TSIP binary command set lets you fiddle and the HP SCPI command set is much easier to use but more limited by comparison. But there's also a rich under-the-hood layer on the HP units. Spend some time with this file and you'll see what I mean:
http://leapsecond.com/museum/z3801a/z3801a-bin.txt
I explored the functionality in some detail during my hp GPSDO DAC dither investigation some years ago. Contact me offline.

I spend time to reverse engineer it, and there is a whole bunch of
"hidden" features which isn't in the documentation. Among others, you
can get the list of the pSOS processes.

There's also a pForth in there, so if you kick the right escape sequence
you get into a Forth prompt, but I don't remember how much of the inner
gut you get through it.

There is MUCH more under the Z38xx hood!

I would need to have pSOS manuals for the 68k variant to get further.

The Trimble approach is a tuneable PI-based PLL. Nothing wrong with
that. HP went for the Smart Clock approach out of NIST. The Trimble
approach is a platform where the openness allowed for the customer to
adapt to its application (and alternative oscillators) while the HP
approach was to achieve a well-engineered solution. What Trimble did
right is that they tuned up the GPS receivers oscillator while HP spent
more on the control algorithms. It's not all, but a quick stab at the
differences.

Cheers,
Magnus

On 10/22/2012 07:13 AM, Tom Van Baak wrote: >> Trimble and HP took different approaches on their GPSDO's. >> Trimble lets you get into things and fiddle around. HP is much more a black box. >> I have never seen anything that lets you "fiddle' with one of the HP units. > > Hi Bob, > > I'm glad you asked. True, the Trimble TSIP binary command set lets you fiddle and the HP SCPI command set is much easier to use but more limited by comparison. But there's also a rich under-the-hood layer on the HP units. Spend some time with this file and you'll see what I mean: > http://leapsecond.com/museum/z3801a/z3801a-bin.txt > I explored the functionality in some detail during my hp GPSDO DAC dither investigation some years ago. Contact me offline. I spend time to reverse engineer it, and there is a whole bunch of "hidden" features which isn't in the documentation. Among others, you can get the list of the pSOS processes. There's also a pForth in there, so if you kick the right escape sequence you get into a Forth prompt, but I don't remember how much of the inner gut you get through it. There is *MUCH* more under the Z38xx hood! I would need to have pSOS manuals for the 68k variant to get further. The Trimble approach is a tuneable PI-based PLL. Nothing wrong with that. HP went for the Smart Clock approach out of NIST. The Trimble approach is a platform where the openness allowed for the customer to adapt to its application (and alternative oscillators) while the HP approach was to achieve a well-engineered solution. What Trimble did right is that they tuned up the GPS receivers oscillator while HP spent more on the control algorithms. It's not all, but a quick stab at the differences. Cheers, Magnus
MD
Magnus Danielson
Mon, Oct 22, 2012 10:26 PM

David,

On 10/22/2012 08:07 AM, David Hooke wrote:

Tom,

It looks like they have a pForth interpreter running in there under
PSOS: http://code.google.com/p/pforth/.

That's not the pForth implementation in there I beleive.
It's pretty close thought.

Is there a mechanism to switch from SCPI to the Forth interpreter?

Yes. I did reverse engineer that a few years back. It will take some
time to recover.

Cheers,
Magnus

David, On 10/22/2012 08:07 AM, David Hooke wrote: > Tom, > > It looks like they have a pForth interpreter running in there under > PSOS: <http://code.google.com/p/pforth/>. That's not the pForth implementation in there I beleive. It's pretty close thought. > Is there a mechanism to switch from SCPI to the Forth interpreter? Yes. I did reverse engineer that a few years back. It will take some time to recover. Cheers, Magnus