×

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
I have tried guiding with the AltAzMount driver driver with not much luck. Although I've tried internal guiding, not PHD. Maybe I should give a try to PHD too...
3 years 5 months ago #61768

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

  • Posts: 90
  • Thank you received: 12
As far as I remember I was able to get the synscan indi driver totally fooled by some not-so-successful sync operation. The sync operation works somewhat different in the case of synscan than the other cases, because the sync makes nothing else but adds an offset to the coordinates at the pathc of the sky at where it is used. And it is done by the synscan app, the INDI driver has no knowlade about it. So it can drive the INDI driver's knowladge about the coordinates and the synscan app coordinates totally out of sync. I know that synscan keeps track of these 'sync offsets' for every pretty small parts of the sky, althogh I'm not sure how small those pathces are. Jupiter and Saturn are pretty damn close...
3 years 5 months ago #61769

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

  • Posts: 90
  • Thank you received: 12
I like to use the telescope with a game controller. This way I can manually stear the scope, and have a feeling of manual search for objects on the sky, while INDI partnered with SkySafari gives me the knowledge of what I'm looking at and where am I going.
3 years 5 months ago #61770

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

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

Odd that...I'm headed almost the opposite direction. While I really like PHD2 =when it is working=, I have real problems getting it to connect and stay connected, especially with the camera. I was planning tonight to use the internal guider. I don't have a joystick presently and have such a narrow FOV anyway, that searching when I am just a tiny bit away is an exercise in frustration. I don't think a joystick would help me much.

My goal now that I have reliable plate solving working is to stabilize the software so that it automatically goes to the image, or somewhere near, then repeats the image/plate-solve/adjust process until I see the image. Since indi_skywatcherAltAzMount more or less goes where I tell it, whether it knows where it is or not, it seems my best candidate so far. Last night was awful. PHD2 kept disconnecting and reconnecting causing "an argument" with the planetarium software and slewing the scope back and forth.

If you do try PHD2, use the New Profile Wizard to create a profile. If things go "wonky" delete the profile and recreate a new one using the wizard. Once things go bad, they stay bad, even when they look OK. When it works, it is great. When it doesn't, it isn't pleasant. I got to one point where I was running PHD2, deleting the profile, creating a new profile and then trying to connect each time I used it.

My plan tonight is to separate the two cameras on different Pi platforms, running different instances of indiserver on each. Since the mount is common to both, I may try the following:

pi1--> indiserver indi_sv305_ccd
pi2--> indiserver indi_wmh_focuser indi_asi_ccd
laptop--> indiserver indi_skywatcherAltAzMount "SVBONY SV305 0"@pi1 "Waveshare Motor HAT Focuser"@pi2 "ZWO ASI Camera"@pi2

then connect to the laptop indiserver as localhost. Either that or some other load balance scheme. Tonight, I plan all KStars. Single vendor, perhaps less network and cpu load. Setting up and spending hours of crash resolution and reset from scratch when I get so close is tedious.

Here's a slightly off-topic question: Do you know if the mount WiFi, in HOTSPOT mode (I have been using it as a regular network client) will support multiple connections and act as a router? Or is it just a one-to-one HOTSPOT? I'm thinking of ways to load balance the network as well.
3 years 5 months ago #61807

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

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

Time to create page: 0.567 seconds