Re: guiding relays vs scope controls


"Chris L Peterson" <clp@xxxxxxxxxxxxxxxxxx> wrote in message
news:2et2g29an7hi02c187vj4e8vpja8t0utdp@xxxxxxxxxx
On Fri, 08 Sep 2006 08:28:19 GMT, "Roger Hamlett"
<rogerspamignored@xxxxxxxxxxxxxxxxxxx> wrote:

How 'good' software guiding is, depends largely on your mount
controller.
'Relay' guiding (actually only a real 'relay' on the ST4, and similar
guiders, while on the SBIG cameras a 'pull down' transistor), gives less
'latency' (the mount is being controlled almost immediately, instead of
having to wait for a longer serial command)...

I don't think latency is a significant factor, for two reasons. First,
the latency shouldn't be significantly different for a relay controller
versus direct telescope control, since the relay controller itself is
receiving a command string itself before it can interpret and act on it.
But more important is the fact that the latencies are small compared
with the guide camera integration and readout time. The former is on the
order of milliseconds, the latter on the order of seconds.

Precisely _when_ you issue your correction command is less important
than its _duration_; a few milliseconds error in duration is much more
significant than a few milliseconds of latency.

I have moderate latency in my guiding because the commands are sent via
Ethernet, and can be delayed by the protocol (which may delay
transmission somewhat in an effort to construct a more efficient
packet). Back when I used a start/stop guider protocol, guiding over the
network caused me all sorts of problems. Once I switched to a
guide-by-time protocol, all the problems disappeared, in spite of the
fact that the latency is still there.
I have to disagree slightly.
You are thinking about the communication latencies only. These are
generally small. However some mounts seem to have a significant 'command
latency' on the serial commands. I have seen a unit, where when using
serial commands, despite it having what appeared to be a working
'milli-second nudge' command - which is the ideal guiding command, there
was a delay nearer to perhaps 1/3rd second, between receiving the serial
command, and moving!. I have used serial guiding fine, on many scopes, but
there can be a 'caveat' on some units. the 'longer serial command', is not
just the time taken to actually send the data, but the time for the
controller to interpret/respond to it.

Best Wishes



.

Relevant Pages

  • Installation problems on Intel D201GLY2
    ... usb1 at ohci0: USB revision 1.0 ... 00:00.0 Host bridge: Silicon Integrated Systems Unknown device ... Latency: 0, ... 00:02.7 Multimedia audio controller: Silicon Integrated Systems AC'97 Sound Controller ...
    (comp.unix.bsd.openbsd.misc)
  • PROBLEM: Serial error
    ... Latency: 64 ... Memory behind bridge: fda00000-feafffff ... 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller ...
    (Linux-Kernel)
  • Re: [PATCH 1/3] block: add blk-iopoll, a NAPI like approach for block devices
    ... from the iopoll softirq handler. ... then we will always have just the one command to complete. ... As to pre-prep for extra latency intensive devices, ... better than the original an CPU usage was lower. ...
    (Linux-Kernel)
  • sky2 X86-64 PCI synchronization problems
    ... with i386 kernel the controller runs fine without errors. ... Capabilities: Vital Product Data ... Latency L0s unlimited, L1 unlimited ...
    (Linux-Kernel)
  • Re: guiding relays vs scope controls
    ... However some mounts seem to have a significant 'command ... latency' on the serial commands... ... not to respond to a number of guide commands, ... It turned out that scope ignored small ...
    (sci.astro.amateur)