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

In a message dated 06/11/2014 12:04:47 GMT Standard Time, kb8tq@n1k.org
writes:

Hi

time-nuts@febo.com wrote:

1. Slave in the sense that it’s slaved to the GPS in the other box. Unless
   we  find a serial link from the Ref-0 back into the Ref-1, that’s all it’s
   doing.
2. It fires up and the Ref-1 box gets all organized and locked up.  It goes
   “ok” first, then the Ref-0 goes “ok” (locks to GPS). In that sense,  the
   Ref-1 is the master.

My guess is that they default to output from  the Ref-0 rather than Ref-1
because it’s the one more likely to fail (more  single points to go wrong).

the

Yes it is confusing - sorry  about that

the

and 3

from

play

resistor,

So a single 15 pin  connector with one jumper and one resistor (or jumper)
plugged into the  interface socket.

an hour

be

to

Works, but if you have an old style +/- 12 V RS-232  signal, things might
or might not work forever. A lot depends on how they have  protected the
chips. They expect a 1.5 to 3.5V signal on the input, so even  +/-5 is a bit
exciting. Full blown RS-422 interfaces are sub $15  gizmos.

Bob

this

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

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

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 kb8tq@n1k.org
To: GandalfG8@aol.com; Discussion of precise time and frequency measurement time-nuts@febo.com
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

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

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, :

It seems that this program will not work for Win 7.
Has anyone attempted to decompile this thing?

Maybe re-work a bit and have it run on anything?
-George, N2FGX

On 11/07/2014 01:34 PM, Bob Stewart wrote:

Hi

Thanks for posting that information. Keeping Ulrich’s code going is a very good thing.

Bob

Hi

The reason it was listed as #1 on the list is that I made the backwards numbering mistake when I was trying to work out the resistances on the interface connector. I’ve been doing this for > 40 years and I still mess it up on a regular basis. We also seem to get it wrong from time to time when we lay out connector connections on pc boards, but that’s another story altogether …..

Bob

Even though Bob says it I also screwed up the 15 pin mini.
To be very clear

Viewed from the chassis front.
Male plugs pin 1 left side
Female plugs pin 1 right side

But that said the systems running fine now by simply doing the pin 2 and 3
approach.
Next things. Battery backup to the GPS unit then RS422 and communications.
My unit took a solid 2.5 hours to lock etc. But I was not on the good
antenna. Instead an inside unit on the bench. Far from optimum. I just did
not want to screw with the antenna connector and the L + 220 ohm R to fake
out the GPS unit.
Thanks for the help every one.

Regards
Paul
WB8TSL

On Fri, Nov 7, 2014 at 9:14 PM, Bob Camp kb8tq@n1k.org wrote:

I will check when I get things going but the error message you see may be a
parity error. I know some GPS things wanted even parity.
I'll take a run at it tonight I hope.
Regards
Paul
WB8TSL

On Sat, Nov 8, 2014 at 10:56 AM, paul swed paulswedb@gmail.com wrote:

Hi

You make another good point, that is worth repeating.

With RS-422, it’s not just the usual RX to TX and TX to RX confusion. You can have all that right and still get it wrong. The + and - of each must be properly identified and connected.

That sounds easy, but there is a catch. If you are used to RS-232, you are used to a negative voltage being a “one” and a positive voltage being a “zero” data wise. It’s upside down from the conventions on say, CMOS logic (one = more positive voltage).

RS-422 uses a convention where the + output is higher than the - output when you have a “one”. That’s the normal idle state for a serial output. Again, it’s a simple DVM check on something it’s VERY easy to get wrong. Simply put - at idle, the + output is the one that should be the higher voltage (3.5V in this case).

Of course one should beware - It’s very easy to run though the archives and find lots of places I get this kind of stuff mixed up. Like I said, it’s not as easy as it seems.

(It’s even more confusing when you start talking about the control lines … thank goodness we don’t seem to have CTS and RTS involved on these boxes).

One further disclaimer, this is all for RS-422. That’s what the HP / Lucent boxes have on them.  Mil-STD-188-114B signaling is very similar, but without the 2.5V offset on the levels. They should talk to each other, troubleshooting a mixed setup like that is a bit more complex. If your adapter is actually a 114B adapter, things will be a bit different when you mate it all up.

All of this differential signaling stuff is designed to be used in noisy environments. You can have a 2V sine wave driving one end’s ground compared to the other end and still get perfect data transmission. With some driver / receiver combos you can have a lot more than 2V and still do 100Kb/s error free. It’s also great for setups where you want to isolate the grounds of two systems. It’s not as good as opto isolation, but it’s a lot better than a hard ground wire.

Bob

Hi

Actually the error message is a “feature” of SCPI. It’s one that I never remember when I’m using a terminal.

You need to send a command (or power cycle) to clear the error que. It’s like GPIB in that regard. The errors stack up as you send commands and you must toss out each one out. Once you have them all tossed, you get the “scpi>” prompt rather than an error message.

Yes I’m sure there is slightly more to it than that, but this is the Cliff notes version.

Bob

why don't you just look at the D_Sub connectors. Pins and sockets are
consistently numbered. I do see these numbers even on the J5 interface
connector of my RFTG-1. If needed take a magnifying glass.
Götz

Am 08.11.2014 16:56, :

Hi Bob,
I've been using the "cheat" method that Stewart posted.  It's mostly working, but I do see occasional errors.  So, I ordered the following USB to RS-422 adapter.  Now your post makes me worry that there's still going to be a problem.  I'll post results back to the list.  It is a FTDI device.  Hopefully it's a "real" FTDI device and not subjected to getting bricked.

USB 2.0 to RS-485/RS-422 RS485/RS422 DB9 Serial Adapter Cable FTDI FT232 FT232R

And I was also wondering if anyone has put together an adapter using LTC-1485 or similar chips?
Bob

  From: Bob Camp <kb8tq@n1k.org>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Saturday, November 8, 2014 10:10 AM
Subject: Re: [time-nuts] Lucent KS-24361 GPSDO arrived today several questions

Hi

You make another good point, that is worth repeating.

With RS-422, it’s not just the usual RX to TX and TX to RX confusion. You can have all that right and still get it wrong. The + and - of each must be properly identified and connected.

That sounds easy, but there is a catch. If you are used to RS-232, you are used to a negative voltage being a “one” and a positive voltage being a “zero” data wise. It’s upside down from the conventions on say, CMOS logic (one = more positive voltage).

RS-422 uses a convention where the + output is higher than the - output when you have a “one”. That’s the normal idle state for a serial output. Again, it’s a simple DVM check on something it’s VERY easy to get wrong. Simply put - at idle, the + output is the one that should be the higher voltage (3.5V in this case).

Of course one should beware - It’s very easy to run though the archives and find lots of places I get this kind of stuff mixed up. Like I said, it’s not as easy as it seems.

(It’s even more confusing when you start talking about the control lines … thank goodness we don’t seem to have CTS and RTS involved on these boxes).

One further disclaimer, this is all for RS-422. That’s what the HP / Lucent boxes have on them.  Mil-STD-188-114B signaling is very similar, but without the 2.5V offset on the levels. They should talk to each other, troubleshooting a mixed setup like that is a bit more complex. If your adapter is actually a 114B adapter, things will be a bit different when you mate it all up.

All of this differential signaling stuff is designed to be used in noisy environments. You can have a 2V sine wave driving one end’s ground compared to the other end and still get perfect data transmission. With some driver / receiver combos you can have a lot more than 2V and still do 100Kb/s error free. It’s also great for setups where you want to isolate the grounds of two systems. It’s not as good as opto isolation, but it’s a lot better than a hard ground wire.

Bob

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi

There are a wide range of chips you can use for “proper” RS-422. There are also a range of USB RS-422 adapters for < $25. I would investigate the adapters, starting with cheap ones that claim FTDI chips inside. I’d also look for a claim of Windows 8 drivers. That’s  not so much because I use Windows 8, but because it implies they have checked in on a modern OS.

The adapters I’m using are 12V powered RS-422 to RS-232 converters that I’ve had forever and ever. I probably got them on eBay a few centuries ago. Mated up with generic 232 to USB converters they seem to work just fine for what I’m doing.

One very real question - do you need to talk to the box? About 99.9% of the time in my setup, the answer is no. Check the LED’s, make sure all is fine, move on. The serial cable is just one more ground loop to worry about. Checking it when you fire it up for the first time - sure, you need to do that. Stewart’s approach works fine for doing that. It’s also ok for a check once every six months to a year to see if the beast is happy or not.

If you are going with a home built converter, start with the FTDI cables from Mouser. Either:

http://www.mouser.com/ProductDetail/FTDI/TTL-232R-5V/?qs=sGAEpiMZZMuGxYVy11yKKrDbHO9RZyo6Pg7KqAgrCmE%3d

or it’s wire lead cousin. Both are $20. Both are legit FTDI gear. Yes you can get similar stuff on eBay for about half the price. Who knows which chip is in what in that case.

Either a perf board and DIP parts or a $2 custom pc board (1” square is plenty) and SMT’s will give you a fine home-brew RS-422 converter. When you are not using it for RS-422, unplug the board and use the adapter for other stuff. Maybe make a 485 and a 232 adapter as well. All the plugin boards and parts probably won’t double the total project cost over just buying the cable.

————

I’m not at all sure I should bring this up, but there is a pps on the output of the KS-24361. If one wished, they could do a board that did 422 to 232 and put the PPS on some pin that a NTP driver might be happy with. The whole NTP driver / GPS time offset / Leap second issue is one we have spent a lot of time on. I might  also could convert the pps to CMOS logic and hook that up to a coax connector. If you did NTP  then serial would be a full time sort of thing.

My guess is that you would eventually go to some sort of pc board to get at the PPS, NTP or not. Do you pull it off the interface connector (and maybe grab the GPS data as well?). Do you get it from the PPS/RS-422 connector and keep things isolated?

Lots to think about. Lots of choices. No one one size fits all solution.

Bob