×

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
The Wifi in the mount in HotSpot mode pretty much a normal hotspot. I don't know what do you mean by 'act as a router', route between what? It has only a single network, the wifi itself. Still you can connect to the wifi with multiple devices, as any wifi, but it is still a single network.
I used my wifi dongle on the mount (i don't have it built in, but I bet that is the same) as a hotspot and connect to it by one android phone running the synscan app, an other running SkySafari, the RPi, and my laptop running VNC too.

But be carfeful witth the wifi, it is easy to overload the wifi capacity. Once I have used my setup as the RPIi was connecting to the mount through the wifi dongle instead of trhe direct USB cable, and my laptop was connected to the RPi using VNC through ethernet cable. When I disconnected the ethernet and swithced the VNC connection to the wifi the mount started to act strangly. I bet it was due to some of the mount commands has been lost on wifi.
I have the feeling that even in the case of direct USB-TTL serial connection between the RPI and the mount some strange behavior and lost tracking is due to packet loss os bit error on the serial cabel (I had made myself the serial cable too long, TTL voltage is prone to noise).

Plate solving is working for me pretty stable either when the camera is on the main scope or when I put it on the finder scope. Just be careful and set the scope focal length correctly, and choose the correct scope on the plate solving tab.
I use my setup as both the Indi server and KStars runs on the RPI and I connect to it using VNC from my laptop or a tablet. This way I can do a setup where the wifi does not play an important role: the mount is connected to the RPI through USB cable, the camera also connected through USB3, so all the tracking and imaging is self contained in devices strapped to the mount. Only I myself monitoring the process is connected through wifi. If the wifi disconnects nothing is lost, I just need to reconnnect, INDI, Kstars, EKOS both running unaffected.
3 years 5 months ago #61824

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

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

Good success last night! Like you, I have had issues with WiFi when the bandwidth gets crowded. I have also had problems with the Pi4 when two busy USB3 cameras were both slamming the system. These problems are not limited to USB, but also impact networking.

When I asked about the Skywatcher HOTSPOT, my use of the word "router" wasn't particularly appropriate. While most HOTSPOTS will allow multiple connections, some do not allow data to pass from one client, through the HOTSPOT to another client also connected to the HOTSPOT. Others do. I know the general RFC for HOTSPOTS is to pass data between clients, but I have run into a couple of phones and other devices that dead-end at the HOTSPOT or route directy outbound to the Internet and directly back to the original client. I was thinking about taking the telescope off my local WiFi network and using the HOTSPOT as a stand-alone network if it would communicate between clients. I'll test that.

My setup, as of last night is a Pi4 named pi4-scope (with an attached Waveshare HAT board) running indiserver as my primary connection point (over WiFi) using:

indiserver indi_wmh_focuser indi_skywatcherAltAzMount indi_asi_ccd "SVBONY SV305 0"@pi3-scope

and a Pi3 named pi3-scope running:

indiserver indi_sv305_ccd

all controlled by a Linux laptop running Ekos, also on the local WiFi network.

Where the focuser is the pi4-scope onboard Waveshare HAT, and the skywatcherAltAzMount connected via my local WiFi network over UDP:11880, the ZWO camera is on a USB3 port of pi4-scope and the SV305 is connected to a USB2 port on pi3-scope. I have connected pi3-scope and pi4-scope via a short null ethernet cable configured as a 2-client simple network. My goal in doing this was both to reduce network traffic and USB load, as I had it all plugged into the Pi4 originally. As it happens, there were no bandwidth or USB issues last evening with this configuration. All worked without connectivity issues.

I used strickly Ekos last evening. Plate solving was great. Both tracking and slew worked well. I was able to go from Saturn, to Jupiter, to M2 and finally M15. Each slew was a bit off, but corrected automatically via solve and slew. The automation used about 3 adjustments for each target, but they all ended up right dead center on the screen.

The only minor problem I had all evening was on the trip from Jupiter to M2. It went about halfway, did a little dance, then gave up. Similar, but not as crazy as the synscan driver in about the same area of the sky. All I had to do to recover was to click slew to target again, and it finished the trip without further issue.

I didn't do any guiding last evening, partly because I tested PHD2 with the new configuration and it connected. When I can get PHD2 to connect, it is very straight-forward and effective. Tonight, I'll prove that guiding does in fact work by doing some actual imaging. I have high hopes. The skywatcherAltAzMount really did work a LOT better than the synscan_telescope driver, and I didn't have to add the tablet into the mix. I really appreciate all the work you did on that driver to get it goiing (especially the UDP bit).
Last edit: 3 years 5 months ago by Jon Carleton.
3 years 5 months ago #61869

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

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

Odd results last evening. I setup as usual and slewed to a couple of targets with Ekos alignment and it did just fine, plate solving along the way and centering each target (skywatcherAltAzMount). Then I decided to try guiding and went to the guiding tab. It is set to internal guider. I was making sure all the exposures and proper camera was set...didn't =intentionally= do anything that should have caused an image or scope move, and the scope suddenly became possessed by demons. I had to run out and shut if off before it started spewing green pea soup.

The next mistake I made was not shutting down and starting everything fresh from scratch. I recycled re-positioned the scope, restarted Ekos/Kstars and reconnected to the still-running indiservers. The rest of the evening was downhill from that point. When I tried a GOTO, it would slew close to the target as usual, and begin the solving cycle. It would solve to within a few arc seconds, then start getting Sync failure. It never would center an image. I tried multiple targets, and the same each time....8 minutes out, Sync, 4 minutes out, Sync, 0.30 minutes out, Sync, 0.15 minutes out Sync Failure! and over and over with Sync Failure until the retry limit was reached.

I did try CCDCiel/Carte du Ciel to try to locate the culprit, but it acted the same, so I cannot blame Ekos for the Sync Failure issue, even if it may have been the root cause. "Close, but no Cigar," syndrome. I should have closed everything down and powered off all the computers and restarted from scratch to exorcise the demon that infested my setup. A bit frustrating after such a good evening the night before last.

Any insight you might have on this issue and how to prevent it will be appreciated. Still in all, better results than I ever got with synscan_telescope.
3 years 5 months ago #61892

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

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

I don't remember things turning that bad for me. I bet your scope was tracking when that happened? If so, it may be a consecquence of communication failure between the mount and the driver. Tracking means the driver periodically reprogrammes the mount to slew at a specific speed at each axes. Having some of this command getting a communication error, the mount may have programmed to slew at a crazy speed. The same communication failure may prevent the driver from instructing the mount to stop... I know, not a really reliable system desing...

After having to turn off the mount, it seems to be a good idea to have a clean start. Maybe you don't need to turn off the RPI, but definitelly disconnect the driver, restart the inidserver, and start from park position, to have a clean sync state.
3 years 5 months ago #61910

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

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

Another not-so-good night. I had trouble plate solving, but that was mostly me getting used to the settings for my new camera. I did get it to solve and sync a few times, but not as it does with clear imaging. That problem is on me. the settings and controls of the ZWO are significantly different than I am used to with my other cameras.

I eventually just pointed it at a spot in the sky and worked on guiding. The guide camera was producing excellent images. Everything was tracking normally. I have used PHD2 with good success with the evil, vile, synscan_telescope driver, so I had reasonable expectations that PHD2 worked with an indi driver and the scope. The only difference would be using the skywatcherAltAzMount instead of synscan_telescope.

Pointing via EKOS, configured to NOT use the internal guiding. As soon as I engaged guiding, the scope became a drunken sailor. Clearly, the calibration process, at least, is over-controlling the scope. I shut it down before things got out of hand and well before calibration was completed. The results were not exactly the same as with the Ekos internal guider and the skywatcherAltAzMount driver, but close enough for me to speculate that the guiding section of that driver was commented out originally for good reason.

This, for the moment, puts me back to using the synscan_telescope driver to be able to engage guiding. I can work around the odd spots in the sky it doesn't like, and guiding is more of a priority for now. I wonder if the skywatcherAltAzSimple will guide properly. I could put up with wobbly tracking if it straightened out when guiding was enabled. My guess is it won't, but I may test that.

I really wish I wasn't mostly useless at C/C++. If this was Java, I'd rip it apart by the roots and take a stab at nobbling it back together. I looked at the Indi-for-Java project, though it looks dead.
Last edit: 3 years 5 months ago by Jon Carleton.
3 years 5 months ago #61927

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

  • Posts: 215
  • Thank you received: 16
Beautiful night here, but I missed it. I found that using the SynScan WiFi HOTSPOT for anything other than sending and receiving motion controls is well beyond the design capabilities of the HOTSPOT. It can connect multiple hosts and will route traffic on its local net, but the data travel at the "speed of smell." A fairly unpleasant smell at that.

I decided instead to add a WiFi router to my telescope kit. A small one, but with some ethernet ports with which to interconnect the Pi3 and Pi4 and a 5G connection to my laptop. My home network is also 5G, but it drops rather dramatically as you move away from the router. Meanwhile, the changes made a staggering difference in image transfer speed. I had considered using VNC to avoid sending all that data over the network, but I don't think I need worry about that now. I typically setup less than 20 feet from the scope, so the bandwidth is...well...as I should have done it in the first place.

I have separated the cameras on the two Pi's. Besides USB collisions, I was having network throughput problems. Now that the bandwidth is solved, I may as well just leave the two Pi computers in the kit....in case you wondered.
3 years 5 months ago #61957

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

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

I am beginning to believe there is something amiss with the basic logic in both the indi_synscan_telescope driver and the indi_skywatcher_AltAzMount with respect to position vs. crosshair reporting. Another long night of testing (and not imaging).

I started with KStars/Ekos with the tablet running synscan and interfacing KStars with indi_synscan_telescope. I aligned with the tablet only to Jupiter. KStars showed Jupiter with the crosshair. I then did a tiny move to a close-by star. It moved in that area, crosshair and all, but the plate solving failed. It failed via max retries (4) and oddly. The first solve showed it about 1 minute 50 seconds off target. The second, 33 seconds (so far, so good), then the next was 41 seconds and the final was 58 seconds. This odd behavior did not occur when I plate solved with skywatcher_AltAzMount.


Then, I tried to move to M15, and the scope moved in that general area, but the crosshair moved "out of the universe." I don't like the synscan_telescope driver, so I blamed it and restarted indiserver with skywatcher_AltAzMount. I restarted KStars/Ekos. The crosshair was in the same place. So, I brought up Carte du Ciel. Same thing. Crosshair out of the known universe. Exactly the same postion as was displayed by KStars. It may be that the screen positioning routine for the AltAz mount drivers is just a bit broken. The scope clearly did not leave earth during the tests. :)

Different test tonight. I am going to try SkySafari on my Android with the SynScan Pro app to control the scope. If that works happily, I'll add in PHD2 with an indiserver running the dreaded synscan_telescope driver. I have, in past tests, had reliable guiding at least with that driver and PHD2. This assumes, of course, that it doesn't fight with SkySafari. That will just leave be back at needing to accommodate plate solving data.

So finally, a question: Do you know if there is a manual way to modify where the scope believe's itself to be with actual data from a plate solve? I'm guessing that setting new RA/DEC coordinates in the indi control panel triggers a GOTO....which would be bad, since it is already there.
Last edit: 3 years 5 months ago by Jon Carleton.
3 years 5 months ago #62030

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

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

I finally had a good night. Alas, the reason was that I was able to eliminate the problem by using strictly the Android Synscan app along with the Android SkySafari app (no indi drivers). Apparently, there are significant issues with both the indi_synscan_telescope and indi_skywatcherAltAzMount. I can no longer blame the SynScan Android app, though I still dislike having it in the mix. When fed data from SkySafari, it passes along a flawless set of commands that both seeks and tracks at a level I have not seen before. The tracking was so good for my "usual suspects" (M2, M15, Jupiter, Saturn, Mars) that I didn't even bother with PHD2 (which would have involved an indi driver at some point).

I did to plate solving (manually) and made manual adjustments and sync'd the mount. Minor adjustments only. The GOTO was pretty close every time.

I still believe that the indi_skywatcherAltAzMount is the better of the two drivers for the Skywatcher 250P, despite its "not production ready" status. The two biggest bugs I see are the wayward crosshair display, which gives the user the impression the scope has gone mad, when in fact it may not have, and the guiding bit. To be fair, I didn't test the guiding issue enough to know if it was related to a network issue. When I get back to testing, I'll look into that. There is also the potential issue of occasional mount madness that could be related to network issues...or something else.
Last edit: 3 years 5 months ago by Jon Carleton.
3 years 5 months ago #62053

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

If we put aside the plate solving and guiding, the mount behaves normally with the drivers? I have EQ8 (which is use with EQMod mount driver) and AZ-GTi (with AZ-GTi driver based on EQMod as well), though never used AZ-GTi with guiding or plate-solving before, just GOTOs.

SkyWatcherAltAzMount uses a different mount model than EQMod, so it may not work well with plate solving and someone needs to take a closer look at that.
3 years 5 months ago #62122

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

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

As far as I know, the AZ-GTi driver is just the EQMod driver with different defaults for connection (upd instead of serial), right? Does the AZ-GTi driver works with AltAz configuration? As far as I know it only works when the AZ-GTi mount is on an eqatorial wedge, and effectively working as an EQ mount. If you want to use your AZ-GTi mount in the default configuration, you must use SkyWatcherAltAzMount os SkyWatcherAltAzSimple, right?

To answer your original question, the drivers (SkyWatcherAltAzMount and SkyWatcherAltAzSimple) basicly works with the mount, with some strange behaviours, which we are discussing here. The plate solving does not make it any better or worse (guiding is an other peace of cake...).
Some of the strange behaviourt is related to some communication issues between the mount and the INDI driver. I blame my too long serial cable, and I definitelly found the mount "going crazy" while connecting through WiFi and UDP, and I have overloaded the wifi by transfering live images.
But some strange behaviour is not related to communication issues, but somehow connected to the translation between AltAz and RaDec coordinates. These issues are mostly due to unsuccesful sync operations, which may be caused by plate solving, but equally can be caused by manual syncing.
As far as I concerned plate solving is essentially needed to use SkyWatcherAltAzMount driver since the main advantage over using synscan is the much easier initial setup of the mount. In the case of synscan you need to do two star training before you can use any intelligent functions, while the SkyWatcherAltAzMount works right after startup, and the mount model is refined as you make more syncs, which is a great feature, at least in theory. In case of synscan any further sync operation makes just a "local ofset" while in the INDI mount model all of them refines the mount model somehow (I don't realy understand the details here) which can be a huge advantage, but if it fails or does not work in an optimal way it may drive the mount model into a totally bad state, and I see no recovery from it (other than restart everithing from scratch).

There is here a funny difference between the behavior of SkyWatcherAltAzMount and the SkyWatcherAltAzSimple driver. the former stores the actual goto coordinates in RaDec form while the later stores it in AltAz form. That means that when you make a plate solve with "sync mount model" option, the mount model is updated and so the conversion between RaDec and AltAz is updated. In the case of SkyWatcherAltAzMount that meas that the mount (hawing its AltAz coordinates not changed) no longer points to the target (by the calculation of the driver) so it slews automatically to the target (although the user does not asked for it). While the SkyWatcherAltAzSimple driver does not slew anywhere since the AltAz coordinates of the scope still points to the requested (stored) AltAz coordinates, but in KStars the croshair is updated to show the actual coordinates the mount is pointing to. The user can then ask to slew to the desired target (or use the proper option on the plate solve tab for that). I think this later one is the correct behavior, the former one may cause user confusion.
3 years 5 months ago #62125

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

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

Please bear in mind that the indi_synscan_telescope and the indi_skywatcher_AltAzMount are quite different animals!

In the case of indi_synscan_telescope driver all the work is done by the synscan app (or hand controller, but you use the app). The driver does not store any information or model abount the mount's state. It gets the mount coordinates from the app, both in AltAz and RaDec coordinates. It issues goto commands to the synscan app to a given coordinates, and all the slewing and tracking is managed by synscan app. The app simple reports the actual coordinates of the mount time to time to the indi driver.
There are places here where things may go wrong.
- The app reports both the AltAz and the RaDec coordinates, as far as I know KStars only use the RaDec coordinates.
- When you issue a goto command in KStars, Kstars gives the RaDec coordinates to the INDI driver to goto to. By default the indi_synscan_telescope worked in a way the it converted the RaDec coordinates to AltAz coordinates knowing the actual location and time of day, and issued a goto to the given AltAz coordinates. But it may not be accurate as the mount is never perfectly aligned, that is why we use training at the begining of the session. But the indi_synscan_telescope driver has no knowladge of the training data at all.
- Also any snyc or plate solve operation tells the synscan app to use a small ofset at the given part of the sky when converting RaDec to AltAz or vica versa. The indi_synscan_telescope dirver also does not keeps track of that.
- That is why I have contributed an option to the indi_synscan_telescope driver that it can issue goto commands to the app in RaDec coordinates. This basically eliminates these issues, lets the synscan app to move to the asked coordinates by it's best knowledge. If you are using my updated version of the indi_synscan_telescope driver (it is in the github main repo since a while, I don't know wheiter it has found it's way to the distroes yet), you can find an option on one of the driver tabs in EKOS for GOTO AltAz or RaDec.
- an other problem can be (i have run into it), that when you connect to the synscan app with the indi_synscan_telescope driver (after correctly setting up the mount and do the alignment) the driver sets the clock and location data to the knowledge of time and location of the RPI. If the RPI's real time clock is not set correctly it may cause serious issues. Your case of "pointing to nowhere" may be caused by this issue. Always make sure the RPI's real time clock is correctly set! I use an RTC module with my RPI.

The indi_skywatcher_AltAzMount does a much greater job with maintaining a mount model, that certanly may still contain bugs, but at least we have the code for it and can fix it. The synscan app is given as is, you may like and use it or hate and don't use it but there is no way to fix it.

Finally: the synscan app and the indi_synscan_telescope driver works quite well for me. I perefer to use it with INDI connected because I have so much more option that using synscan alone.
- first there is plate solving. It helps a lot and can be used with synscan, works well for me.
- I can connect a gamepad to the RPI and control a mount with that during visual sessions, much greater than using the app or SkySafary to move the mount
- SkySafary can either connected directly to the synscan app or to INDI. In case of a hand controller, the only option is to connect SkySafari to INDI (which is a great improvement over using the hand controller alone)
- I have not tried guiding with synscan yet, but it may work too.
3 years 5 months ago #62129

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

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

Thank you for your reply. I much appreciate all your efforts.

To your points:
I do have a very clear understanding now, I believe, of the specific differences between the functional operations of indi_synscan_telescope and indi_skywatcherAltAz mount. Though I am not a C/C++ programmer, I have written commercial complex networking, motor control and remote operations software in assembler and Java for over 40 years. I have now read through the code for the two drivers, along with the motor control spec for the Skywatcher 250P, along with the INDI protocol programming specifications. I have also spent some time looking at INDI for Java, because I believe I can solve -my- problem there, though that entire platform seems dead. If I can contribute testing time to solve the greater problem, I'd feel better about it than just fixing my setup.

I agree that there is a strong possibility of translation issues between RA/DEC and Alt/Az. It -feels- like that from my testing....which is not, by the way, random. I set out with each test to prove or disprove particular steps. I admit to having a warped sense of humor, so sometimes my explanations of tests and results are more literary than specifically factual. You must forgive me for that.

There are a few places I would look for the potential inaccuracy in coordinates. Time, location, and (my favorite) JNow vs. J2000. The latter could be different in different areas of the driver, or calling program and cause some odd results.

Like you, I have been concerned about WiFi issues and RPi time/date. To that end, I moved the Pi to the scope used the Pi WiFi to talk to my local network for NTP and image transfer, then hardwired the Pi (ethernet) to a fairly powerful Cisco WiFI N router, also mounted on the scope, for an on-scope WiFi network, to connect to the Skywatcher WiFi motor client. I would go to a serial connection for the mount motor, but my model requires the hand unit for the serial USB cable connection. I have not had good luck with connectivity from a FTDI/USB cable yet, though finalizing that is a TODO for me. Meanwhile, my high-density WiFi signal should be fairly reliable for the half-meter it has to cover. Image traffic is on a different WiFi channel on the local network.

I have had good results guiding with PHD2 using the indi_synscan_telescope driver. I don't trust it at all for general operations, but once pointed, it will keep you on a star with a little help from PHP2. So, whether that is on or off the current project table is of no consequence to me presently. And, since it involves pulse and not sync, I don't believe it is part of the larger problem.

The big problems are GOTO and SYNC reliability. And by reliability, I don't mean it must go with extreme precision to the target, but at least somewhere close. And the cross-hair must be accurate with where the scope thinks it is. SYNC must work properly and not break things.

I also agree that plate solving is not optional. Both blind solving and relative...but at LEAST blind solving. But that is reliant on a reliable SYNC as well.

The version I am using is a recent (this week) GitHub get from github.com/indilib/indi. I haven't noticed if it has the RA-DEC/AltAz switch. If it has the option, I'll switch it to RA-DEC. Otherwise, I'll look for an update.

If there is anything I can do to test further, please let me know.
3 years 5 months ago #62132

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

Time to create page: 0.756 seconds