In article ,
Johannes Bauer wrote:
>I've developing a backend for (astronomical) CCD cameras. As the camera
>is connected to a PC and the pictures shold be viewed some place else, I
>want to have a daemon controlling the driver and a higher-level protocol
>in place.

>Before I brew my own thing there, is there any existing protocol so far
>which I could be conforming to? Something like POP3

HTTP is the protocol usually used for this purpose.
Just make your directory listing something that is easily
parsable, and accept a GET command which has some constant
prefix such as /image/ followed by the name of the image to fetch.
If you don't need any real security you could probably get away
with using HTTP 1.0 protocol, which is much simpler than HTTP 1.1 .

In article ,
Walter Roberson wrote:

>>Before I brew my own thing there, is there any existing protocol so far
>>which I could be conforming to? Something like POP3
>
>HTTP is the protocol usually used for this purpose.
>Just make your directory listing something that is easily
>parsable, and accept a GET command which has some constant
>prefix such as /image/ followed by the name of the image to fetch.
>If you don't need any real security you could probably get away
>with using HTTP 1.0 protocol, which is much simpler than HTTP 1.1 .

Depending on what was intended, that might be inconsistent with the
other person's sample commands. These appear to involve more than just
fetching existing images:

-> IMG WIDTH 1024
-> IMG HEIGHT 768
-> IMG DURATION 60.0
-> INTEGRATE

That HTTP is now the favorite kludge for tunneling through firewalls
and to bybase and subvert security doesn't convince me. Maybe I'm just
hopelessly prejudiced against SOAP and worse stuff. See
http://www.google.com/search?q=soap+http
including
http://en.wikipedia.org/wiki/SOAP


If I were in the mood for HTTP kludges for such an application, I'd just use
something like
http://camera1.example.com?WIDTH=102...&DURATION=60.0
or
https://camera1.example.com?WIDTH=10...&DURATION=60.0
with some flavor of HTTP authentication. A CGI script of a perl or
Borne shell script or a C program invoked by the Apache HTTP server
httpd would talk to the camera, telescope mount, and so forth. Httpd
would deal with the HTTP authentication chitchat, the TLS stuff for
HTTPS, as well as HTTP 1.0 vs 1.1. I suspect from what httpd does to
some of my slower CGI scripts that it would be necessary to fiddle with
httpd's timeouts to allow the CGI script to not answer for minutes as
suggested by "DURATION 60.0." Or have one URL that tells the camera
to capture an image and another URL that fetches whatever has been
captured.


http://www.google.com/search?q=network+camera+control
finds a bunch of relevant sounding web pages. For example,
http://camera-control.qarchive.org/
starts with a link for something that "has been specifically designed
for use with telescope cameras." See also
http://www.google.com/search?q=netwo...escope+control

Classic remote proocedure calls might be cleaner
http://www.google.com/search?q=remote+procedure


Vernon Schryver vjs@rhyolite.com

On Sep 3, 11:11*am, Johannes Bauer wrote:
> Hello group,
>
> I've developing a backend for (astronomical) CCD cameras. As the camera
> is connected to a PC and the pictures shold be viewed some place else, I
> want to have a daemon controlling the driver and a higher-level protocol
> in place.
>
> Before I brew my own thing there, is there any existing protocol so far
> which I could be conforming to? Something like POP3
>
> -> LIST
> <- 0: SBIG ST-9
> <- 1: SBIG ST-10
> <- .
> -> IMG SET CAMERA 0
> <- +OK Using SBIG ST-9
> -> IMG WIDTH 1024
> <- +OK
> -> IMG HEIGHT 768
> <- +OK
> -> IMG DURATION 60.0
> <- +OK
> -> INTEGRATE
> <- OK
> -> FETCH
> <- DATA FOLLOWS
> <- blablablabla (base64 encoded)
> <- .
> -> QUIT
> <- +OK Bye!
>
> If there was, I'd really be interested.


What not just send the JPEG (or whatever image format you prefer) as
an email attachment. SMTP is pretty easy. A JPEG also has room for a
lot of exposure and camera data. Or you could dump that data in the
body of the email or another attachment.

On Wed, 03 Sep 2008 18:11:27 +0200, Johannes Bauer wrote:
> Hello group,
>
> I've developing a backend for (astronomical) CCD cameras. As the camera
> is connected to a PC and the pictures shold be viewed some place else, I
> want to have a daemon controlling the driver and a higher-level protocol
> in place.
>
> Before I brew my own thing there, is there any existing protocol so far
> which I could be conforming to? Something like POP3
>
> -> LIST
> <- 0: SBIG ST-9
> <- 1: SBIG ST-10
> <- .
> -> IMG SET CAMERA 0
> <- +OK Using SBIG ST-9
> -> IMG WIDTH 1024
> <- +OK
> -> IMG HEIGHT 768
> <- +OK
> -> IMG DURATION 60.0
> <- +OK
> -> INTEGRATE
> <- OK
> -> FETCH
> <- DATA FOLLOWS
> <- blablablabla (base64 encoded)
> <- .
> -> QUIT
> <- +OK Bye!
>
> If there was, I'd really be interested.

Very hard to tell what you want the protocol to *do*.
What's INTEGRATE?

If all you want is to offer a bunch of files lying around on a
computer, I suggest using existing software. HTTP, FTP,
rsync-over-ssh, rsync or all of them. They are better at moving huge
data sets than anything you or I can come up with.

If you want a protocol for controlling the camera-and-computer,
including pointing it at the sky, yes, then I'd do something like what
you do. But I'd skip the FETCH command and do something like this
instead:

STORE
OK
Your file is available from now and until 8 hours from now as:
http://example.com/foo89898
rsync://example.com/foo89898
ftp://example.com/foo89898

Jorgen Grahn schrieb:

>> If there was, I'd really be interested.
>
> Very hard to tell what you want the protocol to *do*.
> What's INTEGRATE?

Yes, I should have been more specific, sorry for that.

Integration of a picture in CCD-terms means "take a frame". The CCD
picture is the integral of the photons over time.

I found another requirement which would be nice-to-have and therefore
makes me tend to an own solution: Suppose you have three computers. One
is connected on the telescope camera. The other is connected to the
telescope adjustment.

I'll define adjustment further: The earth rotates around its axis,
therefore stars appear to "move" on arcs. When taking pictures of dark
objects, integration time may well be 10 minutes or more. Therefore the
picture is blurred. The adjustment rotates the telescope in phase with
earths rotation, so that pictures are sharp. For that there is a second
very-high-speed, very-low-resolution CCD-seonsor in the CCD-camera. A
program reads out that fast CCD sensor, does an autocorrelation,
determines where the picture has moved and gives a signal to the
telescope adjustment to compensate.

Now with the above setup, there would be one server which should be able
to relay connections to all parts (i.e. camera and adjustment). The user
only connects to the main server which then does the rest.

> If you want a protocol for controlling the camera-and-computer,
> including pointing it at the sky, yes, then I'd do something like what
> you do. But I'd skip the FETCH command and do something like this
> instead:

This is a very good idea which I will certainly use. I like relying on
existing protocols very much because it increases the versatility of
solutions.

> Also ... I have a feeling astronomers are smart people with many odd
> skills, and with expensive equipment they want to make the most of, so
> I'd be surprised if noone hasn't solved and published the solution to
> this problem long ago ...

I must admit that I really had a huge smile on my face when reading your
words, because you are exactly right: smart people with odd skills :-)
And there is much software around for astronomers (like MIDAS), but I've
found none which fulfills all of my requirements. That's why I hoped
someone would know a protocol which does what I want (not only does had
it saved me time, but I am very much a supporter of open standards).

Regards,
Johannes