if you want to go the easy way to talk to REF-1 of REF-0 via the
J8-Diagnostic port try Ulrich Bangerts Z38XX software.
Here:
http://www.romahn.info/lucent/z3811.exe
you will find for download a patched and renamed version that directly
recognizes our nice new toys. After setting the right "Parameters" try
"View" or "Manual Command Entry".
cheers Götz
Am 07.11.2014 13:07, :
Hi
When Satstat does the change, I’m sure it uses the correct command to do it.
The syntax is a phrase followed by a numeric. You then use the same phrase
followed by a question mark to see if it took it. The slave happy accepts the
command, stores the data, and returns it when asked. A reasonable external
program would indeed say “yup it did it”.
With no serial com (that’s a guess not a proven) there is no way to change the
GPS. The slave simply stores the data. The only alternative would be for it to
reject virtually all commands over the Diag port. Much easier to just put a
note in the manual than to disable all that code.
Bob
On Nov 7, 2014, at 12:02 AM, Bob Stewart <[email protected]> wrote:
Hi Bob,
I've been using the Satstat program to send commands. What I don't understand is why the
slave will accept commands such as sat elevation angle and not give an error response.
It gives a response of "command complete", but it doesn't change it. Or is
that an indication that both units use the same firmware, and success is actually
indicated by the resulting change of the angle?
Bob From: Bob Camp <[email protected]>
To: [email protected]; Discussion of precise time and frequency measurement
<[email protected]>
Sent: Thursday, November 6, 2014 6:07 PM
Subject: Re: [time-nuts] Lucent KS-24361 GPSDO arrived today several questions
Hi
Ok, I got to spend a little quality time with my pair today. I mostly poked at
the Diag port with a terminal program.
Both of the units seem talk over the Diag port regardless of the mode they are
in (master / slave / fault ). Both respond to a sub-set of the Z3801 SCPI
commands (= not all commands work). There are a few enhancements where a query
to a “node” gives a reply (which it should not if it’s “node only”). All of it
works ok at 9600 baud 8N1. All of it comes back with an error message (E-xxx)
after a valid command response. It may not like the terminal program sending
cr/lf or something like that.
By far the most useful thing to type is :SYST:STAT?
That executes the system:status request and gives you a nice full screen of
information. It shows you about 95% of the useful information all on one page.
About the only major thing missing is the DAC value. That’s available with
another command out of the Z3801 list. It does take a while to compose and
transmit the screen, so it’s not the best way to to this forever and ever.
The data from the request is the same on both boxes. Same everything except one
shows as standby etc. The interesting details are things like elevation mask
and cable delay. Why interesting? You can set them with discrete commands. You
can also query the data with the same commands to make sure the box “took” what
you sent.
This allows experimentation with changing the elevation mask on each box (or
just simply doing a discrete query for the mask on each box). The Ref-0 / slave
will happily change things around with discrete commands. None of them are
reflected in the :SYST:STAT? listing on the Ref-0 or Ref-1. When you look at
the Ref-1 / gps box, it’s discrete query information matches the :SYST:STAT?
screen on both boxes. When you change things on the Ref-1 box both screens
follow that data.
—————
When you pull the antenna on the gps box, it immediately (almost) goes into gps
fault led flashing mode. The slave box happily sits there for a while (say a
minute) with it’s gps led saying all is well. When you plug the antenna back
in, the process is reversed. The gps box goes out of flash mode right away. The
led goes out in a bit. The led on the slave box does not follow for a minute or
so.
—————
All of this suggests to me that the Ref-0 / slave does not talk back to the
other box via serial. It also suggests to me that all it “sees” from the
Ref-1/gps box are the duplicates of the serial string out of the Motorola gps
module. The Ref-0 just figures out what’s happening by watching those strings
as they roll by.
Hope that makes sense….
——————
If that’s all true, it should be “easy” to put dummy gps sentences into the
Ref-0 interface port and a pps from something else. Once it sees stuff that it
likes, it will start locking up to that pps. Cheap micro and just about any
modern gps = fancy new GPSDO. Quick / easy / not much work. A little more
complex if you decide to translate sawtooth data. That of course assumes these
boxes do anything with sawtooth ...
Bob
On Nov 6, 2014, at 7:52 AM, GandalfG8--- via time-nuts <[email protected]>
wrote:
Hi Bob
I view the master/slave situation the same way you do, but only commented
because Lucent effectively sets things up the other way round so just
wanted to be sure which way Paul was considering it.
As regards, the "faking", yes, a single 15 way plug containing just a link
and a resistor is exactly what I use now.
I realise the RS422 fudge isn't ideal but certainly very handy for some
quick tests.
I've got two or three RS422 PCI interfaces but hadn't previously had any
spare slots, now I've got a couple of lovely Magma 13 way PCI expansion units
but need to hack them about so the ports are at the front.
Whoever decided rack mount PC kit should be built with all the connections
at the rear must have been really nuts, and it was too long ago to use
"corridors" of racks as a viable excuse, someone somewhere just fitted ears to
desk top style cases and left the rest of us to get on with it..
One of the best things I ever did was to buy a pair of "back to front"
rackmount PC cases with all ports and cards available at the front, trouble is
now I want everything else to match, and most test gear has just the same
issues!
All good fun, and certainly never a dull moment:-)
Regards
Nigel
GM8PZR
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
