×

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: 215
  • Thank you received: 16
OK, I'm going to have to quit saying that I plan to use the scope on a "particular" evening. Yesterday afternoon, it was hot but cloudless, so I set the scope out in the shade to acclimate. By twilight, when I went out to collimate, massive thunderstorms moving in from the NW. Lightening everywhere. So, I packed it in. Somehow the weather KNOWS when I plan ahead.
3 years 8 months ago #57104

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

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

I've been away a bit dealing with some health issues, but I am back for now. I did recompile the skywatcherAltAzMount code with the Guiding commented-out bit removed. It compiled fine and now can be seen by PHD2 (It couldn't before now). I plan to test it tomorrow and see if it will operate the scope properly and guide.

I finally got the hang of plate solving, if I can just get the mount to go where it solves.
Last edit: 3 years 5 months ago by Jon Carleton.
3 years 5 months ago #61717

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

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

I got in several hours of testing last evening. The result being that I found lots of bugs in indi_synscan_telescope. The most remarkable was in moving from Saturn to Jupiter at about 9:30 EDT from my location in NW Georgia (Thursday, October 15, 2020). Saturn slew in KStars was OK, but try to move to Jupiter (virtually next door) and the chart pointer jumped about 20 degrees up and 30 degrees West. Moving back to Saturn, it would jump back. The scope didn't exactly follow the pointer, but it didn't go to Jupiter either. Upon the return to Saturn request, it missed by a a few degrees.

The SynScan Android app, as the intermediary in these transactions would slew with reasonable accuracy to Saturn and correct the issue....more or less. For grins, I tried Stellarium with the indi_synscan_telescope driver (and the required SynScan Andriod app) and got similar results. I recall you mentioned similar issues in this thread or one like it. Regardless, I won't bother with the indi_synscan_telescope driver again. Having the Android app in the middle of things always seemed a bad idea.
Last edit: 3 years 5 months ago by Jon Carleton.
3 years 5 months ago #61742

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

  • Posts: 215
  • Thank you received: 16
I spent a lot of time today with the indi_skywatcherAltAzMount driver that I re-compiled with the guiding enabled and, so far, haven't found anything spectacularly wrong with it. The park/unpark function is a bit wonky, but it always was. It used to spin the scope South by default. Now, Unpark does nothing until you click on the Park function...and a quick Abort (because nobody really knows where it is headed and it is in a hurry). After the unpark/park/abort ritual, the driver behaves reasonably well. Much better than either indi_skywatcherAltAzSimple or indi_synscan_telescope.

Some programs that provide a manual pointing interface (simulated hand control) get the East/West arrows backwards. Odd that there is a switch for North/South to reverse (and North/South are almost never wrong), yet none for East/West. Clear (enough) skies for guiding a bit tonight. I'll report back.
3 years 5 months ago #61757

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

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

Time to create page: 0.451 seconds