Jump to content

RamaSpaceShip

Members
  • Posts

    180
  • Joined

  • Last visited

Posts posted by RamaSpaceShip

  1. Hi Robert,

     

    When I started to use my ASA DDM85 (~4 years ago), I often had a similar issue like yours (nearly every time I used it). I don't know where it come from.

    I quickly discovered that it does not happen if I don't switch off the mount after using it. With Autoslew, I stop the motors and the fans anyway.

    I now only switch off the mount when I have some cleaning to do in my observatory, and only for the time of the cleaning.

    Never saw this issue again. :)

     

    Hope this helps.

     

    Bernard

  2. Hi George,

     

    You get a warning point when you go beyond the acceptable limits.

     

    These limits are clearly explained in the 'still to be written' appropriate documentation.

    It's ASA after all.

     

    Best regards.

     

    Bernard

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. Bonjour Amenophis,

     

    This is a known issue with Autoslew (never fixed) where config files are read using the locale for decimal separation (',' in France), and are written initially using '.' as decimal separation.

    This leads to errors like the one you've got.

     

    You need to change the decimal separator in your Windows locale settings to be '.'.

     

    Bonne journée.

     

    Bernard

  9. Hi Mike,

     

    As far as I understand, the "Sync" button in Autoslew is only meaningful when you use Autoslew itself to go to an object. If you use any other mean (like CdC), Autoslew is not aware of the target object, just of the coordinates indicated by the external program, and so refuses to sync. In this case, you must use the sync feature of the external program.

     

    The sync feature in Autoslew can be helpful when you don't use an external program to locate objects (I don't know anyone doing that, but that does not mean that there is nobody).

     

    Best regards.

     

    Bernard

  10. Hi Robert and Mark,

     

    I use a variant of Mark's solution: I never switch off the mount. This solved the USB problems I had when I start using this mount four years ago, and since then, these problems never surfaced.

     

    Hope this helps.

     

    Bernard

  11. Hi All,

     

    I don't know how to intercept the Ascom flow, but it is possible to implement a pseudo Ascom focuser that redirects the requests to the real one, gets its position, filters it and returns a stabilized position to the caller.

    The application will connect to this pseudo focuser driver in place of the real one, and by that trick, will get fail-safe positions.

     

    Hope this helps.

     

    Bernard

  12. Hi Lukas,

     

    You can probably run easily Autoslew with Wine on Linux as a standalone application.

    But the nightmare comes from the communication with the other tools, as Autoslew uses Ascom, and Wine is not a multiprocess Windows environment.

    You will have to bridge Indi inside Autoslew: good luck!!!

     

    I bought a used PC for less than 100€ to manage the mount with Autoslew under Windows in the observatory, that I control  from my Linux desktop confortably installed in my home office. This is must simpler than trying to do the impossible for hours, as I don't have that much time.

    I would like to be able to do that all with Linux, but this is not (yet?) the case.

     

    Best regards.

     

    Bernard

  13. Hi Wolfgang,

     

    As far I can see, it seems that your DSLR sensor is too far away to be in focus. You need to calculate where is the focus plane (using a medium position of the OK3), take into account the back focus of your DSLR and use an extension tube of the appropriate length. You cannot expect to be lucky, and get in focus without this calculation.

     

    Best regards.

     

    Bernard

  14. Hi Bernard,

     

    This is a known problem. Your locale is set so ',' (comma) is your decimal separator, while ACC configuration file expects '.' (dot). You need to change your locale parameters.

     

    Best regards.

     

    Bernard

  15. Hi Lukas,

     

    I have the OK3-Z hardware manual (of course, ASA level doc). I should also have its software manual, but I have to do some ASA doc mining to get it.

     

    Please send me your email adress by PM and I will send them to you.

     

    Best regards.

     

    Bernard

     

    PS: I confirm I have both manuals.

  16. Bonsoir Fabrice,

     

    Bienvenue sur le forum ASA.

     

    Your evolution is not that presomptuous: the sooner you start with ASA stuff, the sooner you get it working, as the learning curve is quite deep.

    The reward is that it is like a charm when you eventually master it.

     

    Anyway, don't hesitate to ask in this forum as you will quickly find some help. Look also at http://asa-users.orgwhere we are collecting useful information.

     

    Bon courage (et il t'en faudra).

     

    Bernard

×
×
  • Create New...