[ntp:questions] Palisade Reference Clock

Marc Leclerc marc-leclerc at signaturealpha.com
Wed Sep 1 16:54:26 UTC 2010

  Have you looked at both firmware docs to insure that there is no 
changes in the packet data.

I had to play with this driver to talk to a resolution SMT and just a 
few changes in bits definition gave me
the same error. the driver will fail even if the error is from another 
packet (secondary time or such)


On 2010-08-31 06:17, Chris H wrote:
>> We have an Acutime 2000, which has pretty much just worked since we bought
>> it in 2005.  We haven't felt the urge to do anything to the firmware, and
>> I've no idea what it's running -- whatever was current at the time.
> Just looking at the bug fixes between 7.02 and 7.12, I thought it was a
> good idea to upgrade... now I regret it :( hence my request from anyone
> to get 7.10 firmware again.
>> Have you tried running the (Windows-only?) configuration tool?  What does it
>> say about the acutime?  Remember to run it on the *other* RS232 port on the
>> bottom-end converter box from the one you normally connect ntpd to.
> Yeha -- everything is working correctly, both ports are giving data.
>> Have you tried running the daemon in debugging mode, per the driver29.html
>> page?  What does that say?  We found that quite useful on the one occasion
>> where we had any problem with our unit.
> I still get clk_noreply... :(
>> The only occasion that I recall having any problems at all was when we
>> replaced the linux host with a faster machine, and we came to the
>> conclusion that either the serial hardware was "different" or the new box
>> was simply now pulsing the timestamp-me line too quickly.  As a quick hack
>> workaround I simply duplicated the two ioctl()s in the driver which toggled
>> the relevant control line.  It might be worth checking whether there's
>> anything in the code like that...
> I have been leant a Serial Port Analyser..
> HP4925A
> I can see the pulse per second coming into the unit, and I can see the
> data on the screen.
> When I run palisade_monitor or tsipchat or anything, the whole thing
> comes to life, both DTE and DCE all go green, and I can see packet flow
> in both directions... however when ntp is running, it appears the comm
> port does not 'become active' like it does when running tsipchat or
> palisade_monitor, or anything like that..
> And all I can see in inbound RD light blink green.
> When I run palisade_monitor.exe and select Port A and select
> View/Diagnostics and click Update, I can see RTS (on DTE side) and CTS
> (On DCE side) go from green to red. When I click up the update button, I
> can see the green link blink, but cant see the output packets on the
> analyser..
> I will keep looking, but if anyone else has experience with the HP
> analyser, and used one to diagnose problems, please let me know too :)
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list