Jump to content

Prism


Waldemar

Recommended Posts

  • 3 months later...

I tried a couple of things with Prism, Martin but at the moment I am going to do a housemove, so it will have to wait for further exploration.
It is not cheap, though...

 

Hi Luis, I am not guiding with the DDM85, I just image with short fl's so no need. But even with longer fl's I would try to go unguided. 
I am not sure yet if everything will work under Prism...

Link to comment
Share on other sites

  • 2 weeks later...

I just read the (online) manual for Prism.  I'm planning an online setup and it's time to investigate some of the more "modern" software.

 

I think Prism still can't match software like CCDcommander in terms of flexibility and planning.  Like you want to loop though a series of variables using different filters and adding checks and constraints.  Something that also SGP suffers from.  You just can do a dumb sequence of images and there it stops.

Link to comment
Share on other sites

  • 4 weeks later...
  • 1 month later...

Hello Max,

 

Long time I´ve sent an email to Mr. Hamza from Hyperion Astronomy, here you have his reply, but I couldn't reply to him, but If you want, please feell free to contact with him to continues with the subject! Here you have his email: hyperion.astronomy@gmail.com

 

________________

 

Good morning Mr. Ventura,

Thanks for reaching out to me. We have included a way to model 10Micron mounts because they have a "learn mode". I do believe that ASA mount, like Paramounts, have proprietary software. Is this the case? Can you provide me with information if there is a different option that you know of?

 

My best regards,

Hamza Touhami

________________

 

Best regards

 

Lluís Romero

http://astrophotographysirius.com/

Edited by astrosirius
Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

I am using prism since version 4 (it's version 10). So it's been more than 20 years. And it works quite well with DDM85 and 60.

I am on the contrary slowly discovering the ASA software since I have a few in my own observatory and I recently acquired a (used) DDM60 on which I have a RASA scope.

Did I understand correctly that MLPT is a way of "preparing" a long exposure ? Something like taking frames on the positions where the mount is going to be and then according the astrometry result, the mount is going to follow that path on the real exposure ?

Isn't this redundant with the pointing model. I mean if there is a pointing model, deriving it to get a tracking model is feasible, and when the mount tracks in the sky it should not have a constant speed, but should follow the tracking model (i.e. the derivative of the pointing model).

With the script language of prism (which is very simple to program) one can do almost anything. Now, giving speeds to the mount in order to follow a given track could be possible, even though I am not sure ascom does allow to tell the mount to go to very very slow speed like the ones needed in declination to follow the mount's flexure and change in refraction. Instead of changing the speed, one could also change the reference position (shift the mount by one arc second when it's necessary). From what I have seen though the mount can track very well for quite long individual exposures, so don't understand why MLPT would be needed since after the exposures it's quite easy to recenter all the images...

If somebody can give me more informations, I can see to make a script to do that.

Right now I am working on a script to generate .pox files directly from prism, in order not to have to purchase maxim and pinpoint. Just need a few more informations from ASA.
Alain

Link to comment
Share on other sites

Thank you for keeping us informed about your work with PRISM. I think it is a very interesting program. I downloaded a trial, but did not have the time to work with it in the trial period... Since I do have the other programs like PinPoint and Maxim, I am not in a hurry to spend a few hundreds on yet another program. I will though if it proves to be easier and better than the combination of all other programs.

 

Best regards,

Waldemar

Link to comment
Share on other sites

Hi Alain,

 

Yes MLPT is preparing for a serie of long exposures. It calculates a dedicated pointing model for that exact purpose.

 

Of course, you can recenter the images. But MLPT is for doing very long exposures: up to 20 minutes each. And during that time, you need the mount to shift for less than a fraction of a pixel. This is what MLPT allows to get, and nothing can recenter afterwards if an exposure is broken by a shift of several pixels during it.

 

Bonne nuit.

 

Bernard

Link to comment
Share on other sites

Purely as a matter of interest, with exposures as long as 20 minutes, what proportion are affected by things like aircraft, satellites, etc? There must be a point at which it is more efficient to do more shorter exposures.

Link to comment
Share on other sites

Nigil,

 

Sure they can be a problem. I usually can reject them as long as I have 7 or more images.

 

Max

 

Purely as a matter of interest, with exposures as long as 20 minutes, what proportion are affected by things like aircraft, satellites, etc? There must be a point at which it is more efficient to do more shorter exposures.

Link to comment
Share on other sites

I am surprised no one in has reverse engineered MLPT yet.  I think it could be handled as offset tracking rate minute by like a comet ephemeris.

 

1) Collect data for the imaged object and its path through the sky as sequence does using automation + plate solving.

 

2) Calculate the positional difference for each point in the exposure.

 

3) Plot these differences-use a function to smooth the path deltas.

 

4) Calculate the minute by minute ( or 30 sec) the offset tracking rate for RA and DEC.

 

5) Create a comet/satellite  - ephemeris table - Load this to data scope.

 

Scope now tracks exposure with corrected tracking rates.

 

I think it might cover the basic concept.

This could all be done outside of Autoslew and sequence.

 

I don't know if a comet ephemeris can automatic loaded into autoslew.

 

Off course, it just a thought.

 

Max

Link to comment
Share on other sites

Hi Max,

 

I had a similar thought last night. What if we could reverse engineer the serial protocol Autoslew uses for communication?

It shouldn't be too difficult, and if we would manage to write an open source driver for the ASA mounts, we could make our own "MLPT" or whatever, and maybe even get a Linux port going.

 

I wonder if anybody is willing to log the data going over the (virtual) COM port Autoslew uses? Maybe with adding what operations have been done at the mount, so that we could check if there are any differences between different mount versions...

 

Cheers

Lukas

Link to comment
Share on other sites

Hi Lucas,

 

If we can determine the protocol Autoslew uses with the mount (and I am sure it is possible, but it will take time), we can of course make an open source implementation that can run on a RaspberryPi or equivalent. This will provide a cheap, efficient and flexible way to do all what we need. I will be happy to participate.

 

Logging the USB traffic can be done using Wireshark. To make the recorded data understandable, you need to record separately the communications caused by any simple action on Autoslew. But this is just one step on the deciphering of the protocol.

 

Another much simpler method would be that ASA publishes the protocol specification. Every one has the right to dream....

 

 

Best regards.

 

Bernard

Link to comment
Share on other sites

Hi Nigel,

 

Wireshark was initially a lan packet analyser only. It was added a USB packet sniffer (USBPcap on Windows) so that it is able now to do both lan and USB. Of course, there are other tools that can do the job. Wireshark is just the one I use when I need such a tool.

 

Best regards.

 

Bernard

Link to comment
Share on other sites

Well, I did a first test, and am pretty sure it will be a hell of a work to do  :)

But anyway, basically we'd need to start with something that we can reproduce easily. I'd go for the classic startup sequence, so something like this would be a start:

  1. Start the USB sniffer (or COM port sniffer) software like Wireshark, and let it log all data sent and received on the mount's COM port.
  2. Start Autoslew
  3. Power on the motors
  4. Once the motors are powered on, power them off again
  5. Close Autoslew
  6. Stop the sniffer's logging, and send the log somewhere we can share it (like pastebin)

A first test shows communication with short codes and numbers, which could mean anything. The next step would then be to correlate the data sent from Autoslew with functions/commands. Stuff like activating sidereal tracking, stopping tracking, goto a position etc. Could become interesting  :D

 

@Bernhard: Do you know if Wireshark is sniffing only USB or could it also log serial commands (data sent over a virtual COM port like used by Autoslew)?

Link to comment
Share on other sites

Hi Lucas,

@Bernard: Do you know if Wireshark is sniffing only USB or could it also log serial commands (data sent over a virtual COM port like used by Autoslew)?

 

As long as the virtual com port uses a USB device, it should be possible to sniff it with Wireshark. I didn't test it as I rarely use Windows.

 

Best regards.

 

Bernard

Link to comment
Share on other sites

I know little about usb/com port communications protocols but presumably there is a layered set of protocols:

 

1. FTDI (emulating com port)

2. Com port serial protocol (basic handshaking)

3. At least one layer of data protocols

 

We would need to fully understand the protocol stack so the actual data can be extracted. Does Wireshark know about the stack being used so it can isolate only the application-level data?

Link to comment
Share on other sites

Hi Nigel,

Does Wireshark know about the stack being used so it can isolate only the application-level data?

 

USB packets may contain payload.

As far as I can tell, apart from the serial line initialization, the USB payload of each packet contains the data to be sent over the serial line.

 

Wireshark can isolate the USB payload so we can know what are the data sent or received by the application.

 

Best regards.

 

Bernard

Edited by RamaSpaceShip
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...