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)
hth
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@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
