Hi Thanks for posting that information. Keeping Ulrich’s code going is a very good thing.
Bob > On Nov 7, 2014, at 10:42 AM, Götz Romahn <go...@g-romahn.de> wrote: > > 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 <b...@evoria.net> 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 <kb...@n1k.org> >>> To: gandal...@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 >>> >>> >>> >>> >>> >>> >>>> On Nov 6, 2014, at 7:52 AM, GandalfG8--- via time-nuts >>>> <time-nuts@febo.com> 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 -- time-nuts@febo.com >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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. >> > _______________________________________________ > 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. _______________________________________________ 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.
