×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Indiserver WiFi option for Synscan Goto?

  • Posts: 90
  • Thank you received: 12
My proposal for the Connectivity section (please proof read it and correct it when I fail to write correct english!):

Connectivity

There are basically two way to connect your mount to your computer (PC or Raspberry PI/Stellar Mate): direct serial cable or Network. In either case you are directly connecting to the motor controller of the mount, the driver does not utilize the services of the Synscan Handcontroller or Synscan app.

1. Cable Connection
You are connecting the serial potr of the mount (motor controller board) to your computer, this is usually done through a USB port on the computer. The motor controller on the mount has TTL level serial connection (0V and 5V levels, this is very much different from the standard serial port levels, +/-9V which can be found on some older hand controllers!), so you need a Serial TTL-to-USB cable, also known as EQ Direct USB cable (see EQDIRECT interface). Many vendors sell USB to RJ45/DB9 EQDirect-compatible cables and adapters. You connect the USB to your computer or embedded device running INDI and then use the driver to control the mount.
The EQMod driver can also be used with the Synscan controller if PC Direct Mode is enabled in the handset. However, this approach can be problematic and generally not recommended (please be careful here, as the handcontroller's serial port uses RS232 levels, which is different from the TTL levels of the motor controller. Also the pinout of the RJ12 connector on the handcontroller is different!). For wired connections, using EQDirect cable is recommeneded.

Once the EQDirect cable is connected to your computer, it wil be recognised by the linux kernel as a USB Serial device, and a device file is created for it in the /dev directory. You can check that with the
ls -l /dev/ttyUSB*
command. If more than one USB-serail cable is connected (for example one for the external shooter relase of your DSLR) than you will see more than one such file (/dev/ttyUSB0, /dev/ttyUSB1, etc...), you will need to identify which one is which. They are by default numbered in the order they connected or in the order the linux kernel enumerated them.
That device file name must be written in the "Ports" field on the "Connection" tab.

You may also try connecting your USB cable and allowing the system to scan for candidate ports. USB port detection is effective on a number of operating systems.

The BAUD rate is the data rate and must be set to the baud rate of your mount (please refer to the documentation of your mount), most of the SkyWatcher devices operate at 9600 baud. Changing this number will result in a failure to comnunicate unless at some point SkyWatcher changes the firmware settings in their hardware.

2. Network connection

It is OK as it is, but I would put a screenshot showing 192.168.4.1, as this is the most common case. I would also link to the Az GTi documentation as there are very nice diagrams detailing the different cases (100% applies to our case).
Last edit: 3 years 2 months ago by Zoltán Belső.
3 years 2 months ago #65320

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
@ gubi:

I posted your changes with slight (mostly syntax) motifications. Thank you for the additions and suggestions!

Do you have a joystick recommendation? And do you know if the "simulated hand unit" mount controller in the Ekos Mount section has been stabilized? My assumption is that it has not, hence my request for a joystick recommendation.

@ knro:
Still issues with "Syncing failed" coming from Ekos align.cpp (line 4408). This occurs "occasionally" but frequently enough to be a problem. The scenario is:

Goto target, Capture & solve, stuck in retry loop owing to failure to sync until timeout.

Typically, once this occurs, Capture & sync will also fail, though sometimes this "repairs" the issue and a successful Capture & solve may be executed following the success of a sync.

It smells like a timing thing, as though some additional delay is needed. I see there are retry counters on several related operations. I may mess with them a bit to see if it makes any difference.

@ gubi:
Do you have the above problem on your mount? If not, and since I run WiFi and you run hardwire, that may be a hint.
Last edit: 3 years 2 months ago by Jon Carleton.
3 years 2 months ago #65606

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
Jon,

I'm sorry I missed to reply to your joystick question.
So my original fix for the EKOS conrtol pad and joystick control is in the master trunk since months, so it is as good as it can be according to the 'state of the art' code. It has some overshoot and retrack back like behavior, but imho mostly usable. I have a plan to further tweak it but I'm not sure how much it will help.
The joystick is of course easier to use than trying to push button with a mouse, aspecially when you are sitting next to the scope and trying to look into the eyepeace. So i recomend using a joystick, or even more practiacally a game pad. The game pad has two sticks, one is moving the scope, with the other you can change the speed. The only drawback is that you still have to have the EKOS mount control pad open, to see the actual speed setting, as it is sometimes it skips 2 or 3 steps when setting with the joystick, and I don't know any other means to know it.

Last night it was a sort of clear sky, and I have experimented with the SoftPEC. @krno, with the recent code cleanup you have removed the softPEC code, as it was surrounded with "if (virtuoso()) {}" code, but imho the softPEC the way it is implemented in the code now maybe useful for any kind of mount. It is right to have it disabled (on the settings) by default, but it should be allowed to be enabled, regardles of the mount code. Also I would put the same for the other (Az) axis too.

So during experimenting with this I have done a lot's of solve&sync operation, and it seems that the "sync failed" comes when I successively do solve&sync, and the error goes below some threshold. Afther that the "solve & do nothing" still works, and if I slew to a slightly different target, the "solve & sync" works again. Even worked sometimes for the same target after a while (the mount has drifted away meanwhile". But this "close enough" is still a few hundreds of arcsecs which is obviously not "close enough" for some practical purpose, so something should be done about it.

Jon, I don't understand what do you mean by the "simulated mount has been stabilized" thing!
3 years 2 months ago #65607

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
Gubi,

No worries on a miss. I'm old and miss stuff all the time :). I'll look at game pads, then.

I see why you were confused. I originally had typed, I thought, "simulated hand mount" and the "n" dropped, leaving "simulated had mount" and made no sense at all. I should proofread, and will have corrected it by the time you read this. I was referring to the EKOS mount control pad (that "simulates" the hand controller). I have been afraid to use it on the few good nights we have had as it causes a complete shutdown and restart to exorcise the scope after it has been possessed.

I'm pleased to see you are having the same result as I, more or less, (not that I would wish you any problems), with the Syncing Failed issue. That allows me to believe that the problem is not necessarily related to WiFi versus hard-wire connectivity. And yes, only on near miss solves and it repairs itself in odd ways...or doesn't. I have tried a GOTO to a nearby object with total success only to try and return to my intended target and fail a second time. The next night without clouds, I intend testing a Syncing Fail by cutting and pasting the RA/DEC coordinates into the INDI Control Panel with the SYNC button pressed.

My mount has built-in SoftPEC. I have an idea that two versions of SoftPEC should not be running at the same time. Perhaps, if the driver SoftPEC becomes operational, I might test whether one is better than the other. I will say that I have not been impressed with the SkyWatcher SoftPEC up to now. I tried it several times when running SynScanPro android app, and was not the least bit impressed.
Last edit: 3 years 2 months ago by Jon Carleton.
3 years 2 months ago #65610

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
@Gubi,

I've been looking at the Syncing Failed issue quite a bit. I'm not sure it is -directly- related to the driver. This, because with other pointing software, it does a point and sync without issue. What this probably means is that the alighn.cpp is looking for something that isn't set properly (or at all) in the driver.

I wrote a little Java point and sync driver for testing (very basic and rough) and played with delay timing. That didn't seem to matter. It would still sync, even with the most minimal delay I could muster.

It can be a very frustrating issue. I was on the crab nebula last evening and the mount went straight to it and centered in a couple of hops. I wasn't guiding, so after a few minutes, I needed to re-center. Not a chance. I even tried going to 4 different nearby stars and back (4 compass points), which worked, but each return to crab nebula got close on the first slew, but sync failure after that.

I told my wife I need to buy a joystick so I can recenter the image when it moves. :)
3 years 2 months ago #65980

Please Log in or Create an account to join the conversation.

Any logs that can shed light why it syncing failed? It's possible the driver is rejecting these sync points? One way to resolve this would be to "Clear Alignment Model" in Ekos --> Mount module.
3 years 2 months ago #66003

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
Jon,

I don't really understínd what do you mean by "Java point and sync driver", can you elaborate it a litle bit more detail?

A few days ago I had a clear enough night to take some pictures, targeted M42. I've used my small Virtuoso mount with a SW50ED mini scope (250mm focal length), and the ASI178MC camera.
First I've followed the normal alignment procedures: solve&sync to different parts of the sky. Starting around Polaris (as always), solve one to the east, then gradually going to south (Orion is at the south meridian this time). At first the tracking was terrible, even 1 sec expoes had star trails.
Then I have disconnected EKOS and INDI and restarted the driver. After reconnect (thanks to the latest modification in the driver) it take on the correct position of the scope on the sky, Kstar has shown the scope just where it was before the driver restart (of course idle, not tracking now), so I just issued a goto (small movement, but start tracking) and done solve&sync. The sync issue come up at the second or third solve as usual, but I had M42 in the FOV enough, and this time I got rather good tracking. I was able to capture 20 sec exposures.
I started imaging with 20 sec expos. Some images were almost perfect, others not so good. After a while it started to drift in some direction leaving star trails. Sometimes it stopped or even reversed, drifting in the other way.
So I did a disconnect and restart again. The same result. All in all I was able to get 138 of 20 sec good enough pictures (before M42 went behind the house) with 3 or 4 restarts.
So it seems that only one solve&sync after a fresh driver restart gives better tracking than taking many all over the sky. It is not clear why it is so. In theory the tracking should be more and more precise after taking more and more syncs. But it does not appears to be so.
It is also unclear what causes a good tracking to start slowly drift in a random direction. But it seems the SoftPEC procedure as written on the Virtuoso driver page is not helping, the tracking is not precise enough to even make the measurement procedure written there (I did this imaging session with SoftPEC disabled).

By the way, during this session I used the EKOS mount control pad to put my target in the center of FOV (when the solve&sync was unable to do so), and it worked, no strange issues occured.
Actually the EKOS mount control pad uses the same method to control the driver as the joystic does. So don't expect the joystic to do any better job than the EKOS pad. These are exactly the same. It is just that sometimes the joystic is more convinient to use, especially during visual inspections. My advise is that don't spend on an expensive joystic, just by the cheapest game pad you can find. It will do the same as INDI does not take andvantage of the precisity of the joystic, it just basically use it as a 4 way hat switch.

Here is a bad one:


Here is a good one:


And here is the final stacked (corped) version:
3 years 2 months ago #66006
Attachments:

Please Log in or Create an account to join the conversation.

So why is the tracking terrible in this driver? it needs faster updates? smoother speed adjustments? or the problem is elsewhere?
3 years 2 months ago #66007

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
I wish I knew!
3 years 2 months ago #66008

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
Obviously tracking with Alt/Az is inheritelly much more complicated than tracking with EQ.
For an EQ mount you have polar alignment, and if it is right in theory you only need to rotate the RA axis at a correct speed, right?
For Alt/Az there is no equivalent thing. You have to have your mount level (Az axis vertical, and Alt axis horizontal) in the first place, but still the tracking software (be it the INDI driver or Synscan) still have to consider your exact position on the globe and the exact time. Any inprecisity in that would cause poor tracking.
So far I thought that the alignment procedure is for comensationg for these inperfectments. So by syncing to many stars it could deduce how much the Alt and the Az axis is inclined to the perfect direction (which is maybe the same as having an error in your geo location, I bet). I have a feeling that I could have read these estimated angle errrors from the driver somehow, but I cannot find it anywhere. All I see is that a sync operation adds an offset to the coordinates around the part of the sky it is made. But it will be not enough I'm afraid.
3 years 2 months ago #66009

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
And one more thing: all this misalignments does not explains the phenomea I have had last time (and many times before): after having a good tracking something goes wrong and starts to drift in a direction. The direction and drift speed seems to be random, and changing in time.
I think having the scope not perfectly level or otherwise badly aligned should cause a constant drift at a given target on the sky, at least for a while (which 'while' is measured rather in hours then minutes...)
No explanation.
3 years 2 months ago #66011

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
@knro:

I will try your suggestion of clearing the alignment model and report back. I too have experienced good and bad tracking nights. By the way, this also occurs with the indi_synscan_telescope driver and the SynScan App or HandUnit. One time all is perfect, the next it sinks away. No rhyme or reason.

@gubi:

First of all, AWESOME image!! I have exactly the same camera, but don't seem to have the same FOV. How is that possible? Do you have some kind of reducer?

I also had a good night of tracking. So much so, I had to turn guiding off, as it was over-correcting from a very stable track. I also landed on 20 seconds for a target exposure (very unusual to get tracking that good). I picked a dim target, then I got clouds and it went behind a tree (and the dog ate my homework). Someone told me that objects with "IC" prefixes means that you probably won't. (IC= I SEE) See attached.

Interesting that your startup is similar to mine, excepting that I start West instead of East after unpark. My target area is SW-SE due to obstructions (trees) and I have to setup in the front yard for North targets. Either way, I unpark, then Goto/Solve my way, step at a time, to my target area. Usually 3 or 4 stops from North to South.

I built a little quick and dirty Java indi client that does only two things (beyond connecting to indiserver). It will send Sync XML and Slew XML and receive the feedback. It is just easier for me to do something quick in Java. It isn't a program as much as chunks of code in NetBeans, but it more or less proved to me that the driver isn't malfunctioning in and of itself. There must be something lacking in the communication between the driver and the alignment module in Ekos. Some variable that is being looked at in Ekos that maybe does not exist or is not properly updated in the driver that Ekos relies upon. My little Java thing doesn't check anything. It just sends the commands and receives the feedback (no errors, by the way). It is meant just as a test for me. I fully intend to try Jasem's clearing process next.
3 years 2 months ago #66014
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.777 seconds